The Logic of ERP Driven Improved Financial Performance

Executive Summary

  • ERP systems are justified on the basis of improved financial performance.
  • Learn the accuracy of this proposal regarding ROI.

Introduction

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 an 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 fi nancial 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 fi nd a correlation between ERP implementations and the fi nancial performance of companies) contains several fl aws. Some of these fl aws 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 benefi ts, 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 defi ne 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 effi ciently, 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 fi nancial 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 benefi ts 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

Conclusion

Did the information in this article shock you?

When I first began researching these topics, I was also unaware that every one of the proposed rationales for the purchase and implementation of ERP systems would prove to not only be wrong, but spectacularly wrong. I found myself quite surprised that these false predictions had not been reported in some published form. A multitude of entities have misled readers as to the benefi ts of ERP systems. I don’t necessarily assign a nefarious motive to all the people who have written about ERP vendors over the years. Certainly, vendors and software companies write marketing literature and have no interest in the truth. However, many journalists lack research skills and simply repeat what they have heard about ERP. Perhaps readers do not demand more, and if the journalists were to do the research, they might find things that would be unappealing and could cause blowback from their editors and advertisers.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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

The Length of Implementation Times and ERP ROI

Executive Summary

  • ERP systems have very long implementation times.
  • Learn how these implementation times are justified and what it means for ROI.

Introduction

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 at 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 fi nancial 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 fi nancial 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 fi nd 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 fi nd 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 fi ve 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 golive. 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. At Software Decisions, we are currently working on adjusting the risk in TCO calculations, but do not yet have all of the data. Another 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 benefi ts 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.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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 The High TCO and Low ROI of ERP

Executive Summary

  • ERP is sold on the its financial benefits.
  • Learn why ERP systems have a high TCO and 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-todate 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 signifi cantly 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 signifi cant 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 ineffi ciency 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.

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.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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

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 fl amed 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 fi t 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 acknowledgement that a foundational characteristic—single instance ERP—is giving way to a standard approach of multiple ERP systems, not merely as part of a shortterm 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 story line 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 fl awed 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 offi cial 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

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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 Single Instance Benefits of ERP?

Executive Summary

  • ERP is sold on the ability to be used as a single instance.
  • Learn why the proposal that ERP works as a single instance is incorrect and what this means for projects.

Introduction

A primary selling point of ERP was that a company would be able to move to a single instance of their ERP system. This idea continues to be a selling point of vendors such as SAP, even though in most cases only smaller companies actually have single instances of ERP.

“An ‘instance’ refers to the number of discreet versions of ERP software you have in your company. The original vision of ERP was that companies should have a single instance—that is, a single implementation of the software running on a single database— that serves the entire company. It would mean no duplication of information in different departments or in different geographic divisions and thus better integration and information quality across the company. Upgrading the software would also be easier than with multiple customized instances of ERP across the company.”The ABCs of ERP

Historically companies have been unable to move to a single instance of ERP, yet no one questions why, especially since this is presented as such a desirable end state. As the complexity of a company increases with the addition of regions or subsidiaries, the value of having a single instance of an ERP system, with only one database, becomes questionable. Vendors certainly know this, but present a single instance as a desirable option with benefi ts to the customer anyhow. The reasons why companies are unable to move to a single ERP instance are well documented and are not going away; some of the major causes are listed below:

  1. Database Management and Query Efficiency: ERP systems are supposed to be single database systems, which belies their integration. There are issues with reduced efficiencies at higher data volumes, but what is the value of having sales fi gures from different subsidiaries that may have no relationship to each other in the same sales order table? For instance, if a user performs a query for all sales in a quarter, do they mean the sales of subsidiary one or subsidiary two? How do proponents of the single instance ERP system consider the increased complexity of the data in their presentation of this solution?
  2. Which Region/Division/Subsidiary Gets Its Way?: If different regions do business differently, and they must move to a single instance, which region gets the system configured or customized to its requirements? What happens to the productivity of the company that gets its confi guration adjusted for no other reason than the desire to normalize the functionality across the subsidiaries so that the move to a single ERP system can be facilitated? Most often it is the region with the political power (i.e., the region where the headquarters are located), and has absolutely nothing to do with logic or what is best for the business. I have been on several global implementations and I would recommend to any independent contractor who could choose between a global implementation and a regional implementation to choose the latter. Global implementations are exercises in one region enforcing its will upon the other regions. At one client site, the region with the headquarters simply left out functionality that was available in the application when the new application was explained to the other regions. The functionality they left out would have allowed the application to be confi gured differently. They did this to prevent the other region from choosing a confi guration that was different from what they had already decided upon. The region that selected the confi guration assumed that the confi guration was right for everyone seeing as they had selected it. They called this the “Global Template,” which was a convenient way of getting the other regions to do things their way.
  3. Negotiation Leverage: A single ERP system is viewed as a cost savings because more business is aggregated to one vendor. Surely this is a one-sided view on the matter: single sourcing also increases the negotiating leverage of the vendor (why they like it so much). What happens when the ERP vendor knows they have 100 percent of a customer’s ERP business? Well, this is just the starting point for Tier 1 ERP vendors; their eventual goal is to replace all enterprise software used by the company with their other applications, to turn the client’s IT infrastructure into a monoculture, and to staff the IT departments with 100 percent compliant executive decisionmakers. If this sounds vaguely familiar, it is because it is the same desire of every major IT consulting company. When I first got into consulting, my partner at KPMG explained to me that our role was to “penetrate” the client and then “radiate” through them.
  4. What About Functionality?: Looking from 30,000 feet up, it’s easy to state, “If we use one system we can save money.” However, there is another side of the equation: the value that the system provides. When a company moves to a monoculture, having regions/divisions/subsidiaries—the people who actually know the business, reduces the functionality benefi ts—choose their own solutions. This leads to the next point.
  5. How Much Does Customization Increase With a Single Solution?: Proponents of a single instance ERP leave this point out of the analysis, and for good reason. Using a single instance ERP system will mean more customization or, as so many IT proponents prefer, taking a wrecking ball to the business requirements. However, customization translates to real money, both up front and in long-term maintenance, and the costs must be estimated as part of a strategy of moving to a single instance ERP.
  6. What About Flexibility?: Moving toward a single ERP system has negative implications for the flexibility of the company. If the acquisition is eventually sold, what is the cost of breaking the acquisition out from the combined ERP system? Hold on to your hats! Tier 1 ERP vendors are not doing this analysis—or have done the analysis but don’t want their customers to know the truth. Instead they continue to bang the gong of single instance ERP. In truth, that a single ERP system was never a realistic proposition should have been apparent to buyers from the very beginning. It is now well documented that the vast majority of companies do not have a single ERP system, and the reasons are quite well explained.

