Wie validieren wir den Unternehmenssystemplan?

Ein neuer Systementwurf wirkt oft überzeugend, wenn das Flussdiagramm geordnet ist, die Integrationsliste vollständig erscheint und jede betroffene Abteilung ihren eigenen Bildschirm genehmigt hat. Probleme treten meist später auf: wenn das Lager Teillieferungen abwickeln muss, ein Kunde seine Bestellung ändert, eine falsche Artikelnummer aus dem Webshop kommt oder die Rechnungsstellung andere Daten benötigt als das Handelssystem speichert. Daher ist die Frage nicht nur, wie wir den Unternehmenssystementwurf validieren, sondern auch, ob der Entwurf den realen Anforderungen des täglichen Betriebs standhält.

Die Validierung eines Systementwurfs ist kein formaler Unterschriftenprozess. Es ist ein Überprüfungsprozess, bei dem wir nach Beweisen suchen, dass der geplante Betrieb die Geschäftsziele unterstützt, Ausnahmen behandelt und keine neuen manuellen Umgehungslösungen schafft. Bei einem wachsenden Unternehmen ist dies besonders wichtig: Ein schlecht validiertes System kann jahrelange Verwaltung, unsichere Berichte und Abhängigkeit von Schlüsselpersonen in den Betrieb einbauen.

Der Systementwurf ist nicht identisch mit dem Bildschirmentwurf

Viele Projekte werden zu früh zu einer technologischen Debatte. Soll es ein ERP sein, ein separates Produktionsmodul, eine neue Webshop-Verbindung, eine maßgeschneiderte Anwendung oder eine automatisierte Dokumentenverarbeitung? Diese sind nur dann sinnvoll zu verstehen, wenn zuvor geklärt ist, wie die Arbeit im Unternehmen abläuft.

Nehmen wir einen scheinbar einfachen Handelsprozess. Der Webshop übermittelt die Bestellung, der Kollege überprüft den Lagerbestand, das Lager stellt die Ware zusammen, die Rechnungsabteilung stellt das Dokument aus, der Spediteur erhält die Daten und die Finanzabteilung verfolgt die Erfüllung. Wenn alle Systeme „funktionieren“, der Kollege jedoch täglich Daten zwischen ihnen kopiert, nutzt das Unternehmen kein funktionierendes System, sondern eine menschliche Integration.

Die erste Frage der Validierung ist daher nicht, ob der Entwurf erstellt werden kann. Sondern welche Geschäftsprozesse er verändert, wessen Arbeit er betrifft und auf welchen Informationen er basiert. Eine technisch elegante Lösung kann auch fehlerhaft sein, wenn sie einen Genehmigungsschritt digitalisiert, der eigentlich nicht benötigt wird, oder wenn sie eine Entscheidung aus dem Prozess weglässt, die heute auf Erfahrung basiert getroffen wird.

Beginnen wir mit dem realen Betrieb, nicht mit dem gewünschten Zustand

Systementwürfe stellen oft ideale Prozesse dar. Die Bestellung ist vollständig, die Artikelstammdaten sind sauber, alle Berechtigungen sind aktuell, die Partnerdaten sind einheitlich. In der Realität kann jedoch derselbe Kunde unter mehreren Namen auftreten, ein Produkt wird mit einer Ersatzartikelnummer geliefert oder die Produktion teilt erst später mit, dass der zugesagte Termin nicht eingehalten werden kann.

Eine gute Validierung beginnt daher mit der Beobachtung des aktuellen Prozesses. Es reicht nicht aus, den Leiter zu fragen, wie eine Bestellung funktionieren sollte. Man muss einige tatsächliche Bestellungen, Fertigungsanweisungen, Reklamationen oder Beschaffungsanforderungen vom Entstehen bis zum Abschluss verfolgen. Es werden kleine Schritte sichtbar, die in der Dokumentation oft fehlen: Telefonate, Excel-Listen, E-Mail-Abstimmungen, eigene Notizen und die „jeder weiß, dass es so gemacht werden muss“-Regeln.

Dies sind nicht unbedingt Fehler. Einige manuelle Entscheidungen sind geschäftlich gerechtfertigt, beispielsweise bei individueller Preisgestaltung oder Qualitätskontrolle. Die Aufgabe der Validierung besteht darin, wertschöpfende menschliche Abwägung von mechanischer Datenbewegung und wiederholter Überprüfung zu unterscheiden.

Die Ausnahmen zeigen die Qualität des Entwurfs

Ein Unternehmenssystementwurf sieht in normalen Fällen fast immer gut aus. Das Risiko liegt in den Ausnahmen. Was passiert, wenn kein Lagerbestand vorhanden ist? Wer wird benachrichtigt, wenn die Integration keine Bestellung übermittelt hat? Welches System ist der Dateninhaber, wenn die Lieferadresse an zwei Stellen unterschiedlich ist? Wer und unter welchen Bedingungen kann eine automatische Entscheidung überschreiben?

Ausnahmen können nicht vollständig beseitigt werden. Das Ziel ist vielmehr, dass sie sichtbar, handhabbar und nachvollziehbar sind. Wenn ein Fehler erst dann entdeckt wird, wenn der Kunde reklamiert, verfügt der Systementwurf nicht über eine angemessene Betriebskontrolle. Und wenn bei jeder Abweichung derselbe erfahrene Kollege angerufen werden muss, bleibt das Unternehmen weiterhin personenabhängig.

Wie validieren wir den Unternehmenssystementwurf mit Geschäftsszenarien?

Die nützlichste Methode ist die Verwendung von End-to-End-Geschäftsszenarien. Diese sind keine allgemeinen Testfälle, sondern konkrete Situationen aus dem Betrieb des Unternehmens. Ein Szenario muss zeigen, woher die Informationen stammen, wer sie ändern kann, durch welche Systeme sie laufen, welche Entscheidungen getroffen werden und was als erfolgreicher Abschluss gilt.

