Preface
Chapter 2: Why Killer Applications Can Be Assisted by ERP and CRM Software
2.5 Complexity in Information Technology and Its Effects on Enterprise Resource Planning
As the preceding sections brought to the reader's attention, to a very substantial extent, companies run their mission-critical applications across a variety of platforms that are poorly integrated. They have been put together under one or many roots as if they were never intended to communicate with one another. Both the time to introduce ERP software and the risk that these mismatched platforms will not work as a system increase geometrically as the complexity of the communications chores and
hardware/software configurations increases.
The fact that most computer applications available today grew like wild-fires in the 1954 to 2000 timeframe is not surprising. What is surprising is that far too many companies stick to this mismatch of technology platforms that offers them far too little gain. Sometimes they do so because of inertia. In other cases, they hope that their obsolete and expensive technology will not erode their finances or their competitive edge. They are wrong, of course.
Nothing alienates customers and internal users more than technology that does not work in user-friendly and effective ways.
In a period of fast change, there are duties and challenges that cannot be put on the back burner while sticking to the old stuff.
There is no better example of how counterproductive expensive old programming libraries can become than the huge amount of code maintained by the U.S. Department of Defense (DOD). A 1994 study asserted that (at the time) the DOD had more than 1.4 billion lines of code associated with thousands of heterogeneous, non-combat information systems. These were located at more than 1700 data
centers.[2] This enormous inventory featured many functionally duplicative systems, thereby creating two classes of problems:
1. The cost of operating this applications software inventory consumed an enormous portion of total DOD information technology-related spending, which stood at $9 billion annually.
2. Despite such a high level of expenditures, the DOD was often unable to obtain correct information from various existing databases, due to the lack of standardized information elements and data structures across systems.
This situation fits hand in glove with that prevailing in many industrial and financial organizations today, albeit on a smaller scale. Making the same query to each of the disparate, parochial, and
heterogeneous payroll systems can result not only in multiple answers, but also in several different, incompatible, and contradictory answers. Consolidating the responses to online queries has proved to be an impossible task for many companies and government agencies as well. In such an environment, even the best ERP software will offer no benefits to its user, and might even add to the confusion. The benefits we project from ERP, the Internet, or any other system are always proportional to the
organization and preparatory work being done.
Let's face it; our society is not that successful with the implementation of computer technology. Not long ago, reference was made in an article by Todd Ramsey, IBM's worldwide head of government services, who said that: "About 85 percent of all public-sector IT projects are deemed to be failures."[3] This, of course, does not mean they are total disasters, but they usually take longer to implement, cost more money than planned, and deliver less than what was originally thought.
The same article aptly commented that, by and large, the reasons why big government IT projects get into difficulties are by now understood. The problem often starts with how contracts are awarded. Steve Dempsey, Andersen Consulting's E-government specialist in Britain, says that tender documents often run to 1000 pages and picking a winner can take 18 months.
In a fast-moving technology, both the 1000-page document and the 18-month delay in choosing a contractor can be unmitigated disasters. This and the previous example help explain how awkward are the ways the administration works, and why what is obtained in terms of deliverables is so often
substandard. By the time the 1000-page tender is completed, technology has changed enough to make the description rather obsolete. Some 18 months down the line, the wrong "winner" is chosen and is being asked to do exactly what he should not do.
If one thinks this happens only to the bureaucrats of government services, think again. It also takes place in industrial companies and financial institutions. In my 1999 seminar on "High Technology" in Rome, Italy, one of the participants was the IT director of a large insurance company. Summing up what he said in a few words gives the message that the Middle Ages of EDP are still the "right stuff" today:
"What was valid in the 1960s continues to be the best solution." At least that is how they think in his company — and how they act.
These facts are brought to the reader's attention because I have found them in existence — albeit in less acute terms — when ERP commodity software is introduced to a firm. Only the best companies changed things significantly, including their culture; and this because of the Internet's open standards which, when correctly implemented, allow everyone to effectively communicate with everybody else following the same norms.
Another problem to be brought to the reader's attention regarding the efficiency of ERP implementation is a tendency for IT integration firms to over-customize applications, which is synonymous with over- complicating them. This runs contrary to the principle that off-the-shelf programming products should be used straight-out-of-the-box. As case-after-case demonstrates, changes run deep into the structure and functionality of bought software.
The cases of two recent IT auditing projects come to mind with this reference. One was a bank that bought off-the-shelf software to replace some of its aged commercial banking routines. This happened nearly three years before an audit, and the package they bought was still not running because so much massaging was done that the bugs continued to multiply. The self-made customization reduced the bought software's functionality to below that of the old routines and introduced so many weak points that there were continuous interruptions during runtime.
The second example is exactly the same case of irrationality but with ERP software massaged by a manufacturing company. Here, too, there was a programming product massacre, which also negatively affected other applications. With so much scar tissue around, the confidence shown in the prospects for ERP implementation waned, the end users rejected the service, and the entire project was discarded.
Where both the manufacturing company and the bank failed is that they altered the off-the-shelf
software rather than reengineering their old systems and procedures. Perhaps the former course looked easier at the start; perhaps they lacked the skill to do a neat job in restructuring; or perhaps (and this is the most likely), by being computer illiterate, top management was taken for a ride.
One is justified in asking, "How can computer user organizations reach that level of confusion?" The answer is that over the years their basic information system has been continuously modified — to a large extent through patches — without the benefit of a master plan. It has been supposedly beefed up, and these were presented as made to meet changing needs and upgrades, including functional
requirements, evolving business rules, new data architectures, and requests for management information.
However, the deliverables were not forthcoming and what was available was substandard. Several user organizations have recognized this problem of working without the grand design of a business
architecture, but few have taken the necessary steps to correct the situation. As a result, the variety of incompatible computers, operating systems, database management systems, transaction processors, and data structures not only continue to exist, but are also made worse over time. This is the prevailing situation and, as such, it dramatizes the need for reengineering and reorganizing operations prior to planning for killer applications.
[2]Communications of the ACM, 37(5), May 1994.
[3]The Economists, June 24, 2000.