The Problem with Being Trapped by ERP

Executive Summary

  • ERP systems were introduced with great promises and fanfare, pushed by financially incentivized entities.
  • Now decades after, the research shows few benefits to ERP, but high costs. And customers are trapped in their ERP.

Introduction

ERP systems were aggressively marketed as fixing nearly all the ills that companies faced. In our book The Real Story Behind ERP, we evaluated all of the academic research and found that ERP systems have no history of producing an ROI. A major reason is that ERP systems are simply not that advantageous, they impose high maintenance costs, and the implementations of ERP have become parasitized by consulting companies that increased the costs of implementations, as we covered in the article How Vendors and Consulting Firms Parasitized the ROI of IT.

Out of the Fantasy Stage of ERP and Into the Reality Stage

In the 1980s and 90s, the case was frequently made the ERP systems would be transformational. They would become…

“The only system that any company would ever need, eliminating the overhead of integration between many systems and bringing best practices to companies globally.”

In the modern age, now that nearly every company has an ERP system, it is much less common to hear such rosy projections about ERP. What has replaced the hallucinating is pragmatic discussions around how an ERP system is a “necessity.” However, another observation is that companies can’t leave ERP systems because they have invested so much into them, and this means they are essentially trapped.

The following quotation highlights this exact issue.

“Granted that most ERP systems do not live up to expectations but what is the alternative? Having best of breed systems in the cloud is not going to help either. It will only result in more integrations and more potential for errors. The problem that most organizations face is that they have already implemented an ERP system. Now all their digital transformation initiatives result in quick and (dare I say) agile cloud solutions / mobile apps which then need to be integrated back to either the ERP system or a reporting solution/ data warehouse. Therein lies the problem. Customer information is now spread across multiple systems and someone in the organization suddenly wants campaign analysis or better still an AI analysis that needs information from ERP and other systems. And obviously the ERP system should now do this instantly or else it gets tarred with being slow and unresponsive.” – Jayshree Ravi, ERP Manager 

And the following quotation.

The most important solution ERP systems offer is that there is a single data structure supporting them. The most important disadvantage is that the single data structure inherently needs to be very complex and can hardly be used other than for transactional processing. Bottom line ERP systems replace good data architecture, which should form the basis of tooling choices, allowing a best of breed policy to be followed.” – Maarten van der Heijden

And the following..

I’ve observed the entire life cycle of ERP. Great analogies about the shift of previous industries. I’ve always thought ERP systems delivered a fraction of the promise and have always been really, really expensive FinApps. Sort of like sails that only capture 10% of the wind. ERPs should be kept on life support. Don’t yank it out. Don’t upgrade it. And for heaven’s sake, don’t replace it. A comment made earlier about the robust nature of the ERP ecosystem and sales/marketing influence is not to be ignored. Hopefully, since ERP’s have been ineffective since their inception all the ERP fanboys at the customer retire and the next generation strip ERP down to its value. Maybe stop paying maintenance contracts and support staff to patch the holes in the ERP sail and apply 75% of that savings toward tools that actually enhance your enterprise. Better systems and process, happier users/employees and a 25% savings to take into the board room? That’s an agenda any executive would be happy to support.” – Steve Christensen

How Really Likes ERP Systems?

Well, it certainly is not customers!

Having been on many customer accounts there is never much excitement when discussing the company’s ERP system. Mostly is it “just there” and is something to contend with, something in many cases to work around, rather than anything viewed as enabling the company. ERP systems were not supposed to need so many interfacing systems, but it turns out that the ERP system alone can’t do much more than the basic “blocking and tackling” needed by a company to account for inventory, post goods issue and manage the books. It is not that these are unimportant things, certainly, they are critical, but ERP systems have not demonstrated they are capable of much more than this.

However there is a category of people that are very impressed with ERP systems, and this is invariably ERP consultants. They are the most assertive proponents for ERP, not the buyers of ERP systems, and certainly not the users of ERP systems. When the strongest proponents of something are those that sell or install or service that item…..this naturally brings up questions as to the value to the consumer of that item.

Getting Out of the ERP Trap

Many have resigned themselves to the ERP trap. However, there are ways of either escaping the ERP trap or minimizing the ERP inefficiencies imposed on companies.

One thing to consider is that ERP systems impose high costs and mediocre functionality on a customer. So it is not only the cost side but the functionality that is worse than alternatives.

Considering the Resources that ERP Annually Consumes

The first thing to dispel is that there is something magical about combining a number of modules and calling it ERP. It isn’t. The idea that investing in ERP over custom applications would provide a significant benefit did not pan out. There is nothing to say that this can’t be reversed, then a major problem is that ERP is consuming so many resources every year. This was the genius of ERP marketing, and once you got in, it became difficult to get out. So in the short term moving away from ERP will be probably more expensive.

However, to get out of the clutches of an ERP vendor can in many cases be worth it. One way to cut the umbilical cord is to drop support and go with outside support. That will save money every year. Then one can begin to carve up the ERP system and migrate pieces to new things — this can be customized code in some cases, a best of breed solution in other cases.

Specific Areas of ERP that Can be Remediated

Let us take the topic of forecasting software. Some companies were told their forecasting would be covered in ERP. That was never true. There are great forecasting applications out there that can be used that actually allow the forecast accuracy to be improved. Let us take MRP and supply planning. Doing MRP in ERP is a ticket to adverse outcomes, which we covered in the article. Why Do Companies Use ERP for MRP?. That functionality can be migrated to a custom solution on AWS at low cost with vastly superior run times and outcomes in Real Time MRP. Order management is easy to improve with an outside web-based application, and at low cost with better integration to CRM. There are some excellent pure financial applications out there, or the finance portion can be kept from ERP for a while. Finance is most of what ERP systems have to offer in any case. Being stuck with ERP will increasingly hold a company back, and I see a swing back to custom solutions. This is being promoted by cloud services that make most of the ERP systems look entirely backward. Finally, the concept presented by ERP vendors is that ERP reduces integration. It does, but only really to the ERP system. However, ERP systems have integration to other systems.

Conclusion

Ahmed Azmi, of Brightwork, has the following to observation on this topic.

“People sometimes ask, if ERP is bad, what’s the alternative?

The comments immediately point to multiple cloud apps as alternatives and say that’s not better because of data silos and integration issues. In my opinion, the alternative to ERP is nothing. Don’t adjust with it if it works for you and do not replace it with multiple clouds. Innovate at the edge and focus on systems of customer engagement. Ask any “thinking” enterprise IT person who runs on-premises what’s your biggest pain been and they will all say integration and data silos. The gaps between departmental apps are so big, companies spend huge amounts of money on integrating data and workflows that span multiple departments. This problem is so big, an entire “integration” sub-industry was born to address it. Notice how much Excel is used at ERP customers to work around those integration gaps?

If the promise of ERP, process integration, was remotely realized by customers, they would never have had to spend so much time, effort, and money on systems integration.”

Financial Disclosure

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 Better Managing ERP Content

References

Repair MRP Book

 

MRP System

Repairing your MRP System

What is the State of MRP?

MRP is in a sorry state in many companies. The author routinely goes into companies where many of the important master data parameters are simply not populated. This was not supposed to be the way it is over 40 years into the introduction of MRP systems.

Getting Serious About MRP Improvement

Improving MRP means both looking to systematic ways to manage the values that MRP needs, regardless of the MRP system used. It can also suggest evaluating what system is being used for MRP and how much it is or is not enabling MRP to be efficiently used. Most consulting companies are interested in implementing MRP systems but have shown little interest in tuning MRP systems to work to meet their potential.re

The Most Common Procedure for Supply and Production Planning?

While there are many alternatives to MRP, MRP, along with its outbound sister method DRP, is still the most popular method of performing supply, production planning, and deployment planning. In the experience of the author, almost every company can benefit from an MRP “tune up.” Many of the techniques that the author uses on real projects are explained in this book.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Opportunities to Improve MRP
  • Chapter 3: Where Supply Planning Fits Within the Supply Chain
  • Chapter 4: MRP Versus MRP II
  • Chapter 5: MRP Explained
  • Chapter 6: Net Requirements and Pegging in MRP
  • Chapter 7: Where MRP is Applicable
  • Chapter 8: Specific Steps for Improving MRP
  • Chapter 9: Conclusion
  • Appendix A: Calculating MRP

Do You Suffer from (ECS) – ERP Centric Strategy?

Executive Summary

  • ERP centric strategy is a serious medical condition.
  • Learn about ECS and how it negatively impacts IT decision making.

Introduction

This was going to be a very different article than the ty’pe I ordinarily write. Today I want to talk about a serious topic. You see there is a silent disease-oriented around enterprise software decision making that goes undiscussed within companies.

The following shocking statistics apply to this disease.

  1. A recent study showed that executive decision makers at 4 out of 5 companies suffer from this mental affliction.
  2. Employees that use systems where executives have this affliction are eight times more likely to report that, for planning and analysis, the applications they use to get their work done.

“Totally suck!”

And

“…yea then at that point I have to export it to a spreadsheet…”

or

“…wait, and then after I download that, then I have to manually make the assignments, and then I…”

At this point, you have probably guessed that I am referring of course to the dreaded ERP-Centric Strategy.

ECS is a disease that affects the mind and its only observable through the subject’s statements, the propensity to overpay consulting companies for customization work, an obsessive use of Excel, and of course by the devastating effects on industrial productivity.

ECS is at epidemic proportions within companies, with many people hiding their symptoms from friends and family for years.

ECS sufferers can often be found looking out windows, saying things like..

“I just want to get more out of our ERP system.”

and

“I know that the ERP system can do it, we just need a little customization. How about just a little code!”  

or

“How hard can it be to create a forecast with our ERP system? The brochure said that it does forecasting right? I mean I thought I remember it said that it did…”

What is at the Heart of ECS?

Clinically, ECS is a form of wishful thinking combined with an oversimplification of how requirements must be met by software. The most foundational underpinnings of ECS are a fundamentally irrational belief in the following ideas.

  1. The ERP system should be emphasized above all other systems because “it’s the biggest.”
  2. The ERP system is the system of record for all data.
  3. ERP functionality should be used — even when it is weak in a particular area.
  4. Integration should be avoided at all costs.

The History of Mistaken Centric Thinking

ECS has many historical precedents. For the longest time, the Earth was considered the center of the known universe. Galileo created a huge stir when he said..

“…No, the Sun is actually the center.”

Telling people that what they think is the center isn’t is a dangerous business. Galileo was almost killed by the Roman Inquisition in 1633 for this observation.

It was later found that Pope Paul V suffered from Earth Centricism (EC), which is an early precursor to what we now call ECS. What this shows is mistakenly thinking that things that are the center that are not, goes back nearly 400 hundred years.(1)

The Effects of ECS

ECS is continuing to affect management and executive decision makers, and it has the following symptoms: 

  1. Thinking that the very limited functionality in ERP systems can meet all the company’s requirements.
  2. Consistently approving new requests for enhancing ERP to build common, high maintenance functionality, that should be fulfilled with applications outside of ERP.
  3. Repeating statements from the 1980s made by ERP sales people.

Those suffering from ECS don’t know that the idea that ERP could meet all or almost all requirements was never true. It simply started out as something that ERP vendor marketing departments made up; that was then promoted to executive decision makers by account executives.

These same ERP vendors who promoted ECS thinking soon abandoned the idea when ERP vendors started to buy other systems that they could also sell. However, those who suffer from ECS never got the memo.

Is There a Cure for ECS?

Fortunately yes, as bleak as ERP-Centric Strategy can seem, there is a cure. However, it’s not in the form of a pill. Executive decision makers can recover from ECS there is not anywhere you can go for treatment. There is no Betty Ford Clinic for ECS….not yet anyway.

ECS can be beaten, but important realities must be acknowledged to put someone on the road to recovery. Some of these are listed below.

  • The Big Tent Concept: ERP is simply a large footprint application that provides some functionality areas under one “roof.” It always needs other systems to do work in specific areas.
  • Getting Real on Spreadsheets and Customization: Spreadsheets and customization are performed when the ERP system cannot meet the business requirements. If customization is written, then the application is not meeting the demand, and one is at that point on par with using an external application.
  • Refocusing on the Objective of Enterprise Software Purchases: The objective to get business value out of the purchased solutions, and these means that applications must compete with one another by this concept.

Offering a Helping Hand for the Afflicted

I have studied ECS for a long time now and having seen the effects up close and personal. At first, I used just to scratch my head, but now I see it’s a real medical condition.

While not a physician, I have still successfully shown CIOs in companies that they can use point solutions to enhance their enterprise software categories, and that they don’t have to feel shameful about not “getting more out of the ERP system.”

I also have a book titled The Real Story Behind ERP: Separating Fact from FictionThis book can help stop ECS in its tracks, and it explains the entire history of ERP marketing, and then what happened in reality, and paradoxically how no one who said all the things that were used to sell ERP felt guilty afterward.

If you know someone who has ECS, send this book to them. I know that together we can beat this disease.

Financial Disclosure

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 Problems and Inefficiencies Content

<

References

Repair MRP Book

 

MRP System

Repairing your MRP System

What is the State of MRP?

MRP is in a sorry state in many companies. The author routinely goes into companies where many of the important master data parameters are simply not populated. This was not supposed to be the way it is over 40 years into the introduction of MRP systems.

Getting Serious About MRP Improvement

Improving MRP means both looking to systematic ways to manage the values that MRP needs, regardless of the MRP system used. It can also suggest evaluating what system is being used for MRP and how much it is or is not enabling MRP to be efficiently used. Most consulting companies are interested in implementing MRP systems but have shown little interest in tuning MRP systems to work to meet their potential.re

The Most Common Procedure for Supply and Production Planning?

While there are many alternatives to MRP, MRP, along with its outbound sister method DRP, is still the most popular method of performing supply, production planning, and deployment planning. In the experience of the author, almost every company can benefit from an MRP “tune up.” Many of the techniques that the author uses on real projects are explained in this book.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Opportunities to Improve MRP
  • Chapter 3: Where Supply Planning Fits Within the Supply Chain
  • Chapter 4: MRP Versus MRP II
  • Chapter 5: MRP Explained
  • Chapter 6: Net Requirements and Pegging in MRP
  • Chapter 7: Where MRP is Applicable
  • Chapter 8: Specific Steps for Improving MRP
  • Chapter 9: Conclusion
  • Appendix A: Calculating MRP

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.

How to Apply the Concept of Two Tier ERP to Your Company

Executive Summary

  • Two-tiered ERP is a specific way of managing multiple ERP systems.
  • This serves to explain how to apply two tier ERP in real terms.

Introduction

The basic proposal that two-tiered ERP reduces costs can be true. According to our research, the cost savings on the basis of total costs of ownership (TCO) can range from the a slightly negative cost savings (that is a cost increase) to roughly one fourth of costs when compared to the TCO of providing ERP functionality for users with a 100 percent tier 1 ERP strategy. However, it is not possible to ascribe a specific value to the cost savings estimate without knowing the following:

  1. The specific ERP systems to be used.
  2. How many ERP systems are in the mix.
  3. How many instances are to be modeled.

This is because the savings entirely depend upon factors such as the following:

  • ERP TCO Variability: ERP applications have a high variability in their total cost of ownership. There is also a weak relationship between the cost of the ERP system and its capabilities—meaning some of the best ERP systems are the least expensive—but also most often not included in a software selection as they lack the brand name, marketing, and coverage of IT analysts and recommendations of consulting companies.
  • The degree of Transition to the Tier 2 ERP Application(s): The more users are transitioned to the Tier 2 ERP application, the more money will be saved. If a company has a thousand total users and transitions seven hundred of them to a tier 2 ERP application, the predicted savings will be higher than if the same company were to transition only five hundred users to a tier 2 ERP application.

Reduced Costs

Of course, reduced costs are not the only benefits of two tier ERP strategy—one of the major benefits is having more diversity of functionality, and a better fit between the application and the business requirements. Too often this is lost in the story of cost reduction brought by two tier ERP. However, it bears emphasizing that following a two tier ERP strategy can lead to lower costs, but it is not automatic. It very much depends upon how the strategy is implemented. The benefits come down to the quality of the software selection and the depth of the analysis regarding the overall solution architecture of ERP systems.

Something that is also open to debate is how the ERP systems would be integrated. I have already stated that the commonly presented practice of integrating ERP systems to one another is less cost-effective than integrating all the ERP systems to a common or master BI system. Therefore, choosing to follow a two tier ERP strategy is really just the starting point of a series of questions, each of which must be carefully analyzed and effectively decided. If errors are made along the way, it is actually exceedingly easy to end up with a two tier implementation that nets the company little benefit.

Proponents of Two Tier ERP

Proponents present two tier ERP oversimplify the actual outcomes of following the strategy as if those that follow it essentially can’t lose.

Proponents of two-tiered ERP are correct when they state that the strategy can save companies money. However, in addition to exaggerating the cost savings, they are trying to have their cake and eat it too by proposing cost savings without explaining the actual reasons for the cost savings. Some of the proponents of two tiered ERP are silent on the underlying reason for the cost savings for political reasons. They want to sell their ERP software, but don’t want to offend their prospects who have sizable investments, often poorly performing investments into tier 1 ERP applications. Another reason that proponents don’t want to explain the underlying reason is that they do not want to offend their supporters, which is the case with NetSuite—which will bring up how much a two tiered ERP strategy can save SAP customers, but is mum on how much it can save Oracle customers— because of their business relationship with Oracle.

Additionally, two tier ERP proponents have a strong tendency to leave out the history of ERP in an effort to keep their audience focused on their final conclusion, a final conclusion that is an oversimplification of what we know about ERP systems. This serves to provide a misimpression as to important features of a two-tiered ERP strategy. These misimpressions are listed below:

  1. The Novelty of Two-Tiered ERP: Two-tiered ERP is not new. Most companies that use ERP already use different ERP applications for their various tiers.
  2. The Reason for the Cost Savings of Two-Tiered ERP: Many of the proponents of two-tiered ERP are quick to point out the cost savings that come from following the strategy, but are relatively silent on why this should be the case. The reason is very simple: Tier 1 ERP systems are expensive and furthermore do not provide companies with much of a return on investment (actually our research at Software Decisions concludes that most tier 1 ERP systems have a negative return on investment). That is, most companies would have been better off both financially and operationally if they had never purchased or implemented their tier 1 ERP system. Two tiered ERP is often presented as if it is some great innovative idea, when, in fact, an inefficient system is simply being replaced with slightly more efficient systems. Here’s an analogy. Let’s say a wealthy family purchased five Lamborghinis. A family friend points out that if they sold four of the Lamborghinis (keep one Lamborghini for social appearances) and instead bought four Hondas, the family’s automotive costs would decline by following a “two-tiered automobile strategy.” Quite naturally, a Lamborghini is a hugely expensive prestige item. It should not be considered some great intellectual breakthrough that one can reduce one’s automotive budget by replacing Lamborghinis with more practical automobiles. If the tier 1 systems are so cost inefficient a good question that many companies should consider asking themselves is who recommended purchasing the tier 1 ERP systems in the first place?

Two-tiered ERP will save companies money. Most proponents of two-tiered ERP would like the recipients of their message to stop the analysis at that point and to simply buy a Tier 2 ERP system (from them) and have that be the end of the discussion. However, it should definitely not be the end of the discussion. We have a comparison of multiple solution architecture strategies was performed, which are available at this link.

The findings are that, while two-tiered ERP is a cost savings strategy, it is not the strategy that saves companies the most money or provides the most functionality or the lowest long-term maintenance. ERP companies and consulting companies that are signed up to the two tiered approach can’t tell you what is the best overall strategy—because they have a particular offering to sell.

The strategy that does is a best-of-breed strategy that uses a best-of-breed application in every area, including a best-of-breed financial and accounting system. This strategy may also use an ERP system, but the highest-rated ERP systems are not the most well-known ERP systems; rather they are lesser known systems that provide much better value, and unlike the Tier 1 ERP applications and many of the Tier 2 ERP applications, the best-of-breed vendors “play nice” with other applications rather than using the ERP sale as a wedge to force in more applications (a strategy that is referred to as “penetrate and radiate”). Instead, the best ERP software values in the market come from specialized vendors who only provide ERP software—not from software conglomerates whose ERP applications are simply one of their many offerings and who are planning their next acquisition.

The best-of-breed strategy has the extra benefit of providing the best total functionality. Research available clearly shows that companies that follow this strategy will save between roughly one-third and one-half on their overall solution architecture TCO, and this is including all integration costs. This compares to a predicted cost savings of between an actual cost increase and one-quarter for a two-tiered ERP strategy. Furthermore, the best-of-breed strategy combines the largest possible cost savings with the best functionality of any other strategy, meaning it also provides the highest predicted return on investment. Two-tiered ERP does provide some additional variability in functionality, but the benefits are primarily on the cost side of the equation. Therefore, moving to a two-tiered strategy is an improvement over deploying single instance ERP, but it is not the best strategy that a company can follow.

Whose Interests Do Two Tiered ERP Serve?

