MIDS301 - The SAP Project
Yesterday in class, we read a short play about the inner workings of a company written by our very own professor, Michel Avital. The play focused on the IT issues within a company that produced metallic alloys called "Metalica."
All departments of the company were using different proprietary legacy computer systems that did not communicate cross-department. In its current state, the sales department could not access current inventory numbers stored in the manufacturing department's computers or vice-versa. This was viewed by upper management as a target area where efficiency could be improved greatly; in fact, the head of systems development claimed that this shortcoming would be detrimental to the company's performance and possibly cause it to become uncompetitive in the long run.
The company decided to implement a system called SAP in order to standardize computer systems. Over the next months, the IT department moved quickly to install the new systems in the test department, a serivce center located in Hopewell, VA.
The results of the implementation after more than a year had passed were less than exciting. In fact, the general manager at the service center called it a "meltdown" and spoke with the head of systems development in a curt and accusatory manner. The director explained that only 16% of IT projects are executed without problems, while two thirds are abandoned eventually. While they did not want to be part of the failures, bumps in the road are expected and will be worked out as soon as they are recognized.
This is as far as we have reached in class discussion. Further reading has revealed that Metalica does take efforts to resolve the issues with the installation of the system, but the company will continue to wrestle with IT problems for some time to come.
The Standish Group statistic about IT project failures is one part of this writing that should be highlighted. On the surface, it is positively astonishing that only one-third of IT projects should ever succeed at all, let alone only a measly 16% be executed without long-term issues. Then again, when one thinks in the context of this paper - the growing, infantile IT market of the mid-1990s - most companies had legacy systems dating back to the 1980s and even the 1970s when computers were exclusively purpose-built and custom-installed as needed. This is exactly what happened in this company - funds were allocated to computerize certain databases when the need was recognized and it became cost-efficient to do so. This resulted in a patchwork of non-compatible systems that were never linked to each other nor did they have the built-in capability to do so. The architects of each individual system did not recognize the need for these networks to communicate with each other; perhaps most of the networks did not even exist when these systems were installed, in some cases. The task left before the IT department to standardize was for certain a daunting one.
Comments