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 product from “itself.” While companies make a big deal about being global (and many certainly operate globally), when it comes to fi nance, a company must actually be incorporated in every country in which it operates, 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 fi nd that most publications on the topic of intercompany transfer are on the topic 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 complex, 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 normal stock transfer, transfers goods between two internal locations without any billing.

A billing STO simply 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.

In fact, 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 fi rst 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 managed completely in the ERP system as external supply chain planning systems do not deal with money. This approach is relatively easy to confi gure.
  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 on 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 involved 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 simply 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 in order 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 infl exible 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 really just 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 behavior 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 behavior 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.

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 expense and work down the road.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

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 simply inherent within SAP? Does one have to choose between a best practice implementation and a non-best practice implementation? What constitutes a best practice implementation? This is all extremely confusing, as well as logically inconsistent.

SAP’s Confusion on the Topic of Best Practices

It brings up the question “what exactly are best practices in SAP?” Here is another quotation 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, preconfi guration, 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

In this quotation, SAP classifies best practices as a toolset or accelerator made up of instructions, pre-confi guration and sample master data. But let’s back up a few steps here and take just one example. What do best practices have to do with the master data samples? Best practices are supposed to be business process functionality that is in the system naturally. Master data should be kept up to date and validated with the business, which I suppose could be said to be a best practice; this is not something you can bake into the application unless you mean to make the software transparent and easy to use. In that case you are enabling a best practice; you are not modeling a best practice yourself. Overall, SAP’s best practice seems more like a jumpstart toolkit that contains a combination of things that are best practices. The paragraph goes on to say that there is a NetWeaver component to best practices.

How can this be?

NetWeaver is comprised of the infrastructure components of SAP, so what do these have to do with business process functionality best practices? I suppose one could say that their infrastructure follows best practices, with the business, software, toolkits and infrastructure software all based upon best practices. SAP hammers away at this theme throughout their documentation, but because they apply it to everything they do, it begins to sound like unsupported conjecture— and that is the best-case scenario.

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 just does not know; they are confused themselves as to how to use the term “best practices.” SAP simply smears the term, like cream cheese on a bagel, on almost everything they do. With SAP, simply calling standard SAP documentation a “best practice” will somehow (magically) allow projects to go live much more quickly. In this case a best practice is an incantation. It’s difficult to take a vendor seriously when they are so undisciplined as to the use of their terminology. SAP fi nishes 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 pass 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 a diffi cult 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 the marketing and salespeople don’t actually work on projects or with software, they do not know this. After realizing that they had been bamboozled 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 the purposes of business development. Consultants from large consulting fi rms 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 completely 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 constantly 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, in fact, that and this is because they have no evidence; 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 very useful to ERP vendors as a way of giving them permission to criticize a potential customer’s pre-existing systems. Sales and marketing is 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, and the term “best practices” to describe ERP systems, is highly effective and an impressive feat of rhetoric because it ignores the important 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 defi nition 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 extremely 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 meaning—any system that you would like to replace. However, many decision makers missed an important 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.

Conclusion

Best practices have been a deep well that ERP vendors have repeatedly drawn from in order 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 simply 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 successful selling its software and has signifi cant brand recognition.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

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 to Understand The Best Practice Logic for ERP

Executive Summary

  • ERP systems are frequently sold on the claim of best practices.
  • ERP customers usually do not realize that best practices don’t exist.

Introduction

Many of the arguments that are habitually made in favor of ERP are, in fact, nothing more than logical fallacies, and because of this it is important to review briefly the definition of “logical fallacies.” Proponents of ERP use a number of logical fallacies in the quotations used throughout this book, and when they occur, I will be referring to these proponents by their official names. In fact, 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 in order to make sure I was able to identify all of them properly. When a topic leads one to actually There are some interesting questions that should be asked whenever any software vendor makes a statement about best practices:

  1. Who decided something is a best practice?
  2. Was the best practice put to a vote?
  3. Was it deemed to be so by an expert?

