Personally Attacking Those Who Critique ERP Failures

Executive Summary

  • Pro-ERP consultants personally attack ERP critics and point the finger away from the software products when discussing ERP failures.
  • Pro-ERP consultants and ERP software vendors motivated to sell products, silence ERP critics and create a narrative that project management teams are to blame for ERP failures.
  • Lawsuits, which are often revealed due to public disclosure laws, reveal that many companies are unable to successfully implement ERP products.

Introduction

ERP implementations have a large money trail behind them. It has come to my attention that there is a strong network of pro-ERP consultants that spend at least some of their time attempting to promote a very strongly pro-ERP overlay or interpretation onto ERP failures. Those who disagree with the “ERP friendly” post-mortem analyses of ERP failures are singled out for personal attacks. In this article, we will review a textbook case of this type of personal attack.

A Standard Pro ERP Comment

The following is a recent share on a LinkedIn post by Eric Kimberling, who published the statistics of ERP implementations. The following is the slide that Eric shared.

Now notice the response from a pro-ERP commenter regarding this analysis.

Hi Eric Kimberling your assessment is cruel but dare to say you are right especially with 80% of mediocrity.

That is “awesome” that with 30 years of ERP on the market and so many beautiful methods, tools, and certifications we still can see poor picture with many hysteric voices around ERP. Of course, even these mediocrities are not really so bad (as it somehow works) but bad things are much louder than good.

After all, here is definitely a lot of things to do. My take is we tend to much focus on material things and toys are drawing our attention away from the main area of ERP – these solutions are still for people not for robots or AI!

Studying loud failures, I found all these started very shiny with sound reasonable vision. They drifted astray. The cause of poor picture is that ERP project management lack at persistence with this vision.”

Let us review the assumptions within this comment.

Non-Pro ERP Voices are Hysterical?

The commenter states the following:

“many hysterical voices around ERP.”

This implies that if a person critiques ERP implementation failures, then that voice is hysterical. Conversely, one would naturally assume those that cover up ERP failures or defend them or point to the customer being responsible are level-headed and rational (not hysterical).

This sets up the debate under the artificial construct between people that are sane (defenders of ERP failures) and those that are insane (those that critique ERP failures). What a convenient way to move away from addressing the points of your opposition.

Many Beautiful Methods, Tools, and Certifications?

The commenter states that:

“so many beautiful methods, tools, and certifications we still can see poor picture.”

But how true is this contention?

I have reviewed many of these methods in the article, The Real Story on SAP Implementation Methodologies, from SAP and many consultancies.  My conclusion is that these methodologies are primarily written by marketing and sales entities, and they don’t have much of an impact on projects. Having reviewed so many of them, I have no idea what this commenter finds so impressive. Some methodologies, which have been backward engineered to sell more services, do not address the primary risk factor. How do I know this? Well first, it is clear from reading them. In fact, many readers of these methodologies are not even aware that a methodology is not what they think it is, as I cover in Why Methodology Does Not Mean What You Think it Does.

Secondly, when I worked on Deloitte’s methodology for SAP, I was told to adjust it so that it could incorporate as many of Deloitte’s services as possible. Therefore it was less of an implementation method than it was a sales document. Deloitte presented hirees all of their various services as part of a “proven approach” to improving the project. The statements had no foundation in research and the only thing they were proven to do is meet a quota for a partner. I have spent many hours with partners at these consulting companies and none of them care about their customers. They care about money. They are all under heavy quota pressure and cannot afford to put their customer’s interests first. These are the institutional incentives within these companies.

Reviewing the History of Implementation Methodologies (for SAP)

