ERP-Einführung im Mittelstand: Leitfaden für klare Systemgrenzen

Wenn Auftragsstände, Lagerbewegungen und Rechnungen in E-Mails, Ordnern und getrennten Programmen liegen, wird jede Auskunft zur Sucharbeit. Ein ERP-System führt diese Vorgänge und ihre Daten in einem System zusammen. Eine ERP-Einführung kann damit Bearbeitungsschritte und Statusabfragen vereinfachen. Eine schlecht organisierte Einführung birgt jedoch reale Gefahren: Budgetüberschreitungen und Verzögerungen können das gesamte Projekt zum Kippen bringen. Dieser Leitfaden zeigt, wie Sie Ihr ERP-System schrittweise einführen und das Risiko von Fehlplanungen begrenzen.

Update 2026: Was gleich geblieben ist und was sich geändert hat

Dieser Leitfaden stammt aus unserer ERP-Projektpraxis, zuletzt der Einführung von Microsoft Dynamics 365 Business Central mit einem eigenen CPQ-Konfigurator im Sondermaschinenbau (zur Fallstudie). Die Grundsätze gelten unverändert: klare Verantwortung im Projektteam, ein begrenzter erster Umfang, Stammdatenbereinigung, Schulung vor dem Go-live und Tests mit echten Vorgängen.

Geändert hat sich seit der Erstveröffentlichung 2024 die Antwort auf eine zentrale Frage: Passen Sie den Prozess an das System an oder das System an den Prozess? Damals rieten wir, Anpassungen möglichst zu vermeiden. Heute verläuft die Grenze anders. KI-gestützte Entwicklung hat die Kosten eigener Erweiterungen deutlich gesenkt – günstiger werden vor allem die ersten Versionen; Betrieb, Wartung und Review bleiben echter Aufwand. Für Standardprozesse bleibt der Standard die richtige Wahl. Wo ein Ablauf Ihr Geschäft unterscheidet, ist eine gezielte, sauber gebaute Erweiterung heute oft der bessere Weg als ein verbogener Prozess. Wie Sie diese Grenze ziehen, zeigt Individualsoftware vs. Standardsoftware.

Auch die Anforderungsphase hat sich verschoben: Ein Prototyp des kritischen Prozesses ist heute oft schneller gebaut als ein vollständiges Lastenheft geschrieben – und zeigt am echten Ablauf, was das System können muss. Der Rest dieses Leitfadens beschreibt die Projektstruktur, die sich in unserer Praxis bewährt hat.

ERP-Projektstruktur

1. Projektplanung
2. Systemkonfiguration
3. Anpassungsprogrammierung
4. Datenmigration
5. Schulung
6. Abnahmetests
7. Inbetriebnahme

Gehen wir jeden dieser Schritte durch.

Projektplanung

Definition des Projektumfangs

Geschäftsführer denken über eine ERP-Einführung nach, wenn Auftragsstände, Bestände oder offene Rechnungen nur durch Rückfragen zu klären sind. Mitarbeiter durchsuchen dafür E-Mails, Ordner und getrennte Programme. Ein ERP-System kann die zugehörigen Vorgänge und Zahlen an einer Stelle verbinden. Klar definierte Schritte in Einkauf, Fertigung, Logistik, Vertrieb oder Buchhaltung lassen sich darin automatisieren.

Das Problem: Viele Unternehmen übernehmen sich in Anbetracht der umfassenden Möglichkeiten. Sie wünschen, dass alle Prozesse bei der Projektplanung berücksichtigt wurden. Das Ergebnis ist ein überambitionierter Plan, mit dessen Umsetzung sich das Unternehmen übernimmt. Die erforderliche Abstimmung zwischen Abteilungen lähmt das Projekt bereits bevor es losgeht, und bringt hohe interne und externe Beratungskosten mit sich.

