A Tale Of Two Systems
Sep. 15th, 2010 10:06 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Once there was a computer system. It was an old mainframe system and had been designed and developed in Australia. It didn't mind much about incorrect batches, or odd material numbers, because it took the overall view that "It'll all work out in the end" - an overall attitude of lassaiz faire, although it would never have used such fancy language to describe such a thing! It was easy going and undemanding, and, for the most part, it worked, and its users were accustomed to its foibles and its follies.
Then, one day, it was replaced. Its successor was a client-server system originally developed in Germany that had been around for probably as long as the old mainframe, but which was considerably more complex and complicated. This new system required precision and dedication to detail. This material with this lot number was loaned out to Customer A, therefore it must be received back from Customer A before it could be sent back to Customer B. The same material with another lot number will not do because where is that material now? How can the system keep orderly records if the data comes back in such disarray?
And, lo, the users accustomed to the old system were Not Happy, Jan! And they did complain in great and multitudinous numbers as they learned to use the new system.
Unfortunately for the users, the new system with it's Germanic precision and organisation was here to stay. No haphazard 'tumble it all together and the white and colours will sort themselves out' thinking any more! No more 'she'll be right, mate' attitudes! No, it must be careful attention to detail and the necessity of playing by the rules - crayon marks within the lines - within, I say!
And, lo, it was a big headache for the little programmer sent far from home to help troubleshoot in another city.
tl;dr: I have a headache from dealing with the users learning to use the new system. The system is easy enough; it's the mentalities of the users that's hard to change.
Then, one day, it was replaced. Its successor was a client-server system originally developed in Germany that had been around for probably as long as the old mainframe, but which was considerably more complex and complicated. This new system required precision and dedication to detail. This material with this lot number was loaned out to Customer A, therefore it must be received back from Customer A before it could be sent back to Customer B. The same material with another lot number will not do because where is that material now? How can the system keep orderly records if the data comes back in such disarray?
And, lo, the users accustomed to the old system were Not Happy, Jan! And they did complain in great and multitudinous numbers as they learned to use the new system.
Unfortunately for the users, the new system with it's Germanic precision and organisation was here to stay. No haphazard 'tumble it all together and the white and colours will sort themselves out' thinking any more! No more 'she'll be right, mate' attitudes! No, it must be careful attention to detail and the necessity of playing by the rules - crayon marks within the lines - within, I say!
And, lo, it was a big headache for the little programmer sent far from home to help troubleshoot in another city.
tl;dr: I have a headache from dealing with the users learning to use the new system. The system is easy enough; it's the mentalities of the users that's hard to change.
no subject
Date: 2010-09-15 04:27 am (UTC)no subject
Date: 2010-09-15 03:20 pm (UTC)no subject
Date: 2010-09-20 12:04 pm (UTC)no subject
Date: 2010-09-20 06:52 pm (UTC)I forgot to ask if we're talking SAP software here. But that's been been answered by the comment exchange below. Your story of an IT veteran telling old battle stories made me smile. While I have no personal experience with it, I nevertheless have heard similar stories before.
no subject
Date: 2010-09-20 08:45 pm (UTC)And yeah, it's SAP. :) And it can be finicky at times. (Or, you know - all the time!) On the other hand, when you're talking medical supplies, it's kind of important that they're finicky!
no subject
Date: 2010-09-15 10:04 pm (UTC)However, not all people were fond of ABAP and it's systems and order. Many rebelled and spoke out in fear and anger at it's enforced systems, but they were all eventually ground under the wheels of it's ABAPisms. For no matter what the reason, if it is written in ABAP, it must be good and right.
The end.
no subject
Date: 2010-09-20 12:06 pm (UTC)It's interesting watching people deal with SAP for the first time. I and the other people on the SAP team know how anal SAP can be about things being correctly setup and aligned and sorted out.
Funny story, though: this morning, one of the guys who put in the Old System noted that when they initially installed it over 15 years ago, they had a lot of trouble making it stick. In fact, because it was a rollout, they started off in Sydney, and got Sydney working, before going to Melbourne and the other states to roll out their systems.
When they got back to Sydney, the Sydney office had given up on using it. Just given up! They had to re-rollout the system!
So, heh. We're still here. ;D
no subject
Date: 2010-09-20 12:36 pm (UTC)And if you think SAP is anal as a user, you should try actually having to develop software here. There are requirements docs which are Excel spreadsheets with dozens of tabs and hundreds of rows per tab of questions to complete before you can even start moving on a new version. It's crazy sometimes. (At least, maybe it makes sense for an ERP system which is many years in development and deployment, but not for some of the smaller products which have releases every 18 months.)
And that is a funny story. Yet after 15 years the software is so entrenched people don't want to change.
At least, as you say, you're still there. :)