If item three is affirmative, where is the research to support the notion that a way of doing something is a best practice? What a person who asks these types of inflammatory questions (yes, simply asking for evidence is considered infl ammatory with regard to best practices) will find is that in the vast majority of cases, the practice is a “best practice” simply because the proposer declares it to be so. There is no research and no explanation as to how it was determined to be a best practice. Furthermore, if two different ERP systems—both of which are based upon best practices—diverge in some way on how to do things, which one is actually performing the best practice? 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 fi eld 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 experience 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.

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 different 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 intend 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 a number of 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 may be 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). In order 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 concept 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 happen 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 car 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 tenable statement, but only because I do not have the content expertise to truly analyze the claim. Certainly there are things that are desirable in accounting software that could be deemed “best practices.” For instance, it is desirable 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 banal areas of functionality, there will be considerable debate as to what are best practices.

Conclusion

The fact that the concept of best practices was such an effective marketing ploy is yet another indicator that many of the executives that analyzed ERP software sales pitches did not have suffi cient experience with the software they were purchasing to know that software couldn’t be purchased using best practices as a measure. Now that I have covered best practices generally, I will provide specifi c examples of how best practices have been used to sell ERP, and what the results were. To some degree, all the ERP companies used best practices to sell their software. I happen to focus on how SAP uses the term because I have spent so much time over the years reading their literature.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

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 to Understand The Logic Used to Sell ERP Systems

Executive Summary

  • ERP systems were sold on the basis of 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, and because of this it is important to review briefl  the defi nition of “logical fallacies.” Proponents of ERP use a number of logical fallacies in the quotations used throughout this book, and when they occur, I will be referring to these proponents by their offi cial names. In fact, 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 specifi cally on logical fallacies in order to make sure I was able to identify all of them properly. When a topic leads one to actually 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. 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 conclusion by assuming the conclusion in the proof.
  2. Weak Inference: Failing to provide suffi cient 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: An appeal 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 infl uence 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 discussing.
  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 on the basis of 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 or 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 (Year 2000): This was the concern related to the ability to properly calculate dates in software that had been developed back when there was a very small 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 essentially 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 simply 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 larger 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 previous 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 fi nancial 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 (Year 2000)

Many ERP purchasing decisions were made because companies simply 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 properly post year 2000, they could be replaced—swept away by a shiny new ERP system. Fear of Y2K was a main 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 fi rst, 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 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 basic 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), but companies that rely on ERP systems in this way cannot hope to properly leverage the available manufacturing software, 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 major 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 own 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 completely inconsistent with the earlier arguments used to convince companies to buy ERP. I could fi nd no articles that explained how inconsistent the new diversifi ed application strategy was with ERP vendors’ own 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 actually 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 in order to increase their sales. In some cases they could have simply 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 existing clients, without having the clients remember that a main justifi cation for purchasing ERP in the fi rst 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 largest 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.) was 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 own 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 really 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 other 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 unfairly compete: 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 actually 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. In fact, 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 actually 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 simply subsumed into what is often an inferior application. There are a number of 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, it was 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 confi dence 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 to 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 greatly underestimate the degree to which companies faced this issue of being unable to decommission systems that were performing important tasks, and to overestimate how well the ERP implementations at other companies were faring. Companies bought ERP, often without knowing how specialized their own 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 greatly increases implementation costs and durations. It also means long-term and largely unanticipated 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 completely usable systems. Companies went to 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 simply repeating catch phrases. 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 fi nd 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 operational efficiency be evidenced by improvements in fi nancial performance? 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 declared live before the implementation is complete. Much fi ne-tuning is required post “go-live” to get the applications working as required. 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 a 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 benefi t 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 benefi ts 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.

Conclusion

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.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

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 to Know if You are Tough Enough for ERP?

Executive Summary

  • ERP systems are recommended by consulting companies without ERP considering implementation history.
  • Learn why are ERP systems presented as a hazing process.

Introduction

This book is about uncovering new information and synthesizing new observations from research performed previously. However, the historical problems with ERP systems have been very well advertised, and have been the subject of innumerable books and articles about how to improve the poor implementation success ratio of ERP systems. These articles maintain a consistent theme and seem to follow an algorithm.

  1. The Case Study: Some company wasted an enormous amount of money on ERP.
  2. What to Improve: The central concept to ERP is never questioned. Instead, the author moves onto an account of the management flaws that were at the root of the problem.
  3. The Solution: The end of the article points out that it is important to obtain “top management support” when implementing ERP, and that companies need to change their business processes. Following the algorithm analogy, the content of these articles could be programmed into a computer and generated automatically, with the company and the management flaw entered as variables, thus saving the author the time of having to manually write the article. Those working in the field certainly know that ERP implementations are so problematic, and I don’t think I need to spend much time covering this well-established fact. However, I did find the following quotation to be educational.

