How to Understand Overmapping Functionality to ERP

What This Article Covers

  • Proposals on ERP
  • Oracle and the US Air Force
  • The Real Story on Mapping Functionality to ERP

Introduction

It is often assumed that the more applications that are not-ERP, the more the overall solution will cost. There is no evidence for this, and the cost outcome greatly depends up many factors. It is an attractive illusion that a high degree of the overall functionality required by a company can be obtained from one system. However, the evidence is that even in the largest and most complete ERP systems, such as SAP R/3/ECC/Business All in One, this is never the case.

Proposals on ERP

Consulting companies and ERP vendors that have promised customers that the ERP system would “wipe out” all legacy systems have been successful in convincing companies to buy their software using this idea, but no software vendor has been successful making this statement come true.

The Truth About ERP Systems

ERP systems are designed for companies that make things. That is the “sweet spot.” But when we say make things I don’t refer to what are called projects. So ships, planes, construction — that is large complex items that are few in number. For example, SAP has a module called Project Systems. This allows you to track projects, but it’s not ERP’s “sweet spot.” ERP vendors are very influential, so they tend to over-apply how their software applies to different industries. That is why normally it makes sense to only used a limited part of ERP, or combine a financial product with a construction-specific product.

The Fake Swiss Property S/4HANA Case Study

We analyzed with great skepticism the Swiss Property S/4HANA case study, as we covered in this article.

If we look at the Swiss Properties case study, they combined S/4HANA with a construction-specific application, which brings up the question of how much S/4HANA was actually doing. As soon as you move to really mostly using the ERP system for its financial functionality, then the cost of ERP implementations becomes difficult to justify.

Construction industry-specialized software gets little development. That is, it is a niche area.

Packaged software is based on large numbers of customers. And it takes a surprisingly large number of customers to support packaged software in any particular area, which calls into question how efficient packaged software vendors actually are. Packaged software vendors have a long history of exaggerating how widely their applications can be applied. The actual amount of customization more often than not comes as a surprise to customers.

For example, process industry manufacturing (making cheese, milk, beer) is very underdeveloped, so customized solutions are very common. Now it is not a question of what is possible. Anything is possible as anything can be developed. But it is a question of what is, because of the focus that vendors put into different areas. The market for development is not perfect.

What Happens for Companies Looking for Solutions in Niche Areas

As always, one works back from requirements. If a prepackaged solution meets those requirements then, and if the price and estimated TCO is desirable, then, of course, go with the packaged solution.

But the workflows of ERP don’t overlap strongly with construction projects. Therefore a good portion of the ERP system won’t be used. There is no way around that. ERP systems are designed to support manufacturing companies. That is why the flexibility of the ERP system would be very important. There might be specialized vendors that add to the standard ERP packages (4PS was brought to us as one), but they are just customizing an existing ERP system, adding construction functionality to the ERP system. Maybe what they added is worth it, maybe it isn’t.

Once you get out of the “main lanes” of development. That is major markets for software. Construction management being an example, the pre-packaged offerings shrink and you end up customizing anyway.

Oracle and the US Air Force

Oracle is well known to have even made this proposal to the US Air Force. The US Air Force spent $1 billion on a project it never took live. The purchase of Oracle was primarily based on the idea that Oracle could replace all of its systems (with a particular focus on Oracle’s ERP).

The purchase of Oracle was primarily based on the idea that Oracle could replace all of its systems (with a particular focus on Oracle’s ERP).[1] For anyone who has worked for a defense contractor, the idea that the enormous number of custom designed systems that have functionality that no commercial vendor in the world has developed any software for gives you an inkling of how this idea has been misused over time.

Some salespeople at Oracle, with the help of Computer Sciences Corporation (CSC), essentially convinced the Air Force that they could replace almost all of the supply chain and accounting systems maintained by the Air Force with their ERP system. One billion dollars later, the Air Force fi nally concluded that their project objective was not possible; further extraordinary customization would have been required, which have taken another one billion dollars to complete. Therefore the Air Force cancelled ECSS. The functionality to replicate the Air Force’s existing systems did not exist in Oracle ERP; CSC and Oracle would have been required to both generalize the Air Force’s processes and rebuild an enormous quantity of custom functionality in Oracle. Oracle and CSC took one billion dollars of taxpayer money and did not deliver an operational system.

If there ever was a project doomed before it even began, it was the ECSS project. The Air Force bought the “we can cover all your requirements” argument pitched by ERP salespeople and consulting companies in the most extreme way. Think about this: Oracle ERP can cover two hundred and forty systems encompassing decades of specialized development? That is quite a proposal. But to various degrees, most other companies have fallen for the same argument. This inability to use “out of the box” ERP functionality is a theme that is often repeated, as explained in the quotation below:

“… many mid-sized companies quickly find that different business units have slightly different requirements, even for commodity processes like accounts payable and human resources. These local differences may arise from regulatory and compliance considerations, or simply a resistance to changing current working practices because of the organizational impact. Faced with inherent limitations and no viable way to overcome them, the team responsible for expanding a legacy ERP implementation is often forced to create multiple ERP instances (each with its own database), resulting in:

Dramatically increased cost, complexity and effort for corporate reporting and analytics

Added complexity to support transactions among business units

Increased hardware and IT administration cost and complexity

A natural tendency toward local optimization at the expense of overall visibility and effectiveness”—Is Your ERP Creating a Legacy of Frustration?

The Real Story on Mapping Functionality to ERP

ERP systems can and should be used wherever they meet the requirements, and not where they do not. The focus of the ISAP would be to meet the company’s requirements at the lowest possible cost – which will need to include software acquisition costs, hardware costs, implementation costs as well as maintenance costs.

The research of other entities has dovetailed with my own which indicates that roughly 65% of the cost of systems is in their long-term maintenance.[2] Long-term maintenance is where the real opportunities for lower cost lie.

The Deceptive/Secret Level of Customization on ERP Implementations

