Digital Operational Resilience in der Auftragsabwicklung: Updates ohne Ausfallzeit einspielen und Ausfälle überstehen

Digital Operational Resilience in der Auftragsabwicklung bedeutet, dass Aufträge weiter erfasst, kommissioniert und abgerechnet werden, während ein Server, ein Dienst oder ein Rechenzentrum ausfällt. Für die IT-Leitung ist das keine abstrakte Eigenschaft, sondern die Frage, ob der nächste Ausfall eine Störungsmeldung oder ein Krisenstab wird.

Warum die Auftragsabwicklung der falsche Ort für einen Ausfall ist

Wenn die Auftragsabwicklung steht, steht der Betrieb. Wareneingang wartet auf Bestellnummern, Versand auf Lieferscheine, Buchhaltung auf Rechnungen, und der Vertrieb telefoniert Kunden hinterher, deren Aufträge im Nichts verschwunden sind. Was danach kommt, ist schlimmer als der Ausfall selbst: Aufträge, die in der Zwischenzeit auf Zetteln und in E-Mails gelandet sind, müssen nachgepflegt werden, mit allen Tippfehlern und Doppelungen.

Die Ursachen sind seltener spektakulär als gedacht. Auf einen Angriff von außen kommen viele Ausfälle durch ein Update, das in der Nacht eingespielt wurde und morgens die Auftragsmaske leer ließ, oder durch einen vollgelaufenen Datenträger, den niemand überwacht hat. Regelwerke wie DORA für Finanzunternehmen und NIS-2 für kritische Sektoren verlangen inzwischen, dass solche Szenarien geplant und getestet sind. Sinnvoll ist das auch ohne gesetzliche Pflicht.

Redundanz und Entkopplung: wie eine Architektur Ausfälle wegsteckt

Redundanz heißt, dass die Systeme der Auftragskette mehr als einmal laufen, am besten in getrennten Rechenzentren oder Zonen, mit einer Datenbank, die ihren Stand fortlaufend an eine zweite Instanz weitergibt. Fällt eine Instanz aus, übernimmt die andere; die Bearbeitung wird langsamer, aber sie läuft.

Entkopplung verhindert, dass ein Fehler in einem Glied die ganze Kette anhält. Auftragserfassung, Zahlungsabwicklung und Versand sprechen nicht direkt miteinander, sondern über eine Warteschlange. Ist der Zahlungsdienst gestört, sammeln sich die Aufträge in der Warteschlange und werden abgearbeitet, sobald er zurück ist. Nichts geht verloren, niemand tippt nach.

Beides nützt nur, wenn die Umschaltung ohne Menschen funktioniert. Ein Failover, der einen Anruf beim Dienstleister voraussetzt, ist kein Failover, sondern eine Hoffnung mit Telefonnummer.

Altsysteme: das größte Risiko für die Betriebskontinuität

Ein gewachsenes ERP auf einem einzelnen Server lässt sich selten redundant auslegen; der Hersteller sieht es nicht vor, die Lizenz auch nicht. Solche Systeme sind der klassische Single Point of Failure der Auftragskette, und sie werden gern übersehen, weil sie seit Jahren laufen.

Der gangbare Weg ist die schrittweise Modernisierung: Zuerst wird die Auftragserfassung, der am stärksten frequentierte Teil, als eigener Dienst herausgelöst und redundant betrieben. Das Altsystem bleibt als Backend, angebunden über eine Schnittstelle, die Aufträge puffert, wenn es nicht erreichbar ist. So gewinnt die Kette an der Stelle Ausfallsicherheit, an der sie am meisten wert ist, ohne dass das ERP an einem Wochenende ersetzt werden muss.

Updates ohne Ausfallzeit einspielen: die Nagelprobe der Redundanz

Eine redundante Architektur zahlt sich nicht erst im Ernstfall aus, sondern bei jedem Release. Wer zwei Instanzen hat, aktualisiert erst die eine, prüft sie unter echtem Verkehr und nimmt dann die zweite dran. Läuft etwas schief, bekommt die alte Version den Verkehr zurück, und niemand hat es gemerkt. Voraussetzung sind Datenbankänderungen, die mit der alten und der neuen Anwendungsversion funktionieren, und eine Staging-Umgebung, auf der das Update vorher gegen produktionsnahe Daten gelaufen ist.

Wer Updates dagegen nachts mit Wartungsfenster einspielt, testet seine Resilienz jedes Mal im Blindflug. Der Aufwand für den ausfallfreien Weg ist einmalig; der Aufwand für ein schiefgegangenes Wartungsfenster wiederholt sich.

Messen, ob es wirklich hält

Zwei Kennzahlen reichen für die Steuerung: die Recovery Time Objective (RTO), also wie lange die Auftragsabwicklung höchstens stehen darf, und die Recovery Point Objective (RPO), also wie viele Minuten an Aufträgen im schlimmsten Fall verloren gehen dürfen. Beide legt die Geschäftsführung fest, nicht die IT. Danach wird geprüft, ob die Architektur das hergibt: Schalten Sie in einem Test die primäre Datenbank ab und stoppen Sie die Zeit. Wer das noch nie gemacht hat, weiß seine tatsächliche RTO nicht.

Wie dataso den Betrieb übernimmt

Wir bauen die Auftragskette redundant und entkoppelt, betreiben sie auf Infrastruktur in Deutschland mit Rund-um-die-Uhr-Monitoring, geprüften Backups und verbindlichen Reaktionszeiten und spielen Updates über Staging und wechselnde Instanzen ein. Grenze ehrlich benannt: Die Reaktionszeit garantieren wir, die Lösung nach bestem Bemühen. Ein Altsystem, das nicht redundant laufen kann, machen wir nicht magisch ausfallsicher; wir stellen die Auftragserfassung davor.

Der nächste Schritt

Schreiben Sie für Ihre Auftragskette auf, welches System bei einem Ausfall alles anhält und wann Sie dessen Umschaltung zuletzt getestet haben. Wenn die Antwort „nie“ lautet, gehen wir den Plan in einer halben Stunde mit Ihnen durch: Potenzial-Check buchen.