“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 the 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 most 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 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 intelligently manage, 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.

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 personally deal with the functionality limitations of ERP systems.

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.

Despite the enormous influence of ERP systems on information technology, remarkably little has been written on the history of ERP. This is for good reason. If the 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 to 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 commerical 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

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

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

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 initial proposed benefi ts of ERP as if they were true, and almost all of the materials written about ERP systems since ERP systems were fi rst 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 specifi c needs and without any time lag. ERP covers what are 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 fi nished good. The fi rst 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 as 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 fi rst 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 fi rst designed to meet the needs of supply chain management. However, the opposite is true. In fact, ERP systems were actually designed to fi rst meet the needs of fi nance 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 refl ected 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 personally deal with the functionality limitations of ERP systems. 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 fi rst 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, fi nancialaccounting, 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 fi nancial 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 fl at fi le 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

Conclusion

ERP systems has a history that no ERP vendor or consulting firm is interested in their customers knowing. Rather they prefer to explain ERP as an unquestioned system that has benefited nearly all companies that have implemented ERP systems.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

References

Thanks to Ahmed Azmi for his contribution to this article.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

How to Understand the Non Stop Promotion of ERP

Executive Summary

  • Most of the sources of information in IT are filled with ERP based financial bias.
  • Find out how this makes the coverage of ERP inaccurate.

Introduction

ERP is based upon the oversimplified concept that companies should buy an integrated financial/manufacturing/supply chain/sales management system. This concept could be implemented well or poorly, but it is important to differentiate the implementation of the concept (that is the resulting software application) from the concept itself. Proponents of ERP state that the ERP concept is not only beneficial, but that ERP systems are a requirement for all companies. Companies that don’t buy and implement ERP systems are “not with the times” and “don’t have good executives making decisions for them.” In fact, the logical fallacy used in promoting this concept is “appeal to fear,” and it is effective against executive decision-makers who must keep marketable acronyms such as ERP on their resumes.

For some time, being involved in or overseeing ERP implementations was an important addition to an executive’s resume. In the course of doing research for this book, I found a number of articles that implied that companies where ERP has not yet been implemented should absolutely be thinking of using an ERP system. These articles present no evidence that companies benefit from ERP, but instead rely upon the logical fallacy of “argumentum ad numerum”—that many companies have implemented ERP. They then combined this fallacy with hypothetical statements about how ERP software may benefit a company. Furthermore, this viewpoint is not contradicted by the opposing viewpoint that ERP may not always be the best approach. There is little variability and very little independent thinking on the topic.

How Accurate is the Unanimous View?

After a review of the research on ERP benefits has been presented, the reader should question whether this unanimity of opinion is justified. Companies have invested an enormous number of resources into ERP systems, and contrary to the opinion presented in most of the literature in the area, the failings of ERP to meet the expectations of implementing companies is not something that can be rectified simply with a change in management practice or by hiring a new implementation consultant. This is because the aspects of ERP that have been most disappointing are related to the fact that the concept of ERP—regardless of the specifi c implementation of the concept (the software)—was never as advantageous as was presented. Once companies can interpret these limitations as permanent in nature, they can begin to deal with ERP in a realistic manner rather than by relying upon a new release, wishful thinking, or some new marketing construct provided by their ERP vendor to improve the condition of their ERP systems.

Everpresent Financial Bias

