ERP-Einführung: vom ersten Prozess zur Abnahme.

„Wir brauchen ein neues ERP“ beschreibt eine Lösung, aber noch kein betriebliches Ziel. Benennen Sie, wo Informationen verloren gehen, Aufgaben liegen bleiben oder dieselben Daten mehrfach eingegeben werden. Halten Sie fest, wer davon betroffen ist und woran eine Verbesserung später erkennbar wäre.

Ein illustratives Beispiel: Ein Dienstleister möchte verhindern, dass ein bestätigter Auftrag ohne zuständige Projektleitung bleibt. Das Ziel ist ein nachvollziehbarer Übergang vom Auftrag zur Projektbearbeitung. Als Prüfkriterium eignet sich, ob jeder freigegebene Auftrag eine verantwortliche Person und einen nächsten Arbeitsschritt erhält. Daraus folgen konkrete Anforderungen an Daten, Rollen und Statuswechsel.

Erfassen Sie den Ausgangszustand, bevor Sie Funktionen auswählen. Bearbeitungszeiten, Rückfragen und manuelle Übergaben können später beim Vergleich helfen. Eine Zielgröße braucht jedoch eine eigene Ausgangsmessung; pauschale Effizienzversprechen ersetzen sie nicht.

Wählen Sie einen Vorgang, der ein nutzbares Ergebnis erreicht. Eine isolierte Eingabemaske ist noch kein produktiver Prozess. Im Beispiel gehören die Auftragsdaten, die Zuweisung, die Berechtigung zur Übernahme und die sichtbare nächste Aufgabe zusammen.

Trennen Sie notwendige Funktionen von späteren Erweiterungen. Notwendig ist, was den vereinbarten Vorgang durchführbar macht oder einen unvertretbaren Fehler verhindert. Ein zusätzlicher Bericht kann warten, wenn das Team seine Arbeit auch ohne ihn steuern kann. Ein fehlender Zugriffsschutz lässt sich dagegen nicht durch einen schönen Bericht ausgleichen.

Beschreiben Sie auch Ausnahmen: Was passiert bei einem unvollständigen Auftrag, einer Vertretung oder einer nachträglichen Änderung? Diese Fälle gehören in die Abnahme, wenn sie für den Start relevant sind. Neue Wünsche erhalten eine eigene Bewertung mit Nutzen, Aufwand und Auswirkung auf den vereinbarten Umfang.

Wenn die Abläufe noch nicht zu einer vorhandenen Lösung passen, erläutert die Seite zur individuellen ERP-Entwicklung, welche Fragen bei der Abgrenzung eines ersten Systems helfen.

Lassen Sie mögliche Systeme Ihren eigenen Beispielvorgang zeigen. Prüfen Sie dabei dieselben Rollen, Daten und Ausnahmen. Dokumentieren Sie, was bereits funktioniert, was konfiguriert wird und was zusätzliche Entwicklung benötigt. So vergleichen Sie Arbeitsfähigkeit statt Präsentationen.

Das Lastenheft beschreibt Ihre Anforderungen. Die gemeinsame Umsetzungsspezifikation hält anschließend fest, wie der gewählte Anbieter sie erfüllen soll. Entscheidend ist, dass beide Seiten denselben Ablauf und dieselben Abnahmekriterien verstehen; die Dokumente sollten nicht nur Funktionen aufzählen.

Für den Wechsel gibt es mehrere Möglichkeiten. Bei einer gemeinsamen Umstellung wechseln alle betroffenen Bereiche zu einem Stichtag. Eine stufenweise Einführung kann nach Prozess, Standort oder Nutzergruppe erfolgen. Ein Pilot prüft zunächst einen begrenzten Einsatz. Welche Variante passt, hängt unter anderem davon ab, ob Übergaben zwischen altem und neuem System vorübergehend zuverlässig funktionieren können. SAP beschreibt diese unterschiedlichen Einführungsstrategien ebenfalls; daraus folgt keine allgemeine Überlegenheit eines Modells. Quelle: SAP, Strategien für die ERP-Implementierung.

