If it Aint Broke, Fix It: Understanding ERP Readiness

One symptom of a company being ready for ERP is counter-intuitive. When you discover this Catch-22, you realize that your need for ERP is resulting from the fact that no one is asking for it. The reason that no one is asking for it because everyone has abandoned corporate IT and formed local informal IT organizations, building unsupported business systems on local databases, utilizing PC application software. Not only is the local organization happy with what they have, they are proud of what they have done when unencumbered by “corporate bureaucracy”.

While the entrepreneurial spirit behind such systems development is admirable, the growth of such practices spells problems for a company that would like to maintain some degree of global standardization. Think about some of the difficulties that cascade from a proliferation of independent local business systems:

The collection, reporting, and analysis of corporate wide business information becomes cumbersome to the point of impossibility, as no one is storing data in the same place, or identifying it with common attributes. Corporate totals are only arrived at after begging local representatives to translate local data into a common – “combinable” – format.

Who is Responsible?

There is a question of legal accountability. In the event a programming error is made, such that export goods are identified with the wrong harmonized tariff codes and the company is subsequently fined for smuggling, who is accountable? If the wrong weight is calculated for a trucking shipment, or you don’t properly designate hazardous material, and a trailer is detained and the company fined, who is accountable? Corporate IT clearly had nothing to do with it, division leadership likely didn’t know about it, and it turns out you’ve allowed a twenty-six year old junior manager with two years of experience to expose your company to significant legal and financial penalties.

Because of inconsistent programming methodologies and substandard documentation, when local programmers leave, there is often no one around who knows how to fix problems or make changes to the local business system. Corporate IT is reluctant to assume ownership of such systems because it takes about the same amount of time to rewrite the functionality in a standard supported system as it does to understand the bastard child functionality.

At the same time that individual functional areas are claiming more and more software victories, divisional leadership finds it harder and harder to pull together a coherent strategic picture of what is happening with their business, because there is nothing to force the local data to reconcile properly, and different functional areas give different numerical answers to the same question.

As stated earlier, you have to actively look for these things happening; otherwise, you will interpret the relative silence as contentment and approval of the current software capabilities. If instead, you find that your organization has collectively given up on waiting for ERP, and is progressing local business solutions in a dozen different directions, you may want to think about an ERP solution.