Clearly, information generally available on ERP systems is subject to financial bias, for the obvious reason that the ERP industry is so large and so lucrative. Just a few ERP implementations can make a partner at a large consulting company well off, as they make a lot of money off of their consultants and it takes many consultants to implement an ERP system. For salespeople who sell ERP systems, the same rules apply. Because of the financial bias that exists, information published about ERP is quite positive, bordering on the Pollyannaish. Meanwhile, negative information about ERP tends to be suppressed. When negative information about ERP (mostly in the form of information about failed implementations) does get out, normally the information is spun so that the software and the concept of ERP is not blamed. Instead, the repetitive narrative is that the implementing company must have made some mistakes, and these mistakes are simply managerial in nature and therefore correctable. Clearly, with all this money to be made in ERP systems, the question of who can be trusted to provide accurate information on ERP is clearly not a question that I have come up with exclusively, as the following quotation demonstrates.

“ERP is a multi-billion dollar industry dominated by consultants and software vendors. This is not going to change anytime soon since software and software expertise are the necessities of an automated system. But for a practitioner within an industry responsible for a project and a company that must live with the outcomes, the question is: Who solely has your best interest in mind? I can say only one thing: The deck is clearly stacked against you.” — Control Your ERP Destiny: Reduce Project Costs, Mitigate Risks, and Design Better Business Solutions

Financial bias has caused some highly inaccurate information to be released by most of those who have written about ERP. The fact that so many entities were spectacularly wrong with respect to their predictions for ERP has been one of the great missed stories of enterprise software. And who will cover this story? The IT press themselves are the main culprits; after all, will those who take in advertising revenue from ERP vendors break the story that the emperor has no clothes? It fi ts into the overall storyline of ERP systems; in fact, the ERP phenomenon cannot really be understood without understanding how wrong the projections about ERP have been, and therefore, this is a main theme of this book. It is only through understanding why these projections were so wrong and by taking a full account of ERP as it is today (not blindly accepting the fabricated sales pitch of entities that make their money from implementing ERP), that companies that already have ERP can determine the best way to manage ERP in the future. Secondly, for companies that have not yet implemented ERP, this book will address how to avoid the mistakes of companies that jumped on the ERP bandwagon to their great detriment, and are now stuck in a situation where the system is negatively impacting their ability to meet business requirements and ERP’s resource consumption crowds out best-of-breed solutions.

Unintended Consequences and the Definition of Success

The promises to ERP buyers have not come true, but many things that ERP buyers were never promised and never expected—such as the power that enterprise software buyers handed over to ERP vendors after implementing ERP (and particularly Big ERP vendors and big consulting companies) or the large percentage of the IT budget that the ERP system would consume into perpetuity—did become realities. Therefore, it’s quite important to differentiate between the commercial success of ERP and the benefi ts analysis of what ERP does for companies. No one could dispute that ERP has been tremendously successful for ERP software vendors and for the major consulting companies. On the basis of software sales, ERP systems comprise the highest grossing category of application software ever developed. The sales, implementation, and maintenance of ERP systems have created an enormous number of well-paying jobs and quite well off ERP salesmen and consulting firm partners.

Currently all of the major consulting companies are dependent upon their ERP consulting practice to make their numbers. However, what this book will focus on is the value that ERP provides to the companies that implement it. This book will address two major assumptions. The fi rst is the unquestioned assumption that ERP is necessary.

Big ERP Benefits Companies?

The second assumption is that Big ERP actually benefits companies. As this book will demonstrate, there is no evidence to support these views, and there is quite a bit of evidence that ERP has been an unfortunate misallocation of resources within enterprise software. (In fact, the evidence is that ERP is the largest misallocation of resources to have ever occurred in the history of enterprise software—possibly not as momentous a statement as it appears to be as the history of enterprise software only goes back to the early 1970s, but the total resources expended on ERP since its inception have been gigantic.) This book explains the background of ERP, the expectations that were set for it, and why it is a myth that ERP systems improve the state of companies better than other software that could be implemented. ERP proponents say it is “ERP versus nothing”—a logical fallacy called a “false dichotomy/false dilemma” that is used to stack the deck in favor or ERP—however, the question is really “ERP versus true alternative applications” and therefore alternative expenditures of resources.

The Consensus on ERP

In the previous section I discussed the commonly held belief that ERP is essential infrastructure for a company, something that is particularly true if the company in question is in manufacturing. It is interesting that Aberdeen Research wrote a paper that stated the following about this type of assumption right in the title of the paper: “To ERP or Not to ERP: In Manufacturing, It Isn’t Even a Question.” The words in this title can be described reasonably as the general consensus on ERP, but it is a curious consensus considering ERP’s history. Interestingly, one cannot fi nd consulting advice that questions whether ERP is even a good idea.

