Why ERP projects really fail

Enterprise Resource Planning (ERP) systems continue to play an important/supporting role in most companies‘ IT landscapes even in the age of digital platform economics – marked by digital champions such as Google, Apple, Facebook and Amazon. The main added value of ERP systems consists primarily in the integration of company functions/processes and the controllability of companies across functions/processes.

In addition, the aspects of governance and compliance have become increasingly important in recent decades as a result of legal and regulatory requirements. And finally, as digitalization and competition with digital platform companies continue to evolve, traditional companies with linear business models are forced to deal more intensively with the question of how they can use their master and transaction data to better serve their customers and win new customers.

Now it would appear that 25 years after the market launch of SAP R/3 in 1993, the vast majority of companies have built up enough expertise and experience to manage ERP implementation projects without any major problems. Nevertheless, one hears again and again about projects that have gotten out of hand with regard to time, costs or quality. Why is that, anyway?

Google delivers 13,200 hits to the search query „Why ERP projects really fail“, including well-founded analyses such as the article by Bernd Hilgenberg (former CIO of the retail chain „Fressnapf“) published at Computerwoche.de on July 2, 2014, under the heading „Errors in ERP implementation: Why ERP projects really fail“: https://www.computerwoche.de/a/woran-erp-projekte-wirklich-scheitern,2530844. Note: The article is written in German language and can be translated e.g. with Google’s URL translator: http://itools.com/tool/google-translate-web-page-translator.

From this article I would like to cite the following substantial observation, which already addresses one of the root causes for problematic ERP projects:

„The advantage of ERP systems – their integrated approach – can sometimes be detrimental. As is well known, an ERP system is characterised by its highly process-oriented approach and working methods, and this characteristic is the germination of many problems during implementation and operation.

In a distributed software landscape with different applications, individual departments use software tailored to their individual needs. Communication between the applications takes place via interfaces, which usually only exchange partial amounts of information. In this way, each business unit can optimize and change its own system without touching the subsequent systems. This results in individual ecosystems with often their own reporting.

This has two consequences: On the one hand, the continuity of processes beyond the business units is not guaranteed. On the other hand, own systems also automatically develop their own numbers, whose correctness is difficult to verify or which open up room for interpretation. So there is no single-point of truth here. Companies are losing control and competitiveness.“

Quote End

In addition to the indisputable advantages of an ERP implementation from a business point of view mentioned at the beginning (integration, transparency, controllability, governance, compliance, customer service), ERP systems can also have disadvantages for individual functions and processes of a company when viewed from the perspective of the decentralized business units. Examples:

• Poorer process support compared to the previous IT systems, as these were often tailored and individually developed for the function or process. The unfamiliar user interface and the worse user-friendliness of the new system (especially if they are insufficiently trained and are not adequately supported after the introduction) can also be easily applied against the new ERP system. Man is a creature of habit and no one likes to accept without contradiction that a new IT system suddenly worsens his working environment, which has been painstakingly set up and optimized over the years.
• Additional effort due to the necessary higher quality and the larger scope of data entry for inventory and transaction data. For example, order processors suddenly have to record data that they „never needed before“, just to provide „some chair furlers in the head office can deal with useless evaluations“. The integration of processes (sales, engineering, service, accounting, …) with the aspired one-time recording of data can lead to additional effort, especially at the beginning of the process chain (which is usually loudly communicated), while the reduced effort at the end of the process chain is shyly concealed. The standardization or harmonization of number ranges or data keys initially only causes additional workloads, without the majority of employees being able to benefit from it.
• Not everyone likes transparency, as it makes it easier to measure and compare the performance of the various business units. And not everyone sees it as an opportunity to improve and optimize the performance and competitiveness of their own business unit through systematic comparisons with the key performance indicators of other business units. In addition, there is the „not-invented-here“ syndrome, because managers and employees in the various business units are naturally convinced that they are doing their job in the best possible way and are not dependent on best practices from other business units. Or there are separate stand-alone projects for suboptimization of sub-functions (often HR or purchasing) that are reluctant to integrate into central IT programs (because the central IT „is too slow and has no idea of our processes and their particularities anyway“).