It is important to understand who initially proposed two-tiered ERP because this tells us a great deal about whose interests it serves. Two-tiered ERP arose as a marketing strategy specifically by the Tier 2 and Tier 3 ERP software vendors. Its most notable and vocal proponent is the software vendor NetSuite, but now pretty much all ERP vendors, regardless of their tier, have position documents to let prospects and current customers know their preferred strategy. This is the case even though two-tiered ERP is a direct contradiction to the single instance logic that Tier 1 vendors have been promoting since the initial development of the ERP software market.

It takes living through the initial ERP sales period in the mid-80s, reviewing the old documentation, or performing interviews to find out that not only was a single instance the official proposal of ERP vendors but that a single instance ERP system would be the only system that any ERP customer would ever need to implement. You can now pick yourself up off the floor after falling down laughing, but I kid you not: this was the pitch.

The Background on the Development of the Term “Two-tiered ERP”

Two-tiered ERP was originally conceived of as a philosophical wedge designed to crack open the lucrative Tier 1 ERP market to Tier 2 ERP vendors. The intent of proposing two-tiered ERP was not to present something that was necessarily true, but to sell specific ERP software—and for consulting companies to sell ERP services.

At some point, Tier 1 will be vulnerable to some type of challenge. As is described in part by this book (and in far more detail in, The Real Story Behind ERP: Separating Fiction from Reality), ERP has not achieved the objectives that it was predicted to achieve and many of the ERP systems have aged quite badly. ERP is on its way to being “just another system” instead of the centerpiece of the solution architecture. Overpaying for ERP is now one of the least effective uses of IT budgets. Many large consulting companies misrepresent this fact to their clients. They provide the impression that ERP is so transformational, so important and has such a high ROI that the company should not be concerned with how much they pay for ERP (in particular, how much they pay for their consulting). Nothing could be further from the truth. ERP’s often generic functionality, will not improve a business very much, and in order for ERP to have a positive ROI, it must be procured and implemented and maintained at a reasonable cost. Two-tiered ERP is an important concept, but not for the reason many people think. It is an important concept because two-tiered ERP represents one of the first cracks in the façade of single instance ERP.

Now, three decades after companies began purchasing ERP systems and preparing themselves for a brave new world of system efficiency, many companies have aging ERP systems as ERP vendors (particularly Tier 1 vendors) are using their ERP systems as cash cows. Rather than improving their systems to at least keep them up to date, vendors have used this money to develop new non-ERP applications, which they then attempt to sell into their existing ERP accounts. The applications are not sold on the basis of functionality, usability, or other application-specific factors, but on the idea that the applications will integrate better to their ERP system.

I consult with clients that rely primarily upon ERP systems for supply chain planning, and using these systems is like stepping into a time machine. I was recently working in SAP R/3-ECC-ERP (its name changes depending upon who you are talking to at the time) and was struck by how dated and of poor quality this “flagship” application was in 2013. It has changed very little from the application that I began working with in 1997. And yet, all of that time SAP has been banking support charges that average 20 percent of the initial purchase price while putting close to nothing back into the product.

Tier 1 vendors simply have little incentive to continue to develop their ERP systems. Most Tier 1 vendors have saddled their customers with aging and low functionality ERP systems, but with high costs. This is the “ERP trap.” Companies that bought big ERP never saw much of a financial benefit, and are now paying an even bigger price as they are stuck with dated systems of low capability that eat up large portions of their IT budget. Every year that I spend time in SAP or Oracle ERP, the more out of date their applications seem.

Is Two-tiered ERP the Savior of ERP?

Generally speaking, the dissatisfaction with ERP systems—and Tier 1 ERP systems in particular—is high. Those that have proposed the concept of two-tiered ERP know this, and have, in part, based their strategy around this dissatisfaction. However, two-tiered ERP is just the latest in a number of popular philosophies that have been proposed to improve and rectify the problems with ERP. The narrative of all these philosophies has never been to question the foundations of ERP (although there is ample evidence to justify doing so), but to suggest a way of adjusting or improving ERP. What has not been recognized is that many of the criticisms leveled against ERP, and particularly big ERP, are inherent to features of big ERP systems—and therefore not amenable to improvement.

Possibly the most ridiculous of these philosophies was service-oriented architecture (SOA), which was the philosophy prior to two-tiered ERP. Supposedly SOA was going to stoke up the value of ERP systems. At one point all of the Tier 1 and Tier 2 ERP software vendors produced some trumped-up white paper that described their “vision” for SOA. All of the major consulting companies proposed not only that SOA was logical, but predicted that SOA was going to be a huge trend that was going to help clients reclaim value from their stogy old ERP systems. Many books were written about this new concept, and many presentations were given at conferences. However, SOA, while proposed with great confidence, has now faded with essentially zero effect on ERP. Interestingly, none of the companies that promised so much from SOA have suffered in the marketplace, and none have had their credibility reduced. Intriguingly, those who pumped up the SOA message are now hoping that recipients of the message have short memories and have by now forgotten about all those SOA promises. It should be stated that the concept of SOA was ludicrous from the beginning, as I explained in the following article that I wrote back in 2010 when SOA was somewhat in vogue.

Why Did SOA Not Take Hold?

The reason SOA was never going to take hold in ERP systems (aside from its technical features; a programmer is better qualified to offer an opinion on that than am I) was because Tier 1 and Tier 2 ERP vendors base their competitive strategy on closing off options for their customers—not on publishing their functionality to be used by all. SOA was about breaking down barriers and allowing any application to call upon the functionality of any other application. All Tier 1 and most Tier 2 ERP software is based upon the opposite philosophy: a philosophy of closed-off systems. The ERP system is used as a “wedge” to get into a customer. Once in, the ERP system is used to justify the purchase of uncompetitive applications from the same ERP vendor on the basis of these systems being easier to integrate back to the ERP system. Why would big ERP vendors support an approach based on open standards, which would allow their applications’ functionality to work flexibly with other applications? That is exactly the opposite of their business model. No real technical knowledge was required to predict that SOA would not happen in the ERP space—only knowledge of how big ERP software vendors operate.

Clearly, two-tiered ERP is yet another trend to get behind, to write articles about, and to base conference presentations upon. Unlike SOA, it is based upon a number of truths. I want to be clear that the proponents of two-tiered ERP are not objective sources of information; they are marketers whose primary motivation is to help sell more software. Two-tiered ERP is a marketing construct based upon a truth (although generally the specific truth is not articulated) that Tier 1 ERP systems are not good values for medium-sized companies. In fact, the evidence, which is compiled in, The Real Story Behind ERP: Separating Fiction from Reality, is that Tier 1 ERP applications are poor values, even for the largest companies.

A Dangerous Idea Two-tiered ERP is a threat to Tier 1

ERP vendors because once more diversity is allowed in enterprise software purchases, it will soon be apparent that Tier 1 ERP vendors offer some of the worst value of all applications purchased by the enterprise software market. We estimated the total cost of ownership (TCO) of purchasing both ERP and non-ERP software from an ERP vendor (a one-hundred-percent ERP vendor software strategy) and the TCO of buying mostly from a Tier 1 ERP vendor. Both strategies are the most expensive purchasing strategies that one can follow, and result in the lowest attainable functionality, implement-ability, and usability. Even so, it is still the dominant approach followed by most large and mid-sized companies in the developed countries.

Two-Tiered ERP and SaaS It is widely assumed that “software as a service” (SaaS) is a necessary part of a two-tiered ERP strategy. Two-tiered ERP is about speeding implementation timelines and reducing costs, and both of these objectives are accomplished when using SaaS-delivered solutions.

Matching the ERP System to the Environment Tier 1

ERP vendors essentially own the Fortune 1000 in the US. Large companies have complex requirements and the IT budgets to match. However, Tier 1 ERP also has a high total cost of ownership, long implementation durations, and a degree of complexity that is a poor match for smaller companies. In fact, a major mistake has been for mid-sized companies to “stretch” to implement Tier 1 ERP. Many of these companies ended up with ERP systems that fell to a low level of capability because the companies lack the funding to support the systems. This is partially because of the software, and partially because ERP software has been parasitized by major consulting companies whose business model is to greatly increase the costs of ERP implementations as well as any other enterprise software they implement.10 I would know because I have clients that are in this exact predicament. This is truly the worst-case scenario: an expensive system delivering weak functionality and no real way out. The ERP system cannot be removed because the company spends so much of its IT budget maintaining the Tier 1 ERP system that they cannot afford to pull out. This is the ERP trap and a vicious cycle. It is a phenomenon that was never considered and never predicted but is now entirely commonplace.

In these companies, Excel becomes the predominant system for almost all analysis. Everything becomes about extracting data from the ERP system, making changes in Excel, and uploading the output of the processing back to ERP.

Example

Here is an example. One of my clients used a Tier 1 ERP system for forecasting. The forecasting functionality within the ERP system was extremely difficult to use, and was essentially a black box system. The forecast accuracy was abysmal; first, they could not run the forecasting models appropriately, and second, they could not figure out how to interpret the output because the application had no real user interface—data was uploaded and data was downloaded. In truth, it was barely an application at all—at least not in terms of how we think of a modern application. Just as big of a problem as the poor output was the time wasted by the employees who had to constantly perform gymnastics to adjust for the poor forecast. For this particular client, I used an inexpensive, but modern, forecasting application to create my own forecasts for the company and to do things they never could have done using the functionality in their ERP system. This is the heavy price that is paid if one relies upon ERP systems for planning functions.

Many companies operate as I have just described, and they are operating in a way that is decades behind what is possible. When clients use predominantly Tier 1 ERP systems to get their work done, it saddens me to think of how much human potential is wasted within these companies by working with (and often around) bad software. Poor software selection saddles companies with poor quality applications for many years and employees are put under pressure to meet objectives that often they cannot meet because the tools they are given are of such low quality. It seems like a bad deal for everyone but a lucky few who benefit from either selling or implementing the software from the major ERP vendors.

The Truth To Two-Tiered ERP

As was discussed previously, two-tiered ERP is based upon an interesting kernel of truth about ERP systems. The actual usage of ERP is explained below:

“Our research finds that one-third of companies with more than 1,000 employees use an ERP application supplied by a single vendor while two-thirds use software from two or more vendors; one-third have software from four or more vendors. There are largely two reasons why companies have heterogeneous ERP environments. One is purely historical: Automating back office functions began decades ago, and companies initially did not roll out or upgrade the systems across the entire enterprise. Moreover, some parts of the organization may have been built through acquisitions. If the acquired entity was relatively large, it often made sense to leave the existing systems in place.

A second reason is that, when it comes to ERP, one size simply does not always fit all; lines of business can be different enough that a single vendor’s offering is not well suited to the needs of all. A two- tier approach recognizes that a big ERP system generally, and the headquarters ERP system specifically, often is a bad fit for the needs of a small offsite division or a remote manufacturing unit in, say, Recife, Brazil that is part of a mostly services-oriented corporation. Using the headquarters ERP vendor’s manufacturing application capabilities may well be overkill for this single-site operation. 

Global firms have a long legacy of ERP heterogeneity, with Forrester noting as long ago as 2004 that a third of firms were already running 10 or more instances.”A Strategic Approach to Establishing Two- Tier ERP

Tier 1 ERP vendors would like you to forget that the vast majority of companies that use ERP systems have multiple ERP systems—sometimes multiple ERP instances in one company—due to things such as each country having its own ERP instance, or a subsidiary in the same country having a separate ERP instance. That is important to consider.

Therefore, part of the two-tiered philosophy is really just “business as usual,” although with the rise of the two-tiered philosophy, this is the first time, at least that I could find, that ERP companies diverged from their primary philosophy of a single instance. Tier 1 vendors developed marketing literature on two-tiered ERP after Tier 2 and Tier 3 ERP vendors released their own marketing literature, promoting the use of their applications for all the tiers. This might make for nice marketing literature, and may help muddy the waters, but it makes little sense to simply use a tier 1 ERP system for all business units/subsidiaries, at least if different instances are required (which would be if the different business units/ subsidiaries have different configuration and customization needs). Using tier 1 ERP software for all of the tiers undermines the advantages of two-tiered ERP, in that a) the buyer would not receive a diversity of functionality as provided by multiple ERP systems and b) the buyer would not receive any benefits of lowered costs and TCO from lower cost ERP tier 2 and tier 3 ERP systems.

Marketing Literature for Multi-Tier ERP

Tier 1 vendors clearly released this marketing literature as a defensive measure— to prevent the Tier 2 and Tier 3 vendors from making much headway with the concept of two-tiered ERP. Customers were reading the two-tiered documentation from smaller ERP software vendors and wanted to know the position of Tier 1 ERP software vendors (one could have guessed their position before reading their documentation). SAP and Oracle have countered with a second proposal: Continue to use their applications for the second tiers, but use their Tier 2 solutions (SAP Business One and Oracle JD Edwards World). Because these are much less expensive applications. This approach is at least cost-effective, but it reduces the

competitiveness and diversity of functionality available to the buyer. If a buyer, through a competitive software selection decides to include SAP Business One or Oracle JD Edwards World as their tier 2 ERP system, then that is perfectly fine, but to simply reward these applications with the selection on the basis of the fact that the buyer already owns the vendor’s Tier 1 offering makes no sense at all, as there are few technological advantages to doing this.

competitiveness and diversity of functionality available to the buyer. If a buyer, through a competitive software selection decides to include SAP Business One or Oracle JD Edwards World as their tier 2 ERP system, then that is perfectly fine, but to simply reward these applications with the selection on the basis of the fact that the buyer already owns the vendor’s Tier 1 offering makes no sense at all, as there are few technological advantages to doing this.

The Supporting Logic Versus Marketing Hyperbole

Most often two-tiered ERP is presented as something new, but, in fact, it is a very common practice. The real difference is in the acknowledgment that a foundational characteristic—single instance ERP—is giving way to a standard approach of multiple ERP systems, not merely as part of a short-term approach, but as part of a long-term strategy. In the past, it was considered more appealing to state that, while one had multiple ERP instances, eventually the company would move to a single instance.

The multi-ERP strategy has been around for as long as there have been ERP systems. Yet IT analysts, consulting firms, and IT trade periodicals that discuss the “new trend” of two-tiered ERP strategies, most often fail to bring up the rather important fact that a big part of the ERP value proposition was supposed to be a single instance of ERP, as explained in the following quote from an article in the Sloan Management Review:

“The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus many companies ended up having several instances of the same ERP system or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.”

How can so many entities actively promote the concept of two-tiered ERP without even mentioning that it is in complete opposition to one of the original value propositions of buying ERP systems in the first place? This is a good time to analyze just a few of the logics that were used to sell ERP.

Conclusion

At this point two-tier ERP comes across to many as a thoughtful enterprise software strategy, however, an analysis of the origins of two-tier ERP point to it being nothing more than a marketing construct that was first proposed, or at least popularized by NetSuite. Marketing constructs can be true or false, but it’s important to identify the source of any concept in order to understand why it was proposed in the first place. In this case, this construct was designed to open up the clients that were primarily tier 1 ERP customers to tier two and three ERP products. There is really nothing more than anecdotal evidence quoted that is used to demonstrate that two tier ERP systems reduce costs/provide benefits over a 100 percent tier 1 strategy, however, given the high expense and low value of tier 1 ERP systems, it would be surprising if a two-tier strategy, if properly configured, did not improve outcomes for buyers. I will explain various two-tier ERP strategies and their impact on costs and value in Chapter 6: “Applying the Concept of Two-tiered ERP to Your Company.” Two-tier ERP has been co-opted as much as possible by Oracle and SAP, however, at its heart, it is essentially a thinly disguised indictment of tier 1 ERP systems generally, and single instance tier 1 ERP systems in particular. In fact, two-tier ERP is one of the first cracks in the façade of tier 1 ERP systems, something that, if enterprise software decisions were primarily based upon research and historical analysis, rather than based upon trends and “what other people are doing,” would have occurred some time ago. Another interesting and strange thing about two-tier ERP is that while it sounds or seems novel, in fact, it has been the predominant way that companies implement ERP systems—it is only that two-tier ERP is explicit in its statement of ERP diversity as a laudable goal—something that was often considered or accepted as simply a transitory state to the “Holy Grail” of a single instance ERP system.

Implementing the Two Tiered ERP Strategy