If we look at SAP for a moment, for over 20 years the company has introduced an array of methods that were ostensibly designed to speed implementations, such as ASAP (which we cover in Did ASAP Ever Reduce SAP Implementation Timelines?) and the Rapid Deployment Solution or RDS (which we cover in How to Best Understand the Faux SAP RDS). I have never seen one of these methodologies make one bit of difference on any SAP project. ASAP was introduced with great fanfare, but did anyone go back and check if it did what it said it would do? Of course not. Let us say that a consulting partner did, and the method did nothing. How would they publish this results and expect to keep on good terms with SAP? Experienced implementer (like myself, I say, implementers that do the work, not PMs that are associated with management and do not touch SAP) say that these methodologies are to romance the executives. The ERP consulting space does not question the intent of these “methodologies.” Perhaps they are never intended to improve implementations, but rather intended to do what they look like, which is to improve the consulting company’s ability to close sales.

The Result of All of These “Beautiful Methodologies?”

Now, after all of this, how long do SAP implementations take? Well, our research shows that SAP implementations are lengthening not shortening.

Why?

With products like HANA and S/4HANA being so immature, (for details, see Analysis of Steve Chaflen’s Article on S/4HANA Maturity), these implementations are restricted from completion. With SAP’s new C/4HANA, its maturity is so far out, yet still, the company already started promoting it at SAPPHIRE 2018. Bluefin Solutions published an article trying to hype customers on C/4HANA as covered in the article, How Accurate Was Bluefin Solutions on C/4HANA?  Bluefin Solutions could have told its prospects the truth about C/4HANA’s maturity in the critiqued article, but did they? Of course not. That would be bad for sales. This gets to the issue of why the consulting companies that implement solutions don’t have any interest in honestly informing their “clients” of the reality of these applications.

There is also no evidence that success rates for ERP projects have increased.

Studying ERP Failures Honestly or Through the Lens of Financial Bias?

To study failures in a way that leads to a beneficial outcome for future ERP projects means to study them honestly and not from the perspective of “what is in it for me.” As I have observed in the past, the majority of those writing about ERP failures are riddled with financial bias, as they want ERP implementation to continue unabated. In my meta-research into all (literally all) of the academic literature on the returns from ERP systems going back to the 1980s, the research showed no ROI from ERP implementations. This is covered in the book, The Real Story on ERP. This should be no great surprise as these systems are so expensive to implement. ROI is possible from ERP, but not if you choose a Deloitte or IBM to implement.

ERP Failures Are Loud?

The commenter argues that ERP failures are “loud.”

The implication is that these failures attract people’s attention and distract them from the great story of ERP. But where is this great story? The idea of ERP systems as some great enabler has clearly been a fiction constructed to sell ERP systems. Furthermore, how much money goes into publishing ERP failures? Not much. Now, let us see how much money goes into promoting ERP as valuable items to purchase. As covered in the article, How to Best Understand the Control of SAP on IT Media, SAP funnels money to major IT media outlets for positive media coverage. Oracle and other ERP vendors with large resources do the same. ERP consulting companies have great reach and there is no mention of the actual ROI or success rate of ERP systems on any of their web pages. The ERP and consulting marketing spend is massive and it’s all designed to get companies to purchase ERP systems. The argument that more corporate money supports the case against ERP (by promoting ERP failures) over hyping ERP purchases is very difficult to make. Let us think for a moment:

How much money do IDG, Gartner, and others receive to criticize ERP? How much money do they get to promote ERP?

Once again, nearly all the money is on the side of promoting ERP!

A History of False Constructs to Promote ERP

Over the decades since ERP was introduced, ERP has been promoted with a series of false constructs ranging from how they replace legacy systems (covered in How SAP Used and Abused the Term Legacy) to the idea that a significant competitive advantage could be attained through re-engineering (covered in Reengineering and its Impact on ERP Sales). We have analyzed all of the constructs behind ERP and found nearly all of them to be false. Yet, how often has the accuracy of these constructs been challenged by vendors, consulting companies, or IT media entities? How does the money flow into these entities? ERP proponents have not been held accountable for the many things (benefits) they said that would happen with ERP, which did not happen. If the field was titled “against ERP proponents,” they would not have gotten off “Scott Free.” Companies that have implemented ERP systems do not have the competitive advantage they were promised by vendors and consulting companies. They have spent mightily and made vendors and consulting companies, but what company is today using ERP is “enthused” about the system they now have? What company that has ERP sees it as some empowering system, versus a clerical system that gobbles up the IT budget?

