Solving the Four Problems with ERP

I received quite a bit of feedback on the recent commentary I wrote entitled The Four Problems with ERP. Most of the responses were quite positive, but some did suggest that I missed some problems, such as, “quality of the systems integrator,” “turnover of user personnel,” and “lack of user ownership.” However, my feeling is that these all may be legitimate causes of ERP problems, but they are not separate categories or types of the problems themselves.

There’s nothing wrong with looking for causes. Good problem solving techniques from six sigma to the theory of constraints teach us to fix the root causes, not just treat the symptoms. But if we don’t understand the nature of the problem itself, how on earth will we ever find the cause? Too many managers immediately want to jump to solutions, without really understanding the nature of the problem.

So, I believe that my list of four types of ERP problems is an exhaustive list of the nature of all ERP problems. You could have dozens of possible causes, but the problems themselves only fall into these four types:

1. The system itself is bad
2. The system is good, but it’s set up incorrectly
3. The system is good, but it’s not being used
4. The system is good, but it’s being used ineffectively

Now, having said that, one reader did suggest that it would be best not to just categorize the problems but indicate how to solve them. Fair enough. Once you understand the nature of the problem or problems with an ERP system, how should you go about finding solutions? Of course, each company will have different problems, different causes, and different solutions. But there are some common approaches that you can take:

1. If you’ve got a bad system…
   You need to ask, can the system be fixed (e.g. is there a newer version, a vendor patch, or a modification you can make?). Can you work around it (i.e. can you use a procedural method to bypass the system problem)? Can you use some other piece of software instead of the part of the system that is bad? Or, should you replace the system?

   But too many executives ask that last question before asking any of the others. Just because a system is bad doesn’t mean it needs to be replaced. It depends on how bad it is, and whether the bad parts are fundamental or superficial.

   For example, a system might have an unfriendly order entry screen. Perhaps the order entry screen could be modified to remove unneeded data elements, or it could be reconfigured to be more natural to the way your company takes orders. If the rest of the system is good, it would be foolish to replace the entire system just because of an isolated user interface problem.

   On the other hand, if a company operates on an actual cost basis, and the system only supports standard costing, it is unlikely that the system could be fixed, or a work around would be viable. Or, if a process manufacturer finds itself stuck with an ERP system that is designed for discrete manufacturing, it might be advisable to bite the bullet and get a system that works for the process industry.

2. If the system is set up incorrectly…
   I find it most helpful to find out why the system was set up in the way it is. That will lead you to the possible root cause. Was it just ignorance of the original implementation team? That would point to a need for training on the system. Was it because the company was trying to make the new system look like the old? That would point to a need for business process redesign, or at least to address assumptions about how the business should operate.

   Recently I saw a company that was having a hard time keeping up with inventory transaction volumes. We found that the problem was that the system had been set up to serialize each unit of finished production. The company thought that this was necessary to provide full traceability of products for FDA regulatory compliance. Of course, it also exploded the number of transactions that would need to be entered every time a finished product was transacted. When we investigated, we found that the system was fully capable of providing traceability by means of lot or batch numbering, which would greatly improve productivity while maintaining compliance. We then asked why the system had been configured for serial unit control, and we found that it was because that was how the previous system had done it. When management understood the weak basis for the original decision, it was a simple matter for everyone to agree to change it.

3. If the system is not being used…
   Again, you have to ask why. Is it because parts of the old system are still in use, in parallel with the new system? A client once brought me in to determine whether their new system was in fact the right system for them. Users had many perceptions about the inadequacy of the new system, most of which I suspected were incorrect. Soon I found the reason. The old system was still running for many functions that the new system could have performed. As long as management was not committed to abandon use of the old system, which users had grown accustomed to, there was no hope that they would learn to use and appreciate the new system.

   There can be any number of reasons that a perfectly good system is not being used. It could be a lack of training, or a lack of resources to do the implementation, or resistance to change. I have seen cases where certain users prefer their little Access systems, Excel worksheets, or cumbersome manual systems. Why? Because those little informal systems represent job security. As long as the company depends on those users for their personal knowledge of “how things get done around here,” those users are unlikely to embrace an ERP system that promises to formalize and make transparent the business process.

4. If the system is being used ineffectively…
   You need to do more analysis. In this category, I like to group problems into four sub-categories.
• Data problems. For example, inventory inaccuracy can make MRP systems all but useless. There are dozens of other examples of how data problems can undermine ERP systems and force users to work around the system. Many companies I visit have problems with duplicate part numbers, duplicate vendor numbers, and inaccurate costing data. All of these make ERP ineffective.
• Discipline problems. Invariably, organizations making ineffective use of their ERP systems have poor or nonexistent disciplines in engineering change management, inventory control, and planning. Procedures may not exist, or if they do exist they are not followed. I once saw a company where users were complaining that the planning system didn’t work. Later I found out that the VP of Sales routinely called the plant and forced them to change the day’s production schedule when an important customer had a rush order. The planning system was being used, yes. But it was being used ineffectively because of poor disciplines in planning and scheduling.
• Integration problems. Enterprise systems by definition are integrated systems. But the organizations that implement them may not be integrated. Rather, there may be a strong functional orientation that creates isolated “silos” with walls between departments. ERP systems work best when they automate cross-functional processes. But if sales does not talk to production, and production does not talk to engineering, it is unlikely that the ERP system will be used effectively.
• Measurement problems. Too often companies ask managers to do one thing but measure them on something else. If you ask a factory to ship product according to customer delivery dates, but you measure the plant on “tons produced” each month, it is likely that the plant will maximize tonnage by shipping the largest orders first, instead of the ones with the earliest due dates. Yet, it is easier for management to blame the system instead of their own out-dated measurement systems. There are dozens of similar examples.

Making effective use of ERP generally mean solving problems with business processes and organizational design. This can take you far outside of the IT department and deep into change management in user functions. Although such change can be difficult, the pay off can be huge.

Over the past 15 years, many companies have made enormous investments in enterprise systems. Yet many are unhappy with the results. The temptation is to blame the system and even entertain the thought of replacing it. But, as we have seen, good systems can be saved, as long as management is willing to face the nature of the problems.

June 2004