Nearly all ERP implementations have customization, with a niche item like construction management, the likelihood of customization is very high. So if I were looking for a solution, I would put flexibility of customization higher than the functionality. There is a dramatic difference in customizing efficiency depending upon the solution you choose.

The high degree of customization required to get non-open source packaged niche solutions to work properly is why we are a proponent of open source ERP for niche solutions. Look at ERPNext. The software is open source, and they have easily addressable APIs.

https://erpnext.org/docs/current/api

It is developed in Python, a very good language for math. They have project functionality already.

https://erpnext.org/docs/user/manual/en/projects

With something like this, which is free to use, now you can start with a lot of functionality, and at a low cost add what you want because you can use a Python developer. If you want to customize 50% of it, you can do that. If you want to add a packaged construction management application to cover a specific area, you can do that. And it is already cloud. One can go and get an open source ERP system that we have rated quite highly, and simply begin using it. Build a prototype based on your requirements.

Conclusion

When it comes to lowering maintenance costs, most US companies focus on lower quality ways of cost reduction like outsourcing support. However, the much larger opportunity for lower maintenance costs is through better software selection. One of the dimensions of software selection is choosing more maintainable software. Another dimension is maximizing the fit between requirements and the software selected. Another is selecting software that users naturally want to use – reducing training, support questions, and other general support.

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.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

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

[1] https://www.nytimes.com/2012/12/09/technology/air-force-stumbles-over-software-modernization-project.html?pagewanted=all

[2] This is the only book ever written that covers Total Cost of Ownership as applied to enterprise software.

How ERP System Was a Trojan Horse

 Executive Summary

  • ERP vendors presentation the concept of a single system for everything, and later a fully integrated suite.
  • Neither of these proposals ended up being true. Increasingly ERP looks like a Trojan Horse.

Introduction

ERP fundamentally reconfigured the marketplace of enterprise software and became a major software category. ERP had a second impact in that it positioned several vendors extremely well to sell other types of software. However, what is almost never discussed is whether the logic that was used to persuade companies to purchase ERP systems has proven to be true over time. This is the topic for this article. In it, I will analyze the primary reasons provided for ERP implementations, and how that logic has held up.

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

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

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

The Single System Logic for ERP

The initial idea behind ERP systems was that it would take many applications and make them a single system – reducing application integration issues.

“Many technical reasons exist including the replacement of disparate systems into a single integrated system (Hitt et al., 2002).”

However, after the major ERP vendors sold the ERP product into companies, they began to develop specialized products for things like supply chain planning, business intelligence, customer relationship management, etc.. This was done for several reasons. One was that there was simply no way that an ERP system, with its simple approach to all functionality – with the possible exception of finance and accounting, could meet all the needs of companies. Secondly, once ERP companies had sold their ERP applications, they needed to develop more applications to grow their sales. Once they had the ERP system implemented, they had the network effect on their side, as the ERP system is the mother ship application for a company, the application or set of applications to which other application must all integrate. This allowed ERP vendors to unfairly compete by telling companies that their applications had a head start in integration to the company’s ERP system. Companies like SAP and Oracle promptly took full advantage of this market power.

This means that they were in a competitive position to be able to sell more software into these accounts. These applications all have their platforms and do have adapters to one another, but are each a separate application, with a different database, sitting on different hardware. This means that companies are essentially back where they started before the move to ERP systems. Except, they now rely more on external application development through commercial software rather than internal application development. This leads to the next point.

The Logic of Cost Reduction for ERP

All of these factors undercut one of the primary arguments that were often used to sell ERP systems, which they would reduce costs. As is explained above, the main argument for IT simplification based cost reduction is gone. However, after ERP systems had been sold, that logic conveniently left the building, or declined as a point of emphasis, because after ERP software had been sold, the motivation moved towards selling different types of software. I noticed this change at SAP. Back in the late 1990s, before they had a supply chain planning system, SAP essentially told companies that supply chain planning systems (which duplicated some of the supply chain functionality in SAP R/3, but also offered supply chain functionality not in ERP systems and provide much more advanced functionality.) was unnecessary. However, after they developed their external supply chain planning system, they changed their tune and proposed that it was now very necessary.

Business Cost Reduction

The second area where ERP systems were supposed to save companies money was in the standardization of business processes. This has been accepted uncritically, as the quotation below demonstrates.

“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 piece-meal business procedures and no overall plan, to a re-engineered organization that is poised to take growth and profitability to a whole new level.”

However, there was never any evidence that this was, in fact, true. Searches for research in this area do not produce studies which show the beneficial effects, or the cost reducing effects of ERP implementations. However, there are several studies in the area. Interesting quotes have been listed below:

“The benefits of ERP systems are usually overestimated by ERP vendors.”

The Best Practice Logic for ERP

The manner in which SAP pushes the concept of best practices is extremely easy to ridicule, as I have done in multiple articles such as here and here. SAP simply took the initial pitch of best practices from their ERP system sales approach and applied it to other products such as their supply chain planning suite. As an expert in these SAP systems, I can say that any statement regarding best practices in the SAP supply chain planning APO suite is utterly unfounded. Not only does SAP APO not contain best practices, but many of the areas of functionality in APO are a worst practice. After more than that a decade of opportunity, very few companies have benefited from buying or implementing APO, with companies having a higher likelihood of failure with APO than success. It makes one wonder if the entire best practice logic for ERP ever had any validity. What many vendors call “best practice” often seems to be a code word for “generic” functionality. For instance, many companies would say that posting a goods receipt document after a product has been scanned into a warehouse is a best practice. But is it, or is it simply generic. In the say way, is using a steering wheel to steer a car a best practice? Indeed one could say it is, but it is also now a generic offering. Furthermore, ERP systems had watered down functionality. This was acknowledged even by ERP vendors, but it was counteracted by improved integration. How such watered down functionality can also contain “best practices” is a mystery.

The Integration Logic for ERP

