Unternehmen hüllen sich gerne in Schweigen, wenn es um Details solcher "Worst Practices" geht. Dabei sind es genau diese Fälle, die veranschaulichen, welche Fehler tunlichst zu vermeiden sind und wie der Befreiungsschlag aus verfahrenen Situationen gelingen kann. Im Folgenden werden zwei "Bruchlandungen" unter die Lupe genommen, die in realen ERP-Projekten vorgekommen sind.

Fall 1: Handelsunternehmen fährt ERP-Projekt an die Wand

Das erste Beispiel dreht sich um ein europaweit aufgestelltes, mittelständisches Handelsunternehmen mit einem Jahresumsatz von rund 400 Millionen Euro. Es beschäftigt 300 Mitarbeiter in fünf Landesgesellschaften. Ziel des ERP-Projekts war es, mit Ausnahme der Lagersoftware die komplette Logistik in einem Aufwasch auf SAP umzustellen. Zu den wesentlichen Bestandteilen dieser Einführung zählten das Supply-Chain-Management (SCM), Business Intelligence (BI) und Prozessintegration (PI) sowie die Anbindung und der Datenaustausch mit allen Lieferanten und Partner des Unternehmens. Kurzum: Das Projekt tangierte den Herzschlag des Unternehmens, die Handelsaktivität. Folgerichtig stellte der Auftraggeber zunächst ein Team inklusive Projektleiter zusammen.

Ebenso stellten die beiden mit der Implementierung beauftragten SAP-Partner für ERP sowie für die Module BI und PI jeweils einen Projektverantwortlichen ab. Die Ausgangssituation verhieß auf den ersten Blick ein erfolgreiches Unterfangen. Die Planung des ERP-Projekts war minutiös und es gab klar umrissene Projektziele sowie einen festen Zeit- und Budgetrahmen. Alle Jour-fixe-Termine wurden regelmäßig abgehalten.

Software bildet Geschäftsprozesse falsch ab

Der Projektstart erfolgte Anfang 2009. Mit 16 Monaten glaubten alle Projektbeteiligten ausreichend Zeit für die Einführung eingeplant zu haben, um den "Big Bang" sicher erreichen zu können. Bei der Überprüfung erster Kernprozesse stellte man jedoch fest, dass geschäftskritische Prozesse mit der implementierten Software bei Weitem nicht korrekt abgebildet wurden. Infolgedessen musste der "Go-Live-Termin" bereits um sechs Monate verschoben werden. Das kostete sowohl die Dienstleistungspartner als auch das Unternehmen zusätzliches Geld.

Schnittstellenprobleme kosten Geld und Zeit

Der Druck auf das Projekt wuchs, aber auch der zweite Starttermin konnte nicht gehalten werden. Nach einem Jahr Verspätung sah es schließlich so aus, als ob die Zeichen für das neue System endlich auf Grün stünden. Doch es kam anders. Nach der ersten Woche wurden Mängel sichtbar, die von den Mitarbeitern zunächst fatalerweise unterschätzt wurden. Während sich das Projektteam noch mit der Korrektur von Abläufen und Schnittstellenproblemen befasste, entwickelte sich die Lage im Wareneingang und -ausgang immer dramatischer. Obwohl das Lager voll war, bestellte der Einkauf weiter Waren, weil das System den Bestand nicht korrekt abbildete.

Vorhandene Artikel wurden hingegen nicht ausgeliefert, weil sie laut ERP-System nicht vorrätig waren. Andere Artikel wiederum verließen vom System unerkannt das Haus und wurden teilweise nicht fakturiert. Und damit nicht genug: Die Rechnungsstellung verzögerte sich mehr und mehr, die Liquidität im Unternehmen sank. Ein Zurück zum alten System war zu diesem Zeitpunkt nicht mehr möglich. In der Not erfassten Mitarbeiter die Daten teilweise manuell, doch die Nachführung ins System funktionierte nicht durchgängig und korrekt. Das Unternehmen geriet plötzlich in eine kritische Lage.