The only real topic of conversation is when to implement ERP software or how to improve ERP implementations. If one does not have ERP installed, the question is not whether ERP is a good fit, a good value, and can meet the company’s business requirements, but why ERP hasn’t been implemented already and when the company plans to implement it. Therefore, for the most part, Aberdeen’s research conclusion is correct: this is what the majority of manufacturers believe. But what Aberdeen does not know is that this assumption is not true. With this consensus about ERP among those who provide advice, it is little wonder that most enterprise software buyers believe they need ERP as explained in the quotations below:

“More than 85 percent of respondents agreed or strongly agreed that their ERP systems were essential to the core of their businesses, and that they ‘could not live without them.’ Interestingly, just 4 percent of IT leaders said their ERP system offered their companies competitive differentiation or advantage.” — Thomas Wailgun, CIO

“The business sees the slick demos and possibilities, and then keeps forking over the money for this, and they don’t understand why they are still paying all this money,’ Wang says. ‘Why is it so hard to get a simple report? Why is it so hard to add a new product or build a new product line? Why is it so hard to get consolidated financial information? [underline added] Isn’t that the whole point of ERP?’ ” — Thomas Wailgun, CIO

Companies see the low functionality and the poor reporting functionality of their ERP systems, along with the problems integrating with non-ERP systems, but they don’t seem to be able to put the separate data points together into a complete story. As “everybody” has implemented and used ERP, how could ERP itself be bad?

Books and Other Publications on Software Selection

I perform a comprehensive literature review before I begin writing any book. One of my favorite quotations about research is from the highly respected RAND Corporation, a think tank based in Santa Monica, California—a location not far from where I grew up and where I used to walk with my friend when I was in high school—at that time having no idea of the historically significant institution that I would stroll by on my lost surfi ng weekends. RAND’s Standards for High Quality Research and Analysis publication makes the following statement regarding how its research references other work.

“A high-quality study cannot be done in intellectual isolation: it necessarily builds on and contributes to a body of research and analysis. The relationships between a given study and its predecessors should be rich and explicit. The study team’s understanding of past research should be evident in many aspects of its work, from the way in which the problem is formulated and approached to the discussion of the findings and their implications. The team should take particular care to explain the ways in which its study agrees, disagrees, or otherwise differs importantly from previous studies. Failure to demonstrate an understanding of previous research lowers the perceived quality of a study, despite any other good characteristics it may possess.”

There are so many books that promote ERP, rather than analyze ERP, that there was little to reference when doing research for this book—this is a “why” book rather than a “how” book. Books on ERP have a strong tendency to deal in platitudes and unexamined assumptions, and offer very little new or different information on the topic. The closest I could find to a book that applied some critical thinking to ERP was, Control Your ERP Destiny: Reduce Project Costs, Mitigate Risks, and Design Better Business Solutions, which is sort of a “tell all” book about the errors of ERP implementations. However, as with almost all ERP books, it concentrates on providing information to companies to help improve their ERP implementations rather than questioning the logical and evidentiary foundation for ERP. Most of the references in this book you are reading are not from other books, but from a combination of my personal experience and some articles (including academic articles) that study the impacts and benefi ts of ERP.

Unreliable Information from ERP Vendors

The only quality ERP statistics came from either academic research or, to far a lesser degree, IT analysts. And very little of the material from ERP vendors was found to be reliable; even when they point out flaws in the arguments of other ERP vendors, they proceed to promote their own arguments, which are not based on evidence and often contain logical fallacies. Smaller ERP vendors have gone on the aggressive against Big ERP abuses, but often their arguments are also self-serving. And after reviewing a number of ERP applications, some of the best smaller ERP systems are certainly not the loudest nor do they have the biggest marketing budgets. Some might say that this should be obvious, as these are software vendors and thus entirely biased. However, this has not been true of all vendors in all software categories that I have analyzed. For example, some vendors in the other software categories we cover have added significant content to their space. One vendor that has provided very good and very accurate content in the area of ERP is e2b enterprise, and they are referenced throughout this book. Many of the authors who work for both IT analyst firms as well as IT periodicals frequently quote statistics from other sources, with the same statistics referenced repeatedly. Some of the conclusions that were drawn from the research of others display clear logical errors.

