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?

    We can help you independently verify the information provided by major consulting companies and answer your ERP questions. Our work together can remain confidential too. We are one of the very few truly independent sources of information on the areas we cover

    Just fill out the form below and we'll be in touch asap.

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

Why are Functionality Gaps a Problem on ERP Projects?

What This Article Covers

  • Conventional Wisdom Versus What is True
  • The Built-In Problem with ERP
  • The Problem with Gaps
  • Allowing Interpretations to be Set Through the Use of Terms of Propaganda
  • Overstated Functionality Match of ERP
  • Using Open Source ERP for Customers with Lot of Development to Do

Introduction

Recently we were asked the why gaps are a problem on ERP projects. In this article, we will explain the normal ERP sales process and why gaps proliferate and the issue this brings up to development.

The Problem with Gaps

Gaps are a problem when they are unplanned. ERP systems are oversold to customers in a number of dimensions. One dimension is that the ERP system contains the way companies should be doing things. Which is the BPR thread? Consider, there is never any evidence provided (and none asked for) that the company should engage in BPR. It is simply proposed because it is part of conventional wisdom that processes must be changed. What they are changed to is a topic for another day. If we look at the US political process, whenever one wants to change something, they slap the label “reform” on it. The term is meaningless except to describe the change. The change will in many cases make the program worse. One would have to be a bit simple-minded to accept “BPR” or “reform” as being inherently virtuous. They simply mean a change, change can be good or bad.

Allowing Interpretations to be Set Through the Use of Terms of Propaganda

In fact, the primary reason for using such terms, we call them terms of propaganda, are so that the individual does not have to provide evidence.

As in who doesn’t want “digital transformation?”

The term reform has been used for decades to sugar coat changes to laws and to programs as a form of virtue signaling. The term hides the fact that there will be winners and losers in any change. It casts a positive light on the change, without providing details of what the change will be. The first question when one hears terms of propaganda like digital transformation, reform, reengineering, is to ask what is the specific change that is being proposed. 

Overstated Functionality Match of ERP

The second dimension is that, as with the Oracle Air Force case study — where Oracle sales told the Air Force that all of their specialized custom military systems could be emulated and thus replaced with Oracle ERP, during the sales process the match between the ERP system’s functionality is overstated. Therefore you end up with one assumption of gaps in the sales process, and a completely different number of gaps in the implementation — part of the reason for the out of control RICEF list.

Curiously, ERP vendors are not held accountable for overstating the match of the functionality the customer’s requirements. And a primary reason for this is the pivot to the project being unwilling to perform a sufficient level of BPR — the sufficient level of BPR being determined by the software vendor and the consulting company. Two companies that benefit from as much BPR as possible. Honestly, for a vendor that has oversold their application into a customer and has to answer for large cost overruns, what else are they doing to say?

Using Open Source ERP for Customers with Lot of Development to Do

This is why we have proposed that companies with a lot of unique requirements choose an open source ERP system that they can customize inexpensively. A system like ECC and to a lesser degree other ERP systems, are expensive to customize. I can hire developers in languages outside of ABAP to get things done far more efficiently than in ABAP. If your development work is smaller, then it’s not as much of an issue, but in most cases, it is significant. Therefore, one has to keep an eye on the development ball and development productivity. 92% of SAP ERP systems are either moderately or extensively customized. And as a final point, no ERP vendor, or application vendor, should be telling the customer what to develop in. We don’t need entities with a bias taking control of other areas of IT simply because they sold the company the application.

Therefore in most cases, SAP and other ERP development is going to have a big impact on timelines and budget. There is no ERP vendor who is going to offer a set of development tools that is as efficient as what is available on the open market where one can choose from a variety of languages.

So you can end up selecting the software thinking you won’t customize much, and quickly get into a costly project — a major reason being that the cost to customize SAP is so high. If you have to use specialized applications in addition to the customization, now ECC or S/4HANA really becomes a costly and high maintenance item.

References

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.

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 the Concept of ERP Passed its Expiration Date?

What This Article Covers

  • Conventional Wisdom Versus What is True
  • The Built-In Problem with ERP
  • ERP Systems as Simplistic Platitudes to Sell Mediocre Software
  • The Everpresent Alternatives to ERP

Introduction

While commenting on an ERP study, we were asked the question if ERP is essentially an expired concept. In this article, we will answer this question.

Conventional Wisdom Versus What is True

