How ERP Distracts From and Undermines Intercompany Transfer

Executive Summary

  • Because ERP offers mediocre functionality, it distracts from better functionality outside of ERP.
  • Learn why this leads to so much waste on ERP projects.

Introduction

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 prevalent 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 Intercompany Transfer

An intercompany transfer is when a company buys a product from “itself.” While companies make a big deal about being global (and many certainly operate globally), when it comes to financing, a company must be incorporated in every country in which it works, and must report to the tax authorities based upon its activities within a country. Thus, when a product (or service—but as this is planning we concern ourselves with products) is sent/sold between two different companies. Say an automotive component from Toyota Japan to Toyota U.S.—an accounting transaction must be generated to record that the product has been transferred. This transaction, which is dated and has a transfer price, moves the product from Toyota Japan’s “books” to Toyota U.S.’s “books.” If you search for the term “intercompany transfer” in Google or on Amazon, you will find that most publications on the topic of intercompany transfer are on the subject of intercompany transfer pricing.

While accounting transactions are not particularly “relevant” for supply chain movements, they do have to be accounted for so that the supply network design can support the type of activities required on the accounting side. Supply chain planning systems and ERP systems generally have a standard workflow for dealing with intercompany movements, and this will work for simple intercompany transfers. However, as soon as the intercompany transfer becomes even slightly more complicated, ERP systems most often require expensive customization. Furthermore, because of the rigid design of ERP systems, this customization will consume many analytical and development hours.

Intercompany Transfer Alternatives

There are two basic ways of handling intercompany transfers: a billing stock transfer order and a standard stock transfer order. A standard stock transfer order (STO) is used between locations that are part of one company code. With a standard STO, no billing document is necessary because the STO is an internal movement. A billing STO combines the document used for internal company movements with the invoicing aspect of a purchase order. This is shown in the following graphic.

A standard stock transfer, transfers goods between two internal locations without any billing.

A billing STO performs the same movement and then performs the intercompany transfer in the ERP system. This is shown in the graphic below:

Intercompany transfer is covered by standard ERP system functionality. It combines an internal movement with billing, hence the “billing-STO.” Billing STOs work for straightforward intercompany transfers. The billing STO is the most straightforward way of transitioning ownership between two companies within one global company. However, it does not even come close to meeting all of the requirements of an intercompany transfer. For instance, some companies have multiple locations that interact with one another during an intercompany movement; while the billing relationship is between two locations, the goods are moving between different locations. Entities other than the receiving location can be involved in invoicing the sending location.

There can be four or five locations (or possibly more, although I have never seen more than five location interactions). The standard billing STO will not meet the requirement because the billing is not applied to the location that is sending the product. This is a complexity that is missed by those who propose the non-billing STO for every intercompany transfer situation. (I know as I used to be one of those who proposed the non-billing STO for a company that had a more complex need than I first understood.)

Matching Purchase Order/Sales Order for Asymmetrical Intercompany Transfers

To understand this nonstandard approach to intercompany transfer, we will begin by reviewing the standard purchasing goods transfer.

Standard purchasing transfers goods from an external location to an internal location with billing. However, intercompany transfer combines features of both the internal stock transfers and purchasing.

When the interaction between the locations is complex, and there are more than two locations, customization is required. Here the stock transfer goes between locations B and A, but the invoices go between locations A and C.

A custom program is required to take a stock transport requisition (STR), which in this case is created in the external supply chain planning system, and convert it into several documents, such as the Sales Order and Purchase Order pair between locations A and C, and the STO between locations C and B.

Thus, while an STR is created in APO, once it is sent to ERP, that same transaction becomes a purchase order and sales order (which cancel each other out as they are for the same item or items and same quantities. The sales order and purchase order are simply two transactions moving within a company, or should I say two different companies—a company buying and selling to itself but situated in different countries). Let’s review how the two different approaches work.

  1. Standard Intercompany Transfer: When product flows from an intercompany location A to location B and the invoice flows from location B to location A, a billing STO is the standard and most direct way of managing the relationship between the locations. The external supply chain planning system is unaware that the STO is billing or not billing. Billing is handled completely in the ERP system as external supply chain planning systems do not deal with money. This approach is relatively easy to configure.
  2. Asymmetrical Intercompany Transfer: When more than two locations are involved in the stock transfer relationship, the billing STO is not the way to set up this relationship, as it will place the invoice in the wrong location. In this case, an STR is still created within the external supply chain planning system between the sending and receiving locations. However, once this STR is sent to the ERP system, the STR must be converted to matching purchase orders and sales orders. These items will move between additional locations beyond the two that are involved in the stock transfer. A company engaged in broad-scale international stock movements will sometimes have different intercompany transfer models. Some of these models mean the creation of a paired purchase order and sales order from a stock transport requisition/order created in the external supply chain planning system. Other movements may require no sales order, and in this case, the STO is converted into a purchase order.

Controlling Transfer of Ownership in ICO Movement

In most cases, the transfer of ownership will occur when the product is receipted into the receiving location. Although this is the standard workflow for most ERP systems, it does not meet the requirements of all companies. Some companies want the ownership transfer to occur after the product has left the sending location, but before it arrives at the destination location. I have found this to be true particularly of transfers with very long lead times, such as ocean carriage.

The graphic on the following page shows the standard transfer of ownership versus the custom alternative.

The first alternative is preferable as it is in line with how many external supply chain planning systems and the ERP system operate. However, for different reasons, some companies prefer the second alternative. Because the transfer cannot be performed while the product is in-transit, an intermediate location—which is not an actual physical location but is a virtual location—is sometimes set up to perform the transfer.

The Core Problem of Limited Dimension Transactions

The issue that companies face when attempting to manage complex requirements of this type is that the ERP system is too limited and too inflexible to be adjusted. Instead of prescribing a limited set of functionality, ERP systems could have been designed quite differently.

We use the terminology of STO, non-billing STO, and billing STO. All of this terminology describes transactions that behave differently in a dimension where the transaction impacts the ERP system, as shown in the graphic below:

 

A transaction is nothing more than a container that initiates a series of related transactions— which change the state of the ERP database in prescribed ways. Rather than prescribing a limited number of ways that a transaction can behave in a particular dimension, one can open up the options, and this can be accomplished with far less complexity and without the confusing terminology. It is unclear why so many ERP systems took such a prescriptive approach when developing the software in the first place. Perhaps they lacked the development sophistication to make flexible systems and wanted to reduce the costs of development. Creating a system of more limited behaviour within the dimensions of a transaction saved development effort and money in the short term, but is ultimately a poor trade-off. The software must be customized per client location, resulting in a great deal of redundant customization (because the same customization, or at least very similar customizations, must be performed in a decentralized fashion at implementing companies). In case the point is elusive, this is exactly what has happened with ERP systems.

An alternate development approach is to decompose the transaction to its behaviour per dimension, provide an initial set of common dimension combinations, and allow the transaction to be easily extended. This can happen by simply copying over a pre-existing transaction variant and making a single change to a dimension behavior (or to multiple dimension behaviors), resulting in a new transaction variant. An example of this is shown below:

The total library of the transactions categories and variants within those categories constitutes the total of the functionality within any ERP system.

Advice on Enjoying the ERP Quiz

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

Conclusion

What I have described above would be the perfect scenario, but ERP systems were not designed this way. And because of their transactional inflexibility, the tight integration of their modules means that they restrict the ability of companies to fully leverage the functionalities in applications that are connected to ERP systems. Thus a company with an ERP system will receive less value from any other application that they implement (unless the application is extremely simple) than a company that does not have an ERP system. This is one of the major reasons why most ERP systems are either a dead end—or simply a starter kit setting a company for much more expensive and work down the road.

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.

 

Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.

References

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 SAP Uses Best Practices to Control the Implementation

Executive Summary

  • SAP uses the false assumptions of best practices to control accounts.
  • Best practices assumptions damage the project from beginning to end.

Introduction

SAP lists best practices in several areas on its website. I have included the following screenshot of best practices from this web page.

Here, SAP claims that because they are so big, all best practices are included in their software. Secondly, they propose that customers who use best practices have been able to reduce consulting costs by 50 percent and reduce mistakes.

But, wait one second; aren’t best practices naturally inherent within SAP?

Does one have to choose between a best practice implementation and a non-best practise implementation?

What constitutes a best practice implementation?

This is all extremely confusing, as well as logically inconsistent.

Understanding the Presentation of SAP Best Practices

It’s essential to know how SAP presents best practices to its customers.

To enhance this understanding here are some screenshots from SAP’s presentations. I was amazed at what I found from this presentation because what is presented here by SAP has no relationship to what occurs on SAP implementations.

Here you can see SAP proposing that SAP best practices can reduce the adjustments necessary to the software. In an implementation, a company brings its requirements. Then those that the software cannot meet are either removed from scope, or they are accommodated with an enhancement or by buying another application. SAP never recommends the second option, which is purchasing another application, but nearly always pushes the client in the direction of enhancement, and enhancement that is written in ABAP, even though in many cases a non-SAP coding platform may be better.

This is the text which accompanies the slide above:

SAP Best Practices are packages that provide preconfigured business processes and project accelerators to streamline customer implementations. – SAP

A best practice is not anything that is described above. Instead, it is functionality in the software that is supposed to be the best way to perform a business process. This sentence is very concerning because firstly best practice functionality is not provided by SAP. Still, this sentence implies that there are other things that SAP offers to their clients that are not part of the software that are also best practices. It makes me wonder how much time people in sales in SAP spend in the software they are selling.

All vendors offer documentation and guides for how to implement their software. However, they are generally not called “best practices.” Again, best practices are supposed to be contained in the software themselves. They are not the manuals for the company. SAP is defining best practices so broadly here, that it appears that everything they offer is a best practice, and nothing is not a best practice. They list automated tools on this slide, which again, I have never seen on a project. Finally, they finish off with a graphic of a box. So now SAP best practices are something you can pick up and take with you on your projects I suppose.

This looks interesting, but again I have never seen any of these things on an actual project. I would be concerned if this is presented to a client, and then as an implementor, I am expected to gain all these benefits from “Solution Builder” when in fact it will not even be used on a project. SAP is actually very time-consuming to configure and is the most challenging system to configure that I have worked with. However, this messaging is misrepresenting how difficult it is to configure SAP, and proposing these solutions will significantly ease my task. This is consistent with much of SAP’s messaging, that SAP is amazingly easy to put in, and already has most of your business process or something even better (best practices) already in the application. This is simply delusional. People that write these things need to spend some time on an SAP project.

This slide shows three things I am supposed to be able to leverage to improve the implementation. One is the Solution Builder. The next is the Implementation Assistant. The final one is the Building Block Builder.

I have never seen any of these tools on a single project I have worked on.

The average implementation time for an SAP project is now 4.2 month?

That is interesting.

I should note that this study goes back to 2006, 2007 and 2004. Therefore it cannot be that my information is out of date. I don’t see SAP projects going live faster than a year, and I arrive on many projects where the module has been live for several years and is still not delivering very much value because it was either a poor choice for the business or because it was never appropriately configured in the first place. These numbers are entirely made up. Before I read this presentation, I was not even aware that all of these best practice accelerators were also used on projects, that is how little consequence “best practices” that are described in this presentation have on actual SAP implementations.

The individuals who made this presentation are not living in reality, and are not talking to or listening to the people inside of SAP that implement software. The presentations were developed from a marketing angle, but it is so divorced from reality that it crosses the line into fiction. In some ways, the presentation serves as a comedic document. Still, the document is not that amusing because companies may read this information and think there is some truth to it. Then when they implement, people like me will have to explain why none of the information contained in the document is correct. This is a constant issue with sales and marketing departments, in that they are continually disseminating false information that then has to eventually be contradicted by people who did not publicise the incorrect information, to begin with. When that happens, marketing and sales is nowhere to be found and is often retelling the same false story to new customers.

We cover this problem in more detail in the article Why SAP Customers Followed SAP’s Advice on Coding in ABAP.  

Not Performing A Proper Software Selection

The presentation of SAP best practices is a method for SAP sales to lull their potential clients into not performing a thorough comparison of their business requirements versus what SAP software can do, versus what competing applications can do. When you ask SAP consultants about SAP functionality, they are cautious to always position SAP as the default choice. Any critique about the ineffectiveness of the functionality of SAP applications is met with the benefits of integration to SAP.

The enterprise software market is very inefficient with most companies selecting the wrong software for their needs, and I described for demand planning software in this Why Companies Select the Wrong Demand Planning Systems. One reason for this is that companies do not perform a thorough software selection, and another reason is that they rely upon biased and corrupt consulting companies like Accenture or IBM. These are companies that have long-standing relationships with vendors that they recommend to clients no matter what the fit is with the client’s requirements. This is why large consulting companies are incapable of performing an honest software selection, as I described in the article Why Big Consulting Firms Cannot Do Software Selection.

In essence, what SAP is doing is asking its potential clients to forget making a proper comparison of different enterprise software, and trust their statement that all the best practices exist in SAP in any case, “so what the point of actually performing a software selection?”

SAP Best Practices and SAP’s Marketing Machine

On some projects, through the years, I have noticed the term “SAP best practices” used by SAP quite frequently. In the beginning, It always struck me as a bit curious, but on the other hand, I never gave it much thought. As I describe in this post, SAP has what I think is the world’s most excellent enterprise marketing machine. SAP best practices are part of its strategy for business development. SAP has some marketing concepts that they use for business development to gain, keep and maintain market clients in the marketplace.

Best practice is one of these.

It’s important to understand that SAP marketing messages work not only to get SAP clients but also to control the interpretation of their software during implementation and after go-live.

However, later on in this article, I will show that SAP is both not based upon best practices, and secondly, in SAP’s documentation, they are confused as to what a best practice is.

How Large Consulting Firms misuse the Term Best Practices

SAP is not the only company that uses the term as a marketing construct and for business development. Large consulting firm consultants also like to use the term and use it in a way that is almost always misleading. I once worked as a consultant at IBM who created a custom fix for a safety stock problem in a way that was a worst practice, and then proposed that weekly delivery frequency was “best practice.” This is somewhat amusing as this consultant was so technical he was almost a development resource, and would not know a business best practice if it hit him in the head. This is, in fact, my view of most of the IBM consultants that I have met that work in IBM’s SAP practice. IBM consultants in their SAP practice do have good technical skills, but they are mostly lying to clients when it comes to their business knowledge.

IBM also promised a large number of best practices from their “vault in Armonk,” however, one of the major complaints of the client is that IBM did not seem to offer any, even though this was a significant focus of the overall sales presentation to the client. The only best practices that the client received were made up ones to obtain buy-in on decisions the consultant wanted to go his way. They had nothing to do with a large data sample of companies that showed that one way of doing something was superior to another.

