Wie man risikoarme Entwicklungen plant

Bestellungen eines Webshops kommen an, aber jeden Morgen muss jemand sie manuell in das Verwaltungssystem übertragen. Das Lager sieht andere Bestandsdaten als der Vertrieb, und freitags sammeln drei Personen die Zahlen für den Managementbericht. In einer solchen Situation ist die Frage, wie man risikoarme Entwicklungen plant nicht in erster Linie eine technologische Aufgabe. Zuerst muss man verstehen, warum der tägliche Betrieb so stark von manuellen Übertragungen, Tabellenkalkulationen und dem Wissen einzelner Kollegen abhängt.

Risikominderung bedeutet nicht, dass das Unternehmen keine Veränderungen vornehmen sollte. Es bedeutet, dass die Veränderung einen klaren geschäftlichen Grund, klar definierte Grenzen und überprüfbare Konsequenzen hat. Auch während einer gut geplanten kleineren Entwicklung bleibt das Unternehmen funktionsfähig: Rechnungen werden erstellt, Bestellungen erfüllt, die Produktion wird nicht unterbrochen, und die betroffenen Mitarbeiter wissen, was passiert.

Das Risiko der Entwicklung steckt oft schon im Prozess

Viele Organisationen machen den Fehler, dass sie bei einem ärgerlichen Symptom sofort nach einem System oder einer Automatisierung suchen. Wenn die Rechnungsstellung verzögert ist, wird ein neues Rechnungsmodul angefordert. Wenn es keinen guten Bericht gibt, ein neues Dashboard. Wenn es zu viele E-Mails gibt, wird ein neues Workflow-Management-Tool eingeführt.

Diese Lösungen können gerechtfertigt sein, aber nicht immer. Es kann zum Beispiel sein, dass die Rechnungsstellung verzögert ist, weil die Bestelldaten an drei verschiedenen Stellen erfasst werden und nicht geklärt ist, welche die verlässliche Quelle ist. Das Dashboard würde nur dieselben fehlerhaften oder verspätet erfassten Daten schneller anzeigen.

Das größte Betriebsrisiko ist oft nicht das alte System selbst. Sondern der Prozess, in dem Menschen als Verbindung zwischen Systemen, Abteilungen und Informationsquellen dienen. Wenn ein Mitarbeiter in den Urlaub geht, verlangsamt sich der Prozess. Wenn eine Artikelnummer falsch eingegeben wird, setzt sich der Fehler im Lager, in der Rechnungsstellung oder in der Kundenkommunikation fort. Wenn der Besitzer einer Tabelle nicht erreichbar ist, weiß niemand sicher, welche Version verwendet werden soll.

Deshalb sollte eine risikoarme Entwicklung nicht mit einem Bildschirm oder einer Technologie beginnen, sondern mit einem konkreten Geschäftsprozess.

Wie plant man in der Praxis risikoarme Entwicklungen?

Ein guter Ausgangspunkt ist ein Prozess, der schmerzhaft genug ist, um sich zu lohnen, verbessert zu werden, aber klar genug abgegrenzt ist, um nicht das gesamte Unternehmenssystem auf einmal zu öffnen. Dies könnte die Übergabe von Webshop-Bestellungen an das Lager sein, die Verarbeitung von Lieferantendokumenten, die Verwaltung von Serviceanfragen oder ein regelmäßig manuell erstellter Managementbericht.

Beim ausgewählten Prozess sollte man verfolgen, was tatsächlich passiert. Nicht das, was die Verfahrensanweisung sagt, sondern was die Kollegen Tag für Tag tun. Woher kommen die Informationen? Wer überprüft sie? Wie oft werden dieselben Daten eingegeben? Wo wartet eine Aufgabe auf Genehmigung? Bei welchem Schritt wird telefoniert oder eine E-Mail geschrieben, weil etwas im System nicht ersichtlich ist?