ERP systems integrated some things, but not all things. And again, because corporate landscapes have so may applications, there is still a lot of integration work that needs to be done. One of the areas of logic for ERP systems was that the company would be better integrated. However, it is hard to see how that is the case, and wouldn’t this improvement show itself in financial performance? As pointed out in a research study into the benefits of ERP.

“In the end, it could be said that previous research suggest that a mixed result exists when analyzing the effect of IT on business performance where some studies supported a positive relation while others suggested that companies adopting ERP did not perform financially better than non-adopting companies (Nicolaou, 2004). It can be also said that the effect of IT on business performance differs from country to country (Pilat, 2004) and should be considered when measuring business performance gains due to IT adoption.

Therefore, previous research has found contradicting findings regarding the effect of ERP systems on business performance. While some researchers have found that ERP systems can affect overall business performance positively, others have only found ERP systems to affect specific areas communications of the IBIMA 6and not the overall business performance. This can then suggest that ERP systems do not always affect business performance positively and some contributing factors affect this relationship (Kang et al., 2008).”

The Real Benefit of ERP Systems

The only demonstrated benefit of ERP has been to the ERP vendors, not to the buyers or ERP software. A purchase of an ERP system is an extremely efficient way to lock in a customer to a vendor and allowing the vendor to sell them other applications.

The Presentation of the Integrated Suite Philosophy

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

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

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

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

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

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

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

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

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

The Reality Around Adapters

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

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

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

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

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

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

While doing research for the book The Real Story Behind ERP, I found interesting information regarding the tactics used to sell ERP software. One of the central logics used to sell ERP was that it would decrease the need for integration. This turned out to be false, but was a main motivator for many ERP purchases in any case.

A Better Course for Achieving Integration

A much more effective solution that what has been described above would have been if ERP companies had never been allowed to procure other vendors, and if ERP vendors had not created external products, and instead if they had worked to publish to an integration standard and allowed the middleware vendors, those that were actually skilled at creating middleware to create the adapters.

Why ERP Vendors Invested Nothing in Publishing Standards

ERP companies had no interested in doing this. Instead they intended to use their position at their customers to sell in more software, which was often poorly integrated and uncompetitive with best of breed applications. In this way, the ERP companies put their own interest ahead of their customers’ interests.

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

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

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

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

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

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

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

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

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

Integration Suites as a Way to Reduce Competition?

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

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

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

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

Integration is Not a Primary Driver of TCO

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

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

Consulting Companies Focus on TCO or Set About Maximizing TCO?

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

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

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

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

Hypothesis Testing

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

“Is there a way to test this hypothesis?

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

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

The Most Important Feature in the Software Correlated to Implementation Success

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

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

An Often Repeated Evidence-Free Assertion

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

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

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

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

How ERP Systems Were a Trojan Horse

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

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

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

How Competition in Enterprise Software Works

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

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

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

The ERP System and Horizontal Enterprise Software Competition

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

Industry Consolidation

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

Ignoring The Reduction in Choice

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

What is the Specific Comment

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

What is Account Control?

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

The ERP System as the Queen

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

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

ERP-Centric Strategy?

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

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

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

Conclusion

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

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

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

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

ERP Contact Form

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

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

References

https://www.ibimapublishing.com/journals/CIBIMA/2011/670212/670212.pdf

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

Global Versus Single Software Instances of SAP

Executive Summary

  • A single global software instance is where multiple regional countries are supported by one software instance.
  • Global instances have a limitation in the marginalization of regional business requirements due to differences in political power and conflicting interests.
  • There are positives and negatives in standardization.
  • How to identify opportunities for using single global instances by enterprise application categories.

Introduction to Global Instances

This is the first of a three-part article series focused on critical decision factors between implementing a single global software instance, or multiple regional software instances. This article is based on real experiences taken from global software implementations. You will learn the positives and negatives associated with global instances.

What is a Single Global Software Instance?

Let us discuss what is meant by a single global instance in enterprise software. This is where the software is installed in one region, which is then used by multiple areas.

  • Single Global Instance: A good example of this is where a multinational company installs an application in say Germany, but this instance not only supports the European region but the North American and Asian regions as well.
  • Multiple Regional Instance: The opposite of a single global instance is a multiple instance implementation where each region has its software and hardware which is run from a location within that region.

The Conceptual Appeal of Single Global Instances

The idea of using a single global instance of software to support multiple regions is an appealing concept to many companies, and global instances work quite well under some circumstances.

Companies often like the idea of a single global instance standardizing how the software is used within the enterprise. This restricts the way in which the company can configure, customize and use the software by region, and is consistent with a particular philosophy where IT is emphasized over the business.

IT organizations look for maximum IT efficiency, which means systems that can be applied to the most users with the lowest IT infrastructure. Email and communication systems are a good example of systems that scale very well and exhibit little need for variance per region.

The Single Global Instance Concept Generally

When a global software instance is used for, say supply chain planning where I have worked on many projects, it typically leads to projections that the planning will finally be “integrated” between the different regions.

Multi nationals will often transfer materials between the regions, a transaction which is covered by either purchase orders (which behave as if the two companies are foreign companies to one another), or preferably intra-company stock transport orders).

However, this results in other complexities that are easy to gloss over during the high-level planning sessions before the project kicks off. Two of the major complications are listed below:

  1. Uptime: All applications require their uptime to be coordinated when they are supporting regions across for the different time zones. A single global instance means downtime is harder to organize.
  2. Processing Time: For applications that require substantial processing (and not all do) the processing schedule must also be coordinated between the regions. For instance, if an application runs a procedure, it may lock the activities for other areas, in that the people in the “up” regions may not be able to even make changes to the data. This means that a coordinated “batch scheduled” of when processing is run. For those interested in the details on this topic which explain the challenges, I cover some of them in this article.