Who was the ERP system designed for? To benefit the customer, or for the vendors and consulting firms?

A Single Reason for ERP Failures: Project Management

This commenter states the following.

“I found all these started very shiny with sound reasonable vision. They drifted astray. The cause of poor picture is that ERP project management lack at persistence with this vision.”

Did all of the failures start with a reasonable vision? Let us parse that comment.

Did the management begin with a realistic understanding of what they purchased, or was inaccurate information given both in the sales process and during the implementation? I would say it’s the latter. Finally, this commenter concludes that the single reason for ERP failures is a “lack of persistence” with a “reasonable vision.”

Really? Every ERP implementation fails because of a lack of persistence? This is the status quo explanation that obviates any need on the part of the vendor or the consulting company to provide accurate information to the customer. How convenient! But also, observed through its proper lens, what an intensely self-serving and negative comment. It appears that all of the customers that fail with ERP are losers, and lack the fortitude and persistence to follow through on the vision of ERP. That is to persevere so that they can finally attain the golden chalice of a system with a negative ROI. They are weak and soft-bellied! Unfortunately, I have also been categorized as a weak soft-bellied loser who would not jump on board (aka get with the program) with the “vision” of the company being created by the head of sales of i2 Technologies. A sociopath with a sex addiction who lied as soon as his eyes popped upon in the morning with what could be described as negative software knowledge. The man who famously said…

“I never want to hear something not existing as an excuse to not sell!”

Right….his vision. That vision. And who leveled these charges against me? Well, salespeople whose primary experience was reading sales material, had worked for the company for around 6 months, and never had to show up on projects and do any work.

The type of people who told our prospects that XML was middleware. Isn’t it amazing how appealing a vision can be….if you don’t have to make it happen yourself?

The Illumination of ERP Industry Practices Brought by Court Cases

These public ERP failures and the lawsuits are of great concern to ERP proponents because they expose the truth of these implementations. This is really the only time that the dirty underside and tricks played by vendors and consulting companies are given a public forum. And let us remember, the only reason this occurs is that the legal systems in the countries where these cases are filed require public disclosure of the complaint. Corporations do not share the truth in a public forum. If it were left to corporations, the PR and marketing departments would massage all information. However, the courts require the publication of the complaint. Court complaints are why we know of ERP failures, and they are what ERP entities seeking to defend their money train find so disagreeable.

Since ERP projects began failing, there has been a strong attempt by vendors and consultants to control the narrative in a way that is favorable to the industry. In fact, SAP has a specific way they release paid placements through major IT media entities in order to control the narrative to point entirely away from themselves as covered in the article The Art of Blaming the Client When a Project Fails.

  • This article points out that Michael Krigsman (the IT failure “expert”) makes comments about project failure that have nothing to do with the facts of each of the project failures on which he comments. No matter which projects, Michael Krigsman is there with aphorisms that discuss how “training is important.”
  • Neither the IT media entity nor the sources that are compensated by SAP disclose their financial bias. One wonders why a media entity would not disclose its payments from a vendor to help point blame away from the vendor. Could there be any possible reason for leaving out such information from the reader? If anyone can figure out this intensely complex question, please comment because it is simply too complex for this author’s limited brainpan.

Lying About ERP’s Mapping to Requirements Cannot be Discussed

Deloitte/IBM/Infosys etc.. lie to accounts before they close the account. They habitually exaggerate how much SAP will cover the requirements as covered in the article The Overmapping of ERP Systems to Requirements. This is so well known at this point, it is outrageous to see status quo ERP defenders imply it does not exist. Deloitte/IBM/Infosys etc.. lie to accounts during the implementation to put off the day of reckoning.