Wir raten davon ab, gleich im ersten Schritt alle Prozesse anzugehen. Ein großer Umfang bei der Erstimplementierung erschwert die Planung und Abstimmung. Dies wiederum führt zu zeitlichen Verzögerungen und Budgetüberschreitungen. Stattdessen schlagen wir ein graduelles Vorgehen vor, das nur wenige Prozesse bei der Erstimplementierung abbildet. So wird die Implementierung planbarer und leichter umzusetzen. Sobald das System erfolgreich in Betrieb ist, können zusätzliche Funktionalitäten implementiert werden. Auch diese sind oft leichter einzuführen, da das Team bereits Erfahrung mit der Software gesammelt hat.

Wenn der Umfang des Projekts klar beschrieben ist, wird das Projektteam zusammengestellt.

Projektteam

Das Projektteam ist ein entscheidender Erfolgsfaktor für Ihre ERP-Einführung, wichtiger noch als die Softwarefunktionalitäten. Es sollte aus vier Komponenten bestehen: (1) Executive Sponsor, (2) Projektleiter, (3) Vertreter der relevanten Fachabteilungen, (4) ERP-Einführungspartner.

Executive Sponsor

Der Executive Sponsor stellt sicher, dass das Projektteam über die benötigten Ressourcen verfügt. Eine ERP-Einführung bindet Zeit von erfahrenen Mitarbeitern. Diese Zeit steht nicht für deren übliches Tagesgeschäft zur Verfügung. Der Sponsor klärt diesen Zielkonflikt, genehmigt das Projektbudget und trifft sich regelmäßig mit dem Projektleiter, damit Entscheidungen nicht liegen bleiben.

Projektleiter

Der Projektleiter führt das Projektteam und bereitet Entscheidungsvorschläge für den Executive Sponsor vor. Er pflegt den Projektplan, überwacht den Fortschritt und kommuniziert Engpässe. Er muss das Team motivieren, neben ihrem üblichen Tagesgeschäft Zeit für das Projekt zu schaffen. Um dies zu schaffen, muss der Projektleiter innerhalb des Unternehmens gut akzeptiert sein.

Funktionale Leiter / Abteilungsvertreter

Das Projektteam braucht Abteilungsleiter oder Spezialisten für die Abläufe, die künftig im ERP-System laufen. Diese Vertreter arbeiten zusammen. Selbst eine Bestellung kann Einkauf, Logistik und Buchhaltung betreffen, je nach Betrieb auch Produktion oder Vertrieb. Entscheidend ist, dass sie die realen Vorgänge kennen und genug Zeit für Rückfragen, Entscheidungen und Tests erhalten. Wer nur nach freier Kapazität ausgewählt wird, kann Regeln und Ausnahmen aus dem Tagesgeschäft oft nicht verlässlich klären.

Implementierungspartner

Ein erfahrener Einführungspartner übersetzt die Geschäftsabläufe in die Möglichkeiten des gewählten ERP-Systems. Er sollte zeigen können, welche Anforderungen durch Konfiguration abgedeckt werden, wo eine Erweiterung nötig ist und welche Integrationen Folgekosten erzeugen. Dieses Systemwissen verhindert, dass das Projekt vorhandene Standardfunktionen neu entwickelt oder wichtige Grenzen erst beim Test entdeckt.

Geschäftsprozesse definieren

Sie müssen vor dem ersten Gespräch kein vollständiges Prozesshandbuch schreiben. Bringen Sie für jeden Schlüsselprozess einen echten Vorgang mit, etwa eine Bestellung mit einer Lieferausnahme, und erklären Sie, wie er heute abläuft. Wir stellen die Rückfragen zu Regeln, Ausnahmen, Freigaben und beteiligten Programmen. Wir übersetzen die Antworten in Systemkonfiguration, mögliche Erweiterungen und Prüffälle. Vorhandene Dokumentation und Schulungsmaterialien helfen dabei, sofern sie den tatsächlichen Ablauf widerspiegeln.

