The Myth of ERP Systems as Out of the Box: Why Functionality Gaps are a Common 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 why gaps are a problem with ERP projects and about gap analysis in ERP. This article will explain the normal ERP sales process and why gaps proliferate, and the issue this brings up to development.
See our references for this article and related articles at this link.
The 90% Out of the Box Myth of ERP Vendors and Consulting Firms
Even though ERP systems have been implemented for decades and vendors like SAP know that 92% of the ERP systems will be moderately or heavily customized, SAP sales continue to propose to prospects that 90% of their functionality will be addressed “out of the box” SAP ERP. This is one of the significant reasons ERP systems were able to become so prevalent. In this way, virtually all ERP systems are sold under a false set of pretenses. In each case, they have to escalate in time and budget because the customization percentage is perpetually underestimated. There was never any effort (by consulting firms and Gartner/Forrester) to illuminate this fact to customers. If someone can make me aware of some entity that did this, I will read it, but there is a peculiar silence on this topic.
The Problem with Gaps in Analysis ERP
Gaps are a problem when they are unplanned. ERP systems are oversold to customers in several dimensions.
Gap Analysis in ERP: The Overmapping 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 on 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 successfully convinced companies to buy their software using this idea. Still, no software vendor has been successful in 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 to 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 only to combine a financial product with a construction-specific product.
The Fake Swiss Property S/4HANA Case Study
We analyzed with considerable 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 raises the question of how much S/4HANA was doing. As soon as you move to mostly using the ERP system for its financial functionality, then the cost of ERP implementation becomes difficult to justify. Any gap analysis in ERP performed by Swiss Property would have come to this determination. Certainly, SAP would have fought back against any gap analysis in ERP performed by an independent entity.
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 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 widespread. 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 development market is not perfect.
Gap Analysis in ERP: 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 essential. There might be specialized vendors that add to the standard ERP packages (4PS was brought to us as one). Still, they are just customizing an existing ERP system, adding construction functionality to the ERP system. Maybe what they added is worth it; perhaps it isn’t.
Once you get out of the “main lines” of development, that is the major market for software. Construction management is an example. The prepackaged 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 it 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). 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.
With the help of Computer Sciences Corporation (CSC), some salespeople at Oracle mostly 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. Naturally, no gap analysis in ERP was performed, or the gaps would have been obvious very quickly.
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, and maintenance fees.
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.
How ERP Creates Redundant Systems
ERP systems include fundamental functionality for supply chain planning and management, sales, reporting, etc. Because this functionality is basic, many companies purchase and connect external systems to the ERP system.
Let’s look at the supply chain planning system as an example. In almost all cases, during implementation, the planning system is not integrated into the ERP system’s financial module. Instead, it is connected to the ERP system’s supply chain modules. In SAP ERP, the supply chain modules include all three nonfinancial modules: materials management, production planning, and sales and distribution.
These modules then communicate with the financial and accounting module through the standard ERP workflow. This sets up situations where multiple systems are now used: both the ERP system supply chain modules and the supply chain planning system, leading to complex decisions as to what to perform where. These are some of the questions that I help companies with on implementation projects.
Ordinarily, the external planning system could convert the purchase requisitions created to purchase orders and then send them to a financial system for reconciliation. In fact, by making the inventory management, planners, and procurement individuals use the ERP system, they are less efficient than using the external planning system specially designed for the supply chain management. This same problem exists regardless of which type of external application is added—CRM, reporting, etc. The issue becomes, use the ERP system or use the external application.
When an ERP system is implemented, purchase requisitions must now be sent to the inventory management module in the ERP system. At this point, duplicate supply chain documents are created, and these documents must be kept in sync between the two supply chain systems. If there were no ERP systems and the company had another supply chain application purchased previously, the existing supply chain application would be decommissioned. And the new supply chain application would be connected directly to the financial and accounting system. Therefore, the ERP system has just made the implementation more expensive and more complicated.
The Justification for Using ERP Functionality
Some of the justifications for continuing to perform planning in the ERP system have been more about maintaining the relevancy of the ERP system rather than any real benefit to the company. In this way, ERP has arrested the implementation of more sophisticated and better systems. It’s almost as if companies are continually attempting to justify the investments they have made in their ERP implementations. And of course, when the same vendor that sold them the ERP system is now selling them the bolt on the system, the vendor has the same predisposition: to help convince their customer that their ERP investment was a good one.
Finally, while the traditional approach is to convert planning recommendations (planned production orders, planning purchase orders, planned stock transfers) in the ERP system, it’s very easy for planning systems to convert planning recommendations into execution objects (production orders, purchase orders, etc. stock transfer). These execution objects could be integrated more quickly into a financial application, cutting out the redundancy of the ERP system. Unlike ERP systems (at least, on-premises systems), integrating these execution objects would be a simple matter if the financial application was published to an integration standard.
ERP Versus Custom Development for Core Functions
The research paper ERP for SMEs – is proprietary software. An alternative provides interesting quotations and perspectives on the concept of using an ERP system versus custom-developed solutions.
“Many managers have excluded the possibility of developing their own software, based on experience with time consuming and expensive projects in the past. Thus, implementing standard ERP systems is often viewed as the only solution. However, these systems may impose a rigid structure on a company. threatening the dynamic nature of many SMEs. We show that many companies have a better alternative.”
The Effect of Consulting Companies on the Presentation of “Standard” ERP
It is generally lauded by consulting companies that have the most to gain from proposing that ERP systems save companies money and make them better and more standard. However, a consulting company will never acknowledge that this reduces the company’s flexibility after implementing an ERP system.
The Deceptive/Secret Level of Customization on ERP Implementations
Nearly all ERP implementations have customization. With a niche item like construction management, 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.
Proprietary ERP and High Expense
When a company buys SAP, they also end up with a high-cost ABAP customization environment. They did not have to accept SAP’s recommendation to use ABAP, but almost all of them have. This served as a “double whammy” for the customer. First, they accepted the false assumption that they would only have to perform limited customization. Then when they found out that they would have to customize highly, they were stuck with the ABAP coding and SAP customization environment, which dramatically added to the cost of ERP projects. SAP and other ERP systems have turned out to be high-cost closed systems that give the vendors increasing levels of control over the IT budgets of these customers. While SAP is the most difficult broadly sold ERP system to customize, ERP systems have tended to be developed as monoliths and have been expensive to customize.
Customers that relied upon consulting companies found that the consulting companies were “in on it” and merely repeated whatever the vendors said. This entire system of the undisclosed history of ERP has only helped the bottom lines of consulting companies.
How ERP Vendors Push Mediocre Non-ERP Applications into their Customers
If we think of applications outside of ERP, ERP vendors have acquired many non-ERP applications and use the integration argument and the exposure to the decision-makers to get their clients to purchase more of their software. Secondly, most applications from ERP vendors that are outside of the ERP system usually are not competitive with applications from vendors that specialize in those areas. Suppose we put the issue of how acquisitions tend to stagnate post-acquisition, often losing developers and focus. The question of why a non-ERP vendor that a non-ERP vendor acquired is likely to be the best application for a particular company is an obvious area that should be questioned.
So, in addition to the statement above, the strategy of connecting up the most competitive non-ERP applications and replacing much of the functionality in the ERP system is, in fact, very sound.
“While the implementation of standard ERP system is an implicit acknowledgment of the fact that one does not want to compete on IT, development of proprietary software implies that one want to increase competitiveness by the use of IT.”
This issue is not broached. There is no concept of this, of competing based on custom-developed IT solutions.
Using Open Source ERP for Customers with Lot of Development to Do
This is why we have proposed that companies with many 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 tell 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.
Conclusion
We perform a full evaluation of the business requirements and a correlation to the ERP functionality leading to a gap analysis in ERP. ERP vendors do not want a gap analysis in ERP performed as it exposes the far lower match to the customer’s requirements than are described during their sales process. None of the IT consulting companies will provide a gap analysis in ERP, and they are trying to direct their clients to use the software that will maximize their profits. See the section below to find out more about how we do this and our independence from ERP vendors.