When these behaviors are brought up, the personal attacks begin from the SAP consulting defenders! Why is it virtually every time the SAP consultants, whether they work for the implementation company ceaselessly defend the consulting company and never address (i.e., quickly pivot away) from the issues with the vendor and the consulting firm? Interesting isn’t it. The response is thus…

“Its really much more complicated than that……”

Now the pivot…

“….the real issue is the lack of training, focus __________ (fill in the blank)”

Notice…” it’s much more complicated” always results in “it is the client’s fault.”

No matter how much money is wasted on ERP projects, ERP status quo defenders are always there to tell pro-reform individuals to not be negative. When provided the example of the Air Force’s $1 billion ERP failure, that was again highly based upon lying on the part of the Oracle and the consulting partner, the answer I received from the pro-status quo SAP consultant was that the project was “complex.” For these individuals, there is no amount of money that is too large to waste on ERP!

Conclusion

Something that has not escaped my attention is that the SAP proponents, with their financial bias, never seem to call out many of the very obvious failings of the industry side of the equation. ERP proponents have a story to tell, which is to pay no attention to ERP failures or accept their biased explanations as to the “whys.” However, ERP proponents telling their story means silencing those who critique the overall industry. That is why those critics must themselves be criticized.

ERP Contact Form

  • Want Honest Information about ERP?

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

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

References

The negative ROI of ERP systems from academic studies is covered in the following book.

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 a Lack of Business Process Reengineering the Reason ERP Projects Fail?

What This Article Covers

  • The Quotation from Panorama on ERP Failure
  • Understanding the Actual History of Reengineering
  • The Oracle Air Force ERP Failure
  • Process Industry ERP Implementations
  • How the Coverage of IT Failures is Dictated by IT Media Funding from Software Vendors and Consulting Companies
  • The Problem with the Expectations of BPR/OCM and Cloud ERP
  • Fake Best Practices
  • The Example of Poor Quality MRP Functionality in ERP Systems
  • Faking the Cloud Until You “Make” The Cloud
  • Customization as a Necessity for ERP Systems

Introduction

We were recently reading the report by Panorama on ERP Software Report. While we overall liked the report, we came across a quotation that points in one direction regarding ERP project failure, but we think actually points in a different direction.

We will be evaluating in this article regarding the whether BPR or business process re-engineering and organizational change management are why ERP projects fail.

The Quotation from Panorama on ERP Failure

“Project success won’t have anything to do with technical features, rather it will come down to how well you handle business process reengineering (BPR) and OCM – the most important success factors for any ERP implementation. We often hear organizations say the biggest obstacle to the success of their ERP initiative was misalignment between project management and change management. Often, people involved think they should have invested more in change management, sponsorship, and resourcing.”

Understanding the Actual History of Reengineering

To begin, the concept of re-engineering has always been a bit of a scam. Reengineering fell out of favor in the very early 1990s as was a movement that was based on a book by Hammer and Champy that was a best seller, but not based upon any actual evidence. ERP companies pushed reengineering, paying Michael Hammer up to $100,000 per day to speak because they saw it as a way to sell ERP software.

We covered re-engineering as a blatant falsehood that was promoted by ERP vendors (and strategy consulting companies who also could not have cared less if the basic tenants of re-engineering were true) that used it as a convenient cover to distract observers from the generic functionality they were offering customers. Nothing proposed by re-engineering came true.

  • Companies that engaged in re-engineering projects spent a lot of money on consultants who told them they needed to change their requirements.
  • A lot of strategy documentation was sold.
  • Companies ended up with poorly fitted ERP systems for their requirements that then had to be customized.

Reengineering died, but it was never appropriately critiqued for being a mindless cash grab, and a method to trick executives with poor reasoning skills into buying poorly matched software, and for imposing a massive unpredicted customization effort on these companies.

