Wie man risikoarme Entwicklungen plant

Die Bestellungen eines Webshops kommen an, aber jeden Morgen muss jemand diese 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 verstanden werden, warum der tägliche Betrieb so stark von manuellen Übertragungen, Tabellen und dem Wissen einzelner Kollegen abhängt.

Risikoreduzierung bedeutet nicht, dass das Unternehmen keine Veränderungen vornehmen soll. 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 gestoppt, und die betroffenen Mitarbeiter wissen, was passiert.

Das Risiko der Entwicklung ist oft bereits im Prozess enthalten

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-System eingeführt.

Diese Lösungen können gerechtfertigt sein, aber nicht immer. Es ist zum Beispiel möglich, dass die Rechnungsstellung verzögert ist, weil die Bestelldaten an drei verschiedenen Orten vorhanden sind und nicht klar ist, welche die zuverlässige 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, ist sich 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 verbessert zu werden, aber klar genug abgegrenzt ist, um nicht das gesamte Unternehmensgeschehen auf einmal zu öffnen. Dies könnte die Übergabe von Webshop-Bestellungen an das Lager sein, die Bearbeitung von Lieferantendokumenten, die Verwaltung von Serviceanforderungen oder ein regelmäßig manuell erstellter Managementbericht.

Beim ausgewählten Prozess sollte man verfolgen, was tatsächlich passiert. Nicht das, was das Verfahren sagt, sondern was die Kollegen täglich 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 Prozessabbildung bringt oft schnell ans Licht, dass ein Schritt keinen wirklichen Zweck mehr hat. Möglicherweise 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 können. Es geht nicht darum, „die Systeme zu integrieren“, sondern beispielsweise darum, dass die Webshop-Bestelldaten 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 aus den eingehenden Dokumenten schneller die Daten 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 Vertrieb, Lager, Beschaffung, Rechnungsstellung und Finanzen betrifft, steigt die Anzahl der Entscheidungen schnell. 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 für sich genommen einen Wert bietet. Zum Beispiel sollte nicht die gesamte Auftragsbearbeitungskette zuerst umgestaltet werden. Zuerst sollte nur sichergestellt werden, dass die aus dem Webshop eingehenden Bestellungen in einheitlicher Form automatisch im internen Betriebssystem erscheinen. In der nächsten Phase kann die Lagerreservierung behandelt werden, dann die Übergabe an den Spediteur 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 stellt sich heraus, ob die ursprüngliche Vorstellung richtig 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 von Anfang an die Datenverantwortlichen, die Systemverbindungen, die Berechtigungen und das, was als offizielle Geschäftsdaten gilt, geklärt werden.

Das Risiko kann durch Messpunkte kontrolliert werden

Eine Entwicklung ist steuerbar, wenn das Management nicht nur sieht, dass sie „in Arbeit“ ist, sondern auch, ob sie den Betrieb verbessert. Dazu ist kein kompliziertes Indikatorensystem erforderlich. Bei einem Bestellprozess kann die Zeit für die manuelle Dateneingabe, die Anzahl der fehlerhaften 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. Ohne Ausgangswerte kann später nur auf Grundlage von Eindrücken darüber diskutiert werden, ob die Entwicklung es wert war. 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. Es muss verstanden werden, dass die Verlangsamung ein vorübergehender Lerneffekt, eine notwendige Kontrolle oder ein echtes Planungsproblem ist.

Die Erfolgsvoraussetzungen 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 nötig sind.

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

Die technisch fertige Lösung ist noch keine funktionierende Geschäftslösung. Während der Einführung zeigt sich, ob die Ausnahmefälle, die Verantwortlichkeiten 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 ausgewählten Team.

Ein Parallelbetrieb 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 zu vertrauen ist. Es ist besser, im Voraus festzulegen, wie lange die kontrollierte Testphase dauert, wer das Ergebnis genehmigt und unter welchen Bedingungen das neue Verfahren zum Standard wird.

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

Das Wissen der Menschen sollte nicht ein verborgenes Systemelement bleiben

In wachsenden Unternehmen ist es häufig, dass eine Schlüsselperson die Ausnahmen im Kopf behält: In welchem Format Dokumente an welchen Kunden gesendet werden müssen, 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äftliches Risiko, wenn es nur bei einer Person existiert.

Das Ziel der 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 Administration und mehr dort, wo wirklich Abwägung, Kundenkenntnis oder fachliche Entscheidung erforderlich ist.

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 genauso wichtig wie die eigentliche Aufgabenliste der Entwicklung.

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