How to Understand Overmapping Functionality to ERP

What This Article Covers

  • Proposals on ERP
  • Oracle and the US Air Force
  • The Real Story on Mapping Functionality to ERP


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 efficient 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 lanes” of development. That is 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 for 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 fi nally 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 cancelled 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.

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

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.


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.

ERP Contact Form

  • Want Honest Information about ERP?

    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 support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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.


  • 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


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