SAP

How to Understand Why SAP ERP is Unquestioned

by

Executive Summary

  • ERP systems were proposed to reduce complexity.
  • The result was that landscapes became even more complicated.

Introduction

This book was hatched during a conversation with a longtime friend who works in SAP Basis—the infrastructure area of SAP that is concerned with installing and maintaining the SAP applications. During our conversation, he made the following comment:

“Look at the typical SAP landscape at a company. It now has so many applications that it eliminates what was supposed to be the advantage of ERP in the first place.”

My friend’s statement got me thinking: what is known about the benefits of ERP?

ERP significantly predates my introduction to working on IT projects. Because ERP has been on every project in which I have been involved, I discovered through my research was that my colleague’s single observation was only the tip of the iceberg. Only one example of what turned out to be multiple false assumptions about ERP put forward by multiple entities over many years. I held several false assumptions regarding the benefits of ERP myself; I had never analyzed the issue carefully and had been fed a steady stream of misinformation about ERP by biased parties and those who repeated the message they had heard from others. However, after I read the academic research on ERP, I was appalled to find unsubstantiated statements about ERP made repeatedly and routinely by individuals who presented themselves in their articles as knowing something about the ERP market. Of all the technologies I have researched, the coverage of ERP that I found was probably the worst journalism I have ever encountered.

Based on my research, I concluded that the vast majority of articles on ERP are misleading and not useful to people who are attempting to understand ERP truly. Of course, the articles are beneficial to companies that wish to sell ERP software or services. Interestingly, ERP is a topic that has not been analyzed critically outside of academic literature. For those who believe that—at any time, at any place—the best determining factor of what is true is what most people think, this will not be a good book for you. Examples of when the prevailing opinion is incorrect are too easy to point out for anyone to be able to propose that generally agreed-upon opinions are correct. For instance, at one time, various gods explained all physical phenomena.

The Commonality of Believing False Things

In ancient Egypt, there was a wind god, a sun god, a god of the harvest, a god that ate the sun in the evening and gave birth to the moon and did the opposite in the morning. In ancient times people believed that physical phenomena could be controlled by praying to or making offerings to these gods. If that example is from a time too long ago for you, consider this: within the past one hundred years, the most prestigious universities in the US declared that women could never work in medicine because they would become hysterical at the sight of blood. More recently, US intervention in other countries was based upon a “domino theory,” a proposal that was never proven, never meant to be proven, and was simply a justification for the violation of most of the treaties that the US had signed. These are the tip of the iceberg concerning beliefs that were widely never actually seen as a project without an ERP system.

Henry Ford received the Grand Cross of the German Eagle, the highest medal Nazi Germany could give to a non-German. However, you won’t find this story in any Ford commercial; if something does not fit with the desired history narrative, it is conveniently altered until the desirable storyline is created. For this reason, the great frequency with which the biggest and most prestigious institutions have been wrong is underestimated enormously. It is, therefore, quite likely that many commonly held beliefs today are wrong; in fact, it is easy to demonstrate that they are.

ERP as Just Another False Belief

There are many areas where the commonly held—and institutionally held— opinions are at odds with research in the area, and ERP is such an area. During my research, I found some statements that amounted to: “ERP must be beneficial because so many highly paid executives cannot be wrong.” However, couldn’t the same statement be made about mortgage-backed securities and credit default swaps? AIG, Goldman Sachs and Bear Stearns love them; these companies are chock full of smart people, so how could they be wrong? People who are well disposed toward ERP will most likely read this book (actually they will most likely not read it) and reject it out of hand; how can people agree with something that is counter to their financial benefit? If a person consults in ERP, that person is going to be sold on ERP. Who would ever be so thick as to believe something that could negatively affect their pocketbook?

If you are a partner at a large consulting company that implements ERP systems and your large house and large Lexus have been paid for by ERP implementations, you will not want to read this book—guaranteed—and you will not want other people to read it. Your life would be more difficult if this information got out. However, if you are one of these partners, the problem is that you will have nothing but anecdotal evidence (you have seen ERP work and provide value to clients). Or you have argumentum ad numerum (lots of companies use ERP and how can they be wrong?), or ad hominem (the author must not know what he or she is talking about). This is because the research on ERP will not support what you are telling your clients nor your luxurious lifestyle.

Very few people have suggested what I propose in this book, so it’s rare that people have even had to confront the question of the evaluation of evidence regarding the benefits of ERP. I can anticipate the negative responses because one person, Cynthia Rettig, wrote one of the few articles that were not critical of ERP in an ancillary way, but were vital of ERP’s foundation. Many of the criticisms of her article fell into categories listed in the previous paragraph (argumentum ad numerum, ad hominem, etc.).

Even the most educated part of society—people with PhDs in the sciences—finish their academic careers, still clinging to the idea that discoveries disproving the theories upon which they built their careers must somehow be wrong. A famous example of this is Albert Einstein. Einstein was eerily prescient about most of his scientific hypothesis; in fact, he is widely credited with seeing fifty years beyond any of his contemporaries. However, when he made predictions about the new science of quantum mechanics, he was incorrect. Niels Bohr—a thought leader in what was an entirely new field and who did not follow rules of “large” physics—was proven correct. It turns out that God does play with dice, after all. The desire to find evidence to support one’s already existing hypothesis and to filter out contradictory information is called “confirmation bias.” It is one of the most powerful of cognitive biases. It exists in all of us—except not necessarily to the same degree in each individual, and not to the same degree in each individual at each age in their lifetime. Confirmation bias explains why things that are learned early in life, no matter how false, are adhered to so firmly into adulthood. It explains why advertisers will pay more to reach younger viewers than older viewers.

The Young Impressionable Brain

The young brain is the most malleable; it exhibits what neurologists call neuroplasticity, and as such, it can learn new things quickly. As the brain ages, it develops specific neural connections (actually, the development of knowledge means creating some neural connections at the expense of other neural connections), meaning that it becomes increasingly “hard-wired” for particular thoughts and particular ways of thinking as we age. Although sometimes suggested, it is not true that the best-educated people are immune to confirmation bias. The more an individual has invested in any philosophy or course of action, the more they have to lose by adapting to a new way of thinking. The merely following of the advice can reduce the ability to question that advice, particularly if that advice comes from an entity with some authority. The investment can be both psychological as well as real (in that one receives negative real-world consequences for changing one’s views). Both of these factors—the psychological need to protect previous mental investments as well as real-world consequences of changing one’s views—frequently combine to prevent people from changing to a new and better way of doing things and often make the mind impervious to contradictory information. There is research indicating that math is performed with less accuracy when the conclusion conflicts with one’s beliefs.

One question to ask is:

“Can the person who disagrees with the contentions in this article actually afford to agree with them?”

The Test of Financial Bias

Most importantly, do they have a financial bias? As for myself, I can reasonably propose that I am financially unbiased concerning ERP, unlike the few other authors who have written on the topic of ERP. I do not make my income from ERP, but I do derive work based on the sale or implementation of ERP. I connect the systems I work with to ERP, and if ERP were to go away tomorrow, I would connect a different system to the planning systems in which I specialize.

For the longest time, it has been proposed that ERP serves as a backbone and helps the implementation of other systems. However, from my experience, I have found that ERP tends to interfere with implementing other systems. Although, I should say that all of my implementation experience is with “Big ERP,” and in performing research for this book and other research initiatives at Brightwork Research & Analysis, I’ve found some ERP systems that do not impose as much interfere. I have been impressed with several smaller “ERP” applications; while they have similarities in terms of their footprint, they have nothing in common with Tier 1 or Tier 1 ERP software vendors in terms of costs, account control, business model, and a variety of other factors.

The Lack of Questioning with ERP

