Why are Functionality Gaps a Problem on ERP Projects?

Executive Summary

  • Gaps in ERP functionality are a constant source of cost overruns on ERP projects.
  • We cover why this is so common and its relationship to the ERP sales process.

Introduction

Recently we were asked the why gaps are a problem on ERP projects. In this article, we will explain the normal ERP sales process and why gaps proliferate and the issue this brings up to development.

The Problem with Gaps

Gaps are a problem when they are unplanned. ERP systems are oversold to customers in a number of dimensions. One dimension is that the ERP system contains the way companies should be doing things. Which is the BPR thread? Consider, there is never any evidence provided (and none asked for) that the company should engage in BPR. It is simply proposed because it is part of conventional wisdom that processes must be changed. What they are changed to is a topic for another day. If we look at the US political process, whenever one wants to change something, they slap the label “reform” on it. The term is meaningless except to describe the change. The change will in many cases make the program worse. One would have to be a bit simple-minded to accept “BPR” or “reform” as being inherently virtuous. They simply mean a change, change can be good or bad.

Allowing Interpretations to be Set Through the Use of Terms of Propaganda

In fact, the primary reason for using such terms, we call them terms of propaganda, are so that the individual does not have to provide evidence.

As in who doesn’t want “digital transformation?”

The term reform has been used for decades to sugar coat changes to laws and to programs as a form of virtue signaling. The term hides the fact that there will be winners and losers in any change. It casts a positive light on the change, without providing details of what the change will be. The first question when one hears terms of propaganda like digital transformation, reform, reengineering, is to ask what is the specific change that is being proposed. 

Overstated Functionality Match of ERP

The second dimension is that, as with the Oracle Air Force case study — where Oracle sales told the Air Force that all of their specialized custom military systems could be emulated and thus replaced with Oracle ERP, during the sales process the match between the ERP system’s functionality is overstated. Therefore you end up with one assumption of gaps in the sales process, and a completely different number of gaps in the implementation — part of the reason for the out of control RICEF list.

Curiously, ERP vendors are not held accountable for overstating the match of the functionality of the customer’s requirements. And a primary reason for this is the pivot to the project being unwilling to perform a sufficient level of BPR — the sufficient level of BPR being determined by the software vendor and the consulting company. Two companies that benefit from as much BPR as possible. Honestly, for a vendor that has oversold their application into a customer and has to answer for large cost overruns, what else are they doing to say?

Using Open Source ERP for Customers with Lot of Development to Do

This is why we have proposed that companies with a lot of unique requirements choose an open source ERP system that they can customize inexpensively. A system like ECC and to a lesser degree other ERP systems, are expensive to customize. I can hire developers in languages outside of ABAP to get things done far more efficiently than in ABAP. If your development work is smaller, then it’s not as much of an issue, but in most cases, it is significant. Therefore, one has to keep an eye on the development ball and development productivity. 92% of SAP ERP systems are either moderately or extensively customized. And as a final point, no ERP vendor, or application vendor, should be telling the customer what to develop in. We don’t need entities with a bias taking control of other areas of IT simply because they sold the company the application.

Therefore in most cases, SAP and other ERP development is going to have a big impact on timelines and budget. There is no ERP vendor who is going to offer a set of development tools that is as efficient as what is available on the open market where one can choose from a variety of languages.

So you can end up selecting the software thinking you won’t customize much, and quickly get into a costly project — a major reason being that the cost to customize SAP is so high. If you have to use specialized applications in addition to the customization, now ECC or S/4HANA really becomes a costly and high maintenance item.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP Content

References

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.

ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.

Break the Bank for ERP?

Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.

By reading this book you will:

  • Examine the high failure rates of ERP implementations.
  • Demystify the convincing arguments ERP vendors use to sell ERP.
  • See how ERP vendors take control of client accounts with ERP.
  • Understand why single-instance ERP is not typically feasible.
  • Calculate the total cost of ownership and return on investment for your ERP implementation.
  • Understand the alternatives to ERP.

Chapters

  • Chapter 1: Introduction to ERP Software
  • Chapter 2: The History of ERP
  • Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
  • Chapter 4: The Best Practice Logic for ERP
  • Chapter 5: The Integration Benefits Logic for ERP
  • Chapter 6: Analyzing The Logic Used to Sell ERP
  • Chapter 7: The High TCO and Low ROI of ERP
  • Chapter 8: ERP and the Problem with Institutional Decision Making
  • Chapter 9: How ERP Creates Redundant Systems
  • Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
  • Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
  • Chapter 12: Conclusion