You can read about this history of re-engineering in the article Reengineering and Its Impact on ERP Sales.

The 2018 Panorama study showed a decline in several factors related to ERP satisfaction. However, this factor of BPR and OCM should have been similar in previous years.

What is Actually True?

One proposal is that everything else stayed the same, but companies did not align their project management and change management particularly recently. That may or may not be true. But I could not find anywhere in the report where it said that factor changed.

Furthermore, the statement by Panaorama, while certainly partially true, seems overly stated. It is impossible to see how functionality limitations cannot have been issues that lead to project failure. Many ERP projects get caught in extensive and unplanned customizations that blow the budget and the timeline and result in companies biting off more than they can chew. It is very common for the RICEF list to grow beyond the company’s willingness to fund the list, requiring an extensive back and forth process where customizations and enhancements, reports, and integrations must be culled.

If the functionality they needed had existed, or if they had been told the truth, that would not occur. A primary reason for this is that they are mislead as to the entire “best practice”/BPR construct. We can say this confidently as there is evidence from many public projects to draw on that point to other factors outside of BPR and OCM. For instance, there are many cases where the software is the culprit or consulting company is the culprit. Let us talk about two examples.

The Oracle Air Force ERP Failure

In the $ billion Oracle Air Force debacle, the central point of failure was the lie that Oracle’s standard functionality could replace a very large number of custom military systems. Change management would not have been the issue because Oracle’s ERP does not do specialized military functions. ($ billion sounds like a lot of money until you realize its only the TCO of around 2 F-35s, which are also useless items that the Air Force purchased…so loosely translated, another day at the office for the US Air Force.)

Process Industry ERP Implementations

In another example, ERP systems are often sold into process industry, but they lack the functionality to manage process industry manufacturing. There are very few ERP systems that have this functionality, ProcessPro being one of the few. But salespeople from ERP vendors will frequently misrepresent their functionality to customers as covering all industries equally well — so again, in this case, it is not BPR, because it is an extensive series of gaps in functionality.

There you go, try to BPR your way out of using a non-process industry ERP system for a process industry manufacturing environment. Talk about a “recipe” for failure. Of course, another option would be actually to select an ERP system that has process industry functionality. However, that would take bit of work, and Deloitte and Accenture will recommend against doing this because….well they have SAP and Oracle ERP resources that they need to bill for to maintain the lifestyles of their partners. 

Now after this project bombs, what will Deloitte and Accenture say? Oh right, the real failure of the project was due to the inflexibility of the customer to do BPR. The major IT implementation companies are in agreement that companies should buy applications that are the absolute worst fit for their requirements so that they can keep a narrow set of vendor specialties in-house.

Imagine if these companies had to staff consultants for many different vendors? It would be absolute pandemonium!

How the Coverage of IT Failures is Dictated by IT Media Funding from Software Vendors and Consulting Companies

The vendors and consulting companies provide most of the funding to the IT media entities, and therefore IT media has taken the position that project failures are mostly the fault of customers, with a lack of BPR being a primary talking point. If they were paid by customers, they would switch their reporting, but they have no other source of income than the IT software and service providers. Media companies like ComputerWeekly are not real media outlets in the normal sense of the word, but are fronts for marketing automation, collecting emails from articles which are then shared as lead generation for vendors and consulting companies as we covered in the article How Computer Weekly is a Front for Marketing Automation.

Vendors and consultancies, get in touch with ComputerWeekly, IDG, Forbes…etc., they have a “media plan” for you. They aren’t journalists; they are your “media partners.” Forbes and IDG are owned by Chinese conglomerates, that is owned by conglomerates out of a country that has never known freedom of speech laws and where honest journalism is synonymous with prison. (You go into a Chinese prison, you don’t look the same when you come out.) However, nevertheless, whatever storyline you want to push, the IT “media” entities, now deprived of any subscription revenue because of Google and the Internet are there for you to publish any falsehood that you can afford. But be careful, you have to bid against the largest vendors and consultancies in your space. 

