Editor’s note: The author of this article runs a company that makes enterprise resource planning software for manufacturers. The article is critical of the traditional ERP software business and should be viewed with appropriate skepticism. However, we think it makes some cogent points about the headaches that often accompany ERP implementation and management.

Jay T. Deakins

Jay T. Deakins

If you’re in love with your ERP system, you may find this article offensive. Its purpose is to discuss why many ERP software installations have become so bloated that the software originally purchased to make the organization more efficient now hinders its ability to become or remain nimble, to be responsive and ultimately to compete more effectively.

The scary part is that this ERP bloat is routinely accepted as standard operating procedure and an unavoidable aspect of an ERP implementation. My goal is to debunk that way of thinking and offer some practical advice for vanquishing the bloat. If you’re satisfied with what you have, read no further.

ERP bloat first showed up in the early 1990s. ERP software producers were looking to increase revenues by selling larger systems, and many consulting firms were looking for more ways to generate fees around them. This combination created what I call an axis of evil, with these two groups selling bloat — highly complex systems that required large teams of consultants and IT staff — on a massive scale. The software producers had no desire to create systems that were easier to implement and maintain, nor did the consultants have an incentive to find, recommend or push for development of systems that actually made things easier.

That scenario essentially hasn’t changed. So how do we eliminate the bloat?

The first step is to agree that ERP bloat is not a foregone conclusion. Once you accept that it’s a problem that can be solved, you should no longer accept solutions that perpetuate the problem. That can be challenging if you are a non-technical person discussing the subject with a technical person. You will need the same stubbornness and resolve that probably helped you into your C-level chair. You also will need some strong arguments to overcome the bloat purveyors, like these:

1. ERP is a business function, not an IT function. Making it IT-centric is one of the most fundamental errors made in ERP selection and management. IT can and should have input, but the ERP should be evaluated and implemented to solve specific business problems. Allowing ERP to be foremost an IT project can become expensive and complex as the IT staff is ramped up to feed the beast.

2. The consultants who help you select ERP software should never help you implement it. As mentioned, they have a disincentive to find the simplest solution. Consultants can be helpful in guiding you through the selection process, but their fees for that can pale in comparison to what they charge for creating ERP bloat.

3. Ask for a fixed-price implementation bid. Some consultants and ERP producers take a page out of construction-company playbooks by submitting estimates of the hours the implementation will take. But overruns are common, and their costs are generally the customer’s sole responsibility. Without a fixed price, what is the incentive to finish the project on a timely and cost-controlled basis?

4. What is the remedy for a functionality gap in the software? There is a 100% chance that during the implementation you will encounter issues that were not considered or fully vetted during the selection process. Many of the issues addressed by ERP software are quite complex, so even if a particular issue was addressed, there will likely be nuances that the software can’t completely handle. In order to create true process control, you must completely resolve each shortcoming. Otherwise you may be forced into a customization, Excel workaround or manual process. Each of these solutions carries a cost that is likely beyond the scope of what was initially anticipated.

5. How many systems are bolted together? The magic answer to this question should be “one,” but it frequently isn’t. Bolting together multiple systems is the vendor’s way of serving lots of different industries with the same base software package. The bolt-ons attempt to address the unique needs of different industries and get synched back to the main system. ERP software does lots of different things, but in all cases there is a “fence” — a logical boundary between what the ERP software should handle and what is acceptable to be handled by separate systems. In my view, the boundary should be about process control: anything that directly impacts that is inside the fence.

Functionality that is often bolted on but should not be includes warehouse management, customer relationship management, material requirements planning and master production schedule. If your proposed solution is going to have bolt-ons in any of those areas, you should be nervous about suffering ERP bloat.

6. How will software updates impact your total cost of ownership? ERP bloat inevitably leads to software that is expensive to update and slow to adapt, yet as you know, today’s business world and customer demands are changing at an ever-increasing pace. The cost of updates needs to be small. That will prove challenging if lots of systems are bolted together, the systems are heavily customized or the software is just very complex.

So, did this article offend you? If you’ve read this far, I suspect not. Hopefully you are now better prepared for vigorous debate within your organization about ERP bloat. Remember to be skeptical of those involved in the debate who may profit from the bloat. If the 1990s ushered in the era of ERP bloat being an accepted norm, perhaps now is the time for it to be recognized as evil and start to be eliminated.

Jay T. Deakins is the founder and president of Deacom, a producer of ERP software. He previously founded a process manufacturing company and has used various ERPs. He can be reached at jdeakins@deacom.com.

, , , , , ,

3 responses to “ERP Made Easy? One View of a Better Way”

  1. I find myself agreeing with many of the authors points except the main point, the title point, that there is bloat.

    I disagree.

    There is not a lot of bloat.

    And if there were, the client simply would not buy that module. The client would not pay the implementor to implement it.

    Bloat might be defined here as needless extras, or costly needless extras, or modules that are not used. The article goes on to say that there will be functionality gaps, as well as lots of systems bolted together.

    1. If there was a functionality gap, that would imply that we wanted the ERP to do something for our business, but it couldn’t do it. It actually lacked functions and features. The opposite of bloat.

    2. Then again in the area of lots of systems bolted together. This is a tangent to the topic of functionality gap. If we didn’t have to run a separate custom database outside of the ERP, then we would not need to bolt it on to the side of the ERP. (worst case scenario, it is yet one more XLS file!) Best case scenario it is a database that can be bolted on to the ERP. That means we succeeded at integrating it. That means no silos, no typing in two places, no bad data. Integrating a system to the ERP like this is a good thing, and a valid way to go, if you must. However it is still not ideal. The ideal thing to pursue is a phased approach of migrating those bolted on systems inside of the ERP. Most ERP’s allow writing custom programs (custom modules, if you will) and once they’re inside the ERP, they are a part of it, and no longer need be bolted on.

    Our approach here is that we are trying to centralize as much in one place as possible, bringing the efficiency that the client was originally promised, but ended up never receiving. We see a lot of situations where the implementation was “boiler plate” and the implementors didn’t get to the last 15% of it, to give the client what they wanted.

    Thanks.

    Cheers.

    Jason Sjobeck
    https://www.siperp.com/

Leave a Reply

Your email address will not be published. Required fields are marked *