Nicht alle Prozesse müssen sofort im System implementiert werden. Im Gegenteil führt dieser Versuch oft zu Kostenüberschreitungen im Projekt. Wir empfehlen, sich bei der Erstimplementierung auf ausgewählte Schlüsselprozesse zu konzentrieren. Planen Sie die Umsetzung weiterer Prozesse für spätere Phasen nach dem Go-Live. Die zuvor besprochenen Prioritäten sind ein guter Indikator dafür, welche Prozesse als Schlüsselprozesse zu definieren sind.

Zwei Prozesse sollten Teil jeder Implementierung sein: (1) Der Auftrag-zu-Zahlung-Prozess (Order-to-Cash) und der (2) Einkauf-zu-Zahlung-Prozess (Purchase-to-Pay). Beide zeigen, wie ERP-Prozesse traditionelle Abteilungen überspannen. Der Order-to-Cash Prozess umfasst alle Aktivitäten, die beim Verkauf von Waren oder Dienstleistungen an Kunden anfallen. Dazu gehören das Entgegennehmen und Bearbeiten von Bestellungen, die Bestätigung der Produktverfügbarkeit, die Lieferung von Waren oder Dienstleistungen, das Ausstellen von Rechnungen, das Einziehen von Zahlungen und die Buchhaltung dieser Transaktionen. Der Purchase-to-Pay Prozess bezieht sich auf die Aktivitäten, die notwendig sind, um Waren oder Dienstleistungen von Lieferanten zu erwerben.

Die Prozessanalyse bietet die Möglichkeit zur Standardisierung und Vereinfachung. ERP-Systeme können kaufmännische Abläufe automatisieren, wenn die wiederkehrenden Schritte klar sind. Eine wichtige Entscheidung bei jeder ERP-Einführung ist, ob der Prozess dem System folgt oder das System dem Prozess. Unsere Faustregel: Bei Standardprozessen wie Einkauf, Buchhaltung oder Lager folgen Sie dem System, denn jede vermiedene Anpassung spart späteren Pflegeaufwand. Bei Abläufen, die Ihr Geschäft von Wettbewerbern unterscheiden, gilt das Gegenteil: Dort bildet der Standard die entscheidende Logik oft nicht präzise genug ab, und eine gezielte Erweiterung ist die bessere Wahl. So haben wir es im Sondermaschinenbau umgesetzt: Business Central für die stabilen kaufmännischen Prozesse, ergänzt um einen eigenen CPQ-Konfigurator genau dort, wo der Standard nicht reicht (zur Fallstudie). Wir ordnen die echten Vorgänge dieser Grenze zu und erklären die technische Folge in Alltagssprache.

System und Partner auswählen

Als Nächstes wählen Sie das System, das die priorisierten Abläufe abbilden kann. Beschränken Sie den Vergleich auf wenige Produkte mit dokumentiertem Support, regelmäßigen Versionen und einem für Sie nachvollziehbaren Weiterentwicklungsplan. So prüfen Sie eine konkrete Lieferfähigkeit statt der Größe oder Bekanntheit des Anbieters.

Prüfen Sie außerdem, ob das System Ihre Branche und Region unterstützt. Dazu gehören benötigte Funktionen, verfügbare Länderversionen und die für Ihren Fall geltenden Vorgaben. Fragen Sie nach vergleichbaren Referenzfällen und klären Sie, wo Daten verarbeitet und gespeichert werden. Rechtliche Anforderungen wie HIPAA oder DSGVO müssen für den konkreten Einsatz geprüft werden.

Cloud-Hosting kann Aufgaben vom eigenen Betrieb zum Anbieter verlagern, beweist für sich allein aber weder Sicherheit noch Verfügbarkeit. Lassen Sie sich erklären, wer Plattform-Updates einspielt und wie Zugriffe geschützt werden. Fragen Sie außerdem, wie Backups geprüft und wiederhergestellt werden und welche Verfügbarkeit vertraglich zugesagt ist. Klären Sie, wo die Anwendung tatsächlich läuft und welche Verantwortung beim Softwareanbieter, Hosting-Partner und bei Ihrem Unternehmen bleibt. Erst diese Mechanismen machen verschiedene Betriebsmodelle vergleichbar.