It is therefore „human“ at every corner and every decision-maker is well advised not to make decisions on the implementation of ERP projects (including their focus and scope) exclusively from the entrepreneurial Group point of view. Rather, the consequences and side effects for all functions and processes of the Group must be systematically viewed from the point of view of the executives and employees concerned, discussed openly and honestly with the affected persons and their expectations must be moderated. The more complex a Group’s business model as well as its organizational structure and process organization, the more difficult it is to make meaningful and appropriate decisions regarding the use and design of ERP systems. Particularly since experience has shown that the devil is in the detail, so that even with the best planning, not all potential trip hazards can be identified and defused in time.

In principle, „think big“ approaches rather lead to large, extensive and long-running ERP projects, through which serious failures of the past (e. g. heterogeneous, fragmented IT landscapes with a large number of data silos) are intended to be repaired and remedied in one fell swoop. Although centralized IT architectures offer many advantages from a business point of view, such large-scale projects pose a much higher risk of dissipating and overwhelming the organization with too many changes in one fell swoop. I don’t want to express that such large-scale projects cannot be successful per se, but even the best project team consisting of top experts from IT and business will not be able to avoid all birth pangs if too many screws are turned at once.

In addition, in large companies in particular, it is usually not possible to keep the essential framework conditions, such as the organizational structure and process organization or the business model, stable over periods of more than 18 to 24 months. In addition to the „human factor“, significant changes in the project order at an advanced stage of the project are a frequent reason for ERP implementation projects to get into trouble. Agile process models do not help you either if, figuratively speaking, you send the project team on a journey to develop a family car and make the demand that this family car must also be able to win races and/or transport heavy loads.

Bernd Hilgenberg points out another significant risk in his Computerwoche article of July 2, 2014:

„Can this shortcoming (= absence of a single-point of truth) be remedied by introducing an ERP system per se? Unfortunately not! An integrated ERP system can also be configured or better bent so that the modules behave like independent applications. The resulting figures are just as difficult to comprehend. Thus, there is a real danger that a company will run into economic problems because a poorly configured ERP system can cause high costs in the long run. In addition, the company is deprived of the opportunity to identify negative business developments in good time from the available figures and to optimize its own processes.“

This observation is absolutely in keeping with my own experience and would like to add the important note that standard software is often bent and modified under the pressure of the users by modifications and extensions in such a way that the advantages of using standard software (e. g. participation in continuous further developments of the standard by the manufacturer) are no longer taken into account, since the bent ERP systems are no longer de facto release upgradeable.

