Revisiting the Four Problems with ERP

In 2004, I published two of my most popular posts—on the four problems with ERP. Now, over 20 years later, I’m updating my analysis, including how to solve those problems.

Back in 2004, I published what turned out to be one of the most popular posts on this site: The Four Problems with ERP, along with a follow up post, Solving the Four Problems with ERP.

The technology has changed tremendously over the last 20+ years—for example, cloud ERP was barely yet a thing. Still, I find these four problems remain at the root of organizational dissatisfaction with ERP. The reason is that most problems are not with the technology but rather with how organizations implement it, use it, and manage it.

So the lessons learned from two decades ago still apply [1].

Four Problems with ERP

My understanding of what goes wrong with ERP was crystalized in one client project in 2004. A process manufacturer in the life sciences industry asked my firm, Strativa, to do an evaluation of its ERP system. Users had become increasingly unhappy, and management wanted an independent assessment to determine whether they had chosen the wrong system and should replace it.

Interestingly, four years earlier, working for the SI Firm, we had actually been the ERP selection consultants for this company. However, we only helped them get to the final short list of two vendors. To save money, the client decided to do the demonstrations and the final selection and negotiation without our help.

Four years later, now as Strativa, we were being asked to do an assessment of what went wrong and what they should do about it.

After a couple of weeks of interviewing users and gathering their many complaints about the system, we sat down to do a problem analysis.

Our standard practice for problem analysis was to list each problem mentioned in the interviews and look for evidence that the problem is real. For example, a user might complain that the system is not “user-friendly,” without any evidence or specific examples. That is a generalization that, by itself, is not useful. But if someone can come up with a specific example—such as the system help text is only in German—we can list that as a problem, once we have verified that is a true statement [2].

This approach ensures that the problem analysis is iron-clad and difficult to argue with. For this client, we ended up with dozens of problems in 15 major problem areas, grouped into four categories: Sales and Distribution, Operations and Finance, Quality and Compliance, and Information Systems.

Next—the fun part—is to assign each of the major problem areas into one of four types, as shown in Figure 1 below:

Now, as we will see, these problem types are not mutually exclusive. In fact, most problems can fall into multiple types.

1. ERP System Problem—You've got a bad system
   This does not necessarily mean the system is intrinsically bad, although that can happen. Usually, it means that it’s not right for your organization. There may be gaps in critical functionality, system performance problems, lack of scalability, system bugs, and ERP process flows that don't match your business processes. In other words, there are problems with the system itself that cannot be easily resolved through configuration. These problems are usually easy to spot. Yet, even if these problems are serious, they do not always mean you'll need to replace the system. Sometimes a software or hardware upgrade will do the trick, or a customization may be possible. More on this later.

2. Setup Problem—You've got a good system, but you set it up incorrectly
   This category includes incorrect configuration settings and other problems with how the implementation was performed. For example, users might be complaining that product costs are not accurate, but the company has not set up the system with cost elements that are detailed enough. Or, users might be complaining that inventory counts are inaccurate, but the system has been set up with one big "four wall" inventory bucket, instead of bin location level tracking.

3. Implementation Incomplete—You've got a good system, but you aren't using it
   Examples could be that the original implementation was incomplete, or that the implementation was broken into phases and the company never got beyond Phase I. Other times, the problem is ignorance. It's surprising how often companies don't know what features they have in the software they already own. I have seen companies buy additional point solutions, or modify their systems, all the while their original system could have provided the same functionality, if they had just known it was there.

4. Business Practice Problem—You've got a good system, but you're using it ineffectively
   In this category, I lump together all kinds of problems with business practices, such as data inaccuracy, lack of user procedures, lack of training, lack of discipline, and organizational problems. The system never has a chance to perform well, because the business is not using it effectively.

Back to our client. When we looked at this company's problems, we found that out of 15 major problem areas, the breakdown by type of problem was as follows. (As noted, most problems covered multiple types, so the total adds up to more than 100%):

1. Bad system: 27%

2. Set up problems: 33%

3. Non-use of the system: 73%

4. Ineffective use: 40%

As can be seen, for this company, only 27% of the problems were with the ERP system itself. Most of the problems were simply that the company was not using the system. For example, users had come to the belief that the system was mainly an accounting system, that it had been selected by the accountants, and that it was not a good manufacturing system. However, a quick look indicated that most of the manufacturing functionality had not been implemented! Ironically, the system had been originally selected because of its strength in process manufacturing, not because of its accounting functionality. In fact, as an accounting system I would rate this ERP package as just average.

How did the company get into this position? In this case, it was because shortly after the system was selected the company entered a period of severe financial difficulty, causing them to short-cut the implementation. Many system features were simply never implemented. Now, several years later, as the company was stronger and growing, new employees were surprised to see how poorly the system supported the business. So, their first inclination was to say that "the system stinks" (or, using more colorful language). But as we just saw, the main problem was that the original implementation was cut short.