Funktionslisten reichen für die Bewertung selten aus. Lassen Sie sich stattdessen zeigen, wie jedes System denselben echten Vorgang verarbeitet. Stellen Sie allen Anbietern dieselben Fragen und halten Sie offene Punkte fest. Eine Online-Demonstration, etwa über Teams, lässt sich aufzeichnen und später mit den betroffenen Mitarbeitern prüfen.

Bei der Klärung der verfügbaren Systemfähigkeiten sollten Sie prüfen, welche Funktionen direkt verfügbar sind und welche von Drittanbietern oder dem Partner kommen. Der Einsatz von Drittanbieter-Tools ist oft gerechtfertigt, gleichzeitig müssen Sie wissen, auf welche Software Sie angewiesen sind. Wir empfehlen, wenn möglich die Standardfunktionalität des Systems zu verwenden, um weitere Abhängigkeiten zu vermeiden.

Nach den Demonstrationen sollte klar sein, welches System die priorisierten Vorgänge mit dem geringsten Anpassungsbedarf abbildet. Prüfen Sie außerdem, ob der Partner auf Ihre Beispiele eingeht, offene Fragen nachvollziehbar beantwortet und Zuständigkeiten schriftlich festhält. Danach können Sie Leistungsumfang, Abhängigkeiten und Vertragsdetails vergleichen.

Prozesse und Systemfunktionalitäten abgleichen

Gehen Sie nach der Auswahl jeden priorisierten Ablauf mit uns an einem echten Vorgang durch. Wir zeigen, welche Schritte der Standard abdeckt, fragen nach Regeln und Ausnahmen und halten fest, welche Konfiguration oder Erweiterung nötig ist. Sie prüfen am Ergebnis, ob der Ablauf im Alltag stimmt. Technische Optionen und ihre Folgen erklären wir in Alltagssprache.

Bei der Skizzierung Ihrer neuen Prozesse ist es wichtig, dass Sie die verfügbaren Optionen in Ihrem ERP-System verstehen. Dafür ist eine Schulung der funktionalen Leiter Ihres Projektteams erforderlich. Zwar haben diese an dieser Stelle bereits ein grundlegendes Verständnis des Systems. Doch sie benötigen für eine Umsetzung der Geschäftsprozesse darin detaillierteres Wissen. Diese Schulung sollte jeglicher Softwareentwicklung vorausgehen, da ein besseres Verständnis der Systemprozesse oft das wahrgenommene Bedürfnis nach einer Anpassung ändert. Sie sollte auch der Datenmigration vorausgehen, um sicherzustellen, dass deren Auswirkungen vollständig verstanden sind. Ziel ist, die funktionalen Leiter darauf vorzubereiten, die Implementierung zu überwachen und später ihre Kollegen zu schulen.

Anpassungsanforderungen definieren

Dafür ist eine Konfiguration des Systems erforderlich, bei der Ihr Partner helfen kann. Konfigurieren Sie das System so weit es möglich ist mit Standardfunktionalitäten. Wo dies nicht möglich ist, muss eine Anpassungsprogrammierung geplant werden. Hierbei ist eine Priorisierung wichtig. Einige fehlende Funktionalitäten sind unverzichtbar und müssen vor Inbetriebnahme des Systems umgesetzt werden. Dies gilt vor allem für Prozesse in Einkauf, Verkauf, und Buchhaltung sowie eventuell Produktion und Logistik. Darüber hinausgehende Funktionalitäten und Ideen sollten auf eine Warteliste gesetzt werden, um nach der Inbetriebnahme implementiert zu werden. So können Organisationen das Risiko einer Ausweitung des Projektrahmens reduzieren und die Kosten unter Kontrolle halten. Diese Abwägungen sind Teil der abschließenden Planung.