Applications that require substantial processing reduce the ability of an application to be set up” as a single global instance. Secondly, the processing time for batch jobs may seem manageable at a high level, can turn out to be a problem once the jobs are scheduled, leading to contention once the software has been implemented.

Regional Management of Instances

Companies, which are experienced and advanced in their use of APO, may have two regions up on SNP, but often not the third. Being live with multiple regions does not necessarily mean that the implementations planning effectively between the regions. Whether they are or not is strongly related to the organizational design with regards to planning within companies. There are some companies, particularly companies that rely on 100% outsourced manufacturing that performs all planning in one country, but it is more of a rarity.

While there is much discussion of the “global economy,” supply chain planning continues to be regional and in many cases a local affair.

Planners with an understanding of the local markets are considered to provide an edge over global planning. At least that is the storyline.

Decentralized Planning

Most companies have decentralized planning (Europe planners plan European supply networks, US planners for the US supply network, Latin American planners for et…) and multiple planning departments mean different ways of doing things, different directors and VPs and traditional political rivalries. While companies accept regional planning organizations, most do view having all regions on a single planning system as desirable. It is no simple matter to meet this objective. When implementing SNP globally, the following issues arise.

  1. When the processing is performed daily, will the processing load impact both the responsiveness of the system for the users and or will users be locked out of their user interface? Setting up a global system means analyzing the technical implications of how supply planning processing jobs are set up. This includes locking planning books for product locations which are being processed by a supply planning method. And evaluating issues of contention – this leads to both to implications for hardware sizing, as well as the methods that are selected and how the various planning runs are set up.
  2. SNP has a structured way of transferring demand through the supply network, as is described in detail in this link. The situation does not change when locations are in different international regions. It will move distribution demand between locations the same way. If a location in Ohio has a source of supply in Hungary, and the operational workflow only processes US locations during one-period distribution demand will be created on the Hungary location. The Hungary location will have to wait until the European threads are processes for distribution receipts and planned orders to be created in that factory. Processing the supply network for the entire globe once per week could eliminate this issue. (this way, all regions would be synchronized when they start work on Mondays. It should be noted that there is not a simple 48-hour window in which to perform processing. Instead, the window is when the last region closes for business on Friday, and when the first region opens for business on Monday morning.) The regional processing model and its implications for what appears and when it seems at other the location which is a source of supply is shown in the graphic below:
  3. When a global instance is used, while the initial supply plan and deployment plans are required to be globally aware, the rough cut capacity/ S&OP / MPS plan, as well as the redeployment plan, are not. This is because rough cut capacity / S&OP / MPS planning is regional. Secondly, redeployment is also regional. Therefore, the processing and coordination needs for these plans is lower than for the initial supply plan and for the deployment plan.

The Global Schedule for the SNP System

The different methods for the S&OP/ MPS/ Rough Cut capacity plan and the initial supply plan are listed (in SNP) below:

options-for-supply-planning

Of course, the one method that is left out is inventory optimization and multi echelon planning (MEIO). This method does not exist in SNP. MRP or DRP are also not included, as these two methods do not exist in SNP and are the standard supply planning methods available in SAP ERP. For both, the SNP heuristic and the deployment heuristic are more sophisticated alternatives. I should also note that these options are for the initial supply plan. DRP (as was the deployment heuristic) is part of the deployment plan, which follows the initial supply plan 

Regional Differences in Political Power and Conflicting Interests

A problem with single global instance implementations is they often lead to seemingly endless debates with the other regions as to how the system will be configured and each region has a strong tendency to believe that the configuration settings that work for them should be the ones to be used in the global instance.

What is supposedly cooperative, will often end up competitive once control of a customized and highly configurable application is in play.

Typically, the region where the company is headquartered gets its way – and the other regions must simply deal with a system, which is poorly configured for their needs. Putting the needs of the outlying regions on a second level is a great way to have the regional users reduce their use of the system.

Secondly, the more one gets into the detail of how each region manages their business, the more the differences in how the business operates become apparent. This lengthens both the time of the implementation as well as the risk of the implementation. These are of course major issues to be considered before giving the thumbs up on a single global instance.

Getting the Real Story on an Application from the Hosting Region (Headquarters)

In the 1st article in this series I pointed out that typically, the region where the company is headquartered gets its way – and the other regions must simply deal with a system, which is maybe poorly configured for their needs. Putting the needs of the outlying regions on a second level is an excellent way to have the regional users reduce their use of the system. Having participated in global rollouts, I can say that headquarters getting its way most often has nothing to do with “best practices” or choosing the best design. Instead, it is often simply the group that is based at headquarters and therefore that has the power that gets its way.

Secondly, there are certain ways which this can be accomplished in a way that can be hidden, to restrict the choices of the other regions, but without coming out directly saying to the regions that they had their options limited.

Is the functionality a secret to be tightly controlled and kept from the other regions? As the country where headquarters is located typically implements first, and therefore they are at a great informational advantage versus the other regions.

How Application Design Decisions Can be Steered by Headquarters

Even where documentation exists on the functionality in question, they can be told by the IT support team at headquarters that the functionality “was tested and just did not work properly or simply did not meet the business requirements.” Especially in the early parts of the rollouts for the other regions, where of course many of the decisions are made, there tends to be a natural trust of the information that comes out of headquarters regarding the application. The knowledge difference between a group that has already participated in implementation versus a group that is beginning an implementation is enormous. Now, not all implementations begin at the headquarter region before they are rolled out to other regions, but many do.

The experience above came from a global implementation where I worked. In this case, the region (where headquarters was located) that first implemented the software deliberately mislead the other regions as to what functionality was available so that the system would only be configured the way they wanted it to be rather than letting the other regions know the full story of what the application could do.

The other regions paid for the system (through transfer payments to the headquarter region) just as the headquarters did, however, their ability to get the system to fit their needs was quite small. And the IT support organization worked at headquarters, their bosses all worked at headquarters, so the regions had very little sway over the overseas IT organization.

