Is a Lack of Business Process Reengineering the Reason ERP Projects Fail?

Executive Summary

• We cover a quotation from Panorama on ERP failure, which places most of the blame on business process reengineering.
• This caused us to analyze the history of business process reengineering.

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 it points in a different direction. In this article, we will be evaluating whether BPR or business process re-engineering and organizational change management are why ERP projects fail.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

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 with, 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 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 they had to be customized.

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

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

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

What is True?

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

Furthermore, the statement by Panorama, while undoubtedly 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 widespread 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 misled as to the entire “best practice”/BPR construct. We can say this confidently as there is evidence from many public projects to draw on 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 huge number of custom military systems. Change management would not have been an issue because Oracle’s ERP does not do specialized military functions. ($ billion sounds like a lot of money until you realize it’s 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 the process industry, but they lack the functionality to manage manufacturing processes. 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. In this case, it is not BPR because it is an extensive series of gaps in functionality.

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 actually be to select an ERP system that has process industry functionality. However, that would take a 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 project’s real failure was due to the inflexibility of the customer to do BPR. The major IT implementation companies agree 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 IT Media Funding dictates the Coverage of IT Failures from Software Vendors and Consulting Companies

The vendors and consulting companies provide most of the funding to the IT media entities. 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 customers paid them, they would switch their reporting, but they have no other income source than the IT software and service providers. Media companies like ComputerWeekly are not real media outlets in the usual sense of the word but are fronts for marketing automation, collecting emails from articles that 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.

How to Understand Reengineering and its Impact on ERP Sales

Different people have covered reengineering in depth from the process perspective. However, the issue is that the re-engineering was a significant trope used to justify ERP systems. One vendor, SAP, incorporated reengineering in a significant 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 the Corporation.

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.

Having worked on quite a few projects myself, I have to say I do not share this interpretation. And if I think of SAP ECC, I don’t recall anywhere that the application was 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: We have seen on ERP projects 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 replaced 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 needed to change how SAP did things.

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

• The Unpopular Reality: In reality, many processes 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.

SAP told companies to redesign their processes and use SAP’s standard functionality over and over, 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 necessary.

Reengineering and ERP as Natural Bedfellows

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

This is how you win the sale.

You make the software seem to be easier and smoother to implement than your competitor. It is challenging not to get caught up in the misrepresentation of software to prospects. As a presales consultant, you continuously work with salespeople who have a 100% focus on making sales. But there is too much competition in enterprise software to make sales by telling 100% of the truth. It is straightforward to begin focusing on salespeople’s incentives and be sucked into oversimplifying the implementation work necessary. And if you do not provide the positive information that the salesperson desires, they will give you 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 challenging 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 refers to a more extreme degree to ERP because ERP was always sold with the underlying concept of covering the broadest number of requirements that the company had.

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

This is 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 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 stating 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 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. 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 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 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 undoubtedly declined) that help sell the ERP system and cover-up for the lack of coverage of requirements that eventually became apparent once the requirements had been gathered. 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 merely a self-bestowed title. Much like me saying..

“I am the best dancer in Atlanta.”

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 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 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 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 significant 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 explains 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.”

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 a prospect’s business requirements.
2. Software Vendor B: This vendor has a low match between its functionality and a prospect’s business requirements.

Now close your eyes and answer this question.

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

Ironically, in our application risk ratings, we concluded that the highest predictive element for software success was the match between business requirements and the application’s functionality. 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.

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 conglomerates own out of a country with 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 most significant vendors and consultancies in your space.

Major vendors fund industry specialists 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, 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 not to do customizations and do more BPR. However, the central hypothesis around not doing customizations is based on 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 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 many academic papers. Therefore the right interpretation of when a person states, “my software contains best practices,” is “I am going to trick you.”

Fake Best Practices

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

Why Strategy Consultants Do Not Add Value on SAP Projects

Hypothetically it would seem those strategy consultants could add some value to SAP implementations. Often the business at the client needs assistance in developing requirements. Frequently, this requires quantifying many things that the business often does not have either the time to analyze or the ability to analyze.

Strategy consultants look at the world a bit differently than software implementers. Because they don’t put their hands on much of anything and are trained to be expansive in their thinking, they often make projections based upon very little real-world data.

The Reality of Strategy Consulting

However, in my experience, the reality is quite different than the hypothesis. One of the problems is that most strategy consultants are not particularly practical. They primarily make their money by bringing “trends” to companies to implement. One year the trend might be “Lean,” the next year, it might be something else. Because they are trained to think at such an abstract or unrealistic level, they are not very useful in helping the business drive any realistic requirements.

Furthermore, strategy consultants generally don’t have an excellent idea of implementing their ideas and are very infrequently called on to do this. Because they are not tasked with this, their solutions will often lose any semblance of practicality in favor of what could be called “sex appeal.” If one looks at old strategy presentations ten years after their initial creation, one will notice that many of the projections seem to have a low accuracy level. I was once on an SAP project where strategy consultants encouraged the business users to put anything that they wanted on the list. They were encouraged to “think outside the box” and come up with anything that essentially their hearts desired. This was done even though the solution was already selected. This is an activity that should be performed before software selection, not after software selection.

What if the business comes up with things that the software cannot do (which they invariably will). Then what? This is, in essence, the problem. Strategy consultants increase the expectations for the customer. Still, they don’t do anything to meet those expectations because they just come up with ideas that are unbounded by real-world constraints.

Cultural Issues with Prima Donas

A second issue is culture-related. Culturally strategy consultants are taught to have a very high level of entitlement. Part of the training that the large firms give strategy consultants is to exude arrogance, as this can be mistaken for confidence on the client’s part. Most strategy consultants see IT consultants, as “mechanics” and do not generally work with them very well, making it difficult for them to work successfully on SAP implementations.

Thirdly, most strategy consultants are not mainly quantitative. Most of their work is based upon interviews, not on data analysis, and because they lack these interests and skills, they are not very comfortable asking for extracts from the IT department. I worked with several strategy consultants on an evaluation project. It turns out that by the time I had arrived on site, the strategy consultants who were there had utterly alienated the client’s IT department, which would not provide them with any data. I spent time mending fences by merely showing people in the IT department standard everyday consideration and soon made progress in obtaining data.

However, after I performed the analysis and presented it and in passing told the strategy consultants that they needed to work better with the client IT department, the strategy consultants said to me that they did not have to because they would “roll them over” if they pushed back. Strategy consultants only really think of engaging at the higher levels and little interest in working at the level below this.

The Example of Poor Quality MRP Functionality in ERP Systems

If we take a foundational area 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 ERP results 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 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 cloudy but 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 about 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 the ERP cloud. The customers they do have on the cloud are tiny customers that don’t have customizations and 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 merely be purposefully misidentified as BPR (the vendor and consulting company friendly conclusion). This is true 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.