After working with IBM on several occasions, I can say with confidence that their best practices are fake.

Best Practices as a Legitimate Concept?

The concept behind best practices is that there is one best way of doing something. That is if a user creates and interacts with a purchase order in a system, there is one best way to view, manage and process that purchase order. SAP claims that their software is built around best practices because they are so large that they can say they have “standardized” their software on the best practice.

The concept is used in multiple ways on accounts:

  1. To initially sell the software.
  2. To control the implementation process to guide the client into using the SAP way of doing things.
  3. To shut down disagreement on the part of users.
  4. To prevent executives from actually analyzing the underlying reasons why users are unhappy with the implementation.

What is unknown by most of the population is that the concept of best practices has been thoroughly analyzed in academic research, and found to be invalid.

Fake Best Practices

Best practices sound suspiciously like something that one is asked to take on faith— and they are. Eugene Bardach, a professor of public policy, analyzed claims of best practices in his field and found that best practices are not based upon research.

“Appearances can be very deceiving. On closer inspection, it often turns out that the supposedly ‘good’ practice is not solving the problem at all. Inadequate measurement plus someone’s rose-colored glasses were simply producing the illusion of mitigating the problem. It may also turn out that, even if good effects have truly occurred, the allegedly ‘good’ practice had little or nothing to do with producing them.”

The further one gets from actual implementation, and the less experienced one has with working with software, the more likely one is to believe that software can encapsulate best practices. Because the term “best practices” is so general, it does read a book on the topic of dishonest argumentation. This is a good indicator that something is wrong with the information that is being researched.

Another topic is related to the overall idea of best practices.

At first sight, the logic of best practices as propagated by consultancies seems irresistible: by copying practices of the worldwide mose successful companies, drawing on consultants’ experiences, one can improve one’s performance. However, some authors warn that the practice of implementing best practices is not as easy as consultants insinuate. Thus, Sandal argues that “one of the most pervasive and damaging follower afflictions that has increasingly infested corporate psychology is a disease known as best practicism. He attributes the causes of this disease to a number of erroneous beliefs, among them the belief that best practices are easier and less risky and the belief that the best practices can easily be transferred from one company to another. In a similar vein, Wareham and Gerrits question whether best practices remain best practices when transferred to another context.

Considering the problems in identifying best practices and in transferring them it is somewhat astonishing that best practices are given such a prominent role in consultancies’ communication. – Trading “Best Practices” – A Good Practice?, Industrial and Corporate Change

The Car Versus Truck Best Practice Example

Let’s take the example of two automobiles: one sedan and one truck. I currently own a Honda Accord but have been thinking of buying a four-wheel-drive Toyota Tundra. These are two very different automobiles built for various purposes. Both score very well in reliability, which I consider a best practice; that is, I prefer high-quality cars that require infrequent repairs. However, could the fact that they both use an internal combustion engine and pneumatic tires be considered best practices? These are two of the most important inventions in human history, so I suppose I would not object to calling them best practices.

But on the other hand, every car I look at offers the same thing, so while they are best practices, they are not differentiators. Am I interested in comparing best practices that are not differentiators? I would say probably not. The Toyota has four-wheel drive, which can be a best practice if you intend to take the car off-road, but is an unnecessary and extravagant option if one does not expect to use the vehicle in this manner. Four-wheel drive decreases gas mileage after all, and the knobby tires required to go off-road, ride roughly on a paved road. So should I sell my Honda and buy the Toyota? Well, there are several factors, such as how much I will be using the vehicle for commuting versus taking my jet ski to the lake and going camping.

The vehicle’s benefits to me change depending upon the situation. There are some best practices, such as reliability, that are important to me but maybe less important to other people. For instance, neither of these are particularly stylish. However, the Land Rover is very stylish and has the best practice of four-wheel drive. If anyone has ever sat inside of a Land Rover with a leather interior, I think we can agree that their interiors are a best practice (that is, they feel very nice). To get the stylish ride, one has to pay a great deal more and give up the Japanese reliability for English reliability.

So how do I decide on my vehicle with all these competing best practices?

I hope I have shown that there is a reason that people don’t take the concept of best practices to buying an automobile, or really to any other purchasing decision, and this is because the idea is ridiculous. People look for a series of trade-offs in characteristics until they find a desirable compromise, and then make their purchase decision. It does not happen now, and will not occur in the future, that your friend will announce that he based his new car purchasing decision on best practices.

Best Practices in Which Software?

I used the example of cars because most everyone has at some point made a decision to purchase a vehicle and because cars are relatively easy to understand. However, the concept of best practices is equally unhelpful and even problematic in making distinctions between things that we do not know as well. As my expertise is supply chain software, I know that making supply chain software decisions based upon best practices does not make any sense. This is elementary for me because I have spent more than a decade and a half analyzing and configuring supply chain software and work with it almost every day. However, because I don’t know much about accounting software, if someone were to propose that accounting software can be purchased based upon best practices, it would seem to me to be a strong statement, but only because I do not have the content expertise to analyze the claim truly. Indeed, some things are desirable in accounting software that could be deemed “best practices.” For instance, it is advisable that the program post the actual quantities entered into the database, rather than using a random number generator. It is desirable that the program not crash and delete the last five hundred accounting entries. However, once we get past the rather common areas of functionality, there will be considerable debate as to what are best practices.

How SAP Uses the Concept of Best Practices

I suppose I don’t spend enough time listening or reading to SAP’s marketing message because it took a conversation with an industry analyst to have it explained to me that SAP hides behind the concept of best practices to defend weaknesses in their software.

The basic strategy is that SAP prepares their executives up for complaints about their software by priming their executives to think that any complaints are because the users are resisting the best practices that are in the software. The sentence may be something akin to the following:

“You may receive push back on the system, but that is a change management issue because your employees are resisting the best practices that are in the software.”

In this way, SAP’s software deficiencies are deflected back on the user.

Is SAP 100% Built on Best Practices? 50%?

The question should be, what evidence is ever presented that SAP software only contains best practices? The answer is that no evidence ever is usually provided, at least when the claim is made orally, which is where it ends in most circumstances. However, you can find several SAP resources on best practices. I have entered a screenshot below of best practices.

As you can see, SAP claims that because they are so big, they have all best practices included. Secondly, they propose that customers who use best practices have been able to reduce consulting by 50% and reduce mistakes.

However, wait one second, aren’t best practices naturally inherent within SAP? Does one have to choose between a best practice implementation and a non-best practice implementation? Secondly, SAP implementations are the most expensive implementations on the planet. If one is looking to reduce consulting time or expenses, SAP would be the absolute wrong solution. It brings up the question “what exactly are best practices in SAP?” Here is another screenshot on the topic of best practices.

“SAP Best Practices Based Upon Netweaver—SAP Best Practices provide a toolset that helps IT and functional project team members to quickly deploy functionality in SAP solutions—from SAPNetWeaver, to core SAP applications. The toolset comprises a mix of step-by-step instructions, pre configuration, sample master data, code samples (where applicable) and end-user training—organized by technical or business scenarios that you might want to implement in your landscape. Below you will find the SAP Best Practice versions that support the implementation of SAP NetWeaver components.” SAP

Best Practices in……Master Data?

Here you can see that now SAP is classifying best practices as a toolset made up of instructions, pre-configuration, sample master data. But let us back up a few steps here. What do best practices have to do with the master data? Best practices are supposed to be business process functionality that is baked into the system. Master data should be kept up to date, and validated with the business; however, this is not something you can bake into the application unless you mean making the software transparent and easy to use. Still, in that case, you are enabling a best practice; you are not modelling a best practice yourself.

Overall, this seems more like a jumpstart toolkit. The paragraph goes on to say that there is a NetWeaver component to best practices.

However, how can this be? NetWeaver is essentially the infrastructure components of SAP (PI, ABAP, Basis), so what do these have to do with business process functionality best practices? If by best practice SAP means ease of use or sustainable infrastructure tools, then SAP products are based upon worst practices, because of all the infrastructure I have worked with, it takes SAP the longest to do the essential things. Also, one questions how serious SAP is about their NetWeaver best practices are because all of their links to supporting content on this page are broken.

The answer to this is that SAP does not know and are confusing them. They like to use the term liberally, but they use it in so many ways their usage is not consistent with the term’s meaning. They started off saying one thing with best practices, a statement which was initially false even in that instance, and then their product management could not control themselves. They just began applying the terminology to a variety of initiatives just for the fun of it.

World Class = Best Practices = Digital Transformation?

Interestingly such unsubstantiated statements are quite common either in SAP or outside of SAP. The following quotation demonstrates this.

“A few years ago I had a meeting with a marketing director of a well-known consumer goods brand who proudly told me about the world-class stage-gate product process they had introduced.

How many successful new products have you launched as a result of this process, I asked?

Well, none, he replied, but the process is world-class, he insisted.” Dr. Ken Hudson

If you want to make something sound tantalizing, but you have zero evidence that it is, in fact, beneficial in any way, give it some generalized positive label — best practice, world-class, best-in-class, super-duper — the choice is yours. As a large portion of the business community is unthinking zombies, the technique is amazingly effective in almost any domain.

Ahh, the new term for his is digital transformation, a term as meaningless as best practices as we cover in the article The Problem with the Term Digital Transformation.

Confusion on Best Practices by SAP

The worst-case scenario is that SAP employs marketers who can’t keep their story straight and have limited English and logic foundations. Also, one questions how serious SAP is about their NetWeaver best practices because, when I reviewed this material, all of their links to supporting content on the web page were broken.

The answer to these questions?

SAP does not know; they are confused themselves as to how to use the term “best practices.” SAP smears the term, like cream cheese on a bagel, on almost everything they do. With SAP, directly calling standard SAP documentation, a “best practice” will somehow (magically) allow projects to go live much more quickly. In this case, the best practice is an incantation. It’s challenging to take a vendor seriously when they are so undisciplined as to the use of their terminology. SAP finishes off the proposal by declaring that best practices enable SAP implementations to go live in 4.2 months.

This is not true; in all my years working with SAP, I have never seen any SAP module go live in 4.2 months. This is another problem with credibility: SAP implementations are measured in years—not months—and anyone who works in SAP knows this. So where is this number coming from, and what module is SAP talking about? Where is the evidence for this? No evidence is ever presented.

The Negative Effect of Best Practice Claims on Projects

If only best practice claims ended when the software was sold, that would be one thing; however, the conversations regarding best practices passed from sales to the consultants who are supposed to make good on these claims during the implementation. When you repeatedly tell a customer that they will get best practices in every dimension if they buy your software, unfortunately, they don’t forget this.

As with any promise that can’t be fulfilled, SAP consultants are put in an awkward position. I would know—I have been one of these consultants. On many of my projects, the term “best practice” becomes a punch line. The individuals in the implementing company come to realize that there is no such thing as best practices.

Jokes such as,

“But wait…it’s okay because it has best practices,”

or,

“All we need on this project is just more best practices!”

..are quite common. Because marketing and salespeople don’t work on projects or with software, they do not know this. After realizing that they had been deceived by SAP Sales (accompanied by a healthy dose of cynicism about best practices), I heard senior members of my client declare..

“We don’t want to hear anything more about best practices.”

In the implementation phase, best practices lose all credibility.

Non-ERP Uses of the Term “Best Practices”

SAP is certainly not the only company that uses the term “best practices” as a marketing construct for business development. Consultants from large consulting firms also like to use the term and use it in a way that is almost always misleading. I once worked with a consultant who created a custom adjustment for a safety stock problem in a way that was utterly inadvisable: I would consider it to be a worst practice. He then proposed that weekly delivery frequency was best practice. He essentially suggested that any technique that he wanted to employ was a best practice. On this project, I learned that twice-a-week delivery was a best practice; who knew that how frequently a product is delivered could be a best practice?

It isn’t.

Consulting companies are continually using the term “best practices” to sell work. However, as with best practice claims made by ERP vendors, no evidence exists that what the consultants promote as a best practice is that and this is because they have no proof; it’s an opinion. It’s one thing to say that this or that is one’s opinion from experience. But it’s something else to gusset up this opinion as a best practice—with zero evidence—simply because one would like to have their opinion carry more weight. It is also common to hear from the client that the consulting company did not seem to offer best practices once they were on the project. The reason is simple enough: once one gets into the details of the actual recommendation, they look a whole lot less like “best practices” than they did from a distance.

Criticizing Pre-existing Systems

Best practices have been beneficial to ERP vendors as a way of permitting them to criticize a potential customer’s pre-existing systems. Sales and marketing are about changing perceptions to encourage a purchasing decision. One way of doing this is to increase the purported virtues of the item to be purchased (in this case, the ERP system). Another way is to lower the perceived value of the customer’s current item. Using the term “legacy” to describe all previous systems — which is another technique SAP uses that we cover in the article How SAP Used and Abused the Term Legacy. The term “best practices” to describe ERP systems, is highly effective and an impressive feat of rhetoric because it ignores the critical fact that the legacy system had been customized for the business requirements, while the ERP system had not.

Essentially ERP vendors appealed to a central concept: how things are done in other organizations must be better than how things are done in the potential customer’s company. This is a reversal of the “not invented here,” philosophy which proposes, “anything not invented here.” This is explained in the following quotation:

“ ‘Don’t assume newer is necessarily better,’ advised Project Manager Ellen Harmon of the Washington State Community and Technical Colleges Center for Information Services. Harmon considers her existing legacy system to be just another, older ERP. ‘We actually have an ERP that has been developed over the last 18 to 20 years for specifi c clients, and because of that, this ERP is very focused on these particular client needs.’ The case is the same at other universities.‘Their legacy systems have been developed to meet their specific needs and are tailored to their environment,’ said Harmon. ‘An ERP vendor might say your system is old, and therefore is bad, and we will sell you this new system. But it is a legacy system, too.’ ” Promise of ERP System

This quotation brings up an interesting question: what is the definition of “legacy”? An ERP vendor may be selling a system that has an older code base than the “legacy” system it is replacing.

Interestingly, the designs of many of the ERP applications sold today are incredibly dated, and yet they are never referred to as “legacy.” To a software salesman, other people’s systems are legacy, but your systems are never legacy. One might ask why this is the case.

The reason is not hard to determine. “Legacy” is a term of propaganda that is applied to systems that the designator would prefer to denigrate as a pretext for proposing another system. If you work in ERP Sales, then all pre-existing systems in the companies to which you would like to sell your ERP software are legacy. The ERP system you are selling—no matter how dated—is never referred to as legacy. Therefore the term “legacy” has two meanings: the actual definition (“an old method, technology, computer system or application program”) and the real sense—any system that you would like to replace. However, many decision-makers missed an essential detail of infrastructure technology management, as explained in the following quotation:

“IT analysts estimate that the cost to replace business logic is about fi ve times that of reuse, and that’s not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits—they always have, and they always will. New software may increase the risk of system failures and security breaches.” – Wikipedia

Many companies relearned this fact about computer systems. Many of the cost overruns of ERP systems were related to replacing business logic.

Considering the SAP Best Practices Claims in Light of Their Actual Software R&D

I have worked in SAP APO since 2002 and never found anything in APO that did not exist in other vendors before SAP putting it into APO. Other vendors have adopted cost optimization, allocation, the statistical forecasting methods used by DP; in fact, everything in all the modules. However, if we broaden out the search for novel functionality to ERP, we can see that MRP and DRP were well established before SAP adopted them.

There is nothing new in SAP BW either. SAP is one of the few vendors that partner with smaller software companies so they can specifically both co-opt their technology and build their products from it. So SAP has copied its functionality from everywhere.

However, I don’t think that is what SAP means when they refer to best practices.

Evidence That SAP Software Is Not Based on Best Practices

It’s clear that SAP primarily relied upon its customer base to justify best practice claims. Secondly, there are many areas of SAP that I am aware of that are not best practices. Here are some examples:

  1. SAP APO SPP uses DRP functionality to perform something called inventory balancing. However, DRP is no longer the best approach to achieving this business process. The best practice is to use multi-echelon functionality. DRP plans all facilities as if they are independent of one another, which is a less accurate method of planning, and not an accurate reflection of reality. However, the problem is that SAP APO does not have it, while several best of breed vendors do.
  2. SAP APO DP has very few examples of implementations using the characteristic based planning functionality. This is because it is so difficult to configure that it rarely is. It is also very weak in attribute forecasting. It is so infrequently used that one could question if DP is an attribute-based forecasting tool. I have used an application called Demand Works Smoothie that allows the entry of attributes into different columns in an import spreadsheet or database table. This allows for extremely easy to change attributes, something that is unheard of in SAP APO DP.
  3. SAP APO SNP only has one method by which to use service level to control stocking levels, which is dynamic safety stock. However, that is no longer the best practice. The best practice is to us inventory optimization, which SAP does not have, but best of breed vendors do have.
  4. BW has neither the ability to quickly make changes to the underlying data structures to support changes in the business nor the ability to provide best-practice analytics. SAP would probably say that they have fixed this issue with the purchase of Business Objects. However, Business Objects also lacks best practices in this regard compared to competitors such as Tableau. Secondly, SAP claimed to have a best practice data warehouse back when they only owned BW. So if they already had all the data warehouse best practices, then why did they repurchase Business Objects?
  5. PP/DS uses cost-based optimization and heuristics for developing the plan. However, neither one of these approaches is a best practice currently. Cost-based optimization has failed to find success as an effective way of performing production planning and scheduling, and heuristics while better than purely manual methods are of low average effectiveness. Currently, the best practice in production planning and detailed scheduling is performing time or duration based optimization. However, SAP lacks this functionality. Other vendors have moved ahead of them, and SAP is offering old, less effective technology to its clients and pretending it’s on the leading edge.

These are just a sampling. The areas in which SAP software does not have best practices goes on and on.

Best Practices as a False Construct

The idea that SAP contained best practices was never true. SAP often offered many ways to configure a system, so SAP contradicted itself as this would have to be called best practices, or multiple best practices per process. There are many ways of doing things that aren’t even excellent practices much less “best.” My conclusion of SAP’s best practices is that they are just a marketing concept that looks good in PowerPoint presentations. The less you know about SAP; the more best practices seem like they may exist in SAP.

The fundamental problem with the concept of best practices is there can be no final agreement as to what a best practice isn’t a best practice. Secondly, when SAP or any vendor for that matter declares that they have all the best practices, it must be understood that this is a self-bestowed title. Self-bestowed titles don’t have any meaning. It would be like me naming myself the best dancer in Atlanta. But at least there is some competition I could enter to prove such a thing. There is no best practices competition that is held and no official body that approves certain practices over other practices and names them “best.”

I am still waiting for the software vendor to advertise the fact that they only have the worst practices in their software.

Therefore, part of the reason that SAP used the term legacy was to criticize the existing systems of their customers and to do so without explicitly analyzing any of them. And SAP’s solution?

Well, this is two-fold.

  1. In as many cases as possible simple eliminate the in-house software and move to SAP’s “best practices.” In SAP’s considered opinion, none of them was necessary as SAP’s software did everything correctly anyway, and anything the customer had come up with was the wrong way of doing it. This was true even if SAP did not have the specialized functionality that was developed over what was in many cases decades by the customer.
  2. Port all the logic from open programming languages to their ABAP programming language.

SAP gets our Golden Pinnochio Award for false claims with its repeated claims around best practices. 

The Truth of Best Practices in SAP

Best practices have been pitched as a central premise for SAP marketing efforts for some time. SAP is not the only company to do this. As I described in an earlier article, IBM, as well as many other consulting companies, present the idea of best practices, primarily as a way to get business and as a way to control the implementation.

“I once worked with a consultant at IBM who created a custom fix for a safety stock problem in a way that was really a worst practice, and then proposed that weekly delivery frequency was “best practice.” IBM also promised a large number of best practices from their “vault in Armonk,” however, one of the major complaints of the client is that IBM did not seem to offer any, even though this was a major focus of the overall sales presentation to the client.”

Therefore IBM consultants often use the term “best practices” to get their way on configuration decisions. However, IBM does not offer the best practices that it has supposedly picked up from all its experience to its clients, although IBM salespeople say that they do.

Who Makes These Best Practice Claims and Why?

Best practice claims are made by SAP Marketing and Sales. Best practices that are described by SAP should be categorized as a sales technique. They have no validity on an actual project. The way to evaluate enterprise software is whether it has specific functionality that addresses the needs or business requirements.

Using the term best practices interferes with this analysis and places a false schema on top of the analysis that needs to be done. SAP Sales and Marketing is now simply smearing the term, like cream cheese on a bagel on almost anything do with SAP. This includes calling standard SAP documentation a “best practice” that will somehow, (magically?) allow projects to go live much more quickly. The SAP presentation finishes off by declaring that best practice enable SAP implementations go live in 4.2 months, which is not only not the average, but in all my years working with SAP I have never seen any SAP module go live in 4.2 months anywhere at anytime.

The Effect of Best Practice Claims on Projects

Another problem is that SAP’s best practice claims put SAP consultants in a difficult bind. This is true whenever one is asked to justify something untrue. SAP consultants arrive on projects with these enormous and false best practice claims placed on the software. The consultants are then forced to explain that one still has to gather requirements and determine what parts of the requirements can be covered by standard SAP functionality and which cannot. That is all of the best practice claims made by SAP sales and marketing do not change what must occur on the project.

Advice on Enjoying the ERP Quiz

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

Conclusion

Best practices that are described by SAP should be categorized as a sales technique. They have no validity on an actual project.

The way to evaluate enterprise software is whether it has specific functionality that addresses the needs or business requirements. Using the term best practices interferes with this analysis and places a false schema on top of the analysis that needs to be done. Best practices are all over SAP sales literature as I described in this An Analysis of SAP’s Messaging on Best Practices, and are used very frequently by consulting companies. Still, on actual projects, they mean very little.

SAP uses unsupported marketing concepts for business development in several major categories of their message to companies, but best practices might be the most effective. First of all the statement does not hold up against any analysis of SAP’s software, and second, it is dangerous to assume that any software vendor is telling the truth regarding the idea that they have all the best ways of doing things already programmed into their business logic, so you don’t have to worry or question.

Secondly, SAP is not clear as to what best practices are themselves and does not even take the time to keep the links on the topics updated. The vendors that are more honest about this setup their software to be flexible enough to do things some different ways, but then use their consulting resources to figure out the best way for the particular client. SAP cannot follow this approach because the software design is inherently inflexible, and thus the need for the brilliant sleight of hand known as “SAP best practices.” What “best practices” actually means is that SAP is right. That the way SAP has designed their system is the best way and other ways are wrong. And clients, for the most part, buy this, and consultants have adopted the concept of “best practices,” because it reduces their necessity to present any evidence.

Instead of being hypnotized and distracted by the term best practices, companies should instead get into the details of what software can do and what it cannot do. Secondly, it needs to match that analysis with what the company wants to do. Looking to software vendors to tell you to want to do is a mistake. Your business needs to know what it wants to do, and if they are following poor practices, then need to hire the right people, or bring in the right external business expertise to improve these processes.

Best practices have been a deep well that ERP vendors have repeatedly drawn from to support multiple objectives.

ERP vendors do not attempt to hire professional researchers to validate their claims regarding best practices because

  • a) Most of what they are proposing is how their software works—and is not a best practice, and
  • b) Customers generally don’t question the best practice claims made by ERP vendors.

Generally, all that is needed to convince companies that a software vendor has best practices is if the software vendor has marketing documentation that declares the existence of best practices, and if that software vendor is generally successfully selling its software and has significant brand recognition.

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.

 

Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.

References

https://help.sap.com/bp_dm604/BBlibrary/General/SAP_Best_Practices_overview_EN.pdf

Wellstein, Benjamin., Kieser, Alfred., Trading “Best Practices” – A Good Practice?, Industrial and Corporate Change. Jun 1, 20122.

How to Understand The Logic Used to Sell ERP Systems

Executive Summary

  • ERP systems were sold based on things that never came true.
  • Find out what were the false logics used to sell ERP systems.

Introduction

Many of the arguments that are habitually made in favor of ERP are, in fact, nothing more than logical fallacies. Because of this, it is essential to review the definition of “logical fallacies.” Proponents of ERP use several logical fallacies in the quotations used throughout this book, and when they occur, I will be referring to these proponents by their official names. It is quite surprising how many of the quotations from ERP proponents fall into one or more categories of logical fallacy and realizing this led me to read a book specifically on logical fallacies to make sure I was able to identify all of them correctly.

When a topic leads one to read a book on the subject of dishonest argumentation, this is a good indicator that something is wrong with the information that is being researched. As always, in the absence of actual evidence, it becomes quite easy to fall into the use of logical fallacies. Logical fallacies are arguments that use poor reasoning.

They fall into the following categories:

  1. Presumption: Failing to prove a conclusion by assuming the conclusion in the proof.
  2. Weak Inference: Failing to provide sufficient evidence.
  3. Distraction: Providing conclusion with irrelevant evidence.
  4. Ambiguity: Failing to provide the conclusion due to vagueness in words, phrases, or grammar.

The Logical Fallacies

At least one of the following logical fallacies is presented in the form of a quotation from ERP proponents. These logical fallacies are listed below:

  1. Appeal to Probability: Takes something for granted because it might be the case.
  2. Appeal to Fear: A call to emotion where an argument is made by increasing fear. The fear discussed may have a kernel of truth, but the proposer actively increases this fear in an attempt to win the argument and gain influence over decision-making.
  3. The False Dichotomy/The False Dilemma: Forces a choice between two alternatives, when there are, in fact, more than two alternatives. One alternative is the proposer’s desired course of action, and one alternative would have an unacceptable outcome.
  4. Argument from Ignorance: Assuming a claim is true because it has not been proven false.
  5. Argument from Repetitions: States that, as it has been discussed, it is not worthwhile considering.
  6. Shifting the Burden of Proof: Does not prove a claim, but asks for the claim to be disproved.
  7. Argument to Moderation: Assuming that the compromise between two positions is always correct.
  8. Argumentum ad Hominem: Evading the standard requirement to provide counterevidence through the use of a personal attack.
  9. Hasty Generalization: Leaping to a conclusion based on a small sample of data.
  10. Argumentum ad Numerum or Argumentum ad Populum: Appeals to a widespread belief; the fact that many people believe it, means it must be true.
  11. Appeal to Authority: Where an assertion is deemed true because of the position of authority of the person asserting it.
  12. Appeal to Accomplishment: Assertion is considered true or false based upon the accomplishment level of the proposer.
  13. Appeal to Consequences: Where the conclusion is supported by a premise that asserts positive or negative consequences from some course of action in an attempt to distract from the initial discussion.
  14. Wishful Thinking: An appeal to emotion where a decision is made based upon what is pleasing to think to be true.
  15. Argumentum ad Novitatem/Appeal to Novelty: Where a proposal is claimed to be true/superior because it is new or modern.

This will now put us in the right frame of mind to review the logics presented by ERP vendors, consulting firms, and IT analysts.

The Logic Used to Sell ERP

The following chapter will cover the logics used to sell ERP systems. Each will be analyzed. However, a brief explanation of each will help set the stage.

  1. Y2K (the Year 2000): This was the concern related to the ability to correctly calculate dates in software that had been developed back when there was a minimal amount of data storage available, and developers saved storage by just using the last two digits of years.
  2. Single System: Companies have preferred to have a fewer number of systems. Developers and consultants know that developing specific purpose applications provides better usability, functionality, and maintainability than applications that try to cover a broad range of areas. However, this reality is unappealing to those that purchase software.
  3. Best Practices: Best practices are mostly a single best way of doing something. Best practices can be applied in software or outside of software. However, in software, the concept of best practices is that software vendors can review how many companies do something and choose the best way to incorporate it into their functionality.
  4. Integration Benefits: Hypothetically, if either a single system or a very few number of systems can be purchased and used by a company, it will reduce the integration costs.
  5. One Size Fits All: Under this logic, if the purchasing company agrees to use the software the way the ERP software vendor recommends, often following the logic of best practices, that all or nearly all companies can use the same ERP software.
  6. All Industries: This logic is that ERP systems, and particularly ERP systems from the more significant vendors because of their experience in so many industries, translates into the software vendor being able to build the functionality in their software to be implemented in any industry and to meet most of their requirements.
  7. Cost Reduction: Related to—or build upon the previous logics—that since all of the earlier logics are true that this will result in a reduction in costs. Also, based upon the idea that if a company concentrates its software purchases from fewer vendors that costs will decline.
  8. The Logic of ERP Driven Improved Financial Performance: This was the logic that ERP would be a pathway to improving the financial performance of a company. At one level, the financial performance was predicted to come from the improved operations of the company—but a second proposal was that the purchasing of an ERP system would signal to other entities, which the purchasing company desired to impress that the purchasing company was making a serious effort to improve. These entities could range from customers, suppliers, potential acquiring companies as well as Wall Street.

Details on the Logics

Y2K (the Year 2000)

Many ERP purchasing decisions were made because companies felt they needed to have ERP. This interpretation was often based either upon fear (such as the Y2K fear that drove so many ERP implementations) or a herd mentality. ERP presented itself as a silver bullet for the Y2K issue: instead of adjusting the dates on all of a company’s old systems to ensure they would work adequately post year 2000, they could be replaced—swept away by a shiny new ERP system. Fear of Y2K was the central component of the ERP vendors’ sales strategy.

