ERP-Einführung Phasen: Von der Planung bis zum erfolgreichen Go-Live

Eine ERP-Einführung ist eines der komplexesten Vorhaben, das ein mittelständisches Unternehmen durchführen kann. Es berührt alle Abteilungen, verändert Arbeitsabläufe und erfordert Investitionen in Technik, Zeit und Menschen. Wer dieses Vorhaben ohne strukturierten Ablauf angeht, verliert schnell die Kontrolle – über Budget, Zeitplan und Qualität.

Die gute Nachricht: Jede erfolgreiche ERP-Einführung folgt einem bewährten Phasenmodell. Dieses Modell ist nicht starr – es lässt sich an die spezifische Situation des Unternehmens anpassen. Aber die grundlegende Abfolge der Phasen ist universell. Sie spiegelt eine logische Reihenfolge wider, in der Erkenntnisse aufeinander aufbauen und Ergebnisse einer Phase die Grundlage für die nächste bilden.

Das Überspringen einzelner Phasen ist der häufigste strukturelle Fehler in ERP-Projekten. Wer die Anforderungsanalyse abkürzt, baut das falsche System. Wer die Konzeptionsphase überspringt, konfiguriert ohne Leitplanken. Wer die Testphase kürzt, geht mit bekannten Fehlern in den Produktivbetrieb. Jede eingesparte Woche in einer frühen Phase kostet Wochen oder Monate in einer späteren.

Die erste Phase ist die Grundlage für alles, was folgt. Hier werden die strategischen Ziele des ERP-Projekts definiert, die bestehenden Geschäftsprozesse aufgenommen und die Anforderungen an das neue System dokumentiert. Diese Phase dauert typischerweise vier bis acht Wochen und ist von intensiver Zusammenarbeit zwischen Projektteam, Fachbereichen und Geschäftsführung geprägt.

Die Ist-Aufnahme der Geschäftsprozesse ist der zeitaufwendigste Teil dieser Phase. In Workshops mit den Fachbereichen werden die aktuellen Abläufe dokumentiert – nicht nur die offiziellen Prozesse, sondern auch die informellen Workarounds, die sich über Jahre eingeschliffen haben. Diese Workarounds sind oft Symptome für Schwächen im bestehenden System und liefern wichtige Hinweise auf die Anforderungen an das neue.

Der häufigste Fehler in dieser Phase ist die Verwechslung von Anforderungsaufnahme mit Wunschliste. Wenn jeder Fachbereich seine Wünsche ungefiltert einbringen kann, entsteht ein Anforderungskatalog, der weder realistisch noch finanzierbar ist. Stattdessen braucht es eine klare Priorisierung: Was ist geschäftskritisch? Was ist wichtig, aber nicht dringend? Was ist Nice-to-have? Diese Priorisierung erfordert Entscheidungen der Geschäftsführung – und die Bereitschaft, Nein zu sagen.

In der Konzeptionsphase werden die Anforderungen in ein konkretes Lösungsdesign übersetzt. Aus den Ist-Prozessen werden Soll-Prozesse, aus Anforderungen werden Systemspezifikationen, aus groben Vorstellungen werden detaillierte Konzepte. Diese Phase ist die intellektuell anspruchsvollste des gesamten Projekts – hier fallen die Entscheidungen, die den Charakter des Systems für Jahre prägen.

Die zentrale Aufgabe ist die Definition der Soll-Prozesse. Dabei geht es nicht darum, die bestehenden Prozesse eins zu eins im neuen System abzubilden. Es geht darum, die Prozesse zu hinterfragen und zu verbessern. Welche Schritte sind wertschöpfend? Welche sind historisch gewachsen und überflüssig? Wo bietet das neue System Möglichkeiten, die bisher nicht gegeben waren? Diese Fragen erfordern ein tiefes Verständnis sowohl der Geschäftsprozesse als auch der Systemmöglichkeiten.

Parallel zur Prozessdefinition werden in der Konzeptionsphase das Berechtigungskonzept, das Migrationskonzept und die Schnittstellenarchitektur erstellt. Jedes dieser Konzepte muss mit den Fachbereichen abgestimmt und formal abgenommen werden. Die Abnahme am Ende der Konzeptionsphase ist ein kritischer Meilenstein: Sie bestätigt, dass das geplante System den Anforderungen entspricht – und bildet die verbindliche Grundlage für die Realisierung.