There are really a few different dimensions in which the question of whether ERP is passed its expiry date should be discussed.

  1. One is the dimension of conventional wisdom. Conventional wisdom does not have a lot to do with what is true. So as far as when conventional wisdom changes I have no idea, and I can’t predict when people will gain a better understanding of things. That is a question of mass psychology not what is real.
  2. But if we consider the dimension of what is true — where I am much more comfortable.

Therefore the reality of ERP as an expired concept is what I will address.

The Built-In Problem with ERP

ERP is a problem because it leads people not to question the quality of the system. It is a category that has an inherent assumption that the functionality does not have to be very good because it is ERP, and “everyone knows” you need an ERP system, so shut up and take your ERP medicine. This type of force-feeding of systems that are a bad fit for requirements, or where the business requirements are diminished in importance is the dominant approach of the major consulting companies who work in very top-down fashion. No questioning is tolerated at either the client or within the consultancies themselves.

There is little doubt now that ERP systems were sold on false pretenses, and they did not meet their lofty objectives. (We have a wealth of information that supports this at Brightwork, and a book on the topic.) Yes, the finance system was “out of the box” connected to the supply chain system, but the outcome was you ended up with a shitty supply chain system! What if I sell you a washer and dryer. The washer is great, but the dryer is bad. But how about if I bundle it for you? Personally, I still don’t want that. I want a good washer and a good dryer.

ERP Systems as Simplistic Platitudes to Sell Mediocre Software

ERP systems were, in essence, a simplistic platitude that was appealing. Remember, the first sales pitch of ERP was that it was the only system you would ever need. So ERP systems were sold with a sophistication similar to razors or coffee.

Let us think of some marketing jingles, shall we? Just for comparison purposes.

“Gillette is the best a man can get.”

“The best part of waking up is Folgers in your cup.”

How is that any different from you need a

“Single integrated system that will replace all other legacy systems?”

The Everpresent Alternatives to ERP

There always were many good alternatives to ERP systems. Everything from custom coded solutions to a combination of best of breed with a more moderate amount of custom code, to open source ERP with best of breed, etc… It is a cornucopia of options. But these options could not be seen because in my view, of the high conformist nature of the people to become executives.

Executives are Type A go-getters with little interest in researching things below the surface. Therefore, they often rely on simplistic platitudes.

But there are more options than ever, and the power of ERP should (I say should) decline because it is obvious what the outcome of ERP implementations have been — you just have to pay attention.

Conclusion

So as a principle, it is foolish to be impressed with a system because it is bundled. It is also unwise to try to single source most of your software from one vendor. SAP customers are finding out with indirect access claims and continually increasing support costs, that the more leverage the vendor has over you, the worst you will be treated over time. SAP ERP systems do not have an ROI, and that negative ROI is going to grow as SAP continues to harvest more and more out of their customers. And the customers are now trapped because they have a vendor they over-relied upon, thinking they would have fewer headaches by concentrating their vendor spend.

References

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.

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 BPR 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.

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 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.

References

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.

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 Accurate was Forbes on Systems of Record vs Systems of Engagement?

What This Article Covers

  • What is a System of Record?
  • What is a System of Engagement?
  • The Ripe and Common Misuse of the Term System of Record
  • Historical Systems of Record

Introduction

Previously we explained how the term system of record is a buzzword or term of propaganda that was promoted chiefly by ERP vendors to help sell ERP systems, and to invest more in ERP systems once purchased. We covered this topic in the article Misuse of the Term System of Record.

What we noticed when looking up the system of record topic is the presentation of a different idea which uses the term system of record as a counterpoint. The concept presented is that why ERP systems are the system of record, what is required is a system of engagement.

In this article, we will analyze this concept as explained in an article from Forbes.

What is a System of Engagement?

Probably the best way to explain what a system of engagement is, and how it is presented is to provide a quote.

“There’s an ongoing discussion in the enterprise software world about “systems of record” vs. “systems of engagement.” Which do you have?

“Systems of Record” are the ERP-type systems we rely on to run our business (financials, manufacturing, CRM, HR). They have to be “correct” and “integrated” so all data is consistent. And they were traditionally designed for people who have no choice but to use them.

“Systems of Engagement” are systems which are used directly by employees for “sticky uses” – like email, collaboration systems, and new social networking and learning systems. They “engage” employees. – Forbes

Here the system of record is presented not only as the ERP system (which is a deliberate inaccuracy presented by ERP vendors), but as other systems as well. It is strange to read a CRM system being an “ERP type system,” and it would be more accurate to use a different term, but what the author is driving to seems logical.

