Sometimes new software is the answer. Sometimes it isn\'t. Have you asked the right questions to know? The organization may have skipped a detailed systems analysis step.
Occasionally, an organization will leap to the conclusion that a new system or software package is required when, in fact, there are cheaper and more reliable options available. I had this illustrated for me very graphically recently by one of our clients.
This organization is a large, well managed insurance company that thought it needed a complex new accounting system. The existing system dated from the early 1960s and was perceived to be antiquated, limited in functionality, hard to use and hard to maintain. At some point in the past, the comptroller had been promised a new system, which, of course, he accepted as a good idea (\"new\" always being better than "old" in our society). When the estimated completion date for the project drew howls of disdain from the user community, we were asked to assist in finding other options. What we found surprised both client and consultant. It also illustrated an expensive error that your own organization could make this year, unless you recognize some clear indications that a new system or software package may not always be the best business solution.
First, look at why your Information Technology (IT) and user organizations feel that a new system is necessary. In a situation similar to our client\'s, the best questions to ask are:
1. What specific functions does the user perceive as missing from the existing system?
2. What is the incidence of problems with the existing system and what is the root cause of these problems?
3. What factors cause the existing system to be hard to maintain? How much resource is required to maintain it today?
You might find some surprisesin the answers. For instance, you might find that from the users\' perspective, dissatisfaction has taken the form of an amorphous feeling that \"the whole thing is a mess.\" Reluctant to question an influential user, IT may have skipped a detailed systems analysis step that would isolate the real functional deficiencies the user is encountering. Be surprised and concerned if you find that this important step in the justification process is missing.
You may also find that the problems encountered with the existing system are not really related to problems with the code, per se. Systems built in the\'60s and early\'70s are often difficult to stage, run and restart. This type of problem, while serious, does not indicate a basically unreliable system.
Finally, you may find that your technical staff is proposing a new system because they are tired of fighting with the old one. No one wants to live with "spaghetti code" or an outmoded system and file structure for the rest of his career. Since implementation of a new piece of software is what most IT organizations perceive to be their strong suit, it is natural that this method of problem solving would be the option of choice.
New vs. Old
Next you might want to look at how the available software package options, and similar systems being used by other companies, stack up against your old system. You may find some interesting indicators.
1. The modifications required to the best packaged solutions you can find are predominated with changes required to keep functions currently available to your users from the \"old.\"
2. Other companies using comparable but newer systems may be laboring under limitations that your users would find unacceptable.
3. The replacement cost of the options that you have is too high in terms of dollars, staff or time.
You may also find some reasons to resurrect your old system.
1. The payback on staff time required to restructure, redocument and enhance an existing system compares favorablyto package implementation, and even more favorably to in house development.
2. The implementation of an enhancement project often gets results to the user in an evolutionary fashion and more quickly. The users are seeing changes to a system that they already understand.
3. The portions of the system that are retained have already been debugged as a result of the millions of transactions that have been processed through them.
In the case of our client, the project approach was shifted to enhancement of the old system. Both the technical and user staff were initially concerned about the change, but willing to do what was best from a business standpoint. The project is currently underway and the prognosis is very good. The company will save a significant amount of six figure money in the process, and the comptroller will begin to get his \"new\" system nine months earlier than originally estimated. Like the mythical Phoenix, it is rising from the remains of the old system. The resurrection process for the old system, just as the one for its namesake, is truly inspirational.
Those of you who read this department regularly probably appreciate the irony of a writer who is so positive on the use of software packages recommending that they not be used in certain circumstances. While acknowledging the irony, I feel compelled to point out that no one needs \"bad\" business in the long run.
Software vendors need success stories to get future business. They are best served when their products are planted in the fertile ground of true functional deficiency or technical obsolescence, and not when their products are forced into an inappropriate environment. It is far better for the vendor and the software industry that the funds saved in the resurrection of some old systems be spent on other packages in other functional areas where the payback can be more significant. This process is good for everyone in the industry, including Yours Truly.
Ed Praytor is president of Systems Management Resources, Inc., an Atlanta, Georgia firm that specializes in assisting companies withsoftware package implementation and use.
This article originally published in BUSINESS SOFTWARE REVIEW, March 1988.