The following quote is just one of many examples.

“Well, it sounded great on paper, but unfortunately reality bites. The stories started to leak out—multi-million dollar never-ending ERP projects, high profi le ERP project failures, inability to tailor the deployment to local subsidiary needs, and over-tapped local IT resources overwhelmed by a monolithic on-premise ERP deployment. And if a division is run as a profi t-center, these kinds of deployments can quickly paint red all over the P&L.”The Decline of Single Instance ERP

The Use of Multiple ERP Systems

Multiple ERP systems in companies are now the norm, and not just two or three ERP systems as the quotations below explain.

“On average, big companies worldwide are running fi ve SAP instances, while almost four in ten have more than six, according to a study from IT services firm HCL Technologies.”When SAP Sprawl is Cool, ZDNet

“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.”The Trouble with Enterprise Software

According to one IDC survey, 72 percent of respondents were running more than one ERP system. People will say that multiple ERP instances can be consolidated into one, but in most cases that is simply not practical. There are a number of very good reasons as to why a company cannot reasonably be expected to move to a single ERP instance.

“‘A lot of people run multiple instances because of geographic reasons, regulations, or business-sector reasons,’ Illsley said. “If you’ve got part of your business that is outsourced, for example, you’d probably want to run an instance that your outsourcing provider could use and that would be different to the one you would want to keep inside, so that it’s easier to do things like that.”When SAP Sprawl is Cool, ZDNet

Conclusion

So, while some companies have moved to a single instance of ERP, most have not and will not in the future. It is easier for smaller companies to move to a single instance, and more difficult for larger companies, particularly companies with subsidiaries. We are now three decades into the ERP phenomena and only a small portion of single instance ERP systems are in use. So why is it still considered a realistic goal to move to a single instance of ERP? Apparently many Tier 1 ERP software vendors think it is quite reasonable. However many companies are turning a deaf ear to this message and are, in fact, now far more frequently exploring the concept of a two-tiered ERP system.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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

Simply put, many executives buy software to advance their careers, because other companies buy it, or because the marketing and the salesmanship dazzled them. As discussed in the next section, another common division between manufacturing companies, who are the most common implementers of ERP systems, is the division between discrete and process industry manufacturers.

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 fi nal 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 make by many ERP vendors that helped them get sales, but has been bad for their “customers” and bad for the enterprise software market overall.

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.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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 The Overly Integrated Nature of ERP

Executive Summary

  • ERP systems are internally integrated, but it leads to too much internal integration.
  • Learn how this over internal integration damaged ERP customers.

Introduction

The much-promoted internal ERP integration is described universally as a virtue and as a system with no corresponding downside. I do not exaggerate when I say that I could not find anything published about the disadvantages of ERP being self-integrated. However, systems that are so integrated limit a company’s flexibility to meet its requirements, although at fi rst it can be difficult to see how this is the case. When a system external to the ERP system makes a decision, that decision/output must be converted so that the receiving system can understand and use the transaction. A transaction can have multiple dimensions (a payment processed between two locations/entities, a shipment sent between two entities, etc.). The problem is that ERP systems offer a limited number of options per dimension (as with most systems; however with ERP systems there is a catch), and when the company has a requirement that cannot be met by a transaction that exists in the ERP system, customization must be performed.

Customization rarely works smoothly and becomes something that the company must maintain in the long term. Customization of ERP systems is one of the most expensive customizations a company will ever pay for, as it means hiring programmers at the top of the market and developing from within the ERP software vendor’s environment. This is explained in the following quotation.

“’We could have written ABAP code, but the cost of ABAP programming and maintenance is enormous,’ says Bill Waters, MMS’s director of information services. With Oberon, MMS saved the initial programming effort and will save even more whenever it upgrades its packaged apps. Oberon provides prebuilt connectors between the two systems and is committed to maintaining and enhancing these links so MMS doesn’t have to.”

The Efficiency of Customizing ERP Applications

ERP applications are not known as efficient applications to customize.

“The problem is the lack of a full set of application development tools in ERP packages. Major ERP vendors may publish APIs, include a low-level programming language, reveal their underlying data schema, and even provide some customization tools. But they don’t usually provide testing and debugging—or much of the other functionality developers expect.”ERP: More than an Application