Quite merely, ERP has been ubiquitous and an unquestioned necessity. Indeed, I don’t recall people saying they liked any of the ERP systems that had been on these projects, but that did not matter; ERP was just the reality. After this conversation with my colleague, I began researching the topic of ERP’s usefulness and value-add to companies. I expected to find a large number of books—and quantities of research and articles—that demonstrated the benefits of ERP. Instead, I found quite the opposite. Here is a synopsis of what I found:

  1. There are few research studies on the benefits of ERP. The research that does exist shows that ERP has low financial payback.
  2. Research into multiple aspects of ERP by serious researchers (not some survey by a consulting company or IT analyst firm) clearly shows that ERP significantly changes companies, but that the benefits from these changes are dubious. That is, there can be a mixture of positive and negative outcomes from ERP implementations.
  3. The actual research is at complete odds with most articles on ERP, which almost universally promote ERP as a virtue.
  4. Most of the information on ERP is unsubstantiated hyperbole written by people who benefit financially from ERP implementations directly, or by those who have “sampled the Kool-Aid” and don’t question any of the assumptions about ERP.
  5. There are no books that question the benefits of ERP.
  6. There is no book on the history of ERP.

What the Research into ERP Revealed

What I discovered through my research was that my colleague’s single observation was only the tip of the iceberg, only one example of what turned out to be multiple false assumptions about ERP put forward by multiple entities over many years. I held several false assumptions regarding the benefits of ERP myself; I had never analyzed the issue closely and had been fed a steady stream of misinformation about ERP by biased parties and those who repeated the message they had heard from others. However, after I read the academic research on ERP, I was appalled to find unsubstantiated statements about ERP made repeatedly and routinely by individuals who presented themselves in their articles as knowing something about the ERP market. Of all the technologies I have researched, the coverage of ERP that I found was probably the worst journalism I have ever encountered. Based on my research, I concluded that the vast majority of articles on ERP are misleading and not useful to people who are attempting to understand ERP truly.

Of course, the articles are handy to companies that wish to sell ERP software or services. Interestingly, ERP is a topic that has not been analyzed critically outside of academic literature. For those who believe that—at any time, at any place—the best determining factor of what is true is what most people think, this will not be a good book for you. Examples of when the prevailing opinion is incorrect are too easy to point out for anyone to be able to propose that generally agreed-upon opinions are correct. For instance, at one time, various gods explained all physical phenomena.

Conclusion

Since I began working with ERP in 1997, I have found that ERP systems have interfered with the value that can be obtained from business intelligence systems, bill of material systems, web storefronts, etc. This is in addition to the planning systems I have implemented (in fact, pretty much any system that must be connected to the ERP system). In the past, I accepted this as the way it was: I thought IT implementation had to be difficult and frustrating. My exposure to many systems that are far easier to implement and have better functionality than Big ERP has led me to question my assumptions. More companies should be asking themselves this question; unfortunately, these types of questions are not asked because groupthink has settled over the topic of ERP.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other ERP Myths Content

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 Use the Latest New Digital Transformation Terms!

by

Executive Summary

  • Digital transformation is ramping up the bridge and has caused its digital transformations requiring a whole new set of super open-minded terminology.
  • This is not some “Deepak Chopra-ish” fanciful wordplay, but serious terminology enhancements that all implementers and OTs should be aware of.

Introduction to the New Digital Transformation Terms

The term digital transformation has been with us for a few years, with digital transformations appearing left and right. However, there are special conditions that have now arisen on projects that require further elaboration through terminological discussions. You will learn about these new and groundbreaking digital transformation terminologies in this article.

What is the Right Terminology for Digital Transformations that Fail?

The problem with the term digital transformation is that while we switched out the word “implementation” for digital transformation, it was quickly determined that nothing changed on projects. This lead cynicism to run rampant. Depression occasionally set in, with some of those in software implementation going so far as to wonder (out loud sometimes) if it was merely wordplay.

What did change is that many marketing departments had to use the “find-replace” command in their word processing systems to bring their documents up to snuff?

Within a short period, a revolution occurred in the IT industry, and there were no longer any software implementations.

Why might you ask?

Well, to understand why we need to go back to why the terms were switched in the first place.

The Digital Transformation Master Plan

What follows is top secret. It is not for presentation to non-SAP friendly personnel.

This graphic displays the bad old days of software implementation.

SAP and SAP consulting firms figured out the fundamental flaw in software implementations. And it had nothing to do with the lies told during the sales process, immature SAP applications like S/4HANA being implemented or faked resumes by SAP consulting firms. No, the problem was that the declaration of success had to wait until the end of the project. And since SAP projects failed with such frequency, it meant that most projects would never get to the promised land of being declared a success.

SAP and its consulting partners needed to make a radical change to address this issue.

Introducing……”DT!”

The answer was simple. Make the project associated with a successful terminology so that the process itself rather than the outcome was the focus — i.e., a “digital transformation.”

This way, the project is already successful because it is associated with something considered virtuous. Who in their right mind could be against transforming something?

It does not matter that the term is meaningless in the modern context as it is from the 1900s describing the transition from nondigital technologies to digital technologies. Almost no SAP consultants or customers will bother to look it up!

Assert meaningless terms to your heart’s content!

Furthermore, it turns out that IT departments also have no interest in validating the success of their projects, and are very happy to use this terminology also. Everybody wins!

The 100% Conversion Ratio of Software Implementations to Digital Transformation

We are delighted to report that the conversion of SAP software implementations to digital transformation was 100% successful. There are now no more software implementations occurring…..anywhere.

However, the industry was left with a problem.

The Need for New Digitial Transformation Terminology

Even if digital transformations fail, they are still referred to as digital transformations. For example, the fact that Lidl recently halted one of its SAP projects to go back to it is far more desirable “legacy” system did nothing to diminish the fact that it was still labeled as a “digital transformation.” It is still labeled as a successful implementation on the KPS website. However, was it? Both SAP and KPS still consider the Lidl SAP failure to be a digital transformation…..because they got paid.

Digital Transformation or Bank Account Transformation?

This brings up the question, should a digital transformation that fails instead be more accurately called a..

“Digital bank account transformation”?

And this leads to the next topic.

What is the Right Terminology for Digital Transformations that Fail and are Greater than $300 million?

Now, if the digital transformation fails but also costs more than $300 million? After much discussion, it was agreed that it would be called a..

“digital boondoglefication.”

What is the Right Terminology for Digital Transformations that Lead to High Degrees of Account Control?

A significant benefit of ERP digital transformations is that they put the vendor and consulting company in a good position regarding account control. This allows the vendor and consulting partner the face time to talk down any competing applications. Our research into ERP implementations….digital transformations is that this is a primary ROI to ERP digital transformations. As a high degree of account control is the desired outcome of such projects, the question has been posed “what should they be called.” It was concluded that this is a.

“digital accountformation.”

Conclusion

This is an exciting time to be developing new terminology for the digital transformation industry, and we are happy to report on all of the tremendous new terminologies that are coming from the field. As with the original base term of digital transformation, all of the new derivative terms are equally evidence-free. Digital transformations are transforming digital transformations, and that can only be a good thing, as this video from the digital transformation center can attest.

 

Digital transformation is not simply a term being parroted by people who have “no idea what they are talking about.” Far from it. Endorsements for digital transformation can be found in this video. It is easy to see the excitement in the responses from these endorsements. It turns out that digital transformation is creating more breakthroughs leading to more OT booms than at any time in history (according to the video). 

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other Digital Transformation Content

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

Is SAP ERP Good Because it Won Against Other Options?

by

Executive Summary

  • The concept is sometimes promoted that because SAP ERP is popular, that it must lead to good outcomes for customers.
  • What were the true reasons for SAP ERP’s popularity?