Der größte Fehler in der Konzeptionsphase ist mangelnde Tiefe. Wenn Konzepte zu oberflächlich bleiben, entstehen in der Realisierung Interpretationsspielräume, die zu Diskussionen, Nacharbeit und Verzögerungen führen. Ein gutes Konzept ist so detailliert, dass es keine Fragen offenlässt – zumindest keine grundlegenden. Der zweite häufige Fehler ist die fehlende Einbindung der Key User: Konzepte, die nur von Beratern und IT erstellt werden, übersehen die Praxis.

Die Realisierungsphase ist die längste Phase des Projekts. Hier wird das Konzept in ein funktionierendes System umgesetzt. Das ERP-System wird konfiguriert, Erweiterungen werden entwickelt, Schnittstellen zu externen Systemen werden implementiert und individuelle Reports und Formulare werden erstellt. Diese Phase dauert typischerweise acht bis sechzehn Wochen und erfordert intensive Zusammenarbeit zwischen dem Implementierungspartner und den Key Usern.

Die Konfiguration des Systems erfolgt auf Basis der Soll-Prozesse aus der Konzeptionsphase. Jeder Prozess wird im System abgebildet, getestet und mit den Key Usern validiert. Dieser iterative Ansatz – konfigurieren, zeigen, Feedback einholen, anpassen – ist entscheidend für die Qualität des Ergebnisses. Er stellt sicher, dass das System nicht nur theoretisch funktioniert, sondern auch in der Praxis den Anforderungen entspricht.

Der häufigste Fehler in der Realisierungsphase ist Scope Creep: Während der Konfiguration fallen den Key Usern zusätzliche Anforderungen ein, die im Konzept nicht vorgesehen waren. Jede dieser Änderungen klingt einzeln vernünftig, aber in Summe verschieben sie den Zeitplan und erhöhen die Kosten erheblich. Ein klares Change-Request-Verfahren ist unerlässlich: Jede Änderung wird dokumentiert, bewertet und formal genehmigt oder abgelehnt.

Die Testphase ist die Qualitätssicherung des gesamten Projekts. Hier wird systematisch geprüft, ob das konfigurierte System die definierten Anforderungen erfüllt. Das umfasst verschiedene Teststufen: Unit-Tests einzelner Funktionen, Integrationstests über Prozessgrenzen hinweg und End-to-End-Tests kompletter Geschäftsprozesse mit realistischen Daten. Diese Phase dauert typischerweise vier bis acht Wochen.

Die End-to-End-Tests sind der wichtigste Bestandteil der Testphase. Hier durchlaufen die Key User komplette Geschäftsprozesse – vom Kundenauftrag über die Kommissionierung bis zur Fakturierung und Zahlung. Diese Tests decken Probleme auf, die in Unit-Tests unsichtbar bleiben: fehlende Verknüpfungen zwischen Modulen, inkonsistente Datenflüsse, unerwartete Systemreaktionen bei Sonderfällen.

Ein oft vernachlässigter Aspekt der Testphase ist der Performancetest. Wie verhält sich das System unter Last? Wie schnell werden Auswertungen mit realistischen Datenmengen erstellt? Wie reagieren Schnittstellen bei hohem Transaktionsvolumen? Diese Fragen lassen sich nur beantworten, wenn das System mit realistischen Datenmengen und Nutzerzahlen getestet wird – nicht mit einem Minidatensatz.

Der gravierendste Fehler ist die Verkürzung der Testphase unter Zeitdruck. Wenn das Projekt in Verzug gerät, ist die Testphase oft die erste, die gekürzt wird. Das ist fatal, denn unentdeckte Fehler potenzieren sich im Produktivbetrieb. Ein Fehler, der im Test eine Stunde Korrekturaufwand bedeutet, kann im Produktivbetrieb Tage kosten und reale Geschäftsprozesse blockieren.

Die Migrationsphase ist die kritischste Phase des gesamten Projekts. Hier werden die Daten aus dem Altsystem in das neue System übernommen, die Schnittstellen umgeschaltet und das System für den Produktivbetrieb freigegeben. Der eigentliche Cutover – der Übergang vom alten zum neuen System – dauert typischerweise ein bis drei Tage und findet oft an einem Wochenende statt, um die Auswirkungen auf das Tagesgeschäft zu minimieren.

Die Vorbereitung auf den Go-Live beginnt jedoch Wochen vorher. Stammdaten werden vorab migriert und validiert. Testmigrationen der Bewegungsdaten werden durchgeführt, um den Zeitbedarf und die Datenqualität zu prüfen. Ein Dry Run – eine Generalprobe des gesamten Cutover-Ablaufs – zeigt, ob der Zeitplan realistisch ist und ob alle Beteiligten ihre Aufgaben kennen.