“Slater (1999) discusses the breadth of such problems as he notes that ‘companies buy multimillion-dollar software packages only to fi nd out they don’t work—or at least they don’t work well—for one of their key business processes.’ The reason, Slater suggests, is that ERP software is so hot, the fl ames fanned by consultants and the technical press cause companies to simply push forward without dealing with such key restrictions.” – Technology Monoculture

One System to Rule Them All: The Single System Logic for ERP

A primary logic used to promote ERP purchases was that the ERP system would be the only system that an enterprise needed to purchase, as explained in the following quotation.

“The name is now Enterprise Resource Planning (ERP) systems to suggest that all information systems required for the management of a manufacturing enterprise are part of the solution.” – Process Industry ERP Requirements

When companies that purchased ERP found that ERP did not meet all their business needs, the next idea put forward was to implement the ERP software first, and then to connect non-ERP software (the so-called best-of-breed software) second. This approach is considered desirable because ERP is known as the backbone or the “mother ship,” with the other applications connected to it.

The initial idea behind ERP systems was that it would amalgamate many applications into a single system, thus reducing application integration issues. This concept is encapsulated in the quotation below:

“Many technical reasons exist including the replacement of disparate systems into a single integrated system.” – Hitt, et al., 2002

This turned out never to be the case for the vast majority of companies that implemented ERP software.

“The majority of respondents reported that an ERP system fulfi lls only 30 to 50 percent of IT requirements. As a result, many companies did not abandon their legacy systems but they tend to integrate the functionality from disparate applications.”ERP and Application Integration: Exploratory Survey

This gets into the customization of ERP systems.

“Most pharmaceutical companies have invested in enterprise resource planning systems (ERPs), but few get enough bang for the millions of bucks these platforms cost. It’s as if they bought a Lexus loaded with all the extras, but only use it to drive around the neighborhood. ‘Most [drug] companies are using ERP for the bare minimum,’ says Eric Bloom, vice president of information technology at Endo Pharmaceuticals. To realize the promise of ERPs, pharmaceutical manufacturers must fully integrate them with plant systems such as manufacturing execution systems (MES), quality management systems (QMS), and software for targeted applications such as radio frequency identifi cation, or RFID. For most pharmaceutical companies, the biggest issue is, ‘How deep should I take my ERP system into manufacturing?’ says Roddy Martin, vice president for life sciences industry strategies at AMR Research in Boston.”Realizing ERP’s Untapped Potential

And this is the constant problem: ERP does very little for manufacturing. This is true; in fact, most ERP systems were never really designed with much manufacturing functionality. Often ERP is discussed in terms of its MRP/DRP functionality, but even this is quite basic, not only from a sophistication level but also from a usability perspective. They can perform essential functions on the inventory level—such as goods issue and goods receipt—but ERP systems cannot be considered as much more than a starter kit for any manufacturing company.

Many companies have tried to “get more out of their ERP systems” by pushing them in directions where they were never designed to go (of course, with a healthy dose of customization). Still, companies that rely on ERP systems in this way cannot hope to leverage the available manufacturing software properly, and will always run their plants at a much lower level of efficiency than companies that adopt the more sophisticated and nuanced IT strategy. ERP systems never replaced all of the legacy systems in companies that purchased ERP. Therefore, this prediction was spectacularly incorrect.

Secondly, ERP vendors did not stick with this principle (of ERP being the only system a company needed to purchase) for very long, as the next section will describe. The fact that they moved away from this logic so quickly makes one wonder if they ever actually believed it themselves.

The Changing Story on ERP’s Ability to Meet All Requirements

Soon after the significant ERP vendors had saturated the market for ERP software, they began to develop specialized applications for things like supply chain planning, business intelligence, customer relationship management, etc. That is, when the opportunity presented itself, they immediately contradicted their logic that they had used to convince so many companies to buy ERP systems.

Curiously, a review of the IT/business literature at the time shows that the business/technology press did not seem to pick up on the fact that this new strategy was utterly inconsistent with the earlier arguments used to convince companies to buy ERP. I could find no articles that explained how inconsistent the new diversified application strategy was with ERP vendors’ statements made previously. ERP vendors moved away from providing only ERP systems for several good reasons.

  1. The Single System Approach Was Unworkable: The single system concept was never anything more than marketing hyperbole—and only a credible hypothesis for the naive, and it is unlikely the vendors believed what they were selling. There was simply no way that an ERP system, with its elementary approach to all functionality, could meet all the needs within companies.
  2. Sales Growth: Once ERP vendors had sold their ERP applications into most of the large and medium to large customers globally, they needed to develop more applications to increase their sales. In some cases, they could have added functionality to ERP; however, this strategy would not have maximized the ERP vendors’ revenues, as they would only get upgrade revenues from their existing clients. The trick was to sell new applications to their current clients. And to do so without having the clients remember that the primary justification for purchasing ERP in the first place was that it would cover all of a company’s requirements with a single application that contained all of the best practices (more on that later in this chapter). The ERP vendors relied upon both their consulting partners as well as the compliant IT analysts (the ERP vendors being the most significant sell-side revenue stream of the major IT analysts) to never point out this minor detail to customers.

Account Control

From the competitive positioning perspective, selling an ERP system to a company was one of the best ways ever developed to sell more software (after IBM unbundled software from hardware in 1969) into the same company in the future and to control the account. Rather than looking out for the interests of the buyer, account control is how third parties—such as software vendors and consulting companies—manipulate (or direct, depending upon your preference) their customers into following the desires of the third party. IBM was the first vendor to perfect account control, and many of their strategies (including how they leased their machines, the prices they charged, the way they dealt with their customers, etc.) were based upon account control strategies. Account control is behind how major consulting companies interact with their clients.

For instance, large consulting companies want more of their consultants on a project rather than the consultants from the software vendors, because they receive more billing hours and because it helps them control the account and control the information that their customers receive. At large software purchasing companies, in particular, the enterprise software market cannot be understood without understanding account control.

Misinformation on ERP

Once the software vendors had implemented the ERP system at a company, their relationship with that company was based on the fact that they were responsible for that company’s largest IT purchase. They had the network effect on their side. The misinformation they passed to their clients reinforced the dubious concept that ERP was somehow the keystone application. They pushed the “boogie man” of integration: that is, while the integration from other applications they sold would naturally integrate to their ERP system. The software from different vendors was an “unknown,” a guarantee that other software from that vendor would integrate to the ERP system at a reasonable cost or in a reasonable timeframe. That was the story anyway; a future section in this chapter will explain why this was never true.

Monopoly Power

This integration argument is particularly compelling because the ERP system is considered the central application for a company—the application to which other applications must integrate. This granted ERP software vendors the same type of monopoly power over their customers that Microsoft gained through controlling the operating system on PCs (but in the case of Microsoft, their applications actually did work better than competing applications on Windows, although they often made sure of this by postponing information about Windows from becoming public until the new version of Windows was released—they could have very easily released the APIs earlier). This monopoly allowed ERP vendors to compete unfairly: they told clients that their applications had a head start on integrating to the company’s ERP system. In the example of SAP and Oracle, the integration benefits were far more illusory. I can recall my shock when I analyzed the prebuilt adapter that extracted information from SAP ERP SAP BI/BW. It was clear that Development had done the absolute minimum required in order to mislead potential customers into thinking that they could pull a large variety of data from SAP ERP into BI/BW. Instead, what customers really received was a starter kit. Companies like SAP and Oracle promptly took full advantage of this market power, and this enabled them to charge top dollar for all of their applications, and furthermore to easily compete with applications that were far superior to their own applications.

Overall, this power was abused in so many ways that it would be tedious for my readers if I listed them all. But I will mention one of the more creative ways, which was developed by SAP: their pseudo partnership program with other vendors promised entry into SAP’s enormous client database, when in fact the program was an intelligence-gathering operation by SAP to allow it to steal intellectual property from their “partner” vendors, thus helping them to backward engineer the application.

Once again, the IT/business press and IT analysts failed to explain what this program was, and in fact, they lauded it. And once again, they were proven incorrect when the program died and did not lead to a new golden age of integrated applications (no surprise, it was never intended to). The upshot of all of this was that the ERP vendors were in an excellent position to sell more software into these accounts.

Selling More Software into Accounts

These new non-ERP applications all have their own platforms, and while they have adapters or interfaces to one another, they are each a separate application; they each have a different database and sit on different hardware. Many of these new applications are acquisitions: after a software vendor acquires another software vendor, they typically develop a marketing program to inform all current and potential customers as to how well the new applications will work together. ERP clients who purchased applications that Oracle had acquired were worse off than if the software had been left independent and adapters had been written to Oracle ERP. The long-term history of software acquisition clearly demonstrates that as the price of software goes up, development of the application stalls, and in many cases, the application is subsumed into what is often an inferior application. There are several cases where the acquired application is mostly eliminated. But the acquiring company also acquires the customers and is able to increase their prices now that they have removed a competitor from the marketplace. Software acquisitions have only two winners:

  1. The Acquiring Company: They eliminate a competitor.
  2. The Senior Members of the Acquired Firm: They receive a handsome buyout as compensation.

Despite promises on the part of the acquiring vendor, often the reality for integration does not change much after an acquisition. For example, many of these software vendors already had adapters that connected to Oracle ERP. However, the acquisitions allowed Oracle to increase the price of the acquired application because they became part of the “Oracle Suite.”

As a result, companies that implemented ERP are essentially back where they started before the move to ERP, except now they rely more on external application development through commercial software rather than internal application development. While buying companies were sold on the idea that ERP would take a “blank sheet of paper” approach, to the present day companies still have complex landscapes with many applications that have separate databases and separate hardware and are interfaced, but not integrated—just like before the whole ERP trend began. Promises of a single integrated system simply never came about.

One Size Fits All

One of the original arguments used to sell ERP systems was that the standard functionality of the ERP system could be used “right out of the box.” But as ERP systems are customized so regularly, this sales pitch has long since been forgotten. Not only was this assumption wrong, but it was also fabulously wrong. According to research by Mint Jutras, around 96 percent of respondents to a survey stated that they did moderate to extensive customization to their ERP systems. This has been my experience on projects as well, but I can say with confidence that most companies that purchased ERP systems had no idea they would eventually customize their ERP systems to the degree that they did.

I once had a defense contractor as a client. They discussed their interest in replacing a system that connected to the Department of Defense. At first, it seemed as if we could take the logic for the system and port it to SAP ERP. However, the more we analyzed the application, the more it became apparent that this application was so specialized and had taken so much time and effort to build that the best course of action was simply to keep the system but integrate it into SAP ERP.

It looks much easier to decommission software when you do not personally use it and are not aware of everything that it does. Over the decades, many companies have gone through this identical process. Very little is written on the subject of system replacement errors, which led IT decision-makers to underestimate significantly the degree to which companies faced this issue of being unable to decommission systems that were performing essential tasks. And to overestimate how well the ERP implementations at other companies were faring. Companies bought ERP, often without knowing how specialized their applications were, and they ended up having to integrate many more systems to the ERP system than they had expected, as well as to customize their ERP systems more than they ever anticipated. As a result, their ERP systems consumed a much higher percentage of their IT budgets than forecasted.

All of the above happened, but to a much larger degree, on the Air Force’s Expeditionary Combat Support System (ECSS) initiative, a now-notorious program to take all of the Air Force’s support systems (two hundred and forty legacy systems) and move them to Oracle ERP, which we covered in the following article.

Planning for the Inevitable Customization

Unanticipated customization significantly increases implementation costs and durations. It also means long-term and largely unplanned maintenance as the customized ERP systems face issues caused by each new version (or at least major version) of the ERP software released by the vendor. The customization required for ERP systems has demonstrated that these systems are simply starter kits rather than entirely usable systems. Companies went to the tremendous expense to do nothing more than replicate functionality that was, in many cases, working perfectly well and meeting requirements in the legacy applications that ERP salespeople criticized as archaic. The reality is that the ERP salespeople had no idea what they were talking about. Most had never worked in the field of software implementation and, like trained parrots, were repeating catchphrases. It is the height of arrogance to state that you “know” that the functionality in your software is better than the functionality residing in a customer’s system when you have never seen nor analyzed their system and probably would not understand it if you did.

ERP’s Operational Improvement

One of the logical arguments used to sell ERP was that it would improve the company’s operations. I was able to find several studies that showed a correlation between operational improvements in a company and ERP implementations. A quotation from one of these studies, Which Came First, IT or Productivity, says the following about operational versus financial performance.

“Our results demonstrate that ERP adoption strongly infl uences operational performance (inventory turnover, asset utilization, collection efficiency) and labor productivity but has a negligible impact on measures of financial return or profitability.”

This is a bit of a paradox. Shouldn’t improvements in financial performance evidence improvements in operational efficiency? The study ERP Investment, Business Impact, and Productivity Measures says the following about productivity and brings up some interesting issues in terms of when the productivity is measured.

Given that most of our data is before and during implementation, this suggests that higher performing firms tend to adopt ERP and that their performance is at least maintained and possibly improved by ERP adoption. Our data does not have many (data) points post implementation. “Our results on performance analyses using the same specifications previously, consistently show that firms have higher performance during the implementation than before or after.

“It also suggests that the paybacks begin to appear before the projects are completed—probably the most reasonable interpretation is that many of the components of an ERP adoption are completed and operational before the firm declares the project to be complete.”

In all likelihood, this statement is not true. Companies declare their systems “live” as soon as they can, and rarely does it happen that the systems are operational but not declared “live.” More commonly, the system is announced live before the implementation is complete. Much fine-tuning is required post “go-live” to get the applications working as needed. Frequently I am part of a team that tunes live projects.

“Alternatively, it could be that many of the ‘belt-tightening’ organizational changes such as changes in inventory policy or reduction in the number of suppliers begin to generate gains fairly quickly, even if the more technical aspects of the project have not yet been completed.”

Other alternative explanations for the productivity gain during the implementation could be the “Hawthorne Effect.” The Hawthorne Effect is when subjects in a study improve their performance because they know they are being observed. The researchers do not mention this as a possible reason for the post-go-live performance improvement, but it is quite obvious and likely explanation.

“There is a productivity gain during the implementation period, followed by a partial loss thereafter. When value added is used as the dependent variable, the gains are 3.6 percent during implementation with a loss of 4.7 percent for a net gain of –1.1 percent (t= .8, not significant).”

I list the Hawthorne Effect as a likely reason for the gain during the implementation because the software is not yet operational; therefore, the benefit cannot be from the software itself. Regardless of the reason, the short-term gain in productivity— followed by an overall loss of productivity—is not a happy ending or a compelling reason to purchase an ERP system. When the actual benefits of ERP are evaluated (evaluated from any dimension one cares to choose), the fact that ERP is seen as a “mandatory infrastructure”—as stated in many articles and as is generally accepted in companies—does not seem to compute.