Vor und sogar nach Umsetzung können solche Prozesse außerhalb des Systems abgewickelt werden. Für manche Funktionen bietet sich dies sogar dauerhaft an. Beispiele von Prozessen, die oft besser in spezialisierten Systemen abgewickelt werden, sind: Gehaltsabrechnung, Verkauf und Marketing. Diese werden gewöhnlich in Customer Relationship Management (CRM), Human Capital Management (HCM) und Marketinglösungen bereitgestellt. Diese Systeme können, wo nötig, mit dem ERP-System integriert werden. Hier empfehlen wir Pragmatismus: Nicht alle Funktionen müssen integriert werden, und Integrationen dauern oft länger und sind teurer als ursprünglich angenommen. Wir empfehlen zu klären, welche Daten in welchem System vorhanden sein müssen und sich auf das Wesentliche zu konzentrieren. Besprechen Sie wahrgenommene Funktionslücken mit Ihrem ERP-Einführungspartner.

Datenbedarf festlegen

Die Datenmigration überträgt Daten aus den bestehenden Programmen in das neue ERP-System. Legt das Team Felder, Reihenfolge und Prüfungen nicht vorab fest, entstehen fehlerhafte Zuordnungen oder fehlende Datensätze. Ein Testimport mit anschließender Abstimmung zeigt solche Probleme vor der Inbetriebnahme.

Hier sind einige Schritte, die Sie bei der Vorbereitung auf die Datenmigration befolgen sollten:

1. Analysieren und bereinigen Sie Ihre Daten: Identifizieren Sie doppelte oder irrelevante Datensätze, korrigieren Sie bekannte Fehler und vereinheitlichen Sie die Formate vor der Migration. Das reduziert vermeidbare Fehler beim Import.
2. Vergleich der Datenfelder in beiden Systemen: Identifizieren Sie, welche Datenfelder in Ihrem aktuellen System welchen Feldern im neuen System entsprechen. Dadurch wird sichergestellt, dass alle relevanten Daten korrekt in das neue System übertragen werden.
3. Entwickeln Sie eine Migrationsstrategie: Ihre Migrationsstrategie sollte den Ansatz skizzieren, den Sie verfolgen werden, um Daten aus Ihren bestehenden Systemen in das neue ERP-System zu übertragen. Dazu gehören die Werkzeuge und Technologien, die Sie verwenden werden, die Reihenfolge der Datenmigration und alle Datenvalidierungsprozesse, die Sie implementieren werden. Eine gut geplante Migrationsstrategie hilft sicherzustellen, dass Ihr Datenmigrationsprozess reibungslos abläuft.

Ein erfahrener Partner kann die Feldzuordnung vorbereiten, Testimporte ausführen und Abweichungen dokumentieren. Die Fachverantwortlichen prüfen anschließend an echten Datensätzen, ob die übernommenen Informationen im neuen System stimmen.

Projektplan finalisieren

Sobald die Anforderungen an Anpassungsprogrammierung und Datenmigration definiert sind, können Zeitplan, Verantwortlichkeiten und Budget finalisiert und dem leitenden Sponsor vorgelegt werden. Der Sponsor wird diesen Vorschlag dann genehmigen (oder ablehnen) und dazu falls erforderlich weitere Genehmigungen einholen.

Planen Sie die Implementierungsreihenfolge realistisch. Berücksichtigen Sie die Verfügbarkeit Ihres Führungsteams, der Manager und der firmeninternen Experten, die zum Projekt beitragen. Stellen Sie sicher, dass alle über die Ressourcen-Kompromisse im Klaren sind und dass dies vom Management genehmigt wird.