Standardization sounds nice, but it often means a reduction in the ability to adjust locally, and the “standards” determined by people that don’t have the best interests or that understand or are interested in the complications of local individuals and institutions.

Positives and Negatives of Standardization

Standardization works when the variances are small and when the benefits from standardization are clear.

  • The metric system is an example of one such standard that benefits those that adopt it. The metric system takes the time to implement, but it is both undeniably superior to the imperial system, and once adopted, the country is better integrated into other countries in their weights and measures.
  • Some standards are presented as virtuous when in fact, they merely benefit the entity which is in the position to determine the standard that will be set. Colonialization is one example of this type of standardization which consists of a series of rules and regulations passed and enforced by the ruling entity for the primary benefit of the governing body.

Thus, while companies may look integrated between their regions from the outside looking in, however, what I have found from some projects, is that the firm’s regions primarily care about themselves first, and one region cannot trust other regions to perform solution design for them.

Meeting Business Requirements

While there are a wide variety of business requirements in companies, which can often differ greatly based upon the region, IT departments will frequently attempt to generalize the business requirements to present them as more uniform than they may be. This allows more regions (in the case of a multinational), at least in concept, to use a single global instance of an application. However, are the total costs lower once one moves to a single global instance?

The answer to this very much depends upon the business requirements and how the implementation is performed.

Business needs drive differences regarding how applications need to be configured. If one region requires configuration and follows a particular business process that another region will not follow, then there can be a difficulty in using a single instance, reducing the benefits of going with a single global install.

The second question is whether the business value is as high with a single global instance versus multiple regional instances. I will provide an example of where the business value is, in fact, higher when a single global instance is used.

Identifying Opportunities for Using Single Global Instances by Enterprise Application Category

There are some categories of enterprise applications that make a lot of sense to have as a single instance.

One of these is bill of material management software (aka Product Life Cycle software or PLM). This software is used to allow multiple departments within companies to collaborate on the draft law of equipment – it also allows suppliers and contract manufacturers to work on the BOM. Also which is of primary importance for both efficiency of product development and design as well as enabling the company to get a better price. This is because the BOM components can be bid on by more suppliers. BOM/PLM software does not usually need to be individually configured for different regions.

For instance, the BOM management company Arena Solutions provides a SaaS solution to many customers from a single global instance, where it services all clients. This is where a vendor supports multiple customers who may use the application globally, from a single global instance, but of course, there are divisions between the customers so they can’t see each other’s data.

Having a single global instance of a BOM or PLM system turns out to be incredibly important for this type of software. The BOM is probably the most collaborative master data objects in systems.

Not only should different regions be collaborating on the same BOM information, but suppliers and other partners should also be logged into a single system — of course with an excellent security model.

How the BOM is Shared

The BOM is shared and sits between both some applications as well as interface with users both inside and outside of the company which controls the BOM.

When a vendor works in a software category of this type, they can substantially reduce the costs of delivering the application as well as increase its functionality. Another application group that is also not coincidentally often sold under the SaaS model, which typically requires little customization and has light configuration is CRM.  PLM and CRM software are good candidates for single global instance implementations.

However, the more configuration and customization and configuration that any application requires, the more difficult it is to make those applications be the single instance. ERP applications are some of the most intensively customized applications in any software category.

From the examples provided above, it should be clear that the discussion of the costs and benefits regarding a single global instance versus multiple regional instances very much changes depending upon the enterprise application category.  As well as the degree of similarity in the configuration and customization of applications — which are questions that are specific to the company in question.

How The Cost Categories Change

We have estimated the cost components to single versus multiple instance implementations at our quantification research site. It is important to have this adjustment regarding estimation because the costs change in different areas depending upon whether a single or multiple instances is used. (there are other factors that are important to adjust for as well including the following)

  1. The Number of Software Instances
  2. The Number of Languages Supported
  3. The Number of Regions Supported

The following costs behave the following way as a company moves from a single instance to multiple instances:

  1. Maintenance Costs: Increase
  2. Hardware Costs: Increase (although hardware costs are such a low percentage of the total cost of ownership of any enterprise software application that this is not a deciding factor)
  3. Implementation Costs: Decrease. Single instances – for the majority of applications (those that require more specific configuration) mean more effort in driving to compromise on how software will be configured. This is because the configuration will serve the needs of some regions, subsidiaries, etc.. but not others.
  4. Software Costs: Neutral

All of this drives towards costs. And as much as I like calculating TCO, TCO has nothing to do with benefits received from an application.

As I stated in the second article in this series, costs should not be the determining factor in an IT strategy. Any concept, which reduces the fit of the application to the business, reduces the probability of success of that application and therefore its ROI. If application implementation were simply about costs, then we would select the cheapest applications, the least experienced consultants and the lowest cost outsources IT support that is available on the market. So costs do not define the ROI.

Conclusion

It should not be simply accepted blindly that single global instances applications save money, and offer the same business capabilities as do multi-instance regional implementations. This applies in particular when the application either is processor intensive, requires significant configuration or customization (and there are substantial to moderate variances from region to region). It also means substantially increasing the risk of the project.

CIOs or IT department heads will often oversimplify the trade-offs inherent to the global versus regional instance question. This is because the IT cost is often lower, but that is not all of the expenses, and as can be seen, if the headquarters region controls the functionality and design that is used in other regions. The other regions can end up with a system that was designed to meet the needs of the headquarters region, but which does not meet the needs of the outlying regions. That is a problem.

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.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

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 Determine if You Suffer from (ECS) – ERP Centric Strategy?

What This Article Covers

  • What is ECS?
  • What are Symptoms of ECS?
  • How to Manage ECS

erp

Introduction

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

The following shocking statistics apply to this disease.

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

“Totally suck!”

And

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

or

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

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

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

Bummed

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

Look Out Window

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

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

And

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

or

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

Happy