Should SAP Come Clean on How Much SAP ERP Relies on Excel?

In the original presentations from SAP, R/3/ECC was primarily about work in the application. Customers were not told, even after the evidence was quite clear that users would be using ECC in combination with Excel, that it is how the system would be used. The number one way to report and do analysis in ECC? Yes, that would be Excel. ECC has been fantastic for creating external spreadsheets. It seems that Microsoft does not get enough credit for ECC being able to function.

What Was Promised?

In research, it is essential to evaluate what was promised, and then what happened. One does not view a discrepancy between promise and outcome and disregard it unless there is no research motive. Moreover, SAP salespeople and consulting companies routinely understate how much ECC relies upon external systems to customers. You don’t even hear the word Excel on SAP presentations. Its as if ECC does everything.

Advice on Enjoying the ERP Quiz

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

Conclusion

ERP systems were, in essence, a simplistic platitude that was appealing. Remember, the first sales pitch of ERP was that it was the only system you would ever need. So ERP systems were sold with a sophistication similar to razors or coffee. Over decades the logics presented to sell ERP have turned out to be universally untrue. However, because the media entities and consulting firms and other pro-ERP sources never performed a post mortem, these false logics are used to sell ERP systems to this day.

As a principle, it is foolish to be impressed with a system because it is bundled. It is also unwise to try to single-source most of your software from one vendor. However, Gartner was happy to sheepdog customers to SAP vendors….for the right price (payments from vendors).

SAP customers are finding out with indirect access claims and continually increasing support costs, that the more leverage the vendor has over you, the worst you will be treated over time. SAP ERP systems do not have an ROI, and that negative ROI is going to grow as SAP continues to harvest more and more out of their customers. And the customers are now trapped because they have a vendor they over-relied upon, thinking they would have fewer headaches by concentrating their vendor spend.

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.

 

Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.

References

The History of ERP Systems

Executive Summary

  • The history of ERP systems is normally misrepresented by those with software to services to sell.
  • Find out the real story around ERP history.

Introduction

I find it amazing that there is so little information about the history of ERP, other than a few short articles on the Internet and the paper ERP: A Short History, by F. Robert Jacobs and F.C. Weston Jr. in 2007 in the Journal of Operations Management. It is curious, but I can come to no other conclusion than this: very rarely have ERP systems been put under the microscope.

The articles on ERP tend to accept all of the initially proposed benefits of ERP as if they were true, and almost all of the materials written about ERP systems since ERP systems were first introduced (outside of academic materials) have been promotional in nature. The articles have not demonstrated historical knowledge and certainly are not scientific in their orientation (that is, based on evidence and/or testing). Book after book, and article after article, promote ERP and provide advice about improving ERP implementations—yet never do the authors question the benefits of ERP. The influence of ERP has been so great and has so strongly impacted the structure of the enterprise software market (in addition to impacting the decisions that are made by companies outside decisions about ERP itself), that ERP as a topic really deserves a comprehensive written history. What follows is not that comprehensive history by any means, but enough of a background to support the analysis presented in the following chapters.

What is ERP?

Conceptually, ERP is a combined set of modules that share a database and user interface, and that supports multiple functions used by different business units.10 Because the ERP modules use a single database, employees in different divisions (e.g., accounting and sales) can rely on the same information for their specific needs and without any time lag. ERP covers what is sometimes considered a company’s “core” business processes. These processes are mirrored in the four basic modules of SAP’s ERP system:

  • Sales and Distribution
  • Materials Management
  • Production Planning
  • Financial and Controlling

ERP Gets its Start A bill of materials (BOM) is the listing of components and subcomponents that make up a finished good. The first enterprise system in which the BOM was encapsulated was the material requirements planning system or MRP system for short. Major MRP functionality is shown in the following graphic.

MRP Versus ERP

I will use the term “MRP” a number of times in this book, and you may notice that MRP sounds very similar to the term “ERP.” This is not a coincidence; ERP is actually based upon the term MRP, although, as we will see, it is not a particularly descriptive term for what ERP actually does. MRP software predated ERP software by more than a decade, with MRP systems beginning to be implemented in the mid-1970s and ERP systems beginning to be implemented in the mid-1980s. At one time, MRP systems were sold as standalone systems, and there were around thirty competitors in the market. Many ERP vendors acquired MRP vendors and began to include this software as part of a broader integrated offering.

In its earliest incarnation, ERP software was known as “business systems” software. Prior to the change in terminology, vendors of business systems were simply growing the footprint of their applications; it was actually the IT analyst firm Gartner that began referring to these systems like Enterprise Resource Planning, or ERP. However, as previously stated, in time, the MRP software vendors became subsumed within ERP suites primarily through mergers and acquisitions.

“In the early 1980s, MRP expanded from a material planning and control system to a company-wide system capable of planning and controlling virtually all of the fi rm’s resources. This expanded approach was so fundamentally different from the original concept of MRP that Wight (1984) coined the term MRP II, which refers to manufacturing resource planning. A major purpose of MRP II is to integrate primary functions (i.e., production, marketing and fi nance) and other functions such as personnel, engineering, and purchasing into the planning process. “A key difference between MRP II and ERP is that while MRP II has traditionally focused on the planning and scheduling of internal resources, ERP strives to plan and schedule supplier resources as well, based on the dynamic customer demands and schedules.” — Planning for ERP Systems: Analysis and Future Trend

The dates in the above chart are estimates of when these technologies became broadly used, not when they were first developed. MRP is a method of performing supply and production planning.

The Simplicity of MRP

MRP is quite simple and requires nothing more than elementary arithmetic to perform its functions.12 The software processing requirements are quite low. For instance, while a supply and production planning problem will take hours to run using more advanced methods, MRP can be run for the entire supply network in just a few minutes. Even two decades after the rise of advanced supply chain planning software, MRP is still the dominant procedure/method used in companies around the world for supply and demand planning. MRP is also run in external supply chain planning applications; however, the vast majority of MRP planning runs that are performed today are performed in ERP systems. Let us look at two graphics that succinctly explain how MRP works.

For procured items, MRP converts forecasts and sales orders into purchase orders and production orders with the right dates so material can be brought in on time to support demand. Additionally, the purchase orders and production orders are batched (that is, they are not necessarily in the same quantities as the sales orders) in order to meet order minimums and to create economic order quantities.

Both MRP for procured items and MRP for manufactured items are inbound methods. There is also a method for outbound planning, which is called DRP (distribution requirements planning. I won’t get into DRP here, but I do explain the history of it in the article The History of MRP and DRP.

The Focus of ERP Systems

The relationship between MRP and ERP systems that I have described up to this point could easily lead one to believe that ERP systems were first designed to meet the needs of supply chain management. However, the opposite is true. In fact, ERP systems were actually designed first to meet the needs of finance and sales, and to a lesser degree, manufacturing and supply chain management. When one compares the functionality depth in the SAP ERP modules of Sales and Distribution (SD), Material Management (MM), Production Planning (PP), and Finance and Controlling (FI/CO), FI/CO has by far the greatest depth in functionality.

The major selling point of ERP systems was not that these systems provided particularly good functionality in any operational area. In actuality, they provided very basic functionality in all areas (I will address the notion of best practices in Chapter 4: “The Best Practice Logic for ERP”), but anything that occurred in operations was immediately reflected on the accounting side because all of the applications shared the same database. It was an argument tailor-made for executives: they would never have to deal with the functional limitations of ERP systems personally. That is the common issue when the individuals who buy items are different from the individuals who use the item. Anyone who has had to use a centrally purchased corporate laptop should have no problem understanding this.

However, as we will see further on, companies eventually paid for accepting the assumption that functionality did not really matter all that much, as long as all the applications were integrated.

Why Are ERP Systems Called ERP?

The first system that is recognized to be ERP was an enlargement of an MRP system. This was the IBM MMAS system. However, in an interesting historical turn of events, IBM never became a major player in the ERP space even though they had the first ERP system.

“In 1975 IBM offered its Manufacturing Management and Account System (MMAS) which Bill Robinson from IBM considers a true precursor to ERP. It created general ledger postings and job costing plus forecasting updates emanating from both inventory and production transactions and could generate manufacturing orders from customer orders using either a standard bill of material or a bill of material attached to the customer order.” — ERP: A Short History Gartner is credited with naming ERP systems.

The term “ERP”—Enterprise Resource Planning—was adopted from the term “material requirements planning” (MRP) or “manufacturing requirements planning” by simply replacing the “M” with an “E.” 14 This was done because, in addition to containing the MRP supply and production planning method, ERP systems also contained sales, financial accounting, and materials management functionality. Gartner found itself analyzing what appeared to be a new software category, and they needed a way to broaden out the terminology in a way that was more descriptive than “business systems.” Additions to the MRP functionality made the application include more than just material or manufacturing, and expanded it to the entire “enterprise.”

ERP Begins Its Life with an Illogical Name

I was unable to find whom at Gartner actually named ERP. The term, although wildly successful, unfortunately, is also inaccurate. Naming ERP systems after MRP made little sense because MRP is just one small component of what ERP does. Furthermore, ERP systems have little in the way of actual planning functionality, and instead, are transaction processing systems. They are designed to do things like accept sales orders, create purchase requisitions and convert them to purchase orders, and then connect every transaction to the financial module. If anything, ERP systems were and continue to be the exact opposite of planning. ERP systems are generally known as “execution” systems. This is one reason why companies, after completing their ERP implementations, connected external supply chain planning applications to ERP to replace ERP’s limited planning functionality. On the finance side, “planning” is not performed in the ERP system. Instead, the data is exported to a flat file and opened in a spreadsheet or exported to a reporting application. Regardless of the area in which the analysis is performed, the best way to actually perform planning is to export the data from the ERP system. In reality, ERP systems just tell companies what already happened, for use in planning for the future.

ERP Limitations

Companies found that planning was only the beginning of ERP’s limitations. ERP is now well known for many limitations in its ability to present analytical data to customers. The shortcomings of ERP in this regard are a strong precursor to the growth of the separate business intelligence market, a market that was not supposed to have developed if the original projections by proponents of ERP had come true—that all reporting would be done within the ERP system. What was once known as “reporting” was renamed “business intelligence” to make it sound more appealing and leading edge. After all, “reporting” is boring…but “business intelligence” is leading edge. Business intelligence requires data to be extracted from ERP systems and placed into business intelligence repositories and performs the reporting from these off-line repositories.16 This point is reinforced by the following quotation from Craig Sullivan of NetSuite, a vendor of SaaS ERP and other things.

“Stone-Age ERP was designed when businesses were top-heavy in general administration—when it was standard practice to have someone assigned to rekeying purchase orders or time and expense entries. Today, any unnecessary bureaucracy just wastes time that could be better spent elsewhere.”

Most ERP systems have not evolved past their humble roots, and to the disappointment of many companies that own ERP systems, many ERP systems have essentially stabilized. Stabilization is a development term that means only minimal improvements are being made to the system, as explained in the following quotation.

“Our point is that current ERP technology provides an informationrich environment that is ripe for very intelligent planning and execution logic, yet little has changed since the late 1970s in the logic associated with such applications as forecasting, reorder point logic, MRP, production scheduling, etc. The current systems are now just executing the old logic much faster and in real-time. The area is ripe for innovative new approaches to these old problems. This may include partnering with our business counterparts who live in this dynamic environment on a day-to-day basis.” — ERP: A Short History

The Reality of ERP

“The preponderance of corporate pain lurking throughout the lifespan of a traditional on-premise ERP suite is unequivocal. To wit: ERP projects have only a 7 percent chance of coming in on time, most certainly will cost more than estimated, and very likely will deliver very unsatisfying results. In addition, today’s enterprise has little better than a 50 percent chance that users will want to and actually use the application. Poor application design just adds to the turmoil. In sum, ‘ERP success’ has become a very subjective metric.”Why ERP Is Still So Hard

What is ERP Implementation History?

Only rarely is the actual success rate of ERP implementations quoted. According to the publication, The Critical Success Factors for ERP Implementation: An Organizational Fit Perspective, the success rate is roughly 25 percent. So, according to this source, 75 percent of ERP implementations are considered failures. But quoting just one study is misleading because the estimates are truly all over the map, as the quotation below attests.

“A study by the Standish Group estimates that 31 percent of projects are not successful (Kamhawi, 2007). Barker and Frolick (2003) suggest that 50 percent of ERP implementations are failures. Hong and Kim (2002) estimate a 75 percent failure rate, while Scott and Vessey (2002) estimates failure rates as high as 90 percent. Different statistics for the success or failure of ERP projects have been offered by researchers. In addition Bradford and Sandy (2002) reported that 57 percent of the companies they interviewed had not attempted to assess the performance of their ERP systems owing to a lack of empirically effective evaluation models.” — Measures of Success in Project Implementing Enterprise Resource Planning

Stupidity Disguised as Consulting Advice

One of the ridiculous arguments I’ve heard is that ERP implementations are so difficult that companies that manage to pull them off gain a competitive advantage over other companies. In this incarnation, the ERP system is presented as something akin to the Ironman Triathlon, where the implementing company proves its toughness by running the gauntlet.

It is a ludicrous analogy, which, as far as I am aware, is unique in the field of enterprise software where ease of implementation—rather than the difficulty of implementation—is considered a virtue. And in fact, the argument is edging extremely close to circular reasoning: ERP is virtuous because it is difficult to do, and it is difficult to do because it is virtuous. It is also one of the few times that a high failure rate is presented as a positive attribute of a software category.

One can imagine airport advertisements like this, which focus on ERP’s character-building qualities rather than on its negligible benefits. What is interesting about the problematic implementation record of ERP is that it never seemed to quell the insatiable desire of companies to continue to implement ERP systems. Nothing should ever be accepted as a course of action because “it is hard.” If difficulty irrespective of a beneficial outcome is being promoted, then some type of scam is at play. 

This is the main takeaway: ERP was so quickly established as a mandatory application suite that not even gruesome stories of ERP failures and cost overruns could mitigate the desire for ERP implementations.

What is the Satisfaction Level with ERP Systems?

Discussed much less frequently is how effective ERP systems are in helping companies achieve their objectives after the systems are live. It turns out that the satisfaction level with ERP systems is low.

“Pretty much no one is really satisfied with the state of their ERP. Only 23 percent of users would recommend their ERP system to another enterprise. The truth is that ERP has been placed on the backburner because of the recession and manufacturers have suffered because of it.” — Old and Bad All Over Manufacturing

My research into ERP continually reinforced a central concept: very rarely does ERP impress the companies where it is installed. Who really promotes ERP systems as good? This is exclusively the province of ERP vendors and consulting firms. With customers, ERP tends to be discussed in terms of being a rite of passage.

  • ERP is also commonly referred to as a “standard.”
  • But the adjective “good” does not seem to surface much in discussions about ERP systems.

Of the ERP systems that I have worked with—and these systems are the more popular systems—I would say that none of them have impressed me. Furthermore, multiple aspects of the ERP system displease companies; common complaints include the following:

  1. Stagnant Applications: There is a perceived lack of innovation on the part of ERP vendors. It is increasingly apparent that many ERP vendors are funneling their support revenues into other applications, leaving their existing ERP customers with dated applications.
  2. Costs: ERP buyers frequently mention the high costs of upgrades and support.
  3. ERP Inflexibility: The inability of ERP systems to be adjusted is a constant constraint that companies must work within.
  4. Missing Required Functionality: The inability of ERP to meet a company’s business requirements, which leads to the following point.
  5. Customization: There is a constant need to customize the ERP system, leading to another complaint: the expense to upgrade ERP systems. In a properly functioning media system, these types of issues would be the topic of more articles and better explained.

The Obvious Question

Software buyers should ask the following obvious question:

If ERP software vendors and consulting companies made all of these projections for how ERP would help companies, at some point shouldn’t an investigation into the actual benefits of the software category be performed, particularly when it is the largest enterprise software category? Whose interests do the IT media support: the software vendors or the buyers? The IT media was instrumental in building up demand for ERP software and in serving as an echo chamber for software vendors and IT consultancies.

ERP and Account Control

The history papers that I reviewed for this book left out the fact that ERP was yet another attempt (and one of the most successful attempts by software vendors in the enterprise software space) to take control of clients. Each vendor replaced many of their client’s applications with ERP and then used their leverage as the ERP provider to sell more applications to these semi-captive companies. Mediocre systems were justified on the basis that they were at least integrated and that having poor functionality in an integrated system was better than a nonintegrated system that provided the business with the functionality they needed to get their job done. ERP had a second impact in that several vendors became extremely well-positioned to sell other types of software.

The Outcome of the ERP Boom

Two of the most powerful vendors were created through the ERP boom. One was SAP, which is the most successful ERP company and which parlayed this success into other enterprise software areas. Currently, SAP stands as the largest enterprise software vendor in the world, and the second is Oracle, which extended its reach from the database into the application software realm with ERP software. From their dominant position in ERP, these vendors acquired a number of software companies that were effective at growing the company (although usually bad for the acquired software itself, as well as for the customers).

SAP and Oracle have ridden the “ERP wave” and owe much of their current central position with customers to their role as the provider of the customers’ ERP system. Both companies are “Peter Principled” control enormous faceless conglomerates that neither company has the competence to manage intelligently, and serve as liabilities for all of their customers. SAP and Oracle are followed by companies like Infor and Epicor, and other ERP vendors whose primary organizational goals are to match the account control enjoyed by the ERP market leaders.

How to Understand ERP as The F-22 of Enterprise Software

The F-22/F-35 fighter program is a massive waste of taxpayer dollars that can’t be stopped because of Lockheed Martin’s lobbying.

ERP systems have a great deal in common with the F-22/F-35 program.

In the book The Real Story Behind ERP: Separating Fiction from Reality, I explained something that no major IT consulting company or ERP vendor would want to get out. That is that the consensus of all the academic studies into ERP shows that ERP systems do not show a positive ROI.

However, particularly for ERP systems from the largest vendors, ERP systems have shown an even more nefarious outcome than simply having no ROI themselves. This is that the ERP system is used by the software vendors and the consulting companies to direct IT purchases into other inefficient areas as well.

Understanding the F-22

The F-22 fighter is a long-running exorbitantly expensive initiative to develop the next-generation fighter for three branches of the US military, which began all the way back in 1991.

  • Twenty-seven years later, the F22 costs roughly $68,000 per flight hour.
  • The F-22, while having been featured in movies, has barely taken part in any military action. The F-22 is a stealth aircraft, but for a publicity stunt, it has been used occasionally to bomb Afghanistan — a country without radar.
  • The F-22 has a massive logistics tail and unending reliability problems.

However, the proposal was that all of this would work out because it would go into the F-35. As explained in the video below, this was always a deception developed by those trying to keep the program alive.

As the video above explains, the fact that the F-35 is of little use, but its continued purchase cannot be stopped.

Lockheed Martin, as with ERP vendors, issues simplistic platitudes to support the F-22 and now F-35. One is that the planes provide jobs, but of course, any plane produced would also provide jobs. Therefore it need not be a bad plane. Second, Lockheed Martin has conflated support for the F-22 and F-35 with patriotism. Good patriots who love America want to get ripped off by Lockheed Martin and field the most wasteful fighter jet ever produced in the history of humankind. Americans who want a better value are unpatriotic and may not love America sufficiently.

ERP vendors, and their partners in crime, large consulting companies follow similar approaches in establishing ERP systems as the only option. “Everyone agrees” that ERP systems are necessary and are the “digital core” (as proposed by SAP). And something that all the people who agree with this have in common is that a) they sell or otherwise financially benefit from ERP systems, or b) they have never analyzed the issue in a sufficient level of detail to develop an informed viewpoint on the topic.

