Why erp implementation error

Why ERP projects fail

Companies like to keep silence when it comes to the details of worst practices. It is precisely these cases that illustrate which mistakes are to be avoided as far as possible and how the break free from confused situations can succeed. Two "crash landings" that have occurred in real ERP projects are examined below.

Case 1: Retail company hits the wall with ERP project

The first example is about a medium-sized trading company operating across Europe with an annual turnover of around 400 million euros. It employs 300 people in five national companies. The aim of the ERP project was to convert the entire logistics to SAP in one go, with the exception of the warehouse software.

The essential components of this introduction included supply chain management (SCM), business intelligence (BI) and process integration (PI) as well as the connection and data exchange with all of the company's suppliers and partners. In short: the project affected the heartbeat of the company, the trading activity. Logically, the client initially put together a team including a project manager.

The two SAP partners commissioned with the implementation also assigned a project manager for ERP and for the modules BI and PI. At first glance, the initial situation promised a successful undertaking. The planning of the ERP project was meticulous and there were clearly defined project goals as well as a fixed time and budget. All jour fixe appointments were held regularly.

Software maps business processes incorrectly

The project started at the beginning of 2009. At 16 months, all those involved in the project believed that they had planned enough time for the introduction to safely achieve the "Big Bang". When checking the first core processes, however, it was found that business-critical processes were far from being mapped correctly with the implemented software. As a result, the "go-live date" had to be postponed by six months. This cost both the service partners and the company additional money.

Interface problems cost money and time

The pressure on the project grew, but the second start date could not be kept either. After a year of delay, it finally looked as if the signs for the new system were finally green. But it turned out differently. After the first week, deficiencies became apparent that were initially fatally underestimated by the employees. While the project team was still working on correcting processes and interface problems, the situation in incoming and outgoing goods developed more and more dramatically. Although the warehouse was full, the purchasing department continued to order goods because the system did not correctly map the inventory.

Existing articles, on the other hand, were not delivered because, according to the ERP system, they were not in stock. Other items, on the other hand, left the house undetected by the system and were sometimes not invoiced. And that's not all: Invoicing was delayed more and more, and liquidity in the company sank. A return to the old system was no longer possible at this point. In an emergency, employees recorded some of the data manually, but the tracking in the system did not work consistently and correctly. The company suddenly found itself in a critical position.

  1. When does a project go wrong?
    Pull the rip cord - when and how can you tell that a project is getting out of hand?
  2. Is the project planned for a period of more than one and a half years?
    Then it is better to break down the project into smaller sub-steps and implement business processes one after the other. The reason: A company will continue to develop in two years, business processes change and the originally planned project scope is no longer the same. Even a properly set up change management always intervenes in the ongoing and not yet complete implementation.
  3. Are milestone dates being exceeded?
    At the latest when the first deadline is exceeded, the project management must take this into account immediately and critically examine the planned measures together with the steering committee.
  4. Are there a lot of changes during the project?
    If there are permanent changes during the project duration, the planning was poor or the reality overtakes the introduction. In these cases, everyone involved should speak openly about the foreseeable risks and develop realistic countermeasures that ensure the success of the project. Or decide together to make time and budget adjustments.
  5. Are the interpersonal relationships still correct?
    If there is increased tension between consultants, project management and key users, communication will no longer work properly. Motivation problems arise and culprits are often sought instead of solutions. In such cases, action should be taken immediately - this is one of the main causes of failing projects!
  6. Is the agreed documentation ...
    ... up-to-date in the project and are changes clearly documented? If not, this is a sure indicator that the project is about to get out of hand.
  7. Is the quality right ...
    ... the implementation partner and how can the consultants' lack of knowledge be identified? Implementation goals that are broken and partial steps that do not correspond to the planning in terms of quality are clear signs of weakness. If you check partial steps in regular acceptances using a test catalog, deviations can easily be identified.
  8. An implementation partner ...
    ... and the person responsible is always easier to control than several. Especially when they are in a competitive situation with each other.