Customization is a near universal requirement for ERP systems. According to IDC, 87 percent of respondents to their survey performed moderate to extensive customizations in their ERP system, and estimates from other sources move that figure up to 96 percent.

“During the past two years, Data Exchange has invested several million dollars in its systems overhaul. A good portion of that money went toward custom coding. ‘Each business is unique,’ Malchicoff says. ‘We did a gap analysis of what Oracle could do and what we needed to do for our business.’ The company wrote nineteen modules comprising fifty thousand lines of code for such things as logistics, process control, and data mining. That effort was just as significant as deploying the ERP software—and it cost just as much, an amount Malchicoff had to calculate as part of his ROI analysis.”Making ERP Add Up

How Many Releases Behind the Latests Version

More than a third of small to mid-sized manufacturers that use on-premises ERP operate between two and three releases behind the most up-to-date version of their ERP system. Furthermore, because the modules within the ERP system are so tightly integrated, there is no easy way around the module in order to connect directly into the ERP’s financial system. The reason for this is clear: if we use ERP’s inventory system as an example, the inventory system must have the full information on all inventory movements, even if there is no standard way for the ERP’s inventory module to process the movement.

While many articles describe ERP systems as inflexible, they miss out on the distinction that I just explained: part of this infl exibility is due to the overintegration of ERP systems. In one article that followed the “ERP is inflexible theme,” the IT analyst firm IDC did an excellent job of elaborating on one aspect of ERP inflexibility:

“ERP systems in general are not designed to be flexible; in fact, most are designed to provide and automate repeatable business processes. While there is substantial benefit to this automation and predictability, there are also risks and costs.”

Inflexibility of Umbrella Term for ERP Shortcomings

“Inflexibility” is used as an umbrella term for many ERP shortcomings, but “over integration” is the term I use to explain the specific problem that results in infl exibility. ERP systems cannot represent all the different business processes that exist in a system, and its introverted design limits a company’s ability to implement these business processes without considerable and expensive customization. In fact, one of the reasons that ERP vendors and consulting companies make so much mention of best practices is because ERP’s coverage of business processes is restricted, making it necessary for ERP vendors to have a readymade argument to use to convince the company not to implement its preferred—and in many cases valuable—business process, and to accept a substitute that requires the company to make all the adjustments. How ERP Sets the Integration Agenda for All Other Applications If you check out the websites of non-ERP vendors, you will fi nd them littered with various certifi ed (by the ERP vendor) integration adapters. (Most of these certified adapters are more marketing sizzle than reality as described in What Are SAP’s Vendor Integration Certifications.)

Integrate Applications of ERP Vendors

It is crucial for non-ERP vendors to show their ability to integrate with the applications of ERP vendors. During the presale presentation to the customer, they often pay homage to the customer’s existing ERP system (particularly to SAP and Oracle because of their popularity in the market) by talking about the great relationship they have with that ERP vendor, and if possible, by discussing the details of as many joint implementations as possible. I have been critical of software vendors in the inventory optimization space who dilute their own message by stating in their marketing literature that they “work with” ERP vendor functionality, rather than replace ERP functionality. These vendors have sophisticated solutions with functionality that is head and shoulders above what can be found in ERP systems. Yet, because they are concerned about offending the ERP vendor, they are as non-confrontational as possible, even to the point of misrepresenting what their applications actually do. For instance, when they refer to SAP on their websites, they could not be more deferential, as I explain in the following article How to Understand Why Software Vendors are Fear SAP.

Conclusion

This is the power that many ERP systems have. Other vendors are fearful of contesting the ERP system directly or showing how their systems are superior. That is, the other vendors self-censor. These are not the workings of a transparent market; the power and veto authority of the ERP software vendors influence the information provided by other vendors that do not even sell ERP software.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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 The Fake Integration Benefits for ERP

Executive Summary

  • ERP systems were sold on the basis of reduced integration costs.
  • Learn how the ERP systems increased most integration costs.

Introduction

Enhanced integration was one of the major selling points of ERP. The hours of PowerPoint presentations that have been created since the first ERP systems were sold describe the great cost savings and integrative benefits that implementing companies would receive from a “solution” where all the main applications used the same database. One of the assumptions about purchasing an ERP system was that the buying company would implement all of the modules and decommission their current software. I discussed this briefly in a previous section. This oversimplified assumption was self-serving for the concept’s promoters, but not considerate of the buyer’s needs. The fact is, some of the company’s pre-existing applications could not be replaced by ERP, and for a variety of very good reasons.

Here are two of the common scenarios in which companies that implemented ERP found themselves:

Scenario 1: When Companies Replaced All Pre-Existing Systems with ERP

In rare cases, companies eventually replaced every one of their existing systems with ERP, representing a perfect match with what the ERP salespeople proposed.

  1. Some companies that followed this approach paid far more than they had anticipated customizing the ERP application to replicate part of their current solutions.
  2. Some companies that followed this approach lost functionality and wished they had not gone 100 percent ERP, but could not go back once they had completed the switch.
  3. In some cases they removed all existing systems and replaced them with ERP, and were happy with both the cost and the functionality that resulted from doing this.

Scenario 2: When Companies Replaced Some of the Pre-Existing Systems with ERP

In most cases companies did not implement all of the modules that they had purchased.

  • General estimates are that an average of 60 percent of the modules were implemented and 40 percent were unimplemented.
  • Other times, companies implemented all the modules but were unable to decommission pre-existing applications because those applications did something of value for the company and it would have required too much work to customize their new ERP system.

