ERP Implementation: is Testing a Waste of Time?

For the first-time implementation team, the ERP implementation process is as mystifying and frustrating as any experience they will have in their business careers. Team members previous successes at installing or using legacy systems made them the obvious choices to populate the ERP team, but those success formulas are irrelevant to understanding and comprehending the impact of total data integration. This is because their experience says that the key to a smooth implementation is to test, test, test, test and then test some more. Unfortunately, in an ERP environment, that mental model is as logically flawed as thinking about a small nuclear explosion.

Wrestling the Octopus

Imagine you want to test the validity of your blueprint. Your vision is to select a few big products, a couple of big customers, run through some order-to-cash cycles and work on optimizing it. This is totally reasonable in a legacy world. In an ERP environment, though, everything has arms and legs that can't be avoided.

The first set of problems is that the customers aren't validated for credit, the materials cannot be ordered because they have not been costed, and the bills of materials cannot be exploded because there is no procurement sourcing data. So your finance people set up some credit limits, your purchasing people create the appropriate vendors, but then your costing people say they can't just put in a cost; they need plant budgets, SGA budgets, capacity allocations. So you talk and you compromise and you figure out that moving forward means forfeiting any meaningful financial data. You place the customer order, but it won't activate because you have no finished goods inventory, and it won't give a promise date since you have no inventory of the components, and no purchase orders for the components. So you force in some inventory, but it can't be applied to an order because you haven't reported it passing quality. And so on and so on until by the time you've actually tested shipping one order, so much time and effort has been expended that the idea of any fine tuning seems farther away than lasting peace in the Mideast.

And that's when the paradox begins to dawn on you: The only way you can actually test an integrated system is to test everything at once, and you can't do that until the system is completely built, and master data populated. But once the system is totally built, by definition, you are only testing for out and out failures.

The moral of the story is that there is no such thing as optimizing an ERP implementation with testing. The best that you can hope for is that you have made good blueprinting decisions, that you do not disrupt business at go-live, and that your ERP team has the talent, creativity, and resources to fix and improve the myriad of unanticipated outcomes that show up after implementation.