Ein oft unterschätzter Aspekt des Go-Live ist die Kommunikation. Mitarbeiter, Kunden, Lieferanten und Partner müssen informiert werden – über den Zeitpunkt der Umstellung, über mögliche Einschränkungen während der Übergangsphase und über Ansprechpartner bei Problemen. Ein Kommunikationsplan für den Go-Live-Zeitraum ist keine optionale Ergänzung, sondern eine operative Notwendigkeit.

Der häufigste Fehler ist ein Go-Live ohne Dry Run. Ohne Generalprobe ist jede Zeitplanung Spekulation. Unternehmen, die auf den Dry Run verzichten, erleben am Go-Live-Wochenende regelmäßig Überraschungen: Migrationen dauern länger als erwartet, Schnittstellen funktionieren nicht, Berechtigungen fehlen. All das lässt sich durch einen Dry Run zwei bis vier Wochen vor dem Go-Live vermeiden.

Der Go-Live ist nicht das Ende des Projekts – er ist der Beginn der kritischsten Betriebsphase. In den ersten vier bis acht Wochen nach dem Go-Live treten die Probleme auf, die trotz guter Testarbeit nicht vorhergesehen wurden: Sonderfälle, die in keinem Testszenario vorkamen, Benutzer, die mit dem neuen System nicht zurechtkommen, Prozesse, die unter Reallast anders funktionieren als im Test.

Die Hypercare-Phase erfordert ein dediziertes Team aus internen und externen Experten, das schnell auf Probleme reagieren kann. Tägliche Stand-ups in den ersten zwei Wochen helfen, Probleme frühzeitig zu identifizieren und zu priorisieren. Ein klar definierter Eskalationsprozess stellt sicher, dass kritische Themen sofort adressiert werden und nicht in der Masse der Anfragen untergehen.

Die Optimierungsphase beginnt, sobald das System stabil läuft. Hier geht es darum, die Prozesse im neuen System zu verfeinern, Nachschulungen für Bereiche durchzuführen, die noch Schwierigkeiten haben, und die Systemkonfiguration auf Basis der Erfahrungen aus dem Produktivbetrieb anzupassen. Diese Phase markiert den Übergang von der Projektorganisation in die Linienorganisation.

Der häufigste Fehler ist das zu frühe Auflösen des Projektteams. Wenn Key User und Berater nach dem Go-Live sofort in andere Aufgaben zurückkehren, fehlt die Kapazität für die Problemlösung in der kritischsten Betriebsphase. Die Hypercare-Phase muss im Projektplan eingeplant und mit Ressourcen hinterlegt sein – sie ist nicht optional, sondern integraler Bestandteil einer erfolgreichen Einführung.

Die Besetzung des Projektteams verändert sich im Laufe der Phasen. In der Anforderungsanalyse stehen die Fachbereiche und die Geschäftsführung im Mittelpunkt. In der Konzeptionsphase arbeiten Fachexperten, Key User und Berater eng zusammen. In der Realisierung dominieren die technischen Spezialisten und die Key User als Sparringspartner. In der Testphase kehren die Fachbereiche zurück, um das System aus ihrer Perspektive zu validieren.

Eine Rolle zieht sich durch alle Phasen: die des Projektleiters. Der Projektleiter ist der rote Faden des Projekts. Er koordiniert die Beteiligten, überwacht den Fortschritt, eskaliert Probleme und stellt sicher, dass die Ergebnisse jeder Phase die Qualität haben, die für die nächste Phase erforderlich ist. Ein erfahrener Projektleiter ist der wichtigste Einzelfaktor für den Projekterfolg.

Die Übergänge zwischen den Phasen sind die wichtigsten Kontrollpunkte des Projekts. An jedem Phasenübergang sollte eine formale Prüfung stattfinden: Sind die Ergebnisse der abgeschlossenen Phase vollständig und in ausreichender Qualität? Sind die Voraussetzungen für die nächste Phase erfüllt? Gibt es offene Risiken, die vor dem Weitergehen adressiert werden müssen?

Diese Go/No-Go-Entscheidungen an den Phasenübergängen sind keine Formalität. Sie sind Qualitätstore, die verhindern, dass Probleme aus einer Phase in die nächste verschleppt werden. Ein Konzept, das nicht abgenommen ist, darf nicht die Grundlage für die Realisierung sein. Ein System, das die Integrationstests nicht bestanden hat, darf nicht in den Produktivbetrieb gehen. Die Disziplin, diese Tore ernst zu nehmen, unterscheidet erfolgreiche von gescheiterten Projekten.