How to Understand Overmapping Functionality to ERP

Executive Summary

  • ERP vendors and consulting firms over-map functionality to ERP systems during the sale phase.
  • This means massive inefficiencies during the implementation phase.

Introduction

It is often assumed that the more applications that are not-ERP, the more the overall solution will cost. There is no evidence for this, and the cost outcome greatly depends up many factors. It is an attractive illusion that a high degree of the overall functionality required by a company can be obtained from one system. However, the evidence is that even in the largest and most complete ERP systems, such as SAP R/3/ECC/Business All in One, this is never the case.

Proposals on ERP

Consulting companies and ERP vendors that have promised customers that the ERP system would “wipe out” all legacy systems have been successful in convincing companies to buy their software using this idea, but no software vendor has been successful making this statement come true.

The Truth About ERP Systems

ERP systems are designed for companies that make things. That is the “sweet spot.” But when we say make things I don’t refer to what are called projects. So ships, planes, construction — that is large complex items that are few in number. For example, SAP has a module called Project Systems. This allows you to track projects, but it’s not ERP’s “sweet spot.” ERP vendors are very influential, so they tend to over-apply how their software applies to different industries. That is why normally it makes sense to only used a limited part of ERP, or combine a financial product with a construction-specific product.

The Fake Swiss Property S/4HANA Case Study

We analyzed with great skepticism the Swiss Property S/4HANA case study, as we covered in this article.

If we look at the Swiss Properties case study, they combined S/4HANA with a construction-specific application, which brings up the question of how much S/4HANA was actually doing. As soon as you move to really mostly using the ERP system for its financial functionality, then the cost of ERP implementations becomes difficult to justify.

Construction industry-specialized software gets little development. That is, it is a niche area.

Packaged software is based on large numbers of customers. And it takes a surprisingly large number of customers to support packaged software in any particular area, which calls into question how efficiently packaged software vendors actually are. Packaged software vendors have a long history of exaggerating how widely their applications can be applied. The actual amount of customization more often than not comes as a surprise to customers.

For example, process industry manufacturing (making cheese, milk, beer) is very underdeveloped, so customized solutions are very common. Now it is not a question of what is possible. Anything is possible as anything can be developed. But it is a question of what is, because of the focus that vendors put into different areas. The market for development is not perfect.

What Happens for Companies Looking for Solutions in Niche Areas

As always, one works back from requirements. If a prepackaged solution meets those requirements then, and if the price and estimated TCO is desirable, then, of course, go with the packaged solution.

But the workflows of ERP don’t overlap strongly with construction projects. Therefore a good portion of the ERP system won’t be used. There is no way around that. ERP systems are designed to support manufacturing companies. That is why the flexibility of the ERP system would be very important. There might be specialized vendors that add to the standard ERP packages (4PS was brought to us as one), but they are just customizing an existing ERP system, adding construction functionality to the ERP system. Maybe what they added is worth it, maybe it isn’t.

Once you get out of the “main lines” of development. That is the major markets for software. Construction management being an example, the pre-packaged offerings shrink and you end up customizing anyway.

Oracle and the US Air Force

Oracle is well known to have even made this proposal to the US Air Force. The US Air Force spent $1 billion on a project it never took live. The purchase of Oracle was primarily based on the idea that Oracle could replace all of its systems (with a particular focus on Oracle’s ERP).

The purchase of Oracle was primarily based on the idea that Oracle could replace all of its systems (with a particular focus on Oracle’s ERP).[1] For anyone who has worked for a defense contractor, the idea that the enormous number of custom designed systems that have functionality that no commercial vendor in the world has developed any software gives you an inkling of how this idea has been misused over time.

Some salespeople at Oracle, with the help of Computer Sciences Corporation (CSC), essentially convinced the Air Force that they could replace almost all of the supply chain and accounting systems maintained by the Air Force with their ERP system. One billion dollars later, the Air Force finally concluded that their project objective was not possible; further extraordinary customization would have been required, which have taken another one billion dollars to complete. Therefore the Air Force canceled ECSS. The functionality to replicate the Air Force’s existing systems did not exist in Oracle ERP; CSC and Oracle would have been required to both generalize the Air Force’s processes and rebuild an enormous quantity of custom functionality in Oracle. Oracle and CSC took one billion dollars of taxpayer money and did not deliver an operational system.