A Lack of Analysis on ERP

Many authors in this area are simply not qualified or have not spent the time to try to make sense of the numbers and to triangulate them with other sources. They may be effective beat reporters, but they lack a background in research. Because of this, one finds that many of the same numbers are repeated in various articles; however, when you study the underlying research, you will find that the conclusions do not follow from the statistic that is quoted in the secondarily sourced article. Executive decision makers certainly do not have time to perform this type of analysis themselves, and as a result, there is little doubt that many of them have been misled by authors who lacked the background to perform the analysis for the articles that they wrote on ERP.

Aberdeen’t Fake ERP Cost Estimation

The most prolific IT analyst firm with respect to ERP cost estimation is Aberdeen. However, Aberdeen’s cost estimates are not realistic. They greatly underestimate the implementation costs for ERP projects, as well as underestimate the variance in license costs between the Tier 1 and Tier 2 vendors (projecting them with an average cost per user no greater than 15 percent in a study that included SAP, Oracle, Lawson and QAD). Aberdeen did, however, have an interesting estimate of the average number of users per ERP vendor, and that helped reinforce how various ERP vendors tend to sell into different sized companies. This is well known in the industry, but the exact figures helped drive the point home. One of the more comprehensive studies of the benefits of ERP also evaluated the research on ERP, and explained their findings in the following quotation.

“Previous evidence on ERP systems has come from qualitative case studies (e.g., Markus et al. 2000) or surveys of self-reported perceptual performance (e.g., Swanson and Wang 2003), but relatively few studies collect data from a large number of fi rms or use objective measures of productivity and performance.” — Which Came First, IT or Productivity?

Conclusion

This lack of information also demonstrates that the demand for such information was never very high. ERP was one of the most powerful trends in enterprise software; however, it was one that was driven largely without the support of academic or other forms of research. This may have been attributed to the compelling logic of ERP. Some philosophies have their own appeal and lower the need for proof in order to make people believe them to be true. ERP was clearly one of these philosophies. I cannot explain why so much writing on the topic of ERP is so generic and duplicated, I only know that this is what I found, but it has a basis in financial bias. In performing research for this book, I would frequently jump between different books and articles; often the similarities were so striking that it seemed as if I were reading from the same book or article.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

References

Thanks to Ahmed Azmi for his contribution to this article.

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

A Marketing Strategy Software Vendors Against the Big ERP Centric Vendors

What This Article Covers

  • Keep Modest at All Costs, Show your Application as “Complimentary”
  • My View on This Strategy
  • The Evidence for the Benefits of the ERP-Centric Approach?
  • The Truth on the Decline of Integration Costs?
  • A Different Strategy
  • Surprise Surprise!

Introduction

We have spent quite a lot of time analyzing how the enterprise software market works. We have a number of associations in the best of breed vendors both in the supply chain — my home software area, as well as other categories that we have evaluated.

What we have found is that most of these vendors are in similar positions — they typically have better applications than what is offered by ERP-centric vendor brands in the market, but because the major brand has so much “mindshare” over customers, and is recommended by the major consulting companies, the best of breed vendor has much lower market share than they really should have.

Keep Modest at All Costs, Show your Application as “Complimentary”

In order to be attractive to prospects, best of breed vendors tend to downplay (to clients) the degree to which their applications can replace the functionality within the ERP systems.

This means that companies often get poor information about where specialized applications should be used versus where ERP functionality should be used. These best of breed vendors prominently display logos on their websites that show they are compatible or have adapters with the major ERP based software vendors.

My View on This Strategy

I don’t like this strategy for several reasons. First, it does not accurately communicate that the best of breed vendor a superior application to the application that is offered by the ERP-based vendor. I call this strategy playing the big ERP based vendor’s game, and while it seems justified on the surface, it will never lead to anywhere close to the proper amount of sales that the best of breed software vendor deserves based upon the functionality of their application. It results in the ERP vendor having its system used for all types of things it is unsuitable for. It essentially sets a mental framework which puts the tier 1 ERP vendor in the driver’s seat.

