Warum die ERP-Migration in die Cloud dein Prozessproblem nicht löst

In jedem ERP-Migrationsmeeting fällt derselbe Satz. "Wenn wir erst in der Cloud sind, wird alles einfacher." Wird es nicht. Die Cloud ändert, wo die Software läuft, nicht wie dein Unternehmen arbeitet.

Wenn eine Bestellung heute durch drei E-Mail-Freigaben, eine separate Excel-Tabelle und einen Telefonanruf läuft, läuft sie danach genauso. Nur eben auf Servern in Frankfurt statt auf einer Maschine im Keller.

Die Cloud ist ein Ort, keine Prozessentscheidung

Eine Cloud-Migration löst echte Probleme. Du verwaltest keine Hardware mehr. Du bekommst verwaltete Backups, elastische Skalierung, Updates ohne Betriebsstopp. Das ist die Investition wert. Aber es ist ein Infrastrukturproblem.

Dein Problem ist fast immer ein anderes. Es ist der Vertriebler, der Kredite aus dem Bauch heraus freigibt. Es ist der Bestand, der vom System abweicht, weil niemand Rücksendungen rechtzeitig erfasst. Es ist der Monatsabschluss, der zwei Wochen dauert, weil die Hälfte der Buchungen in losen Tabellen lebt.

Keine dieser Sachen wird durch einen Serverwechsel besser. Das ERP, ob lokal oder Cloud, ist der Spiegel deiner Prozesse. Ist der Prozess wirr, spiegelt es Wirrnis zurück, nur mit besserer Verfügbarkeit.

Der Fehler der bequemen Ist-Aufnahme

Die typische Migration beginnt mit einer Aufnahme der aktuellen Prozesse. Das erklärte Ziel lautet "abbilden, was wir schon haben". Genau hier stirbt das Projekt, bevor es anfängt.

Abbilden, was du schon hast, heißt Jahrzehnte von Ausnahmen, Abkürzungen und "das war schon immer so" in ein neues, teures System zu gießen. Das Ergebnis ist ein maßgeschneiderter Frankenstein, den danach niemand mehr aktualisieren kann.

Der Fall Lidl ist das meistzitierte öffentliche Beispiel. Der Händler arbeitete jahrelang an einem neuen Warenwirtschaftssystem auf SAP-Basis. Das Projekt wurde 2018 nach Hunderten Millionen Euro abgebrochen. Ein berichteter Grund: Lidl bestand darauf, die Software an sein Bestandsmodell zum Einstandspreis anzupassen, statt den Prozess an den Standard. Die Software bog sich, bis sie brach.

Zwanzig Jahre früher ging Hershey den umgekehrten Weg und scheiterte an der Eile. Das Unternehmen nahm ERP, CRM und Supply-Chain-Management gleichzeitig in Betrieb, kurz vor Halloween, ohne Zeit, die Prozesse zu stabilisieren. Es konnte Bestellungen nicht ausliefern, deren Ware im Lager stand. Die Migration war technisch fertig; der Betrieb stand trotzdem still.

Was du erledigen musst, bevor du die Cloud anfasst

Die richtige Reihenfolge ist unbequem, weil sie am Anfang langsamer ist. Zuerst verstehst du die Prozesse. Dann entscheidest du, welche sich lohnen, welche du streichst und welche du an den Standard der Software anpasst. Erst danach migrierst du.

• Kartiere die echten Prozesse, nicht die im Handbuch. Der echte Prozess ist das, was die Leute freitags um 17 Uhr machen, mit einem wütenden Kunden am Telefon.
• Frag bei jeder maßgeschneiderten Ausnahme nach dem Warum. In der Hälfte der Fälle ist die Antwort eine Regel, die niemand mehr braucht.
• Entscheide, was du an den Standard anpasst. Teure Anpassung heute ist technische Schuld, die dich morgen an einen Anbieter fesselt.
• Bereinige die Daten vor der Migration. Schmutzige Daten in einem neuen System sind schmutzige Daten, Punkt.
• Lege fest, wer Eigentümer jedes Prozesses ist. Ohne Eigentümer verteidigt niemand die Veränderung, wenn das Team sich wehrt.

Der innere Widerstand ist das eigentliche Projekt

Der technische Teil einer Migration ist der berechenbarste. APIs, Integrationen, Cutover-Fenster, dafür gibt es Handbücher. Wofür es keine gibt, sind die Menschen, die den alten Prozess fünfzehn Jahre lang gemacht haben und ihn besser kennen als jeder Berater.

Klassische Studien zum Change-Management sind an diesem Punkt eindeutig. Die meisten Transformationsprogramme scheitern nicht an der Technik. Sie scheitern an Umsetzung, Ausrichtung und der Mitwirkung der Menschen. Die HBR bringt das in der Arbeit von Sirkin, Keenan und Jackson zu den harten Faktoren der Veränderung gut auf den Punkt.

Stell dir das typische Szenario vor: Der Lagerleiter bekommt ein neues System, das ihn zwingt, jede Bewegung sofort zu erfassen, statt am Ende der Schicht. Für ihn bedeutet das neue System mehr Arbeit, nicht weniger. Zeigst du ihm nicht das Warum und passt den Prozess nicht an die Realität auf dem Hallenboden an, kehrt er zur parallelen Excel-Tabelle zurück. Und dein Cloud-ERP wird zu einem toten, teuren Archiv.

Lohnt sich die Cloud also?

Sie lohnt sich. Aber aus den richtigen Gründen. Migriere in die Cloud, um keine Infrastruktur mehr zu verwalten, um Elastizität zu haben und um leichter mit dem Rest deines digitalen Stacks zu integrieren. Migriere nicht in der Hoffnung, dass der Serverwechsel deinen Betrieb neu ordnet.

Die Reihenfolge, die funktioniert, ist leicht gesagt und schwer getan. Bring den Prozess in Ordnung. Bereinige die Daten. Richte die Menschen aus. Dann schalte die Cloud dazu. Wer diese Reihenfolge umdreht, zahlt zweimal: einmal für die Migration und einmal, um sie rückgängig zu machen.

Gute Software repariert keinen schlechten Betrieb. Sie macht ihn nur schneller im Zerbrechen. Die richtige Frage war nie "Cloud oder lokal". Sie war "verdienen unsere Prozesse es, so automatisiert zu werden, wie sie sind?". In den meisten Fällen lautet die ehrliche Antwort nein, und genau da beginnt das Projekt wirklich.