What is at the Heart of ECS?

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

  1. The ERP system should be emphasized above all other systems because “it’s the biggest.”

  2. The ERP system the system of record for all data.

  3. ERP functionality is used — even when it is weak in a particular area.

  4. Integration should be avoided.

Earth

The History of Mistaken Centric Thinking

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

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

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

Galileo

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

ECS

The Effects of ECS

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

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

Myth

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

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

Is There a Cure for ECS?

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

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

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

Help

Offering a Helping Hand for the Afflicted

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

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

Brain Gears

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

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

References

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

1. Threatening to torture and kill Galileo is as one imagines for something he was right about is very embarrassing for the Vatican, yet there was someone, a Giovanni Battista Enrico Antonio Maria Montini, who actually choose to take the name Pope Paul the VI.

This was in 1963 mind you. Now you can choose any name you want as the new Pope. However, one has to ask, what was the mentality of the guy who wanted to be the 6th Pope Paul?

How to Understand the Problems with Bias in Enterprise Software

What This Article Covers

  • The Objectivity of Those that Work in Enterprise Software.
  • The Hidden Income that Gravitates to Those that are Subjective.
  • Why Being Objective is Bad for One’s Career.
  • The Assumption of Objectivity from Information Providers.

Introduction

This sub-blog focuses on how little evidence there is that the most popular software category in enterprise software — ERP — provides benefits beyond costs to the companies that implement it. This is the topic of my book The Real Story Behind ERP: Separating Fiction From Reality.

However, ERP systems continue to be popular, and beyond that, there is zero questioning regarding ERP.

The lack of objectivity extends to just about every other area of enterprise software. Here are some examples that I have witnessed.

  1. Most software vendors exaggerate how good their application is versus the competition. They not only amplify to prospects and clients, but to anyone they interact with.
  2. There are very few employment positions where one can be objective without negatively affecting one’s career. Obviously, if one works for one software vendor, one cannot say good things about competing for software – however, the lack of ability to be objective extends to consulting companies and IT, analysts. As a consultant working for a consulting company, the policy of what software to recommend is made at a very high level with those below senior partner positions having substantially no input. As an IT analyst, due to the need to sell services to software vendors, one cannot realistically be objective as an analyst and expect to have a good career. IT journalists also must write articles that pass their editor’s review, and that means those that make their advertisers happy — which are the large consulting and software vendors. Conferences also have specific funders and do very little to mitigate the bias of the presenters that provide information to the conference attendees.

Conclusion

There is essentially no objectivity in the enterprise software market because there is no way of making a living from being objective. All the income resides on the side of being subjective. Much of how the revenue flows to influence bias is hidden. For instance, some journalists received direct payments from software vendors.

Consulting companies recommend one software application, but don’t mention that their opinions are highly influenced by the fact that they can make the most money from that particular application.

Gartner and other IT analysts hide the fact that they receive income from software vendors, they also hide who they receive income from, and there is no way to find out — either from their website or even from their annual reports. Rather than declare their sources of revenue,

Gartner proposes that their funding is irrelevant and that they have an ombudsman, which is a false position that in effect does nothing to mitigate the effects of vendor money on Gartner, but instead acts as a PR function, to convince customers of Gartner’s objectivity. It allows Gartner to continue to take large sums of money from the biggest software vendors — which then highly influences their ratings — that they then also sell to enterprise software buyers. This is all covered in the SCM Focus book, Gartner and the Magic Quadrant: A Guide for Buyers, Vendors, and Investors.

Interestingly, there is the assumption that information that is provided — either by consulting companies or IT analysts or other entities is objective — if this were not the assumption that there would be little reason to listen to information in the first place. Furthermore, almost every entity that provides information in the enterprise software space claims they are objective. They just happen to hold the views that line up 100% with their career and compensation structure. It is truly an amazing coincidence.

References

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

The Real Story on ERP

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

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

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

Break the Bank for ERP?

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

By reading this book you will:

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

Chapters

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

How Much Money Has Been Wasted on Oracle and SAP ERP

 What This Article Covers

  • Background on the Waste with Tier 1 ERP Systems
  • The Team Effort for Required for the Analytical Failure
  • Tips for Interpreting the Book

Introduction

In the book The Real Story Behind ERP: Separating Fact from Fiction, extensive research performed by SCM Focus is presented — and the conclusion is that ERP was never proven to improve either the operations or finance of any company. Furthermore, one after another prediction made by — particularly the Tier 1 ERP vendors never came true.

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

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

The Team Effort for Required for the Analytical Failure

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

Tips for Interpreting the Book

The first step for readers — and it is a big step, is to review the evidence presented in the book to understand what transpired in an over 30-year misinformation program. Because ERP is now so ubiquitous, it is assumed that ERP is necessary — even if it does not provide any payoff. However, there are a large number of flaws in this common assumption. “ERP” is some things. First, it is a concept, which is defined by the book as the following:

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

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

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

Conclusion

The book includes specific examples of how ERP limits companies which are listed below.

  1. Case Study #1 of ERP Misuse: Managing the Bill of Materials/Recipe
  2. Case Study #2 of ERP Misuse: Disabling the Enterprise for Collaboration
  3. Case Study #3 of ERP Misuse: How ERP Undermines Internal/External Planning
  4. Case Study #4 of ERP Misuse: Intercompany Transfer

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.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

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

Do Non Manufacturing Distribution Companies Require ERP?

Executive Summary

  • Background on OEMs that do Not Need to Explode the BOM
  • Does A Company That Performs No Manufacturing and No Distribution Require an ERP System?
  • Alternate Designs to Exploding the BOM with MRP.
  • If MRP is Required, Must it Come From an ERP System?

Introduction

In this article, we investigated what happens when an OEM performs no manufacturing and an alternative model to the convention design — where the OEM runs MRP and explodes the BOM. In one alternative, MRP is run by the OEM, but only for the well-finished level. In this article we take this thought exercise to one following level — and this third scenario is where the OEM also performs no distribution. In fact, many high-tech OEMs outsource not only manufacturing but distribution as well. However, most consulting companies follow a standard policy of recommending ERP implementations to their clients.