Industry specialists are funded by major vendors to promote the concept of the responsibility for failure being the customer. SAP has a specific strategy for allocating the blame to customers after a lawsuit breaks, which we have covered in the following article titled The Art of Blaming the Client When the Project Goes South.

The Problem with the Expectations of BPR/OCM and Cloud ERP

Now let us look at the cloud for a moment.

Multitenant cloud means no customizations. That works for simpler systems like CRM and HR, but it has been an unanswered question regarding its applicability to ERP.

But overall, this attempt to do cloud ERP may mean a stronger push to not do customizations and to do more BPR. However, the central hypothesis around not doing customizations is based on what is a false assumption, that all best practices are contained in the ERP system. We analyzed and rejected SAP’s claims of its systems containing best practices in the article How Valid are SAP’s Best Practice Claims?

This concept of best practices has been proposed for decades and is both incorrect, but insulting to anyone who has exposure to ERP systems and to business processes. It is something a salesperson would say who has never been on a project. Furthermore, the entire concept of best practices has already been summarily contradicted by large numbers of academic papers. Therefore the right interpretation of when a person states “my software contains best practices,” is “I am going to trick you.”

Fake Best Practices

ERP systems are not “filled with best practices.” This is a carefully conceived fallacy to get companies to accept functionality that is not a fit for customers because that is what ERP vendors have to offer. Loosely translated your apartment may have space for a two seated couch, but if the furniture salesperson only has three seated couches in stock, then three seated couches are “the best practice.”

The Example of Poor Quality MRP Functionality in ERP Systems

If we take a foundational are of functionality as an example, I am not satisfied with how a single ERP system I have worked with performs MRP. I have been recommending performing MRP in external systems for quite some time and sending the results to ERP to perform all the commits. I can take the MRP run of any ERP system and produce better output and a better planning process with a specialized external planning system. Therefore not only is MRP not a best practice in ERP systems, but it is also functionality to be replaced.

Customization as a Necessity for ERP Systems

Even the largest ERP systems like ECC must be customized — because what you are buying in most cases is just a big batch of generic functionality, with a veneer that it will “work for anyone.” But, if companies are being sold the concept that they can’t customize because of multitenancy, and the idea is that the customer will have to “BPR their way out of every custom requirement” then that will hurt implementations. As soon as multitenancy is broken (that is a copy of the ERP system is made that can be customized) now the solution is no longer cloud, but simply hosted, and many of the benefits of cloud go out the window.

The Panorama report does not say this, but it is an interesting question how much the cloud (no customization) ERP implementations are running into reality. We can only speak to SAP as that is our main focus area and the only vendor we do research extensive project research on and have private data points to draw from. However, SAP is not having success with ERP cloud. The customers they do have on cloud are tiny customers that don’t have customizations, and in fact don’t even need an ERP system (SAP consultancies, etc..)

Faking the Cloud Until You “Make” The Cloud

SAP is pretending to have cloud ERP business to keep Wall Street happy and to make it seem they are “hip and cool.” Estimates from my sources indicate that SAP is probably not making any money on cloud ERP.

Conclusion

The observation of the reason for failure could end up being inaccurate. Therefore the reason for failure on ERP projects can very simply be purposefully misidentified as BPR, (the vendor and consulting company friendly conclusion) when the actual problem was there was no possible way for the company to have performed BPR around the limitations of the ERP functionality due to the requirement being an absolute necessity.

This can be viewed as a desirable conclusion for the individuals filling out such a survey as it obscures their responsibility from performing a well-informed software selection.

ERP Contact Form

  • Want Honest Information about ERP?

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

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

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

References

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

Five Surprising Takeaways from the 2018 ERP Software Report