Für die Planung wird oft ein agiler Ansatz mit der sogenannten Wasserfallplanung verglichen. Bei der Wasserfallplanung werden zunächst alle Anforderungen gesammelt und das Projekt auf dieser Basis linear geplant und umgesetzt; agile Planung liefert Funktionen dagegen iterativ in kleinen Schritten. Für die Inbetriebnahme selbst gilt weiterhin: Datenmigration, Umstellung und Schulung haben eine feste Reihenfolge und brauchen vorausschauende Planung über das gesamte Projekt. Geändert hat sich die Phase davor. Anforderungen müssen nicht mehr als vollständiges Lastenheft vorliegen, denn ein Prototyp des kritischen Prozesses ist heute oft schneller gebaut als eine Spezifikation geschrieben – und beantwortet offene Fragen am echten Ablauf statt auf dem Papier. Nach der Inbetriebnahme empfehlen wir wie bisher ein iteratives Vorgehen: neue Prozesse und Funktionen in kleinen Schritten, angepasst an sich ändernde Geschäftsbedingungen und -anforderungen.

Systemkonfiguration

Sobald die Spezifikationen vorliegen, richtet Ihr Partner zusammen mit Ihrer IT-Abteilung die Software für Sie ein. Dies beinhaltet die Konfiguration und gegebenenfalls die Anpassung der Software zur Unterstützung der neuen Prozesse. Das kann auch die Integrationen mit anderen bestehenden Geschäftsanwendungen des Unternehmens umfassen, die nicht durch das ERP-System ersetzt werden.

In einem ersten Schritt wird Ihre Software so konfiguriert, dass sie die neu gestalteten Prozesse optimal unterstützt. Oftmals ist dies von Anfang an der Fall. Wie bereits erwähnt, kann es in manchen Fällen jedoch erforderlich sein, Anpassungen zu programmieren, damit das System wirklich zu Ihrem Unternehmen passt.

Es ist auch üblich, während einer ERP-Einführung neue Bedürfnisse und Möglichkeiten zu entdecken. Diese müssen nach ihrer Dringlichkeit bewertet und, sofern möglich, auf die Warteliste für Verbesserungen nach der Inbetriebnahme gesetzt werden. Änderungsaufträge brauchen einen benannten Entscheider, damit neue Wünsche nicht unbemerkt Zeitplan und Budget verändern.

Datenmigration

Parallel zur Softwareentwicklung beginnt das Team mit der Datenmigration. Daten müssen oft aus mehreren Systemen extrahiert, transformiert und geladen werden. Jedes dieser Systeme kann unterschiedliche Formate verwenden und möglicherweise doppelte oder inkonsistente Informationen enthalten.

Das Projektteam muss sorgfältig festlegen, welche Daten in dieser Phase migriert werden sollen. Ein wichtiger Unterschied besteht zwischen Stammdaten und Bewegungsdaten (Bestellungen, Rechnungen usw.). Es ist in der Regel nicht notwendig, historische Bewegungsdaten in das neue System zu migrieren. Kosteneffektiver ist es, diese von der Migration auszuschließen und im alten System bzw. einem Data Warehouse zu speichern.

Mitarbeiterschulung

Die Schulung beginnt beim Projektteam. Es muss verstehen, wie Stammdaten vorbereitet werden und wie die ausgewählten Alltagsvorgänge im neuen System laufen. Mit diesem Wissen kann das Team die Einrichtung prüfen und später die Kollegen an echten Aufgaben schulen.

Die erste Schulung sollte noch vor Softwareanpassungen erfolgen, da ein besseres Verständnis dazu führen kann, unnötige Anpassungen zu erkennen und zu vermeiden. Die Schulung sollte auch noch vor der Datenmigration stattfinden, damit jeder weiß, wozu die neuen Daten eingesetzt werden.

Sobald das System einsatzbereit ist, schult das Projektteam die übrigen Mitarbeiter an den Aufgaben, die sie nach der Inbetriebnahme ausführen. Rückfragen und Fehler aus diesen Übungen zeigen, wo Konfiguration oder Schulungsmaterial noch angepasst werden müssen. Das Wissen bleibt im Unternehmen, wenn benannte Ansprechpartner diese Unterlagen später pflegen.