Introduction to SAP ERP Being Popular as an Argument

We recently found this quote on ECC regarding its popularity.

“R/3 in its days – before SAP had the dominant market position it has today – did win against most of the options on the market so it had some merit. “

How SAP Sold Out Customers to Corrupt Consulting Firms

There are many things to say here. First, SAP was the most aggressive vendor in giving away it is consulting to consulting firms. These firms, in turn, recommended SAP. Not because SAP was right or the correct fit, but because it allowed them to make the most money. Therefore, the playing field was not level. Consequently, it is not at all evident that this was a good decision merely because many companies selected ECC.

How is SAP Degrading Customer’s Investments into SAP?

Moreover, as I observed, that initial decision is looking worse and worse as SAP is changing the terms of the deal by giving customers a bad upgrade option in S/4HANA and by using indirect access to illegally push the account to buy SAP. Customers now deal with an SAP that is making up false constructs (like Type 2 indirect access) to control them. SAP thinks and behaves as if they are owed a certain percentage of the IT budget, even if the customer does not want to use their software. A vendor that acts this way is a liability to have in the building. SAP will be pummelling its customers for the next two decades. Every year that passes will likely increase the regret that they ever purchased SAP.

Who Likes ECC, Customers or SAP Consultants?

There is no evidence that ERP systems are beneficial to customers that implement them. I can say I have never seen an SAP account particularly happy with ECC. Users also do not enjoy working with ECC. They find it a burden and SAP is frequently lampooned at my client sites. It is also often commented that the system does not live up to expectations or is otherwise “takes forever” to “get things done.” ECC frequently appears to be a system that was forced on the users by the executives rather than a system that users want to use. The people who are happy with ECC, are consultants who make money from ECC.

The most prominent defenders or ECC or SAP on LinkedIn are never customers. They are SAP consultants who say a lot of unscientific things to defend their source of income. 10 out of 10 SAP consultants enjoy billing hours for SAP. I keep pointing to academic research that no other ERP consultant has read and that no ERP consultant is interested in reading. That is the academic consensus of decades of papers on the subject demonstrates no ROI from ERP systems.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Is it Right to Lead Clients into SAP Software Failure?

by

Executive Summary

  • S/4HANA is an implementation that makes money for SAP and consulting partners but has a very low likelihood of success.
  • S/4HANA implementation has turned into quicksand, and the consulting partners know this.

Introduction to S/4HANA Risks

Our observation from many implementation data points of S/4HANA as outlined in our S/4HANA implementation study is that S/4HANA is the highest risk application with the least likelihood of going live of any application we track. One major reason? S/4HANA is not a completed application.

The risks of S/4HANA implementations that are specific to S/4HANA (that is exclusive of all of the factors outside of S/4HANA such as the implementation partner, customer, etc..) break into the following:

  1. Incomplete nature of the overall application. (see SAP’s Misleading Storyline For S/4HANA Being Incomplete)
  2. Problems with HANA has in supporting a S/4HANA ERP system.
  3. Customization remediation effort due to changes in the database schema.
  4. Data migration effort due to the changed in the schema and the shortage of tools for making the migration (along with migrating custom tables)
  5. The loss of functionality through “simplification.”
  6. Customization remediation effort due to changes in functionality.

Obtaining Financially Biased Information About S/4HANA from SAP’s Coterie

Interestingly, the entities that provide information about S/4HANA to the market are either SAP itself or SAP consulting firms. SAP has been massively overstating S/4HANA as covered in How Accurate was Hasso Plattner on S/4HANA? Media entities that cover SAP are paid directly by SAP. We are a research entity that focused mostly on SAP. When we receive research requests from companies interested in the validation of information about S/4HANA that has been provided by SAP and their coterie, we find that in 100% of cases, the company is working from an inaccurate set of assumptions. And in 100% of cases, the assumptions are positively biased. It is clear that the objectives of SAP and their coterie is to get S/4HANA into companies by any means necessary, and by telling any lie, they need to tell.

S/4HANA’s deplorable implementation history has been almost entirely censored. SAP consulting firms won’t discuss these failures and halted projects with prospects; they want to discuss SAP marketing talking points. And when an individual from a consulting firm writes an article about S/4HANA, they are cautious to never discuss their financial bias in favor of S/4HANA, or that they, for instance, have a quota to sell S/4HANA services. Instead, they prefer to present their views as if they are impartial.

This explains articles like this that vastly overestimate the readiness of S/4HANA for implementation and underestimate the implementation challenges with S/4HANA. They have no other purpose than to drum up business for S/4HANA implementation services.

The S/4HANA On-Premises vs. Cloud Distinction

These are all called out for S/4HANA on-premises. S/4HANA Cloud has too small of a functionality footprint for any one company but small professional services firms to implement. (S/4HANA on-premises and S/4HANA Cloud are two separate applications, something which SAP deliberately obscures to customers and Wall Street.)

Implementation Costs

Secondly, the implementation cost of S/4HANA on-premises is guaranteed to be extremely high for the factors listed above. Merely the costs of items 3 and 4 will be extremely high. S/4HANA is like no other SAP ERP upgrade, which was already quite problematic and expensive.

ERP Failure Rates

ERP and, more broadly, enterprise software failure rates are a frequent topic of conversation among those that work in the industry. However, what is curious is how undiscussed the implementation of applications that have a very low likelihood of implementation success. If the implementation advisory function is more focused on billing hours than in selecting applications that have higher probabilities of implementation success, then naturally, failure rates will be higher than necessary.

Increasing Consulting Revenues with S/4HANA

Even with S/4HANA’s extremely low implementability, SAP consulting firms still want the S/4HANA consulting business. This means they work with SAP to mislead customers, and prospects about the existing S/4HANA case studies, their personal implementation experience with S/4HANA, and S/4HANA’s revenues.

But what happens if the project that is being recommended by the consulting company has close to no chance of being successful?

Consulting

What we are seeing is a consulting ecosystem that is recommending S/4HANA implementations that, in most cases, will not go live and will worsen the condition of the client, but which benefit the consulting company. So should consulting companies be recommending implementations that they know will fail? The SAP consulting market has become so profitable for so many companies, combined with SAP bringing out such immature applications, that implementations are recommended that have close to zero chance of improving the condition of the customers.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other Improving Implementation Content

References

Repair MRP Book

 

MRP System

Repairing your MRP System

What is the State of MRP?

MRP is in a sorry state in many companies. The author routinely goes into companies where many of the important master data parameters are simply not populated. This was not supposed to be the way it is over 40 years into the introduction of MRP systems.

Getting Serious About MRP Improvement

Improving MRP means both looking to systematic ways to manage the values that MRP needs, regardless of the MRP system used. It can also suggest evaluating what system is being used for MRP and how much it is or is not enabling MRP to be efficiently used. Most consulting companies are interested in implementing MRP systems but have shown little interest in tuning MRP systems to work to meet their potential.re

The Most Common Procedure for Supply and Production Planning?

While there are many alternatives to MRP, MRP, along with its outbound sister method DRP, is still the most popular method of performing supply, production planning, and deployment planning. In the experience of the author, almost every company can benefit from an MRP “tune up.” Many of the techniques that the author uses on real projects are explained in this book.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Opportunities to Improve MRP
  • Chapter 3: Where Supply Planning Fits Within the Supply Chain
  • Chapter 4: MRP Versus MRP II
  • Chapter 5: MRP Explained
  • Chapter 6: Net Requirements and Pegging in MRP
  • Chapter 7: Where MRP is Applicable
  • Chapter 8: Specific Steps for Improving MRP
  • Chapter 9: Conclusion
  • Appendix A: Calculating MRP