Therefore, for companies looking for the best overall solution architecture strategy, it’s neither employing a 100 percent tier 1 ERP strategy, nor a two-tiered ERP strategy (both of which would be augmented with what is often mediocre applications offered by the ERP vendor for “integration” along with other assorted best of breed applications.

However, executive decision makers most often don’t have the authority to review the overall corporate solution architecture, but instead must make decisions on incremental additions to their corporate solution architecture. For these decision makers, the first question with respect to two-tiered ERP is whether it is better than 100 percent tier 1 ERP strategy, and for this, the answer is yes. The second question is “which tier 2 ERP system,” and final question is “what is the best way to integrate all of the ERP systems.” The answer to the first question is that it very much depends upon how the two-tier strategy is implemented, as has already been discussed in this chapter. Now we will look at the second of these two questions.

Choosing a Two Tier ERP System

Many ERP software vendors present themselves to their prospects as if they have the best answer for how to choose a two tier ERP system, and the answer is unsurprisingly their software. ERP vendors have made the case that some ERP vendors have a leg up on others in terms of being the tier 2 or tier 3 ERP application. After analyzing this area, as well as their documentation and their statements, it’s difficult to see how any of this argument holds any water. The best reason not to believe something is if it has no evidence, but in this case, there are two other reasons why it’s not a good idea to listen to ERP vendors on the topic of two tier ERP.

  1. Solution Architecture Role: ERP vendors are attempting to serve as solution architects for their clients when they propose why their software is part of a grand two tier ERP strategy. There is a long history of software vendors and consulting companies serving as solution architects for buyers, and it rarely works out well. Software vendors cannot look after the overall architecture because of their bias to insert their applications at every turn.
  2. Distraction: The advantages of a two tier ERP strategy are based upon a buyer gaining access to a lower cost and lower maintenance ERP system, it is not based upon integration. It is worth repeating this because many ERP vendors are combining several issues which will always lead to confusion on the part of buyers. The primary benefit of two tiered ERP is based upon getting access to a lower cost and lower maintenance ERP system as well as gaining access to more functionality, which can meet more business requirements without expensive customization. Let us remember, that if the main objective were an integrated system, and if one integrated system lead to lower costs, then we would simply stick with a 100 percent tier 1 ERP strategy. However, companies that have followed this strategy have experienced the highest possible costs of any possible ERP solution architecture. And in this vein, the most beneficial ERP system is the one that best meets the business requirements of the company.

Many ERP vendors are proposing the old integration argument, and the Tier 2 and Tier 3 ERP vendors will discuss how their systems integrate better to the teir 2 ERP system that is already in place. However, a tier 2 ERP strategy can be implemented with the ERP system—but this is not the way to implement this strategy—which leads into the final question.

How to Integrate the Tier 2 or Tier 3 ERP System

ERP systems must be integrated to other ERP systems for really two reasons—one is the two entities that run each ERP system do business with each other, and therefore it may be convenient if the two ERP systems are integrated—however it’s certainly a minor consideration. Unrelated companies have no problem doing business with each other when their ERP systems are not integrated through the standard business documents/transactions of purchase orders, sales orders, etc. Secondly, ERP systems were never designed to be integrated to other ERP systems. The second, and far more important reason for ERP systems that are within the same overall enterprise to be integrated, is reporting. However, ERP systems are not generally all that proficient at reporting—which is the primary capability of business intelligence systems. ERP systems can have data extracted from them and sent to business intelligence systems, and two or more ERP systems can be integrated to a single business intelligence system in the same way. In fact, this is the most logical way of implementing multiple ERP systems that result in integrated reporting.

Getting the Best ERP System……and Other Systems.

The fact that a company already uses one particular BI application should not promote that company to try to purchase an ERP system from the same vendor. This is because getting the best ERP system and best business intelligence system for the company’s requirements is far more important than getting the systems with some faux integration that comes from the same vendor. Just the analysis of long-term maintenance costs between the different ERP applications demonstrates this, but of course, the other side of the story is the functionality differences between the ERP applications that are often quite significant. For example, in the case of ProcessPro, an ERP system that is customized for process industry manufacturing (things like cheese, petroleum refining, mining, etc.) the applications come standard with a number of key areas of functionality that no other ERP system have in total, but many other ERP vendors partially have or pretend to have. Process industry manufacturing buyers that choose systems that have less of this specialized functionality, accepting the integration argument, or that the customization will be “not that big of a deal,” end up with problematic ERP implementations that cost a lot to maintain. Hopefully, this emphasizes the importance of mating the application to the requirements—although there are many other examples that could be given. Furthermore, there is no software vendor that offers both a leading ERP system and a leading business intelligence system. In fact, the software vendors that offer ERP systems offer some of the lowest productivity and highest cost business intelligence systems, and purchasing both from one vendor is a guarantee of ending up with at least one bad application.

Conclusion

In order to implement two-tier 2 strategy most effectively, it’s necessary to resist the arguments presented by two tier ERP proponents and also to dig a little deeper into under what circumstances and why following a two tier ERP strategy can save companies money. Many proponents of two tier ERP will make the argument that their systems are better suited to be the second or third tier, when in fact any ERP system can be equally placed in these tiers. The hyperbole on two tiered ERP should not distract buyers from attempting to find the best match between the ERP system and the business requirements. Secondly, it is in most cases unnecessary to integrate the multiple ERP systems that are part of a multi-tiered ERP solution architecture. Even when companies buy and sell from one another, all of this can, and is, easily managed with standard purchase order and sales order functionality that requires no integration. For consolidated reporting, it is necessary to have all of the ERP systems in the company’s ecosystem to have data extracted from them, but again, here the most important feature is the capabilities and the productivity of the business intelligence solution. The best software vendors in business intelligence do not offer ERP systems, but some of the lower quality and higher cost ERP vendors do. The best approach is to find the highest value applications in both ERP and business intelligence and combines them as on any other project, there are simply no “special rules” when it comes to two-tiered ERP.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

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 Two Tiered ERP Content

References

The Real Story Behind Tier ERP

Two Tiered ERP 2

The Real Story Behind Two Tier ERP: Separating the Marketing from The Usable Strategy

What the Book Covers

If you need help determining your company’s overall enterprise software strategy and how two-tiered ERP fits in, this book is for you.

Two-tiered ERP is widely understood as the use of different ERP systems for different layers of an organization. Until this book, the effectiveness of a two-tiered ERP strategy could only be determined through anecdotal evidence, the marketing literature of ERP software vendors, and the advice of consulting companies. By understanding two-tiered ERP software within the context of ERP’s history, readers will see how two-tiered ERP may represent a crack in the façade of “big ERP,” and will know how to formulate a comprehensive and logical response to proposals about implementing a two-tiered strategy.

By reading this book you will:

  1. Eliminate confusion over definitions of two-tiered, multi-tiered, and single instance ERP.
  2. Review SAP and Oracle’s Tier 1 and Tier 2 ERP products.
  3. Understand why two-tiered and single instance ERP is not the best strategy.
  4. Appreciate that WHAT is written about two-tiered ERP depends greatly upon WHO is writing it.
  5. Recognize the logic used by vendors to sell two-tiered ERP and whose interests are being served by a two-tiered strategy.
  6. Learn an alternative strategy that provides functionality, cost savings, and the best return on investment.

If you are just beginning your research on ERP systems, read the companion book by the same author, The Real Story Behind ERP: Separating Fiction from Reality first, as it provides the most exhaustive history of ERP currently published.

Related Books

This book is closely tied to the book Enterprise Software TCO, a lack of proper analysis in multiple dimensions (as well as TCO) explaining the uptake of solution categories which are not validated by any evidence. Once ERP systems could not demonstrate much in the way of financial benefits, the book explains how a new logic was developed — that ERP systems were simply “essential infrastructure.” This also turns out not to be true. Of course, the initially proposed argument that ERP software would be the only system that companies ever needed is now laughable three decades after the ERP trend began. Readers will learn that with respect to ERP software, old logics are never proven, simply new hypotheses proposed.

The book is also connected to the book Enterprise Software Selection, because the selection of so many poor quality ERP software solutions from big-name vendors demonstrates a clear inability on the part of many companies to perform a proper software selection.

This book provides a strong focus on SAP ERP as well as Oracle ERP. This gets into SAP ERP ECC/R/3 and Oracle JD Edwards EnterpriseOne and SAP Business One and Oracle JD Edwards World. SAP ERP software is both the author’s area of expertise as well as the most popular ERP software application. ERP software solutions are discussed from the perspective of Tier 1, Tier 2 and Tier 3.

See the Book Page

How to Understand What is Two Tiered ERP

Executive Summary

  • Two tiered ERP is a specific way of managing multiple ERP systems.
  • This serves as an introduction to the concept.

Introduction

We begin with the word “tier,” which means a hierarchy. Interestingly if you type the word tier into an image search engine or stock photography site, the most commonly returned image is that of a wedding cake.

Other common images are steps, however, the image that I found to be the best analogy is the Kuang Si Falls in Laos—because it signifies integration between the different tiers. As we will see further on in the book, integration between the various ERP tiers is critical to the two tiered ERP method.

The term “two-tiered ERP” has two meanings. The more general definition, which I have taken from Wikipedia, is as follows:

“Two-tier ERP software and hardware lets companies run the equivalent of two ERP systems at once: one at the corporate level and one at the division or subsidiary level. For example, a manufacturing company uses an ERP system to manage across the organization. This company uses independent global or regional distribution, production or sales centers, and service providers to support the main company’s customers. Each independent center or subsidiary may have their own business model, workflows, and business processes.”

The second definition, which is attributed to Gartner, is very specific. It imposes certain requirements on how two-tiered ERP is employed and defines different types of two-tier ERP implementations.

“Two-tier ERP is the use of different ERP systems at two different layers of the organization: One system serves as the global backbone, often for administrative ERP processes such as financials, human resources, and procurement, which are able to be harmonized across all divisions as shared services [bold added]. In addition to the global backbone, one or more ERP solutions (or even reconfigured instances of the same system) are used in parts of the organization to support geographical subsidiary needs, usually for smaller operational requirements, such as sales, marketing, field services and local manufacturing.”

According to Gartner, if there is no master ERP system to which the other company’s ERP systems are integrated, it is a “zero-tier system.” Gartner proposes that, in order for a two-tiered solution to meet the definition, it must include an overseeing or master ERP system or some type of integration that connects up the ERP systems. Furthermore, Gartner has the following to say regarding zero- tiered ERP strategies:

“A zero-tier approach, where there is no integration between the core (Tier 1) solution and the solution(s) used by subsidiaries (each operating autonomously under its own profit and loss [P&L] rules), is not considered a tiered strategy—it’s also usually a mess waiting to happen. Only if some level of financial consolidation or information sharing among systems is present (subsidiary to core, or subsidiary to subsidiary) is it considered tiered.”

Gartner’s definition is a bit too rigid for general use; two-tiered ERP is often described simply as using different ERP systems from different software vendors for different parts of the business. Gartner goes on to propose that two-tiered ERP is not a best-of-breed approach where modules from the different ERP systems are mixed and matched.

“The term ‘two-tier ERP’ has been used for several years, although it is also referred to as ‘hub and spoke’ or ‘multi-tier ERP.’ It should not be confused with a best-in-class approach. The main difference is that best-of-breed combines modules from various vendors in an overall solution, whereas a two-tier strategy is the combination of full ERP suites on different layers.”

On this I agree; two-tiered ERP does not combine different modules from different ERP systems.

Two-tiered ERP with Integration to a Master ERP System Versus Business Intelligence Integration

Gartner proposes the following architecture to represent two-tiered ERP.

Getting ERP systems to integrate to one another is quite a lot of work. If the various companies do not require integration beyond buying and selling from one another, it’s unclear why Gartner sees this as preferable. There is little payoff for all the work. Certainly the following architecture is preferable.

Companies tend to desire this architecture more as it provides flexibility: different ERP software can be used depending upon the circumstances, but all the ERP systems can be integrated through the business intelligence layer. Gartner seems to consider this to be a two-tiered ERP strategy, as information is shared from the ERP systems.

Actually, a software vendor with some of the best material on the topic of integrating multiple ERP systems is Teradata, the well-respected business intelligence company. This is explained in one of their white papers.

“The Teradata approach centralizes all legacy data before mapping to the new ERP Environment. This allows significant portions of the migration effort to be reused across multiple source systems. Leveraging existing tools can significantly reduce the time required for data mapping and cleansing tasks.”

“The Teradata environment developed during the ERP conversion project provides an alternative to standardizing on a single ERP instance while still enabling a single view of the enterprise. Enterprise-level global visibility can be provided within the Teradata system at a fraction of the cost and time of extending an ERP instance into these regions. “Because the road to reducing ERP instances generally stretches across many years, a decision to collapse ERP instances is not taken lightly. Strategic business or cost considerations may dictate that a company looks for alternatives to get to a single view or reduced ERP instances, but never gets to a single ERP instance [bold added]. Whatever the case for the company in question, a data warehouse provides the platform that facilitates integration and eases ERP transitions.”

Notice the bolded statement, that while a single instance is often put forward as a goal, that it is often not reached. Teradata then provides the detail related that comes with moving to a single instance ERP.

However, Teradata’s applications can also be used to simply manage a two-tiered ERP solution architecture.

They are speaking here of migrating ERP systems, however, this experience can also be leveraged for integrating multiple ERP systems to a single business intelligence platform. That is with multiple ERP systems integrated to a single business intelligence platform the buyers can receive a comprehensive view of the multiple businesses that are controlled by different ERP systems.

Two-tiered Versus Multi-tiered ERP

These last two graphics represent what two-tiered ERP is not, which is the integration of different ERP systems. Notice that I included a Tier 3 ERP system in the graphic.

So while “two-tiered ERP” implies the use of two tiers of ERP systems, in fact, two-tiered ERP can also mean the use of a third tier ERP system. Essentially this is another dimension to the definition of two-tiered ERP: two-tiered ERP can mean more than two tiers as explained in the following quotation.

“To add to the confusion over terminology, even the second tier, as used in a two-tier strategy, can be misleading. Some companies require more than one additional tier effectively, a multi-tiered strategy. Some subsidiaries may require another tiered solution below the second tier, particularly in distribution and retail industries, where an even smaller system may be required to support, for example, franchisees. For the purposes of simplicity, our use of the term ‘two-tier ERP’ encompasses these multi-tiered solution scenarios, because the strategy determination, governance requirements and selection process are common. In other words, selecting a two-tier approach means that you accept the possibility of a multi-tiered deployment requirement. It’s all in the requirements definition.”

When one gives the topic some thought, two-tiered ERP is actually a rather strange shorthand for various divisions and subdivisions, as there is also a term called “multi-tier ERP.” Multi-tier ERP is where different tier ERP systems—Tier 1, Tier 2 and Tier 3—are deployed, with Tier 3 being used for the smallest of the entities within or associated with the purchasing company. One might propose that “multi-tier ERP” is the more accurate term as it applies more broadly. However, “two-tier” ERP is by far the most commonly used term. As “multi-tier” is used infrequently in practice, I will stick with “two-tier” for this book, and I will use the term “two-tiered ERP” to also mean multi-tier ERP.

How Two-tiered ERP Is New Two-tiered

ERP is the opposite of single instance ERP—the long-held logic originally used by ERP software vendors to sell the ERP concept. This logic held that the company should use a single integrated system for all of its subsidiaries. In fact, the reason for the use of the term “tier” is to present the company as a hierarchy of superior and subordinate subsidiaries. However, the term is actually not all that helpful, except to the degree that the higher tier ERP is used for bigger entities and vice versa. Single instance ERP, long held out as a goal by ERP vendors, never became the normal mode of operation. And this is a very important distinction: two-tiered ERP is different conceptually from single instance ERP, but is simply a reflection of what has come to be, and therefore does not differ from common practice. This very interesting feature of two-tiered ERP will be discussed in detail in this book and is central to understanding the concept as well as the reality of ERP.

As has been explained, two-tiered ERP normally means that different types of tiers of vendors are used for different subsidiaries of a company. These tiers correspond to how the ERP vendor is classified. As mentioned in the first chapter, SAP and Oracle are considered Tier 1 ERP vendors, while Microsoft, Infor and Epicor are considered Tier 2 ERP vendors. Generally, the systems from Tier 1 ERP vendors have more functionality, are more expensive, and are directed toward the largest companies, as explained by the following Gartner quotation.

“Tier 1 vendors that sell ERP systems are typically those that are used by global corporations with annual revenues in excess of $1 billion. Such systems are more complex, provide greater functionality, need higher numbers of trained personnel and have higher cost of ownership. Tier 1 vendors are likely to offer global support to their clients. SAP, Oracle and Microsoft are considered Tier 1 vendors in the ERP space. “Tier 2 ERP vendors mainly serve mid-market businesses, with revenues from $50 million to $1 billion. Their products are of medium complexity and functionality, and have lower ownership costs than their Tier 1 counterparts. Often they are focused on individual industry verticals, whereas Tier 1 products are broad-based. Fujitsu, Epicor, Ramco and Sage Software are some Tier 2 ERP vendors. “Tier 3 vendors sell ERP systems that are designed for small companies that have annual revenues from $10 million to $50 million. Such systems have the least complexity and costs of ownership; at the same time, their broader functionality is also much lower. However, they often have greater focus on individual industry verticals. Expandable, NetSuite and Syspro are some examples of Tier 3 vendors.”

However, this second general definition—or modality of the first definition—is two-tiered philosophy as it is generally implemented. This is expressed in the following quotation:

“A typical set-up is to have Oracle or SAP operating as the primary system while adding a different tool elsewhere, often using a software- as-a-service delivery model. Infor, Microsoft, Epicor, Plex, Ultimate Software, NetSuite, Workday, QAD and IFS are some of the more frequently used vendors for the secondary deployments, Wang noted.”Two-tier Strategy a Way to “Reinvigorate” ERP

However, because SAP offers both a Tier 1 and Tier 2 ERP application, a two-tiered strategy could consist of using two different applications from the same software vendor.

If all of this discussion of tiers and ERP applications have left your head spinning, you are not alone. The following graphic should help clarify which vendor is in what tier.

Some view the term “Tier 2 or 3” to be an indicator of software quality or value. It isn’t. The Tier 1 ERP vendors produce some of the worst-value ERP applications that are sold in the ERP software category. Two of the highest quality and highest value ERP applications that we have evaluated at Software Decisions are actually Tier 2 ERP software vendors.

To wrap up this chapter, the following features apply to two-tiered ERP:

  • Tier 2 ERP software vendors focus on the mid-market, and Tier 3 ERP software vendors focus on the mid-market and even the small market.
  • Two-tiered ERP is defined as using applications from different software vendors from each tier. Most often the top tier would use a Tier 1 ERP application (often an on-premises version of the software) while the subsidiaries may use a Tier 2 or Tier 3 ERP application.
  • Some Tier 1 ERP vendors recommend using their Tier 1 software for all the various companies. However, this is not a two-tiered strategy; it is a multi-instance strategy—that is a multi-instance of the same application.

Why Two Tier ERP is Not New

The first thing to consider when understanding what to do with two-tiered ERP is that two-tiered ERP is not new. Two-tiered or multiple- tiered ERP has been used since ERP systems were initially sold. What is new is the marketing of the concept: the use of multiple ERP systems from different vendors is a way of improving the value returned from ERP implementations.

The Unstated Assumption of Two-tiered ERP

What is unsaid regarding two-tiered ERP may be even more interesting. The story that is being told regarding two-tiered ERP is not the full story; instead, it is an engineering/marketing construct that only tells part of the story. Tier 2 and Tier 3 ERP vendors don’t dare contradict the established viewpoint that Tier 1 ERP software is necessary, even though it isn’t. Software vendors don’t want a lot of controversy or “trouble”—they just want to sell software. Thus the Tier 2 and Tier 3 vendors have developed the two-tiered concept as an adjunct to a centralized ERP system. The vendors have presented this digestible new strategy without undermining the sacred cow of Tier 1 ERP, which would be off-putting to companies that have spent so much money on tier 1 ERP systems and have so little to show for it. The two-tiered ERP concept allows Tier 2 and Tier 3 ERP vendors to tiptoe around what makes the two-tiered strategy work—unlike other ERP “savior concepts” that have come before it such as rapid big ERP implementation methodologies (an oxymoron if there ever was one) or service oriented architecture (i.e. SOA—a philosophy that Tier 1 vendors had zero interest in supporting).

Hopefully, this book has provided enough information to convince you that two-tiered ERP both a) makes sense and b) is nothing new. However, if one accepts the premise that two-tiered ERP is worthwhile, the question becomes what to do about it. A big part of this decision is determining who to listen to; so many entities in the market claim theirs is the right course to follow with respect to two-tiered ERP. However, very few of these vendors could be considered financially unbiased, and none provide any evidence to support these claims.

Let’s start off by listening to what the Tier 1 vendors have to say on the topic.

The Tier 1 ERP Software Vendors Tier 1

ERP software vendors have attempted to co-opt and change how two-tiered ERP is implemented. Let’s remember that the original idea behind two-tiered ERP was to implement below Tier 1 ERP applications into subsidiaries and sub-companies that had lower functionality demands than the parent company. Two-tiered ERP was initially presented as a way to reduce cost and complexity, to which the Tier 1 ERP companies say:

“Great, we are on board. Just implement multiple instances of our Tier 1 software.”

However, that is not a two-tiered ERP strategy: that is a multi-instance ERP strategy using the same software. Tier 1 ERP vendors counter this argument with their second proposal:

“We offer mid-market ERP systems also, so use our mid-market solutions for the other tiers.”

Depending upon whether the vendor is SAP or Oracle, the cost savings can be lower or about the same as other well- known Tier 2 ERP applications. However, adjusting for more than costs, the argument is actually better for SAP, as they have a far more capable Tier 2 ERP application in SAP Business One than does Oracle in Oracle JD Edwards World. Both software vendors propose that they offer a better value versus alternatives that do not offer both a tier 1 and tier 2 ERP application, as their respective tier 1 and tier 2 ERP systems are integrated to one another or share a common heritage. However, a close examination of each software vendor’s system calls this assertion into question. SAP’s Tier 1 offering (called ECC or R/3) has nothing at all to do with SAP Business One, their Tier 2 offering. SAP Business One was not developed by SAP but was renamed after SAP acquired TopManage Financial Systems, along with TopManage’s sister company TopTier. As such SAP Business One has a completely different technical heritage than SAP ECC. And while SAP will no doubt advise that it has some adapters that connect SAP ECC to SAP Business One, the connection benefits between these systems should be viewed with great skepticism if previous experience with SAP’s integration claims is any indication.

How Acquisitions Play into Two Tier ERP

Both of Oracle’s main ERP systems—Oracle JD Edwards EnterpriseOne and Oracle JD Edwards World—were the result of acquisitions and were not developed by Oracle. Regardless of any integration that exists between the systems, Oracle JD Edwards World is an application that should be retired as it is not a viable option for future purchases.

SAP and Oracle—knowing they have limited ability to stop a customer set on the concept from moving to a two-tiered ERP strategy—would like to steer customers in a direction that benefits SAP and Oracle. Rather than performing a proper software selection, SAP and Oracle would like their customers to simply choose the solutions that SAP and Oracle want them to choose. Once again they will argue that their systems will integrate better with their tier 1 ERP systems, an argument that we discredited in the previous section. Even if integration were not an issue, their solution may not be a good decision as it’s unlikely the proposed application is the best fit for the company’s business requirement. Secondly, integrating the lower-tier ERP systems into a master ERP system is only one way of implementing two-tiered ERP. Another, less costly, approach is simply to integrate all the ERP systems to a master business intelligence system. Many ERP vendors leave this alternative out when discussing two tier ERP with potential clients. However, integrating to the master business intelligence system is, in my view, a preferable solution architecture.

Biased “Advice” from Tier 1 ERP Vendors

It’s unclear why anyone would listen to Tier 1 ERP software vendors on the topic of two-tiered ERP. Their only interest is to redirect purchases back to their applications, and so any of their opinions or recommendations are based simply on their marketing and sales function. They are countering a movement in the marketplace with the tools they have available. Furthermore, nothing that either SAP or Oracle has predicted on the topic of ERP has ever turned out to be true. Bill Maher lampooned those who promoted the Iraq War.

“If you’re someone from one of the think tanks that dreamed up the Iraq War, who predicted that we would be greeted as liberators, and that we would not need a lot of troops, and that the Iraqi oil would pay for the war, that the WMDs would be found, that the looting was not problematic, that the mission was accomplished, that the insurgency was in its last throws, that things would get better after the people voted, after the government was formed, after we got Saddam, after we got his kids, after we got Zarqawi, and that the whole bloody mess would not turn into a civil war…you have to stop making predictions.”

The same could be said for Tier 1 ERP software vendors. Buyers that have followed the advice of SAP or Oracle in setting up their solution architecture have resulted in the highest cost, and lowest functionality corporate IT infrastructures, as is explained in the Brightwork Research & Analysis TCO studies.

SAP routinely spins false marketing constructs that have little to do with reality, such as NetWeaver and HANA. Oracle’s internal culture of lying runs so deep that other software vendors point to it as a reason to increase their own lying. Many marketing departments have put effort into developing literature regarding their position on two-tiered ERP, with the single intent of getting you to think they have the best approach to two-tiered ERP. Much of the information provided by Tier 2 and Tier 3 ERP software vendors is of a dubious nature, as demonstrated by the following quotation from Sage, a Tier 2 ERP software vendor:

“Well-run, global organizations are increasingly adopting a two-tier enterprise resource planning (ERP) strategy.”

If one were to read through the source paper of this quote, one would note that this bold pronouncement is never supported by any evidence. The statement is not, “Increasingly a few well-run, global organizations are adopting…”; the statement is categorical. In fact, the only evidence presented throughout the paper is that two-tier ERP is becoming a topic of greater interest among corporate buyers. This is a problem, because the paper implies that it has evidence that two-tiered ERP is what good companies implement as will be demonstrated at some point in the paper (but never is).

