ERP Testing and the Road to Failure

Except for badly controlled change management, no single activity does more to ensure a failed ERP implementation than passive and incomplete testing. Part of the value of testing is obviously to verify that the system works, but there are other large benefits that accrue, as well. Resolving problems gives end users and the ERP implementation team experience in trouble shooting. Participating in testing exercises solidifies classroom training for end users, and allows them to begin understanding interactive effects.

Testing should be thought of in three distinct phases, each more ambitious and complicated as the ERP system grows toward completion.

The first phase is testing individual transactions to see if they execute. This is an uncoordinated activity; each functional area has a list of transactions they need to have working by a certain target date, and each transaction is expected to be tested and operational.

Running Business Process Tests

The second phase gets more interesting as the appropriate transactions are sequenced into complete business processes, and each business process tested. Examples of testing a business process might include “taking an order and shipping it from inventory”, or “taking an order and manufacturing it”. Spend at least two to four hours as a team to identify the fifteen to thirty business processes that will represent 90% of normal activity in the ERP system. Write transactional scripts to make the processes as complete as possible. Do not expect the initial business process tests to go smoothly; your team may spend an entire day the first time you try to coax a sales order into the ERP system, then plan, manufacture, ship, and bill it. The next test will take a little less time and the last few tests go fairly quickly as problems have been resolved down to mostly master data errors. During this phase you may also recognize decisions that sounded good in the conference room, but are painful in reality. If you move quickly, it is possible to fix these pain points and avoid the spectre of ERP failure.

Further Reading: Steps to ERP implementation success

The final phase of testing is volume testing. The best results for volume testing occur when you select a real life data set for a given time period, and try to replicate the real world. For instance, can you duplicate all the business activity you conducted in a week, and make the ERP test system generate the same amount of revenue as you did in actuality? To run a test of this size, your master data must be complete, and you must initialize your sales order, inventory, purchase order, and production order data exactly as you would at go-live. After a successful volume test, you will either know for certain that you can survive ERP go-live, or know that you need to make some adjustments and test again.

Even with robust testing, you will find unexpected problems at go-live. If you have tested aggressively, the problems will be manageable. If you have chosen to test safe scenarios using prepared data, you may encounter enough surprises at go-live to put your ERP implementation into fail mode.