Categories SAP

Is SAP’s ERP System Innovative?

by

Executive Summary

  • SAP’s ERP systems are often presented as a useful application, even innovative, but we question this assertion.
  • To understand SAP ERP, it becomes necessary to know how ERP was originally sold when SAP first became a well-known vendor.

Introduction to Whether SAP’s ERP Was Innovative

SAP claims to be an innovative application. The following quotation presents this.

“To be fair to SAP, they have great products and they have not so good products 🙂
SAP Business Suite is a great ERP when implemented properly and deployed on a scalable/reliable platform (ahem, e.g. Oracle).
You have correctly pointed out all those inaccurate claims on their other not so good products. However, this shouldn’t diminish those positive impacts of their very trusty and reliable Business Suite applications since 1992. Rational product development decisions should prevail over old feud though. Moreover, the rational thing to do is to continue the ECC product line way past 2030 with updates in technology and Business processes so that true innovations without disruption is what all customers can depend on.”

Is ECC a Good Product? Is it an Innovative Product?

There is a consensus that ECC is a good product. SAP’s entire existence is due to ECC.

However, is ECC innovative? To consider this question, let us consider the actual definition of innovation.

“Innovation can be defined simply as a “new idea, device or method”. However, innovation is often also viewed[by whom?] as the application of better solutions that meet new requirements, unarticulated needs, or existing market needs. Such innovation takes place through the provision of more-effective products, processes, services, technologies, or business models that are made available to markets, governments and society. The term “innovation” can be defined[by whom?] as something original and more effective and, as a consequence, new, that “breaks into” the market or society.” – Wikipedia

Therefore, innovative means the company came up with something that no one else came up with. It must be new. Now let us consider ECC.

ECC was just a better and broader implementation of something all the ERP vendors were doing back in the 1980s. At that time, software vendors were acquiring MRP vendors and incorporating MRP systems into financial systems to make “ERP.” The benefit was integration, but less discussed was that much was lost in this process. For example, it worsened the MRP systems, which is something I covered in this article Why are Companies Still Running MRP from ERP?

The idea was that with one system, costs would decrease. However, can anyone look at the costs of ERP implementations and say these reduced costs?

Another problem is that ECC is so weak in so many areas that without Excel, it would die.

The number one way to report and do analysis in ECC? Yes, that would be Excel. ECC has been fantastic for creating external spreadsheets. It seems that Microsoft does not get enough credit for ECC being able to function. 

ECC is Good Outside of Finance?

ECC is challenging to use in supply chain management (the area of functionality I have been consulting in for decades in SAP), and it received far less development effort than SAP’s FI/CO module. I consult with ECC customers that generally have great difficulty in managing the supply chain process with ECC. The supply chain functionality was hastily created by what looks to be force feeding supply chain books to developers. The forecasting functionality is virtually impossible to work with. I could go on and on. But this is why I recommend to companies that they do not perform MRP or forecasting or any supply or production planning in ECC.

Deloitte and Accenture, on the other hand, desiring to bill the most SAP hours as possible, never recommend reducing the reliance on SAP, no matter how bad the functionality. The entire SAP consulting ecosystem exists not to help customers, but to bill as many hours in SAP as possible. Any approach that reduces this primary objective will never be recommended. SAP gives awards to consulting companies, no matter how much they mistreat clients. Even WiPro won an award!

However, SAP proposes ECC is excellent for all of the things mentioned above. The result is that now companies perform these functions in ECC with great difficulty. This issue extends to analytics (all ECC systems have separate analytics systems) to sales order management (CRM has taken much of ECC’s sales order origination function) (why SAP loves indirect access claims against Salesforce).

ECC, a System Propped Up By Customization, Other Systems and Excel

As time has progressed from the initial “sales job” for ECC as the Swiss Army knife of applications, ECC has given up increasing amounts of functionality to other better applications. No one seems to remember that this is not what SAP or their coalition of the billing said would happen. Originally CIOs wanted to get rid of their multiple systems, but decades later, ECC also has….you guessed it, many systems connected to it. And SAP is more challenging to integrate with other systems than any other vendor.

Without these systems, and without extensive customizations (something else that SAP lied to customers about), and without exporting to Excel, the frustration with ECC would have no release valve, ECC would be removed from companies at a far high rate. People that consider the popularity of ECC neglect to mention that ECC is propped up from so many dimensions. ECC can be regarded as like an older man. If four other people drive him around and give him his medication, he can have an active lifestyle. But without that external help, he is not going anywhere.

ECC is stable, comprehensive (a relative term I know), standardized, and probably a few more accolades…..but innovative? Companies that implemented ECC are better off than before they purchased ECC? Not the companies I see, and that is not what the academic research indicates.

And as we will discuss, life is about to get even more difficult for ECC customers.

When and How ERP Became the Largest Software Category

ERP became the largest enterprise software category purchased during the 1980s, and it held onto this title until just recently until giving it up to CRM. But it did so without any evidence that ERP improved the condition of companies that purchased it and used it.

It is important to recall that SAP and consulting companies told customers that ECC was the only system companies would never need and would lower their spending. Over decades a tremendous number of companies have lied about the impact of ERP on customers. Because all of the money is on the side of the ERP “industrial complex,” they are never called out on their inaccuracy. These are the usual suspects. And they have something fundamental in common. None of them care about what is true.

The Sordid History of ERP

Looking back at the history of ERP, it is easy to see that ERP was purchased because it became a trendy item. Deloitte, Gartner, Accenture, and a whole industry — all with a pro-ERP financial bias — all told companies they had to have an ERP system. My analysis of the academic literature is that ERP systems have a negative ROI (as covered in The Real Story Behind ERP).  And because of the high cost of SAP ECC implementations and ongoing maintenance and the fact that ERP systems don’t particularly enable companies to do things better than they did them before.

SAP ECC has a strongly negative ROI. SAP ECC implementations are the most expensive implementations that we track. We offer two online TCO calculators for ECC, one for large customers, and a second for extra-large customers. Lidl just canceled a 7-year project that cost 500 million Euros. Many billion-dollar and up R/3/ECC failures are all through SAP’s history. Imagine what happens to the ROI of ERP when the failures are taken into account?

Both software vendors and consulting companies have been cautious never to let their customers know the TCO of ERP. It would be ruinous to ERP sales, and therefore would not allow the most critical driver in all of the ERP industry, namely quota attainment.

Trapped by SAP ECC and Lead to the Slaughter with S/4HANA?

Executives brought no standard of evidence to the decision making process concerning ERP, never asking what proof vendors or consulting companies could point to. Executives within customers that purchased ECC were not so much “thinking” as following the adverse risk strategy of just “looking at what your neighbor is doing.”

Now, these companies are stuck with ECC systems that offer little flexibility, are extravagant to maintain, and with the introduction of S/4HANA have a highly unappealing upgrade path. S/4HANA cannot be upgraded from ECC, but is a full reimplementation, pounding customers budgets once again. This is truly outrageous, but the consulting companies are silent on this, presenting S/4HANA as a positive development. (the customer’s expensive TCO is money in consulting firm’s pockets)

Deloitte and Accenture’s perspective on software TCO can be understood by Matthew McConaughey’s speech in the Wolf of Wall Street. “You take your customer’s money and put it in your pocket.” This is how the SAP consulting companies think about their customers. 

With the introduction of S/4HANA, a system that over three years after the introduction is still not ready to be implemented, SAP has made the entire value proposition of their ERP system from bad to horrendous. And this is before we get into the other questions of the even lower ROI products that customers often buy from SAP to connect to ECC, and the indirect access liabilities of HANA, which SAP stipulates as the database for S/4HANA.

Conclusion

