Probleme in der SAP-Einführung: ERP-Projekte auf der Kippe

Best Practice in der ERP-Einführung ist schwer. Welche Sündenfälle Unternehmen vermeiden sollten, zeigen zwei ERP-Projekte, die gehörig schief liefen. [...]

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.


Mehr Artikel

News

Große Sprachmodelle und Data Security: Sicherheitsfragen rund um LLMs

Bei der Entwicklung von Strategien zur Verbesserung der Datensicherheit in KI-Workloads ist es entscheidend, die Perspektive zu ändern und KI als eine Person zu betrachten, die anfällig für Social-Engineering-Angriffe ist. Diese Analogie kann Unternehmen helfen, die Schwachstellen und Bedrohungen, denen KI-Systeme ausgesetzt sind, besser zu verstehen und robustere Sicherheitsmaßnahmen zu entwickeln. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*