Wer glaubt, Testmanagement sei reine IT-Aufgabe, riskiert Fehlentscheidungen, Frust und teure Nacharbeiten. Warum echte Qualität nur entsteht, wenn der Fachbereich aktiv mitgestaltet.
Warum Testmanagement kein IT-Anhängsel ist
S/4HANA-Transformationen sind kein IT-Projekt. Sie sind ein Unternehmensprojekt – mit echten Auswirkungen auf Prozesse, Rollen und Menschen. Trotzdem wird das Testmanagement oft wie ein technisches Anhängsel behandelt: etwas, das „die IT schon übernimmt“. Ein gefährlicher Irrtum.
Denn gerade in den Tests entscheidet sich, ob die neue Lösung später funktioniert – und zwar dort, wo sie gebraucht wird: im Fachbereich. Hier sitzen die Menschen, die mit den Prozessen leben, die jeden Klick und jede Maske im Alltag spüren. Wenn etwas nicht läuft, merken sie es zuerst.
Unsere Erfahrung zeigt: Der Wille, sich einzubringen, ist da. Viele Fachbereiche wollen aktiv mitwirken – aus berechtigter Sorge, dass nach der Einführung nichts mehr so funktioniert wie vorher. Doch oft fehlt es nicht am Engagement, sondern an den Strukturen. Niemand möchte den Fachbereich „belasten“, man bittet vorsichtig um Unterstützung, anstatt klar zu sagen: Ohne Sie geht es nicht.
Das Ergebnis: Testmanager jagen den Fachexperten hinterher, Testfälle bleiben oberflächlich, und am Ende wundert man sich über Fehlfunktionen im Live-Betrieb. Fachlich fundierte Testfälle erfordern tiefes Wissen über Prozesse, Ausnahmen und Abhängigkeiten – Wissen, das nur im Fachbereich vorhanden ist. Wird dieses Wissen nicht konsequent eingebunden, zahlt das Unternehmen später doppelt: mit Nacharbeiten, Frust und Ineffizienz.
„Testmanagement ohne Fachbereich ist wie ein Navigationssystem ohne Karte – technisch brillant, aber völlig orientierungslos.“
– Alexander Schöberl, IT Consultant
Der Wille ist da – aber die Strukturen fehlen
In vielen S/4HANA-Projekten erleben wir hochmotivierte Fachbereiche. Sie wissen, dass sie die Hauptnutzer sind – und dass sie es sind, die die Auswirkungen jeder Prozessänderung spüren. Aber zwischen Motivation und Umsetzung steht der Projektalltag: volle To-do-Listen, operative Verantwortung, keine Freiräume.
Oft wird versucht, die Belastung der Fachbereiche zu minimieren – aus Rücksicht. Doch genau das führt zu oberflächlicher Einbindung. Wenn Testmanager wochenlang auf Input warten müssen oder Business-Analysten die Testfälle allein formulieren, entstehen generische Tests, die am Ende wenig Aussagekraft haben.
Das Paradoxe: Viele dieser „Zeitspartaktiken“ führen genau zu dem Gegenteil – zu mehr Aufwand. Unklare Testfälle verursachen Missverständnisse, Verzögerungen und Nacharbeiten nach dem Go-Live. Aus Managementsicht mag das Testing formal abgeschlossen sein, in der Realität beginnt der Ärger dann erst richtig.
Warum generische Tests teuer werden
Ein gutes Testdesign ist nie Standardware. Es lebt vom Fachwissen. Doch genau dieses Wissen fehlt oft dort, wo die Testfälle geschrieben werden. Wenn Tests zu generisch bleiben, fehlt die Tiefe, um reale Prozessszenarien abzubilden – die kleinen, aber entscheidenden Unterschiede, die später den Unterschied machen.
Die Folgen:
Fehler werden erst nach dem Go-Live entdeckt.
Prozesse laufen im Alltag anders als geplant. Die Wartung der Lösung wird teurer, weil niemand genau weiß, was getestet wurde – und warum.
Kurz gesagt: Wer beim Testdesign spart, zahlt in der Betriebsphase drauf.
Ownership statt Alibi-Testing
Testing ist kein Gefallen, den der Fachbereich der IT tut. Es ist Teil der eigenen Verantwortung.
Deshalb braucht es organisatorische Lösungen: klare Rollen, Prioritäten und vor allem Freiräume. Mitarbeitende, die testen sollen, können das nicht „nebenbei“ erledigen.
Management muss diese Zeiträume bewusst schaffen – durch reduzierte Tageslast, temporäre Entlastung oder klare Kommunikationswege.
Noch besser: Wenn Fachbereiche Testfälle selbst definieren, bevor etwas entwickelt wird. So wird von Anfang an transparent, woran sich das Projekt messen lassen muss.
Das ist im Grunde Test-Driven Development – nur aus Business-Perspektive.
Drei Erfolgsfaktoren für S/4HANA-Testmanagement mit Fachbereichsbeteiligung
- Shift Left – frühzeitige Einbindung
Fachbereiche sollten nicht erst am Ende testen, sondern schon früh in Sprints, Demos oder Prototypen einbezogen werden. Das schafft Verständnis und vermeidet böse Überraschungen.
- Sprint Shows mit Stakeholdern
Regelmäßige Einblicke in den Entwicklungsfortschritt fördern Transparenz und Vertrauen. Hier kann das Business früh Feedback geben – bevor ein Fehler teuer wird.
- Wissenstransfer und Schulung
Testmethoden, Tools und Abläufe sind oft Neuland für Fachbereiche. Schulungen werden häufig als „Zeitverschwendung“ gesehen – bis man merkt, wie viel Zeit schlechte Tests später kosten.
Diese Schritte klingen banal – sind aber entscheidend, um aus reiner Beteiligung echte Verantwortung zu machen.
Am Ende zählt Haltung
Testmanagement in S/4HANA-Projekten ist kein IT-Prozess. Es ist ein Organisationsprozess.
Er funktioniert nur, wenn das Management klare Rahmenbedingungen schafft, Fachbereiche aktiv Verantwortung übernehmen und IT und Business auf Augenhöhe zusammenarbeiten.
Oder anders gesagt: Gute Tests entstehen nicht durch mehr Tools, sondern durch mehr Miteinander.
Fazit & Einladung zum Dialog
Ohne Fachbereich kein Fortschritt.
S/4HANA-Transformationen gelingen nur, wenn Business und IT gemeinsam Verantwortung übernehmen – vom ersten Testfall bis zur Abnahme.
Wie schaffen Sie in Ihrem Unternehmen die Balance zwischen Tagesgeschäft und Projektanforderungen?
Wir bei Sirius Consult begleiten Unternehmen genau dabei: Testmanagement neu denken – kompetent, menschlich, besser.
👉 Kontaktieren Sie uns, wenn Sie wissen möchten, wie Sie Ihre Fachbereiche im Testmanagement organisatorisch und methodisch optimal einbinden.
Titelbild: © pressfoto/freepik
