ERP-Einführung: die Phasen im Überblick

Eine ERP-Einführung ist kein Softwareprojekt mit Prozessanteil, sondern ein Prozessprojekt mit Softwareanteil. Diese Reihenfolge erklärt die meisten Verläufe: Wo Prozesse vorher geklärt sind, läuft die Einführung; wo sie im Projekt geklärt werden, wird es teuer.

Phase 1: Prozesse aufnehmen

Aufgenommen wird der Ist-Zustand, nicht der Wunsch. Für jeden Kernprozess gilt: Wer macht was, in welchem System, und wo bricht es. Ein Prozess ist erst beschrieben, wenn die Ausnahmen dabeistehen, denn die kosten im Projekt die Zeit.

Was hier bereits entschieden wird: welche Abläufe übernommen und welche abgeschafft werden. Eine Einführung ist die günstigste Gelegenheit, Umwege loszuwerden. Wer den Ist-Zustand eins zu eins nachbaut, bezahlt Anpassungen, die den Aufwand konservieren.

Phase 2: Zielstruktur festlegen

Jetzt wird bestimmt, wie die Prozesse im System abgebildet werden: welche Module, welche Belegarten, welche Nummernkreise, welche Berechtigungen. Diese Phase entscheidet über den späteren Aufwand stärker als jede andere.

Die wichtigste Frage lautet, was im Standard gelöst wird und was eine Anpassung braucht. Jede Anpassung ist später zu pflegen, deshalb sollte jede einzelne begründet sein.

Phase 3: Einrichtung und Datenmigration

Das System wird konfiguriert, Belege werden angelegt, Schnittstellen entstehen. Parallel läuft die Datenmigration, und die ist der Teil, der regelmäßig unterschätzt wird: Der Aufwand hängt an der Datenqualität, nicht an der Datenmenge.

Eine Testmigration mit echten Daten gehört in diese Phase, nicht in die nächste. Sie deckt auf, was in der Konzeptphase niemand sieht: Dubletten, uneinheitliche Einheiten, fehlende Pflichtfelder. Korrigiert wird danach im Altsystem, nicht im Migrationswerkzeug, sonst wiederholt sich der Fehler.

Phase 4: Test und Schulung

Getestet wird gegen Szenarien aus dem eigenen Alltag, inklusive der Sonderfälle. Ein Test, der nur den Standardablauf prüft, verschiebt die Probleme auf den Go-Live.

Bei der Schulung ist die Unterscheidung zwischen Key-Usern und Endanwendern entscheidend. Key-User brauchen Verständnis für die Zusammenhänge, damit sie im Betrieb Fragen beantworten können. Endanwender brauchen ihren Arbeitsablauf, nicht das Systemhandbuch.

Phase 5: Go-Live und die Wochen danach

Am Go-Live entscheidet die Vorbereitung, nicht die Reaktionsfähigkeit. Wichtig sind ein klarer Stichtag, eine festgelegte Behandlung übergreifender Vorgänge und Leserecht auf das Altsystem für den Zweifelsfall.

Die ersten Wochen gehören zum Projekt und nicht in den Regelbetrieb. In dieser Zeit tauchen die Fälle auf, die im Test nicht vorkamen, und die Feinjustierung passiert genau hier.

Woran Projekte scheitern

• Der Umfang wächst während des Projekts, ohne dass Termin und Budget mitwachsen
• Die Fachbereiche sind nicht eingebunden, die IT entscheidet über Prozesse
• Interne Kapazität wird nicht freigestellt, sondern zusätzlich erwartet
• Es gibt keine Ausgangswerte, also lässt sich hinterher kein Erfolg zeigen
• Die Datenmigration beginnt zu spät