Advantages of ERP Integration?

Contrary to most assumptions, ERP systems provide no advantages in terms of integration to other systems, and in fact present several disadvantages:

  1. No Integration Advantage: ERP systems were not designed to integrate well with any other system, with the exception of electronic data interchange (EDI). ERP vendors proposed that their systems integrated better with the other applications that they offered for sale. However, this contention is also of a dubious nature. Many applications sold by ERP vendors (Oracle being a good example) resulted from acquisitions. These applications have different heritages than the vendor’s ERP system. Oracle created adapters for these disparate applications, but their value is questionable.
  2. Low Quality and Uncompetitive Middleware: Even when the non-ERP vendor applications were developed internally (such as with SAP), the applications did not integrate very well. I have many years of experience integrating external planning systems to SAP, and contrary to what ERP vendors say, not as many of these applications integrate to the ERP system as what is led to believe. Part of the reason for this is that ERP vendors are not necessarily good at creating middleware (the software that connects other software). In fact some (such as SAP) are not at all skilled in creating integration applications of any type; they seriously lag behind the best vendors in the middleware software category. Therefore, the customer ends up purchasing middleware by default from a company that is uncompetitive in that software category. I discuss this in the following articles that I wrote to inform companies that they were greatly underestimating the short-term and long-term effort involved to maintain the SAP ERP to SAP APO integration application called the “core interface” (CIF). The CIF is an SAP-to-SAP interface, but while it can be brought up quickly, is so maintenance-intensive that over the long term, I debate whether it is better to develop an adapter from scratch in Why I No Longer Recommend Using the CIF.

ERP companies normally entirely exaggerate how much integration their systems provide. The following is a good example of this.

“As companies buy Oracle ERP Cloud, Oracle is seeing more companies attach other Oracle services, such as human capital management. Companies don’t have to buy Oracle HCM Cloud and Oracle Sales Cloud, since Oracle ERP Cloud integrates with cloud and on-premises applications from other providers. But companies see advantages in buying cloud applications from the same provider because those apps are designed to work together, eliminating the integration work that’s often required to weave together cloud services from different providers.” Oracle

This is a complete lie on the part of Oracle, but it is the type of lie frequently told to customers.

The Unfortunate History of ERP “Integration”

Here is a much more effective solution than I have described above: ERP vendors should never have been allowed to procure other vendors. They should not have created external applications, and instead should have published an integration standard and allowed the middleware vendors (those that were actually skilled at creating middleware) to create the adapters. ERP companies had no interest in this solution. Instead they intended to use their position at their customers to sell in more software. Often this software was poorly integrated and uncompetitive with best-of-breed applications (outside of just the ERP system). In this way, the ERP companies put their own interests ahead of their customers’ interests, as explained in the quotation below.

“Of course, as soon as companies began buying these products, it became clear that enterprise software was another chunk—a much larger and better integrated chunk to be sure, but still a chunk—of software in a complex architecture of IT systems that desperately needed to talk to one another and exchange information. The vendors created clunky, proprietary methods of connecting their systems with others that have improved over the years, but that misses the point. The architecture of these systems, in a broad sense, was just like the ones that they were intended to save you from monolithic, highly integrated and difficult to change.“The high degree of integration envisioned in the R&D lab was tenuous at best inside most customers.”CIO

The Increased Need for Integration

ERP systems integrated some areas of functionality used by the company, but certainly not all things. And again, because most companies have so many applications, there is still a lot of integration work that needs to be done. A 2001 study found that ERP increased the need for integration.

“ERP technology does not offer an integrated solution but amplifies the need for integration.”ERP and Application Integration

ERP as a single architecture.

“Although ERP is touted as a single architecture, ERP applications usually contain different generations and sources of technology. Third-party applications are acquired and amalgamated into the platform, sometimes by name only. In total, this makes the environment complex for the customer and diffi cult to change over time. ERP suppliers have become system integrators. [emphasis added] The sheer size and number of applications makes moving all the applications forward a diffi cult task. Application functionality often lags.”ERP Alternatives

Short Term or Long Term Benefit?

In terms of ERP’s impact on application integration, companies did not see any immediate benefit. But was there a longer-term benefit? Unfortunately after extensive searching I was unable to find research data that compared what portion of the IT budget was consumed by application integration before and after ERP implementations. The shortage of research on this topic is particularly galling when one considers how confidently those who sold ERP systems predicted that integration costs would decline. However, findings in the study ERP and Application Integration are not promising.

“ERP technology does not offer an integrated solution but it amplifies the need for integration. Enterprises faced integration problems when they attempted to incorporate other applications with an ERP system. Only EDI applications were integrated successfully (81 percent) with ERP infrastructure. This high integration rate derives from the fact that EDI technology follows similar concepts to AI (application integration).”ERP and Application Integration

This shocking quotation states that ERP “amplifies the need for integration.”

But wait, how can that be the case?

It is because ERP applications are self-integrated, the problems that ERP systems have with interfacing with other systems is actually higher than the benefits derived from ERP’s self-integration. That is yet another amazing statement.

The quotation goes on to say as much.

“All observations discussed above indicate that ERP systems cannot be seen as a reliable solution to integration problems as ERP modules co-exist with other applications. Additionally, there is a need to integrate the ERP solutions with other applications. However, this incorporation causes serious problems, especially with companies.”ERP and Application Integration