“Today we are in the middle of a transition away from “systems of record” toward “systems of engagement.” If you look at SAP’s new Employee Central or Oracle’s Fusion and compare it to older SAP and Oracle applications, it’s like night and day. And these systems, which have come a long way, still have not caught systems like Silkroad and Workday.” – Forbes

This is where the concept runs into problems. This is because both the older systems and the newer systems are “systems of record.” It just so happens that the newer systems are easier to use. This problem illustrates why the term system of record should not be used to describe older systems as it almost serves as a proxy for the term “legacy.”

The Ripe and Common Misuse of the Term System of Record

This example aligns with our earlier observations regarding the term that the vast majority of people that use the term system of record don’t understand computer systems very well. It is a prestige term which is grabbed quickly, without understanding its meaning.

“Take a look how HR systems have evolved over the years. The first, labeled “Green Screen,” is an old-fashioned 1980s style mainframe HR system (I grew up on these). IBM dictated what they looked like, believe it or not. This is a “system of record.”” – Forbes

Now, this is just becoming humorous. The author seems to think that “how easy a system is to use” determines if it is a system of record. That is not the definition of a system of record.

Systems of record have been around for quite some time. 

Historical System of Records

If one has a stone tablet that is used as a reference and has all the calculations used to engineer a pyramid, and excerpts of the tablet are kept on papyrus for pyramid foreman to refer to while at the construction site, then the stone table is the system of record. The term system of record has nothing to do with either how modern the data storage is, or how easy it is to use.

In the Christian religion, each denomination goes through a process where they accept some books as their “system of record” and reject others. This becomes the cannon of that denomination. In religions, quite a lot of people have ended up on the wrong side of a sword or pike for not agreeing with others as to what is the system of record.

One of the best movies that illustrate religious disagreements is the movie Elizabeth. Throughout the movie, various people demand that others submit to “the one true faith.” Sound familiar. Perhaps you have heard the term “one source of truth” while sitting in an IT meeting?

Therefore, it shortsighted to only consider the term system of record, considering the concept has been with human societies as far back as the written language has existed.

Conclusion

Using the term system of record in the way used in this Forbes article is unnecessary, and it is not used correctly. This is because it is being used, as the term mostly is, by a person with only a fleeting grasp of how computers work. It is perfectly fine to say that systems should become easier to use…everyone agrees they should be. But there is no need to invoke the term system of record to make this case. A system of record relates to the origin and authoritative reference point of a system as it relates to data. It can’t be converted to mean older systems.

References

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.

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

https://www.forbes.com/sites/joshbersin/2012/08/16/the-move-from-systems-of-record-to-systems-of-engagement/3/#71d1b7e86227

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

The Misuse of the Term System of Record

What This Article Covers

  • What is a System of Record?
  • Misunderstanding What the Term System of Record
  • When Does the Term System of Record Normally Come Up?

Introduction

In this article, we will analyze the use and misuse of the term system of record.

What is a System of Record?

Let us begin with the official definition of a system of record.

“A system of record (SOR) or source system of record (SSoR) is a data management term for an information storage system (commonly implemented on a computer system running a database management system) that is the authoritative data source for a given data element or piece of information.

The need to identify systems of record can become acute in organizations where management information systems have been built by taking output data from multiple source systems, re-processing this data, and then re-presenting the result for a new business use.

In these cases, multiple information systems may disagree about the same piece of information. These disagreements may stem from semantic differences, differences in opinion, use of different sources” – Wikipedia

The system of record for ERP originated information is ERP, however beyond that the other systems that originate their data are the systems of record.

So where did the myth develop that ERP systems are the system of record in the company?

The answer to that turns out to be predictable….from ERP vendors and consultancies that make money from installing and maintaining ERP systems.

Misunderstanding What the Term System of Record

The use of the term system of record comes from a deep lack of understanding as to what a system of record is (as you know Ahmed).

ERP vendors are greatly to blame for this, but ERP is not system of record for fields it does not originate. If we take a non-ERP application, that application will have fields that ERP does not have. So what is the system of record? It is the non-ERP application. Therefore the idea that ERP systems are “the system of record” is just false, and false in an easily provable way.

When Does the Term System of Record Normally Come Up?