High Cost of Tier 1 ERP

Two-tiered ERP does make sense due to the high cost and poor performance of Tier 1 ERP. However, there is a difference between something appearing logical and stating that better companies are employing the strategy.

“Organizations in the market for ERP solutions are increasingly considering a two-tier ERP strategy. A recent study by Constellation Research found that forty-eight percent of buyers in 2011 were considering a two-tier strategy, up sharply from thirty-two percent in 2010 and twenty-seven percent in 2009”

The above statement is a standard way to begin a promotional paper of this type. However, the statement does not demonstrate whether a two-tier strategy has actually worked in practice. Instead, it merely provides evidence that more companies are focused on the question. This increased interest could be due to any number of reasons, such as the enormous quantity of marketing literature produced by software vendors and the prevalence of conference sessions on the topic. The article goes on to trace the supposed roots of two-tiered ERP.

“Two-tier ERP systems began their rise in popularity during the economic recession that began in late 2008. As IT budgets were slashed, IT departments were forced to make do with less. In many cases, large-scale ERP migration plans were delayed or eliminated entirely. Instead of moving to new systems, companies focused on improving existing systems, including legacy ERP applications. As a result, many organizations decided to retain functionality in their existing systems that were still working while migrating to Tier 2 systems where existing solutions were not meeting their requirements.”

This paragraph is not true. The popularity of two-tiered EPR did not rise during the economic recession of 2008. Two-tiered ERP has always been used for one reason: generally, Tier 1 ERP is too expensive for subdivisions, and companies never moved to single instance Tier 1 ERP.22 This entire paragraph is confusing and apparently, the author does not know the history of ERP. Instead of being based in the history of ERP, this paragraph attempts to develop a narrative where Tier 2 ERP is a significant trend and to give the impression that two-tier ERP is entirely new. The paper goes on to say:

“At the same time, organizations began realizing that big-bang, corporatewide ERP installations are often ineffective. When a system becomes very large, it becomes costly to customize, maintain, and upgrade.”

Porblematic ERP Implementations

For some time we have proposed that an incremental implementation strategy be used even within one application—rolling out less complex functionality earlier. Generally, this approach is not followed. Implementation methods tend to change little over the years, in that they rarely reflect what has worked or not worked historically. Since I began working on IT implementations in 1997, I have seen little adjustment to implementation methodologies. No evidence is presented in the paper that companies are moving away from big bang implementations. I could find no research that even studied the movement of companies away from big bang IT implementations to incremental IT implementations. The Sage paper goes on to say that two-tiered ERP is being driven by changes in corporate structures.

“For example, many organizations have undergone multiple mergers and acquisitions that leave them with multiple ERP solutions—and unacceptable support costs.”

There is nothing at all new about this, except for the fact that support costs from the Tier 1 ERP vendors have been increasing steadily. However, multiple companies being part of another company, all with different ERP systems, is why two-tiered or multi-tiered ERP has become a popular “strategy” since ERP systems first began being used in the mid-1980s—although calling it a “strategy” may be giving it too much credit for forethought. Rather, the strategy resulted from circumstances.

“Seventy percent of respondents to a recent Software Insider survey remarked that existing, Tier 1 systems are too expensive. An estimate published by CIO magazine in 2009 placed the cost of the average Tier 1 ERP system deployment at between $13 million and $17 million. ROI calculation on Tier 1 ERP systems show that high costs are due to overruns in implementation, customization, maintenance fees, and staff costs. Upgrade costs are also high—45 percent of respondents said that upgrades are too costly.”

Yes, the survey results reflect reality but are presented in the article as if they represent new information. In fact, the only new part to this is that support fees have increased. Tier 1 ERP systems have been known to be quite expensive for decades.

The Sage paper goes on to report that many respondents to a survey believe that Tier 1 ERP systems are expensive.

“When all of the implementation, ongoing maintenance fees, upgrades, and modifications are considered, a two-tiered system can offer significant financial savings. For example, Gartner Research found that companies see a thirty-three percent reduction in implementation costs when a two-tier system is deployed.”

Firstly, our research is quite a bit more thorough than Gartner’s because we estimate the cost savings for the entire TCO of a two-tiered ERP strategy—and we have tested a number of scenarios. Our research shows that a thirty-three percent reduction in TCO costs is the upper end of the cost savings continuum, while a predicted TCO cost savings in the twelve percent to seventeen percent range is a more reasonable expectation. However, it depends upon the size of the Tier 1 ERP system as compared to the Tier 2 ERP system.

Obviously, Tier 1 ERP systems are bad values. Any other strategy, such as using a best-of-breed application (even a best-of-breed finance application), will yield far better financial outcomes. All this seems to beg the following question: If Tier 1 ERP systems are so expensive, why have they been recommended by Gartner and the major consulting companies for more than three decades? (Hint: It’s not because Tier 1 ERP provides good value to customers. No research has ever produced a positive return on investment for Tier 1 ERP.) So, whose interests are these entities looking out for, if not the customer’s?

The Answer is Two Tier ERP?

Sage presents a lot of information, but seems interested in drawing only one conclusion: the answer is two-tiered ERP. In doing so, they leave out other conclusions that are just as interesting and important to analyze. The Sage paper goes on to highlight a well-known issue regarding Tier 1 ERP systems and innovation.

“Yet thirty-five percent of Software Insider survey participants found that enterprise-class ERP vendors have not innovated quickly enough. Subsidiaries are finding that they can customize Tier 2 applications more quickly than they can convince corporate to change the global ERP system to meet their local needs.”

This is also true. Tier 1 ERP software vendors have been using their ERP applications as cash cows for more than a decade and a half. They use the high profits from their ERP systems to acquire or develop non-ERP applications, which they then sell into their customer bases, acquiring a higher and higher percentage of their customers’ IT budgets. Again, who are the culprits for this end result? Those who recommended Tier 1 ERP systems as necessary: the major consulting companies and Gartner (who is used repeatedly as a source in the Sage article), as well as other analysts who told companies that Tier 1 ERP would lead to great things.

Fast Implementations?

The Sage article goes on to praise the speed with which Tier 2 ERP applications can be implemented.

“A two-tiered infrastructure can be deployed quickly and cost effectively. The time to implement and modify or upgrade is likely to be shorter, which means that deploying such a system will deliver a shorter timeto- benefit, and these systems can be modified more quickly and easily than a Tier 1 ERP solution.”

This could be filed under the category of “self-evident.” This quotation again states that Tier 1 ERP software is inefficient and expensive to operate. Of course, anything— with the possible exception of lagging business intelligence applications (i.e., IBM Cognos, SAP BI, Oracle BI)—are going to seem efficient compared to Tier 1 ERP, which brings up again the question of why Tier 1 ERP is used in the first place. Marketing Does not Equal Reality Just because a vendor has invested in marketing literature about two-tiered ERP, does not mean they are a good choice for your two-tiered or multi-tiered ERP strategy. In fact, an ERP vendor’s position or marketing material on two-tiered ERP is immaterial to any purchasing decision. Different ERP systems are fundamentally separate. We have evaluated thirteen ERP systems, and none of these ERP systems were designed to be integrated to other ERP systems. Gartner states this, albeit more delicately.

“Do not assume that integration between systems will be plug-and-play, even if provided by the same vendor.”

The vendors of some of the better ERP systems that we have reviewed have not written any marketing literature on two-tiered ERP. Conversely, some of the lowest-scoring ERP on systems include the most literature on two-tiered ERP. Any company that intends to use a variety of ERP software vendors can simply use the same software selection approach that tends to result in the best software being selected. No review of the various literature on two-tiered ERP is necessary.

Major Consulting Companies

The major consulting companies don’t have much interest in promoting two-tiered ERP because their main interest is in billing for tier 1 ERP resources; resources for lower tier ERP bill out at a lower rate. Furthermore, there are more software vendor options, and major consulting companies are not interested in retraining or hiring new resources so that they can bill hours. So the “recommendation” of major consulting companies on two-tiered ERP will be that it is “too early to jump in,” and that two-tiered ERP will take resources away from the really important work of “improving the tier 1 ERP system and moving toward a single instance.” Not surprisingly Accenture published a document entitled “Why Big Systems Are Here to Stay,” which perhaps should have been called “Why Big Systems Are Here to Stay: Because We Make Tons of Money That Way.” In this document, Accenture makes the following contentions:

“And a third advantage of an ERP environment has to do with how data is managed, integrated and secured. If not properly integrated, cloud and software-as-a-service solutions can create a more chaotic, less reliable and less secure data environment.”

This is an interesting assertion because ERP environments have zero advantage over non-ERP environments with respect to data management, integration or security. ERP systems that I evaluated often had the lowest data quality of any software category—particularly for the Tier 1 ERP vendors as the applications have such dated data management tools. As for integration, ERP systems may be integrated to themselves, but the Tier 1 ERP vendors are some of the most difficult systems to integrate with other applications. As for the security argument, ERP systems are not more secure than other software categories.

The above Accenture statement also confuses the topic of ERP systems versus SaaS systems. SaaS is a delivery method for software; ERP is a category of enterprise software. SaaS can deliver as an on-premises solution for any application, including ERP. ERP systems that are on-premises are more secure than cloud or SaaS applications, but that is a different issue.

The Evidence Presented by Accenture?

Overall, the evidence to support the statement made in the Accenture paper is severely lacking, and it should qualify as FUD (fear, uncertainty and doubt). Accenture has a financial incentive to slow the movement away from Tier 1 ERP and toward SaaS solutions because it’s how they make a lot of money: they have far less control once the application is delivered via SaaS. With SaaS, the software vendor tends to take over consulting and support. Interestingly, nowhere in the paper does Accenture mention how it makes money (which is with on-premises consulting and support) and how this may influence its “recommendations.”

Accenture goes on to say that the best approach is a hybrid: some on-premises and some SaaS. They then proceed to make another self-serving proposal, that this IT ecology must be managed by using a trusted “broker.”

“So, who’s in charge of managing this complex hybrid system? The answer lies in the rising trend of using an integrator or trusted broker. This brokerage can act as either a consultant or as a managed services provider. This holistic or managed services approach enables companies to treat their IT resources as just that and also provides a new level of fl exibility for companies and CIOs.”

And who would be this trusted broker? That’s right—Accenture! After spending decades overcharging and misdirecting their clients to all the wrong software in the on-premises environment, Accenture would like to be handed the keys to managing their clients’ IT solution architecture in the new on-premises/SaaS “hybrid” environment.

The major consulting companies don’t really have “opinions” on topics; all they see is whatever maximizes their revenues. It’s very simple: two-tiered ERP along with SaaS-delivered software reduces their revenues—therefore, they are against it. Now, if what I am saying is true, why would Accenture develop a partnership with NetSuite, as the links below describe?

https://www.netsuite.com/portal/landing/accenture.shtml

https://www.oracle.com/us/corporate/press/1966087

Generally, partnership statements of this kind are not reliable indicators regarding a policy within the consulting companies. Companies develop partnerships all the time, and many of them do not extend beyond the marketing press release and the insertion of company logos on one another’s websites.

Both software vendors and consulting companies love having partnership logos on one another’s websites. However, in most cases, these partnerships are much less than meets the eye. I cover this topic in the following article about the overused and often meaningless integration certifications that many smaller software vendors have on their websites that show some integration to a major ERP software vendor.

A far better indicator of how dedicated a company is to a particular strategy or line of business is whether they put out marketing collateral on the topic. And the major consulting companies have not done this—at least at the time this book was published. If their clients demand that they provide Tier 2 and Tier 3 resources, the major consulting companies will do it; after all, they prefer to have the business rather than to lose the business, but they would prefer not to do this.

IT Analysts

Having read the reports of several analysts on two-tiered ERP, it was interesting to see their take on the topic. IT analysts have not spent space in print explaining the history of ERP to their subscribers. Some of them use phrases such as, “two-tiered ERP can be effective if implemented properly,” which sounds authoritative. As there are no studies on the effectiveness of two-tiered ERP, this statement sounds quite fabricated unless they can provide the evidence to back it up. Statements like this provide a nice escape hatch for IT analysts. If the trend does well, the analyst can say, “I predicted it,” and if two-tiered ERP does not work well, the analyst can say, “It was not implemented properly.” This approach is copied from economists and allows one to sound authoritative without doing any research and without committing either way.

I was very surprised that none of the analysis on two-tiered ERP brought up the fact that the analysis was contradictory to the original logic of ERP, something that I consider to be one of the biggest stories related to two-tiered ERP. Another letdown was that not a single IT analyst asked the question: If two-tiered ERP is so advantageous and saves so much money, what does this mean regarding Tier 1 ERP?

An Algorithm for Starting Trends Without Evidence This is how trends get started in enterprise software; the process seems to have the following stages:

  1. The Marketing Machine: Software vendors with a financial bias propose something is a good idea and rev up the marketing machine.
  2. Stoking the Fire: IT analysts write reports on the idea, without declaring the source of the new idea—the financially biased software vendors. They do not evaluate the merits of the proposal but instead write articles—perhaps with a few anecdotes of why “it could be” a good idea.
  3. The Conference Circuit: Vendors and consultants start presenting on the topic at conferences, and articles are written about the idea in IT publications.
  4. The Conference Aftermath: Purchasing company executives attend these conferences, and come back saying, “We need to take a look at two-tiered ERP.”
  5. The Surveys: Surveys are performed that show that X percent of executives are thinking about whether or not to implement the new idea.

Enterprise software buyers are thus primed for the marketing materials and sales pitches from the software vendors that started the trend in the first place. This is very reminiscent of how topics become popular in national politics. Often an event will occur, prompting a number of stories on the topic. Then a survey is taken and the survey shows that this topic (not without coincidence) is on people’s minds. Another person was able to control public opinion in the same manner. His name was William Randolph Hearst and here is his famous cable:

“When Hearst Artist Frederic Remington, cabled from Cuba in 1897 that ‘there will be no war,’ William Randolph Hearst cabled back: ‘You furnish the pictures and I’ll furnish the war.’”

The above essentially describes how historically media outlets have been used to manipulate what people think and what they feel. The history of media, in general, goes back much further than the history of media for enterprise software. In fact, the history of enterprise software only goes back to roughly 1970 (most software applications prior to this period were shrouded in secrecy as they were military in nature). However, many of the same outcomes are consistent to the point of repetitiveness and are easy to catch if one studies the topic. Knowledgeable entities can influence media systems. In fact, a major impetus of marketing is to influence storylines in a way that makes them seem entirely authentic.

Conclusion

The term two-tier ERP means applying different ERP systems to different “tiers” of the business. In a nutshell, the larger and more prominent parent companies tend to receive the tier 1 applications, while the subsidiaries receive ERP systems that are considered tier 2. IT analysts and software vendors present a model where multiple ERP systems are connected to a master ERP system. There is no real evidence provided as to why this is a good thing, and it is also contradictory to ERP systems, as ERP systems are designed to represent the “enterprise.” Furthermore, attempting to integrate multiple ERP systems increases the expense of following a multi-ERP system strategy. There is also no strong delineation between the use of the term two-tier ERP versus multi-tier ERP strategy. Both refer to the use of multiple ERP systems for various tiers of entities within one business. However, both of these terms are clearly the opposite of the term “single instance ERP,” which was an unrealized goal of many buyers that implemented ERP systems, but upon closer examination, there is real justification for the goal of using a single instance ERP system. Certainly using one system can save money as it provides economies of scale—and the more users a single instance of an application has, the lower its costs tend to be per user. However, this relationship cannot be generalized to it being a universally applicable strategy as one must give up flexibility, functionality and must perform more customization to the application as it grows in scope. Complexities in mating one monolithic system to variable requirements was a major reason that the single instance concept, while appealing if one only considered an overly simplistic set of assumptions, never became a commonly implemented approach.

SAP and Oracle have attempted to control the two-tier ERP story and to co-opt the trend so that their customers buy lower tier ERP systems from them. Neither of these software vendors has proven to provide good information to their customers, and, in fact, both gouge their customers to a ridiculous degree on support costs. They should have zero credibility with buyers, especially if one actually evaluates their history of being right with their previous predictions and advice. Of course, the bad quality information on this topic is not limited to SAP and Oracle. This chapter provided numerous examples of evidence-free statements made by those that often have a substantial influence on the information technology media and also what buyers think.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

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 Two Tiered ERP Content

References

The Real Story Behind Tier ERP

Two Tiered ERP 2

The Real Story Behind Two Tier ERP: Separating the Marketing from The Usable Strategy

What the Book Covers

If you need help determining your company’s overall enterprise software strategy and how two-tiered ERP fits in, this book is for you.

Two-tiered ERP is widely understood as the use of different ERP systems for different layers of an organization. Until this book, the effectiveness of a two-tiered ERP strategy could only be determined through anecdotal evidence, the marketing literature of ERP software vendors, and the advice of consulting companies. By understanding two-tiered ERP software within the context of ERP’s history, readers will see how two-tiered ERP may represent a crack in the façade of “big ERP,” and will know how to formulate a comprehensive and logical response to proposals about implementing a two-tiered strategy.

By reading this book you will:

  1. Eliminate confusion over definitions of two-tiered, multi-tiered, and single instance ERP.
  2. Review SAP and Oracle’s Tier 1 and Tier 2 ERP products.
  3. Understand why two-tiered and single instance ERP is not the best strategy.
  4. Appreciate that WHAT is written about two-tiered ERP depends greatly upon WHO is writing it.
  5. Recognize the logic used by vendors to sell two-tiered ERP and whose interests are being served by a two-tiered strategy.
  6. Learn an alternative strategy that provides functionality, cost savings, and the best return on investment.

If you are just beginning your research on ERP systems, read the companion book by the same author, The Real Story Behind ERP: Separating Fiction from Reality first, as it provides the most exhaustive history of ERP currently published.

Related Books

This book is closely tied to the book Enterprise Software TCO, a lack of proper analysis in multiple dimensions (as well as TCO) explaining the uptake of solution categories which are not validated by any evidence. Once ERP systems could not demonstrate much in the way of financial benefits, the book explains how a new logic was developed — that ERP systems were simply “essential infrastructure.” This also turns out not to be true. Of course, the initially proposed argument that ERP software would be the only system that companies ever needed is now laughable three decades after the ERP trend began. Readers will learn that with respect to ERP software, old logics are never proven, simply new hypotheses proposed.

The book is also connected to the book Enterprise Software Selection, because the selection of so many poor quality ERP software solutions from big-name vendors demonstrates a clear inability on the part of many companies to perform a proper software selection.

This book provides a strong focus on SAP ERP as well as Oracle ERP. This gets into SAP ERP ECC/R/3 and Oracle JD Edwards EnterpriseOne and SAP Business One and Oracle JD Edwards World. SAP ERP software is both the author’s area of expertise as well as the most popular ERP software application. ERP software solutions are discussed from the perspective of Tier 1, Tier 2 and Tier 3.

See the Book Page

How ERP is Similar to a Out of Control Octopus

Executive Summary

  • ERP has grown into an out of control octopus that has taken over IT.
  • The implications of such high overhead systems go little covered in IT media.

Introduction

Economics gave us the useful term of “externality.” When an entity engages in a behavior that places costs on other entities for which it does not compensate them, this is referred to as a negative externality. The ERP craze has been primarily an exercise in the perpetuation of a negative externality on the part of ERP vendors and ERP implementation companies on ERP buyers, and given the evidence of poor ERP functionality and costs, it is amazing that it has gone on for this long. It is the greatest misallocation of resources in the still relatively young enterprise software industry.

The Results of Research into ERP Systems

My analysis of the research into ERP systems tells a very interesting story about how software is purchased. I have explained the issue of ERP systems to a number of people—from executives to technical resources, to laypeople. A very effective analogy to use with people not familiar with ERP is to think of ERP as an octopus. ERP systems began as one thing, and now they are an unruly and expensive octopus, which connects throughout the enterprise but mostly in unproductive ways. The following quotation brings up an interesting point that more companies should consider.

“Over the last two decades, companies have plowed many billions of dollars into enterprise resource planning (ERP) systems and the hardware required to run them. But what, in the long run, will be the legacy of ERP? Will it be viewed as it has been promoted by its marketers: as a milestone in business automation that allowed companies to integrate their previously fragmented information systems and simplify their data flows? Or will it be viewed as a stopgap that largely backfired by tangling companies in even more systems complexity and even higher IT costs?”Nicolas Carr

The Reality of ERP ROI

ERP software is a category of software with a very low ROI (if one limits the financial returns to the ERP system itself), and a negative ROI when one looks at how ERP negatively impacts a company’s overall software investment—for instance, the negative affect on the company’s other applications, as well as how ERP isolates companies from customers and suppliers. In the book, Enterprise Software Selection: How to Pinpoint the Perfect Software Solution using Multiple Information Sources, I describe how most companies that buy enterprise software lack the internal ability to validate the claims made by software vendors. In addition, they are often led down the garden path to a bad decision by consulting companies that place their interests ahead of their clients. ERP systems became so popular because the actual claims about their benefi ts were never analyzed properly.