How Much Money Has Been Wasted on Oracle and SAP ERP

 What This Article Covers

  • Background on the Waste with Tier 1 ERP Systems
  • The Team Effort for Required for the Analytical Failure
  • Tips for Interpreting the Book

Introduction

In the book The Real Story Behind ERP: Separating Fact from Fiction, extensive research performed by SCM Focus is presented — and the conclusion is that ERP was never proven to improve either the operations or finance of any company. Furthermore, one after another prediction made by — particularly the Tier 1 ERP vendors never came true.

The uncovered story of how ERP software become the most popular category ever developed within enterprise software. This was done without any evidence that it could either pay back the enormous investment it required, could improve the return or efficiency of applications which were connected to it. Or even reduce the integration costs incurred by IT departments relates to a central problem in IT decision making, which is explained in the quotation from the book below:

  1. Accepting Simplistic Explanations: Companies tend to be easily influenced by oversimplified rationales or logics for following particular courses of action. This will repeatedly be shown in this chapter. If the executive decision-makers had known technology better, and if they had studied the history of both enterprise software sales methods there is no way that the simple logics that were so effective in selling ERP would have worked. Another way of looking at this is that it was simply all too easy.

The Team Effort for Required for the Analytical Failure

It was a team effort to make such poor decisions, and the research shows repeated unsubstantiated comments made by both IT analysts as well as consulting companies. The book chronicles evidence-free statements made by the most prestigious IT analysis, consulting firms and from enterprise software media. What is clear is that most of the entities which put out articles on enterprise software combine both a financial bias with an inability to perform original research — or even to review research that should not have been that difficult to find.

Tips for Interpreting the Book

The first step for readers — and it is a big step, is to review the evidence presented in the book to understand what transpired in an over 30-year misinformation program. Because ERP is now so ubiquitous, it is assumed that ERP is necessary — even if it does not provide any payoff. However, there are a large number of flaws in this common assumption. “ERP” is some things. First, it is a concept, which is defined by the book as the following:

“Conceptually, ERP is a combined set of modules that share a database and user interface, which supports multiple functions used by different business units.”

However, it is more than this idea and the following are just some of the aspects of ERP that are covered in the book.

  1. ERP as the Central System: ERP is also a philosophy that ERP should be the center of the IT system – when in reality it is simply another application.
  2. Functionality if of Secondary Importance: ERP takes as a foundational assumption that functionality is secondary in importance to integration — which was never true. In fact, the benefits of all software — enterprise or consumer — are what the application can do. Integration is a consideration, but it can never be the driver to what software to purchase. ERP vendors were not only able to get companies to implement common functionality which resided in the ERP application, but also in the standard feature in uncompetitive non-ERP solutions that they sold. ERP vendor, and their partners — the major consulting companies, are significantly responsible for the low efficiency of enterprise software as so much standard and low functioning software has been implemented by ERP vendors at so many companies.
  3. ERP as a Method of Account Control: ERP – as practiced by both Tier 1 and many Tier 2 vendors are connected to anti-competitive practices which are centered around account control. In the grand strategy of the Tier 1 ERP vendors, the ERP system serves as “the wedge.” Once the ERP vendor has sold the ERP system, the ERP vendor has both the established relationships and from there uses a variety of logical fallacies to take over as much of the IT business of the customers as possible. The eventual goal gobbles up as much footprint as possible and to turn the IT department into a passive and controlled entity which implements the software it tells it to.

Conclusion

The book includes specific examples of how ERP limits companies which are listed below.

  1. Case Study #1 of ERP Misuse: Managing the Bill of Materials/Recipe
  2. Case Study #2 of ERP Misuse: Disabling the Enterprise for Collaboration
  3. Case Study #3 of ERP Misuse: How ERP Undermines Internal/External Planning
  4. Case Study #4 of ERP Misuse: Intercompany Transfer

ERP Contact Form

  • Want Honest Information about ERP?

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

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

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

References

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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