Wie validiert man den Unternehmenssystemplan?

Ein neuer Systementwurf erscheint oft überzeugend, wenn das Flussdiagramm geordnet ist, die Integrationsliste vollständig aussieht und jede beteiligte Abteilung ihren eigenen Bildschirm genehmigt hat. Probleme treten meist später auf: wenn das Lager Teillieferungen bearbeiten 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 täglichen Betrieb tatsächlich aushält.

Die Validierung eines Systementwurfs ist kein formaler Unterschriftenprozess. Es ist ein Prüfprozess, bei dem wir Beweise dafür suchen, dass der geplante Betrieb die Geschäftsziele unterstützt, Ausnahmen behandelt und keine neuen manuellen Umwege 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 dasselbe wie der Bildschirmentwurf

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

Nehmen wir einen scheinbar einfachen Handelsprozess. Der Webshop übergibt die Bestellung, der Kollege überprüft den Bestand, das Lager bereitet vor, die Rechnungsstellung erstellt das Dokument, der Spediteur erhält die Daten, und die Finanzabteilung verfolgt die Erfüllung. Wenn alle Systeme „funktionieren“, aber der Kollege täglich Daten zwischen ihnen kopiert, nutzt das Unternehmen kein funktionierendes System, sondern menschliche Integration.

Die erste Frage der Validierung ist daher nicht, ob der Entwurf erstellt werden kann. Sondern, welcher Geschäftsprozess verändert wird, wessen Arbeit betroffen ist 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, der Artikelstamm ist sauber, alle Berechtigungen sind aktuell, die Partnerdaten sind einheitlich. In der Realität kann jedoch derselbe Kunde unter mehreren Namen auftreten, ein Produkt unter einer Ersatzartikelnummer eintreffen oder die Produktion erst später mitteilen, dass die zugesagte Frist 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. Es müssen einige tatsächliche Bestellungen, Fertigungsanweisungen, Reklamationen oder Beschaffungsanforderungen von der Entstehung bis zum Abschluss verfolgt werden. Sichtbar werden die kleinen Schritte, die in der Dokumentation normalerweise fehlen: Telefonanrufe, Excel-Listen, E-Mail-Abstimmungen, eigene Notizen und die „jeder weiß, dass man das so machen muss“-Regeln.

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

Die Ausnahmen zeigen die Qualität des Entwurfs

Ein Unternehmenssystementwurf sieht in normalen Fällen fast immer gut aus. Die Risiken liegen in den Ausnahmen. Was passiert, wenn kein Bestand 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 kann unter welchen Bedingungen 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 Information kommt, wer sie ändern kann, durch welche Systeme sie geht, 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 angelegt wird. Es muss auch geprüft werden, welche Informationen der Kunde erhält, ob das Lager genaue Aufgaben hat, ob die Rechnungsstellung den Unternehmensrichtlinien entspricht, ob die Bestandsreservierung korrekt angepasst wird und ob der Managementbericht zwischen erfüllten und offenen Bestellungen unterscheidet.

Bei einem Fertigungsunternehmen 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 tatsächlich Daten- und Verantwortungsfehler. Zwei Systeme speichern dieselben Kundendaten, aber es gibt keine klare Regel, welches die vertrauenswürdige Quelle ist. Der Status einer Bestellung ändert sich, aber die Änderung erreicht die Rechnungsstellung nicht. Ein Arbeitsablauf startet automatisch, aber es gibt keine zugewiesene Person, die die Ausnahme bearbeitet.

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 Artikelstämmen, Preisen, Beständen, Kundendaten, Fertigungsparametern 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 hat und ob ein sofortiges Eingreifen erforderlich ist.

Auch nicht-funktionale Anforderungen sind Geschäftsthemen

Die Validierung eines Systementwurfs darf nicht bei den Funktionen aufhören. Möglicherweise verarbeitet das System Bestellungen korrekt, verlangsamt sich jedoch bei einer Belastung am Monatsende. Oder es kann nach einem Serverausfall wiederhergestellt werden, aber die Wiederherstellung dauert acht Stunden, während das Lager keinen zweistündigen Ausfall bewältigen kann.

Verfügbarkeit, Backups, Berechtigungsmanagement, 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 werden.

Das Ergebnis der Validierung sollte eine Entscheidungsgrundlage sein

Am Ende einer guten Validierung steht nicht ein vages „bestanden“. Die Führung muss verstehen, unter welchen Bedingungen der Entwurf funktioniert, welche Risiken bestehen bleiben, welche Prozessänderungen vor der Einführung erforderlich sind und welche Entscheidungen noch getroffen werden müssen.

Es ist sinnvoll, die zu behebenden Fehler, die bewusst eingegangenen Einschränkungen und die zukünftigen Entwicklungsmöglichkeiten separat zu behandeln. Nicht jede Lücke rechtfertigt die Einstellung des Projekts. Eine seltene 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 zu starten, 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 Neugestaltungen, dringende manuelle Korrekturen und unsicheren Betrieb, während das Wachstum des Unternehmens weniger zu einer administrativen Belastung wird.