How ERP System Was a Trojan Horse

 What This Article Covers

  • The Presentation of the Integrated Suite Concept
  • Virtually All Applications (Integrated Suite or Point Solutions) Are “Integrated”
  • The Reality Around Adapters
  • After the Acquisition of a Vendor, How is The Integration Story “So Much Better?”
  • Integrated Suites Tend to be More Expensive in Multiple Dimensions (i.e., Have a Higher TCO)
  • Integration Suites as a Way to Reduce Competition?
  • Integration is Not a Primary Driver of TCO
  • Consulting Companies Focus on TCO or Set About Maximizing TCO?
  • How Consulting Companies Undermine any Intelligent Software Selection Process for Their Own Ends
  • The Most Important Feature in the Software Correlated to Implementation Success
  • An Often Repeated Evidence-Free Assertion
  • How Competition in Enterprise Software Works
  • The ERP System and Horizontal Enterprise Software Competition
  • Industry Consolidation
  • Ignoring The Reduction in Choice
  • What is Account Control?
  • The ERP System as the Queen
  • ERP-Centric Strategy?

Introduction

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

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

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

The Presentation of the Integrated Suite Philosophy

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

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

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

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

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

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

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

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

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

The Reality Around Adapters

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Integration Suites as a Way to Reduce Competition?

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

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

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

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

Integration is Not a Primary Driver of TCO

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

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

Consulting Companies Focus on TCO or Set About Maximizing TCO?

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

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

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

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

Hypothesis Testing

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

“Is there a way to test this hypothesis?

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

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

The Most Important Feature in the Software Correlated to Implementation Success

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

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

An Often Repeated Evidence-Free Assertion

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

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

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

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

How ERP Systems Were a Trojan Horse

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

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

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

How Competition in Enterprise Software Works

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

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

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

The ERP System and Horizontal Enterprise Software Competition

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

Industry Consolidation

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

Ignoring The Reduction in Choice

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

What is the Specific Comment

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

What is Account Control?

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

The ERP System as the Queen

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

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

ERP-Centric Strategy?

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

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

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

Conclusion

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

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

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

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

ERP Contact Form

  • Interested in More Research and Analysis?

    Have you noticed the vast majority of sources on ERP are pro-ERP? There is a reason for that. ERP has created an unending revenue stream for consultancies and media entities. However we are one of the very few truly independent sources of information on the areas we cover.

    • We can be used to answer a specific question.
    • We can be hired to provide more details on existing research or to perform new research.
    • We can tell you what is happening on implementations on other projects.
    • We can verify proposals and statements made by consulting companies or software vendors (typically a good idea!).
    • Once we know more we can provide a quote as well as what you can expect to receive.

    Just fill in your contact details in the form below.

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

Leave a Reply

Be the First to Comment!

  Subscribe  
Notify of