Die Prozesskartierung bringt oft schnell ans Licht, dass ein Schritt keinen wirklichen Zweck mehr hat. Vielleicht wurde eine Tabelle vor Jahren eingeführt, weil das damalige System eine bestimmte Information nicht verarbeiten konnte. Inzwischen hat sich das System geändert, die Tabelle ist jedoch geblieben und erzeugt heute nur noch zusätzliche Überprüfungen, Kopien und Unsicherheiten.

Das Entwicklungsziel sollte in Geschäftssprache formuliert werden. Das Ziel ist nicht, „die Systeme zu integrieren“, sondern beispielsweise, dass die Bestelldaten des Webshops ohne manuelle Eingabe und überprüfbar an das für die Erfüllung zuständige Team gelangen. Es geht nicht darum, eine „KI-Lösung zu erstellen“, sondern darum, dass die Kollegen die Daten in den eingehenden Dokumenten schneller finden, die sie für Entscheidungen benötigen.

Kleinerer Umfang, echtes Ergebnis

Ein zu großer erster Schritt macht das Projekt unberechenbar. Wenn eine Entwicklung gleichzeitig den Vertrieb, das Lager, den Einkauf, die Rechnungsstellung und die Finanzen betrifft, steigt die Anzahl der Entscheidungen schnell an. Jede Ausnahme, alte Regel und unterschiedliche Arbeitsweise erfordert neue Abstimmungen. Bis die Lösung fertig ist, kann sich der geschäftliche Bedarf selbst geändert haben.

Es ist besser, eine erste Phase zu gestalten, die in sich selbst Wert bietet. Zum Beispiel sollte nicht die gesamte Bestellabwicklungskette zuerst umgestaltet werden. Zuerst sollte sichergestellt werden, dass die Bestellungen aus dem Webshop in einheitlicher Form automatisch im internen Betriebssystem erscheinen. In der nächsten Phase kann die Lagerreservierung behandelt werden, dann die Übergabe an den Transporteur oder die Kundenbenachrichtigungen.

Dies ist kein langsamerer Ansatz. Oft bringt er schneller greifbare Ergebnisse, während er die Wahrscheinlichkeit verringert, dass das gesamte Projekt aufgrund einer Annahme in die falsche Richtung geht. Während der Nutzung der ersten Phase zeigt sich nämlich, ob die ursprüngliche Vorstellung korrekt war und mit welchen Ausnahmen tatsächlich gerechnet werden muss.

Die Einschränkung des Umfangs darf nicht bedeuten, dass die spätere Erweiterung ignoriert wird. Die Lösung muss so in die Systemumgebung passen, dass sie später nicht verworfen werden muss. Daher müssen bereits zu Beginn die Datenverantwortlichen, die Systemverbindungen, die Berechtigungen und was als offizielle Geschäftsdaten gilt, geklärt werden.

Das Risiko kann durch Messpunkte gesteuert werden

Eine Entwicklung ist steuerbar, wenn das Management nicht nur sieht, dass sie „in Arbeit“ ist, sondern auch, ob sich der Betrieb dadurch verbessert. Dazu ist kein kompliziertes Indikatorensystem erforderlich. Bei einem Bestellprozess kann die Zeit für die manuelle Dateneingabe, die Anzahl fehlerhafter Bestellungen, die Durchlaufzeit und die Anzahl der Ausnahmen, die von Menschen bearbeitet werden müssen, gemessen werden.

Die Messung muss bereits vor der Änderung beginnen. Wenn es keinen Ausgangswert gibt, kann später nur anhand von Eindrücken darüber gestritten werden, ob sich die Entwicklung gelohnt hat. Es kann auch vorkommen, dass der neue Prozess zunächst langsamer erscheint, weil er Kontrollen sichtbar macht, die zuvor informell oder inkonsistent durchgeführt wurden. Dies ist nicht unbedingt ein Misserfolg. Man muss verstehen, dass die Verlangsamung ein vorübergehender Lerneffekt, eine notwendige Kontrolle oder ein echtes Planungsproblem ist.