Darüber hinaus benötigen Sie einen Plan für neue Mitarbeiter, die ins Unternehmen kommen. Wir empfehlen, großen Wert auf Schulungsmaterial zu legen, idealerweise durch Videos für die wesentlichen Prozesse. Die Dokumentation sollte bereits während der Systemeinrichtung umrissen werden. Wir empfehlen die Einrichtung eines geeigneten Systems für das interne Wissensmanagement, falls noch keines vorhanden ist.

Anpassungsprogrammierung

Wenn die Basisfunktionen des ERP-Systems wesentliche Geschäftsanforderungen nicht erfüllen, ist eine Anpassungsprogrammierung notwendig. In diesem Fall ist eine gründliche Dokumentation essentiell. Der Programmcode sollte mit klaren Kommentaren versehen werden, um spätere Fehlerbehebungen und Wartungen zu erleichtern. Dies ist besonders nützlich, wenn das System später von einem neuen Team oder einem anderen Dienstleister betreut wird. Ein zentrales Repository zur Versionsverwaltung, wie etwa Git oder GitHub, ist ebenfalls empfehlenswert.

Je nach ERP-Lösung können spezielle Entwicklungsumgebungen verfügbar sein, die die Programmierung von Anpassungen vereinfachen. Es ist von großer Bedeutung, alle Änderungen gründlich in einer Testumgebung zu prüfen, um die Stabilität und Zuverlässigkeit des Gesamtsystems zu gewährleisten.

Die Anpassungsprogrammierung sollte als fortlaufender Prozess angesehen werden, da sich Geschäftsanforderungen im Laufe der Zeit ändern können. Daher ist es ratsam, regelmäßige Überprüfungen der Anpassungen durchzuführen und notwendige Aktualisierungen vorzunehmen. Dabei sollte eine klare Priorisierung der Aufgaben und die Pflege einer Aufgabenliste (Backlog) nicht vernachlässigt werden. Zusätzlich sollte die Langzeitwartung bei Anpassungen berücksichtigt werden. Jede Änderung könnte potenzielle Auswirkungen auf die Kompatibilität mit künftigen Systemaktualisierungen haben. Daher ist es sinnvoll, Anpassungen so modular wie möglich zu gestalten, um die Wartung zu vereinfachen und das Risiko zukünftiger Kompatibilitätsprobleme zu minimieren. Behalten Sie dabei die Eigentumsfrage im Blick: Anpassungen in Versionskontrolle, mit Dokumentation und Tests, kann später auch ein anderer Dienstleister übernehmen. Undokumentierte Sonderlogik, die nur ein Anbieter versteht, ist die teuerste Form der Abhängigkeit.

Abnahmetests

Testen und Entwicklung können teilweise gleichzeitig stattfinden. Beispielsweise kann das Projektteam spezifische Module und Funktionen testen, auf Basis der Ergebnisse Korrekturen oder Anpassungen vornehmen und dann erneut testen. Erste Tests der grundlegenden Funktionen der Software sollten von gründlichen Tests der vollen Systemfähigkeiten gefolgt sein. Dazu gehört auch, dass einige Mitarbeiter das System für ihre täglichen Aktivitäten testen dürfen. Diese Tests sollten erst nach der notwendigen Endbenutzerschulung und der Datenmigration erfolgen.

Ihr Implementierungspartner wird eine Schulungsumgebung einrichten, die es Ihnen ermöglicht, alle Ihre Prozesse im Testbetrieb zu überprüfen. So stellen Sie sicher, dass alles wie erwartet funktioniert, ohne Überraschungen. Nutzen Sie die im Entwicklungsprozess erstellten Schulungsmaterialien hier sinnvoll. Ressourcen, die speziell auf die täglichen Aufgaben Ihrer Endbenutzer zugeschnitten sind, haben einen echten Mehrwert.

Bevor Sie Ihr ERP-System vollständig einführen, ist es entscheidend, es zu testen, um sicherzustellen, dass es Ihren Anforderungen entspricht und ältere Systeme effektiv ersetzen kann. Neben rein technischen Überprüfungen ist es wichtig, eine Liste von Geschäftsaufgaben und -situationen zu haben. Dies ermöglicht es den tatsächlichen Benutzern, das ERP-System auszuprobieren, bevor es vollständig implementiert ist.