Diese Fehler wurden gemacht

• Zunächst hatten alle Beteiligten die Projektkomplexität falsch eingeschätzt. Alle beziehungsweise zu viele SAP-Module auf einmal einzuführen ist erfahrungsgemäß ein schwieriges Unterfangen. Der Kunde verließ sich dabei allerdings auf die Aussagen seiner ausgewählten Implementierungspartner - und war verlassen. Ein klassischer Fall von schlechter Beratung.

• Gemessen an der Größe des Projektes war die Personaldecke auf beiden Seiten zu dünn.

• Es gab Ressourcen- und Terminprobleme, die Zeitplanung war unrealistisch.

• Zwischen den beiden unabhängig voneinander arbeitenden Implementierungspartnern gab es Abstimmungs- und Kommunikationsprobleme - der Kunde saß zwischen den Stühlen.

• Die Projektleiter kommunizierten die eskalierende Situation zu spät an den Lenkungsausschuss.

• Durch den Zeitdruck und die ständigen Terminverschiebungen entstand eine enorme Belastung für die Projektmitarbeiter. Sie wurden zum Teil "verheizt". Schritt für Schritt verabschiedeten sich die involvierten Berater wie auch Key User des Kunden nicht nur aus dem Projekt, sondern zum Teil auch aus dem Unternehmen. Damit ging wichtiges Know-how verloren und musste erst wieder mühsam aufgebaut werden - ein Teufelskreis.

• Beide Seiten - Kunde und Implementierungspartner - prüften das System aus Termingründen vor dem "Go Live" nur unzureichend. Stellt man erhebliche Mängel jedoch erst nach einer Live-Schaltung im Betrieb fest, gleicht das einem informationstechnischen Super-Gau.

Ausweg aus der Projektfalle

Im Lauf des Jahres 2011 wandte sich der Vorstandsvorsitzende des Handelsunternehmens an die Gebhardt Sourcing Solutions AG in Böblingen. Der Sourcing-Advisory-Spezialist sollte die Projektsituation begutachten und Hilfestellung in der verfahrenen Situation geben. In ihrer Rolle als Berater und Mediator brachten die Böblinger zunächst einmal alle Beteiligten wieder an einen Tisch. Dann begann die Prüfung und Definition der "Hot Spots". Es wurde geklärt, welche Prozesse die höchste Geschäftsrelevanz haben und wo betriebswirtschaftlich am meisten Geld verloren ging.

In einem ersten wichtigen Schritt wurde ein Release V1 implementiert, das den Geschäftsbetrieb stabilisierte. Parallel dazu entstand Version 2. Die ganz pragmatische Marschroute lautete: Besser ein 80/20-Ansatz beziehungsweise ein Prozess, der vielleicht nicht ganz optimal läuft, aber eingeführt werden kann. Im vorliegenden Fall hätte man sich bereits nach dem ersten "Go-live-Patzer" auf die ERP-Einführung konzentrieren und die Kopplung der Bestandteile BI und PI an das ERP neu takten sollen.

Gleichzeitig wurde die Qualität der Implementierungspartner geprüft und neue Mitarbeiter für das Projekt angefordert. Ein kompletter Wechsel zu anderen Beratungshäusern kam nicht in Frage. Sie hätten neue Templates mitgebracht, mit der Folge, dass eine erneute Anpassung aller bereits erfassten Geschäftsprozesse unvermeidbar gewesen wäre. Zudem hätte sich ein neuer Implementierungspartner kaum auf die ausgehandelten Vertragsbedingungen eingelassen. Auch ein kompletter Wechsel auf ein anderes System stand nicht zur Debatte: Das Unternehmen hatte zu diesem Zeitpunkt bereits zu viel Geld in die SAP-Implementierung gesteckt und den "Point of Return" längst überschritten.