Bei einer Einführung in Etappen brauchen Sie ausdrücklich eine Regel, welches System in jeder Etappe für welche Daten führend ist. Sonst kann der kleinere Startumfang zusätzliche Abstimmungsarbeit erzeugen.

Datenverantwortliche und Datenqualität

Erstellen Sie ein Verzeichnis der benötigten Daten: Quelle, zuständige Person, relevante Felder und gewünschter Zielzustand. Trennen Sie Stammdaten wie Kunden und Leistungen von offenen Vorgängen und historischen Informationen. Nicht alles muss in gleicher Form ins neue System umziehen. Entscheiden Sie fachlich, welche Daten für die Arbeit benötigt werden und wie weiterhin erforderliche Historie zugänglich bleibt.

Prüfen Sie früh einen repräsentativen Export. Finden Sie Dubletten, fehlende Pflichtangaben oder uneinheitliche Nummern, legen Sie eine Bereinigungsregel und einen Verantwortlichen fest. Die technische Projektseite kann fehlerhafte Daten erkennen; was fachlich richtig ist, muss das Unternehmen entscheiden.

Testmigration und Änderungen bis zum Wechsel

Ein erfolgreicher Import meldet zunächst nur, dass die Übernahme technisch gelaufen ist. Prüfen Sie zusätzlich, ob Beziehungen, Werte und offene Vorgänge im Zielsystem stimmen. Vereinbaren Sie Kontrollsummen oder andere fachlich passende Abgleiche und untersuchen Sie Abweichungen.

Während der Vorbereitung entstehen im Altsystem weitere Daten. Halten Sie fest, wann die Bearbeitung dort endet und wie Änderungen seit dem Probeexport übernommen werden. Der Ablauf für den eigentlichen Wechsel sollte vorher getestet werden. Microsoft nennt wiederholte Migrationsproben und fachliche Freigaben ausdrücklich als Teil der Startvorbereitung. Quelle: Microsoft, Datenmigration und Go-live-Checkliste.

Die folgende Reihenfolge verbindet Datenqualität mit der Entscheidung über den Start. Jeder Schritt braucht ein überprüfbares Ergebnis.

1. Daten auswählen. Quellen, Umfang und Verantwortliche bestätigen.
2. Probeübernahme durchführen. Zuordnung und Bereinigungsregeln anwenden.
3. Fachlich abgleichen. Fehler dokumentieren, korrigieren und erneut prüfen.
4. Wechsel proben. Datenänderungen, Zeitfenster und Abbruchentscheidung berücksichtigen.
5. Produktivstart freigeben. Nur mit bestätigten Prüfungen und erreichbarer Betreuung starten.

Bei Schnittstellen sollten Sie nicht nur die erfolgreiche Übertragung prüfen. Testen Sie auch, wie fehlgeschlagene Übertragungen sichtbar werden, wer sie bearbeitet und wie eine Wiederholung ohne unbeabsichtigte Dubletten gelingt. Halten Sie Testzugänge und Ansprechpartner der beteiligten Anbieter fest.

Für Datenmapping, Testläufe und den Abgleich offener Vorgänge enthält der Leitfaden zur ERP-Migration eine eigene Arbeitsvorlage.

Benennen Sie für jede Entscheidung eine verantwortliche Person mit Vertretung. Die Projektleitung organisiert Termine und Abhängigkeiten. Fachverantwortliche entscheiden über Abläufe und Daten. Die technische Seite verantwortet Umsetzung und technische Prüfungen. Die Geschäftsleitung klärt Prioritäten, Budget und Konflikte, die das Projektteam nicht selbst lösen kann.

Binden Sie spätere Nutzer früh ein. Sie sollten die wichtigen Vorgänge mit den vorgesehenen Rechten selbst ausführen. Ein erfolgreicher Test unter einem Administratorkonto zeigt noch nicht, ob der Alltag für die tatsächlichen Rollen funktioniert.

Die Matrix dient als Vorlage für Ihr Projekt. Tragen Sie konkrete Namen und die vereinbarten Freigabetermine ein.

