Experience tells us that poor system testing before an ERP system go-live inevitably leads to disappointment and, in the worst cases, outright failure. It is difficult to get an accurate figure for failure rates because different people have differing ideas on what success and failure are. Some deem it a success if the system goes live, regardless of how well it delivers on anticipated benefits; and even failure comes in different flavors.
Some systems fail to go live at all because however late in the day, the company realizes that the chosen system is never going to be able to do what is needed, or in the way it is needed. Others go live but perform so badly that they are halted and the company reverts to previous ways of working; at least temporarily.
And yet others go live and fail to produce any worthwhile benefit, but reverting to the old system is, for whatever reason, not possible, and so the company limps forward with inadequate systems that have to be supported by extra-departmental level systems and cumbersome workarounds.
Problems frequently encountered after go-live include:
- missing and inaccurate data,
- inadequately trained people,
- missing functionality and reports, and
- impractical processes.
Missing and inaccurate data
Before an ERP system can go live, an enormous amount of data has to be loaded. There is always the temptation to limit workload by transferring data electronically from the old system but few companies have systems and procedures in place to ensure the integrity of their data so what can happen is that the new system starts life with the old, bad data.
Entering data manually encourages people to cull bad data beforehand but takes a lot of time and effort, and inevitably mistakes are made, so data needs to be carefully checked, both before and after it is entered. But checking data is boring and, ironically, the closer it is to 100% accuracy the more boring it becomes because fewer errors are found. Having checked 100 records and found them to be accurate, it is easy for people to believe that only random checks are needed on the remaining 10,000. They convince themselves that 99% accuracy is, anyway, good enough; and sometimes they are right.
But sometimes they are wrong, and that leads to everything from good customers being put on credit stop when they shouldn’t be, and bad customers not being put on credit stop when they should be; through to necessary materials and items not being ordered when they should be and unnecessary items being bought at premium prices to satisfy a demand that doesn’t actually exist.
Spotting bad or missing data is notoriously difficult to do, but there are ERP features and strategies that can help you with this. For example; if checking customer credit limits, run a customer report that is sorted by credit limit and exceptions will jump out. And, in manufacturing companies, run costed bills of material reports and compare the values with standard or last actual costs. But do these things before go-live and not after!
Inadequately trained staff
When companies try to cut costs or compress timelines, cutting back on the training that the ERP vendors and systems integrators recommend can seem a good idea. It’s easy to understand why: the quantity of days being cut is known, as is the daily rate, so it’s very easy to calculate the ‘saving’. The problem is that sometimes saving money costs a fortune and, when ‘savings’ are made by cutting training, there is always a price to pay. What is the cost of incompletely trained staff not being able to get accurate information from the system, ordering materials too late to keep the production line running and the shelves full, and charging customers the wrong price? And, when people can’t use the formal system properly they will use informal systems: what is the cost of that?
So a new system shouldn’t go live until the people who will be using it have demonstrated that they can use it efficiently and effectively.
Missing functionality and reports
It is common for people to think that the new system will be an “old system plus” but, even if the new system is from the previous supplier, it is almost certainly not. Over a period of time, ideas change and the system author’s development team will also have changed. And, if the new system was just “Old system plus”, there wouldn’t be a new system anyway: just Release 47 of the old system. Add to that the fact that what most people regard as being ‘the system’ generally includes a number of bespoke modifications and reports, and frequently the only similarity between old and new systems is, at best, the name on the box.
The problem is compounded when there is no proper ITT or system specification document that describes exactly what the system is required to do. In the lead-up to system selection, all manner of people will have stated, in both formal and informal meetings, what they require from the new system and, if they haven’t been told specifically that they won’t be getting what they’ve asked for, they will assume that they will be getting it. But casual conversations around the coffee machine are not formal requests: and neither are undocumented verbal requests.
In the run-up to a go-live, nothing exists unless it has been confirmed to exist. And that means that it should be explicitly described in the ITT/specification document and somebody should have checked that it exists, that it functions, and that it functions in an acceptable manner.
Impractical processes
The amount of change that individual departments, and people, have to cope with when a new ERP system is implemented varies according to what they are moving from. Towards one end of the spectrum, a payroll department that is moving from one computerized system to another will not see much difference in their daily processes but, at the other extreme, a manufacturing company moving from manual systems, such as spreadsheets, to a fully integrated solution incorporating everything from Materials Requirements Planning (MRP) to Finite Capacity Scheduling (FCS) are likely to have to completely redesign their ways of working.
The problem then is that they will be entering, for them, uncharted territory. One furniture manufacturer was excited by the possibility of having proper bills of material (as opposed to just parts lists) and the potential that gave for collecting very accurate manufacturing costs for absolutely everything they made; down to dowels. As part of their testing, they entered a few sales orders, ran MRP, and raised and processed the necessary works orders. What they didn’t do was consider how many items they had to make every week and, although they set MRP to consolidate demand at a weekly level, they were somewhat shocked when, on going live and running MRP against their full order book, it recommended raising over 4,000 works orders for the forthcoming week’s production.
So, how can companies overcome these problems?
Clearly, there is much that can go wrong when a new ERP system goes live, but none of the problems discussed here need to come as a surprise. They are all things that can and should be anticipated and things that can and should be avoided. The key lies in comprehensive and realistic testing, and the key to that is having a good test plan. It is necessary for companies, when testing the system, to realize that ‘the system’ is not just software but also the people and procedures that the software is there to support. At a very basic level; if the people don’t know how to use the software properly, if the quality of the data in the system is poor, and, remembering the furniture manufacturer, if unrealistic demands are placed on individuals and departments, then the system is not going to work.
ERP is not a computer system. It is a people system that just happens to run on computers.
Taken from: The importance of proper ERP testing (erpfocus.com)