Die Bedingungen für den Erfolg müssen im Voraus festgelegt werden. Zum Beispiel: 95 Prozent der täglichen Bestellungen können ohne manuelle Übertragung verarbeitet werden; das Lager sieht denselben Status wie der Kundenservice; die Erstellung des Finanzberichts verkürzt sich von drei Stunden auf dreißig Minuten. Das konkrete Ziel hilft zu entscheiden, wann weitergegangen werden kann und wann noch Verbesserungen erforderlich sind.

Einführung: Nicht alles entscheidet sich am Tag der Installation

Die technisch fertiggestellte Lösung ist noch nicht unbedingt eine funktionierende Geschäftslösung. Bei der Einführung zeigt sich, ob die Ausnahmefälle, die Verantwortungsbereiche und der tägliche Arbeitsrhythmus tatsächlich handhabbar sind. Daher ist es ratsam, den neuen Prozess zunächst in einem begrenzten Umfang zu verwenden: bei einer Produktgruppe, an einem Standort, bei einem Kundentyp oder in einem bestimmten Team.

Ein paralleler Betrieb ist in bestimmten Fällen gerechtfertigt, sollte jedoch nicht unbegrenzt aufrechterhalten werden. Wenn der alte und der neue Prozess zu lange nebeneinander bestehen, arbeiten die Mitarbeiter doppelt, die Daten können abweichen, und niemand weiß, welchem System man glauben soll. Es ist besser, im Voraus festzulegen, wie lange die kontrollierte Probezeit dauert, wer das Ergebnis genehmigt und unter welchen Bedingungen das neue Verfahren zum Standard wird.

Der Wiederherstellungsplan ist ebenfalls Teil des Risikomanagements. Nicht, weil die Entwicklung voraussichtlich scheitern muss, sondern weil der Geschäftsbetrieb geschützt werden muss. Wenn eine Integration fehlerhafte Daten sendet, muss man wissen, wie sie gestoppt werden kann, wie die betroffenen Transaktionen identifiziert werden können und wer über die Korrektur entscheidet. Eine gut dokumentierte Wiederherstellungsmöglichkeit macht die Einführung auch selbstbewusster.

Das Wissen der Menschen sollte kein verborgenes Systemkomponente bleiben

In wachsenden Unternehmen ist es häufig, dass eine Schlüsselperson die Ausnahmen im Kopf behält: welcher Kunde in welchem Format Dokumente erhalten muss, welche Lieferantendaten besonders überprüft werden müssen oder warum eine bestimmte Bestellung nicht automatisch übergeben werden darf. Dies ist wertvolle Erfahrung, aber ein Geschäftsrisiko, wenn sie nur bei einer Person existiert.

Das Ziel einer risikoarmen Entwicklung ist nicht, diesen Kollegen zu ersetzen. Vielmehr soll sein Wissen in überprüfbaren Regeln, sichtbaren Status und gemeinsam nutzbaren Arbeitsabläufen erscheinen. So verbringt er weniger Zeit mit wiederholender Verwaltung und mehr dort, wo tatsächlich Abwägungen, Kundenkenntnisse oder fachliche Entscheidungen erforderlich sind.

Die Dokumentation sollte kurz, aber nützlich sein. Bei einem neuen Prozess muss das Team wissen, was sich geändert hat, was im Fehlerfall zu tun ist, an wen es sich wenden kann und welche Daten nicht frei geändert werden dürfen. Die Klärung der betrieblichen Verantwortung ist mindestens so wichtig wie die eigentliche Entwicklungsaufgabenliste.

Die beste erste Entwicklung ist nicht unbedingt die auffälligste. Oft ist es die wertvollste, die eine tägliche halbstündige Kopie beseitigt, eine blockierte Bestellung sichtbar macht oder den Prozess von einer einzigen Tabelle unabhängig macht. Diese Schritte sparen nicht nur Zeit: Sie liefern den Beweis, dass der Betrieb des Unternehmens kontrolliert und ohne das Risiko des nächsten großen Sprungs entwickelt werden kann.