Ein international tätiger Küchengerätehersteller war schon vier Monate nach Projektstart mit einer Kostensteigerung um mehr als 60 Prozent für das Pilotprojekt konfrontiert, - ohne Veränderung des Projektumfangs.

Würde sich dann wenigstens inhaltlich die gewünschte Lösung präsentieren, hätte man am Ende zumindest zufriedene Anwender. Doch die anfangs definierten Projektversprechen erweisen sich im Laufe des Projektes als nicht realisierbar.

Auch bei einem international tätigen Anlagenbauer versprach man sich mehr Transparenz in der Auftragsabwicklung und ein entsprechend aussagekräftiges Berichtswesen. Das Unternehmen verpasste allerdings, ein Gesamtkonzept zu entwickeln und die nötigen Organisations- und Prozessveränderungen anzugehen. Stattdessen wurde den Teilprojektteams überlassen, was bottom-up optimiert wird. Die Klammer, welche die Konsistenz hätte sichern sollen, gab es nicht, denn das Projekt wurde an die IT-Abteilung und das Mittelmanagement delegiert.

Jedes Projekt hat seine eigene Geschichte. Gemeinsam ist ihnen, dass sie alle weit hinter den Erwartungen zurückbleiben, zu lange dauern oder zu teuer werden. Analysiert man die gescheiterten Projekte, sind immer wieder dieselben fünf Ursachen beteiligt (siehe Bildergalerie, oben).

Organisations- statt IT-Projekt

Wesentliche und zwingende Voraussetzung für das Gelingen eines ERP-Projekts ist die Einsicht, dass es sich bei einem ERP-Projekt primär nicht um ein IT-, sondern um ein Organisationsprojekt handelt. Doch genau dieses Verständnis fehlt in den meisten Unternehmen. Entsprechend fehlt die systematische Verbindung zwischen der Geschäftsstrategie und dem ERP-System. Die Folge dieses "Missing Link" ist, dass die implementierte Lösung an den spezifischen Geschäftsanforderungen vorbeigeht und lediglich die vorherrschende Betriebskomplexität im System abbildet. Folge davon sind Sachzwänge, welche spätere Systemanpassungen erschweren oder gar Organisationsoptimierungen verunmöglichen. Denn selbst sehr mächtige ERP-Systeme mit beinahe unbegrenzte Funktionalität und Prozessvarianten verlieren durch die frühe Festlegung der sogenannten "Systemorganisation" an Flexibilität.

Zwei Voraussetzungen für den späteren Projekterfolg

Um das zu vermeiden, müssen zwei wesentliche Voraussetzungen geschaffen werden. Diese werden in den ersten beiden Phasen des generischen Vorgehensmodells erarbeitet. Dort wird der Grundstein für die erfolgreiche ERP-Einführung gelegt. Während Phase 1 (Projektinitialisierung) primär die Projektmotivation und -führung thematisiert, adressiert Phase 2 diejenigen Vorgaben, die für die Verbindung von Strategie und ERP-System sorgen. Nur ein systematischer und konsistenter Top-down-Ansatz stellt die konsistente Umsetzung der Geschäftsvorgaben im ERP-System sicher, reduziert die Komplexität und schafft einen positiven "Business Case". Was ab Phase 3 folgt, setzt auf diesen von der Geschäftsleitung erarbeiteten Vorgaben auf und ist professionelles Handwerk jeder ERP- Implementierung.

Voraussetzung 1: Projektinitialisierung durch die Geschäftsleitung (Top-Management)

In der Projektinitialisierungsphase gilt es die Rahmenbedingungen des Projektes zu definieren. Ausgehend vom gemeinsamen Verständnis bezüglich des Handlungsbedarfs und der Projektziele müssen die Erfolgsfaktoren und Risiken des ERP-Projekts identifiziert werden. Dies ist Aufgabe der Geschäftsleitung. Hier muss Einigkeit darüber herrschen, worin der Projektnutzen besteht. Typischerweise wird dieser in einem "Business Case" basierend auf dem Investitionsbudget mit allen internen und externen Aufwänden unter Berücksichtigung der Projektrisiken bewertet. Davon abgeleitet sind dann die Projektrollen und Verantwortlichkeiten, insbesondere auf der Business-Seite verbindlich festzulegen. Dazu gehören auch eine realistische Zeitplanung und vor allem die Benennung der beteiligten Schlüsselpersonen (Projektsponsor in der Geschäftsleitung, Projektleiter mit Business-Hintergrund).

Ohne gemeinsames Verständnis des Topteams im Unternehmen, ohne realistisches Budget und machbaren Zeitplan oder ohne eindeutiges Commitment für die Prioritäten darf das Projekt nicht freigegeben werden. Zu hoch sind die Risiken, beginnend bei den direkten Projektkosten (in der Höhe eines halben Jahresgewinns) oder - nicht zu vergessen - die noch höheren indirekten Kosten wie beispielsweise Geschäftsverluste wegen gestörter Auftragsabwicklung. Infolge der Systemeinführung fehlte bei einem Einzelhändler die margenträchtige Ware im Regal; dafür wurden Saisonartikel zu Ladenhüter.

Voraussetzung 2: Strategische Vorgaben geklärt

Ebenso Aufgabe des Topteams ist es, die strategischen Vorgaben für das ERP-Projekt festzulegen, ggf. zu klären. Mit der Verbindlichkeit von (realistischerweise) 5 Jahren soll das Geschäftskonzept und Geschäftsmodell definiert werden. Denn der verbreitet angestrebte "permanente Wandel" würde nicht nur die Flexibilität des ERP-Systems überfordern, sondern auch dessen Stabilität gefährden. Idealerweise entspräche die Stabilität des Geschäftsmodells der erwarteten Lebensdauer des Systems.