Quotes from Scientific America on the F35

Like ERP, the F22/F35 has been relentlessly pitched by those that either make ERP or make money off ERP using exaggerated claims. With respect to the F22/F35, this is explained in the following quotes.

“The company building the F-35 has made grand claims. Lockheed Martin said the plane would be far better than current aircraft – “four times more effective” in air-to-air combat, “eight times more effective” in air-to-ground combat and “three times more effective” in recognizing and suppressing an enemy’s air defenses. It would, in fact, be “second only to the F-22 in air superiority.” In addition, the F-35 was to have better range and require less logistics support than current military aircraft. The Pentagon is still calling the F-35 “the most affordable, lethal, supportable, and survivable aircraft ever to be used.”

But that’s not how the plane has turned out. In January 2015, mock combat testing pitted the F-35 against an F-16, one of the fighters it is slated to replace. The F-35A was flown “clean” with empty weapon bays and without any drag-inducing and heavy externally mounted weapons or fuel tanks. The F-16D, a heavier and somewhat less capable training version of the mainstay F-16C, was further encumbered with two 370-gallon external wing-mounted fuel tanks.

In spite of its significant advantages, the F-35A’s test pilot noted that the F-35A was less maneuverable and markedly inferior to the F-16D in a visual-range dogfight.

Lockheed Martin and the Pentagon say the F-35’s superiority over its rivals lies in its ability to remain undetected, giving it “first look, first shot, first kill.” Hugh Harkins, a highly respected author on military combat aircraft, called that claim “a marketing and publicity gimmick” in his book on Russia’s Sukhoi Su-35S, a potential opponent of the F-35. He also wrote, “In real terms an aircraft in the class of the F-35 cannot compete with the Su-35S for out and out performance such as speed, climb, altitude, and maneuverability.”

Other critics have been even harsher. Pierre Sprey, a cofounding member of the so-called “fighter mafia” at the Pentagon and a co-designer of the F-16, calls the F-35 an “inherently a terrible airplane” that is the product of “an exceptionally dumb piece of Air Force PR spin.” He has said the F-35 would likely lose a close-in combat encounter to a well-flown MiG-21, a 1950s Soviet fighter design. Robert Dorr, an Air Force veteran, career diplomat and military air combat historian, wrote in his book “Air Power Abandoned,” “The F-35 demonstrates repeatedly that it can’t live up to promises made for it. … It’s that bad.” – Scientific America

Continuing the Undending Fiasco that is the F-22 and F-35

ERP is eerily similar to the F-22 and F-35 not only in the inability to meet exaggerated claims but in how it has created a great number of financially biased entities that support it. For the F-35, the proponents of the fighter are the politicians in the various states. The customer is the normal US citizen (ostensibly who is purchasing defense), i.e., the taxpayer. However, the decision-maker is different than the taxpayer. The politician is far more focused on their political career than defense overall. Many years after the JSF was conceived, and with the development of drones (which often run around $5,000 per flight hour), there are many who question whether the F-35 has any reason for existing. But this does not matter to the US politicians that seek to direct revenues to their states.

Lockheed Martin need only make payments to the right politicians and then set up the F-35 so that most US states receive income from the F-35 (right now 46 out of 50 states do).

This is enough to have the F-35 continue to be purchased, regardless of whether it is a good fighter or a good value for US taxpayers.

The video uses the term “political engineering” to describe how Lockheed Martin continues to receive funding for the F-35.

The Political Engineering of ERP

ERP has its own proponents. While ERP is a poor value for most companies that have implemented ERP (as explained in the book The Real Story Behind ERP: Separating Fiction from Reality), ERP is very good for the largest consulting companies. These consulting companies are very high in recommending ERP systems. Normally ERP systems from the largest vendors like Oracle and SAP, but especially SAP.

The lesson from the history of enterprise software history is that consulting companies don’t much care what the right software for their clients to purchase and implement is. They are in it to maximize their own billing hours. Therefore, they will recommend the software categories and the vendors within each category that maximizes their revenues. The longer your software takes to implement, and the worse value the software is for the end customer, the more the large consulting companies will sing your praises!

The clients of consulting companies don’t seem to recognize that nearly all of the consulting company’s “recommendations” are determined by working backward from self-interest. 

In the Vox video, it states.

“Despite deep design flaws and constant problems, there have been no serious efforts to cancel or scale back the project.”

This quotation was referring to the F-35, but it applies equally to ERP systems. Once in place, ERP systems take on a life of their own.

Lack of Oversight

ERP systems are typically implemented by large corrupt consulting firms. They do not allow any independent entity into the company to evaluate the process. If a client asks for this, the consulting firm will state that

“They already do that.”

ERP implementations are normally so filled with waste that they have similarities with a US defense contract, which also has very little oversight and enormous cost overruns as a normal course of business. This reduction in oversight in the US defense contracting is described in the following quotation from a comment on an article in the blog BIG by Matt Stoller.

Lockheed did let me have as much time in the F35 plant as I wanted.  And, I had free reign to talk to anyone.  I was totally appalled by what I saw.  It was clear that the rate of production promised would not be accomplished with the plant as designed.

Even more disturbing was that there was complete lack of DoD oversight – none.  There were no DoD engineers in the plant.  Back in the Pentagon I asked to meet with the procurement people who were in charge of DoD industrial policy.

There had been such a thing during the time when DoD did not take 35 years to produce an AC that still does not meet it design objectives and did not cause pilots to pass out – the F35.  I was told that the lack of an industrial policy is an industrial policy.  Around that time the administration changed from Bush to Obama and the situation only got worse.  I let it go and continued my job while continuing to see the inside. – BIG

Pushing Customers to Reinvest in Low or Negative ROI ERP Systems

ERP vendors continually reinforce investing more back into the ERP system. This can take the form of unnecessary upgrades. Increasing support costs, customization, remediation, etc..

The Example of S/4HANA

For the past three years, SAP has been telling a wide variety of lies about S/4HANA in order to…you guessed it, get companies to redirect even more money into ERP, even though companies that do this will have little hope of getting this investment back. S/4HANA is an amazingly brazen example of how many ERP vendors harvest their accounts in that SAP’s demand that customers pay for what is merely an upgrade to ECC and should be covered by SAP’s 22%+ yearly software support fee. (we covered this topic in the article Why S/4HANA Should be Free). SAP does not worry about their claims about R/2, R/3 and ECC not coming true, they have simply pushed the claims forward to S/4HANA.

For example, SAP has stated that running MRP and end of period close is really horribly problematic in ECC, and therefore companies should move to S/4HANA. However, curiously, when SAP was selling companies on moving to ECC, they did not, at the time, point out how horribly ECC was in these two processes.

Statements made by both SAP and other ERP vendors win our Golden Pinocchio award. The intent is to make it seem as if everything the ERP vendors offers is “naturally integrated,” and that other vendor that connects to their ERP do not also use adapters. 

How ERP Vendors Overstate the Integration Argument

ERP vendors use their relationships with customers to push their customers to purchase other non-ERP software that they offer, arguing that while it may not be competitive in its own right, at least it is “integrated” back to the ERP system. This argument dilutes the most important aspects of the software that should drive any software purchase, which is the quality of the software, combined with how well that software matches the business requirements of the customer. It is also misleading because ERP vendors use an adapter to connect their non-ERP to ERP systems, in the same way that non-ERP vendors do.

This results in large amounts of mediocre or worse software that has been acquired by ERP vendors, only being selected because it happens to be owned by the ERP vendors. Not because it is good software, and not because it meets the business requirements. Therefore the ERP system cannot be looked at in isolation from its impact on the rest of the company’s IT landscape. While, as was pointed out already, the studies point very clearly to ERP systems not having an ROI, ERP systems also reduce the ROI of the other systems that a company purchases. This is accomplished through the way that ERP redirects purchases away from competitive applications to the applications that the ERP vendor happens to have in their stable.

When taken as a whole, this means that it is the case the ERP has a substantially negative ROI when this larger effect is taken into account. These types of analyses are not done in the industry. The assumption is that ERP has a positive ROI. A positive ROI that has never been proven. Therefore the analysis of the impact of ERP on the ROI of related applications is beyond the industry’s ability to process or even analyze properly. 

The IT organizations within companies that are often more interested in keeping the number of software vendors to a minimum push for what is most cases the worst software for the business inside of their companies to use, so they can both deal with fewer vendors. Another prime motivator is so the IT decision-maker can show their allegiance to specific vendors to which they frequently have more loyalty than to the company they receive their paychecks.

Maintaining a Portfolio of Applications that are Not the Expertise of the ERP Vendor

This has caused ERP vendors to maintain broad portfolios of applications that normally are not adept at maintaining. That means acquiring applications that they have no business acquiring. SAP is an excellent example of this. SAP has really only ever demonstrated competency in ERP, yet they maintain a broad portfolio of bad applications that have nothing to do with ERP. Applications that get acquired by ERP vendors to “broaden the portfolio” become less prominent over time.

Driving Industry Consolidation

ERP vendors have, in many cases, acquired other non-ERP applications, specifically, so they could force these non-ERP applications into their accounts. And thus, ERP has been a force of consolidation in the enterprise software market, making the overall market less competitive.

Along with the consulting companies, many directors and VPs of IT have an incentive to keep up the high investments into ERP for career reasons, which means that ERP continues to soak up resources, further decreasing its ROI from neutral to negative, to steeply negative.

Advice on Enjoying the ERP Quiz

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

Conclusion