We conclude that while SAP R/3/ECC has been great for Deloitte, Infosys (and, of course Oracle who loves those database revenues driven by ECC with 70% of all ECC instances using the Oracle DB), ECC has not been beneficial for customers that implemented it. That is, these SAP customers would have been better off custom coding their solutions (or keeping their existing solutions). Moreover, now companies have SAP, they have SAP account reps trolling their hallways. These sales reps are insistent that their customers double down on their negative ROI SAP ERP investments with even more negative ROI investments into more SAP products that are a step down from ECC. And that with indirect access, customers may have to pay for connecting any non-SAP applications to the negative ROI SAP ERP application. The entire SAP scenario has completely lost the plot. And money rather than product drives every decision.

If only customers buying SAP ERP back in the 1980s and 1990s had any idea that this would be the eventual outcome of their trendy SAP ERP purchase.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other ERP Content

References

https://en.wikipedia.org/wiki/Innovation

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
Categories SAP

Analysis of Rimini Street’s Presentation on ERP Support

by

Executive Summary

  • Rimini Street created a presentation on ERP support.
  • We evaluated this presentation for accuracy.

Introduction

Rimini Street wrote the article 10 Telltale Signs of that it is Time to Change in Your ERP Strategy. This is a document that focuses on the history of ERP and ERP support. It seemed worthy of analysis.

Rimini Street Quotes

“In the beginning, your vendor delivered great software and valuable support that helped you troubleshoot issues and optimize your systems. But over time, that model changed. The support partnership between you and your vendor has eroded and software improvements have all but disappeared.”

Brightwork Research & Analysis covered this in a previous article titled What To Do About SAP’s Declining Support.

“89% of the average IT budget is dedicated to keeping the lights on, leaving only 11% for innovative projects*”

This has been known for some time. What SAP and their consulting partners, in particular, have excelled at doing is maximizing their take of the IT budget or the larger companies. This is covered in the article How Vendors and Consulting Firms Parasitized enterprise Software’s ROI.

“In ERP’s early days, annual support was typically 15% of the original license cost. Today, support costs have risen to a standard 22% — a whopping 47% increase over the years. And it’s not because Oracle and SAP have been investing in making support more responsive to customers’ needs. It’s because vendors net up to a 90% profit margin on support revenue, accounting for roughly half their revenue streams, making investors very happy.”

This is consistent with what amounts to changing the terms of the software sale. If the software was initially sold under the concept of a 15% yearly support fee, then that percentage should continue. No doubt one of the logic used by Oracle and SAP is that on software purchased many years back, its support, as it is based upon the list license cost. However, this argument is undercut by the fact that most SAP customers have been purchasing other SAP applications as time has passed. Furthermore, Oracle and SAP have both followed a consistent approach to harvesting their existing customers. Oracle does this with highly punitive audits. SAP has opted instead for indirect access to force companies into purchasing more of their software.

“Before you know it, one small problem has morphed into a big project with regression testing and downtime that costs a lot of money, time and resources. When you get back in touch with support, you’re unlikely to get access to experienced engineers unless you navigate a maze of escalations.”

I have faced this issue myself. Poor quality support undermines the system. Curiously, so much money in IT is spent on system implementations hiring highly expensive and wasteful firms like Deloitte, Accenture or IBM. Still, when it comes to supporting, there is often a desire to reduce the support as much as possible.

“Most ERP implementations are robust and stable. Without compelling new functionality in the pipeline, many enterprises prefer to continue running the current system.”

In the case of SAP, they have tried to alter this truth by proposing that their new ERP system, S/4HANA has a great deal of innovation. Roughly 93% of S/4HANA is simply ECC (the previous version of S/4HANA).

And SAP customers have lost functionality with S/4HANA that came from ECC. SAP has also invalidated the agreement with customers that all new versions of purchased software would be included in the support price. SAP has decided to charge for S/4HANA even for customers that already are running ECC. This is covered in the following article Why SAP S/4HANA Should be Free.

“72% of SAP licensees believe their current release meets business needs*”

This figure is quite interesting. But it may even underestimate the actual benefit of upgrading for customers. This is because many of the business needs of the customer are not in the next release of their ERP system. There are always areas of functionality that the customer would like that is not contained in the ERP system.

“The cost of an upgrade can easily exceed $1 million. And more than 56% of Oracle ERP upgrades take nine months or more.* Upgrades also pose significant risks. Licensees are concerned about testing, staff limitations, maintaining customizations and the possibility of downtime.”

This was one of the most important areas of ERP that Rimini Street along with Nucleus Research highlighted. It was surprising to me when I read their coverage of the topic because:

  • a) it was never an area in which I specialized, and
  • b) it seems not to be mentioned on projects. Instead, upgrades are treated as necessary and responsible.

90% of ERP systems are customized*

* 85% of Priority 1 issues are custom-code related* 65% of all issues are custom-code related*

* 65% of all issues are custom-code related*

This was surprising. In my consulting experience, I don’t recall seeing the customizations cause that high a percentage of the issues. However, following up issues was not mainly what I have done.

“Gradual rollouts of cloud versions of Oracle Fusion and new SAP S/4HANA updates have triggered lukewarm interest from customers. Acquisitions of cloud vendors, such as Oracle’s buy of NetSuite and SAP’s purchase of Concur, have introduced more questions about ERP roadmaps.”

That is certainly true. Extremely few customers are live on S/4HANA. Oracle Fusion’s lack of adoption is renown even for those that do not specialize in following Oracle.

The Problem: A Lack of Discussion and Fact-Checking Around SAP and Oracle Support Costs and Value

Oracle, SAP and their consulting partners, as well as the IT media entities all, have something in common. They don’t want the total costs of support, the margin obtained from support by these vendors or the value of this support provided discussed.

The total costs of Oracle and SAP ERP support are enormous, and they pull resources from IT departments with little commensurate value provided. This is why these entities don’t want these topics discussed.

Oracle and SAP benefit from the lack of quantification or the hidden nature of ERP support costs. Upgrades, many of which cannot add value over their costs, are simply absorbed into the IT budget and considered “business as usual.”

Being Part of the Solution: What to Do About Oracle and SAP Support

The first step is to calculate the total costs of support — not just the 22% base level, but the extra costs with support additions as well as the cost of upgrades, etc. Then to quantify the value provided by ticket closure and determine which applications are actually planned to be upgraded. Paring support costs is not an all or nothing decision, even though SAP and Oracle sales reps make it sound like trimming support costs is close to the end of the world.

If you need independent advice and fact-checking that is outside of the vendor and vendor consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other SAP Support Content

Conclusion

This is a quite interesting presentation from Rimini Street. Quite educational actually. This is the type of information that would never come from an SAP or Oracle rep or consulting firm.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other ERP Content

References

https://www.riministreet.com/Documents/Collateral/Rimini-Street-ebook-10-Telltale-Signs-Change-ERP-Strategy.pdf

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 ERP System Was a Trojan Horse

by

 Executive Summary

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

Introduction

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

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

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

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

The Single System Logic for ERP

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

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

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

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

The Logic of Cost Reduction for ERP

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

Business Cost Reduction

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

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

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

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

The Best Practice Logic for ERP

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

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

The Integration Logic for ERP

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

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

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

The Real Benefit of ERP Systems

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

The Presentation of the Integrated Suite Philosophy

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

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

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

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

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

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

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

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

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

The Reality Around Adapters

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

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

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

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

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

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

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

A Better Course for Achieving Integration

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

Why ERP Vendors Invested Nothing in Publishing Standards

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

This is explained in the quotation below:

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

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

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

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

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

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

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

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

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

Integration Suites as a Way to Reduce Competition?

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

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

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

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

Integration is Not a Primary Driver of TCO

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

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