When the term comes up and who uses it tells us a lot about the term. We find it curious that people that use the term the most often tend to not work on the software side and are non-technical. Rather, they tend to work management. In all my daily technical discussions I do not recall anyone using the term “system of record.” However, in the meetings with the high-level people, or in demos with a lot of salespeople involved all of a sudden the term starts being uttered.

This tells us that the word is a term of propaganda and a term of prestige adopted by non-technical people to seem like they are technically savvy.

Conclusion

ERP systems just don’t do what they said they would do for customers. The only way around that observation is to try to ignore it. That is what is happening en mass right now with ERP systems. And when you compare it to what was promised, its like night and day.

Ignoring obvious outcomes that are inconsistent with the original intent or proposals is a major part of the human experience, and is how we keep from having to admit how wrong we often are.

However, calling the ERP system a system record does not fill in this chasm, and it does not have a useful meaning for the management of systems.

References

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.

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

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

Niche Areas and ERP Customization

What This Article Covers

  • The Truth About ERP Systems
  • The Fake Swiss Property S/4HANA Case Study
  • The Overinvestment into CRM Development
  • The Deceptive/Secret Level of Customization on ERP Implementations

Introduction

ERP systems have become very overapplied. In this article, we will discuss a question we received regarding a narrow application — called construction management.

The Truth About ERP Systems

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

The Fake Swiss Property S/4HANA Case Study

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

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

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

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

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

The Overinvestment into CRM Development

There is a great overinvestment into CRM development. CRM systems, in my view, can be just as well created by using a simple online database like Airtable. But CRM a “hot” software category, so it gets too much development resources. CRM systems have probably a negative ROI, but because they are still “hot”, they keep getting tons of development.

What Happens for Companies Looking for Solutions in Niche Areas

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

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

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

The Deceptive/Secret Level of Customization on ERP Implementations

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

Conclusion

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

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

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

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

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

References

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.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

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

What This Article Covers

  • Understanding the F-22 Program
  • Quotes from Scientific America on the F35
  • F-22 and F-35 Failures
  • Continuing the Unending Fiasco that is the F-22 and F-35
  • The Political Engineering of ERP
  • Pushing Customers to Reinvest in Low or Negative ROI ERP Systems
  • The Example of S/4HANA
  • How ERP Vendors Overstate the Integration Argument
  • Maintaining a Portfolio of Applications that are Not the Expertise of the ERP Vendor
  • Driving Industry Consolidation

Introduction

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

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

Understanding the F-22

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

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

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

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

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

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

Quotes from Scientific America on the F35

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

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

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

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

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

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

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

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

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

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

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

The Political Engineering of ERP

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

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

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

In the Vox video, it states.

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

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

Pushing Customers to Reinvest in Low or Negative ROI ERP Systems

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

The Example of S/4HANA

For the past three years, SAP has been telling a wide variety of lies about S/4HANA in order to…you guessed it, get companies to redirect even more money into ERP, even though companies that do this will have little hope of getting this investment back. S/4HANA is an amazingly brazen example of how many ERP vendors harvest their accounts in that SAP’s demand that customers pay for what is merely and upgrade to ECC and should be covered by SAP’s 22%+ yearly software support fee. (we covered this topic in the article Why S/4HANA Should be Free). SAP does not worry about their claims about R/2, R/3 and ECC not coming true, they have simply pushed the claims forward to S/4HANA. For example, SAP has stated that running MRP and end of period close is really horribly problematic in ECC, and therefore companies should move to S/4HANA. However, curiously, when SAP was selling companies on moving to ECC, they did not at time point out how horribly ECC was in these two processes.

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

How ERP Vendors Overstate the Integration Argument

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

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

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

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

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

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

Driving Industry Consolidation

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

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

Conclusion

None of the ERP vendors ever proved the early claims that ERP would have an ROI or that they would improve the operation of companies. In fact, several of ERP vendors claims, ranging from best practices to re-engineering to ERP being the only system a company would ever need, is now in shambles. But luckily for the ERP vendors, people generally do not have very good memories, and there is now good evidence that digital media and a number of other modern factors is making this worse, further eroding both attention span an memory. If we had a properly functioning IT media system, IT media entities would cover where software vendors and consulting companies made projections that ended up not coming true. However, the IT media systems are themselves paid by the largest IT entities and therefore they are actually part of the problem. Because of this all of the things that ERP vendors (and Gartner, and the major consulting companies, and IT media) said would happen because of ERP, they are not held accountable for being so wrong.