Why?

This is done not because there is any evidence that ERP systems provide a financial return (they don’t as is explained in the SCM Focus Press book The Real Story Behind ERP: Separating Fact from Fiction.)

Consulting doesn’t know or care much what works for their clients but are intensively driven to maximize their revenues — which means software categories which maximize the revenues of consulting companies will be recommended. ERP provides a negative return on investment, even for enterprises that have most of the business processes covered by ERP systems, but can be especially poor values for companies that cannot use ERP systems for much more of a minority of what they do because they do not fit the ERP cookie cutter design. To see why this is the case, let us look at the application components of ERP systems:

  1. Sales
  2. Materials Management/Distribution
  3. Production Planning
  4. Finance and Controlling

For many high-tech OEMs they, as we have just discussed do no production or distribution, so they have no use for two of the standard application components of any ERP system. As for the Sales component, this is an entertaining area.

How About Sales and Finance?

What is happening is that CRM is encroaching on the standard sales module of applications like SAP and Oracle. Increasingly solutions like Salesforce can provide most all of the functions of the sales module of ERP systems — and they are far easier to use, and allow a true connection to the sales force. Specific best of breed applications for sophisticated functionality such as pricing can be added at a higher functionality level than anything offered by the major ERP vendors. This leaves the finance module – which any company requires. The finance module can be acquired with a system such as Financial Force, which is pre-integrated with Salesforce and is native to the Force platform, or Intacct, which also provides easy to integrate stand-alone finance application, and which is capable of scaling to the accounting needs of even large companies. However, the original argument, or should I say one of the major original reasons for ERP system acquisition was that one could use all of the modules of an ERP system and they have been fully integrated (sit on the same database, no interfaces, etc..) However, while this may apply to many traditional companies – it in no way applies to many other businesses that do not perform all the traditional functions of a manufacturing company. Here is why:

  1. The ERP system may be integrated, but these high-tech OEMs have little use for the set of functionality that ERP systems offer.
  2. ERP systems are a significant expense, much larger than anyone originally projected. It is laughable now, but ERP was originally planned to decrease IT costs. This is probably the point where anyone who has worked in ERP sales will want to stop reading. This is because promoters of ERP systems have been proven wrong on every one of the major logics that were used to justify ERP (as is covered in great detail the SCM Focus Press book The Real Story Behind ERP: Separating Fact from Fiction). And this applies in particular to Tier 1 ERP vendors and becomes less and less true, and one moves through the Tier 2 and least true as one moves to cloud-based ERP.

Alternate Designs to Exploding the BOM with MRP

  1. The Alternative Design 1: MRP at Finished Good Level at OEM

The Benefits of the Alternative Design

The OEM gets a much easier and lower cost to maintain the system, and the complexity manufacturing is moved to where it should reside, at the CM as they are planning the production. Some companies attempt to prepare their CM/subcontract suppliers actively. This can work when the OEM is a sizable part of the demand of the CM/subcontractor (and there are still complications in this – a detailed explanation of the type of software that can relatively easily handle this requirement is covered in the SCM Focus Press book  SuperPlant: Creating a Nimble Manufacturing Enterprise with Adaptive Planning Software) if one represents only a small fraction of the demand for a CM/subcontractor capacity, it makes little sense to model this plant – in fact, it is highly unlikely the CM/contractor would be willing to share capacity information – it is simply not worth their time.

If MRP is Required, Must it Come From an ERP System?

In Alternative Design 1 above, MRP is still performed for the well-finished level. Wouldn’t an ERP system be required to run MRP? Actually no. MRP functionality can be purchased at low cost compared to a full ERP system. Demand Works Smoothie runs MRP and does so with overall functionality and usability, which is superior to any ERP system that SCM Focus has tested – which includes all Tier 1, and several Tier 2 as well as multiple clouds based ERP systems. More on this topic is covered in detail in the article Why Not All MRP Systems Are Created Equal.

Conclusion

The answer is that for many companies that do no manufacturing or distribution even, do not require an ERP system. Instead, they can combine much high value best of breed applications at a fraction of the cost and long-term total cost of ownership, while increasing their flexibility. More on this topic will follow at this site, as we will release portions of insights from upcoming books on these subjects.

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.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

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

https://www.sciencedirect.com/science/article/pii/0272696381900310 MRP. Accessed October 18, 2013. https://en.wikipedia.org/wiki/Material_requirements_planning

Should OEMs with CMS use MRP and BOM Explosion?

What This Article Covers

  • How Much Does MRP and BOM Explosion Help Companies that Use Contract Manufacturing?
  • Do Companies that Outsource Need to Have a Manufacturing BOM in Their Supply Planning System?
  • The Alternative Design 1: MRP at Finished Good Level at OEM

How Much Does MRP and BOM Explosion Help Companies?

There is little doubt that the introduction of MRP took a great deal of the effort out of the supply and production planning process and by automating the process of supply and (initial) production planning and of BOM explosion. A review of the research on the benefits of MRP is available in this article.

An Approach That Becomes Dominant

For the past several decades MRP/DRP and ERP have become dominant concepts, The general thinking has been the following:

  1. All companies must acquire and implement ERP systems. A good example of this mindset is found in a white paper written by Aberdeen titled — To ERP or Not to ERP: In Manufacturing, It Isn’t Even a Question. This paper did not analyze any of the previous research on ERP, but simply reviewed the opinions of manufacturers, which favored the continued implementation of ERP.
  2. All companies much maintain a full BOM and explode this BOM using MRP or using other supply planning/production planning methods to accomplish the same objective.

However, is this always the case?

For companies that perform their production, some supply and production planning system – be it MRP or MRP substitute is a necessity.

In the last few decades have shown the rise of companies that design, but do not manufacture their products. This is, in fact, the common approach among high-tech OEMs.