Consulting Companies Focus on TCO or Set About Maximizing TCO?

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

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

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

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

Hypothesis Testing

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

“Is there a way to test this hypothesis?

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

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

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

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

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

Purchasing More Software From One Software Vendor

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

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

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

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

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

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

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

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

The Validity of the Hypothesis

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

The Most Important Feature in the Software Correlated to Implementation Success

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

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

An Often Repeated Evidence-Free Assertion

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

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

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

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

How ERP Systems Were a Trojan Horse

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

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

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

How Competition in Enterprise Software Works

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

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

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

The ERP System and Horizontal Enterprise Software Competition

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

Industry Consolidation

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

Ignoring The Reduction in Choice

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

What is the Specific Comment

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

What is Account Control?

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

The ERP System as the Queen

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

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

ERP-Centric Strategy?

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

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

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

Conclusion

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

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

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

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

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

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other ERP Problems and Inefficiencies Content

<

References

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

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 Compare Global Versus Single Software Instances of ERP

by

Executive Summary

  • ERP is sold on the ability to be used as a single instance.
  • Learn why the proposal that ERP works as a single instance is incorrect and what this means for projects.

Introduction to Global Instances

This article is based on real experiences taken from global software implementations. You will learn the positives and negatives associated with global instances.

How Accurate Are the Single Instance Benefits of ERP?

A primary selling point of ERP was that a company would be able to move to a single instance of their ERP system. This idea continues to be a selling point of vendors such as SAP, even though in most cases, only smaller companies have single instances of ERP.

“An ‘instance’ refers to the number of discreet versions of ERP software you have in your company. The original vision of ERP was that companies should have a single instance—that is, a single implementation of the software running on a single database— that serves the entire company. It would mean no duplication of information in different departments or in different geographic divisions and thus better integration and information quality across the company. Upgrading the software would also be easier than with multiple customized instances of ERP across the company.” — The ABCs of ERP

Historically companies have been unable to move to a single instance of ERP, yet no one questions why, especially since this is presented as such a desirable end state. As the complexity of a company increases with the addition of regions or subsidiaries, the value of having a single instance of an ERP system, with only one database, becomes questionable. Vendors certainly know this, but present a single instance as a desirable option with benefits to the customer anyhow. The reasons why companies are unable to move to a single ERP instance are well documented and are not going away; some of the major causes are listed below:

  1. Database Management and Query Efficiency: ERP systems are supposed to be single database systems, which belies their integration. There are issues with reduced efficiencies at higher data volumes, but what is the value of having sales figures from different subsidiaries that may have no relationship to each other in the same sales order table? For instance, if a user performs a query for all sales in a quarter, do they mean the sales of subsidiary one or subsidiary two? How do proponents of the single instance ERP system consider the increased complexity of the data in their presentation of this solution?
  2. Which Region/Division/Subsidiary Gets Its Way?: If different regions do business differently, and they must move to a single instance, which region gets the system configured or customized to its requirements? What happens to the productivity of the company that gets its configuration adjusted for no other reason than the desire to normalize the functionality across the subsidiaries so that the move to a single ERP system can be facilitated? Most often it is the region with the political power (i.e., the region where the headquarters are located), and has absolutely nothing to do with logic or what is best for the business. I have been on several global implementations and I would recommend to any independent contractor who could choose between a global implementation and a regional implementation to choose the latter. Global implementations are exercises in one region enforcing its will upon the other regions. At one client site, the region with the headquarters simply left out functionality that was available in the application when the new application was explained to the other regions. The functionality they left out would have allowed the application to be configured differently. They did this to prevent the other region from choosing a configuration that was different from what they had already decided upon. The region that selected the configuration assumed that the configuration was right for everyone seeing as they had selected it. They called this the “Global Template,” which was a convenient way of getting the other regions to do things their way.
  3. Negotiation Leverage: A single ERP system is viewed as a cost savings because more business is aggregated to one vendor. Surely this is a one-sided view on the matter: single sourcing also increases the negotiating leverage of the vendor (why they like it so much). What happens when the ERP vendor knows they have 100 percent of a customer’s ERP business? Well, this is just the starting point for Tier 1 ERP vendors; their eventual goal is to replace all enterprise software used by the company with their other applications, to turn the client’s IT infrastructure into a monoculture, and to staff the IT departments with 100 percent compliant executive decisionmakers. If this sounds vaguely familiar, it is because it is the same desire of every major IT consulting company. When I first got into consulting, my partner at KPMG explained to me that our role was to “penetrate” the client and then “radiate” through them.
  4. What About Functionality?: Looking from 30,000 feet up, it’s easy to state, “If we use one system we can save money.” However, there is another side of the equation: the value that the system provides. When a company moves to a monoculture, having regions/divisions/subsidiaries—the people who actually know the business, reduce the functionality benefits—choose their own solutions. This leads to the next point.
  5. How Much Does Customization Increase With a Single Solution?: Proponents of a single instance ERP leave this point out of the analysis, and for good reason. Using a single instance ERP system will mean more customization or, as so many IT proponents prefer, taking a wrecking ball to the business requirements. However, customization translates to real money, both upfront and in long-term maintenance, and the costs must be estimated as part of a strategy of moving to a single instance ERP.
  6. What About Flexibility?: Moving toward a single ERP system has negative implications for the flexibility of the company. If the acquisition is eventually sold, what is the cost of breaking the acquisition out from the combined ERP system? Hold on to your hats! Tier 1 ERP vendors are not doing this analysis—or have done the analysis but don’t want their customers to know the truth. Instead, they continue to bang the gong of single-instance ERP. In truth, that a single ERP system was never a realistic proposition should have been apparent to buyers from the very beginning. It is now well documented that the vast majority of companies do not have a single ERP system, and the reasons are quite well explained.

The following quote is just one of many examples.

“Well, it sounded great on paper, but unfortunately reality bites. The stories started to leak out—multi-million dollar never-ending ERP projects, high profi le ERP project failures, inability to tailor the deployment to local subsidiary needs, and over-tapped local IT resources overwhelmed by a monolithic on-premise ERP deployment. And if a division is run as a profi t-center, these kinds of deployments can quickly paint red all over the P&L.” — The Decline of Single Instance ERP

The Use of Multiple ERP Systems

Multiple ERP systems in companies are now the norm, and not just two or three ERP systems as the quotations below explain.

“On average, big companies worldwide are running fi ve SAP instances, while almost four in ten have more than six, according to a study from IT services firm HCL Technologies.” — When SAP Sprawl is Cool, ZDNet

“The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus, many companies ended up having several instances of the same ERP systems or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.” — The Trouble with Enterprise Software

According to one IDC survey, 72 percent of respondents were running more than one ERP system. People will say that multiple ERP instances can be consolidated into one, but in most cases, that is not practical. There are several excellent reasons as to why a company cannot reasonably be expected to move to a single ERP instance.

“‘A lot of people run multiple instances because of geographic reasons, regulations, or business-sector reasons,’ Illsley said. “If you’ve got part of your business that is outsourced, for example, you’d probably want to run an instance that your outsourcing provider could use and that would be different to the one you would want to keep inside, so that it’s easier to do things like that.” — When SAP Sprawl is Cool, ZDNet

How to Understand ERP as The Original Monolith

ERP systems can be considered the original monolithic system. This article covers what monolithic systems are trying to pretend they are based on microservices.

The Mother of All Monoliths, the ERP System and Its Influence on Present Day IT

The ERP industry is massive and because of this, infrequently criticized because of its enormous economic power. When ERP systems first were marketed, consulting companies became partners with packaged software companies, effectively parroting everything they said. Even to the point where almost no one in IT is aware that academic research going back to the 1980s on packaged ERP systems consistently show the same results, which is a negative ROI. One author of this book, Shaun Snapp, covers this in the book The Real Story on ERP: Separating Fiction from Reality.