The Evidence for the Benefits of the ERP-Centric Approach?

I have had this debate a number of times with a number of best of breed vendors — and while discretion is often considered the better part of valor, I think best of breed vendors should instead frontally attack the logic of the ERP. The reason for this is that the logic of the ERP is not supported by research in this area. I have a game plan for doing this. This game plan is based upon the meta-research (that is a review of all the available research into the ROI of ERP systems) that I have performed into tier 1 ERP applications. The inaccurate presentation of the benefits to companies of tier 1 ERP systems is one of the most interesting stories in enterprise software, but it is also a largely untold story with close to no one covering the story in its entirety.

The ERP vendors won’t tell it, nor will the major consulting companies, nor will IT publications, nor will the big IT analyst firms — so it falls on the best of breed vendors to get the word out, as they stand to gain the most by doing so. I will describe this story in a future post. However, the short version is that companies that implement tier 1 ERP systems do not receive a productivity boost, and pay a heavy price concerning higher software costs.

The Truth on the Decline of Integration Costs?

Almost unknown to everyone is that integration costs — which were projected to decline with ERP system adoption — have increased as a percentage of the IT budget.

This is because while Tier 1 ERP systems are integrated to themselves, they make integration to other systems more difficult — and companies cannot live by ERP alone.

A Different Strategy

I propose that instead of following the strategy of accepting all of the assumptions of the ERP benefits, the best of breed vendors should focus on a strategy which calls into the question the benefits of following this approach.

This approach was also questioned in a recent article by Lora Cecere, which has been a quite popular article and generated a good discussion.

Lora picked up on something through a survey and her personal experience that is verified by my meta-research and ERP TCO calculators at Software Decisions. Now, it should be noted that Lora has a more moderate viewpoint on ERP that I do, and I had a more moderate position as well before I performed extensive research on the history of ERP benefits for my book The Real Story Behind ERP: Separating Fiction from Reality on this topic.

Surprise Surprise!

Even I was surprised by what I found. If one does not perform this research, it’s very easy to accept the assumptions of ERP benefits which are often stated, often accepted, but rarely if ever investigated.

Conclusion

In conclusion best of breed, vendors will benefit by not playing the ERP-centric game — as they can never obtain the sales they deserve by following this complementary strategy. To follow this strategy, best of breed vendors should instead clearly communicate the evidence for why the tier 1 ERP-centric strategy does not deliver the proposed benefits. This is not as challenging as it might first appear. I have all the research — both in the form of meta-research — which synthesizes all of the academic research on Tier 1 ERP systems performed since ERP was first introduced in the mid-1980s. In but also regarding specific TCOs and the combined functionality ratings specific solution architectures ranging from 100% best of breed to ERP-centric, to ERP + best of breed.

While all the information is easily available, as I have it all compiled and even interactive calculators, at least some best of breed vendors need to put it to use

ERP Contact Form

  • Want Honest Information about ERP?

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

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

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

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

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 to Best Understand ERP Versus Custom Development for Core Functions

What This Article Covers

  • Custom Development Versus ERP
  • The Effect of Consulting Companies on the Presentation of “Standard” ERP
  • The Effect of IT Analysts on the Presentation of “Standard” ERP
  • How ERP Vendors Push Mediocre Non-ERP Applications into their Customers

Introduction

The research paper ERP for SMEs – is proprietary software an alternative provides interesting quotations and perspective on the concept of using an ERP system versus custom developed solutions.

“Many managers have excluded the possibility of developing their own software, based on experience with time consuming and expensive projects in the past. Thus, implementing standard ERP systems is often viewed as the only solution. However, these systems may impose a rigid structure on a company. threatening the dynamic nature of many SMEs. We show that many companies have a better alternative.”

The Effect of Consulting Companies on the Presentation of “Standard” ERP

It is normally lauded by consulting companies that have the most to gain from proposing this idea that ERP systems save companies money and make them better and more standard. However, a consulting company will never acknowledge that this reduces the flexibility of the company after implementing an ERP system.

The Effect of IT Analysts on the Presentation of “Standard” ERP