How The Lucrative Nature of ERP Leads to Censorship on the Topic of ERP Benefits

Because ERP systems have been so lucrative for software vendors and consulting companies, there has been a strong incentive for them to get companies to purchase them. For decades, when a company complained to their consultants about their current system’s shortcomings, the consultants commonly responded that what the company really needed was an ERP system (cue the oversimplified explanation of how ERP systems integrate all of the company’s processes). One can imagine how many times this same conversation has played itself out at companies around the globe. The unfortunate fact of the matter is that most ERP systems were purchased without appropriate research; a very large percentage of them were purchased because they were seen as the “thing” to implement. This faulty logic controls many IT purchase decisions, as the following quotation attests.

“Interviews with the managers confi rmed that if a successful strategic IT (e.g., laptops to salespeople) was implemented by one or two firms, the other competitors soon followed the lead. Thus, although the IT intensity of the industry increased, no net performance effect was observed.”The Relationship Between Investment in Information Technology and Firm Performance: A Study of the Valve Manufacturing Sector, Information Systems Research

The Misleading Sales Job of ERP

At its heart, ERP was a misleading and oversimplified, although a highly compelling, concept. It was never a good investment and now hinders a company’s ability to leverage the Internet and reduces its ability to gain value from its other applications. ERP was based upon several false assumptions that have been explained throughout this book. The central premise of ERP—that you could have a single set of integration applications from a single vendor that would always meet the implementing company’s needs and therefore greatly reduce and almost eliminate the need to integrate to other applications—was delusional when it was first proposed. It is even more delusional now.

How Cloud and (AWS and Google Cloud, etc..) Works Against ERP

The development of information systems in the form of Internet and SaaS/PaaS/IaaS service providers has worked against ERP. ERP are primarily closed systems, but SaaS/PaaS/IaaS are open systems.

The future of information systems will involve mixing and matching the best solutions from a variety of vendors, with much of the data storage and processing being handled remotely. The IT burden on companies will be greatly reduced, and ERP has no place in this model. The more that companies cling to their ERP investments, the less they will be able to participate in this open approach to accessing application functionality. Forward-thinking companies will consider their ERP investments as what they are: sunk costs. They will migrate to better functionality in other systems and take a piecemeal approach to ERP. The logics that were used to sell ERP systems was never anything more than hypotheses. When I explain why any well-promoted concept should have evidence to support it, often the listener simply repeats the hypothesis back to me. At that point, I have to say, “Yes that is the hypothesis, but there is no evidence to support it.”

Of course, anyone has the right to propose any hypothesis they like. However, while a hypothesis may turn out to “make sense” or seem likely, it’s only through testing that we can know for sure. If a hypothesis has had a full opportunity to be tested (after 30 years, ERP has certainly had this opportunity) and has proven false, then it is time to dispense with the hypothesis and to move to a new one. That is how all knowledge advances. Two powerful vendors—SAP and Oracle—were installed at the top of the enterprise software hierarchy because of ERP.

This development has been bad for the enterprise software market, as these two actors have abused their power by offering their clients low value and high costs, and by using account control techniques. Many other ERP vendors were never able to capitalize on their ability to sell ERP software and to sell other types of software.

Is There Truly No Alternative to ERP?

Proponents of ERP make it sound as if there are no alternatives to ERP, or that the alternatives are “poorly integrated” (which is another way of saying that there are no alternatives). A misleading argumentative technique frequently used by people who are not interested in evaluating or discussing alternatives is to judge ideas as not representing valid alternatives. When an alternative is presented, they may say, “That is not a real alternative,” when it is in fact an alternative; it is simply not an alternative they agree with.

Reversing the Evidence Requirement for ERP

Arguments are certainly simplified when you state that all other alternatives are not real alternatives, do not provide evidence to support your claims, and announce that you have chosen the one true alternative. The following quotation is an example of this type of argument.

“If I’m a major enterprise, especially a manufacturer, what’s the cost of NOT having an ERP system?”

This frames the question in the reverse and is an example of the logical fallacy of shifting the burden of proof. It is designed to essentially ask the person on the other side of the argument to prove that ERP is not a good investment. This is called “proving a negative.” The responder is asked to prove that ERP is not a good investment. This is not how proof works in science. We don’t start off by making a contention, providing no evidence, and then asking the other person to prove our statement is incorrect. But since the question was asked…the bulk of evidence shows that the benefi ts of ERP systems are small. Therefore, naturally, the costs of not having an ERP system are less than the cost of having an ERP system, both in terms of implicit and explicit costs. A company with no ERP system will incur fewer software-related costs and gain better functionality (by choosing the best software for its needs rather than whatever their ERP vendor is offering).

“What are my alternatives to accomplish the same objectives? I submit those alternatives are few and poorly integrated.”

There are a wide variety of alternatives available to accomplish the same objectives. Quite a few financial and accounting applications can be selected and connected to any number of other applications in order to replicate (and greatly exceed) what ERP does. Secondly, while ERP systems are better integrated to themselves, which is a highly parochial way of looking at integration, ERP offers no integration benefit for connecting to a company’s other systems, and may offer higher integration costs than non-ERP environments. Here is a further quotation from the failed Air Force’s ECSS initiative:

“It’s not worth the money to poorly implement anything. It’s worth the money to take the time, hire people with the appropriate knowledge, and do the necessary planning and testing to minimize the chances of an ERP installation failing.”

Unending Excuses by ERP Consultants and Vendors on ERP Failures

In this statement, the individuals take the common approach to analyzing ERP failures: the failure of the ERP project was related 100 percent to how it was implemented and not related to issues with the ERP system itself. How do faulty implementation methodologies explain the low satisfaction rate with ERP systems as a whole? How did a system, which has never shown much financial and operational benefit to companies, gain its halo? Were all ERP systems incorrectly implemented? These types of comments are extremely common among ERP proponents, but they offer no evidence and no new information. They provide nothing more than an excuse, which—thirty years into ERP history—is becoming somewhat stale. The evidence, which few have any interest in reviewing, is that ERP systems produce a meager return on investment, and in other ways are major distractions for companies, drawing energy away from other initiatives. All of the investment of time and money in ERP must be compared against what it could provide if invested in other areas.

Options for ERP

ERP proponents like to present the idea that there are not options to ERP. In fact, they go a step further, they state that there aren’t real alternatives to whatever ERP they happen to have resources they can bill for. Then after they buy ERP, they tell their customers they don’t have options outside of buying applications from the same vendor that made the ERP system. Consulting companies are very good at leading companies down a restricted number of options, all of which end up benefiting the consulting company itself.

Here is the truth, there are a large number of options to ERP systems, and furthermore to how any ERP system is used. Here are just a few alternatives — without getting into any specific vendor offerings.

  1. A commercial ERP system can be purchased, but large areas of it unused, and combined with better external functionality.
  2. A commercial ERP system can be purchased, but large areas of it unused and connected to custom functionality/custom applications rather than porting the code to the ERP system (that is not recoding everything in say SAP’s ABAP and porting to the SAP system)
  3. An open source ERP can be used and with the large extra pool of money, any number web-based (hosted on AWS or Google Cloud for example) applications can be developed and connected to the ERP system.
  4. ERP can be dispensed with entirely, and a financial solution can be connected to both specialized applications and custom coded applications.
  5. ERP can be dispensed with entirely, and a custom coded solution can be created which covers financials and other and combined with specialized applications.

These are just five options. Any number of permutations are possible from these options. The evidence of decades of ERP projects heading back to the 1980s is clear; no company of any size or complexity will use an ERP system by itself without support from other applications.

Financial Disclosure

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 Better Managing ERP Content

References

https://www.forbes.com/sites/oracle/2015/12/24/5-signs-that-cloud-erp-has-serious-momentum/#4a8073d2e8cc

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 Alternatives to Standard ERP Advice

Executive Summary

  • ERP vendors and consultants propose that there are no alternatives to ERP.
  • Learn about very realistic ERP alternatives.

Introduction

ERP promoters make a serious misrepresentation in their discussions of ERP by suggesting that there is no alternative to ERP. To think that there is no alternative, one would have to be biased (either financially—they work in or somehow make money from ERP—or nonfinancial—they are simply used to ERP environments), or they simply don’t understand the enterprise software market very well. Actually there are plenty of alternatives to ERP. Some of the alternatives call themselves “ERP” because this has become the desired terminology, even though they would not meet the technical definition of ERP.

Is Criticism of ERP Simply Negative and Counterproductive?

As part of a broader and quite interesting article about enterprise software, Cynthia Rettig was critical of ERP and SOA software and implementations. In this article, she begins with the following explanation of how IT grew as a percentage of investment since 1970.

“Back-office systems—including both software applications and the data they process—are a variegated patchwork of systems, containing fifty or more databases and hundreds of separate software programs installed over decades and interconnected by idiosyncratic, Byzantine and poorly documented customized processes. To manage this growing complexity, IT departments have grown substantially: As a percentage of total investment, IT rose from 2.6 percent to 3.5 percent between 1970 and 1980. By 1990 IT consumed 9 percent, and by 1999 a whopping 22 percent of total investment went to IT. Growth in IT spending has fallen off, but it is nonetheless surprising to hear that today’s IT departments spend 70 percent to 80 percent of their budgets just trying to keep existing systems running. “But these massive programs, with millions of lines of code, thousands of installation options and countless interrelated pieces, introduced new levels of complexity, often without eliminating the older systems (known as ‘legacy’ systems) they were designed to replace. In addition, concurrent technological and business changes made closed ERP systems organized around products less than a perfect solution: Just as companies were undertaking multiyear ERP implementations, the Internet was evolving into a major new force, changing the way companies transacted business with their customers, suppliers and partners. At the same time, businesses were realizing that organizing their information around customers and services—and using newly available customer relationship management systems—was critical to their success.

“The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus, many companies ended up having several instances of the same ERP systems or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.”

So much money now flows from the ERP industry that criticism is not well tolerated. A lot of water has passed under the bridge here; many entities (whose pockets would be lined by the sale) recommended ERP systems to clients, even though there was no evidence that the ERP systems would improve the condition of these companies. Several of those who criticized Cynthia Rettig had the following to say:

“There’s really nothing new in [Ms. Rettig’s] analysis. But Rettig goes a step further and says there’s no hope for the future. In fact, while she doesn’t offer any remedies for her gloomy prognosis, she does quash one—service-oriented architecture (SOA).”

The beginning of this quotation provides an example of the logical fallacy argument from repetition. Those who dislike research or someone else’s conclusions, but do not have anything of substance to add offer this standard criticism. Rettig disagrees with the proposal that SOA will solve the problems of ERP (a prognosis that ended up being true). Why is that considered “gloomy”?

SOA to the Rescue?

If there is little evidence that SOA will remedy the issues with ERP, then why invest resources into it? Secondly, if there is “nothing new” in Rettig’s analysis, perhaps the analysis is synthesized in a different way. Furthermore, I read through countless articles on ERP that repeated unfounded statements regarding the benefits of ERP—and Rettig’s analysis, and I can’t recall anyone criticizing these generic articles that could have come off of a copy machine from previous articles, yet one of the first articles to be critical of ERP as a concept is not new? What is this author’s definition of new? The explanation that ERP systems have performed poorly by any measure and have a bleak future is not generally accepted, so her analysis is new in the sense that it explains something that is generally not known. Actually Rettig’s article is novel in many ways; it is not original research but does a nice job referencing multiple sources of original research. Furthermore, there is nothing new in the multitude of articles about the opportunity of ERP or about getting more value from ERP, or how SOA was going to make all the ERP investments worthwhile. But no one seems to criticize those articles—because they are promotional. In terms of the criticism regarding “not offering any remedies,” firstly, not every form of analysis needs to provide a solution. The very idea that research or observations need to provide remedies (why would anyone think that is true?), is itself a pretext for rejecting research. This does not provide a positive outlook. In fact, the remedy should be self-evident: reduce one’s investment in ERP software, and do not place one’s bet on SOA as a solution.

As it turns out, this remedy would have been the correct choice. This type of criticism deliberately evades the obvious behavioral adjustment that is implicit with Cynthia Rettig’s analysis. As long as the standard is what is positive rather than what is true, the evidence required for a promotional statement will always be lower than the evidence required for a critical statement.

Reducing ERP Dependency

Companies will benefit if they reduce their dependency on ERP—particularly “Big ERP”—in even small ways. Any redirection of resources away from ERP (for example, replacing ERP functionality with external systems) should benefit the company over the long term. However, companies that buy new non-ERP software that helps them manage their businesses better rather than their ERP software must still pay the support cost of the system, and they will pay the same amount even if they turn off portions of their ERP system. This is a major reason as to why so many companies have continued to implement uncompetitive functionality in their ERP systems when so many better solutions are available in the marketplace: they are attempting to utilize their pre-existing investment in their ERP system.

However, our research demonstrates that this is a faulty logic: companies can only expect to save 12.5 percent of the application’s TCO by leveraging the sunk cost of a previously implemented ERP system. Other applications that are specifically designed to meet business requirements (aka best-of-breed) have better ratings in a variety of compensating criteria. Companies must consider which costs are higher: the cost to purchase better software plus pay the support cost of their ERP system, or the continuing indirect costs associated with their ERP system, including:

  1. A longer implementation
  2. More customization expense
  3. A higher-risk implementation
  4. Lower functionality/worse fit of functionality
  5. Lower usability
  6. Lower maintainability

The Research is Conclusive for the Negative Hypothesis

Once all the negatives are recognized, ERP cannot even be shown to improve the financial performance of companies. The only real demonstrated benefit of ERP has been to the ERP vendors and to implementation companies, not to the actual buyers of ERP software. A purchase of an ERP system is an extremely effective way to lock in a customer to a vendor and to allow the vendor to sell other applications to current customers. Have ERP systems been beneficial for SAP, Oracle, IBM, Deloitte and all manner of consulting companies? There the evidence is clear: ERP has greatly benefited those that sell and implement ERP software. Therefore, if you want to benefit from ERP, sell it or implement it, but don’t buy it.

ERP Adjustment

The value of Big ERP is just not there. Some of the highest rates in the enterprise software space are being charged for what amounts to basic functionality. The resources can be transitioned from Big ERP to applications that offer a better ROI. ERP disintegration is a term that I have coined to describe what should be the next phase of ERP: that is, to begin to give up the long-dead idea that ERP can meet all of a company’s needs (the original proposition for ERP), and that “getting the most” out of ERP is the best strategy for a company to follow. Getting the most from ERP translates very simply to giving the least to your business. Rather than trying to get ERP to do things that it is not good at doing, more diverse applications should be brought into the fold, along with more analytical skills. The ERP period was a period when many people turned their brains off and put their trust in ERP vendors and in official “authorities” (all of whom had financial conflicts of interest) to answer all of their question and to meet all of their requirements. With ERP disintegration, true system integration skills will be brought back within implementing companies and custom solutions will be developed that fit the company’s needs. On average, companies still have 60 percent of their ERP systems modules implemented. It’s been a long road and the payoff has been poor.

It is now all too obvious that the promise of ERP will not be realized, and it will not get better in the future. Too often, applications were purchased from the ERP vendors because customers preferred to go with familiar vendors over vendors whose software best met their business requirements. IT departments have been covering up the deficiencies in software purchased from the major ERP vendors for many years now, and it has led to poor outcomes. Companies looking for the easiest route to enhancing the value of their IT spend should break the cycle of dependency on their ERP vendors and create a competitive environment that rewards software innovation and the best software available. This means running tighter and more analytical software selections, and comparing what is currently implemented in the ERP system against applications that could improve the area.

Free from Overinvestment in ERP

Freed from overinvestment in ERP, the company is able to choose the best software for its needs in each area and then integrate this software directly to the fi nance system. However, for those who already have ERP, the question becomes: What to do with the ERP system, and how to best leverage it?

Essentially, the effect of the ERP system must be minimized. Different areas of the ERP system will gradually cede ground to other applications and the more quickly this happens, the more quickly companies can improve their IT by leveraging the better functionality in non-ERP applications. As a result, ERP vendors will have less infl uence over your company, and your company may not need to upgrade its ERP system as frequently. Remember that there is no reason to look to other software from the ERP vendors, or to give their software preferential treatment.

One approach to detaching from your ERP system is to deactivate complete modules or portions of modules. ERP systems are modular, and in fact, most companies have not implemented all of the modules in their ERP system, but instead continue to use other applications and connect them to the ERP system—although they pay a high price in integration costs and functionality incompatibility to do so. A company can run one module or several modules, and can slowly decommission portions of each module and attach best-of-breed applications. A company that is running a sales and distribution module, along with a production planning module and finance/accounting module, could deactivate the production planning module and instead use a best-of-breed production planning and execution system from the vendor of their choice. They would then integrate this production planning module back to the ERP sales module and the finance/accounting module, instead of integrating the external production planning and execution system to the production planning module, which would then interact with the sales module and the finance/accounting module.

There are plenty of alternatives to an ERP centric approach, and many companies use them. I have included a few alternatives in this book, but this book is really directed toward a review of the research on ERP.

ERP Alternatives Per Company Size

Larger companies tend to be the bread and butter of large ERP vendors such as SAP and Oracle. Mid-sized companies do not use anywhere near the amount of functionality offered by these software vendors. SAP and Oracle started off building their software around the needs of big companies. They adjusted their software to appeal to smaller companies, but their solutions are simply overkill for anything but the larger companies. Therefore, when people address the topic of Big ERP, it is from the perspective that ERP has proven something—at least at big companies. When they do this, they essentially accept the assumptions they have heard from the marketing departments of ERP vendors and their lieutenants, the large consulting companies. As I have shown in this book, research has proven that the fanciful projections regarding ERP were simply marketing hyperbole. To accept the position that “ERP must be helpful” is to accept something that has never been proven. It is argumentum ad numerum—a fallacious argument—that concludes the proposal is true because many people (and companies) believe it to be true.

Options for ERP

ERP proponents like to present the idea that there are not options to ERP. In fact, they go a step further, they state that there aren’t real alternatives to whatever ERP they happen to have resources they can bill for. Then after they buy ERP, they tell their customers they don’t have options outside of buying applications from the same vendor that made the ERP system. Consulting companies are very good at leading companies down a restricted number of options, all of which end up benefiting the consulting company itself.

Here is the truth, there are a large number of options to ERP systems, and furthermore to how any ERP system is used. Here are just a few alternatives — without getting into any specific vendor offerings.

  1. A commercial ERP system can be purchased, but large areas of it unused, and combined with better external functionality.
  2. A commerical ERP system can be purchased, but large areas of it unused and connected to custom functionality/custom applications rather than porting the code to the ERP system (that is not recoding everything in say SAP’s ABAP and porting to the SAP system)
  3. An open source ERP can be used and with the large extra pool of money, any number web-based (hosted on AWS or Google Cloud for example) applications can be developed and connected to the ERP system.
  4. ERP can be dispensed with entirely, and a financial solution can be connected to both specialized applications and custom coded applications.
  5. ERP can be dispensed with entirely, and a custom coded solution can be created which covers financials and other and combined with specialized applications.

These are just five options. Any number of permutations are possible from these options. The evidence of decades of ERP projects heading back to the 1980s is clear; no company of any size or complexity will use an ERP system by itself without support from other applications.

Cap Gemini and their ERP software Business

Cap Gemini has a very large and lucrative ERP software business recommending and implementing primarily SAP and Oracle tier 1 ERP software. When clients approach Cap Gemini, the answer is always the same, regardless of the client’s requirements. This is curious because this ERP software, in particular, score poorly across multiple criteria ranging from implementation duration to the satisfaction level of customers. In fact, the only criteria where they seem to excel is providing Cap Gemini with strong financial returns. Unknown to most corporate buyers, the ROI of tier 1 ERP software have been researched in academic literature – and the results are surprising – essentially no ROI can be found, which considering how much most companies spend on their tier 1 ERP software implementation, combined with the dated and mediocre functionality these applications primarily contain. This story and the explanation of the review of the research into ERP software benefits are explained in the book The Real Story Behind ERP: Separating Fact from Fiction. However, you won’t hear any of this from Cap Gemini. Cap Gemini is not about reading the academic literature or performing research, they have a lucrative business in implementing overpriced and poorly performing ERP software, and the reality of what, after decades of implementations, is becoming increasingly clear will not intrude upon Cap Gemini’s recommendations.

Getting the Right Information

Clients of Cap Gemini should not expect objective advice from an entity that makes a significant portion of its income from ERP software implementations, and implementations of specific applications. For Cap Gemini, the question of recommending SAP or Oracle ERP is an easy one – its excellent for their bottom line.

However, it is not excellent for their client’s bottom line – which is why its important that companies interested both in buying new ERP software, as well as determining the benefits of expanding the use of their present ERP software need a rigorous and unbiased source of information on these topics, the truth of which can never be learned from some company with a pure sales culture like Cap Gemini.

Conclusion