Bei einem E-Commerce-Unternehmen könnte ein solches Szenario eine Bestellung sein, bei der ein Artikel sofort verfügbar ist und ein anderer erst später geliefert werden kann. Bei der Validierung muss nicht nur überprüft werden, ob die Bestellung im ERP erstellt wird. Es muss auch geprüft werden, welche Informationen der Kunde erhält, ob das Lager genaue Aufgaben erhält, ob die Rechnungsstellung den Unternehmensrichtlinien entspricht, ob die Lagerreservierung korrekt geändert wird und ob der Managementbericht zwischen erfüllten und ausstehenden Bestellungen unterscheidet.

Bei einem Produktionsunternehmen könnte das Szenario mit einem fehlenden Rohstoff oder einer geänderten technischen Spezifikation beginnen. Hier ist die Frage, ob die Änderung die Planung, den Einkauf, die Werkstatt und die Kostenrechnung erreicht, ohne dass mehrere unterschiedliche Excel-Versionen entstehen.

Die Szenarien sollten mit den Prozessverantwortlichen durchgegangen werden. Nicht ausschließlich mit der IT und nicht nur mit dem Projektleiter. Der Lagerleiter, der Finanzkollege, der Kundenservice oder der Produktionsleiter kennen Details, ohne die der Entwurf auf dem Papier korrekt, im Betrieb jedoch unvollständig bleibt.

Untersuchen wir die Daten, die Verantwortung und die Übergaben

Ein erheblicher Teil der Systemfehler sind eigentlich Daten- und Verantwortungsfehler. Zwei Systeme speichern dieselben Kundendaten, aber es gibt keine klare Regel, welches die verlässliche Quelle ist. Der Status einer Bestellung ändert sich, aber die Änderung erreicht die Rechnungsstellung nicht. Ein Arbeitsablauf startet automatisch, aber es gibt keine benannte Person, die die Ausnahme behandelt.

Bei der Validierung sollte bei allen wichtigen Daten geklärt werden, wo sie entstehen, wer für ihre Qualität verantwortlich ist und wo sie verwendet werden. Dies ist besonders kritisch bei Artikelstammdaten, Preisen, Beständen, Kundendaten, Produktionsparametern und Finanzstatus.

Ebenso wichtig sind die Systemgrenzen. Jede Übergabe birgt ein Risiko, sei es über API, Dateiimport, E-Mail oder manuelle Eingabe. Nicht jede Verbindung muss in Echtzeit automatisiert werden. Eine tägliche Synchronisation kann ausreichend sein, wenn die Geschäftsentscheidungen dies zulassen. Die Wahl hängt davon ab, wie viel Verzögerung akzeptabel ist, welche Kosten ein Fehler verursacht und ob ein sofortiges Eingreifen erforderlich ist.

Die nicht-funktionalen Anforderungen sind auch geschäftliche Fragen

Die Validierung eines Systementwurfs darf nicht bei den Funktionen haltmachen. Es kann sein, dass das System Bestellungen korrekt abwickelt, aber bei einer Monatsendbelastung verlangsamt. Oder nach einem Serverfehler wiederhergestellt werden kann, aber die Wiederherstellung acht Stunden dauert, während das Lager zwei Stunden Ausfallzeit nicht bewältigen kann.

Verfügbarkeit, Backups, Berechtigungsverwaltung, Protokollierung, Leistung und Supportmodell sind alle Teil des Betriebs. Diese sollten nicht als allgemeine technische Anforderungen formuliert werden, sondern mit den geschäftlichen Konsequenzen. Wie viel Datenverlust ist akzeptabel? Wer kann weiterarbeiten, wenn ein zentrales System ausfällt? Wie schnell muss die Rechnungsstellung, die Produktionsdatenerfassung oder die Webshop-Bestellverarbeitung wiederhergestellt werden?

Die Antworten helfen, eine angemessene Architektur zu wählen. Nicht jeder Prozess erfordert das gleiche Maß an hoher Verfügbarkeit, aber an kritischen Betriebspunkten kann Unsicherheit teuer sein.

Das Ergebnis der Validierung sollte eine Entscheidungsgrundlage sein

Am Ende einer guten Validierung steht nicht ein vager „bestanden“-Vermerk. Das Management muss verstehen, unter welchen Bedingungen der Entwurf funktioniert, welche Risiken darin verbleiben, welche Prozessänderungen vor der Einführung erforderlich sind und welche Entscheidungen noch getroffen werden müssen.

Es ist ratsam, die zu behebenden Fehler, die bewusst eingegangenen Einschränkungen und die späteren Entwicklungsmöglichkeiten separat zu behandeln. Nicht jede Unzulänglichkeit rechtfertigt den Stopp des Projekts. Eine weniger häufige Ausnahme kann mit einer vorübergehenden Regel behandelt werden, wenn der Verantwortliche bekannt ist und die Auswirkungen messbar sind. Es ist jedoch nicht ratsam, einen Prozess in Betrieb zu nehmen, bei dem der Dateninhaber nicht klar ist, die Fehlererkennung nicht funktioniert oder der tägliche Betrieb auf dem stillschweigenden Wissen einer einzigen Person basiert.

Ein Systementwurf kann als ausgereift angesehen werden, wenn wir nicht nur sagen können, wie er im Idealfall funktioniert, sondern auch, wer was bei Abweichungen tut. Diese Art von Disziplin verlangsamt die Entwicklung nicht. Sie reduziert spätere Neuentwürfe, dringende manuelle Korrekturen und unsicheren Betrieb, während das Unternehmenswachstum weniger zu einer administrativen Belastung wird.