Companies that have ERP systems are at a distinct disadvantage when doing things like running MRP. When companies purchased ERP systems they had no idea that the systems could not survive without keeping legacy systems (or heavy customization), spreadsheets, and Scotch Tape. Yet the orientation of most companies is to “get as much as possible” out of their ERP systems, whether or not the ERP system is any good at doing what it is tasked with doing. Outside of the supply chain system being integrated into the financial system, nothing else that the ERP vendors claimed came true.

ERP became popular and continues to be the largest category of enterprise software not because of its technical capabilities, and not because of what it does for customers, but because as with the F-22/F-35, ERP systems were politically engineered. And the major IT media entities, IT analysts, ERP vendors and ERP based consulting companies, all of whom were part of ERP’s financial engineering have any interest in having any of this known.

References

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.

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

https://www.scientificamerican.com/article/what-went-wrong-with-the-f-35-lockheed-martins-joint-strike-fighter/

http://nationalinterest.org/blog/the-buzz/the-real-reason-the-us-air-force-wont-build-new-f-22-raptors-15920

https://www.politicopro.com/defense/whiteboard/2016/04/thornberry-supports-study-on-restarting-f-22-070837

http://www.popularmechanics.com/military/aviation/a13820424/f-22-drug-lab-afghanistant/

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

Enterprise Software Risk Book

Enterprise Software Project Risk Management: How to Control the Main Risk Factors on IT Projects

What the Book is About

This book is tied to the book Enterprise Software Selection. This is because the first place to manage risk is during the software selection phase, which is the opportunity to connect the best available application to the business requirements. There are of course many other risks that require enterprise risk management after the software is selected and implementation has begun. This is the first book to focus on the interpretation aspects of enterprise risk management in term of the information that is received from the main information providers such as consulting companies, vendors and IT analysts. The book explains how to triangulate on data sources, and is less about the mechanical aspects of enterprise risk management — which is covered in other books and online material. It is much more focused on providing practical information from years of experience in enterprise risk management and seeing the how companies can often struggle to find accurate information and unbiased advice on the topic of enterprise software decision making. Surprise, not all information providers in this area actually lead companies to risk-appropriate decisions, and the book covers how many of the techniques that implementing companies use as shortcuts to reduce the t

This is the first book to focus on the interpretation aspects of enterprise risk management in term of the information that is received from the main information providers such as consulting companies, vendors and IT analysts. The book explains how to triangulate on data sources, and is less about the mechanical aspects of enterprise risk management — which is covered in other books and online material. It is much more focused on providing practical information from years of experience in enterprise risk management and seeing the how companies can often struggle to find accurate information and unbiased advice on the topic of enterprise software decision making. Surprise, not all information providers in this area actually lead companies to risk-appropriate decisions, and the book covers how many of the techniques that implementing companies use as shortcuts to reduce the risks of their projects actually increase the riskiness of their implementations.

  • Vendor Risk Management
  • Enterprise Risk Management
  • Risk Assessment
  • Client Specific Risk Assessment

A Book Based in Reality

The book provides many examples from real life project experiences, the emphasis being on the reality of planning projects.

Interconnected to Web Information

Buy Now

Chapters 

  • Chapter 1: Introduction
  • Chapter 2: Enterprise Software Risk Management Misconceptions
  • Chapter 3: The Basics of Enterprise Software Risk Management
  • Chapter 4: Understanding the Enterprise Software Market
  • Chapter 5: Software Sell-Ability Versus Implement-Ability
  • Chapter 6: Controlling for IT Consulting Advice
  • Chapter 7: How to Use The Reports of Analyst Firms Like Gartner
  • Chapter 8: How to Interpret Vendor Provided Information to Reduce Project Risk
  • Chapter 9: Evaluating Implementing Preparedness
  • Chapter 10: Using TCO for Decision Making
  • Chapter 11: The Software Decisions’ Risk Component Model Defining The Components of Risk

How to Understand Reengineering and its Impact on ERP Sales

What This Article Covers

  • Reengineering and Michael Hammer & James Champy
  • Michael Hammer & James Champy Foundational Assumption Regarding IT
  • Reengineering and ERP as Natural Bedfellows
  • Some Interesting Questions to Consider About Re-engineering
  • The Evidence for Re-engineering Being the Elixer for IT Improvement
  • The Reality of Post ERP Sales
  • ERP Vendors and Consulting Companies Unite!
  • Taking the Re-engineering Application Test
  • Reengineering and Digital Transformation

Introduction