As a result of our assessment, the company launched a series of projects to finish the implementation and get the benefits from the existing system. We stayed on to help with some of that. This approach saved the company much time and money and got improvements more quickly than if they had waited until they could implement a new system.

ERP systems are an easy target for blame. Executives would do well not to let users take the easy excuse that "the system" is the problem but to look at all the factors that are required to make ERP effective.

Are There Not Other Problems?

On the original post, some readers gave me feedback that there are other types of problems, such as, "quality of the systems integrator," “lack of top management commitment, “lack of user ownership,” or "turnover of user personnel."

Those can certainly be problems, of course. But for deciding whether to replace an ERP system or deciding what needs to be done to improve it, these four types are sufficient.

The other reader-suggested categories are really not types of problems but causes of the problems. That is useful, if you want to place blame, say, in a lawsuit, or a performance review. But our goal in an assessment is not to point fingers. It is to recommend actions to fix the problems.

In fact, as shown in Figure 2, there are really only two types of problems: (1) The ERP system is bad, and (2) everything else. Nevertheless, I like to break down “Everything Else” into three types, because that’s more useful in communicating possible solutions.

There's nothing wrong with looking for causes. Good problem-solving techniques from six sigma to the theory of constraints teach us to fix root causes, not just treat the symptoms. But if we don't understand the nature of the problem itself, how will we ever find the cause?

So, I believe that my list of four types of ERP problems is adequate to categorize the all types of ERP problems. There could be many possible causes, but the problems themselves generally fall into these four types.

Now, once you understand the nature of the problems with an ERP system, how should you go about finding solutions? While each company will be different, but there are some common approaches:

If You’ve Got a Bad System

For these problems, 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 a point solution or complementary software product to solve the problem? Can you do a small modification? Or does the entire system need to be replaced?

But too many executives ask that last question before asking any of the others. Just because the 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 a problem with one user interface.

On the other hand, some problems are so fundamental, there can be no choice but to replace the system. For example, 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 is running an ERP system that is designed for discrete manufacturing, it might be advisable to bite the bullet and get a system built for the process industry.

If the System Is Set Up Incorrectly

Here I find it most helpful to find out why the system was set up 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 the 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.

For example, one of the problems that we encountered with this client was that it 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, that exploded the number of transactions needed—one per finished unit. When we investigated, we found that the system was fully capable of providing traceability by means of lot numbering, which would greatly improve productivity while maintaining compliance. We then asked why the system had been configured for serial unit control. The answer? 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 to get agreement to change it.

If the System Is Not Being Used

Where the system provides needed functionality, but the client is simply not using the system, again, you have to ask why. Is it because parts of the old system are still in use, in parallel with the new system?

Years earlier, a client once hired us 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 the new system.

There can be any number of reasons why 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 database, Excel worksheets, or cumbersome manual systems. Why? Because those 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. Ultimately, it is an organizational change management issue.

If the System Is Being Used Ineffectively

For this type of problem, more analysis is needed. Here I like to group problems into four sub-categories.

• Data problems. There are many examples of how data problems can undermine ERP systems and force users to work around the system. I’ve seen many companies with inventory inaccuracy, 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 demanded that the plant 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 discipline on the part of top management.

• Integration problems. Enterprise systems 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 the sales group 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 tell a factory to ship product according to customer delivery dates, but you measure the plant on units shipped each month, it is likely that the plant will achieve their incentive goal 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 misaligned measurement systems.

ERP Problem Resolution Often Means a Phased Solution

Because most companies have all four types of problems with their ERP systems, the future roadmap often means a hybrid solution, where you may need to replace the current system long term, but in the meantime there are critical improvements you will need to make to the current system. This will give you more immediate payback and buy you time to select and implement the new system.

In fact, this is exactly what happened with our client. Due to changes in the business, including their being acquired, they knew they were going to have to replace their current system. And almost certainly that meant implementing the new parent company’s system (even though our analysis showed that their current system had certain advantage over the parent company system. Nevertheless, they could make short-term changes to the existing system to resolve some immediate problems and deliver tangible benefits to the business.

Over the past decades, many companies have made enormous investments in enterprise systems. Yet many are unhappy with the results. The temptation is to blame the system and plan on 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.

End Notes

[1] Even though this post deals specifically with ERP problems, the advice also applies to all types of large enterprise systems, such as CRM and HCM.

[2] Too often, consultants simply take a user’s word at face value. It’s not that users lie. It’s that they generalize. So, when users make a general statement, such as “the system is not user friendly,” I like to follow up with, “Can you give me an example?” The user may then respond, “It takes me eight screens to enter one purchase order. Here, let me show you.” That makes for a much more useful and actionable problem statement than simply that the system is not user friendly.

Like this post? Browse my past posts.