|
Hi AlI've resisted (so far) any comment on your methodology because I understand how this kind of approach can evolve. The need for fixes such as you describe is more generally encountered in homegrown systems where, rather than provide a method to back transactions out correctly and reprocess them, the programmers decide not to provide the additional maintenance programs required because the error "won't ever happen", or because management decided - possibly after it has happened - that having programmers create maintenance programs for something that "doesn't happen very often" is not a worthwhile use of funds. I don't see so many of these systems these days...
However, where such maintenance programs exist as part of the application then the correct procedure as Tom mentioned is to use them to correct the error. This is how you provide an audit trail that corresponds to what actually happened. What the users wanted to happen is irrelevant, the system ought to reflect what they did - there is no other way that anyone can have any confidence in the system otherwise.
Your logic inevitably means that any output the system produces or any data it contains cannot be trusted as someone may have "touched" it or "fixed" it.
When using back doors to fix things, particularly in large, complex packages such as you are using, the end result is that you end up fixing symptoms rather than causes. Instead of the people in accounts (for example) learning to do things correctly, they learn to do them incorrectly. Nothing teaches someone how to do something right faster than having to do the additional work that is required to fix it.
Additionally, as you pointed out, having the problem fixed properly saves time over the long run.
The other thing typically experienced when people starting taking shortcuts such as you describe is that the integrity of the database is gradually compromised, leading to more shortcuts being required to fix "downstream" errors as the resulting data integrity issues start to compound and create other "weird and unexplainable" errors. I always visualise this as the mythical little dutch boy trying to plug the dyke - he can never succeed as there will always be one more leak popping up. To stretch that further and make it relevant: he is trying to fixing a symptom of the dyke being fundamentally unsound, when what really needs to happen is that the dyke needs to be replaced. So it is with the approach of fixing and patching things - this approach needs to be eradicated.
In your earlier email you commented on the fact that there were more errors occurring, or more fixes being required. I'd hazard a guess that the way to eliminate this growth would be to eliminate the use of "fixes".
Even though it might be drawing a long bow, it seems to me that ultimately this kind of approach does the software, the iseries and the business a disservice, not to mention reflecting poorly on the IT department in the eyes of users. Having the IT department constantly having to fix things that are the result of user errors usually translates into the perception that the IT department has some kind of efficiency problem or is a constant hold up. The work being displaced from the area it occurs in also means that work that should be done by the IT department - for example training - is being consumed by unnecessary fixes. Sooner or later IT is asking for additional staff to handle the fixes that the "system requires", eventually leading to upper management asking "why not just get another system, this one is full of problems".
You didn't really say whether you would accept your bank "fiddling" with your records, but I wonder if you would accept errors in your paycheck for the same reasons. Let's hope that both your bank and your payroll are giving you the same information that they provide to the tax department and not some patched information that someone has fixed so it came out how the payroll clerk wanted.
I realise that you can't realistically change the culture of a business if that's how things are done where you work, nor is it always practical to be righteous and holier than thou about this kind of approach, but in the longer term this is not an approach that will serve you well. I understand that sometimes fixes are required in the short term, but they should never make their way into Standard Operating Procedure.
I can also agree to disagree about your perspective on this - I am not in your shoes, and therefore can't fully appreciate your situation and the culture surrounding it. I don't for a second doubt that your intentions are to do anything less than the best for your company regardless of my opinion on how things should work.
regards Evan Harris At 08:02 a.m. 2/03/2006, you wrote:
It is my view that, when making corrections, the system should reflect what the users WANTED to happen, that the computer geek's customers are the users of the system, and the customer should be presumed to be right, in what they ask for, unless it violates some management policy. Software fixes are great, because although it may take the programmer more time to set them up than one manual fix would take, over time, the time saved on the manual fixes tend to accumulate. When there are multiple alternative ways available for making corrections, the approach that I think should be used is the one that eats the least amount of time, irrespective of who is doing whatever. But that is not my call. This has been how I have done my job for decades, at many different employers and under many different managers. I recognize that you have a contrary view, and I will be asking my current managers if they agree with you or me, because over the years there has been some evolution in philosophy on what is appropriate. The bank that I stick with is the one that seems most solvent, according to reports on banks, whose personnel behave like the customer (me) is always right, and I don't catch them in lots of errors. - Al Macintyre http://en.wikipedia.org/wiki/User:AlMac BPCS/400 Computer Janitor ... see http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html --
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