All of this is why the ERP system can be viewed as a Trojan Horse as is covered in the article How ERP System Was a Trojan Horse.

ERP implementations were instant money makers. ERP consulting firms were careful to never expose any of the problems with the ROI ERP systems. Everyone “knew” that ERP systems benefited companies. Also, if you had any doubt, you could read a report from Gartner that would say how good ERP systems were. You know, Gartner, a “trustworthy” firm with significant undeclared revenues from ERP vendors.

ERP sales reps have done their job well, with software “stuffing” after the initial ERP sale being quite ordinary. Moreover, the maintenance of ERP systems has proven to be higher than anyone imagined. The estimates on this topic vary, but let us review some we were able to find.

  • According to Rimini Street, 89% of the average IT budget is dedicated to keeping the lights on, leaving only 11% for innovative projects.[i]
  • “Some agencies are spending 90 per cent or more of their IT budgets on operations and maintenance. A report released last week found. The IDC Government Insights report found 77.7 percent of proposed agency IT budgets for the fiscal year 2017 is going to operations and maintenance, with the remaining sliver dedicated to systems development and enhancement.” [ii]
  • “The federal government spent more than 75 percent of the total amount budgeted for information technology (IT) for the fiscal year 2015 on operations and maintenance (O&M) investments.” [iii]

Stuffed Accounts

IT departments are so stuffed with unused or little-used software that a major complaint of SAP and Oracle sales reps is that they can’t get more growth from their current customers, which is why “net new” customers, which is customers who have never been SAP or Oracle customers, are considered so highly valued.

In the case of SAP, the question is how to unlock value from the massive investment made into both the ERP system and the associated systems purchased by SAP customers. (Hint: it is not by buying more SAP).

  • In some cases, it is decommissioning some SAP applications. Leveraging cloud services is a primary way to improve the investments made into SAP and ERP systems generally.
  • There are so many ways to unlock value from SAP environments, but they aren’t from leveraging more SAP, or from leveraging most of what SAP has to offer as most of the new things that SAP offers don’t work out.

The first step is to stop listening to SAP or to the SAP consulting partners that won’t tell their clients anything independent but repeating whatever SAP says. All of the advice from these entities leads right back into buying more of what SAP has to offer. And when it comes to cloud, SAP is just a big pile of liability.

What is a Single Global Software Instance?

Let us discuss what is meant by a single global instance in enterprise software. This is where the software is installed in one region, which is then used by multiple areas.

  • Single Global Instance: An excellent example of this is where a multinational company installs an application in say Germany. Still, this instance not only supports the European region but the North American and Asian regions as well.
  • Multiple Regional Instance: The opposite of a single global instance is a multiple instance implementation where each region has its software and hardware which is run from a location within that region.

The Conceptual Appeal of Single Global Instances

The idea of using a single global instance of software to support multiple regions is an appealing concept to many companies, and global instances work quite well under some circumstances.

Companies often like the idea of a single global instance, standardizing how the software is used within the enterprise. This restricts how the company can configure, customize and use the software by region, and is consistent with a particular philosophy where IT is emphasized over the business.

IT organizations look for maximum IT efficiency, which means systems that can be applied to most users with the lowest IT infrastructure. Email and communication systems are an excellent example of systems that scale very well and exhibit little need for variance per region.

The Single Global Instance Concept Generally

When a global software instance is used for, say supply chain planning where I have worked on many projects, it typically leads to projections that the planning will finally be “integrated” between the different regions.

Multinationals will often transfer materials between the regions, a transaction which is covered by either purchase orders (which behave as if the two companies are foreign companies to one another), or preferably intra-company stock transport orders).

However, this results in other complexities that are easy to gloss over during the high-level planning sessions before the project kicks off. Two of the major complications are listed below:

  1. Uptime: All applications require their uptime to be coordinated when they are supporting regions across for the different time zones. A single global instance means downtime is harder to organize.
  2. Processing Time: For applications that require substantial processing (and not all do) the processing schedule must also be coordinated between the regions. For instance, if an application runs a procedure, it may lock the activities for other areas, in that the people in the “up” regions may not be able even to make changes to the data. This means that a coordinated “batch scheduled” of when processing is run. For those interested in the details on this topic which explain the challenges, I cover some of them in this article.

Applications that require substantial processing reduce the ability of an application to be set up” as a single global instance. Secondly, the processing time for batch jobs may seem manageable at a high level, can turn out to be a problem once the jobs are scheduled, leading to contention once the software has been implemented.

Regional Management of Instances

Companies, which are experienced and advanced in their use of APO, may have two regions up on SNP, but often not the third. Being live with multiple regions does not necessarily mean that the implementations were planning effectively between the regions. Whether they are or not is strongly related to the organizational design with regards to planning within companies. There are some companies, particularly companies that rely on 100% outsourced manufacturing that performs all planning in one country, but it is more of a rarity.

While there is much discussion of the “global economy,” supply chain planning continues to be regional and in many cases a local affair.

Planners with an understanding of the local markets are considered to provide an edge over global planning. At least that is the storyline.

Decentralized Planning

Most companies have decentralized planning (Europe planners plan European supply networks, US planners for the US supply network, Latin American planners for et…) and multiple planning departments mean different ways of doing things, various directors and VPs and traditional political rivalries. While companies accept regional planning organizations, most do view having all regions on a single planning system as desirable. It is no simple matter to meet this objective. When implementing supply planning globally, the following issues arise.

  1. When the processing is performed daily, will the processing load impact both the responsiveness of the system for the users and or will users be locked out of their user interface? Setting up a global system means analyzing the technical implications of how supply planning processing jobs are set up. This includes locking planning books for product locations which are being processed by a supply planning method. And evaluating issues of contention – this leads to both implications for hardware sizing, as well as the methods that are selected and how the various planning runs are set up.
  2. Supply planning systems have a structured way of transferring demand through the supply network, as is described in detail in this link. The situation does not change when locations are in different international regions. It will move distribution demand between locations the same way. If a location in Ohio has a source of supply in Hungary, and the operational workflow only processes US locations during one-period distribution demand will be created on the Hungary location. The Hungary location will have to wait until the European threads are processes for distribution receipts and planned orders to be built in that factory. Processing the supply network for the entire globe once per week could eliminate this issue. (this way, all regions would be synchronized when they start work on Mondays. It should be noted that there is not a simple 48-hour window in which to perform processing. Instead, the window is when the last region closes for business on Friday, and when the first region opens for business on Monday morning.) The regional processing model and its implications for what appears and when it seems at other the location which is a source of supply is shown in the graphic below:
  3. When a global instance is used, while the initial supply plan and deployment plans are required to be globally aware, the rough cut capacity/ S&OP / MPS plan, as well as the redeployment plan, are not. This is because rough-cut capacity / S&OP / MPS planning is regional. Secondly, redeployment is also regional. Therefore, the processing and coordination needs for these plans is lower than for the initial supply plan and for the deployment plan.

The Global Schedule for the Supply Planning System

The different methods for the S&OP/ MPS/ Rough Cut capacity plan and the initial supply plan are listed (in SNP) (in an example SAP SNP supply planning system) below:

options-for-supply-planning

Regional Differences in Political Power and Conflicting Interests

A problem with single global instance implementations is they often lead to seemingly endless debates with the other regions as to how the system will be configured and each region has a strong tendency to believe that the configuration settings that work for them should be the ones to be used in the global instance.

What is supposedly cooperative, will often end up competitive once control of a customized and highly configurable application is in play.