Inbetriebnahme

Mit der Inbetriebnahme beginnt der Betrieb im neuen System. Das Projektteam braucht in den ersten Tagen einen festen Weg für Fragen und Fehlermeldungen. Es erklärt unbekannte Schritte, ordnet Probleme nach Dringlichkeit und gibt technische Fehler an den Einführungspartner weiter. Dass Mitarbeiter anfangs Rückfragen haben, ist auch bei guter Vorbereitung normal.

Nicht alle Daten werden zum selben Zeitpunkt übertragen. Stammdaten können vor dem offiziellen Start geladen und geprüft werden. Zeitkritische Informationen wie laufende Bestellungen oder aktuelle Buchungen kommen erst kurz vor der Inbetriebnahme. Der Migrationsplan hält fest, wer den letzten Import ausführt und wer die Werte im neuen System freigibt.

Manche Unternehmen führen alle Module gemeinsam ein, andere starten mit priorisierten Abläufen und ergänzen später. Ein Parallelbetrieb von altem und neuem System kann für einzelne Vorgänge nötig sein, verdoppelt aber Dateneingaben und Abstimmung. Begrenzen Sie ihn deshalb auf klar benannte Prozesse und ein festes Enddatum.

Nach der Inbetriebnahme sammelt das Projektteam Rückmeldungen aus dem Alltag und trennt Fehler von neuen Wünschen. Fehler werden behoben; zusätzliche Konfigurationen oder Erweiterungen kommen priorisiert auf die Warteliste. Neue Mitarbeiter brauchen weiterhin eine Einführung in die für ihre Arbeit relevanten Vorgänge.

Bei einem On-Premises-System plant Ihr Unternehmen Software-Updates und bei Bedarf neue Hardware. Bei einem Cloud-System übernimmt der Anbieter häufig Plattform-Updates. Eigene Erweiterungen, Integrationen, Berechtigungen und Schulungsunterlagen müssen in beiden Fällen weiter gepflegt und nach Änderungen geprüft werden.

Vereinbaren Sie für die ersten Wochen kurze Rückmeldetermine mit den betroffenen Mitarbeitern. Das Projektteam beantwortet Bedienfragen und dokumentiert wiederkehrende Probleme. Der Einführungspartner übernimmt die technischen Punkte, die Konfiguration oder Entwicklung betreffen. Neue Funktionswünsche werden für die nächste Entscheidung gesammelt und verändern die laufende Einführung nicht ungeprüft.

Kernprozesse zuerst, Ausbau in Phasen

Die erste Phase braucht eine klare Grenze. Nehmen Sie einen Kernprozess auf, dessen Stammdaten für einen realistischen Test ausreichen und dessen Verantwortliche für Entscheidungen verfügbar sind.

Folgt dieser Ablauf einem üblichen Muster, nutzen Sie den ERP-Standard. Unterscheidet seine Logik Ihr Geschäft, planen Sie eine gezielte und dokumentierte Erweiterung. Der Einführungspartner muss diese Einordnung am echten Vorgang erklären können.

Alles, was für einen verlässlichen Start nicht gebraucht wird, wartet auf die nächste Phase. Entscheidend ist, ob der gewählte Kernprozess mit echten Daten sicher in Betrieb gehen kann.

Wenn Sie ein ERP-Projekt prüfen, starten Sie mit den Kernprozessen und den Daten, die wirklich entscheiden. Wenn Sonderlogik, Exporte oder Abstimmung trotzdem zwischen Systemen hängen bleiben, ist das der richtige Punkt für Individualsoftware: Individualsoftware prüfen.

Wenn Sie rund um Ihre ERP-Einführung die ergänzende Workflow-Schicht planen, sprechen wir über den konkreten Ablauf.