Neben den sechs Kernphasen gibt es Aktivitäten, die das gesamte Projekt begleiten und keiner einzelnen Phase zugeordnet werden können. Die wichtigsten sind: Projektmanagement mit laufendem Controlling, Risikomanagement und Stakeholder-Kommunikation; Change Management mit kontinuierlicher Kommunikation, Schulungsplanung und Widerstandsmanagement; Qualitätsmanagement mit durchgängiger Dokumentation und regelmäßigen Reviews.

Diese parallelen Aktivitäten werden häufig unterschätzt, weil sie keine spektakulären Ergebnisse produzieren. Aber sie sind das Bindegewebe des Projekts. Ohne laufendes Projektmanagement driften Aufgaben auseinander. Ohne Change Management wächst der Widerstand im Stillen. Ohne Qualitätsmanagement entstehen technische Schulden, die nach dem Go-Live teuer bezahlt werden.

Die klassische Phasenstruktur steht nicht im Widerspruch zu agilen Methoden. Im Gegenteil: Innerhalb der einzelnen Phasen lassen sich agile Elemente sinnvoll einsetzen. Kurze Iterationszyklen in der Realisierung, regelmäßige Demos für die Fachbereiche, tägliche Stand-ups im Projektteam – all das erhöht die Transparenz und verkürzt Feedback-Schleifen.

Was dabei wichtig ist: Die übergeordnete Phasenstruktur bleibt erhalten. Ein Sprint in der Realisierung ersetzt nicht die Konzeptionsphase. Agile Methoden beschleunigen die Arbeit innerhalb der Phasen, aber sie ersetzen nicht die Logik der Phasenabfolge. Die Kombination aus strukturiertem Phasenmodell und agilen Arbeitsmethoden hat sich in der Praxis als der effektivste Ansatz für mittelständische ERP-Projekte erwiesen.

Die sechs Phasen der ERP-Einführung sind kein bürokratisches Korsett. Sie sind ein Rahmen, der Orientierung gibt, Risiken reduziert und sicherstellt, dass nichts Wesentliches vergessen wird. Innerhalb dieses Rahmens gibt es Spielraum für individuelle Anpassungen, agile Methoden und kreative Lösungen.

Unternehmen, die sich an die Phasenstruktur halten, erreichen ihre Projektziele deutlich häufiger als solche, die Phasen überspringen oder abkürzen. Das liegt nicht daran, dass die Phasen magisch sind – sondern daran, dass sie eine Disziplin erzwingen, die in komplexen Projekten überlebenswichtig ist: die Disziplin, erst zu denken, dann zu handeln, und die eigene Arbeit zu prüfen, bevor man weitermacht.

Teilweise, ja. Bestimmte Aktivitäten können überlappen – zum Beispiel kann die Konfiguration der ersten Module beginnen, während die Konzeption der letzten Module noch läuft. Auch Change-Management-Aktivitäten laufen parallel zu allen Phasen. Allerdings gibt es harte Abhängigkeiten: Die Konzeption muss abgeschlossen sein, bevor die Realisierung für den betreffenden Bereich beginnt. Und die Testphase kann erst starten, wenn die Realisierung abgeschlossen ist. Das Überlappen von Phasen kann Zeit sparen, erfordert aber eine sorgfältige Koordination.

Jede Phase ist wichtig, aber die Konzeptionsphase hat den größten Hebeleffekt auf das Gesamtergebnis. In der Konzeption werden die Weichen gestellt, die den Charakter des Systems für Jahre bestimmen. Fehler in der Konzeption – unvollständige Soll-Prozesse, falsche Architekturentscheidungen, vergessene Schnittstellen – potenzieren sich in jeder folgenden Phase. Wer in der Konzeption gründlich arbeitet, spart in der Realisierung, im Test und nach dem Go-Live erheblich Zeit und Geld.

Typischerweise vier bis acht Wochen, wobei die Intensität schrittweise abnimmt. In den ersten zwei Wochen ist eine tägliche Abstimmung und sofortige Problembehandlung erforderlich. Ab Woche drei bis vier reduziert sich der Aufwand, wenn die kritischsten Themen gelöst sind. Der Übergang zum Regelbetrieb sollte an klaren Stabilisierungskriterien festgemacht werden – nicht an einem fixen Datum. Typische Kriterien sind: keine kritischen offenen Fehler, alle Kernprozesse laufen stabil, Key User arbeiten selbstständig im System.