ERP may have been a step forward for the integration of the ERP modules, but they were a major step backward for all other forms of integration. However, the only important measurement is total integration—not how much the integration effort was reduced for one application. It is important to consider that no study demonstrates that ERP systems reduce integration costs, and at least one study demonstrates that ERP increases integration costs. This exact statement may be used the next time you hear a person promote the integration benefits of ERP systems: ask him/her to produce the study that demonstrates this “well-known fact.”

Project Experiences with SAP ERP

My personal experience with SAP ERP is that it is an extremely difficult system to write interfaces for, but this level of difficulty varies for each ERP vendor. SAP does not even export data in rows and columns but instead uses something called an intermediate document or IDOC. This is a hierarchical document, which is difficult to read, and time consuming to write transformation scripts for which will convert the document into rows and columns. Unfortunately IDOCs also change between versions of SAP, and a single movement of a character by one place can render the integration unusable and require a script rewrite. However, when these IDOCs will be changes is not communicated by SAP—so you find out when something breaks. Generally, others who work in SAP ERP integration tend to agree that SAP is difficult to integrate to, although they will not go on record as saying so; if one wants to continue to work in an area, it’s better, of course, to keep silent. I did not perform an analysis of all ERP systems to determine integration difficulty. I found it far easier to integrate to some of the lighter open-source ERP systems, but it is no coincidence that these applications were developed more recently than Tier 1 ERP applications.

Although there are too few studies upon which to base any definitive conclusion, it is equally possible that ERP systems increased the integration costs that were incurred by companies. But either way (whether it is a wash, or whether ERP increases integration costs), the story does not have a positive outcome. That they most likely did not reduce their integration costs (and quite possibly increased their integration costs) would be quite surprising to companies that gave up so much for the promise of an integrated system.

ERP and the Internet

There are few people (with the natural exception of ERP vendors themselves) who will debate the notion that ERP systems are walled off from the Internet. Since ERP developed, the Internet has become an important force, and web front-ends have greatly improved application interfaces and the ability to connect various applications. This point is reinforced by a 2007 article in the MIT Sloan Management Review.

“Just as companies were undertaking multiyear ERP implementations, the Internet was evolving into a major force, changing the way companies transacted business with their customers, suppliers and partners.”

Here’s a concrete example of how far integration has come since ERP first became popular. I recently installed an application called Yesware off of the Internet. Yesware automatically integrates with my Gmail to track emails, and also integrates with a variety of CRM applications; this is integration across Internet servers by different companies that have decided to cooperate. These are two applications that are communicating over the Internet to one another—each performing a different function—and each aware of what the other is doing. All of these adapters are created for me, and all of them work transparently.

My integration effort was limited to clicking a button to install Yesware, and rebooting my email client. This is clearly the future of application integration across the Internet. Of course, none of this capability existed when the concept of ERP was developed. In stark contrast, most ERP software—and particularly on-premises ERP software—still sits with dated application interfaces and manually intensive ways of interacting with other systems. Getting most ERP systems to do what I did with Yesware, Gmail and a CRM application would be a major initiative at a company and cost quite a lot of money. This point is brought up in the following quotation:

“As the web increasingly becomes the medium for information exchange, your on-premises ERP is increasingly a disconnected silo from the rest of the world.”Craig Sullivan, NetSuite

Rootstock, which covers much of the functionality of an ERP system, does in fact work in a similar way, as it is part of the Salesforce.com platform. But Rootstock is more of an exception, most ERP systems do not work this way.

Errors in the Platitudes Regarding ERP Integration

Executive decision-makers, and also researchers, have some general misunderstandings about the state of integration. The following is an example.

“Information integration is a key benefit of ES. This integration can replace functionally oriented and often poorly connected legacy software, resulting in savings in infrastructure support costs. Furthermore, improvements in operational integration enabled by ES can affect the entire organization and therefore can positively impact fi rm performance. As discussed below, ERP systems also provide benefi ts in the area of transaction automation, SCM systems provide more sophisticated planning capabilities, and CRM systems facilitate customer relationship management.”The Impact of Enterprise Systems on Corporate Performance

This and other similar quotes confuse functionality with the system that brings that functionality, in much the same manner as those who confuse an economic system with a particular form of production. For instance, one who says that industrial capitalism is good because “people bake bread for profit” misses the fact that bread has been baked and sold for thousands of years before the existence of industrial capitalism. Such logic intends to prove that the desired output—the bread in this case—is best accomplished within an industrial capital system versus some alternative system.

Analyzing Quotations

Let’s parse this quotation in order to analyze it properly because there are a number of assumptions contained within:

  1. New software can replace poorly connected legacy software: It’s unclear why the legacy systems were so poorly connected in the first place, as was suggested by ERP salesmen during the early stages of ERP’s popularity. All enterprise software faces these integration challenges. Notice the researchers in this quote are using “ES” not “ERP,” as they propose that all enterprise software has advantages in integration over legacy systems. However, no evidence is given as to why this is true. Systems must be made to work with other systems. An ERP system is more integrated to itself, but as I have explained earlier, that is not the end of the story. Furthermore, enterprise software infrastructure costs have not declined due to ERP being implemented. Some vendors do allow their applications to be integrated easily to other systems that are not their own. However, SAP and Oracle do not promote ease of integration to systems from other vendors. Instead they sell closed systems to companies, getting them to buy into the SAP or Oracle ecology. Even if one vendor provides multiple systems, the systems will not share the same database, and many of the adapters that are offered are of questionable value.
  2. ERP systems also provide benefits in the area of transaction automation: This may have been a differentiator when ERP was fi rst introduced, but now less expensive applications like RootStock or ERPNext can automate transactions as well as any Tier 1 or 2 ERP system. There is no reason to give up so much leverage and pay such a high price for automation that can be found in applications from software vendors that are far easier to deal with.

