Eine ERP-Migration in einer 20-Personen-Firma ist ein Projekt, das kleiner aussieht, als es ist. Ein Plan über drei Monate endet üblicherweise nach sechs, ein Budget über 80.000 Złoty schließt bei 140, und nach dem Go-live stimmt das Lager um zweistellige Prozentwerte nicht. Nicht weil die Software schlecht ist. Weil niemand die Annahmen geprüft hat, auf denen das ganze Projekt stand.
Letztes Jahr haben wir mit einem 12-Personen-Möbelhersteller gesprochen, der gerade den Wechsel von Subiekt GT auf Comarch Optima abgeschlossen hatte. Vier Monate Migrationsarbeit, zwei Wochen nach dem Produktivstart kam heraus, dass die historischen Lagerbestände um 18% abwichen. Der Grund: im alten System wurde ein Teil der Rohstoffe in laufenden Metern, ein anderer in Quadratmetern geführt, und beim Datenmapping ins neue ERP wurde alles als schlichtes „m" übernommen. Niemand hat das verifiziert, denn „die Daten werden ja automatisch migriert". Zwei Wochen lang verkaufte das Unternehmen Sachen, die es physisch nicht hatte, und lehnte Aufträge für Ware ab, die im Lager lag. Die Bereinigung dauerte sechs Wochen und kostete mehr als die Migration selbst.
Das ist kein exotischer Fall. Das ist eine typische ERP-Migration in einem polnischen KMU, wenn niemand vor dem Kickoff harte Disziplin durchsetzt.
Wo die Probleme herkommen
Die meisten Migrationsprobleme haben eine gemeinsame Wurzel: die Daten im alten System bedeuten nicht das, was du glaubst, dass sie bedeuten. Das Feld „Produktbeschreibung" in einer acht Jahre alten Subiekt-Installation enthält eine Mischung aus Handelsname, Herstellercode, internen Lagernotizen und gelegentlich einer Projektnummer. Das Feld „Kundennotizen" enthält das gesamte Stammeswissen darüber, dass dieser Kunde trotz 30-Tage-Vertrag tatsächlich nach 90 Tagen zahlt. Nichts davon ist irgendwo dokumentiert — es lebt in den Köpfen von drei Personen, die gerade im Urlaub sind.
Das zweite klassische Problem: Anpassungen, an die sich niemand mehr erinnert, warum sie nötig waren. Jedes länger laufende ERP trägt drei bis sieben „seltsame" Dinge mit sich: handgebaute Berichte, modifizierte Druckvorlagen, Excel-Makros, die ERP-Output in etwas übersetzen, das die Buchhalterin versteht. Der neue Anbieter sieht das alles meistens erst, wenn jemand aus der Firma sagt „ach ja, wir brauchen außerdem, dass dieser Bericht zeigt…".
Das dritte: ein Prozess, den die Firma anders abwickelt, als das Standard-ERP ihn abwickelt. Das ist kein technisches, sondern ein organisatorisches Problem. Entweder passt du den Prozess an das System an (und jemand muss akzeptieren, dass der bisherige Weg nicht mehr existiert), oder du passt das System an den Prozess an (und bezahlst dafür nicht nur jetzt, sondern bei jedem Update über die nächsten fünf Jahre).
Ein Plan, der wirklich funktioniert
Ein realistischer ERP-Migrationsplan in einem KMU sieht anders aus als der auf den Folien des Anbieters. Die Dinge, die wirklich darin stehen müssen:
- Dateninventar vor der Migration — nicht „wir exportieren aus Subiekt", sondern: welche Tabelle, wie viele Datensätze, welche Felder, welche Werte stehen tatsächlich drin. Das sind üblicherweise zwei bis drei Wochen Arbeit. Ohne das ist alles, was danach kommt, Raterei.
- Verzeichnis der Anpassungen und Workarounds — erstellt mit den Leuten, die das System wirklich nutzen, nicht mit dem Abteilungsleiter. Den Lageristen zu fragen „zeig mir, was du anders machst als das Handbuch sagt", liefert mehr Informationen als zwei Tage Workshops.
- Datenmapping mit Stichprobenprüfung — migriere zuerst 200 repräsentative Datensätze, prüfe sie von Hand. Erst danach 20.000.
- Parallelbetrieb statt Big Bang — mindestens zwei Wochen nach dem Go-live muss das alte System parallel weiterlaufen, und sei es nur lesend. Sonst hast du keine Möglichkeit zu prüfen, ob etwas auseinandergedriftet ist.
- Disaster-Recovery-Test — vor dem Produktivstart führst du den Test durch: Server fällt aus, wie lange dauert es, den vollen Betrieb wiederherzustellen. Lautet die Antwort „wissen wir nicht", dann gehst du noch nicht live.
Dieser Plan addiert 30–40% zur Zeitlinie, die der Anbieter vorschlägt. Aber er reduziert die „Reparaturzeit nach dem Go-live", die fast immer unterschätzt wird, um 60–80%.
Rote Flaggen bei der Anbieterwahl
Ein paar Dinge, die im Gespräch mit einem Implementierungspartner Warnlampen anschalten sollten:
- Ein Angebot ohne Datenaudit. Wenn dir jemand nach einem einzigen Termin und ohne einen Blick in deine aktuelle Datenbank einen festen Preis nennt, ist das kein Angebot. Das ist eine Eröffnungsofferte, die im Projekt wachsen wird.
- „Datenmigration" als eine Position im Angebot. Sie sollte aufgegliedert sein in: Extraktion, Bereinigung, Mapping, Testladung, Verifikation, Produktivladung. Jedes dieser Wörter ist ein anderer Arbeitsumfang und ein anderer Preis.
- Keine Referenzen in deiner Größenordnung. Ein Anbieter, der Rollouts für 200-Personen-Firmen macht, kann das nicht zwangsläufig auch für eine 25-Personen-Firma. Anderes Team, anderes Budget, anderes Entscheidungstempo. Frag nach einem Kunden ähnlicher Größe, am besten aus deiner Branche.
- Das Versprechen „alles wird wie jetzt, nur besser". Wird es nicht. Manches wird besser, manches schlechter, manches einfach anders. Ein Anbieter, der das nicht klar sagt, verkauft dir eine Ruhe, die nicht existiert.
- Keine „Projekteigentümer"-Rolle auf deiner Seite. Wenn der Anbieter nicht darauf besteht, dass du eine Person mit Entscheidungsbefugnis für mindestens 30% ihrer Arbeitszeit über ein halbes Jahr benennst, weiß er nicht, was er tut. Oder er weiß es und profitiert davon, dass du es nicht weißt.
Was vor dem Go-live zu testen ist
Bevor du die Produktion umschaltest, gehst du fünf Szenarien im neuen System mit echten (oder sehr ähnlichen) Daten durch:
- Vollständiger Verkaufszyklus — von der Bestellung über die Rechnung bis zur Buchung. Mit drei typischen Kunden und einem untypischen (z.B. ausländischer Kunde, Reverse-Charge-MwSt.).
- Vollständiger Einkaufszyklus — Wareneingang, Eingangsrechnung, Verbuchung. Mit besonderem Augenmerk auf Dienstleistungen ohne Lagerbestand.
- Monatsabschluss — im Testmodus. Sagt die Buchhalterin nach der Übung „ich weiß nicht, wie ich das machen soll", dann geht ihr noch nicht live.
- Teilinventur — wähl eine Produktgruppe, zähle physisch, vergleiche mit dem System. Eine Abweichung über 2% bedeutet, die Daten sind noch nicht da, wo sie sein müssen.
- Serverausfall — abschalten, aus dem Backup wiederherstellen, Zeit und Vollständigkeit prüfen. Es ist langweilig, und es ist genau das, was niemand macht und was man hinterher am meisten bereut.
Wie geht es weiter
Eine ERP-Migration ist kein IT-Projekt. Sie ist ein Organisationsprojekt mit einer IT-Komponente. Die meisten Firmen, die in die Spirale „zweite Migration in drei Jahren" geraten sind, haben denselben ersten Fehler gemacht: sie haben das Ganze dem Softwareanbieter überlassen und sind wiedergekommen, als „es fertig war". Diesen Moment gibt es nicht. Eine Migration ist fertig, wenn deine Leute im neuen System ohne Anleitung arbeiten können — und dafür musst du im Prozess drinbleiben.
Wenn du in den kommenden Monaten einen ERP-Wechsel planst oder gerade mitten in einer feststeckenden Implementierung bist — sprich mit uns. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde. Häufig reicht es, um zu zeigen, wo das größte Risiko liegt und was sich noch retten lässt, ohne das ganze Projekt zurückzusetzen.
Eine ERP-Migration ist fertig, wenn deine Leute im neuen System ohne Anleitung arbeiten können — nicht wenn der Anbieter sagt, er sei fertig.