Conceptually, ERP is a combined set of modules that share a database and user interface, and which supports multiple functions used by different business units. Because the ERP modules share a single database, employees in different divisions—for example, accounting and sales—can rely on the same information for their specific needs without any time lag. A major selling point of ERP systems was not that they provided particularly good functionality in any operational area. In actuality, they provided very basic functionality in all areas, but, because the applications shared the same database, anything that occurred in operations was immediately reflected on the accounting side. It was an argument tailor-made for executives who would never have to deal with the functionality limitations of ERP systems personally.

Gartner is credited with naming ERP systems. The term ERP (Enterprise Resource Planning) was adopted from the term “material requirements planning” (MRP) or “manufacturing requirements planning” by simply removing the “M” and replacing it with an “E.” This was done because, while ERP systems contained the MRP supply and production planning method, they also contained sales, financial accounting, and materials management functionality. Companies found that planning was only the beginning of ERP’s limitations. ERP is now well known for many limitations in its ability to present analytical data to customers. The shortcomings of ERP in this regard are a strong precursor to the growth of the separate business intelligence market, a market that was not supposed to have developed if all reporting was done within the ERP system as had been originally projected by proponents of ERP. My research into ERP continually reinforced a central concept that ERP rarely impresses the companies where it is installed. Instead, ERP tends to be discussed as a rite of passage.

Although there is an enormous influence of ERP systems on information technology, remarkably little has been written on the history of ERP. This is for good reason. If history were known, many ERP systems would be reduced in investment, and the reputation of ERP vendors would be irreparably damaged. ERP vendors, the compliant ERP consulting firms, and the paid off IT media and IT analysts make sure that the history stays hidden.

Options for ERP

ERP proponents like to present the idea that there are not options for ERP. In fact, they go a step further. They state that there aren’t real alternatives to whatever ERP they happen to have resources they can bill for. Then after they buy ERP, they tell their customers they don’t have options outside of buying applications from the same vendor that made the ERP system. Consulting companies are very good at leading companies down a restricted number of options, all of which end up benefiting the consulting company itself.

Here is the truth, there are a large number of options to ERP systems, and furthermore, to how any ERP system is used. Here are just a few alternatives — without getting into any specific vendor offerings.

  1. A commercial ERP system can be purchased, but large areas of it unused, and combined with better external functionality.
  2. A commercial ERP system can be purchased, but large areas of it unused and connected to custom functionality/custom applications rather than porting the code to the ERP system (that is not recoding everything in say SAP’s ABAP and porting to the SAP system)
  3. An open-source ERP can be used, and with the large extra pool of money, any number web-based (hosted on AWS or Google Cloud for example) applications can be developed and connected to the ERP system.
  4. ERP can be dispensed with entirely, and a financial solution can be connected to both specialized applications and custom coded applications.
  5. ERP can be dispensed with entirely, and a custom-coded solution can be created which covers financials and other and combined with specialized applications.

These are just five options. Any number of permutations are possible from these options. The evidence of decades of ERP projects heading back to the 1980s is clear; no company of any size or complexity will use an ERP system by itself without support from other applications.

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.

 

Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.

References

https://mattstoller.substack.com/p/how-bill-clinton-and-american-financiers

Thanks to Ahmed Azmi for his contribution to this article.

How ERP System Was a Trojan Horse

 Executive Summary

  • ERP vendors presentation the concept of a single system for everything, and later a fully integrated suite.
  • Neither of these proposals ended up being true. Increasingly ERP looks like a Trojan Horse.

Introduction

ERP fundamentally reconfigured the marketplace of enterprise software and became a significant software category. ERP had a second impact in that it positioned several vendors extremely well to sell other types of software. However, what is rarely discussed is whether the logic that was used to persuade companies to purchase ERP systems has proven to be true over time. This is the topic for this article. In it, I will analyze the primary reasons provided for ERP implementations, and how that logic has held up.

One of the largest trends in enterprise software was ERP vendors acquiring their way into non-ERP applications. (In the case of Oracle, it was Oracle moving into applications overall, purchasing both ERP and non-ERP systems).

A major reason why software vendors have gone on acquisition sprees is due to the resonance of the concept of the single integrated suite.

In this article, we will review the philosophy that integrated suites and gets into more detail than is typically done when this term is used, finishing off by getting into the topic of how ERP systems became a Trojan Horse.

The Single System Logic for ERP

The initial idea behind ERP systems was that it would take many applications and make them a single system – reducing application integration issues.

“Many technical reasons exist including the replacement of disparate systems into a single integrated system (Hitt et al., 2002).”

However, after the major ERP vendors sold the ERP product into companies, they began to develop specialized products for things like supply chain planning, business intelligence, customer relationship management, etc.. This was done for several reasons. One was that there was simply no way that an ERP system, with its simple approach to all functionality – with the possible exception of finance and accounting, could meet all the needs of companies. Secondly, once ERP companies had sold their ERP applications, they needed to develop more applications to grow their sales. Once they had the ERP system implemented, they had the network effect on their side, as the ERP system is the mother ship application for a company, the application or set of applications to which other application must all integrate. This allowed ERP vendors to unfairly compete by telling companies that their applications had a head start in integration to the company’s ERP system. Companies like SAP and Oracle promptly took full advantage of this market power.

This means that they were in a competitive position to be able to sell more software into these accounts. These applications all have their platforms and do have adapters to one another, but are each a separate application, with a different database, sitting on different hardware. This means that companies are essentially back where they started before the move to ERP systems. Except, they now rely more on external application development through commercial software rather than internal application development. This leads to the next point.

The Logic of Cost Reduction for ERP

All of these factors undercut one of the primary arguments that were often used to sell ERP systems, which they would reduce costs. As is explained above, the main reasoning for IT simplification based cost reduction is gone. However, after ERP systems had been sold, that logic conveniently left the building, or declined as a point of emphasis, because after ERP software had been sold, the motivation moved towards selling different types of software. I noticed this change at SAP. Back in the late 1990s, before they had a supply chain planning system, SAP essentially told companies that supply chain planning systems (which duplicated some of the supply chain functionality in SAP R/3, but also offered supply chain functionality, not in ERP systems and provide much more advanced functionality.) were unnecessary. However, after they developed their external supply chain planning system, they changed their tune and proposed that it was now essential.

Business Cost Reduction

The second area where ERP systems were supposed to save companies money was in the standardization of business processes. This has been accepted uncritically, as the quotation below demonstrates.

“It is also one of the most worthwhile initiatives for securing your place in a competitive market. A successful, enterprise-wide implementation will move your company from one with piece-meal business procedures and no overall plan, to a re-engineered organization that is poised to take growth and profitability to a whole new level.”

However, there was never any evidence that this was, in fact, true. Searches for research in this area do not produce studies which show the beneficial effects, or the cost-reducing effects of ERP implementations. However, there are several studies in the area. Interesting quotes have been listed below:

“The benefits of ERP systems are usually overestimated by ERP vendors.”

The Best Practice Logic for ERP

How SAP pushes the concept of best practices is extremely easy to ridicule, as I have done in multiple articles such as here and here. SAP took the initial pitch of best practices from their ERP system sales approach and applied it to other products such as their supply chain planning suite. As an expert in these SAP systems, I can say that any statement regarding best practices in the SAP supply chain planning APO suite is utterly unfounded. Not only does SAP APO not contain best practices, but many of the areas of functionality in APO are a worst practice. After more than that, a decade of opportunity, very few companies has benefited from buying or implementing APO, with companies having a higher likelihood of failure with APO than success. It makes one wonder if the entire best practice logic for ERP ever had any validity. What many vendors call “best practice” often seems to be a code word for “generic” functionality. For instance, many companies would say that posting a goods receipt document after a product has been scanned into a warehouse is a best practice. But is it, or is it merely generic. In the say way, is using a steering wheel to steer a car a best practice? Indeed one could say it is, but it is also now a generic offering.

Furthermore, ERP systems had watered down functionality. This was acknowledged even by ERP vendors, but it was counteracted by improved integration. How such watered down functionality can also contain “best practices” is a mystery.

The Integration Logic for ERP

ERP systems integrated some things, but not all things. And again, because corporate landscapes have so many applications, there is still a lot of integration work that needs to be done. One of the areas of logic for ERP systems was that the company would be better integrated. However, it is hard to see how that is the case, and wouldn’t this improvement show itself in financial performance? As pointed out in a research study into the benefits of ERP.

“In the end, it could be said that previous research suggest that a mixed result exists when analyzing the effect of IT on business performance where some studies supported a positive relation while others suggested that companies adopting ERP did not perform financially better than non-adopting companies (Nicolaou, 2004). It can be also said that the effect of IT on business performance differs from country to country (Pilat, 2004) and should be considered when measuring business performance gains due to IT adoption.

Therefore, previous research has found contradicting findings regarding the effect of ERP systems on business performance. While some researchers have found that ERP systems can affect overall business performance positively, others have only found ERP systems to affect specific areas communications of the IBIMA 6and not the overall business performance. This can then suggest that ERP systems do not always affect business performance positively and some contributing factors affect this relationship (Kang et al., 2008).”

The Real Benefit of ERP Systems

The only demonstrated benefit of ERP has been to the ERP vendors, not to the buyers or ERP software. A purchase of an ERP system is an extremely efficient way to lock in a customer to a vendor and allowing the vendor to sell them other applications.

The Presentation of the Integrated Suite Philosophy

The presentation of the integrated suite philosophy is that integration between applications that are not from the same vendor is complicated. The concept is that while it may be acceptable to give up functionality and fit between the application and the business requirements, it is highly desirable to purchase as much software as possible from a single vendor into order to receive integration benefits.

There are significant holes with this philosophy even though it is quite prevalent.

Virtually All Applications (Integrated Suite or Point Solutions) Are “Integrated”

Here is the standard type of completely integrated marketing hyperbole offered by integrated suite vendors.

“The SAP NetWeaver technology platform is a comprehensive integration and application platform that helps reduce your total cost of ownership (TCO).”

This sentence is inaccurate. NetWeaver never did anything to improve integration on projects and was more marketing construct than an actual product as is covered in the article Did Netweaver Ever Actually Exist?

But this concept was effectively used to push customers to buy from SAP, and customers found out that Netweaver did nothing to reduce integration overhead. The argument before Netweaver offered by SAP was that all of their applications were already integrated. If that was the case, then why was Netweaver necessary.

Unless the application sits on the same database as another application, all applications require adapters. The only applications that meet this standard are the various modules within an ERP system. For example..

  • The sales module of an ERP system sits on the same database as the finance module. In that case, there is no integration.
  • But this is not true of any non-ERP application.

The Reality Around Adapters

Sometimes the adapters are internal to a vendor, and sometimes the adapters are between applications from different vendors.

But, because in many cases the software that is sold as part of an “integrated suite” is from a variety of different vendors, the adapters that you receive from integrated suites are often nothing more than the adapter the acquired application already had when they were part of the pre-acquisition independent vendor.

Furthermore, the idea that being acquired by a more significant software vendor better or more complete adapters to be created is also an oversimplification. There are many stories of integration still being a problem years after an acquisition. In the case of the SAP acquisition of Ariba, Steve Lucas of SAP made a strange statement that we covered in the article The Problems with Diginomica on Steve Lucas on HANA, Oracle, IBM, AWS, and Microsoft.

Steve Lucas made the following statement to Diginomica, that, of course, Diginomica allowed to pass without comment.

“We are integrating that (one of that being Ariba) with our logistics applications, our inventory applications.)”

There is a three year lag between the acquisition of Ariba and this comment by Steve Lucas. How many years are necessary for SAP to integrate an acquisition to SAP’s ERP system?

While researching the book The Real Story Behind ERP, I found interesting information regarding the tactics used to sell ERP software. One of the central arguments used to sell ERP was that it would decrease the need for integration. This turned out to be false but was a primary motivator for many ERP purchases in any case.

A Better Course for Achieving Integration

A much more effective solution than what has been described above would have been if ERP companies had never been allowed to procure other vendors, and if ERP vendors had not created external products, and instead if they had worked to publish to an integration standard and approved the middleware vendors, those that were actually skilled at creating middleware to create the adapters.

Why ERP Vendors Invested Nothing in Publishing Standards

ERP companies had no interested in doing this. Instead, they intended to use their position at their customers to sell in more software, which was often poorly integrated and uncompetitive with best of breed applications. In this way, the ERP companies put their interest ahead of their customers’ attention.

This is explained in the quotation below:

“Of course, as soon as companies began buying these products, it became clear that enterprise software was another chunk–a much larger and better integrated chunk to be sure, but still a chunk–of software in a complex architecture of IT systems that desperately needed to talk to one another and exchange information. The vendors created clunky, proprietary methods of connecting their systems with others that have improved over the years, but that misses the point. The architecture of these systems, in a broad sense, was just like the ones that they were intended to save you from–monolithic, highly integrated and difficult to change.”

After the Acquisition of a Vendor, How is The Integration Story “So Much Better?”

Applications tend to have adapters to the significant ERP systems both to ease the sales process and to speed the integration process. Therefore it is a vast oversimplification to give an integrated suite so much preference over applications that are from different vendors. If a vendor is acquired and already had an existing adapter to the company that acquired it, what changed from the integration perspective due to the acquisition?

We cover this topic specifically in the book Enterprise Software TCO: Calculating and Using Total Cost of Ownership For Decision Making.

“…while many companies like SAP and Oracle lead executives to believe that they will incur minimal integration overhead if they purchase one of their non-ERP applications to connect to their ERP applications, this is untrue. All of SAP and Oracle’s applications sit on different hardware, and while they may have adapters, they are not actually integrated – they have different databases (the term “integrated” is colloquially used to mean any connected systems, but most accurately it means that the systems sit on the same database – when systems have adapters between them, they are not actually technically integrated). The quality and ease of use of these adapters is often not actually superior to the adapters that are written to connect best of breed applications to the ERP system.”

Integrated Suites Tend to be More Expensive in Multiple Dimensions (i.e., Have a Higher TCO)

Integrated suite vendor tends to charge more than point solutions. For example, when IBM acquires an application, one of the immediate effects is for the price of that application to significantly rise. But the change in the price of the application license is only one part of the increased TCO.

Integrated suite is also more often implemented by large consulting companies, which increases their TCO. This is the truest of the largest integrated suites and consulting companies will typically only build consulting specialities around these largest vendors. As soon as the application is implemented by a consulting company, an consulting company makes a practice around the software, the costs vary significantly increase. Consulting companies not only charge more daily than the consultants of software vendors (not in all cases, but most cases) but they also lengthen the implementation duration.

And they do this often against the wishes of the software vendor. This extra cost quickly overwhelms any increased integration costs that come from integrating point solutions to the existing systems at the account.

Integration Suites as a Way to Reduce Competition?