The use of standard software and cloud-based software – the latter especially if you want to use it as Software as a Service (SaaS) (see: https://www.computerwoche.de/a/was-sie-ueber-die-cloud-wissen-muessen,2504589,2) – makes in general (I don’t say „exclusively“) sense for those functions and processes of a company that are neither competitive differentiating nor have a significant influence on the customer experience.

In principle, you cannot expect a standard software to support specific business processes as well as custom-made individual software, and you should be careful not to arouse or stir up expectations that cheaper off-the-shelf suits can fit as good as tailor-made suits – this is almost always unrealistic. This applies regardless of the fact that standard software can normally be adapted to a certain extent to the specific requirements of individual companies or business units by customizing. Before commissioning a project team to replace their existing IT system one-on-one with an ERP system, you better burn your money for other purposes because this is usually a pointless mission impossible for the following reasons:

• On the one hand, in certain cases it is quite deliberate to limit existing degrees of freedom in business processes, e. g. when entering and processing orders or data, in the course of an ERP introduction in order to guarantee later possibilities for a differentiated evaluation or to satisfy legal requirements.
• On the other hand the introduction of standard software should be utilized to streamline business prozesses and cut-off outdated habits. If not now, when? The design of an ERP system should not be based on a company’s past, but rather on its future, which is why the early integration of corporate functions such as strategy or business development is essential for the success of ERP projects.

The development of individual software for companies has completely gone out of fashion in the last thirty years (should one say „unfortunately“?), but should not be excluded dogmatically, since business processes are influenced by the IT systems that support them and standard software does not usually enable a company to differentiate itself from its competitors (at least not permanently). The success of digital platform companies such as Google, Apple, Facebook or Amazon is based not least on their ability to offer their customers a simple user interface to get into business with them and, as a result, capture as much customer-specific data as possible and make it usable for their own purposes.

Expectations (especially those of top management) also need to be managed in the right direction on another important point: I don’t know of any large ERP project that would have been able to make reliable predictions about the impact of ERP implementation on the company’s future process costs before the start of the project – often only because the process costs are not known in the actual state and therefore the baseline for comparisons is missing.

While the cost side of the ERP project can be reasonably qualified and realistically calculated after the definition phase on the basis of empirical values and assumptions – both with regard to the costs for customizing and development of necessary extensions of the ERP system (keywords: Fit gap analyses, appraisal assessments), as well as the costs of roll-out including training, on-site support and babysitting and the costs of running the ERP system in the future – I consider qualified assessments of the impact of an ERP implementation on the future process costs of a company to be difficult or even impossible.

This is also for a reason, because once the implementation of an ERP system has been completed, the essential work is not finished, but only begins, because now it is necessary to systematically utilize the ERP system and its possibilities for cross-functional and cross-process control and optimization of the company. This in turn presupposes that appropriate functionalities for measuring process performance are available and can be used.

This leads us directly to the truism that an ERP system can only make the desired cross-functional/process controllability of a company possible if the data in the ERP system has an adequate quality. In order to guarantee this, it is usually necessary to carry out complex data cleansing before the transfer of data from existing IT systems, which is usually not very popular with the users entrusted with this task, as they often get their eyes on it as an additional task to their normal full-time job. In addition, it must be ensured that new data (e. g. customers, suppliers, orders) can be recorded in the ERP system with sufficient data quality. In any case, an ERP implementation must be embedded in the definition and design of an integrated data model and an IT master plan in which the interfaces and dependencies to the rest of the IT landscape are documented.

Bernd Hilgenberg states in his Computerwoche article of July 2,2014, that there are other significant errors in the introduction of ERP systems, such as a strong dependence on external consultants („consulting bondage“), which is often caused or intensified by the fact that decentralized business units are not prepared to hand over their top people to ERP implementation projects. In some cases, this means that external consultants have to make fundamental directional decisions, which should actually be made by internal employees of the company.

The aforementioned list does not claim to be exhaustive (e. g. „no-brainers“ are not mentioned, such as the necessary backing from top management, intensive cooperation between IT and business when setting up the ERP system or the reference to the influence of the corporate and management culture), but it should at least include all „big points“ of decisive importance. If, in your opinion, important points are missing, I am grateful for any advice.

Conclusion:

A careful analysis of whether or to what extent the (future) business model and (future) business processes of a company can be supported by standard software according to requirements is the essential prerequisite for the success of ERP implementation projects and other projects in which (cloud-based) standard software is to be introduced. This analysis must serve as an essential basis for determining a meaningful and feasible project scope. Not everything that is meaningful and desirable from an ther overall entrepreneurial Group’s point of view can be implemented in practice throughout the entire company. A very central question is how much change can and wants to be expected of one’s own organization. The answer to this question depends, among other things, on the size, heterogeneity and staff quality of the organisations concerned. Change management, training and support measures are indispensable, but no guarantee for a smooth project flow. According to Gaussian normal distribution, approximately 15 to 20% of managers and employees in an organization will generally find it difficult to accept and implement the necessary changes in the course of an ERP implementation. Fundamental changes in the project order during the project runtime should be avoided. In addition, it is often necessary to implement maintenance processes and quality assurance mechanisms for data that did not exist in the old IT system landscape in this form. Without an integrated data model and measures to ensure adequate data quality, an ERP project will be just as unsuccessful as an ERP project without the embedding in an IT master plan as a basis for the management of interfaces and dependencies to upstream and downstream IT systems. Finally, too much dependence on external consultants should be avoided.

If you liked this blog about ERP projects, you can find my blog from November 4, 2017 on the topic „Digital Business Models and Platform Economy“ at https://kubraconsult.blog/2017/11/04/digital-business-models-and-platform-economy/ and my blog from December 23, 2018 on the topic „Crypto Assets – the most important Q&A“at https://kubraconsult.blog/2017/12/23/cryptocurrencies-the-most-important-qa/.