Why did you buy it ?

Last post I mentioned that I had thought about writing a "ERP Implementation" book. This is my first official post to this blog regarding the process of ERP implementation.

I'm going to refer to Microsoft Dynamics GP and/or Infor Visual ERP during different parts of the book. This is because these two ERP systems are those that I know best and are also pretty good SME (Small or Medium Enterprise) ERP systems. You can find out more about either of them at creative or sabre if you're interested.

* * *

A critical question to ask yourself if you are in the process or about to implement an ERP is "Why did I buy this?." It's curious how quickly the primary project goals get set aside during the implementation process. We often think that we know why we chose to purchase the ERP - but in fact the decision makers involved in the purchase are rarely involved in the actual implementation.

The answer you find should identify the underlying need that drove the decision. Dig deep enough to find the original "pain" that the purchase was trying to address. Identify the decisions that your organization needed to make (at the time the buying process was initiated) but which were not satisfied by the information at hand. This will point the way to why the ERP was purchased in the first place.

Reminding management of the original reason they purchased the ERP will help you out later on in this process, because a number of sacred cows may need to be shot in order to really implement your ERP effectively.

The book on tape (or CD) "Beyond the Goal" by Eli Goldratt has a great section on how messed up ERP implementations can become because the company refuses to change internal processes which are in fact, completely useless (ie - replaced by other processes) after the ERP is put in place.

Be sure to get “buy in” from the management team that the reason for the purchase remains unchanged. It can change sometimes, as the capabilities of the ERP become more obvious. Usually the delivery of this information was the original goal. Whether that be in the format of a report or in some kind of process that was missing (for instance, a purchasing process). Often you come up with a list of reports they were missing but felt would be essential for running the business more efficiently. There are other possible requirements - but you might be surprised, you can almost always track them back to some kind of missing information and a report or view of that information is the real driving factor.

In Visual Manufacturing most reports are driven from Crystal reports or the built in "QRP" reports. In Dynamics GP the SmartList is a fantastic and easy to use alternative to a report.

If you're in the process of a phase 2, phase 3 etc... re-implementation, then be cautious of a report request without a careful analysis of the data required for the report. This is a danger which can lead to trying to cover up the symptoms of a problem with more and more elaborate reports and information. This is best explained in the chapter on root cause analysis, but I’ll give a quick example:

Acme Inc. implements their ERP system and wants to manage their customer supplied materials with a report. Over time the report begins to become very complicated, accounting for scrap produced, quantities shipped, quantities on machines, user defined fields etc… to arrive at a total on hand.


After digging into it we find that Acme is not receiving and relieving the customer supplied material in their database accurately, and many of the complexities of the report are to cover for this fact. Fixing the data at the source makes the report unnecessary, since all Acme needs to do is look at the quantity on hand in their database to manage this material.

So we've determined the purpose which management had in mind before we started the project. Now what do we do with this information.

First we create a "Mission Statement" for the project.
Then we create a "Project Scope."

I'll cover these in future posts.