Nur mit großer Anstrengung konnte die Situation Schritt für Schritt bereinigt werden. Die Nachwehen sind bis heute im Unternehmen spürbar. Doch inzwischen läuft der Geschäftsbetrieb so stabil, wie es für die Zeit nach Einführung von SAP Mitte 2010 geplant war.

Fall 2: Falsches Prototyping der SAP-Suite

In diesem Fall handelt es sich um ein großes, europaweit agierendes Handelsunternehmen mit einem Jahresumsatz von zirka zwei Milliarden Euro. Es beschäftigt eine kleine IT-Abteilung, die 1200 SAP-Nutzer betreut. Wie im ersten Beispiel stand auch hier eine umfangreiche Einführung von SAP mit den Modulen ERP, BI/PI, SCM und CRM plus Archivierung auf der Projektagenda. Die Feinkonzeption erfolgte durch einen SAP-Implementierungspartner. Da parallel zum SAP-Projekt der Betrieb der zukünftigen IT-Landschaft ausgeschrieben und verhandelt werden sollte, waren schon zu einem frühen Zeitpunkt verlässliche Aussagen über die Systemleistung erforderlich.

Redesign nach Explosion der Betriebskosten

Im Rahmen eines Prototypings kalkulierte der Implementierungspartner die Systemleistung mit rund 210.000 sogenannten SAP Application Performance Standards (SAPS, siehe Kasten "Das magische Dreieck"). Für rund 4000 SAPS wird ein Dual-Core-Server mit zwei Prozessoren veranschlagt. Die Systemlandschaft wurde also quantifiziert, ausgeschrieben, verhandelt und beauftragt. Doch schon deutlich vor dem "Go Live" kam die unangenehme Überraschung: Der Implementierungspartner scheiterte am Prototyping. SAP griff selbst ein und kalkulierte eine Größenordnung von 1.300.000 SAPS. Die Folge: Der jährliche Aufwand für den externen Betrieb explodierte von ursprünglich 800.000 Euro auf knapp 1,8 Millionen Euro. Was tun? Als Lösung blieb nur, unter großem Zeitdruck ein präzises sowie komplettes Redesign aufzusetzen.

Fehlerursachen und Projektrettung

Der Implementierungspartner konzentrierte sich in diesem Projekt nicht auf das Wesentliche, sondern ließ sich zusätzlich von den Anforderungen der Fachbereiche leiten. Das hatte zur Folge, dass nicht nur der Implementierungsaufwand in die Höhe schnellte, sondern auch die Abläufe und Prozesse komplexer wurden. Das hatte wiederum höhere Betriebskosten zur Konsequenz. Beim Redesign durch SAP lag die Systemleistung gegenüber der ursprünglichen Planung glatt um den Faktor sechs höher. Als Lösung blieb nur, den Grad der Komplexität deutlich zu verringern. Das ERP-Projekt wurde in überschaubare Teilschritte gegliedert. Mit realistischen Anforderungen und neuen Prozessen erarbeitete Gebhardt Sourcing Solutions ein angemessenes Sizing - mit geringeren Betriebskosten.

Server-Virtualisierung und Hosting nach Maß

Um die Kosten weiter zu senken, wurde auch das Betriebskonzept optimiert: Statt klassischer Unix/RISC-Systeme kommen heute virtualisierte Server zum Einsatz. Außerdem wurde mit dem Hosting-Partner ein flexibles und bedarfsorientiertes Wachstum der voraussichtlich benötigten Systemleistung verhandelt. Innerhalb dieser Leitplanken kann sich der Leistungsbedarf flexibel nach oben und nach unten ändern. Bezahlt wird nur der tatsächliche Verbrauch. Benchmarks brachten den Hosting-Partner auf ein marktgerechtes Preisniveau.

Unterm Strich steht die gesamte Implementierung nun auf Grün: Die Systemanforderungen wurden von 1.300.000 auf rund 700.000 SAPS reduziert. Dadurch sanken die jährlichen Betriebskosten von 1,8 Millionen Euro auf rund 950.000 Euro - ein akzeptabler Wert für den Kunden. (pg)