ERP-Testmanagement: Warum strukturiertes Testen den Unterschied macht

In vielen ERP-Projekten wird das Testen als nachgelagerter Schritt betrachtet – etwas, das man macht, wenn die Konfiguration fertig ist und bevor der Go-Live kommt. In der Realität wird die Testphase dann häufig komprimiert, weil vorher zu viel Zeit verbraucht wurde. Die Konsequenz: Das Unternehmen geht mit einem System live, das nicht ausreichend geprüft wurde.

Das ist kein theoretisches Risiko. In unserer Beratungspraxis sehen wir regelmäßig, dass Probleme, die nach dem Go-Live auftreten, in einer strukturierten Testphase erkennbar gewesen wären. Die Kosten für die nachträgliche Behebung sind um ein Vielfaches höher als die für eine sorgfältige Vorbereitung.

In der ersten Phase werden einzelne Funktionsbereiche isoliert getestet: Kann das System eine Bestellung korrekt anlegen? Werden Preise richtig berechnet? Funktioniert die Lagerbestandsführung? Diese Tests liegen primär in der Verantwortung des Systemhauses und prüfen, ob die Konfiguration technisch korrekt ist.

Modultests sind notwendig, aber nicht hinreichend. Sie prüfen einzelne Bausteine – nicht das Zusammenspiel.

Hier wird das Zusammenspiel der Module geprüft: Was passiert, wenn ein Kundenauftrag durch den gesamten Prozess läuft – vom Auftragseingang über die Disposition und Kommissionierung bis zur Fakturierung? Funktionieren die Schnittstellen zum Webshop, zur Finanzbuchhaltung, zum Lagerverwaltungssystem?

Integrationstests decken die Fehler auf, die in Modultests nicht sichtbar werden: Datenübergaben, die nicht stimmen. Prozesslogik, die an Modulübergängen bricht. Berechtigungen, die in einem Modul funktionieren, aber im Zusammenspiel mit einem anderen zu Problemen führen.

Die wichtigste und zugleich am häufigsten vernachlässigte Phase. Hier testen nicht die Berater oder Entwickler – hier testen die Mitarbeiter, die das System im Alltag nutzen werden. Key User prüfen ihre täglichen Arbeitsabläufe: Kann ich meine Bestellungen so anlegen, wie ich es brauche? Finde ich die Informationen, die ich für meine Arbeit benötige? Stimmen die Auswertungen?

UAT ist der Moment der Wahrheit. Wenn Key User hier feststellen, dass das System ihre Arbeit nicht abbildet, ist das ein kritisches Signal – aber ein behebbares. Wenn diese Erkenntnis erst nach dem Go-Live kommt, wird es teuer.

Die letzte Phase vor dem Go-Live: Ein vollständiger Durchlauf des Cutover-Prozesses unter möglichst realen Bedingungen. Daten werden migriert, Schnittstellen aktiviert, das System unter Last gesetzt. Hier zeigt sich, ob die Cutover-Planung trägt und ob das Team auf die Umstellung vorbereitet ist.

Eine gute Go-Live-Simulation reduziert das Restrisiko erheblich. Sie ist die Generalprobe, die verhindert, dass der Ernstfall zur Premiere wird.

In vielen Projekten wird erst getestet, wenn die Konfiguration „fertig“ ist – oft wenige Wochen vor dem geplanten Go-Live. Das Problem: Für gefundene Fehler bleibt dann kaum Korrekturzeit. Testphasen müssen frühzeitig eingeplant und im Projektplan als eigenständige Arbeitspakete verankert sein – nicht als Puffer, der bei Verzögerungen als Erstes gekürzt wird.

Wer mit idealisierten Testdaten testet, findet idealisierte Ergebnisse. In der Praxis braucht es Testdaten, die die reale Komplexität abbilden: Sonderzeichen in Artikelnamen, Kunden mit Sonderkonditionen, Bestellungen mit ungewöhnlichen Kombinationen. Testdatenmanagement ist keine technische Nebensächlichkeit – es ist die Voraussetzung für aussagekräftige Tests.

