Leitfaden für regulierte Softwareliefermodelle

Ein Upgrade eines Lagersystems verursacht nicht nur dann Probleme, wenn es ausfällt. Es reicht schon, wenn der Kommissionierer zu Beginn der Schicht andere Bestandsdaten sieht als die, die der Vertrieb dem Kunden versprochen hat. Dasselbe gilt für eine Rechnungsintegration, ein Fertigungsterminal oder ein Kundenportal: Eine Softwareänderung greift direkt in den Betrieb ein. Dieser Leitfaden zu geregelten Softwareliefermodellen hilft dabei, dass Releases nicht auf individuellen Heldentaten, sondern auf transparenten Entscheidungen, nachvollziehbaren Prozessen und geschäftlicher Verantwortung basieren.

Geregelte Lieferung bedeutet nicht zwangsläufig langsamere Entwicklung. Es bedeutet, dass eine Organisation genau weiß, was sich ändert, wer es genehmigt hat, welche Auswirkungen zu erwarten sind, wie das Ergebnis überprüft werden kann und was passiert, wenn die Änderung nicht wie erwartet funktioniert. Dies wird besonders notwendig, wenn mehrere Systeme, Abteilungen, Standorte oder externe Partner miteinander verbunden sind.

Nicht die Installation ist die Hauptfrage, sondern das Betriebsrisiko

In vielen Unternehmen beginnt die Softwareveröffentlichung als technisches Ereignis: Eine Funktion ist fertig, der Entwickler lädt sie auf den Server hoch und jemand meldet, dass sie bereit ist. Dies kann bei kleineren, isolierten Anwendungen vorübergehend funktionieren. Bei einem Bestellprozess, der mit einem ERP verbunden ist, einer Lagerintegration oder einer Produktionsdatenerfassung sind die Konsequenzen jedoch zu groß, um dies ausreichend zu sein.

Die richtige erste Frage ist nicht, welches Release-Tool eingeführt werden soll. Vielmehr, was gefährdet ist, wenn diese Änderung fehlerhaft, verzögert oder nur teilweise ausgeführt wird. Kann die Lieferung gestoppt werden? Kann eine Bestellung zu einem falschen Preis ausgehen? Können Transaktionen verloren gehen? Entstehen stundenlange manuelle Korrekturen? Weiß nur eine Schlüsselperson, wie der Zustand wiederhergestellt werden kann?

Anhand der Antworten kann entschieden werden, welches Maß an Kontrolle gerechtfertigt ist. Eine interne, risikoarme Berichtsänderung erfordert ein anderes Verfahren als die Änderung der Datenübertragung zwischen Lagerverwaltung und Bestandsverwaltung. Die Regelung ist dann gut, wenn sie verhältnismäßig ist. Wenn jede kleine Textkorrektur dieselbe Genehmigungskette erhält wie eine Änderung einer Finanzschnittstelle, wird der Prozess schnell umgehbar.

Was macht ein Softwareliefermodell geregelt?

Das geregelte Modell ist kein einzelnes Dokument oder eine genehmigende Person. Es ist ein zusammenhängendes Betriebsregime, in dem der Weg der Änderung vom aufgetretenen Bedarf bis zur Betriebsprüfung nachvollziehbar ist. Es hat vier grundlegende Elemente: die klare Beschreibung der Änderung, die Zuweisung von Verantwortlichkeiten, die angemessene Validierung und das Management der Rücksetzung.

Die Beschreibung der Änderung sollte auch in Geschäftssprache verständlich sein. Es reicht nicht aus, nur „API-Änderung“ zu sagen. Es muss festgehalten werden, welchen Prozess sie betrifft, welches Ergebnis erwartet wird, zwischen welchen Systemen Daten bewegt werden und was als akzeptabler Betrieb gilt. So sprechen der Betrieb, die Entwicklung und der betroffene Geschäftsbereich über dieselbe Änderung.

Verantwortung ist nicht gleichzusetzen mit der technischen Durchführung. Der Entwickler kann für den Code verantwortlich sein, der Betreiber für die Installation, aber der Eigentümer des Geschäftsprozesses kann sagen, ob aus der Bestellung tatsächlich ein fakturierbares und lieferbares Geschäft wurde. Wenn diese Rolle nicht zugewiesen ist, beschränkt sich die Prüfung nach der Inbetriebnahme oft darauf, dass „kein Fehler sichtbar ist“. Das ist nicht dasselbe wie ein ordnungsgemäß funktionierender Prozess.

