Home Results Services Products Publications Clients About Us
Ideas and Opinions Brochures Contact Us Blog

Having a single, integrated information system meeting all of the information needs of an entire organization is an attractive idea to executives and a seductive one to information technology (IT) professionals. But no one has ever succeeded in building one, and no one ever will. Organizational and human constraints will prevent it. This is no loss. In fact, having such a system is basically a bad idea. The right way to meet enterprise-wide needs is to use carefully chosen modules connected through standard interfaces, providing effective integration of business processes while preserving technical flexibility.

For over thirty years the information technology (IT) profession has been enamored with the idea of a single, integrated system to meet all of the information needs of an organization. Enterprise Resource Planning (ERP) systems are the current version. The dream is of a Silver Bullet that will slay all information problems with a single shot. Untold billions of dollars have been spent in pursuit of this dream, and we are not much closer than we were thirty years ago. Many things have been tried. None has worked.

The first major attempt to provide this capability was made in the mid-1960s by the hardware manufacturers, most notably IBM, when they created the third generation computer systems. These systems, very powerful for their day, supported multi-tasking and later multi-programming. Their power was so great that even a large company could realistically think about all of its applications on a single machine.

There was the unspoken assumption that once all systems were on the same machine they would be able to communicate easily with one another. Anyone who managed a computer center in those days soon learned that this was not so. The limiting factors turned out to be the regiments of console operators and armies of tape hangers needed to make things happen.

The next effort (early 1970s) centered around the idea of a corporate data base, a relational data base containing all machine-sensible data in the enterprise. The idea was that if all systems used a common data base they could effectively communicate by use of the data base and that corporate wide systems could be implemented using the corporate data base.












back to top















back to top















back to top















back to top

Data base technology ­ hardware and software ­ was simply was not up to the task. Furthermore, even small applications showed the necessity for increased analytical capability beyond simply connecting systems. Finally, only 2% to 5% of corporate data existed in machine sensible form.

As the problems with the data base approach were recognized (mid-1970s) the idea of a comprehensive MIS came to the fore ­ based on relational technology and designed from the top down to assure that all company needs were met.

Once again the technology was not completely up to the task, but it was getting so close that the importance of other issues became clear.

  • Senior management support
  • User support and acceptance
  • The need to revise business processes to use the technology
  • Organizational inertia and politics
  • Human resistance to change.

MANY OTHER SMALLER EFFORTS, TOO NUMEROUS TO DESCRIBE HERE, INCLUDING: The first major attempt to provide this capability was made in the mid-1960s by the hardware manufacturers, most notably IBM, when they created the third generation computer systems. These systems, very powerful for their day, supported multi-tasking and later multi-programming. Their power was so great that even a large company could realistically think about all of its applications on a single machine.

ERP is our current attempt. It was originally promoted as the long awaited integrated system to meet all of an organization¹s information needs. The concept is incredibly seductive, but it is essentially the same as the promise of MIS two decades before. Here is a scenario.

A United States based company sells a widget in France. As soon as the transaction is entered into the sales system, these things happen automatically:

  • Inventory is decremented, the warehouse in notified, a shipping ticket is created, the shipper is notified, the item is picked, packed, and shipped.
  • Factories in Malaysia and Taiwan are notified of the sale and parts ordered for assembly and restocking.
  • The customer is billed, currencies are translated into home country currency, and the financial system is updated to reflect the sale, costs are captured, and the P&L Statement is updated

This is an executive¹s dream come true ­ having timely, accurate and consistent understanding all of the corporate consequences of each transaction.

The users have learned:

  • No single vendor can provide best-of-breed solutions for all functional areas of a business. It is imperative that any system allow graceful interfaces with other systems.
  • Implementation of an ERP system requires re-engineering business processes at the same time that the new system is being installed. This causes major corporate disruption. We have known since the early days of information systems that any new application affects the business process it supports. ERP systems, with their goal of supporting larger and larger segments of an enterprise, cause greater and greater disruption.
  • ERP is very expensive, and requires large commitments of money and user organization manpower.

The vendors have learned:

  • They cannot supply best-of-breed in all areas of business. Hence they promote "bolt-ons" and "strategic partners" to fill out their product offerings.
  • Specialized expertise ­ beyond software expertise ­ is needed to implement large systems.

Suppose a company could acquire a complete ERP.

  • Suppose it could afford the cost in dollars.
  • Suppose it could reengineer all of its business processes to reflect the requirements of the ERP software.
  • Suppose it could afford the cost in business disruption.
  • Suppose it could convert all its data to the new system without problems.
  • Suppose it could train all of its people to use the new system.
  • Suppose all of its people accepted the new system.

Every company in today¹s'world must be able to cope with radical and rapid change.

  • Changes in business needs engendered by competition, regulation, and the business environment.
  • Changes in customer demands.
  • Changes in its own business strategies.
  • Changes in the business environment.
  • Changes in technology.

The larger the system, the more difficult it is to make changes. Tracking the cascading effects of changes in an enterprise-wide system is a mind-boggling task.

  • Can it be done? Of course!
  • Would it be a big job? Very!
    (Remember that 80% of all systems development budgets are already spent on maintenance.)
  • Are there better ways to spend resources? Yes!

Could a company ­ with the necessary resources ­ implement and operate a complete ERP system?

  • Perhaps, but considering all of the costs and all of the problems, this is a bad idea.

None the less, the ERP vendors have sold billions of dollars worth of systems, and are continuing to sell at a substantial rate. What is going on?

The user community has developed a very pragmatic approach to the enterprise-wide system issue. The approach of choice is

  • Build a general purpose infrastructure, most often based on TCP/IP standards.
  • Buy individual modules from the ERP vendors and others, and implement them one at a time. Typically these modules support common business functions such as finance, human resources, etc. Users often buy several modules from the same vendor because it minimizes learning time and interface problems.
  • Buy specialized modules from solution set providers such as Ariba and CommerceOne, and interface them to the ERP and other modules.
  • Develop custom modules for functions that provide competitive advantage ­ for example, a manufacturing system that radically reduces cycle time.

This approach allows the company

  • To install individual modules when and if needed, rather than commit up front to a company-wide multi-year program.
  • To control the organizational disruption and spread it over a long period of time if appropriate.
  • Most important of all, to respond to changing business needs by making incremental changes in individual modules without endangering the entire organization.

It works!