Mit der Klärung der strategischen Vorgaben entsteht auch die Chance, die in der Vergangenheit schleichend entstandenen Geschäftskonzepte zu schärfen, gewachsene Strukturen zu hinterfragen und Weichenstellungen bewusst vorzunehmen. Bei einem global aktiven Komponentenlieferanten stellte sich heraus, dass die nationalen Unter-schiede an Bedeutung verloren hatten. Stattdessen bildeten sich zwei globale Kundensegmente mit komplett unterschiedlichen Geschäftsmodellanforderungen heraus: nämlich ein Projektgeschäft mit hohem kundenspezifischen Lösungsanteil und ein wiederkehrendes Kataloggeschäft mit kundenspezifischer Belieferungslogistik. Kein Wunder, mussten nicht die nationalen Besonderheiten, sondern die beiden Geschäftsmodelle als globale Standards abgebildet werden.

Werkvertrag statt Dienstleistungsvertrag?

Trotz mustergültiger Projektinitialisierung und Klärung der strategischen Vorgaben ist die Verunsicherung nach wie vor groß. Was liegt da näher, als das Projekt an einen starken Implementierungspartner zu delegieren und sich mit einem Werkvertrag abzusichern.

Wäre das ERP-Projekt ein reines IT-Projekt, dann wäre der Werkvertrag tatsächlich eine elegante Lösung gegen explodierende Projektkosten. Allerdings setzt jeder Werkvertrag voraus, dass das "Werk" im Pflichtenheft eindeutig beschrieben ist. Aber gerade daran scheitern viele Unternehmen. Die Prozesse sind oft ungenügend detailliert be-schrieben oder aber die Beschreibungen entsprechen nicht mehr den aktuellen Abläufen und Zuständigkeiten. Dazu fehlt häufig das relevante Systemwissen. So gehören häufig mehr als 95%, in Hunderten von Seiten akribisch beschriebenen Funktionen, zum Standard in den üblichen ERP-Systemen. Wenige, aber geschäftskritische Funktionen sind dagegen als solche nicht bezeichnet oder fehlen in den Ausschreibungstexten ganz.

Aber auch der Implementierungspartner möchte keinen Werkvertrag. Um das Risiko des Werkvertrages zu minimieren, muss er mit Risiko¬zu¬schlägen kalkulieren, um sich vor Änderungen im Pflichtenheft abzu¬sichern. Aber aufgepasst: Je akribischer das Pflichtenheft ist, desto mehr gelingt es dem Implementierungspartner Lücken zu finden. Wie heute schon in der Bauwirtschaft gang und gäbe, optimiert der Implementierungspartner mit "Change Requests" - wie etwa der Bauunternehmer - die im Aus-schreibungswettbewerb verlorene Marge.

Dieses Geschäftsgebaren ist mittlerweile stark in Mode gekommen. Das Klima zwischen Unternehmen und Implementierungsparteien ist meist schon kurz nach Projektbeginn sehr angespannt und durch Misstrauen geprägt. Am Ende ist der Frust riesengroß. Immer häufiger streitet man sich vor Gericht.

Gerade weil dem Unternehmen oftmals die notwendige ERP-Systemkompetenz - zu-mindest bei Projektbeginn - fehlt und sie sich erst im Verlauf des Projekts aufbaut, ist der Werkvertrag eine schlechte Lösung. Denn der Werkvertrag ersetzt die fehlende Kompetenz nicht. Die Lösung muss heißen, (a) die Kompetenz im eigenen Haus aufbauen (Stichwort: ERP-System-Kompetenzzentrum) und (b) sich die zusätzliche Kompetenz auf individueller Basis (Stichwort: Body Shopping) extern beschaffen. Der klassische Dienstleistungsvertrag funktioniert nur, wenn die Projektführung im eigenen Haus bleibt und nicht an den externen Implementierungspartner delegiert wird.

Auch der Komponentenlieferant entschied sich nach dem Abbruch des ersten Projektanlaufs für die In-house-Lösung. Mit dem Aufbau des eigenen Kompetenzzentrum, das er mit ausgewählten Spezialisten eines externen IT-Beraters ergänzte, machte er sich unabhängig.

Häufig fehlt aber im eigenen Haus der Projektleiter, welcher schon über die mehrfache Erfahrung mit ERP-Einführungen verfügt. Aus diesem Grund engagierten sowohl der Komponentenhersteller als auch das Einzelkaufhaus auf mehrjähriger Mandatsbasis einen unabhängigen Top-Projektleiter, welcher je über mehrfache Erfolge mit Implementierungsprojekten nachweisen konnte.

Ähnlich, wie heute die öffentliche Hand einen Bauherrenvertreter für ihre Bauvorhaben engagiert, ist Anheuerung eines senioren und einschlägig erfahrenen Projektleiters (Manager auf Zeit) ein erfolgreicher Ansatz: Er stellt den Projekterfolg sicher, zeichnet auch "Change-Requests" ab und übergibt mit dem Projektabschluss an den IT-Leiter des Unternehmens. Um Interessenskonflikte (z.B. Auslastung des externen Beraters, Beratungsqualität) vorzubeugen, ist die Auswahl dieses Projektleiters entsprechend kritisch und unabhängig vom Implementierungspartner vorzunehmen.

Die Autoren: