- Reengineering was a massive trend in consulting that fizzled out.
- While discredited outside of ERP, the concept continues to influence ERP implementations.
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..
- The present business process used by the company was inadequate and needed to be redesigned.
- 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.
- 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.
- 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.”
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:
- Software Vendor A: This vendor has a very high match between its functionality and the business requirements of a prospect.
- 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?
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.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other ERP Content
The Real Story on ERP
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.
- 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