Key User sollen das System testen – aber neben ihrer normalen Arbeit. Das führt dazu, dass Tests oberflächlich durchgeführt oder verschoben werden. Ergebnis: Die Abnahme erfolgt formal, aber nicht inhaltlich. Key User brauchen dedizierte Testzeiten, in denen sie von ihrem Tagesgeschäft freigestellt sind. Das kostet Kapazität – aber es kostet weniger als ein Go-Live mit ungetesteten Prozessen.

Ohne Testplan wird unsystematisch getestet. Manche Prozesse werden dreimal geprüft, andere gar nicht. Ein guter Testplan definiert: Welche Szenarien werden getestet? Wer ist verantwortlich? Was sind die Akzeptanzkriterien? Wie werden Fehler dokumentiert und nachverfolgt? Ein Testplan muss keine hundert Seiten haben – aber er muss existieren und gepflegt werden.

Tests sind nur so gut wie das Fehlermanagement dahinter. Wenn Fehler gefunden, aber nicht systematisch dokumentiert, priorisiert und bis zur Lösung nachverfolgt werden, verliert die Testphase ihren Wert. Ein einfaches Issue-Tracking – ob in Jira, Excel oder einem anderen Werkzeug – ist unverzichtbar.

Testmanagement und Change Management sind enger verknüpft, als es auf den ersten Blick scheint. Die Testphase ist der erste Moment, in dem Mitarbeiter das neue System in ihrem Arbeitskontext erleben. Wenn diese Erfahrung positiv ist – wenn sie das Gefühl haben, gehört zu werden und Einfluss auf das Ergebnis zu haben –, entsteht Akzeptanz.

Wenn die Testerfahrung negativ ist – ein System, das nicht funktioniert, Tests ohne ausreichende Einweisung, Feedback, das ignoriert wird –, entsteht Widerstand, der sich bis nach dem Go-Live hält.

Deshalb sollte die Testphase nicht nur als technische Qualitätssicherung betrachtet werden, sondern als Teil der Change-Strategie. Unser ChangeReady360-Ansatz integriert Testbegleitung und User-Enablement systematisch.

Strukturiertes Testmanagement ist kein Overhead – es ist die günstigste Form der Qualitätssicherung. Jeder Fehler, der in der Testphase gefunden wird, kostet einen Bruchteil dessen, was seine Behebung nach dem Go-Live kostet.

Die Investition in einen guten Testplan, realistische Testdaten und ausreichend Zeit für Key User zahlt sich mehrfach aus: in einem stabileren Go-Live, in höherer Mitarbeiterakzeptanz und in weniger Nacharbeit in den Wochen danach.

Als Faustregel: mindestens 20 bis 25 Prozent der gesamten Projektlaufzeit sollten für Tests reserviert sein. Bei einem 12-monatigen Projekt sind das etwa drei Monate – verteilt auf die verschiedenen Testphasen. In der Praxis wird diese Zeit häufig unterschritten, was zu erhöhtem Risiko beim Go-Live führt.

Nicht zwingend. Für die meisten mittelständischen ERP-Projekte reicht eine strukturierte Testdokumentation in Excel oder einem einfachen Ticketsystem. Wichtiger als das Werkzeug ist der Prozess: Szenarien definieren, durchführen, Ergebnisse dokumentieren, Fehler nachverfolgen. Spezialisierte Testmanagement-Tools lohnen sich erst bei sehr großen Projekten oder wenn automatisierte Tests sinnvoll werden.

Beides. Modultests und Integrationstests liegen primär beim Systemhaus, weil sie die technische Konfiguration prüfen. User Acceptance Tests müssen von Ihren eigenen Mitarbeitern durchgeführt werden – sie kennen die Prozesse und die Anforderungen, die das System abbilden muss. Ein externer Berater kann den Testprozess moderieren, aber die fachliche Bewertung muss aus dem Unternehmen kommen.