So let us first review what MRP does.

  1. BOM Explosion: Automates the calculation of input products (raw material and components) which are necessary for a particular quantity of desired output products (finished goods). BOM explosion is one of the foundational functionalities within all supply planning system. All companies need to multiple the number of finished goods by the bill of material (production or procured items), and BOM explosion is how that is accomplished.
  2. Inventory Netting: Reduces the forecast + sales orders by the planned on hand from the planned inventory position.
  3. Inventory Planning: Calculates reorder points, safety stock, etc..
  4. Purchase Order Creation: In the quantities and the adjusted for the lead time required to meet the demand date.
  5. Production Order Creation: In the quantities and the adjusted for the lead time required to meet the demand date.
  6. Create Stock Transfers: This is technically not part of MRP but is the output of DRP — however, when people refer to “MRP systems” they are referring to both MRP/DRP, as they work in conjunction. A system with only an MRP procedure would have no way of creating stock transfers and moving stock through the supply network.

Now let us review how these MRP/DRP functions are used or not used by companies which outsource their manufacturing:

  1. BOM Explosion: No (BOM explosion is sometimes performed by the OEM, but other times the BOM explosion is often carried out by the outsourced factory in their MRP or other supply planning system)
  2. Inventory Netting: Yes
  3. Inventory PlanningYes
  4. Purchase Order CreationYes – but only at the good finished level.
  5. Production Order Creation: No
  6. Create Stock Transfers: Yes

Therefore, even companies that outsource all of their manufacturing still need to use an MRP or other supply planning system.

There are other ways to perform these same activities — and all the more advanced supply planning/initial production planning methods provide the same categories of output. This article is about sticking to the simpler side of the supply and production planning continuum, and so MRP/DRP is still useful.

Do Companies that Outsource Need to Have a Manufacturing BOM in Their Supply Planning System?

I want to be careful to be specific here so as not to cause confusion.

  1. Design BOM or Manufacturing BOM?: There are many different types of BOMs, however for our purposes here we only need to be concerned with the design BOM and the manufacturing BOM (or MBOM). The design BOM is as the name implies the BOM that is produced by the engineering and design side of the business.
  2. Must the OEM Instantiate and Maintain an MBOM in their MRP (or other supply planning/production planning) System?: There is no doubt the OEM will have a design BOM. It is their design after all. However, the question is – if they do not perform any manufacturing do they need to maintain the MBOM? The answers are no because the OEM does not need to explode the BOM because they are not communicating with their supplier’s detail below the finished good. This is because the CM is delivering the finished good to the OEM.

The Alternative Design 1: MRP at Finished Good Level at OEM

The OEM can move directly from the forecast for the finished good and then sending the finished goods forecast. This is the same as the OEM procurement plan to their contract manufacturer.

The steps in this process look like the following:

This design can be used with a product called Arena Demand. Arena Solutions, a PLM/PDS vendor, has a soon to be released product called Arena Demand that can allow the OEM supply plan to be aggregated and then exported to a file to be sent to the CM. It would allow the following to be performed.

  • The demand report is intended for general quoting.
  • From a top-level demand plan, the OEM probably would use a spreadsheet and type in the fields themselves.
  • As the CM already has the BOM in their MRP system, they would be able to derive the component demand themselves.
  • The OEM can’t see the component demand (if they don’t run MRP) and therefore Arena Demand enables them to see the component demand based on the supply plan.
  • The OEM can use this information to quote component cost across the market to ensure that each component is taking advantage of the purchase volume planned for the upcoming months.

Arena Demand-2-1

Notice the quarterly supply plan shown above for the two GPS units. This is a finished goods supply plan, and because there is no BOM, there is no necessity for the Arena application to calculate lead times.

That calculating is performed by MRP when the CM has provided feedback to the OEM on the feasibility of the OEM supply plan, and when POs have been sent from the OEM to the CM. Notice that in the upper right corner there is an export button, which is used to export the supply plan to a file.

Also, notice that this is just one possible planning bucket – one can also choose the monthly planning bucket rather than quarterly. Arena refers to this as the “Interval.”

The Benefits of the Alternative Design

The OEM gets a much easier and lower cost to maintain system, and the complexity manufacturing is moved to where it should reside, at the CM as they are planning the production.

Some companies attempt to actively plan their CM/subcontract suppliers, however, while this may work when the OEM is a sizable part of the demand of the CM/subcontractor. And there are still complications in this – a detailed explanation of the type of software that can relatively easily handle this requirement is covered in my book SuperPlant: Creating a Nimble Manufacturing Enterprise with Adaptive Planning Software.

Conclusion

If one represents only a small fraction of the demand for a CM/subcontractor capacity, it makes little sense to model this plant – in fact; it is highly unlikely the CM/subcontractor would be willing to share capacity information – it’s simply not worth their time. Therefore this brings up the question of whether BOM explosion is actually necessary for companies that have outsourced manufacturing.

To learn about the history of MRP see this link.

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.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, tell us your question below.

Brightwork Explorer for ERP Parameters

How to Tune ERP Systems

ERP applications require MRP parameters to be optimized externally to the ERP system. Having analyzed many ERP systems, we developed the Brightwork MRP & S&OP Explorer. It is free to access until it sees “serious usage” and is free for students and academics. Click the image to find out more.

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

https://www.sciencedirect.com/science/article/pii/0272696381900310

MRP. Accessed October 18, 2013. https://en.wikipedia.org/wiki/Material_requirements_planning

Castenllina, Nick. To ERP or Not to ERP: In Manufacturing, It Isn’t Even a Question, Aberdeen. 2011 https://aberdeen.com/aberdeen-library/7116/RA-enterprise-resource-planning.aspx

I cover BOM explosion in MRP in the following book.

Repair MRP Book

 

MRP System

Repairing your MRP System

What is the State of MRP?

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

Getting Serious About MRP Improvement

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

The Most Common Procedure for Supply and Production Planning?

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

Chapters

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