It is no secret that software vendors do not acquire other vendors to increase the competition that they face. Our research into the growth of ERP vendors other associated applications, after ERP vendors told customers that ERP systems were the only applications they would ever need, is covered in our book The Real Story Behind ERP: Separating Fact from Fiction.

“…this has meant that the business does not get the software it needs. Software selection based on software suites does not emphasize each application (emphasis added) but instead emphasizes the suite. As explained in this quote from Christopher Koch of CIO Magazine, software suites themselves are mechanisms that reduce the competition a vendor must face.

“Indeed, integration standards interfere with ERP vendors’ traditional ways of gaining and keeping customers and market share. Before the Web came along, your integration strategy was simple: Buy as many pre-integrated applications from a single vendor as possible. That worked for you, and it worked extremely well for the vendor; integrated application suites fetched a high price and required long- term maintenance and support contracts that promised a steady, predictable stream of revenue from customers.”—ABCs of ERP

How well is that working for companies that bought ERP systems? Did companies find that they were able to eliminate all legacy systems and not use any non-ERP systems?

Integration is Not a Primary Driver of TCO

There is no one else that has performed as much work into TCO as Brightwork Research & Analysis. Our free TCO calculators are available for anyone to use. The poor state of TCO research was uncovered as part of our investigation into TCO, that is the literature review we performed before creating our calculators and writing the only book on the TCO of enterprise software systems. We were not able to find any reliable studies on TCO. Most TCO calculations, for instance, those we analyzed from Salesforce, are created by the marketing department of the software vendor. And “shockingly,” in each case we examined the TCO estimation released by the vendor showed them as having the lowest TCO in 100% of the occasions.

One of the conclusions from our research is that integration is an overestimated cost by both the largest software vendors and the consulting companies that align with integrated suites for their financial reasons. Through recommending an integrated suite, consulting companies can drive their “client” into the highest TCO outcomes.

Consulting Companies Focus on TCO or Set About Maximizing TCO?

It should also be remembered that large consulting companies do not want their customers to know what the TCO of different solutions is. This is because consulting companies like Deloitte or Accenture are significant drivers of the higher TCOs. In our calculators, the highest TCOs routinely came from the purchase of large software suites implemented by the largest consulting companies. The major consulting companies are a primary reason why the ROI on so many application implementations are negative as is covered in How Consulting Firms Parasitized enterprise Software.

An extra benefit of using smaller vendors and more point solutions is that companies like Deloitte and Accenture don’t have resources trained and available in those applications, and the vendor’s consultants typically implement the applications.

How Consulting Companies Undermine any Intelligent Software Selection Process for Their Ends

Consulting companies like to create “uni-crop” software environments which allow them to have large numbers of consultants in a relatively smaller number of applications. Consulting companies overstate their software coverage and resource specialization to their clients on a routine basis. They will often hire independent consultants off of the market (as the client could have done) and then present the independent consultant as if they are a full-time employee, and that represent furthermore, the consulting company was somehow responsible for developing their skills. The consulting firms demand a significant margin on the resources even if they just met the resource a week ago.

Hypothesis Testing

Our risk research into software risk and which calls into question the quality and objectivity of the information provided by large IT consulting companies are covered in the book Rethinking Enterprise Software Risk. The following quotation is from this book.

“Is there a way to test this hypothesis?

The question we had was whether clients that followed the advice of major consulting companies would receive the benefit of lower risk implementations. As it turns out, there is a way to test this question. The applications recommended by the major consulting companies are rated for risk (among other characteristics such as maintainability, usability, functionality and implement-ability) in the Software Decisions MUFI Rating & Risk evaluation. We compared the MUFI Rating & Risk evaluation for applications in ten software categories and compared them to software that the major consulting companies typically recommend.

The research shows that the applications recommended by the major consulting companies always have a high or the highest TCO (total cost of owner-ship) in the respective software category, along with the highest risk. The reason is simple: not a single major consulting company that provides IT services is a fiduciary. This means Accenture, IBM, Deloitte, etc., have no legal responsibility to place their client’s interests ahead of their own. And the internal incentives laid out within each consulting company, where sales is far more esteemed than implementing the software successfully, or even implementing the best software (there is no measure for this whatsoever) means that the customer’s interests are a distant second to the profit-maximizing interest of the consulting company. It is in the financial self-interest of these major consulting companies to recommend software for which they have trained resources ready to bill—therefore it is this software that is recommended.”

How to Misunderstand the Risk of Purchasing More Software From One Vendor

After a detailed analysis of this topic, it is clear that the standard approaches to managing risk on enterprise software selection and implementations such as hiring a name brand consulting company, purchasing name brand software or paying for IT analysts like Gartner do not work. This should be entirely obvious at this point.

Some journalists will mourn the high failure rate of IT projects but will fail to point out the precise reasons as to why. Most of the advice they give and issues they highlight seem to be just nibbling around the edges of the problem. (Actually, most of them can’t because the entities that are most responsible for the high failure rate of IT projects are significant advertisers in the publications they write for). However, the failed approach to risk management is still the dominant approach to managing project risk. This chapter explains why each approach does not work. We will start with one of the most commonly followed strategies.

Purchasing More Software From One Software Vendor

This is an augmentation of the strategy above. However, its logic is primarily based upon integration, which has been historically the “fools gold” in the enterprise software area.

The concept is that the buyer will receive benefits through improved integration if they buy more software from a single vendor. This is covered in the article SAP’s Position on SAP to Non SAP Application Integration. This is one of the most important ways that companies end up with inappropriate and low functionality applications – and in fact, it is one of the primary methods by which large software vendors and mediocre applications compete with and win out against far superior applications. Integration benefits were instrumental in the growth of ERP systems. I quote from my book The Real Story Behind ERP: Separating Fiction from Reality.

“Enhanced integration was one of the major selling points of ERP. The hours of PowerPoint presentations that have been created since the first ERP systems were sold describe the great cost savings and integrative benefits that implementing companies would receive from a “solution” where all the main applications used the same database. One of the assumptions about purchasing an ERP system was that the buying company would implement all of the modules and decommission their current software.

The fact is, some of the company’s pre-existing applications could not be replaced by ERP, and for a variety of very good reasons.

Contrary to most assumptions, ERP systems provide no advantages in terms of integration to other systems, and in fact present several disadvantages:

Here is a much more effective solution than I have described above: ERP vendors should never have been allowed to procure other vendors. They should not have created external applications, and instead should have published an integration standard and allowed the middleware vendors (those that were actually skilled at creating middleware) to create the adapters.”

“ERP technology does not offer an integrated solution but amplifies the need for integration.” — ERP and Application Integration

“Although ERP is touted as a single architecture, ERP applications usually contain different generations and sources of technology. Third-party applications are acquired and amalgamated into the platform, sometimes by name only. In total, this makes the environment complex for the customer and difficult to change over time. ERP suppliers have become system integrators. [emphasis added] The sheer size and number of applications makes moving all the applications forward a difficult task. Application functionality often lags.” — ERP Alternatives

The Validity of the Hypothesis

This turns out, the hypothesis, and it was never anything else than an untested hypothesis no matter how confidently it has been asserted, of selecting more software from one vendor to reduce the integration costs has not worked at all in practice. Those that make the assertion have no research to support their contention. (a hint at we did perform the research, and the assertion turns out to be widely incorrect.) Furthermore, the approach places unnecessary shackles on the software selection process. It has been a primary way that SAP and Oracle have grown to their dominant position, and it has caused many software vendors such as JDA, Sage, and Infor to perform software acquisitions in the hope of providing a full suite of products to customers, steering them to purchase other applications, often based on the software vendor which provides the ERP system. For these vendors, they see the ERP system as the pathway to achieving more monopoly power, and therefore the ability to increase their prices.[1]

The Most Important Feature in the Software Correlated to Implementation Success

This has to lead us to conclude that the most crucial feature of the success of an implementation is the match between the business requirements and the selected software. Not whether the software comes from a single vendor. There can be cases where more than one application purchased from one vendor meets the business requirements of a customer. Still, each application should be able to win in each area on its own merits without having to rely upon the “crutch” of being part of a suite of applications offered by one vendor.

The degree of match is a significant determinant of the overall risk of the implementation. That is pushing for an integrated solution at the expense the fit with business requirements will result in a higher risk that the project either never goes live or that after it goes live the value it provides to the company will be minimal.

An Often Repeated Evidence-Free Assertion

The integrated suite argument, most prominently from ERP vendors is at its essence and the evidence-free assertion that is put forward by integrated suite vendors and reinforced by consulting companies who have a financial interest in repeating and companies like Gartner. They receive the most vendor income from the most significant vendors and who slant their Magic Quadrants in the direction of the most significant vendors.

To provide evidence would require a little work, and the outcome would go in the opposite direction of the assertion. We have provided more evidence against the integrated suite argument in this one article you are reading than has been provided to support the integrated suite argument.

This says a lot about how little assumptions are verified in the IT space.

IT buyers have proven extremely susceptible to misleading simplistic platitudes that are promulgated not because they are true but because they fit the financial incentives of those that promote these concepts. The most prominent IT analysts companies have proven useless in educating IT buyers on these inaccuracies because, in part, they are paid by the largest software vendors and consulting companies to perform well in their various published ratings. 

How ERP Systems Were a Trojan Horse

Enterprise software is an area with an enormous amount of hype, and while some of the hype works out and becomes real, most of the hype does not. That means that most of the hype people are currently exposed to now will not work out. And when I say “work out,” I don’t only mean won’t become popular — because some things can come popular, but don’t work out in that they don’t add value over what they replaced. After the enterprise resource planning system had been purchased, it started gobbling up the IT budget.

It also, and very importantly, narrowed the options of the buyer and put into place a series of false assumptions. That was that the purchaser needed to perpetually consider and give preferential treatment to the enterprise resource planning system when making all other enterprise software purchases.

Using the enterprise resource planning system to preference purchases for other software, the enterprise resource planning vendor offers is what I call horizontal competition, as it is competition within one layer. (For those with an economics background you will recognize the relationship to horizontal integration.)

How Competition in Enterprise Software Works

However, competition for software sales moves vertically as well as horizontally.

  • For instance, Oracle has used its high market share of the database market as a wedge to get into applications (by acquiring many applications vendors and by leveraging its already account management).
  • SAP is currently using its dominance in many of its customers in the application space to push Oracle (and others) out of the layer below by introducing its database.

A great deal of misinformation about the centrality of enterprise resource planning systems has been built up over time which was never proven but merely became part of a set of unexamined assumptions that continues to drive enterprise software purchases. These are unmet promises that are virtually undiscussed.

The ERP System and Horizontal Enterprise Software Competition

In my view, one of the worst things in the history of enterprise software decision making was due to the introduction of the enterprise resource planning systems in the mid-1980s. Before this time, systems that made up enterprise resource planning were sold by different vendors.

Industry Consolidation

Enterprise resource planning software caused lots of consolidation, so much so that after the 1980’s it was uncommon to find MRP vendors that had not been gobbled up and incorporated into an enterprise resource planning suite.

Ignoring The Reduction in Choice

This was sold as a good thing. However, it reduced the choice available to customers because they now had to select an enterprise resource planning suite where the various selections had been already made for them. This feature of enterprise resource planning systems went seemingly unnoticed by IT analysts. There was a tremendous amount of money paid to analysts like Gartner, and they never provided a 360-degree view of the implications of buying so much functionality from a single vendor. Gartner and other analysts promoted the trend to the moon

What is the Specific Comment

Now, I am not commenting” here as to whether enterprise resource planning systems are necessary or not necessary. Instead, I am making a particular comment as to how enterprise resource planning systems have been and continue to be used in what is referred to as “account control.”

What is Account Control?

Account control is a term coined by IBM decades ago, which describes how IBM would use a customer’s previous IBM purchases to control its future purchases and to steer them towards buying more IBM products. It’s not something IBM talks about in public, but it is part of the public record that they discussed this strategy on many internal documents.

The ERP System as the Queen

Quickly following their introduction, ERPs became the queen of the enterprise software chessboard, and once captured, the software vendor who captures this piece was in a position to dictate much of the rest of the game.

This is at its essence anti-competitive behaviour because the enterprise resource planning company is no longer merely competing on a level playing field, but is proposing that it’s other applications be given preference because they “integrate better” with the already purchased enterprise resource planning system. Every monopolist going back since before John D Rockefeller has used control of one area, to establish control in another, most often connecting area.

ERP-Centric Strategy?

Enterprise resource planning vendors used these systems to steer purchases to applications that in a freely competitive arena would have never been bought. In our book The Real Story Behind ERP which was a meta-analysis of every single academic study into the ROI of enterprise resource planning software since the category was first introduced, the book outlines how we could not find a single study that demonstrated a positive ROI of enterprise resource planning systems after go-live.

Overall, this has set back the enterprise software decision ever since. And while it did this, it established a faulty thought pattern in enterprise software decision-makers — and ERP-centric thinking is a consequence of this.

I ridiculed this way of thinking, which I likened to a medical condition in the article Do You Suffer from (ECS) – ERP-Centric Strategy?

Advice on Enjoying the ERP Quiz

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.

 

Conclusion

Those vendors that offer integrated suites universally attempt to make their customers overestimate the degree to which their applications are integrated into one another, and push their prospects to overstate the impact on TCO of application integration. Furthermore, they also minimize the adapters that the point solution providers have created for the major ERP systems.

Therefore the largest software vendors, the consulting companies, and the IT analysts (by in large) push the integrated suite concept as improving implementation outcomes, not because it is true, but because they find it to be profit-maximizing.

The enterprise resource planning system has not lived up to its promises. The entire software category was promoted by and for the vendors and consulting companies that benefited from ERP sales. These entities created the impression that companies “had to have” enterprise resource planning software. However, there was never any evidence presented that this was true. Instead, it was proposed through an endless number of conferences, articles, consulting and vendor presentations.

Based upon pretences, these systems became the queens on the chessboards of enterprise software where they promoted the sale of more software that was often acquired by the vendor. This created higher degrees of concentration in enterprise software and more lock-in and account control that could have been obtained without these systems.

Our research at Brightwork Research & Analysis shows that buying a large quantity of software from one vendor is the worst strategy that a company can follow resulting in the highest costs and lowest functionality of all available solution architecture strategies. We also measure the riskiness of applications, and again, the more applications that are purchased from one vendor, the higher the risk to the buyer – because it means a higher likelihood of implementing weak applications. Large software vendors that have many applications are universally not strong in all of their applications. The more a buyer purchases from any one vendor, the higher the likelihood that they will purchase an application, which has a far more competitive application in the marketplace – that can be implemented more quickly, at lower risk, and with a higher ROI.

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.

 

Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.

References

https://www.ibimapublishing.com/journals/CIBIMA/2011/670212/670212.pdf