Executive decision-makers undermine their software selection process when they attempt to validate the statements about and capabilities of applications that neither they nor other people in their company have experience with. The executive decision-maker is in a position of weakness, which makes it difficult for them to make informed decisions. First-hand experience regarding all enterprise software is available and can be found on LinkedIn or Dice. Independent consultants may be hired full-time and work on-site, or be hired remotely, depending upon the circumstances and the consultant’s availability. An independent consultant is far more reliable than a consulting company for advising on a software selection. Unlike a major consulting firm, an independent consultant is not attempting to staff consultants on the project.

However, in order to minimize bias, it should be explained to the independent consultant that they will not be part of the implementation in any way. This removes any potential for financial bias and makes the consultant indifferent as to which software the company decides to implement.

Financial Disclosure

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 Better Managing ERP Content

References

https://www.forbes.com/sites/oracle/2015/12/24/5-signs-that-cloud-erp-has-serious-momentum/#4a8073d2e8cc

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 ERP Distracts From and Undermines Intercompany Transfer

Executive Summary

  • Because ERP offers mediocre functionality, it distracts from better functionality outside of ERP.
  • Learn why this leads to so much waste on ERP projects.

Introduction

ERP sets up mediocre functionality at companies and interferes with buying better software that could provide a great deal of value to the business. I will use several examples in this chapter to explain this prevalent feature of ERP software. ERP implementations result in generic functionality being installed. Then, after the ERP system is installed, other applications that provide better functionality are frequently and selectively used to replace ERP. These superior applications must often coexist with portions of the ERP functionality that are still active.

The Problem with ERP and Intercompany Transfer

An intercompany transfer is when a company buys a product from “itself.” While companies make a big deal about being global (and many certainly operate globally), when it comes to finance, a company must actually be incorporated in every country in which it operates, and must report to the tax authorities based upon its activities within a country. Thus, when a product (or service—but as this is planning we concern ourselves with products) is sent/sold between two different companies—say an automotive component from Toyota Japan to Toyota U.S.—an accounting transaction must be generated to record that the product has been transferred. This transaction, which is dated and has a transfer price, moves the product from Toyota Japan’s “books” to Toyota U.S.’s “books.” If you search for the term “intercompany transfer” in Google or on Amazon, you will find that most publications on the topic of intercompany transfer are on the topic of intercompany transfer pricing.

While accounting transactions are not particularly “relevant” for supply chain movements, they do have to be accounted for so that the supply network design can support the type of activities required on the accounting side. Supply chain planning systems and ERP systems generally have a standard workflow for dealing with intercompany movements, and this will work for simple intercompany transfers. However, as soon as the intercompany transfer becomes even slightly more complex, ERP systems most often require expensive customization. Furthermore, because of the rigid design of ERP systems, this customization will consume many analytical and development hours.

Intercompany Transfer Alternatives

There are two basic ways of handling intercompany transfers: a billing stock transfer order and a standard stock transfer order. A standard stock transfer order (STO) is used between locations that are part of one company code. With a standard STO, no billing document is necessary because the STO is an internal movement. A billing STO combines the document used for internal company movements with the invoicing aspect of a purchase order. This is shown in the following graphic.

A normal stock transfer, transfers goods between two internal locations without any billing.

A billing STO simply performs the same movement, and then performs the intercompany transfer in the ERP system. This is shown in the graphic below:

Intercompany transfer is covered by standard ERP system functionality. It combines an internal movement with billing, hence the “billing-STO.” Billing STOs work for straightforward intercompany transfers. The billing STO is the most straightforward way of transitioning ownership between two companies within one global company. However, it does not even come close to meeting all of the requirements of an intercompany transfer. For instance, some companies have multiple locations that interact with one another during an intercompany movement; while the billing relationship is between two locations, the goods are moving between different locations. Entities other than the receiving location can be involved in invoicing the sending location.

In fact, there can be four or five locations (or possibly more, although I have never seen more than five location interactions). The standard billing STO will not meet the requirement because the billing is not applied to the location that is sending the product. This is a complexity that is missed by those who propose the non-billing STO for every intercompany transfer situation. (I know as I used to be one of those who proposed the non-billing STO for a company that had a more complex need than I fi rst understood.)

Matching Purchase Order/Sales Order for Asymmetrical Intercompany Transfers

To understand this nonstandard approach to intercompany transfer, we will begin by reviewing the standard purchasing goods transfer.

Standard purchasing transfers goods from an external location to an internal location with billing. However, intercompany transfer combines features of both the internal stock transfers and purchasing.

When the interaction between the locations is complex, and there are more than two locations, customization is required. Here the stock transfer goes between locations B and A, but the invoices go between locations A and C.

A custom program is required to take a stock transport requisition (STR), which in this case is created in the external supply chain planning system, and convert it into several documents, such as the Sales Order and Purchase Order pair between locations A and C, and the STO between locations C and B.

Thus, while an STR is created in APO, once it is sent to ERP, that same transaction becomes a purchase order and sales order (which cancel each other out as they are for the same item or items and same quantities. The sales order and purchase order are simply two transactions moving within a company, or should I say two different companies—a company buying and selling to itself but situated in different countries). Let’s review how the two different approaches work.

  1. Standard Intercompany Transfer: When product flows from an intercompany location A to location B and the invoice flows from location B to location A, a billing STO is the standard and most direct way of managing the relationship between the locations. The external supply chain planning system is unaware that the STO is billing or not billing. Billing is managed completely in the ERP system as external supply chain planning systems do not deal with money. This approach is relatively easy to configure.
  2. Asymmetrical Intercompany Transfer: When more than two locations are involved in the stock transfer relationship, the billing STO is not the way to set up this relationship, as it will place the invoice in the wrong location. In this case, an STR is still created within the external supply chain planning system between the sending and receiving locations. However, once this STR is sent to the ERP system, the STR must be converted to matching purchase orders and sales orders. These items will move between additional locations beyond the two that are involved in the stock transfer. A company involved in broad-scale international stock movements will sometimes have different intercompany transfer models. Some of these models mean the creation of a paired purchase order and sales order from a stock transport requisition/order created in the external supply chain planning system. Other movements may require no sales order, and in this case, the STO is simply converted into a purchase order.

Controlling Transfer of Ownership in ICO Movement

In most cases, the transfer of ownership will occur when the product is receipted into the receiving location. Although this is the standard workflow for most ERP systems, it does not meet the requirements of all companies. Some companies want the ownership transfer to occur after the product has left the sending location but before it arrives at the destination location. I have found this to be true particularly of transfers with very long lead times, such as ocean carriage.

The graphic on the following page shows the standard transfer of ownership versus the custom alternative.

The first alternative is preferable as it is in line with how many external supply chain planning systems and the ERP system operate. However, for different reasons, some companies prefer the second alternative. Because the transfer cannot be performed while the product is in-transit, an intermediate location—which is not an actual physical location but is a virtual location—is sometimes set up in order to perform the transfer.

The Core Problem of Limited Dimension Transactions

The issue that companies face when attempting to manage complex requirements of this type is that the ERP system is too limited and too inflexible to be adjusted. Instead of prescribing a limited set of functionality, ERP systems could have been designed quite differently.

We use the terminology of STO, non-billing STO, and billing STO. All of this terminology really just describes transactions that behave differently in a dimension where the transaction impacts the ERP system, as shown in the graphic below:

 

A transaction is nothing more than a container that initiates a series of related transactions— which change the state of the ERP database in prescribed ways. Rather than prescribing a limited number of ways that a transaction can behave in a particular dimension, one can open up the options, and this can be accomplished with far less complexity and without the confusing terminology. It is unclear why so many ERP systems took such a prescriptive approach when developing the software in the first place. Perhaps they lacked the development sophistication to make flexible systems and wanted to reduce the costs of development. Creating a system of more limited behavior within the dimensions of a transaction saved development effort and money in the short term, but is ultimately a poor trade-off. The software must be customized per client location, resulting in a great deal of redundant customization (because the same customization, or at least very similar customizations, must be performed in a decentralized fashion at implementing companies). In case the point is elusive, this is exactly what has happened with ERP systems.

An alternate development approach is to decompose the transaction to its behavior per dimension, provide an initial set of common dimension combinations, and allow the transaction to be easily extended. This can happen by simply copying over a pre-existing transaction variant and making a single change to a dimension behavior (or to multiple dimension behaviors), resulting in a new transaction variant. An example of this is shown below:

The total library of the transactions categories and variants within those categories constitutes the total of the functionality within any ERP system.

What I have described above would be the perfect scenario, but ERP systems were not designed this way. And because of their transactional inflexibility, the tight integration of their modules means that they restrict the ability of companies to fully leverage the functionalities in applications that are connected to ERP systems. Thus a company with an ERP system will receive less value from any other application that they implement (unless the application is extremely simple) than a company that does not have an ERP system. This is one of the major reasons why most ERP systems are either a dead end—or simply a starter kit setting a company for much more expensive and work down the road.

Financial Disclosure

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 Problems and Inefficiencies Content

<

References

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

How to Understand Why ERP Has a High TCO and Low ROI

Executive Summary

  • ERP is sold on the basis of its unsubstantiated financial benefits.
  • Find out why ERP systems have a high TCO and normally a negative ROI.

Introduction

The Wikipedia definition of total cost of ownership (TCO) is as follows:

“Total cost of ownership (TCO) is a financial estimate whose purpose is to help consumers and enterprise managers determine direct and indirect costs of a product or system. It is a management accounting concept that can be used in full cost accounting or even ecological economics where it includes social costs.”

Background on TCO

We find TCO research incredibly illuminating. TCO is one of the most misunderstood, abused and underutilized tools for enterprise software decision-making. Our work on TCO has provided us with insight across multiple software categories. In fact, it is a mistake to limit the use of TCO to such a narrow range of decisions. Because we perform TCO for so many software categories, we know the following:

  • How the TCO varies based upon the size of the implementation.
  • How the TCO varies based upon the delivery method (SaaS or on-premises).
  • How TCO varies based upon the complexity of the implementation.
  • The average percentage that one can expect the implementation to cost for any one specific cost item, or for cost categories such as implementation, license, hardware, or maintenance and support.
  • Using ERP combined with 100 percent ERP vendor applications.
  • Using ERP combined with 100 percent best-of-breed solutions.
  • Open source ERP, 100 percent best-of-breed solutions.
  • No ERP, 100 percent best-of-breed solutions.
  • The risks of various software categories.

False Assumptions of ERP

The analyses include assumptions that are often not considered, such as realistic average implementation times. These implementation times, which are habitually underestimated by vendors and consulting companies, have been taken from actual projects. I can say unequivocally that from this database of knowledge we have been able to disprove many deeply entrenched concepts that drive IT decisions to poor outcomes. In our view, combining unbiased and highly detailed TCO calculations, along with an evaluation of comparative software functionality based on strong domain expertise, are two of the most important inputs to producing quality IT decisions.

Unfortunately, this knowledge is not resident within companies, and ERP software vendors (as well as consulting companies and IT analysts) have not informed companies as to the true TCO of ERP systems; it takes work to do this analysis, and probably more importantly, the ERP vendors do not want buying companies to know.

Various ERP TCO Studies Versus Our Estimates

The study What Managers Should Know About ERP/ERP II estimates the costs of ERP software licenses to be between 10 and 20 percent of the overall TCO, which is higher than we estimate. While the software license cost of most application categories averages 20 percent of the TCO, we estimate 8 percent of the TCO of Tier 1 ERP software is due to software license costs. ERP implementations take so long, and have so much customization, and therefore, maintenance expense. So it’s not that the software license cost is lower; the TCO is made so much larger by the customization and implementation expenses that the software license cost becomes a smaller percentage of the cost in comparison. The book, Control Your ERP Destiny: Reduce Project Costs, Mitigate Risks, and Design Better Business Solutions considers a reasonable estimate of the costs of ERP software to be 20 percent of the total project budget. According to this book, software vendors provide their potential customers with estimates (as do consulting companies) that consulting costs will be roughly twice the cost of the software. One independent source, called 180systems, actually estimates that consulting costs average 65 percent of the license costs (71 percent for larger customers and 59 percent for mid-sized customers). Below is a meta-analysis and comparison of my individual TCO analyses in this regard.

While the software vendor estimate of consulting costs holds true for my sample (although you can see that there is considerable variability), this does not correlate with our estimations because other TCO estimations that we have reviewed consistently underestimate the TCO of applications. Because license costs are explicit costs, they are the easiest to estimate, and thus the easiest to overestimate in relation to other costs.

Estimations from other sources are all over the map. Some entities recommend a rule of thumb of 1:1 between license and consulting costs. The software vendor e2benterprise recommends a ratio of between 1:3 to 1:4. We worked backward from these numbers and found that the estimations on the software license costs are solid, but the ratio of 1:4 only estimates consulting; it does not bring the total ERP cost even close to the estimations of the total costs of ERP. Additional costs such as the vendor support costs, hardware costs, and ongoing maintenance costs are well known. It is difficult to see why so much emphasis is placed on the software and implementation costs while maintenance costs are left out. Hardware costs are barely worth mentioning as they represent a small percentage of the overall TCO, but estimated maintenance costs must be included in decision-making.

The Brightwork Research & Analysis Estimates

On our website, we estimate software, hardware, implementation, and maintenance costs—both external costs and internal costs. The maintenance costs are incurred to keep the applications running, but also include maintenance of customizations. As 96 percent of ERP implementations require moderate or heavy customization, work is required to keep customizations up-to date with new releases and to augment the customizations, and this makes ERP software maintenance a high cost. An important aspect to consider when evaluating ERP TCO studies is that the consulting expenditures on most ERP projects are significantly over-budget, something that ERP software vendors would not have included in their TCO estimates.

Generally speaking, a 100 percent success rate is assumed for implementations (strange, as the real success rate, is far lower than this) when vendors estimate TCO for ERP and enterprise software. However, if the project goes over-budget or fails, the estimates provided by the software vendor do not apply, and neither do our estimates. We have observed this as a problem in terms of how projections are performed and I explain this in the book Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects. We are currently developing risk estimators for all analyzed applications; these risk estimates auto-adjust based on the application, the consulting partner used, and the stated capabilities of the company. The company can perform their own interactive analysis right on our website.

Is the TCO of Failed Implementations Included?

What is the TCO for software that is never implemented? I have interviewed for several projects (and worked on a few projects) that were re-implementations, where the software failed to go live.

That failure may have taken a year and a half; the company focused on other things and then decided to re-implement the software two and a half years after it began the first implementation. If the software is taken live the second time, most likely the project will have a negative ROI. The standard ERP TCO calculators we provide would not apply. Therefore, a question that anyone with an interest in ERP estimation should ask is: If 60 percent of ERP implementations fail, and if the vast majority of ERP implementations miss their deadlines by significant durations, why are TCO estimations still based upon assumptions that do not include these very critical factors?

There is little disagreement on the fact that companies repeatedly underestimate the costs of ERP systems.

“In ERP systems, having clear criteria for success is particularly important since the cost and risk of these valuable technological investments must be reviewed in light of possible payoffs. Mabert, et al. (2001) put the total ERP implementation cost at tens of millions of dollars for a medium-sized company and $300 to $500 million for large international corporations.”Measures of Success in Project Implementing Enterprise Resource Planning

According to Aberdeen, the average number of users per ERP software vendor is as follows (we used Aberdeen’s numbers for this purpose, although Aberdeen’s TCO studies were not used in this book):

There are significant price differences if just the aggregate license revenues are compared among a sample of ERP vendors. However, this difference in license revenue is primarily driven by the differences in the average number of users. On average, the Tier 1 ERP vendors such as Oracle and SAP have a much larger customer base, as measured here by the number of users. This relationship is so strong that a regression performed between just the number of users and the software cost results in a 96.75 R Squared, as the following graphic shows.

The average number of users for Microsoft is more comparable to Lawson, QAD, and Infor than they are to Oracle and SAP.

Even though it is well known that ERP does not lower costs, the actual cost of ERP goes well beyond the direct cost of the software, but extends to the indirect costs such as the costs of maintenance, the costs of adjusting the functionality in other systems in order to make it compliant with how ERP works, to increased needs for customization, to losses in inefficiency as mediocre ERP functionality is used in place of better functionality that could be obtained by buying specialized software. In the vast majority of cases, companies did not perform TCO analyses prior to purchasing ERP systems. It is now long forgotten that ERP systems were sold based on the concept that they would lower costs (the idea that an ERP system could have a low TCO is laughable even in the present day). Since then, ERP systems have proven to be very expensive, not only to implement but also to maintain, as the following quotation explains.

“ERP systems were expensive, too, costing companies more than they had ever paid for software when costs had been based on per workstation usage. But that price tag was dwarfed by the installation charges, because companies had to hire brigades of outside consultants, often for a number of years, to actually get the software up and running. While the average installation cost $15 million, large organizations ended up spending hundreds of millions of dollars.”The Trouble with Enterprise Software

How Mistakes With Respect to ERP

The long-lived mistakes with respect to ERP have affected every part of IT today. ERP systems have proved to be much more expensive than even the highest “generalized” cost estimates (even though 80 percent of the time companies did no real estimation), and ERP systems now consume a very substantial portion of the overall IT budget, particularly for companies that purchased from the most expensive Tier 1 ERP software vendors. The high investment in ERP negates investment in other possible applications, even though most of these other applications would have a higher ROI than ERP. All ERP ever offered was basic functionality, and any company that has basic functionality consuming the majority of its IT budget has a serious problem of resource allocation. By that measure, an enormous number of companies have this problem. The direct cost of ERP systems has continued to increase. When companies give so many modules over to one vendor, they also give up a lot of negotiating leverage. The ERP vendors use this leverage to:

  • Sell uncompetitive software in other areas of the same account.
  • Increase the cost of the yearly support contract. The TCO of on-premises ERP systems is generally considered to be high compared to other application categories. It is quite amazing that writers who cover ERP implementations do not bring up these issues with any frequency. Various articles will discuss how expensive ERP systems seem, but the enormous elephant in the room—the leverage of ERP vendors—is unaddressed.

The Influence of the Length of Implementation Times on the ROI of ERP Systems

ERP systems have very long implementation times, and a high run rate in costs.

The ERP Implementation Duration

The implementation time for ERP systems is the longest of any enterprise software category. The term “implementation time” is laden with assumptions. At our site we perform risk and duration estimation for all of the major enterprise software categories. ERP has by far the longest implementation of any software category—and by a wide margin.

Furthermore, ERP software comes with high risks for implementation. According to IDC, 15 percent of survey respondents implemented their ERP software again. What was the implementation time on those projects? It is not easy to find detailed TCO studies on ERP systems, which is one of the reasons we began estimating it on a separate website. ERP ROI The ROI of ERP is an interesting topic; as one would expect, a company implementing an application with a very high TCO is put at a disadvantage when it comes to obtaining a high ROI.

“A Meta Group study of sixty-three companies a few years ago found that it took eight months after the new system was in (thirty-one months in total) to see any benefits. The median annual savings from the new ERP system were $1.6 million—pretty modest, considering that ERP projects at big companies can cost $50 million or more. ERP systems may be integrated, but on-premises ERP has proven to be poor at integrating to other applications and to business partners.”The ABCs of ERP

“Markus, et al. (2000) argued that the companies that adopted ERP systems need to be concerned with success, not just at the point of adoption, but also further down the road. After ERP implementation is complete, the expected return may not come as soon as desired. In fact, most ERP systems show negative return on investment (ROI) for the first fi ve years that they are in service.”Measures of Success in Project Implementing Enterprise Resource Planning

This is quite a statement.

And the implications of this statement cannot be understood without performing a little math.

The math presented above is problematic when one compares the known estimated durations with ERP. Generally, ERP systems are thought to have a useful life of between eight and twelve years. If it is true that no return can be expected for the first five years of use, it is seven-and-a-half years into the ERP project when the company has begun paying for the ERP system (including two-and-a-half years of implementation time).

If the ERP system is decommissioned after eight years, the company has three years to receive a return (which would clearly mean a negative ROI). If the ERP system is decommissioned at the high side (after twelve years), there are seven years or 58 percent of the total time the ERP system is in the company to receive a return. While the information up to this point is problematic, the news gets worse with the following statement.

“After the first five years of use, a company can expect steady returns, but not in the traditional form of revenue. As Markus and Tanis (2000) indicated, different measures are needed at different stages in the system lifecycle and a minimum set of ERP success metrics should include projects metrics, early operational metrics and long-term business results.”Measures of Success in Project Implementing Enterprise Resource Planning

According to this quote, there are close to no financial returns, which is what studies generally say. Researchers think that no return can be expected until seven-and-a-half years after the ERP project kick-off. While no financial return can be demonstrated, it is implied continually that ERP pays off in other ways, ways that are imperceptible to the company’s financial health. In fact, the company may not be able to expect a return until other applications are connected to the ERP system.

Selling the Dream…..of ROI in on Related Items

“‘There’s a general understanding today that ERP is the investment you have to make just to get into the game,’ says Josh Greenbaum, a principal analyst with Enterprise Applications Consulting. ‘First you have to get ERP installed, and then you can take a look around and see where major ROI can be achieved. It’s the so-called secondwave applications, such as business intelligence, supply-chain management, and online procurement, that can leverage the ERP backbone and offer the highest return,’ says Greenbaum.”Making ERP Add Up

