While I was in the Chessie System’s Transportation Department and responsible for installation of ‘Terminal Service Centers’ at a dozen terminals around the system, the reality is that despite all the efforts that go into understanding all the job functions that take place at a particular location and accounting for them in the new system - there is a learning curve involved with EVERYONE, both employees and trainers, in developing the proper, repeatable procedures to correctly handle the situations.
In the first week of implementation it might take doing a operation 4 or 5 times to get it to a successful conclusion - like anything else, familiarity breeds improved performance. At the start of an installation, the local employees would always ‘cry’ that the operation did not have enough people working to accomplish the tasks - and, at that point in time, they are right - if a person takes the time necessary to do, and re do the job four or five times to get it successfully done - no amount of manpower will be enough. However, once employees are sufficiently trained and competent in doing their jobs ‘the new way’ there is more than enough manpower working to get the job done - in some cases it was even possible to further reduce the terminal’s clerical manpower as the employees performed their job function proficiently.
One hard rule - once the computer is interjected into the work flow with it performing various job functions and reports along the way - THERE IS NO GOING BACK TO THE OLD MANUAL WAY. The reality is that after six months to a year, employees forget all the checks and balances of their old systems and would be in big trouble if an effort was made to return to manual systems.
The issue is not so much that it’s impossible to return to a manual system or that ‘institutional memory’ tends to be short even with low turnover and high motivation. It is that you never, ever cut over to a new mission-critical system without keeping the old one running in parallel.
Obviously the old KCS system had been doing its job, including any protocol translation between KCS systems and some purported L&A legacy thing persisting over 3 decades. Things broke because of issues with CP’s build, and in the absence of specific technical information from CPKC about the specific issues – and it may show up in the computer tech press at some point -/ we can only note that if they had run in parallel even a few days they would have identified the points of disaster and started fixes or patches or workarounds without service crises.
There has been a regrettable trend to extend some of the working principles of the Internet as developed by the IETF into software build and test. It’s attractive on paper to code lean and agile, then quickly identify only what breaks and fix it or work around it ASAP. All that waterfall crap and extensive testing and exercising is so Twentieth Century!
I watched that attitude completely ruin Yahoo Groups in only a few years.
I doubt if it ever existed except in some fantasy world.
I did experience the changeover at my college from a hybrid paper-based + computerized final grading to completely computers [and yes rather late in the day!] It was an experiment with some departments continuing with the old and some with the new. The results were obvious in favor of computers: reduced staff man-hours and fewer errors. But doing both contemporaneously? No.
I worked with computers for 45 years. I started out in 1964 as a computer operator trainee working for Union Carbide on the 1401 series computers. Worked for the US Government for 38 years until my retirement in a management position. I did it all and completly understand how two different computer systems work. For example I was tasked with making an Apple 1 computer talk to our mainframes seamlessly. Totally different operating systems and data. Was very interesting especially since all data was encrypted.