Die drei anwendbaren Liefermodelle

Es gibt kein einziges ideales Modell, das für alle Organisationen gilt. Die richtige Wahl hängt von der Kritikalität der Systeme, der Häufigkeit der Änderungen, der Größe des Teams und auch davon ab, wie dokumentiert die aktuellen Prozesse sind.

Fallweise, genehmigungsbasierte Releases

In diesem Modell erscheint jede Live-Änderung als separates Änderungsprotokoll. Bestimmte Personen bewerten die Auswirkungen, genehmigen die Installation und überprüfen nach der Inbetriebnahme das Ergebnis. Es eignet sich gut für selten geänderte, geschäftskritische Systeme, wie z.B. Lösungen, die Finanz-, Produktions- oder Kundendaten verarbeiten.

Der Vorteil ist die hohe Transparenz. Der Nachteil ist, dass, wenn die Genehmigungen ausschließlich per E-Mail und informellen Abstimmungen erfolgen, der Prozess langsam und personenabhängig wird. Hier ist nicht mehr Verwaltung das Ziel, sondern die Klärung der Entscheidungspunkte.

Geplante Release-Fenster

Bei den Release-Fenstern legt die Organisation im Voraus fest, wann Änderungen live gehen können. Zum Beispiel werden Änderungen an einem Logistiksystem nur in Zeiten mit geringerer Auslastung, zu festgelegten wöchentlichen oder monatlichen Terminen veröffentlicht. So können Änderungen gebündelt werden, und die erforderlichen Geschäftstests und der Support sind planbar.

Dieser Ansatz ist nützlich, wenn eine Änderung aufgrund mehrerer betroffener Systeme oder Partner Koordination erfordert. Im Gegenzug ist ein separates Verfahren für dringende Korrekturen erforderlich. Wenn jedes Problem das Etikett „dringend“ erhält, verschwindet die Disziplin der Release-Fenster schnell.

Kontinuierliche Lieferung mit eingebauten Kontrollen

Bei häufig wechselnden digitalen Diensten stellen kleinere, häufigere Releases oft ein geringeres Risiko dar als seltene, große Pakete. Dazu sind automatisierte Tests, versionierte Installationsprozesse, separate Umgebungen und eine klare Rücksetzungsmöglichkeit erforderlich. Die Kontrolle besteht hier nicht unbedingt in manueller Genehmigung, sondern in der Erfüllung vordefinierter Qualitätsanforderungen.

Dieses Modell ist nicht deshalb geregelt, weil es schnell ist. Sondern weil jede Veröffentlichung denselben, nachweisbaren Prüfungen unterzogen wird und Ausnahmen sichtbar bleiben. Wenn Tests unvollständig sind, die Installation manuell erfolgt oder es keine zuverlässige Umweltverwaltung gibt, verbirgt das Wort „kontinuierlich“ eher häufige Unsicherheiten.

Der Leitfaden zu geregelten Softwareliefermodellen in der Praxis

Die Einführung sollte nicht mit einer neuen Regelung, sondern mit der Kartierung des aktuellen Änderungswegs beginnen. Nehmen Sie drei kürzliche Veröffentlichungen: eine problemlose, eine verspätete und eine, die Nacharbeit verursacht hat. Wer hat die Änderung angefordert? Wo wurde sie festgehalten? Wer hat darüber entschieden? Gab es eine Testumgebung? Wer hat das Geschäftsergebnis überprüft? Wie lange hat es gedauert, bis klar wurde, dass etwas nicht stimmte?

Daraus wird in der Regel schnell ersichtlich, wo das tatsächliche Risiko entsteht. Häufig ist die technische Installation dokumentiert, aber die geschäftliche Abnahme nicht. Manchmal wissen Entwicklung und Betrieb, was passiert, aber das Lager oder die Finanzen erfahren erst im Nachhinein von der Änderung. Es kommt auch vor, dass die Rücksetzung theoretisch möglich ist, aber noch niemand sie in einer live-ähnlichen Umgebung ausprobiert hat.