Different people have covered reengineering in depth from the process perspective. However, the issue is that the re-engineering was a major trope which was used to justify ERP systems. One vendor, SAP incorporated reengineering in a major way to cover up limitations in its software.

In this article, we will cover the self-serving nature of re-engineering and ERP.

Reengineering and Michael Hammer & James Champy

Michael Hammer and James Champy produced the book Reengineering.

No understanding of re-engineering can be understood without understanding this book.

One quite representative quotation was the following:

“The usual methods for boosting performance—process rationalization and automation—haven’t yielded the dramatic improvements companies need. In particular, heavy investments in information technology have delivered disappointing results—largely because companies tend to use technology to mechanize old ways of doing business. They leave the existing processes intact and use computers simply to speed them up.”

Michael Hammer & James Champy Foundational Assumption Regarding IT

Hammer & Champy’s assumption was that..

  1. The present business process used by the company was inadequate and needed to be redesigned.
  2. Furthermore, the failure to do this is why IT investments have delivered disappointing results

I have to say, having worked on quite a few projects myself, I do not share this interpretation. And if I think of SAP ECC, I don’t recall anywhere that the application was really pushing “the envelope.” The reason being that ERP systems contain quite generic functionality.

But the functionality that was included in the ERP systems could never meet every requirement in the business.

  • Pushing Generic Functionality: What have seen on ERP projects is the term best practices and re-engineering used to justify moving to generic functionality within SAP.
  • Removing that “Awful” Legacy: There was absolutely nothing in the functionality that was better than the functionality it was replacing in “legacy.” It was just what SAP had to offer. So, of course, it was “great.”

And because SAP and the consulting company wanted the “client” to use the system, they told the customer that the way they were doing it was wrong (not a best practice) and that they needed to change to how SAP did things.

What a surprise that the “right answer” was contained in SAP.

  • The Unpopular Reality: In reality, many processes simply can’t use SAP ECC or other ERP functionality.
  • Mass Customization: This is where customization and custom programming came in. For a standard system with “best practices” around 92% of SAP implementations became either highly or moderately customized. And at virtually every account, the amount of customization necessary greatly exceeded the estimate.

Over and over SAP told companies to redesign their processes and use SAP’s standard functionality, but it simply was not feasible for the vast majority of functionality. A massive industry built up around coding in the highly inefficient SAP ABAP coding language to place these customer processes into SAP. This was covered in the article Why Did Customers Listen to SAP on ABAP and Coding Tools? 

And when SAP recently introduced a new ERP version with a new table structure which broke all the previous customizations, SAP again pushed the narrative as this being not a bad thing, but an “opportunity” to review if these customizations were actually necessary.

Reengineering and ERP as Natural Bedfellows

  • ERP is based upon a basic exaggeration of the degree to which the application fits with the requirements of a company.
  • During the ERP sales process, the sales team will normally try to present the idea that any requirement the company has can be met by the application.

This is how you win the sale.

You make the software seem to be easier and smoother to implement than your competitor. It is extremely difficult to not get caught up in the misrepresentation of software to prospects. As a presales consultant, you constantly work with salespeople who have a 100% focus to make sales. But there is too much competition in enterprise software to make sales by telling 100% of the truth. It is very easy to begin focusing on the incentives of salespeople and to be sucked into oversimplifying the implementation work necessary. And if you do not provide the positive information that the salesperson desires, they will provide you with negative feedback if they see you interfering with making a sale.

In enterprise software sales, the presales consultant is part of the sales organization and is reviewed by salespeople. And I say this as a person with many years of SAP implementation experience and as a person who worked as a contractor (rather than an employee) and had other work I could switch to. Most presales resources do not have this and most presales resources are full-time employees of the software vendor, so for them, it is even more difficult to resist the pull of the salesperson. They serve at the pleasure of the account executive.

This means that ERP vendors sales teams compete to make their offering seem like the best fit. Now this same issue applies to other software categories as well. It applies to a more extreme degree to ERP because ERP was always sold with the underlying concept of being able to cover the broadest number of requirements that the company had.

And which software vendor has the biggest interest in promoting changing or “re-engineering” your business processes?

The vendor with the weakest match between its software and the customer’s business requirements of course.

Some Interesting Questions to Consider About Re-engineering

All of this brings up some interesting questions.

  • Question 1: ERP vendors greatly benefited from Hammer & Champy’s messaging. Did any ERP vendor pay for Hammer and Champy to speak at conferences or otherwise use their resources to magnify the reengineering message?
  • Question 2: Did the consulting companies care whether re-engineering was true, or did they ride the wave?