Gartner or Forrester never address the issue of using custom developed applications. But of course, Gartner and Forrester receive many millions from packaged software vendors. Therefore, they have a strong bias to not promote anything but packaged applications.

Another quite good quote which is related to this is found in the paper Prioritization Best Practices in a Ratified Consulting Services Maturity Model for ERP Consulting.

“The successful implementation of the ERP system can provide organizations with many benefits including increased accuracy of information, quicker response to customers’ needs, reduced order and delivery times, and elimination of unnecessary or redundant. These benefits are achieved through its data structuring capability. However, there are several drawbacks of the ERP system including vast storage and networking requirements, huge scale of business process re-engineering and customization, which all result in difficulty of implementation and large financial time and human resource costs. These costs can impact very heavily on an organization so typically specialists consultants assist companies with the complex implememntation. It is not just the cost problem that has been a major drawback of ERP. ERP implementations may also be prone to failure particularly during the implementation stage. As Beheshti has noted “the failure rates for ERP projects are relatively high and could lead to bankruptcy of the corporation” and he provides some examples of abandonment including Dell Computers and Allied Waste and also of consequential bankruptcies and law suits.”

Again, this is found in the academic literature, but far less in the industry literature.

Now let us return to the original research paper.

“These encompassing systems will reduce the idiosyncrasies of the company from the transaction processing part, all the way up to company management and customer relations. While this may be an advantage for some companies, it may be disastrous for companies that thrive on their ability to conform to customer demands, to be flexible and dynamic.”

Once again, this is never really brought up. The overall impression given is that all companies benefit from ERP rigidity, forcing companies into a “standard process.”

“An in-house development effort offers full freedom. All processes are candidates for reengineering, and all options are available for implementation. In opposition, an ERP implementation is often viewed as a mapping from the existing system to the new ERP system. The idea is to find a common denominator between the company and the business model embedded in the ERP system. Success is determined when the system work, seldom of how well it services the company.

In house, development should be limited to core functions. It is not necessary to develop a full body ERP system. Instead, a custom designed system should be put together out of several different systems, where only the core part is developed in house.”

How ERP Vendors Push Mediocre Non-ERP Applications into their Customers

If we think of applications outside of ERP, ERP vendors have acquired many non-ERP applications and use the integration argument and the exposure to the decision makers to get their clients to purchase more of their software. Secondly, most applications from ERP vendors that are outside of the ERP system are normally not competitive with applications from vendors that specialize in those areas. If we put the issue of how acquisitions tend to stagnate post-acquisition, often losing developers and focus, the question of why a non-ERP vendor that was acquired by a non-ERP vendor is likely to be the best application for a particular company is an obvious area that should be questioned.

So in addition to the statement above, the strategy of connecting up the most competitive non-ERP applications, and replacing much of the functionality in the ERP system is in fact very sound.

“While the implementation of standard ERP system is an implicit acknowledgment of the fact that one does not want to compete on IT, development of proprietary software implies that one want to increase competitiveness by the use of IT.”

This issue is not broached. There is no concept of this, of competing on the basis of custom developed IT solutions.

ERP Contact Form

  • Want Honest Information about ERP?

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

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

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

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

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

ERP for SMEs – is proprietary software an alternative? Kai A. Olsen and Per Saetre, Business Process Management Journal, 2007.

Prioritization Best Practices in a Ratified Consulting Services Maturity Model for ERP Consulting, Alan Simon, Peter Schoeman, Amrik Sohal, Journal of Enterprise Information Management, 2010.

How to Understand Overmapping Functionality to ERP

What This Article Covers

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

Introduction

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

Proposals on ERP

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

The Truth About ERP Systems

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

The Fake Swiss Property S/4HANA Case Study

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

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

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

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

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

What Happens for Companies Looking for Solutions in Niche Areas

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

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

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

Oracle and the US Air Force

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

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

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

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

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

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

Added complexity to support transactions among business units

Increased hardware and IT administration cost and complexity

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

The Real Story on Mapping Functionality to ERP

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

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

The Deceptive/Secret Level of Customization on ERP Implementations

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

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

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

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

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

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

Conclusion

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

ERP Contact Form

  • Want Honest Information about ERP?

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

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

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

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

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

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

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