“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

This paper was written in 2005, but manual interfaces between systems were replaced a long time ago. There is standardized cross-functional transaction automation, but that is only within the ERP application and not between the ERP application and the many different systems with which it must interact.

“Another benefi t of ERP systems is that all enterprise data is collected once during the initial transaction, stored centrally, and updated in real time. This ensures that all levels of planning are based on the same data and that the resulting plans realistically reflect the prevailing operating conditions of the fi rm. For example, a single, centrally developed forecast ensures that operational processes remain synchronized and allows the firm to provide consistent order information to customers (Bancroft et al. [1998]).” The Impact of Enterprise Systems on Corporate Performance

Unless the company uses an ERP system only (and no other systems), the example above is inaccurate. On projects I have spent quite a lot of time working on how the supply chain planning system will pull data from the ERP system and on how the planning recommendations will be sent back. Data pulls from the ERP system for reporting or business intelligence must also be timed, and this is not a real-time feed. These are just two examples, but all systems that are connected to ERP face the same questions and limitations. The only thing that is true about the above quotation is that the ERP system has updated transactions (stock transfers, purchase orders, financial transactions), but this functionality is generic.

Conclusion

ERP vendors continually propose false information on the integration benefits from ERP. The integration benefits never turned out to be true, but they remain mostly unquestioned because of the army of ERP vendors, consultants and industry paid IT analysts that provide the bulk of information about ERP to customers.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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 SAP Uses Best Practices to Control the Implementation

Executive Summary

  • SAP uses the false assumptions of best practices to control accounts.
  • Best practices assumptions damage the project from beginning to end.

Introduction

SAP lists best practices in several areas on its website. I have included the following screenshot of best practices from this web page.

Here, SAP claims that because they are so big, all best practices are included in their software. Secondly, they propose that customers who use best practices have been able to reduce consulting costs by 50 percent and reduce mistakes.

But, wait one second; aren’t best practices simply inherent within SAP? Does one have to choose between a best practice implementation and a non-best practice implementation? What constitutes a best practice implementation? This is all extremely confusing, as well as logically inconsistent.

SAP’s Confusion on the Topic of Best Practices

It brings up the question “what exactly are best practices in SAP?” Here is another quotation on the topic of best practices.

“SAP Best Practices Based Upon Netweaver—SAP Best Practices provide a toolset that helps IT and functional project team members to quickly deploy functionality in SAP solutions—from SAPNetWeaver, to core SAP applications. The toolset comprises a mix of step-by-step instructions, preconfi guration, sample master data, code samples (where applicable) and end-user training—organized by technical or business scenarios that you might want to implement in your landscape. Below you will find the SAP Best Practice versions that support the implementation of SAP NetWeaver components.” — SAP

In this quotation, SAP classifies best practices as a toolset or accelerator made up of instructions, pre-confi guration and sample master data. But let’s back up a few steps here and take just one example. What do best practices have to do with the master data samples? Best practices are supposed to be business process functionality that is in the system naturally. Master data should be kept up to date and validated with the business, which I suppose could be said to be a best practice; this is not something you can bake into the application unless you mean to make the software transparent and easy to use. In that case you are enabling a best practice; you are not modeling a best practice yourself. Overall, SAP’s best practice seems more like a jumpstart toolkit that contains a combination of things that are best practices. The paragraph goes on to say that there is a NetWeaver component to best practices.

How can this be?

NetWeaver is comprised of the infrastructure components of SAP, so what do these have to do with business process functionality best practices? I suppose one could say that their infrastructure follows best practices, with the business, software, toolkits and infrastructure software all based upon best practices. SAP hammers away at this theme throughout their documentation, but because they apply it to everything they do, it begins to sound like unsupported conjecture— and that is the best-case scenario.

Confusion on Best Practices by SAP

The worst-case scenario is that SAP employs marketers who can’t keep their story straight and have limited English and logic foundations. Also one questions how serious SAP is about their NetWeaver best practices because, when I reviewed this material, all of their links to supporting content on the web page were broken.

The answer to these questions?

SAP just does not know; they are confused themselves as to how to use the term “best practices.” SAP simply smears the term, like cream cheese on a bagel, on almost everything they do. With SAP, simply calling standard SAP documentation a “best practice” will somehow (magically) allow projects to go live much more quickly. In this case a best practice is an incantation. It’s difficult to take a vendor seriously when they are so undisciplined as to the use of their terminology. SAP fi nishes off the proposal by declaring that best practices enable SAP implementations to go live in 4.2 months. This is not true; in all my years working with SAP I have never seen any SAP module go live in 4.2 months. This is another problem with credibility: SAP implementations are measured in years—not months—and anyone who works in SAP knows this. So where is this number coming from, and what module is SAP talking about? Where is the evidence for this? No evidence is ever presented.

The Negative Effect of Best Practice Claims on Projects

