- 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.
Recently we were asked why gaps are a problem with 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 90% Out of the Box Myth
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, but also by 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
Gaps are a problem when they are unplanned. ERP systems are oversold to customers in a number of dimensions.
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 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. 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 brings up 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.
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 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, 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).
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.
Some salespeople at Oracle, with the help of Computer Sciences Corporation (CSC), 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. 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 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. 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 of the 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 that it creates 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 if they used the external planning system, which is specially designed for 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 that it had 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.
How ERP Distracts From and Undermines Planning Functionality
ERP sets up mediocre functionality at companies and interferes with buying better software that could provide a great deal of value to the business. I will use several examples in this chapter to explain this characteristic feature of ERP software. ERP implementations result in generic functionality being installed. Then, after the ERP system is installed, other applications that provide better functionality are frequently and selectively used to replace ERP. These superior applications must often coexist with portions of the ERP functionality that are still active.
The Problem with ERP and Supply Chain Planning
ERP systems were developed with a sharp delineation between supply chain partners and customers. Since then, that delineation has blurred significantly. While ERP systems have been updated since they were first introduced, updating an old design in an attempt to meet requirements it was never designed to achieve is quite a bit different than if the software was designed from the beginning to work a particular way. Subcontracting, contract manufacturing, direct sales through the Internet, modeling supplier capacity, supplier collaboration—all of these features blur the line as to what is inside or outside of the company. Let me provide an example.
In ERP systems, suppliers are external locations, and resources cannot, at least with most ERP systems, be created or exist in supplier locations. Under the ERP design, suppliers are simply for accepting purchase orders. But what if a company wants to model supplier capacity? That is, what if the company intends to perform capacity constraining to treat the external location partially as an internal location? Some planning systems can do this, but the ERP system cannot, meaning that there is any inconsistency between the ERP system and the planning system that requires work to overcome. Let us look at another example.
Some time ago, I received two packages from my favorite running store, RoadRunnerSports.com. I noticed that both packages were not from Road Runner Sports’ distribution center, but separate, one from each manufacturer. I needed to send both packages back but did not know where to send them: to Road Runner Sports or to the manufacturer’s distribution center addresses, which were listed on the boxes. When I called, they told me that all returns come to them. I asked if this was a change in policy—did they no longer fulfill their orders? They told me that they used drop shipping for some items but not others, which allows them to provide a broader selection on their website. They stock high volume items at their DC. This is consistent with Amazon’s approach, which is to fulfill some, but not all of the orders from their website (Amazon has grown into a marketplace where other online retailers also offer products).
What Changed and Who Must Know What
The old model for order fulfillment is from a time when most orders were fulfilled at a physical store. However, with orders taking place on the Internet, it is not particularly relevant who fulfills the order, as long as it gets done. Amazon was one of the first web retailers to pick up on this fact, and now it is a significant part of their business. Other online retailers are copying Amazon’s approach. A variety of system adjustments are required to pull this off. The less your systems are designed to do this model of order fulfillment. The more custom work is needed.
This product is sold on Amazon’s website, but the options below are fulfilled by someone else. Under this model, the sales order goes from Amazon to the fulfillment company, and the product goes from the fulfillment company to the customer. Payment goes to Amazon, which then pays some of this money to the fulfillment company. This is one example of how traditional roles are changing.
Road Runner Sports must know the inventory position at their fulfillment company so that they know what they can commit to the customer and what is available to ship. Also, notice that the return does not go back to the fulfillment company, but goes to Road Runner Sports, which sends bulk returns to the fulfillment company. Increasingly, what is inside and outside the company is blurred, yet in the ERP model, inventory is shown for internal locations only. The problem is that ERP’s model won’t work for this business requirement. Examples of the blurring distinction between what is inside and outside of a company are covered in detail in the book, Superplant: Creating a Nimble Manufacturing Enterprise with Adaptive Planning Software, which includes multi-plant planning, multi-sourcing and subcontracting. Superplant is the more accurate modeling of location interdependencies for production and supply planning that is provided by standard advanced planning functionality. Superplant alters the assumptions along which a planning system makes decisions. It can see relationships that software lacking these functionalities cannot access. Superplant allows for manufacturing processes to be planned and integrated across plants. Sources of supply are automatically and dynamically selected based upon changing circumstances, and the integrated planning of external partner plants are treated as if they were internal plants.
These functionalities are logically grouped under Superplant as they all relate to improving the scope of planning concerning how locations are treated when solving a combined supply and production problem. Superplant is characterized by an expansive and integrated view of planned locations, the ability to nimbly react to changes in things such as capacities, and to redirect to other sources of supply. Superplant is not a management technique. It is a specific set of software capabilities that must be configured, tested, and accounted for in a range of areas, from user training to integration to ERP systems. For example, with some special multi-plant planning software, companies can leverage more of their manufacturing resources as part of the natural output of the planning system (that is without any manual intervention).
ERP Repeatedly Getting in the Way
In case after case, ERP systems, because of their introverted nature and dated designs, put up substantial barriers to the flexibility when locations in a supply network are pseudo internal. Most vendors that sell add-on software don’t spend much time or energy criticizing how ERP systems slow the implementation of their applications, but their deployments are slowed. This is because all systems must be made to integrate back to a system that sees sharp delineations between “inside” the company and “outside” the company. The very integration between the supply chain modules and the financial modules of ERP systems has made companies that much less adaptable.
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, convert planning recommendations into execution objects (production orders, purchase orders, stock transfer). These execution objects could be integrated more quickly to a financial application, cutting out the redundancy of the ERP system. Unlike ERP systems (at least, on-premises systems), the integration of these execution objects would be a simple matter if the financial application 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 perspective 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 this idea that ERP systems save companies money and make them better and more standard. However, a consulting company will never acknowledge that this reduces the flexibility of the company after implementing an ERP system.
The Effect of IT Analysts on the Presentation of “Standard” ERP
Gartner or Forrester never addresses the issue of using custom-developed applications. But of course, Gartner and Forrester receive many millions from packaged software vendors. Therefore, they have a strong bias not to promote anything but packaged applications.
Another quite good quote that is related to this is found in the paper Prioritization Best Practices in a Ratified Consulting Services Maturity Model for ERP Consulting.
“The successful implementation of the ERP system can provide organizations with many benefits including increased accuracy of information, quicker response to customers’ needs, reduced order and delivery times, and elimination of unnecessary or redundant. These benefits are achieved through its data structuring capability. However, there are several drawbacks of the ERP system including vast storage and networking requirements, huge scale of business process re-engineering and customization, which all result in difficulty of implementation and large financial time and human resource costs. These costs can impact very heavily on an organization so typically specialists consultants assist companies with the complex implememntation. It is not just the cost problem that has been a major drawback of ERP. ERP implementations may also be prone to failure particularly during the implementation stage. As Beheshti has noted “the failure rates for ERP projects are relatively high and could lead to bankruptcy of the corporation” and he provides some examples of abandonment including Dell Computers and Allied Waste and also of consequential bankruptcies and law suits.”
Again, this is found in the academic literature, but far less in the industry literature.
Now let us return to the original research paper.
“These encompassing systems will reduce the idiosyncrasies of the company from the transaction processing part, all the way up to company management and customer relations. While this may be an advantage for some companies, it may be disastrous for companies that thrive on their ability to conform to customer demands, to be flexible and dynamic.”
Once again, this is never really brought up. The overall impression given is that all companies benefit from ERP rigidity, forcing companies into a “standard process.”
“An in-house development effort offers full freedom. All processes are candidates for reengineering, and all options are available for implementation. In opposition, an ERP implementation is often viewed as a mapping from the existing system to the new ERP system. The idea is to find a common denominator between the company and the business model embedded in the ERP system. Success is determined when the system work, seldom of how well it services the company.
In house, development should be limited to core functions. It is not necessary to develop a full body ERP system. Instead, a custom designed system should be put together out of several different systems, where only the core part is developed in house.”
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 correctly 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 addressed APIs.
It is developed in Python, a perfect 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’re going 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 begun using it. Build a prototype based on your requirements.
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. If 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 was acquired by a non-ERP vendor 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 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 are going to have a significant impact on timelines and budgets. No ERP vendor is going to offer a set of development tools that are 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 becomes a costly and high maintenance item.
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.
Search Our Other SAP Custom Code Content
The Real Story on ERP
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