Der nächste Schritt ist die Klassifizierung der Änderungen. Es ist nicht erforderlich, ein zu detailliertes Kategoriensystem zu haben, aber es ist notwendig, standardmäßige, wiederkehrende, risikoarme Änderungen; geplante, geschäftlich genehmigungspflichtige Änderungen; sowie außergewöhnliche Fehlerkorrekturen getrennt zu behandeln. Für alle drei sollte es ein kurzes, bekanntes Verfahren geben. Auch außergewöhnliche Änderungen dürfen nicht undokumentiert sein - sie erfordern lediglich schnellere Entscheidungs- und nachträgliche Überprüfungsprozesse.

Die Validierung sollte ein geschäftlicher Nachweis sein

„Die Seite lädt“ oder „kein Fehler im Protokoll sichtbar“ reicht für eine geschäftskritische Änderung nicht aus. Die Validierung ist dann nützlich, wenn sie eine konkrete geschäftliche Aussage überprüft. Bei einer Änderung im Webshop zum Beispiel, dass die Bestellung mit dem richtigen Preis in das ERP aufgenommen wird, eine Bestandsreservierung erzeugt und im Lagerprozess erscheint. Bei einer Fertigungslösung, dass die Rückmeldung der Operation der richtigen Arbeitsnummer und dem Status zugeordnet ist.

Es ist nicht in jedem Fall eine vollständige End-to-End-Testung erforderlich. Das Ziel ist ein dem Risiko entsprechender Nachweis. Bei einer kleineren Änderung können einige gezielte Überprüfungen ausreichen. Bei einer Veröffentlichung, die mehrere Systeme betrifft, kann jedoch ein vorgefertigtes Testdrehbuch, ein benannter geschäftlicher Abnehmer und die Aufzeichnung des Ergebnisses gerechtfertigt sein.

Die Rücksetzung ist kein Notfallplan in der Schublade

Der Rücksetzungsplan sollte nicht bedeuten, dass „im Bedarfsfall die vorherige Version wiederhergestellt wird“. Bei Datenbankänderungen, an externe Systeme gesendeten Transaktionen oder teilweise verarbeiteten Bestellungen kann die Wiederherstellung komplexer sein. Es muss bekannt sein, bis zu welchem Punkt zurückgegangen werden kann, wer die Entscheidung trifft, wie die währenddessen entstandenen Daten behandelt werden und wie die betroffenen Mitarbeiter informiert werden.

Ein guter Plan ist kurz und umsetzbar. Er ist nicht das Versprechen von Fehlerfreiheit, sondern der Nachweis, dass die Organisation im Fehlerfall nicht improvisiert. Die Rücksetzung sollte insbesondere vor neuen Integrationen, größeren Datenänderungen und kritischen Betriebszeiten getestet werden.

Die Kontrolle funktioniert, wenn sie keine separate Welt wird

Die Einhaltung der Release-Regelung sollte nicht allein von der IT durchgesetzt werden. Wenn die Prozessverantwortlichen verstehen, warum sie um Zustimmung gebeten werden, und der Betrieb die erwarteten geschäftlichen Auswirkungen rechtzeitig sieht, wird die Kontrolle Teil des täglichen Betriebs. Wenn die Regelung jedoch ausschließlich aus Formularen besteht, betrachten die Mitarbeiter sie als Last, und die tatsächlichen Entscheidungen werden weiterhin über informelle Kanäle getroffen.

Im Ansatz von CGAT ist die Ordnung der Softwarelieferung daher keine isolierte Entwicklungsfrage. Prozesse, Systeme, Informationsflüsse und Verantwortungsgrenzen bestimmen gemeinsam, welches Maß an Steuerung erforderlich ist. Zuerst sollte geklärt werden, wo Unsicherheit entsteht, und erst dann sollten die technischen und organisatorischen Kontrollen eingeführt werden, die diese tatsächlich reduzieren.

Das beste Release-Modell ist nicht dasjenige, das die meisten Unterschriften oder Automatisierungen enthält. Es ist dasjenige, bei dem nach einer Änderung das Lager, die Produktion, der Kundenservice und die IT mit derselben Sicherheit weiterarbeiten können: Sie wissen, was passiert ist, warum es passiert ist und wie überprüft werden kann, dass der Betrieb tatsächlich in die richtige Richtung geändert wurde.