If only best practice claims ended when the software was sold, that would be one thing; however, the conversations regarding best practices pass from sales to the consultants who are supposed to make good on these claims during the implementation. When you repeatedly tell a customer that they will get best practices in every dimension if they buy your software, unfortunately they don’t forget this. As with any promise that can’t be fulfilled, SAP consultants are put in a diffi cult position. I would know—I have been one of these consultants. On many of my projects, the term “best practice” becomes a punch line. The individuals in the implementing company come to realize that there is no such thing as best practices. Jokes such as, “But wait…it’s okay because it has best practices,” or, “All we need on this project is just more best practices!” are quite common. Because the marketing and salespeople don’t actually work on projects or with software, they do not know this. After realizing that they had been bamboozled by SAP Sales (accompanied by a healthy dose of cynicism about best practices), I heard senior members of my client declare, “We don’t want to hear anything more about best practices.” In the implementation phase, best practices lose all credibility.

Non-ERP Uses of the Term “Best Practices”

SAP is certainly not the only company that uses the term “best practices” as a marketing construct for the purposes of business development. Consultants from large consulting fi rms also like to use the term, and use it in a way that is almost always misleading. I once worked with a consultant who created a custom adjustment for a safety stock problem in a way that was completely inadvisable: I would consider it to be a worst practice. He then proposed that weekly delivery frequency was best practice. He essentially suggested that any technique that he wanted to employ was a best practice. On this project, I learned that twice-a-week delivery was a best practice; who knew that how frequently a product is delivered could be a best practice? It isn’t. Consulting companies are constantly using the term “best practices” to sell work. However, as with best practice claims made by ERP vendors, no evidence exists that what the consultants promote as a best practice is, in fact, that and this is because they have no evidence; it’s an opinion. It’s one thing to say that this or that is one’s opinion from experience. But it’s something else to gusset up this opinion as a best practice—with zero evidence—simply because one would like to have their opinion carry more weight. It is also common to hear from the client that the consulting company did not seem to offer best practices once they were on the project. The reason is simple enough: once one gets into the details of the actual recommendation, they look a whole lot less like “best practices” than they did from a distance.

Criticizing Pre-existing Systems

Best practices have been very useful to ERP vendors as a way of giving them permission to criticize a potential customer’s pre-existing systems. Sales and marketing is about changing perceptions to encourage a purchasing decision. One way of doing this is to increase the purported virtues of the item to be purchased (in this case, the ERP system). Another way is to lower the perceived value of the customer’s current item. Using the term “legacy” to describe all previous systems, and the term “best practices” to describe ERP systems, is highly effective and an impressive feat of rhetoric because it ignores the important fact that the legacy system had been customized for the business requirements, while the ERP system had not. Essentially ERP vendors appealed to a central concept: how things are done in other organizations must be better than how things are done in the potential customer’s company. This is a reversal of the “not invented here,” philosophy which proposes, “anything not invented here.” This is explained in the following quotation:

“ ‘Don’t assume newer is necessarily better,’ advised Project Manager Ellen Harmon of the Washington State Community and Technical Colleges Center for Information Services. Harmon considers her existing legacy system to be just another, older ERP. ‘We actually have an ERP that has been developed over the last 18 to 20 years for specifi c clients, and because of that, this ERP is very focused on these particular client needs.’ The case is the same at other universities.‘Their legacy systems have been developed to meet their specific needs and are tailored to their environment,’ said Harmon. ‘An ERP vendor might say your system is old, and therefore is bad, and we will sell you this new system. But it is a legacy system, too.’ ” — Promise of ERP System

This quotation brings up an interesting question: what is the defi nition of “legacy”? An ERP vendor may be selling a system that has an older code base than the “legacy” system it is replacing. Interestingly, the designs of many of the ERP applications sold today are extremely dated, and yet they are never referred to as “legacy.” To a software salesman, other people’s systems are legacy, but your systems are never legacy. One might ask why this is the case. The reason is not hard to determine. “Legacy” is a term of propaganda that is applied to systems that the designator would prefer to denigrate as a pretext for proposing another system. If you work in ERP Sales, then all pre-existing systems in the companies to which you would like to sell your ERP software are legacy. The ERP system you are selling—no matter how dated—is never referred to as legacy. Therefore the term “legacy” has two meanings: the actual definition (“an old method, technology, computer system or application program”) and the real meaning—any system that you would like to replace. However, many decision makers missed an important detail of infrastructure technology management, as explained in the following quotation:

“IT analysts estimate that the cost to replace business logic is about fi ve times that of reuse, and that’s not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits—they always have, and they always will. New software may increase the risk of system failures and security breaches.” — Wikipedia

Many companies relearned this fact about computer systems. Many of the cost overruns of ERP systems were related to replacing business logic.

Conclusion

Best practices have been a deep well that ERP vendors have repeatedly drawn from in order to support multiple objectives. ERP vendors do not attempt to hire professional researchers to validate their claims regarding best practices because a) most of what they are proposing is simply how their software works—and is not a best practice, and b) customers generally don’t question the best practice claims made by ERP vendors. Generally all that is needed to convince companies that a software vendor has best practices is if the software vendor has marketing documentation that declares the existence of best practices, and if that software vendor is generally successful selling its software and has signifi cant brand recognition.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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 The Best Practice Logic for ERP

Executive Summary

  • ERP systems are frequently sold on the claim of best practices.
  • ERP customers usually do not realize that best practices don’t exist.

Introduction

