Katastrophale Datenmigrationen bei Go-Lives

Von Monika Pletschke am 01. Juli 2015

lost signWas kann bei Go-Lives von SAP Projekten alles schiefgehen?  Meiner Erfahrung nach? Eine ganze Menge!

Eines der weitverbreitetsten Probleme ist Datenqualität. Die Auswirkung von Bad Data kann katastrophale Folgen haben. Hier einige Beispiele aus meinen 16 Jahren als SAP Berater.

Auto-Krüppel

Die Projektverantwortlichen des inzwischen zweieinhalb Jahre laufenden SAP Projekts bei einem der globalen Autohersteller hatten keine andere Wahl, als mit dem geplanten Go-Live fortzufahren.  Obwohl in den 2 Monaten vor Go-Live äußert  viele Prozessänderungen durchgeführt wurden und durch die Umarbeitung viele Baustellen nicht fertig waren, gab es keine Möglichkeit, das Projekt zu verlängern. Die Einführung eines neuen Automodells zur selben Zeit, konnte auf dem Altsystem nicht mehr durchgeführt werden und forcierte den Go-Live. Einer der gröbsten Fehler bei diesem Projekt war die Migration der Inbound-Container. Die Handling Units und Anlieferungen in SAP stimmten mit den aktuellen Inhalten der Container nicht überein. Der Wareneingang wurde so erschwert, dass nach einer Woche das Lager leerlief während sich unplatzierte Paletten stapelten.  Nach etwa 2 Wochen konnten keine kompletten Autos mehr hergestellt werden weil es unmöglich war, Teile aus dem Lager abzurufen. In dieser Branche bezeichnet man Autos, welche die Produktionslinie unfertig verlassen als “Krüppel“.

Go-Live abgebrochen

Bei Template Rollouts wird häufig nach dem Pilotprojekt das Team reduziert. Das war auch bei diesem Projekt der Fall. Als ich knappe 3 Wochen vor Go-Live dem Projekt zugeordnet wurde, bemerkte ich, dass viele der benötigten Daten noch nicht für die Migration berücksichtigt worden waren, weil  dass das viel zu kleine Projektteam so überfordert war.  Es fehlten zum Teil noch Lade- und Extrahierungsprogramme. Am kritischsten war meiner Meinung nach die Migration der Warenbestände. Obwohl die Migrationsprogramme noch rechtzeitig erstellt werden konnten, wurden viele der Daten beim Cutover ungetestet geladen.  Cutover begann am  Freitag Nachmittag und wurde nach ununterbrochener Arbeit des gesamten Projektteams am Sonntag Nachmittag abgebrochen. Der Grund: Die Datenmigration wurde durch die Anzahl der Datenfehler so erschwert, dass sie bis zum Produktionsstart am Montag nicht fertiggestellt werden konnte. Das Projekt musste um einen ganzen Monat verschoben werden.

Lager lahmgelegt

Beim Pilot eines globalen SAP Roll-Out Projekts eines mittelständischen Autozulieferers war die Datenmigration trotz relativ kleiner Datenmengen äußerst schwierig. Die Qualität der gelieferten Daten verbesserte sich trotz wiederholter Load Cycles nur sehr wenig. Die Korrektur der „schlechten“ Datensätze nahm jedes Mal so viel Zeit in Anspruch dass es etwa 4 Wochen dauerte, eine komplette Migration durchzuführen. Der schlimmste Fehler beim finalen Cutover war wohl eine Umstrukturierung des Lagers, eine Woche vor Go-Live. Es war nicht mehr genug Zeit da, die Tausenden Materialstammdaten den neuen Lagerstrukturen anzupassen.  Nach dem Go-Live herrschte im Lager dermaßen Chaos, dass Teile nicht mehr gefunden werden konnten. Nach nächtelanger Arbeit, viel Programmierung und speziell angeheuerten Zeitarbeitern, die bei der  Umlagerung helfen mussten, konnte das Lager erst nach 3 Monaten stabilisiert werden.

Materialbedarfsplanung (MRP) kaputt!

Bei diesem Go-Live schien alles relativ problemfrei abgelaufen zu sein. Nach einem Monat „Intensive Support“  zogen die Berater ab und die Firma lief auf SAP. Drei  Jahre später wurde ich vom CFO beauftragt, zu untersuchen, warum der Inventurbestand sich verdreifacht hatte. Das Lager war zu eng, um alle eingekauften Teile und Rohstoffe zu lagern und trotzdem fehlten in der Produktion wichtige Bestandteile,  die nicht bestellt worden waren. Der Einkaufschef teilte mir mit, dass die Materialprognose in SAP nicht funktioniere, und dass er deshalb seine Bestellungen selber berechnen müsse. Die Grundursache des Inventurproblems lag in verkehrten Werten in den Dispositionssichten am Materialstamm:  Sicherheitsbestände, Losgrößen und Lieferzeiten waren verkehrt gepflegt. Außerdem fehlten Bestellungen im System und unabgeschlossene Fertigungsaufträge, die bereits mehrere Jahre alt waren, reservierten den Rohmaterialbestand. Mit einigen Massenkorrekturen konnten die Daten ausgebessert werden und die Lagerbestände waren nach 3 Monaten schon um ein Drittel reduziert.

Datenmigrationen sind meist aufwendig und komplex. Winshuttle unterstützt Migrationen mit einem Toolset, das die Arbeit der Datenerstellung, Validierung und  Fehlerbehandlung um vieles erleichtert. Excel-basiert, mit einfacher Integration zu SAP, unterstützt es vor allem Facharbeiter, welche zuständig sind, die Daten zu liefern und deren Qualität zu sichern, und falls nötig Massenänderungen vorzunehmen. Mit Winshuttle erübrigen sich aufwendige Ladeprogramme und Spezialisten zum Laden und Fehlerauswerten.