You can guess for yourself what the answer to these questions probably was.

The Evidence for Re-engineering Being the Elixer for IT Improvement

The problem with Hammer & Champy’s hypothesis is that they never proved it to be true.

They merely asserted it. And asserting it, along with the financial incentives of those who wanted the message repeated was enough to have it accepted as true.

However, let us pull back for a moment to look at the question re-engineering was addressing.

A lack of IT payback has always been a problem with IT implementations. I have my own views as to why the payback has been disappointing. I several reasons, but if I had to bet money, my primary hypothesis would be that vendors like SAP and the large consulting companies overpromise and increase the cost of software implementation projects such that the ROI becomes quite frequently negative. I covered this in detail in the article How Vendors and Consulting Companies Parasitized the ROI of Enterprise Software. This is another explanation and I have much more evidence for it than was ever presented by Hammer and Champy for their hypothesis. It is unclear to me why Hammer & Champy’s explanation was so compelling.

Care to take a guess as to why IT investments tend to be disappointing? Many people have tried, and as far as I am aware, Hammer and Champy are not considered to have solved this puzzle. So why was an unproven hypothesis carried forward to the four corners of the world? 

The most logical explanation I can think of is that it was a compelling message for ERP vendors and for consulting companies, so it was the message that was paid to be repeated.

For some reason, I don’t expect to find SAP or Deloitte or Accenture paying to amplify this hypothesis.

The Reality of Post ERP Sales

Reengineering was and is a concept (although its popularity has certainly declined) that help both sell the ERP system, and cover up for the lack of coverage of requirements that eventually became apparent once the requirements had been gathered and the time came to configure the requirements into the application.

Reengineering was used by SAP in conjunction with the concept of best practices to essentially convince customers to use the software as standard as possible. And that within this “standard” contained best practices. Now there was never any evidence that these were best practices. It was simply a self-bestowed title. Much like me saying..

I am the best dancer in Atlanta.

Actually, it is even worse than self-proclaimed titles of being the best dancer in a particular city, as there is no competition you can enter to determine if something is a best practice. At least dancing competitions exist.

This was consistent with what SAP and other ERP vendors tended to do to dismiss whatever existed inside their customers and built up whatever they had to offer.

  1. Legacy: The term legacy, which is pejorative, was used by SAP to dismiss any system that existed inside of the customer that was not SAP. This is explained in the article How SAP Misused the Term Legacy. Existing systems are legacy by vendors trying to sell software in the same way that furniture is out of date in people’s homes by people trying to sell new furniture.
  2. Best Practices: SAP took the best of whatever process they ran into and put it into their software — well that was the official story. But as an SAP researcher, it is also the case that SAP lies a lot. And as a long time SAP consultant, I can say I never witnessed any best practices inside of SAP’s numerous applications. But how SAP used the term best practices to gain business is covered in the article The Evidence Against SAP’s Best Practice Claims.

ERP Vendors and Consulting Companies Unite!

  • What both the ERP vendors and consulting companies wanted to do was bill hours. And you can’t really bill hours by keeping things the same.
  • Therefore, the argument for change is something that software vendors and consulting companies tend to accept quite readily. Whenever something means a change, you can count the consulting companies “in.”

Who were the major promoters of reengineering — ERP vendors and consulting companies. And who were the major beneficiaries of reengineering — ERP vendors and consulting companies.

And oh yes, this was lucrative for them as the following quotation from Thomas Davenport, someone deeply involved with the re-engineering trend attests.

“No one wants to see 25-year-old MBAs in their first year of consulting making $80,000 per year with $30,000 signing bonuses, being billed out at six times their salaries, putting the company’s veterans through their paces like they’re just another group of idiots who “can’t think out of the box.””

A feeding frenzy was underway. Major consulting firms could routinely bill clients at $1 million per month, and keep their strategists, operations experts, and system developers busy for years.

For their part, executives had to show financial benefits – especially at those consulting rates. The fastest way to show financial results was to reduce headcount.

Thomas Davenport goes on to explain why reengineering became such a fad, and it fits with financial bias.

How did reengineering go from a decent idea in 1989 to a $51 billion industry in 1995? Chalk it up to the rise of the Reengineering Industrial Complex. Just as the concept of re-engineering wove together three previously unrelated strands, its application brought together an iron triangle of powerful interest groups: top managers at big companies, big-time management consultants, and big-league information technology vendors.