Many of the arguments that are habitually made in favor of ERP are, in fact, nothing more than logical fallacies, and because of this it is important to review briefly the definition of “logical fallacies.” Proponents of ERP use a number of logical fallacies in the quotations used throughout this book, and when they occur, I will be referring to these proponents by their official names. In fact, it is quite surprising how many of the quotations from ERP proponents fall into one or more categories of logical fallacy, and realizing this led me to read a book specifically on logical fallacies in order to make sure I was able to identify all of them properly. When a topic leads one to actually There are some interesting questions that should be asked whenever any software vendor makes a statement about best practices:

  1. Who decided something is a best practice?
  2. Was the best practice put to a vote?
  3. Was it deemed to be so by an expert?

If item three is affirmative, where is the research to support the notion that a way of doing something is a best practice? What a person who asks these types of inflammatory questions (yes, simply asking for evidence is considered infl ammatory with regard to best practices) will find is that in the vast majority of cases, the practice is a “best practice” simply because the proposer declares it to be so. There is no research and no explanation as to how it was determined to be a best practice. Furthermore, if two different ERP systems—both of which are based upon best practices—diverge in some way on how to do things, which one is actually performing the best practice? Best practices sound suspiciously like something that one is asked to take on faith— and they are. Eugene Bardach, a professor of public policy, analyzed claims of best practices in his fi eld and found that best practices are not based upon research.

“Appearances can be very deceiving. On closer inspection, it often turns out that the supposedly ‘good’ practice is not solving the problem at all. Inadequate measurement plus someone’s rose-colored glasses were simply producing the illusion of mitigating the problem. It may also turn out that, even if good effects have truly occurred, the allegedly ‘good’ practice had little or nothing to do with producing them.”

The further one gets from actual implementation, and the less experience one has with working with software, the more likely one is to believe that software can encapsulate best practices. Because the term “best practices” is so general, it does read a book on the topic of dishonest argumentation, this is a good indicator that something is wrong with the information that is being researched.

The Car Versus Truck Best Practice Example

Let’s take the example of two automobiles: one sedan and one truck. I currently own a Honda Accord, but have been thinking of buying a four-wheel drive Toyota Tundra. These are two very different automobiles built for different purposes. Both score very well in reliability, which I consider a best practice; that is, I prefer high quality cars that require infrequent repairs. However, could the fact that they both use an internal combustion engine and pneumatic tires be considered best practices? These are two of the most important inventions in human history, so I suppose I would not object to calling them best practices. But on the other hand, every car I look at offers the same thing, so while they are best practices, they are not differentiators. Am I interested in comparing best practices that are not differentiators? I would say probably not. The Toyota has four wheel drive, which can be a best practice if you intend to take the car off road, but is an unnecessary and extravagant option if one does not intend to use the vehicle in this manner. Four wheel drive decreases gas mileage after all, and the knobby tires required to go off-road, ride roughly on a paved road. So should I sell my Honda and buy the Toyota? Well, there are a number of factors, such as how much I will be using the vehicle for commuting versus taking my jet ski to the lake and going camping. The vehicle’s benefits to me change depending upon the situation. There are some best practices, such as reliability, that are important to me, but may be less important to other people. For instance, neither of these are particularly stylish. However, the Land Rover is very stylish and has the best practice of four-wheel drive. If anyone has ever sat inside of a Land Rover with a leather interior, I think we can agree that their interiors are a best practice (that is, they feel very nice). In order to get the stylish ride, one has to pay a great deal more, and give up the Japanese reliability for English reliability.

So how do I decide on my vehicle with all these competing best practices?

I hope I have shown that there is a reason that people don’t take the concept of best practices to buying an automobile, or really to any other purchasing decision, and this is because the concept is ridiculous. People look for a series of trade offs in characteristics until they find a desirable compromise, and then make their purchase decision. It does not happen now, and will not happen in the future, that your friend will announce that he based his new car purchasing decision on best practices.

Best Practices in Which Software?

I used the example of cars because most everyone has at some point made a decision to purchase a car and because cars are relatively easy to understand. However, the concept of best practices is equally unhelpful and even problematic in making distinctions between things that we do not know as well. As my expertise is supply chain software, I know that making supply chain software decisions based upon best practices does not make any sense. This is elementary for me, because I have spent more than a decade and a half analyzing and configuring supply chain software and work with it almost every day. However, because I don’t know much about accounting software, if someone were to propose that accounting software can be purchased based upon best practices, it would seem to me to be a tenable statement, but only because I do not have the content expertise to truly analyze the claim. Certainly there are things that are desirable in accounting software that could be deemed “best practices.” For instance, it is desirable that the program post the actual quantities entered into the database, rather than using a random number generator. It is desirable that the program not crash and delete the last five hundred accounting entries. However, once we get past the rather banal areas of functionality, there will be considerable debate as to what are best practices.

Conclusion

The fact that the concept of best practices was such an effective marketing ploy is yet another indicator that many of the executives that analyzed ERP software sales pitches did not have suffi cient experience with the software they were purchasing to know that software couldn’t be purchased using best practices as a measure. Now that I have covered best practices generally, I will provide specifi c examples of how best practices have been used to sell ERP, and what the results were. To some degree, all the ERP companies used best practices to sell their software. I happen to focus on how SAP uses the term because I have spent so much time over the years reading their literature.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

ERP Contact Form

  • Want Honest Information about ERP?

    It is difficult for most companies to make improvements in ERP without outside advice. And it is close to impossible to get honest ERP advice from large consulting companies. We offer remote unbiased multi-dimension ERP support.

    This article is free, we do not answer questions for free. Filling out this form is for those that have a budget. If that describes you, just fill out the form below and we'll be in touch asap.

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