If there ever was a project doomed before it even began, it was the ECSS project. The Air Force bought the “we can cover all your requirements” argument pitched by ERP salespeople and consulting companies in the most extreme way. Think about this: Oracle ERP can cover two hundred and forty systems encompassing decades of specialized development? That is quite a proposal. But to various degrees, most other companies have fallen for the same argument. This inability to use “out of the box” ERP functionality is a theme that is often repeated, as explained in the quotation below:

“… many mid-sized companies quickly find that different business units have slightly different requirements, even for commodity processes like accounts payable and human resources. These local differences may arise from regulatory and compliance considerations, or simply a resistance to changing current working practices because of the organizational impact. Faced with inherent limitations and no viable way to overcome them, the team responsible for expanding a legacy ERP implementation is often forced to create multiple ERP instances (each with its own database), resulting in:

Dramatically increased cost, complexity and effort for corporate reporting and analytics

Added complexity to support transactions among business units

Increased hardware and IT administration cost and complexity

A natural tendency toward local optimization at the expense of overall visibility and effectiveness”—Is Your ERP Creating a Legacy of Frustration?

The Real Story on Mapping Functionality to ERP

ERP systems can and should be used wherever they meet the requirements, and not where they do not. The focus of the ISAP would be to meet the company’s requirements at the lowest possible cost – which will need to include software acquisition costs, hardware costs, implementation costs as well as maintenance costs.

The research of other entities has dovetailed with my own which indicates that roughly 65% of the cost of systems is in their long-term maintenance.[2] Long-term maintenance is where the real opportunities for lower cost lie.

The Deceptive/Secret Level of Customization on ERP Implementations

Nearly all ERP implementations have customization, with a niche item like construction management, the likelihood of customization is very high. So if I were looking for a solution, I would put flexibility of customization higher than the functionality. There is a dramatic difference in customizing efficiency depending upon the solution you choose.

The high degree of customization required to get non-open source packaged niche solutions to work properly is why we are a proponent of open source ERP for niche solutions. Look at ERPNext. The software is open source, and they have easily addressable APIs.

https://erpnext.org/docs/current/api

It is developed in Python, a very good language for math. They have project functionality already.

https://erpnext.org/docs/user/manual/en/projects

With something like this, which is free to use, now you can start with a lot of functionality, and at a low cost add what you want because you can use a Python developer. If you want to customize 50% of it, you can do that. If you want to add a packaged construction management application to cover a specific area, you can do that. And it is already cloud. One can go and get an open source ERP system that we have rated quite highly, and simply begin using it. Build a prototype based on your requirements.

Conclusion

When it comes to lowering maintenance costs, most US companies focus on lower quality ways of cost reduction like outsourcing support. However, the much larger opportunity for lower maintenance costs is through better software selection. One of the dimensions of software selection is choosing more maintainable software. Another dimension is maximizing the fit between requirements and the software selected. Another is selecting software that users naturally want to use – reducing training, support questions, and other general support.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

ERP Contact Form

  • Interested in Our ERP Research?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP decision support.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch

Search Our Other ERP Content

References

[1] https://www.nytimes.com/2012/12/09/technology/air-force-stumbles-over-software-modernization-project.html?pagewanted=all

[2] This is the only book ever written that covers Total Cost of Ownership as applied to enterprise software.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.

ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.

Break the Bank for ERP?

Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.

By reading this book you will:

  • Examine the high failure rates of ERP implementations.
  • Demystify the convincing arguments ERP vendors use to sell ERP.
  • See how ERP vendors take control of client accounts with ERP.
  • Understand why single-instance ERP is not typically feasible.
  • Calculate the total cost of ownership and return on investment for your ERP implementation.
  • Understand the alternatives to ERP.

Chapters

  • Chapter 1: Introduction to ERP Software
  • Chapter 2: The History of ERP
  • Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
  • Chapter 4: The Best Practice Logic for ERP
  • Chapter 5: The Integration Benefits Logic for ERP
  • Chapter 6: Analyzing The Logic Used to Sell ERP
  • Chapter 7: The High TCO and Low ROI of ERP
  • Chapter 8: ERP and the Problem with Institutional Decision Making
  • Chapter 9: How ERP Creates Redundant Systems
  • Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
  • Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
  • Chapter 12: Conclusion