Re: Small changes are better RE: Daylight savings time

A scenario ...
I write a check for $100.   The clerk at the bank makes an error and
enters the check as $1000.00.  I figure this out when balancing my
account, and go to the bank asking them to make me whole.  I had
enough slack in my account that no other checks bounced.

What should happen ...
<a> some programmer at the bank backdoors my check and they re-issue
my statement?
<b> the bank credits me the $900 difference plus the lost interest,
which shows up on my next statement as an error correction.

If <a> happened, I would be finding another bank, and so would you I imagine.

My position is ...

The fact of the matter is that mistakes happen; that is why there are
methods in any system to reverse transactions or make adjustments. 
When an error happens, those means should be employed if at all
possible.  DBU or SQL or fix programs should only be employed when the
system cannot be used.

Question for the list ... is my position unreasonable?  How are these
situations handled in your companies?

On 2/27/06, Al Mac <macwheel99@xxxxxxxxxxx> wrote:

> I use back door solutions on average, a dozen times a week.
> About once a month I figure out another back door solution to a problem we
> been having that I had not previously figured out how to fix.
.....
> Years ago, back door actions were once in a blue moon.

This fact reveals a lot about the situation.

> The actual back door action probably took me less than an hour to
> implement.  The unexpected mess on the system cost me several hours, and
> greatly inconvenienced people who depend on the stuff that runs thru GO
> CMDSCDE which amounts to dozens of jobs a day.
>
> I told them that I was happy to know that this kind of fix was in fact
> doable, but next time I will strive to find a different way to do it.

This is a huge problem with back door fixes; Murphy and the law of
unintended consequences are both waiting to bite you in the butt.

> While there are also solutions within the system for most scenarios where I
> doing back door stuff, we are on tech support contracts, where if we not
> call tech support, we not have to pay them anything, which means management
> approval to call tech support, which means if we can figure out a back door
> way to fix some problem, that gets used instead, which means the company is
> experiencing a rapid growth in using back door fixes, like business as usual.

This is nonsense.  The users are perfectly capable, without calling
tech support, of crediting and rebilling an invoice, or correcting an
incorrect PO receipt, or an incorrect warehouse transfer, or an
incorrect production posting.

> We know about issuing credits and re-billing.  That requires more work that
> the regular personnel are not enthusiastic about doing, when there is a
> perfectly good back door guru available.

This is the real issue; the users have become lazy and complacent. 
They are careless, taking no care to make sure they do things
correctly, because if they screw up Al will fix the problem.  You
ended up spending 4 hours doing something that would have taken the
users 15 minutes to fix.

Don't you have a list of requests piling up like the rest of us?  How
much more could you do on that list is you didn't spend (perhaps?) 8
hours a week doing these back door fixes?  Perhaps the time could be
used tightening up the programs to reduce errors?

> The business documents appeared the way the people requested them to
> appear, both at the customer site and at our site.
>
> The customer wanted the invoicing and receivables to reflect reality as if
> the shipment was made Feb-3.  The "paperwork" on the invoicing and
> receivables was the way desired by our personnel, and personnel at the
> customer site, according to e-mail back and forth with them.
>
> Our shipping documents and history showed that the inventory actually
> walked out of the building Jan-20.  No fakery was done with the actual
> shipment.

However, your paperwork no longer matches your system.  In the event
of a dispute, there is no clear paper trail, and no paperwork
indicating that customer received the shipment for which they have
been billed.

> There was e-mail between relevant personnel identifying the error and
> clarifying what exactly they wanted done about it.
>
> I do the billing in the evenings after everyone off the system.
> My first steps in billing are
> * Check to see if the shipping people are done for the day.
> * Check 3 different ways messages & e-mail are sent to me from personnel in
> shipping and customer service requesting back door fixes to the data for
> billing from today's shipments

So, the users are so prone to errors and so careless that you, the
computer guy, have to stand at the ready to correct those errors. 
Your company needs better clerks, or the programs need to be fixed to
prevent errors, or both.

> The attitude by my co-workers, who are in charge of the data, is that if an
> error in shipping is allowed to stand in billing, then THAT is a false
> document.
> e.g. shipping tells BPCS that we shipped 1000 parts at a price of 2.25
> each, when in fact only 100 parts went out, which should have been priced
> at 4.25, then the billing invoice should reflect what was actually sent the
> customer, at the price at which it should have been sent, because they
> shipped against the wrong customer order line, where quantity discounts are
> based on quantity involved.

No, it is an INCORRECT document, which is a completely different thing
than a false document.  When you back door the system, the documents
are CORRECT, but FALSE.  When the users enter the corrections and
issue the corrected documents, then the documents are TRUE and
CORRECT.

My view is that the system should reflect what actually happened,
rather than what the users WANTED to happen.  If they make a mistake,
they should fix it using the tools available; you should only
intervene when their tools will not correct the situation.

As I noted, when started at my current employer we had a situation
similar to yours.  One programmer spent a lot of time doing back door
fixes.  I hate back door fixes, and wanted the programmer doing (gasp)
programming.   Surprise, surprise .. the number of errors went down
tremendously.  The users developed their own audits to prevent errors,
because they didn't want to take the time to fix errors and they
didn't want errors out there for the world (and their bosses) to see. 
And when they make an error, they fix it without having to call IS. 
And I got a programmer back.

Regards..

--
Tom Jedrzejewicz
tomjedrz@xxxxxxxxx