Typically, the region where the company is headquartered gets its way – and the other regions must simply deal with a system, which is poorly configured for their needs. Putting the needs of the outlying regions on a second level is a great way to have the regional users reduce their use of the system.

Secondly, the more one gets into the detail of how each region manages its business, the more the differences in how the business operates become apparent. This lengthens both the time of the implementation as well as the risk of the implementation. These are, of course, significant issues to be considered before giving the thumbs up on a single global instance.

Getting the Real Story on an Application from the Hosting Region (Headquarters)

In the 1st article in this series I pointed out that typically, the region where the company is headquartered gets its way – and the other regions must simply deal with a system, which is maybe poorly configured for their needs. Putting the needs of the outlying regions on a second level is an excellent way to have the regional users reduce their use of the system. Having participated in global rollouts, I can say that headquarters getting its way most often has nothing to do with “best practices” or choosing the best design. Instead, it is often merely the group that is based at headquarters and therefore that has the power that gets its way.

Secondly, there are specific ways which this can be accomplished in a way that can be hidden, to restrict the choices of the other regions, but without coming out directly saying to the regions that they had their options limited.

Is the functionality a secret of being tightly controlled and kept from the other regions? As the country where headquarters is located typically implements first, and therefore they are at a great informational advantage versus the other regions.

How Headquarters Can steer application Design Decisions

Even where documentation exists on the functionality in question, they can be told by the IT support team at headquarters that the functionality “was tested and just did not work properly or simply did not meet the business requirements.” Especially in the early parts of the rollouts for the other regions, where of course many of the decisions are made, there tends to be a natural trust of the information that comes out of headquarters regarding the application. The knowledge difference between a group that has already participated in implementation versus a group that is beginning an implementation is enormous. Now, not all implementations begin at the headquarter region before they are rolled out to other regions, but many do.

The experience above came from a global implementation where I worked. In this case, the region (where headquarters was located) that first implemented the software deliberately mislead the other regions as to what functionality was available so that the system would only be configured the way they wanted it to be rather than letting the other regions know the full story of what the application could do.

The other regions paid for the system (through transfer payments to the headquarter region) just as the headquarters did, however, their ability to get the system to fit their needs was quite small. And the IT support organization worked at headquarters, their bosses all worked at headquarters, so the regions had very little sway over the overseas IT organization.

Standardization sounds nice, but it often means a reduction in the ability to adjust locally, and the “standards” determined by people that don’t have the best interests or that understand or are interested in the complications of local individuals and institutions.

Positives and Negatives of Standardization

Standardization works when the variances are small and when the benefits from standardization are clear.

  • The metric system is an example of one such standard that benefits those that adopt it. The metric system takes the time to implement. Still, it is both undeniably superior to the imperial system, and once adopted, the country is better integrated into other countries in their weights and measures.
  • Some standards are presented as virtuous when in fact, they merely benefit the entity which is in the position to determine the standard that will be set. Colonialization is one example of this type of standardization which consists of a series of rules and regulations passed and enforced by the ruling entity for the primary benefit of the governing body.

Thus, while companies may look integrated between their regions from the outside looking in, however, what I have found from some projects, is that the firm’s regions primarily care about themselves first, and one region cannot trust other regions to perform solution design for them.

Meeting Business Requirements

While there are a wide variety of business requirements in companies, which can often differ significantly based upon the region, IT departments will frequently attempt to generalize the business requirements to present them as more uniform than they may be. This allows more regions (in the case of a multinational), at least in concept, to use a single global instance of an application. However, are the total costs lower once one moves to a single global instance?

The answer to this very much depends upon the business requirements and how the implementation is performed.

Business needs drive differences regarding how applications need to be configured. If one region requires configuration and follows a particular business process that another region will not follow, then there can be a difficulty in using a single instance, reducing the benefits of going with a single global install.

The second question is whether the business value is as high with a single global instance versus multiple regional instances. I will provide an example of where the business value is, in fact, higher when a single global instance is used.

Identifying Opportunities for Using Single Global Instances by Enterprise Application Category

There are some categories of enterprise applications that make a lot of sense to have as a single instance.

One of these is bill of material management software (aka Product Life Cycle software or PLM). This software is used to allow multiple departments within companies to collaborate on the draft law of equipment – it also will enable suppliers and contract manufacturers to work on the BOM. Also, which is of primary importance for both efficiency of product development and design as well as enabling the company to get a better price. This is because the BOM components can be bid on by more suppliers. BOM/PLM software does not usually need to be individually configured for different regions.

For instance, the BOM management company Arena Solutions provides a SaaS solution to many customers from a single global instance, where it services all clients. This is where a vendor supports multiple customers who may use the application globally, from a single global instance. Still, of course, there are divisions between the customers so they can’t see each other’s data.

Having a single global instance of a BOM or PLM system turns out to be incredibly important for this type of software. The BOM is probably the most collaborative master data objects in systems.

Not only should different regions be collaborating on the same BOM information, but suppliers and other partners should also be logged into a single system — of course with an excellent security model.

How the BOM is Shared

The BOM is shared and sits between both some applications as well as interface with users both inside and outside of the company which controls the BOM.

When a vendor works in a software category of this type, they can substantially reduce the costs of delivering the application as well as increase its functionality. Another application group that is also not coincidentally often sold under the SaaS model, which typically requires little customization and has light configuration is CRM.  PLM and CRM software are good candidates for single global instance implementations.

However, the more configuration and customization and configuration that any application requires, the more difficult it is to make those applications be the single instance. ERP applications are some of the most intensively customized applications in any software category.

From the examples provided above, it should be clear that the discussion of the costs and benefits regarding a single global instance versus multiple regional instances very much changes depending upon the enterprise application category. This is true as well as the degree of similarity in the configuration and customization of applications — which are questions that are specific to the company in question.

How The Cost Categories Change

We have estimated the cost components to single versus multiple instance implementations at our quantification research site. It is important to have this adjustment regarding estimation because the costs change in different areas depending upon whether single or multiple instances are used. (other factors are important to adjust for as well including the following)

  1. The Number of Software Instances
  2. The Number of Languages Supported
  3. The Number of Regions Supported

The following costs behave the following way as a company moves from a single instance to multiple instances:

  1. Maintenance Costs: Increase
  2. Hardware Costs: Increase (although hardware costs are such a low percentage of the total cost of ownership of any enterprise software application that this is not a deciding factor)
  3. Implementation Costs: Decrease. Single instances – for the majority of applications (those that require more specific configuration) mean more effort in driving to compromise on how the software will be configured. This is because the configuration will serve the needs of some regions, subsidiaries, etc.. but not others.
  4. Software Costs: Neutral

All of this drives towards costs. And as much as I like calculating TCO, TCO has nothing to do with benefits received from an application.

As I stated in the second article in this series, costs should not be the determining factor in an IT strategy. Any concept, which reduces the fit of the application to the business, reduces the probability of success of that application and therefore, its ROI. If application implementation were simply about costs, then we would select the cheapest applications, the least experienced consultants and the lowest cost outsources IT support that is available on the market. So costs do not define the ROI.

Conclusion

It should not be simply accepted blindly that single global instances applications save money, and offer the same business capabilities as do multi-instance regional implementations. This applies in particular when the application either is processor-intensive, requires significant configuration or customization (and there are substantial to moderate variances from region to region). It also means substantially increasing the risk of the project.

CIOs or IT department heads will often oversimplify the trade-offs inherent to the global versus regional instance question. This is because the IT cost is often lower, but that is not all of the expenses, and as can be seen, if the headquarters region controls the functionality and design that is used in other regions. The other regions can end up with a system that was designed to meet the needs of the headquarters region, but which does not meet the needs of the outlying regions. That is a problem.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Other Two Tiered ERP Content

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