Bereich	Fachlich verantwortlich	Nachweis zur Freigabe
Arbeitsablauf	Prozessverantwortliche	Normal- und Ausnahmefälle erfolgreich getestet
Daten	Datenverantwortliche	Übernahme und Abweichungen fachlich geprüft
Zugriff & Anbindung	IT mit Fachbereich	Rollen und Schnittstellen samt Fehlerfällen getestet
Team & Betreuung	Fachbereich mit Support	Aufgaben geübt, Hilfeweg und Zuständigkeit bekannt
Startentscheidung	Benannte Entscheidungsinstanz	Offene Risiken bewertet, Freigabe dokumentiert

Ein offener Punkt braucht eine Beschreibung, eine zuständige Person und eine Entscheidung: vor dem Start lösen, mit akzeptierter Einschränkung starten oder den Start verschieben. Vermeiden Sie eine pauschale Freigabe, hinter der kritische Probleme unsichtbar bleiben.

Prüfen Sie die Betriebsbereitschaft anhand des vereinbarten Umfangs. Funktionieren die wichtigen Abläufe mit den vorgesehenen Daten, Nutzern und Anbindungen? Sind die notwendigen Tests dokumentiert? Weiß das Team, wie es Fehler meldet und wer nach dem Start erreichbar ist?

Vereinbaren Sie außerdem einen Rückfallweg für den Wechsel: Wer darf den Start abbrechen, bis wann ist das möglich und wie wird weitergearbeitet? Besonders wichtig ist, was mit Daten geschieht, die bereits im neuen System entstanden sind. Ein Backup allein beantwortet diese organisatorischen Fragen nicht. Das Vorgehen muss zu Ihren Systemen und zum Zeitpunkt der Umstellung passen.

Schulung sollte vor dem produktiven Einsatz stattfinden. Lassen Sie Nutzer typische Aufgaben selbst lösen und erfassen Sie dabei Verständnisprobleme. Diese Rückmeldung hilft, zwischen einem technischen Fehler, einem unklaren Ablauf und zusätzlichem Schulungsbedarf zu unterscheiden.

Leiten Sie Termine aus Arbeitspaketen, Abhängigkeiten und verfügbarer Kapazität ab. Wenn eine Fachentscheidung oder ein Testzugang fehlt, kann zusätzliche Entwicklungszeit diese Voraussetzung nicht ersetzen. Reservieren Sie deshalb Zeiten für Entscheidungen, Datenprüfung und Abnahme genauso verbindlich wie technische Umsetzungstermine.

Eine kleinere erste Version kann den ersten produktiven Einsatz näherbringen. Sie verkürzt aber nicht automatisch die gesamte Einführung. Zusätzliche Etappen benötigen ebenfalls Tests, Übergaben und Betreuung. Ein realistischer Plan benennt deshalb das Ende des ersten nutzbaren Umfangs getrennt vom weiteren Ausbau.

Für die finanzielle Planung sollten Sie Anbieterleistungen und internen Einsatz gemeinsam betrachten. Der Leitfaden zu den ERP-Kosten zeigt, wie Sie Einführung und Betrieb vergleichbar erfassen.

Planen Sie für die erste Betriebsphase erreichbare Ansprechpartner und einen klaren Weg für Fehlermeldungen. Trennen Sie Störungen des vereinbarten Umfangs von neuen Wünschen. Sonst konkurriert die Stabilisierung des Betriebs mit Funktionen, die für den Start nicht erforderlich waren.

Prüfen Sie anschließend die ursprünglich festgelegten Ziele. Funktioniert die Auftragsübergabe? Werden die benötigten Daten gepflegt? Welche manuellen Schritte bleiben übrig? Priorisieren Sie Erweiterungen anhand dieser Beobachtungen und prüfen Sie ihre Auswirkungen auf bereits genutzte Abläufe.

Damit endet die Einführung eines abgegrenzten Umfangs mit einer nachvollziehbaren Übergabe. Die weitere Entwicklung beginnt auf einer geprüften Grundlage und mit einer eigenen Entscheidung über Nutzen, Aufwand und Zuständigkeit.