That is one incredible statement. Talk about “future selling.” There is no evidence that ERP improves the benefits/return on investment from other applications; this is utter conjecture on the part of this analyst. Then comes the other issue with estimating operational benefits, as the following quotation explains.

“According to Parr and Shanks (2000) ‘ERP project success simply means bringing the project in on time and on budget.’ So, most ERP projects start with a basic management drive to target faster implementation and a more cost-effective project… Summarizing, the project may seem successful if the time/budget constraints have been met, but the system may still be an overall failure or vice versa. So these conventional measures of project success are only partial and possibly misleading measures when taken in isolation (Shenhar and Levy, 1997).”Measures of Success in Project Implementing Enterprise Resource Planning

With such high costs, ERP ends up consuming a very large portion of the overall IT budget. The maintenance of ERP systems consumes anywhere from 50 to 90 percent of the IT budget according to Forrester and Gartner. ERP software, as with any other type of software, consumes resources across all of the IT operating budget categories. ERP has proven to be an expensive proposition for companies and did not reduce costs as was promised by its proponents. The problem is that both the direct AND indirect costs of ERP systems have been high.

The Low (and Misleading) ROI of ERP Software

It is difficult for ERP to have a good ROI if it also has a high TCO. Obviously, the TCO is the denominator in the ROI equation, with the business benefits being the numerator. Another problem with ERP ROI is that ERP systems take a long time to implement. Other estimations are shorter, but I have not been able to find any research that provides a solid method for this analysis. I quote this book’s estimate not because it explains or divulges its data points, but because I find the book credible in other aspects. However, even this book’s estimates are lower than the study by Meta Group, which proposed that it takes eight months until the ERP system begins showing any benefit. This figure is contradicted by the study The Impact of Enterprise Systems on Corporate Performance, and that after the ERP implementation the company loses productivity every year the ERP system is live. (This study is discussed on the next page.) If we take the lowest estimate and average the high and the low values, we get the following:

((12 + 36 months)/2 + (4 + 6 months)/2) = 29 months 29 months / 12 = 2.4 years

According to the above calculation, a company must pay for an ERP implementation for two years and then wait another five months before the software is functional to the degree that it can be relied upon. That is taking the average of the most optimistic of the three estimates; other scenarios are not even this rosy. For instance, one scenario is that the company never sees any productivity benefit even though it implements the ERP system. Another scenario is that there is a 40 percent likelihood of major disruption to business operations during the go live. What is the cost of this “major disruption”? Well, that is not estimated. What about smaller disruptions? It would seem quite likely that smaller disruptions occur with even greater frequency; however, I have never seen a TCO analysis for ERP that includes the costs of these disruptions. An interesting timeline was provided in the paper Which Came First: IT or Productivity? where a full timeline of an ERP implementation, as well as the software that followed it, was laid out.

This shows the timeline for a relatively fast ERP implementation of nineteen months from the ERP system kickoff until the full go-live. However, this company would not have seen the full benefit of ERP until the ERP system was fully integrated, which is not mentioned in this study.

In fact, most estimates are unreliable because they are put out there by consulting companies or ERP vendors themselves. Generally, what is not debated is that ERP software takes the longest of any software category to implement. Furthermore, most of the estimates of ERP implementation timelines leave out the time taken to integrate other applications to the ERP system. Gartner estimates that it can take up to five years to integrate the other applications within the company to the ERP system. Because the full benefits of an ERP system are not realized until ERP is integrated to all the company’s various applications, the value realized is incremental up until that time.

The Problematic Logic of ERP Driven Improved Financial Performance

Our research into the studies of ERP ROI shows the following:

  1. ERP implementations show no positive business benefit, and often impose significant costs (e.g., missed orders due to lack of inventory, inability to ship orders that are received due to execution problems).
  2. The potential for ERP implementations to show a positive business benefit for up to a year after implementation is low, as the company is still adjusting to the radical changes that an ERP system imposes on a company. Once these problem projects are thrown into the mix, the average return for an ERP planning project is negative.

While there is no research into the ROI of ERP software, one would assume that ERP would generally have a poor ROI for the reasons listed above. Others, such as the Sloan Management Review, have noted this lack of ROI research:

“Given the high costs of the systems—around $15 million on average for a big company—it’s surprising…that despite such study, researchers have yet to demonstrate that ‘the benefits of ERP implementations outweigh the costs and risks.’ It seems that ERPs, which had looked like the true path to revolutionary business process reengineering, introduced so many complex, difficult technical and business issues that just making it to the finish line with one’s shirt on was considered a win.”

This begs the question as to why, as stated in the above quote, “ERPs…had looked like the true path to revolutionary business process reengineering.” The answer to this question is simple: a number of entities with a strong financial bias declared it to be so.

Negative ROI: The Missing Link of the ERP ROI Research

Every research study into the ROI of ERP systems that I reviewed (except for the research that attempts to find a correlation between ERP implementations and the financial performance of companies) contains several flaws. Some of this flaws have been stated previously in this book and relate to an underestimation of the TCO as described in the previous section. Obviously, if the TCO is not conclusive, then the ROI is inaccurate; the TCO is the base or the “I” in the ROI. Let’s review the issues with estimations of the TCO (issues that are usually overlooked) before moving on to examining the error from the return side.

  1. The TCO for ERP projects are not adjusted for risk.
  2. The total length of ERP projects is not included in the TCO calculation. The longer the project, the longer it takes for the project to pay back the investment. Furthermore, ERP projects are so problematic from the integration perspective that it can take up to five years for them to be fully integrated with other systems, and therefore fully operational.
  3. There is a 40 percent likelihood of a major operational disruption after an ERP project goes live. The costs of these major disruptions nor the costs of smaller disruptions are included in the ERP TCO calculations.
  4. ERP TCO estimations consistently underestimate the actual TCOs of projects. These estimations completely neglect or underestimate the costs of internal resources to adjust to and learn the ERP system. Actually, this issue is not specific to ERP software but is a feature of enterprise software generally. However, the large-scale nature of ERP software makes this issue worse.

The error on the return side of ROI is that ERP ROI studies look at the ERP system in isolation from the other software that the company implements. However, as will be explained in more detail in “Case Study #4 of ERP Misuse: Intercompany Transfer”, the transactional inflexibility of ERP systems—the fact that they have their modules so tightly integrated—restricts a company’s ability to fully leverage the functionalities in applications that are connected to ERP systems. As a result, a company with an ERP system will receive less value from other applications that they implement (unless the application is extremely simple) than a company that does not have an ERP system. Companies with ERP systems do not leverage the other applications that they purchase and implement, and this means the companies must use more of the mediocre functionality within the ERP system. I found this statement by Aberdeen very interesting:

“As ERP has become more pervasive, there is always a risk in perceiving it as necessary infrastructure. If viewed as a requirement for doing business, companies also run the risk of neglecting to measure the business benefi ts resulting from its implementation.”

I would say this statement is a bit late. The decision to purchase ERP was not based upon measurement of its business benefits, but was primarily based upon an idea that ERP systems were “necessary infrastructure.”

Support Costs of ERP

The maintenance costs of Tier 1 ERP (and possibly other tiers as well) are likely headed upward. ERP software is stabilizing; it is falling further and further behind the other applications connected to it and that can replace much of ERP’s functionality. Instead, SAP moves almost all of their newer functionality to their non-ERP modules, as they can charge new license fees for the modules. Analysts are not picking up on this, but investment in ERP has wilted, and ERP systems are unable to meet requirements without further customization. Your ERP vendor already has your ERP business; now they want to nudge up the ERP support costs and they have some other software they would like to sell you. The High

Opportunity Cost of ERP

The opportunity costs of ERP are underemphasized (or ignored altogether). The term “opportunity cost” is used infrequently, so let’s define it before we explain how it should be used in making decisions:

“In microeconomic theory, the opportunity cost of a choice is the value of the best alternative forgone, in a situation in which a choice needs to be made between several mutually exclusive alternatives given limited resources. Assuming the best choice is made, it is the ‘cost’ incurred by not enjoying the benefit that would be had by taking the second best choice available.” — Wikipedia

In general parlance, costs are often described as the amount that we pay for things. Economists look at costs quite a bit differently. Opportunity cost is one cost category, and sunk cost.

Promoters of ERP tend to present any benefits of ERP without acknowledging that the time and effort spent on ERP could have gone into other initiatives. However, the gain from those systems should be compared against the gain from ERP systems.

Let’s take a simple example. Imagine that I have no car. I have a hard time getting around town because I lack transportation. To improve my condition, I buy a Hummer. After a week, I report that I am able to get around town much more efficiently, and compared to walking, I am now much more mobile. Have I established that the Hummer was the best possible alternative? Obviously, I have not proved this. I could have purchased any car—almost any of them with lower operating costs than a Hummer. Therefore, the question is not whether the purchase of the Hummer improved my condition compared to the other alternatives (these alternatives could have included any other car of equivalent or lower cost, public transit, bicycle, etc.). Does my analogy that a Hummer is the best automobile one can buy sound silly? Well, it should, but it is no sillier, no less evidence-based, than the evidence presented for why ERP has helped companies. The comparison can never be between “something” and “nothing,” but between two “somethings.” People that compare something to nothing are stacking the deck in favor of the “something” and are not promoting research or a logical and serious framework.

The Logic of ERP Driven Improved Financial Performance

Enterprise software implementations should have a positive ROI. This is why they are purchased. In this section I will provide a synopsis of the research findings.

“The results are based on a sample of one hundred eighty-six announcements of ERP implementations; one hundred forty SCM implementations; and eighty CRM implementations. Our analysis of the fi nancial benefits of these implementations yields mixed results. In the case of ERP systems, we observed some evidence of improvements in profitability but not in stock returns. “The results for improvements in profi tability are stronger in the case of early adopters of ERP systems. On average, adopters of SCM system experience positive stock returns as well as improvements in profi tability.” — The Impact of Enterprise Systems on Corporate Performance

This makes sense because ERP functionality was more advanced in the past. Now the technology of almost any on-premises ERP system will be quite dated. Secondly, at one time an announcement that a company was going to implement an ERP system would have had an effect on stock prices because the system was considered leading edge. However, ERP systems are so common now that a bump in stock price can no longer be expected. Interestingly, the improvement in financial performance for ERP lagged SCM implementations. When ERP is compared to other types of implementations, it consistently lags other enterprise software categories.

The Stock Price of Firms that Invest in ERP

“The evidence suggests that over the five-year period, the stock price performance of firms that invest in ERP systems is no different from that of their benchmark portfolios.”The Impact of Enterprise Systems on Corporate Performance

This means that investing in an ERP system did not impact the stock price of the companies in the study.

“The positive changes in ROA (Return on Assets) during the implementation period are statistically signifi cant at the 5 percent level. Although the changes in ROA during the post implementation period are positive, none of the changes are statistically signifi cant. Overall the evidence suggests that although fi rms that invest in ERP systems do not experience a statistically significant increase in stock returns, there is some evidence to suggest that profi tability improves over the combined implementation and post-implementation periods.” — The Impact of Enterprise Systems on Corporate Performance

ERP Versus SCM ROI?

While the financial benefits of ERP investments are either nonexistent or barely perceptible, the results of SCM software investments were positive; while investments in CRM software were the same as ERP, they did not show gains. Furthermore, clients that were early adopters of ERP achieved better returns, which means that returns of companies that have recently implemented ERP are even worse.

“The results for the accounting metrics provide strong support that fi rms that invest in SCM systems show improvements in ROA and ROS (Return on Sales). Improvements are observed in both the implementation and post-implementation periods, with mean and median changes in ROA and ROS generally positive and most are statistically signifi cant at the 2.5 percent level or better.”The Impact of Enterprise Systems on Corporate Performance

ERP Versus CRM ROI?

CRM on the other hand scores very similarly to ERP implementations: no relationship to financial performance improvement can be found.

“Over the full four-year period, the mean (median) abnormal return is –15.22 percent (–12.41 percent), and nearly 53 percent of the sample firms do better than the median return of the firms that belong to their assigned portfolio. However, none of these performance changes are statistically significant. Basically, investments in CRM systems have had little effect on the stock returns of investing firms. These results are consistent with that of Nucleus Research (2002), who report that 61 percent of the twenty-three Siebel customers that they surveyed did not believe they had achieved a positive ROI.” The Impact of Enterprise Systems on Corporate Performance

Overall ROI of ERP

“Despite the generally positive acceptance of ERP systems in practice and the academic literature, other studies have not found overwhelming evidence of strong positive performance effects from investments in ERP systems. Our results are generally consistent with these findings.”The Impact of Enterprise Systems on Corporate Performance

“For example, although Peerstone Research (Zaino [2004]) found that 63 percent of two hundred fifteen fi rms gained ‘real benefi ts’ from adopting ERP, they also report that only 40 percent could claim a hard return on investment (ROI). Other ROI results are reported by Cooke and Peterson (1998) in a survey of sixty-three companies that found an average ROI for ERP adoption of negative $1.5 million.”The Impact of Enterprise Systems on Corporate Performance

“Overall we find that, controlling for industry, ERP adopters show greater performance in terms of sales per employee, profit margins, return on assets, inventory turnover (lower inventory/sales), asset utilization (sales/assets), and accounts receivable turnover.”ERP Investment: Business Impact and Productivity Measures

This last quote sounds convincing, although no numbers are listed and there is no comparison of the financial benefit versus the implementation of another type of system. Furthermore, it is no longer possible to be an earlier adopter of ERP software; at this point one can only be a late adopter, meaning that the benefits to adopting ERP are lower. The data for this report was taken from companies before or during the implementation (prior to the system being live) and prior to when the system is operational and providing benefits to the company. This same report stated that the benefits of the ERP implementations began to reverse after the system was live. Here are the productivity gains from the same study.

“There is a productivity gain during the implementation period, followed by a partial loss thereafter. When value added is used as the dependent variable, the gains are 3.6 percent during implementation with a loss of 4.7 percent for a net gain of –1.1 percent (t=.8, not significant).”ERP Investment: Business Impact and Productivity Measures

How Much Money Has Been Wasted on Oracle and SAP ERP?

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

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

The Team Effort for Required for the Analytical Failure

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

Ubiquity of ERP

Because ERP is now so ubiquitous, it is assumed that ERP is necessary — even if it does not provide any payoff. However, there are a large number of flaws in this common assumption. “ERP” is some things. First, it is a concept, which is defined by the book as the following:

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

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

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

Including the Larger Picture Analysis — Post ERP Implementation

The studies on ERP ROI are focused only on the ROI of the ERP system. However, none of the studies that we reviewed looked at the overall picture. We analyzed this in the Brightwork Solution Architecture Analysis.

The problem with the ROI of just ERP is that it limits the impact that ERP systems have on the other applications that are purchased. This is because the strategy of ERP vendors to push what are most often marginal applications into the customer by the ERP vendor. A perfect example of this is SAP. SAP has an extremely poor stable of applications outside of their ERP system, the sordid history for which we covered in the article How SAP is Now Strip Mining its Customers.  None of the research includes this very important implication. (Oracle, SAP, Infor, Epicor, Sage), etc…. the larger ERP vendors follow this approach.

How Much Do Companies that Implement ERP Know About their Lack of ROI?

This quotation for Sam Graham, a highly experienced independent ERP consultant applies.

“ROI rarely comes into the equation. At best, ERP is seen as an inevitable necessary evil, or a ‘rite of passage’ to becoming a big company (SAP had a very effective campaign in the UK (and presumably other markets) a few years back, along the lines of, “Now SAP isn’t just for large companies” which glossed over the fact that they were actually talking about Business One. Clever marketing; and a lot of companies fell for it, believing that they were running the same software as the ‘big boys’.) Rarely do they talk to independent ERP consultants and, when they talk to general management consultants, these people are usually keen to sell their services (and gain experience in ERP) so the last thing that they will do is put obstacles in the way of their clients buying a system.

In my last job in industry, I was taken on as Materials Manager for a $100m t/o Swiss company that had just had a disastrous BPCS implementation. They approached what was then called Coopers & Lybrand (now part of PWC) for assistance. C&L sent in a consultant, who identified more work than one consultant could handle, so they pulled in a second, and then a third. Now; when you had 3 C&L consultants, you had to have a senior consultant to supervise them. And when you had 3 senior consultants, you had to have a partner to manage the 3 senior consultants. So they ended up with a partner, 3 senior consultants and 9 consultants on-site. 5 days a week. I’m not making this up; but it gets worse.

This was in the days of MRPII and, in those days, Ollie Wight & Associates were thought to do the best courses on the subject. So the Partner persuaded our CEO to send all of the company’s management team on a 5-day course. Then, when they came back, he said to the CEO, “You know, now that your people have been on that course, there is a danger that they will use terminology that our people don’t”. So he persuaded the CEO to pay for the same 5-day course for all 13 C&L staff on the project. And that meant not only paying for the courses, hotels, expenses etc; but paying for their time to be on the course!”

This is our observation as well.

Companies that purchase ERP listen to biased entities, ERP vendors and ERP consulting companies that are presenting them with sales information.

Why Software Vendors Don’t Want to Know the ROI of Their Software

Considering how often vendors talk about their software having a high ROI, they seem quite disinterested in having it calculated. What explains the vendor’s fear of ROI calculation?

It is frequently stated by consulting companies, Gartner and software vendors that this or that application has a high ROI. SAP is one of the most common promoters of the great benefits of ROI of their applications. In this article, we will get into how true this is and what vendors want people to know about the ROI on their applications.

The Generalized Assumption of ROI

Software vendors and consulting companies frequently use verbiage such as “improving ROI” for applications that have no evidence of having any ROI. One of the most surprising things is that even the grandaddy of enterprise software, the ERP system actually does not have evidence of having a positive ROI.

If we look at ERP, what was the evidence that ERP systems had a positive ROI? Well, I analyzed all the academic research on ERP systems and found no evidence for a positive ROI from ERP. I was so surprised by this result after being told the opposite by just about everyone; I wrote a book on these findings called The Real Story Behind ERP: Separating Fiction from Fantasy.

(you can obtain a positive ROI on ERP, but that is a different topic from what normally happens)

The problem, of course, is that vendors and consulting companies have a conflict of interest when describing the ROI of software. Software vendors and consulting are in the business of selling enterprise software. Therefore, there is a natural tendency to underestimate the costs of their applications and to overestimate the benefits. A high percentage of software implementations fail to provide any positive ROI, and a high percentage of software implementations actually provide a negative ROI. But even with the biggest software implementation failures, the software vendor and consulting companies that perform the implementation still benefit.

And who were the main proponents of system implementations being a necessary purchase? The software vendor, Deloitte, IBM, Accenture, Gartner, etc… And who were the main beneficiaries of implementations? Given the shortage of good ROI stories on implementations, the primary beneficiaries, that is the beneficiaries we can really prove are the software vendors, Deloitte, IBM, Accenture, Gartner, etc..

Background on Enterprise Risk Management and Performance Management

One of the most interesting results of evaluating the success metrics that are applied to enterprise software projects post go-live is that the only success metrics turn out to be related to hitting project management goals — that is the success metrics are not tied to the actual performance of the system.

“I say “may,” because the research is clear that companies often have no way of validating whether their project was a success because they have no formal measurements in place. The following quotation from research into the project success determination explains this fact – and a fact, which is frequently and easily glossed over when failure statistics are quoted, quite well. “According to Parr and Shanks (2000) “ERP project success simply means bringing the project in on time and on budget.” So, most ERP projects start with a basic management drive to target faster implementation and a more cost-effective project… Summarizing, the project may seem successful if the time/budget constraints have been met, but the system may still be an overall failure or vice versa. So these conventional measures of project success are only partial and possibly misleading measures when taken in isolation (Shenhar and Levy, 1997)” ” Measures of Success in Project Implementing Enterprise Resource Planning

This quotation is only one example – all of the research in the area of success measurement for IT projects points in the same direction.

How Enterprise Risk Management Relates to the Purchase of Major Enterprise Software and Consulting Brands

Because companies do not measure the success of their projects, they will frequently simply purchase software and services from major brands. The logic is the following:

“We purchased software from SAP, and we chose our consulting partner as Accenture – therefore what could go wrong.”

It turns out a lot can go wrong. We add a larger multiple for implementation cost because software, which is implemented by a major consulting company, will in every instance that we have analyzed, cost more and take longer to implement than if no major software company is involved. This is why the implementation durations of best of breed applications is so much faster – they are not brought in by major consulting companies and are no obligated to hand their consulting over to them or to accept the consulting company’s “methodology,” which is not a methodology, but a method, and is centered around maximizing the billing hours that are pulled from the client.

Do Implementing Companies Want their Projects Evaluated for Success?

The research shows that companies don’t perform enterprise risk management and don’t know if their projects are a success. At first blush, the answer might seem to be “absolutely.” However, do the executives actually want to find out? If you are an executive at a company and have made a purchase decision, clearly, you want the project deemed a success. If you actually measure for success, you may find out it is not actually a success in that the system does not provide the quality of output expected, and or it does not improve the company’s condition beyond the system that was replaced. So what do companies do? Well, they essentially measure success based upon whether the project met its implementation deadlines. As stated in the SCM Focus Press book Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making.