Conclusion

Reengineering died as a fad over two decades ago. It bears the markings of many other fads.

  • Step 1: A Kernel of Truth: It begins with a kernel of truth (yes, it makes sense to design processes around value add).
  • Step 2: Jumping on The Bandwagon: Entities that can make money from it jump on the bandwagon and begin to repeat the messaging. At this point brand name companies are thrown out that have benefited from the fad.
  • Step 3: The Association Phase: The fad begins showing up on resumes, certifications begin to become available to be prominently displayed in offices and cubicles (belts, ribbons, medals and merit badges are handed out with aplomb!)
  • Step 4: The Implementation Phase: It promptly becomes an excuse for whatever one wants to do. Whatever change initiative the company had before, are renamed to the new fad.

Reengineering no longer has the cache it once did, so now one must introduce the redesign under the rubric of Six Sigma.

Business trends come and go, and I don’t have a particular interest in them as there are always lemmings to jump on the next new “hot thing.”

However, the interesting thing to me as a researcher is that in a way, reengineering lives on as a way to justify software that is a poor match for business requirements.

To see why take a look at the following test.

Taking the Re-engineering Application Test

Imagine two software vendors:

  1. Software Vendor A: This vendor has a very high match between its functionality and the business requirements of a prospect.
  2. Software Vendor B: This vendor has a low match between its functionality and the business requirements of a prospect.

Now close your eyes and answer this question.

Which vendor is going to be more supportive of the prospect engaging in “re-engineering” to successfully purchase and implement their application?

Conclusion

Ironically, in our application risk ratings, we concluded that the highest predictive element for software success was the match between business requirements and the functionality of the application. Yet, re-engineering works against this. Re-engineering justifies purchasing applications that are a poor fit for customer requirements under the principle that the process can be re-engineered.

In this way, at least in the ERP realm, re-engineering qualifies as fool’s gold. And while re-engineering washed out, in a way at least a similar concept has been renamed as digital transformation. Digital transformation is a curious term as it is utterly false if used to describe modern IT implementations. Why is the term reengineering not used? Terms are changed when they lose credibility.

References

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.

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

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

https://www.fastcompany.com/26310/fad-forgot-people

https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate

SAP Labs Publishes Dishonest Paper About ERP

What This Article Covers

  • Interesting Quote on ERP Commodification
  • How Accurate Were the Predictions
  • The Problem with Industry Promoted Fake Research

Introduction

“Some mature information technologies, such as ERP systems and relational databases, are now undergoing commoditization, much like what happened in the automotive and chemical industries over the past 15 years. This trend is accelerating by reducing IT spending because of slowing economic growth.

I see big technology and business model changes coming from ERP. New technology trends such as high-performance computing, pervasive connectivity, Web services, and SOA will affect the front end as well as the back end of ERP.

….an ERP’s average life cycle is about 15 years.”

This is a study from SAP Labs. Interestingly none of these things happened in the roughly nine years since this was published. SOA and web services went nowhere. High-performance computing has had no effect on ERP.

SOA lets developers partition and decouple applications. It provides a bridge between incompatible technologies.

No one did more to undermine SOA than SAP. SAP is based upon coupling applications and restricting competition. Why would they want to decouple applications?

Web services are ideal for letting developers adapt ERP to fast-changing business processes. Web services can be orchestrated to create multi-service business processes that connect via SOA to the robust and reliable back end….

Once again, no one did more to undermine this than SAP. SAP does not want flexibility or open systems. But people who work for SAP Labs are not going to put this in a paper.

Conclusions

This is a completely dishonest paper written by SAP Labs and should not have been accepted as a research paper. There is much more in it that what we have quoted, but it is all primarily self-serving information for SAP, and as we described, none of it came true. It obscures the fact that SAP as a matter of policy undermines the supposed openness trends that are a big part of the paper.

This paper was written by Paul Hofmann who is Vice President of Research at SAP Labs. He has a Ph.D. in physics from Technical University in Darmstadt Germany.

However, this demonstrates that private industry research offerings can’t seem to do much more than serving as marketing puff pieces for the company they work for. This is why private research has such a poor reputation. This paper should not have been accepted for publication.

References

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.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

ERP is Deal, Long Live ERP. SAP Labs, Published by the IEEE Computer Society, Paul Hoffman. 2008.

1 2 3