“It is in fact quite easy to bring up an application so that it is “live.” All that has to be done is client specific master data setup, integration performed to other systems and a generic configuration used. I refer to this as an IT implementation – the system is working and all the server lights are blinking. Implementing the software in a way that adds significant value is the actual goal not simply hitting a deadline. However, in multiple studies it has been found that companies have no other way of objectively determining project success beyond the meeting of project deadlines.”

Lets us use an analogy that everyone can relate to. If we look at the wars in Iraq and Afghanistan, were they a success? The bill for these wars is estimated to be roughly $6 trillion.

“The decade-long American wars in Afghanistan and Iraq would end up costing as much as $6 trillion, the equivalent of $75,000 for every American household, calculates the prestigious Harvard University’s Kennedy School of Government.

“The Iraq and Afghanistan conflicts, taken together, will be the most expensive wars in US history—totaling somewhere between $4 trillion and $6 trillion. This includes long-term medical care and disability compensation for service members, veterans and families, military replenishment and social and economic costs. The largest portion of that bill is yet to be paid.”- Global Research

There were great sacrifices on the parts of Americans — both in terms of those that funded it, and those that fought in these wars. Let us remove from the equation any innocent Iraqis and Afghanis who were injured or killed and the loss of their national independence — or the final impact of these wars on their future. Rather, let us restrict the analysis of the wars as to whether these wars were a success or failure for the US. How does one determine if these wars were a success?

  1. Is it defeating the militaries of these countries?
  2. Is it the elimination or reduction of terrorism?
  3. Is it the possession of the natural resources of these countries?
  4. Is it the long term political control of these countries?
  5. Is it whether both countries begin to operate as great democracies?

There is a strong tendency to declare the wars a success because of the sacrifice rather than the benefit — however that for obvious reasons can never be a correct measurement. The question that should be asked is not were there sacrifices made — but were the sacrifices worth the cost?

Of the $4 to 6 trillion spent, were there other things that could have been done to help the US meet its objectives? As with IT implementations, the output of initiatives seems quite frequently to be analyzed. It also brings up the question of, if the analysis is performed and the initiative was a poor investment of resources, does anyone want to know?

How Do You Calculate ROI from Software?

While the term ROI and improve ROI are thrown around quite carelessly, the consideration that is missed is how difficult it is to calculate ROI. Brightwork Research & Analysis has the most extensive and automated total cost of ownership or TCO calculators that exist. Yet while TCO is difficult enough to calculate, we don’t even bother calculating and ROI. The ROI uses the TCO estimate as to the starting point, however, how do you actually estimate the return on a software implementation? There are ways to begin going about it, but it simply requires too many assumptions to really do. And that is the interesting feature of ROI. The people that make statements about reduced TCO don’t have any idea how complicated it is to calculate. Prior to creating our online TCO calculators, we read all the work that was previously performed on TCO. What we found is that almost all the entities that calculated TCO had the incentive to underestimate TCO by leaving things out. This is because most TCO calculations are performed by software vendors.

We then created our own TCO method which included far more costs than we had seen in any other estimate. Our method is documented in the book Enterprise Software TCO. However, we know that no software vendor even bothered to estimate an all-inclusive TCO, so how can they possibly say they know the ROI of their software? They simply don’t have any idea.

Conclusion

TCO on ERP is not analyzed outside of academics. Vendors, consulting companies and paid off IT analysts and IT media have conveniently circumvented the question of the TCO and ROI of ERP because it leads to all the wrong answers.

Companies that implement ERP systems have not and are not doing the most elementary research to evaluate the potential benefits of the software they are purchasing. They not only do not research the ROI of the ERP system itself but do not have the knowledge of the ROI of the follow-on applications that the ERP vendors plan to sell to them after they have captured the account.

Decision makers don’t measure benefits, (measurement is tricky), don’t read academic literature, and benefit by doing things that are considered “right” at the time to do. What is considered right to is controlled by the marketing departments of vendors and consulting companies that also control the media landscape? So IoT is being pushed right now. Are there really many use cases for IoT? They exist for package delivery and a few other areas, but IoT use cases are quite overstated. Big Data is similarly overstated. But assertion without evidence is the norm in the IT industry. Loosely translated, the only justifying logic for ERP is that firms that promote ERP propose that ERP is something that should be purchased. That is it. And the firms that recommend ERP, most frequently recommend the most expensive ERP systems to implement.

The Necessity of Fact Checking

We ask a question that anyone working in enterprise software should ask.

Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?

If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.

In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.

Financial Disclosure

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 Problems and Inefficiencies Content

<

References

Shahin, Dezdar. Sulaiman, Ainin. Measures of Success in Project Implementing Enterprise Resource Planning. International Journal of Business Performance Management, Jan 1 2011

Iraq and Afghanistan War Cost

*https://www.globalresearch.ca/us-wars-in-afghanistan-iraq-to-cost-6-trillion/5350789

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

What Are the True Benefits of Two Tiered ERP?

Executive Summary

  • Two-tiered ERP is sold as a highly beneficial strategy.
  • Learn how beneficial two-tiered ERP is to customers that follow this advice.

Introduction

Two-tiered ERP systems are a trend in ERP, but there is little research on the impacts of two-tiered ERP strategies and how they differ from what companies are doing anyway with multiple ERP systems. Once again, the marketing is far ahead of the evidence. Remember that a previous concept—service-oriented architecture (SOA), which has now flamed out with respect to ERP systems—was also supposed to be a “savior” for ERP. I work on projects where ERP is omnipresent, yet after so many SOA books published and so many ERP vendor marketing documents written, SOA has yet to show its face on any of my projects. Major ERP vendors made a lot of noise about supporting SOA, but SOA never fit their business model because it reduces their account control; there was no reason for them to support it. On the other hand, there was a large incentive to say that they supported the concept, as is explained in the following article.

Accept the Marketing Message

So before we go forth and accept a new marketing message (i.e., two-tiered ERP), let’s analyze whether it makes any logical sense. It is not clear how two-tiered ERP is much different from the current practice, where most companies have several instances of ERP. Let’s look at a few quotations that define two-tiered ERP.

“Two-tier ERP software and hardware lets companies run the equivalent of two ERP systems at once: one at the corporate level and one at the division or subsidiary level. With two-tier ERP, the regional distribution, production, or sales centers and service providers continue operating under their own business model—separate from the main company, using their own ERP systems. Since these smaller companies’ processes and workfl ows are not tied to the main company’s processes and workfl ows, they can respond to local business requirements in multiple locations.”Wikipedia

Obviously, companies are already doing this. The real difference is in the acknowledgment that a foundational characteristic—single instance ERP—is giving way to a standard approach of multiple ERP systems, not merely as part of a short-term approach, but as part of a long-term strategy. I would not have guessed that ERP systems had diverged so far from their original intent in this regard, as I tend to work for just one subset of enterprise software that is connected perpetually to ERP systems.

Multi ERP Strategy

The multi-ERP strategy has been around for as long as there have been ERP systems. Yet IT analysts, consulting firms and IT trade periodicals that discuss the new trend of two-tiered ERP strategies, fail to bring up the rather important fact that a big part of the ERP value proposition was supposed to be a single instance of ERP, as explained in the following quote from an article in the Sloan Management Review:

“The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus many companies ended up having several instances of the same ERP system or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.”

How can so many entities actively promote the concept of two-tiered ERP without even mentioning that it is in complete opposition to one of the original value propositions of buying ERP systems in the first place? Simply put, it is ignorance, amnesia, or a desire not to disrupt various forms of funding that they receive from ERP vendors.

The Logic of Cost Reduction for ERP

All of the above factors undermine a primary argument used to sell ERP systems: they reduce costs. After the ERP market had become saturated, the cost reduction logic “declined as a point of emphasis,” because the vendors were now motivated to sell different types of software. I have noticed other previous changes in SAP’s storyline as well. Back in the late 1990s, before they had a supply chain planning system, SAP essentially told companies that supply chain-planning systems were unnecessary. Advanced supply chain planning systems were designed to replace some of the supply chain functionality in SAP R/3. They offered supply chain functionality not available in ERP systems, in addition to more advanced functionality. The argument used by SAP at the time was that this software was only of interest to a very small number of companies. However, after SAP developed their own external supply chain planning system, they changed their message, proposing that it was now quite necessary.

Business Cost Reduction

ERP systems were supposed to save companies money through the standardization of business processes. ERP customers generally accepted this without question. The quotation below provides an example of the pitch.

“It is also one of the most worthwhile initiatives for securing your place in a competitive market. A successful, enterprise-wide implementation will move your company from one with piecemeal business procedures and no overall plan, to a re-engineered organization that is poised to take growth and profi tability to a whole new level.”Why ERP is Vital to Productivity and Profitability

This is an example of a generic argument that proposes that businesses were somehow lost in the wilderness, lacking direction until—POOF! ERP came to save them from themselves. The next quotation is a more sophisticated explanation for what is still a flawed appraisal of the situation.

“Many organizations have several different legacy systems that have developed over the years to meet their information needs for planning and decision making. Often there is little or no integration among departments and applications used by separate departments do not communicate with each other. This means that data has to be entered into each separate department of the organization resulting in data redundancy and at times inaccuracy. ERP systems can virtually eliminate the redundancies that occur from these outdated and separate systems. ERP systems integrate various systems into one and data is entered into the system only once.”What Managers Should Know About ERP and ERP II

It’s hard to fathom why these companies had not already created interfaces between their applications. ERP has not “virtually eliminated the redundancies that occur from separate systems.” We have the same redundancies and the same issues, except we have newer systems. The previous quote seems to have been written by someone who does not spend any time on actual projects, because those who have work experience in this area have come to the opposite conclusion.

Legacy Systems?

As far as systems being outdated, one of the major complaints of ERP clients is that their ERP vendors have stabilized the functionality within their ERP systems and are no longer innovating. This was the same complaint regarding legacy systems and the reasons they were called outdated! Here is another quotation that contains more unexamined assumptions.

“ERP systems are based on a value chain view of the business where functional departments coordinate their work, focus on value-adding activities and eliminate redundancy. ERP can be a valuable tool for managers to improve operational as well as financial performance of the firm.”What Managers Should Know About ERP and ERP II

This sounds great; however, how would the author know this?

A lot of things “could be” but I have searched through all of the research on this topic and there is no evidence of this. In fact, the ROI is so low, that companies have had to change their stories as to why they implemented ERP, often turning to the equally fallacious argument that ERP improved integration in their companies (as highlighted in the quote below).

“ERP systems replace complex and sometimes manual interfaces between different systems with standardized, cross-functional transaction automation.”The Impact of Enterprise Systems on Corporate Performance

I have to ask how current this observation is and whether it still applies, or whether it was ever true. This paper was written in 2005, but interfaces between systems do the same thing that ERP does and have for many years.

Conclusion

This chapter covered the other logics—in addition to best practices and integration benefi ts that were used to sell ERP systems. All of these logics are similar in that they were over simplifi cations of reality, and none of them were ever actually proven true. They were never hypotheses that were formulated to be tested. They were proposals that were designed to help pave the way for software and consulting purchases. The evidence is clear that none of the logics were proven to be correct, and yet there is almost a total blackout of this fact. Academic research shows this, but exceedingly few have addressed the discrepancy between the official storyline on ERP and the research. Instead, the logics presented in this chapter continue to be used in order to sell more software and consulting. This displays a concerning inability of corporate buyers to differentiate between evidence-based statements and marketing propaganda. In the next chapter, we will explain the total cost of ownership of ERP systems—which is directly related to the logic of whether ERP systems reduce costs.

Financial Disclosure

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 Two Tiered ERP Content

References

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

How Accurate are the All Industries Benefits of ERP?

Executive Summary

  • ERP is sold on the ability to be used in any industry.
  • Learn why the proposal that ERP works for any industry is incorrect and what this means for projects.

Introduction

ERP vendors have been adamant that their software can be used for any industry. SAP has many different industry solutions. However, when one examines these advertised capabilities, the actual functionality is often lacking. These SAP industry solutions are really more marketing constructs than usable functionality, and because the marketing is so good, it took me years of working on SAP projects to figure this out. While I have not worked with every industry solution, I have worked with many of them, and none of them have been as advertised. Most of the time the ERP system is implemented without using the functionality of the “industry solution.” It is quite accurate to declare that SAP lies about its industry solutions.

SAP industry solutions are designed to get executives in purchasing companies to think that SAP can meet the unique requirements within their industry, but in truth, SAP tends to offer generic functionality as a base, which they sell to most of their customers. Then they add some functionality for the specific industry, which is of dubious implementation value but serves as the “hook” to make the executive decision-makers think the software has been customized for their needs. I have worked on several SAP implementations for repetitive manufacturing.

The Example of Repetitive Manufacturing

Repetitive manufacturing is a manufacturing environment where the production is continuous and the equipment investments are high, as is the rate of production. Late in one project, it finally came out that the repetitive manufacturing functionality was not worth turning on. As a result the implementing company decided to forgo the functionality and stick with the standard discrete functionality with a few adjustments. SAP got the sale by pitching repetitive functionality down to the eleventh hour. But the company wasted an enormous amount of time discussing whether or not repetitive manufacturing functionality would be used. As a very experienced SAP consultant (from SAP itself) once stated to me,

“There is really more sizzle than steak to SAP repetitive manufacturing.” This issue of “there not being much there”

..is repeated throughout SAP industry solutions.

Among prospects there seems to be some confusion on this topic. Just because a software vendor has a number of customers in a particular industry does not mean that their software serves that market or provides the necessary functionality. But with applications from name-brand vendors, so much of the purchasing decision is based upon the brand yet so much of the ERP system is customized by many clients. Across all industries, one of the greatest unheralded “helpers” is probably Excel. It might be more accurate to say in airport advertisements “XYZ ERP vendor + Excel is used by four out of five top chemical companies.” An honest statement—but obviously not as catchy.

The Example of Discrete Versus Process Manufacturing Requirements

In discrete manufacturing (e.g., automobiles, toys and tools), usually there are multiple input items and a single output item. However, in-process manufacturing, where the final item cannot be broken down and converted back to the original input products (i.e., cheese cannot be disassembled into its original components, but an automobile can), one input item can convert to multiple output items, or multiple-input items can convert to multiple output items. All of these relationships can be easily modeled in a spreadsheet.

The finished product of process manufacturing is not simply the assembly of the input products, but is, in fact, an altogether transformed item.

For example:

  1. One cannot unthread fabric to get to the original spools and restock the thread as inventory.
  2. Once crude oil is cracked into jet fuel, kerosene, tar, etc., it cannot be reconstituted back into crude oil.
  3. In some types of process industry manufacturing, the input product is literally “gone.” For instance, when coal is converted into electrical energy, it cannot be converted back into coal.

So what common and important capabilities are typical of process industry manufacturing? The software vendor TGI, which states the following capabilities within its Enterprise 21 software application, can demonstrate the requirements for process manufacturing planning.

“1. Supports infinite-level formulas with yielding at the top level or ingredient level and rank-ordered ingredient substitutes

2. Products can have global formulas or unique facility-specific formulas

3. Supports scalable batches

4. Supports recipes through the integration of formulas and associated processing instructions and notes for use during batch process production

5. System maintained version and revision control with a fully integrated engineering change order process

6. Formulas support nested formulas and intermediates and can have infi nite notes and instructions

7. Supports online review of formulas via single-level and multi-level explosion

8. Multi-level where-used functionality enables rapid access and mass change to all finished goods using specific ingredients, intermediates, and nested formulas

9. Formulas and recipes are easily duplicated and updated for the same product or a new product

10. Formulas are pulled into work orders or batches for tracking and recording of actual ingredients consumed or backflushed at defined standards”

Batch Functionality in SAP ERP

Batch functionality in SAP can be enabled, which is used for batch process manufacturing. Batch functionality is a very popular requirement for all types of batch manufacturing (including manufacturing such items as bakery items, paint, glass, specialty chemical, and pharmaceuticals, as is explained in the book Process Industry Manufacturing Software: ERP, Planning, Recipe, MES & Process Control). Batch functionality allows specific batches (e.g., a batch of pharmaceuticals from a single production run) to be tracked. Batch manufacturing can be enabled in SAP ERP.

However, batch functionality is well known as a major headache to enable. Batch management was added as an afterthought, even though it is foundational to a batch management ERP system and also a process industry ERP system. SAP ERP was designed to work with discrete manufacturing, which simply has quite different requirements. This is not just an issue with SAP ERP, but of ERP generally, and not just with ERP as a software category, but with all manufacturing enterprise software sold to process industry customers.

This is a topic in the book, Process Industry Manufacturing Software: ERP, Planning, Recipe, MES & Process Control. The following quotations talk about how enterprise software designed for discrete manufacturing customers is sold to process manufacturing companies.

“For IT chiefs like Pam Haney, IT director at Irvine Scientific, a $28 million life sciences company, issues of competitive advantage are overshadowed by ever-present customization needs with her ERP system. ‘What we’re faced with is having to deal with ERP packages that are not designed for process manufacturers.’” — Why ERP Systems are More Important Than Ever, CIO

“Originally business information systems for manufacturing companies were designed for discrete manufacturers, not process industries. These systems targeted industries such as automotive, consumer electronics, machine tools, etc. The discrete manufacturing sector produces piece parts to form subassemblies, which are then combined to form the fi nal product. Nearly all ERP suppliers have built their information systems to support the business functions of discrete manufacturers.”Process Industry ERP Requirements

Very specific requirements exist in process industry manufacturing companies that must be met one way or another.

“Today, process manufacturers have a proliferation of products. These products are produced using the same equipment or using existing processes downstream but at the same site. Because of the number of products now fl owing through the same cost center, using financially based cost systems to develop accurate, individual product costs is difficult, sometimes impossible. Furthermore, as multiple methods evolve for producing the same end item (whether in a sister plant or with newer technologies in an existing plant), the setting of standard costs must reflect a weighted average cost. This type of costing can only be done using an ERP system designed for the process environment.”Process Industry ERP Requirements

Unplanned Customizations

Businesses require solutions that have been designed from the ground up to meet their requirements, not software that attempts to meet their requirements. ERP vendors claim they can address the specific requirements of manufacturers by appealing (successfully) to all industries with slick marketing literature, yet with the barest level of functionality. Right now, thousands of companies have made unplanned customizations to their ERP systems because ERP vendors told them that the software would cover their industry-specific requirements when, in fact, they could not. So much money has flowed into Tier 1 ERP vendors who have provided generic solutions and left promises regarding industry-specific functionality unfulfilled, that money has been prevented from flowing to solutions that could have been developed to offer companies software that meets their requirements. This is another example of a prediction made by many ERP vendors that helped them get sales but has been bad for their “customers” and bad for the enterprise software market overall.

Should You Rely Upon Deloitte (Or Other Major Consulting Firms) for Process Industry ERP?

Deloitte both recommends and staffs primarily SAP and Oracle ERP for its process industry and non-process industry clients. However, these applications, SAP ECC/R/3 or Oracle JD Edwards Enterprise One have quite poor process industry functionality. This is consistent with a long history of the recommendation of software, which is inappropriate for process industries by the major consulting companies. The reason for this is that the major consulting companies have resources trained in specific software and would rather keep implementing this software than have to retrain a portion of its employees to implement process industry specific software. Therefore Deloitte recommends the software that it prefers to implement rather than software, which is the best fit for its clients.

This one size fits all approach is more focused on maximizing Deloitte’s revenues than providing advice of any quality to its clients. The replication of this strategy with other consulting companies is a primary reason that process industries tend to have such customized and high maintenance systems.

Where Can You Find These Applications?

Both SAP and Oracle spend more effort on developing marketing literature which talks about what a good fit their software is for process industries than actually developing specific process industry functionality. A perfect example of this is batch functionality in SAP ECC/R/3 that is extremely difficult to configure and use, but the same functionality is standard in at least one other ERP system. What functionality is required of an ERP system in process industries is explained in the book Process Industry Manufacturing Software: ERP, Planning, Recipe, MES & Process Control.

Understanding Deloitte’s Institutional Structure

However, Deloitte is not working off of any research orientation but is instead steering its clients into purchasing the application that makes Deloitte the most money, and they will come up with any argument necessary in order to achieve this objective, including providing misinformation about the applications they are “recommending.” However, process industry companies don’t have to continue to rely upon this extremely self-serving advice from Deloitte.

Conclusion

The concept of using ERP for any industry with little customization is a sales construct that after decades has proven not to be true. The more customers have bought into this sales pitch, the more unplanned expenses and corrections and customizations were required of the ERP systems that they purchased and implemented. ERP vendors have been lying to a wide variety of industries declaring that they have functionality purpose-built for them that they do not. Consulting companies assist in this lie by telling prospects that whatever is in the sales literature from the ERP vendors they partner with is true.

Financial Disclosure

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 Better Managing ERP Content

References

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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