EDI-Geschäftskontinuität: Nachrichtenflüsse schützen

Bestellungen können weiter eintreffen, während ein ERP-System sechs Stunden lang nicht verfügbar ist. Das eigentliche Risiko besteht darin, nach dem Neustart nicht zu wissen, welche Bestellungen verarbeitet wurden, welche noch warten und welche zweimal übermittelt wurden. EDI-Geschäftskontinuität ist das Betriebsmodell, das während eines Ausfalls die Spur jeder Nachricht bewahrt und eine kontrollierte Wiederaufnahme ermöglicht.

Dieses Modell geht über eine Serversicherung hinaus. Bestellungen, Lieferavise und Rechnungen haben unterschiedliche geschäftliche Auswirkungen. Das Betriebsteam sollte für jeden Dokumenttyp vorab Wartegrenze, Alarmverantwortlichen, Wiederverarbeitungsmethode und Abstimmungsnachweis festlegen.

Inhalt

1. Warum endet ein EDI-Ausfall nicht mit dem Systemneustart?
2. Wie werden RTO und RPO in Ziele für den Nachrichtenfluss übersetzt?
3. Welche Lücken zeigt der Vier-Datensätze-Test?
4. Wie werden Retry, Resend und Reprocess unterschieden?
5. Wie kann ein Hersteller in der Türkei einen Ausfall bewältigen?
6. Wie wird ein EDI-Kontinuitätsplan getestet?

Warum endet ein EDI-Ausfall nicht mit dem Systemneustart?

Ein EDI-Ablauf durchläuft Übertragungs-, Transformations-, Geschäftsregel- und Zielanwendungsebenen. Eine AS2-Verbindung kann funktionieren, während das ERP die Bestellung ablehnt. Das Mapping kann abgeschlossen sein, obwohl die Bestätigung des Handelspartners ausbleibt. Eine grün angezeigte Verbindung beweist nicht, dass der Geschäftsvorgang abgeschlossen ist.

In der Untersuchung des Uptime Institute von 2025 entfielen 23 Prozent der folgenreichen Ausfälle des Jahres 2024 auf IT- und Netzwerkprobleme. Von den Teilnehmern, die die Kosten ihres letzten Ausfalls angaben, nannten 20 Prozent einen Betrag von mehr als 1 Million US-Dollar. 37 Prozent lagen zwischen 100.000 und 1 Million US-Dollar. Diese Werte messen nicht ausschließlich EDI-Ausfälle, verdeutlichen jedoch die finanzielle Bedeutung disziplinierter Wiederherstellung bei digitalen Abläufen.

Bei EDI ist die Wiederherstellung nicht beendet, sobald der technische Dienst wieder läuft. Die wartende Queue muss gezählt, beim Empfänger eingegangene Nachrichten müssen getrennt und die Ergebnisse mit den ERP-Datensätzen abgestimmt werden. Andernfalls kann das Team dieselbe Bestellung zweimal verarbeiten oder ein unbemerkt verlorenes Lieferavis übersehen.

Der EDI-Sicherheitsleitfaden des NIST empfiehlt, Transaktionsprotokolle und Statusrückmeldungen zu nutzen, um verlorene, falsch verarbeitete oder doppelte Nachrichten zu erkennen. Die Wiederherstellung nach einem Netzwerkausfall ohne ausgelassene oder duplizierte Nachrichten wird ebenfalls als eigene Kontrolle behandelt.

Wie werden RTO und RPO in Ziele für den Nachrichtenfluss übersetzt?

Die RTO legt fest, wie lange ein System ausfallen darf, bevor die Auswirkungen nicht mehr vertretbar sind. Die RPO gibt an, wie viele Daten bei der Wiederherstellung neu erzeugt werden dürfen. Ein einziger „EDI-RTO“-Wert verdeckt die unterschiedlichen Folgen einzelner Dokumentabläufe.

Ein Produktionsabruf in der Automobilbranche, eine Einzelhandelsbestellung und eine Rechnung zum Periodenende haben möglicherweise nicht dieselbe Zeitgrenze. Der Betrieb sollte Ziele nach Dokumenttyp, Handelspartner und Annahmeschlusszeit getrennt festlegen. ISO/TS 22317 verlangt, dass eine Geschäftsauswirkungsanalyse Produkte, Dienste, Abhängigkeiten, RTO und geeignete RPO-Anforderungen gemeinsam ermittelt.

Eine praktische Entscheidungsfolge lautet:

1. Welches Geschäftsergebnis stoppt der Ausfall: Produktion, Kommissionierung, Versand, Zahlungseingang oder Berichterstattung?
2. Nach wie vielen Minuten oder Stunden werden die Auswirkungen unvertretbar?
3. Werden Nachrichten in einer sicheren Queue gehalten, und reicht deren Kapazität für die Zieldauer?
4. Welche Kontrollnummer und welche Bestätigung kennzeichnen bei der Wiederaufnahme den letzten nachweislich korrekten Punkt?
5. Welche Dokumente benötigen eine manuelle Freigabe, wenn die Verarbeitungsreihenfolge gestört wurde?

NIS2 Artikel 21(2)(c) führt Geschäftskontinuität, Sicherungsmanagement, Notfallwiederherstellung und Krisenmanagement in derselben Maßnahmengruppe auf. Die Durchführungsverordnung 2024/2690 verlangt außerdem einen schriftlichen Plan für Wiederherstellungsreihenfolge, Ziele, Ressourcen und die Rückkehr von vorübergehenden Maßnahmen zum Normalbetrieb. Auch wenn ein Unternehmen nicht in den Geltungsbereich von NIS2 fällt, kann diese Struktur zur Bewertung seiner EDI-Abhängigkeiten dienen.

Welche Lücken zeigt der Vier-Datensätze-Test?

Prüfen Sie das Schicksal einer EDI-Nachricht anhand von vier Datensätzen. Fehlt einer davon, besteht im Kontinuitätsplan eine Sichtbarkeitslücke.

• Identität: Sind Nachrichten-ID, Kontrollnummer, Absender, Empfänger und Dokumenttyp gespeichert?
• Zeit: Sind Empfang, Transformation, Übergabe an das Zielsystem und Bestätigungszeitpunkt sichtbar?
• Status: Werden technische Übermittlung und geschäftliche Annahme als getrennte Zustände geführt?
• Aktion: Werden handelnde Person, Grund für Retry oder Resend und Ergebnis nach einem Fehler protokolliert?

Dieser Test betrachtet einen Eintrag „Datei gesendet“ nicht als ausreichenden Nachweis. Eine X12-997- oder EDIFACT-CONTRL-Nachricht gibt beispielsweise Auskunft über eine bestimmte Stufe der technischen Annahme. Sie belegt nicht immer, dass der Handelspartner geschäftliche Inhalte wie Menge, Preis oder Lieferdatum akzeptiert hat.

MAP Monitor, die EDI-Überwachungs- und Verfolgungslösung von MAP, zeigt aktuellen Status und Verlauf ein- und ausgehender Dokumente an einer Stelle. Berechtigte Lieferanten können ebenfalls auf diese Daten zugreifen. Diese Sichtbarkeit hilft den Teams, während eines Vorfalls mit einem gemeinsamen Nachrichtendatensatz zu arbeiten. Queueing, automatische Retries und das Verhalten bei der Notfallwiederherstellung müssen für die eingesetzte Integrationsarchitektur dennoch gesondert geprüft werden.

Wie werden Retry, Resend und Reprocess unterschieden?

Eine falsche Wiederholung kann ein Datenproblem verursachen, das teurer ist als der eigentliche Ausfall. Die doppelte Verarbeitung einer Bestellung kann Überproduktion auslösen. Eine doppelte Rechnung verursacht zusätzlichen Aufwand in Buchhaltung und Abstimmung.

Unterscheiden Sie drei Aktionen:

• Retry: Die Übertragung wurde nicht abgeschlossen, und es ist nachgewiesen, dass die Nachricht den Empfänger nicht erreicht hat. Dieselbe technische Zustellung wird erneut versucht.
• Resend: Der Empfänger hat die Nachricht abgelehnt. Die Daten werden korrigiert, Version und Kontrollnummer regelkonform verwaltet und das Dokument erneut gesendet.
• Internal reprocess: Die EDI-Ebene hat die Annahme abgeschlossen, doch ERP, WMS oder eine andere Zielanwendung hat die Verarbeitung abgelehnt. Die Nachricht wird intern erneut verarbeitet, ohne sie nach außen zu senden.

Microsoft empfiehlt in seinem Leitfaden zur EDI-Notfallwiederherstellung, X12- und EDIFACT-Kontrollnummern regionsübergreifend zu synchronisieren. Dadurch sollen beim Wechsel in eine Sekundärumgebung keine doppelten Kontrollnummern entstehen. Die Dokumentation des SAP Business Network zeigt ebenfalls, dass Retry- und Bestätigungsverhalten vom Verbindungstyp abhängen können. Statt Annahmen für jede Plattform zu treffen, sollten Produktdokumentation und Handelspartnervereinbarung geprüft werden.

Der Entscheidungsdatensatz sollte ursprüngliche Nachrichten-ID, Fehlerebene, Zustellnachweis an den Handelspartner, gewählte Aktion und neue Nachrichten-ID enthalten. Begrenzen Sie automatische Retry-Versuche. Tritt derselbe Fehler wiederholt auf, verschieben Sie die Nachricht in eine Prüf-Queue und leiten Sie sie an das verantwortliche Team weiter.

Wie kann ein Hersteller in der Türkei einen Ausfall bewältigen?

Betrachten wir einen hypothetischen Automobilzulieferer in Bursa. Das Unternehmen verarbeitet in einer Schicht 600 ORDERS-, 420 DESADV- und 180 INVOIC-Nachrichten. Die ERP-Verbindung fällt für 90 Minuten aus, während das EDI-Gateway weiterhin Nachrichten empfängt.

Das Team hält zunächst die letzte erfolgreiche Kontrollnummer beim Beginn des Ausfalls fest. Neue ORDERS-Nachrichten werden in einer sicheren Queue gespeichert. Bestellungen mit Einfluss auf den Produktionsplan werden nach Handelspartner und Lieferzeit sortiert. DESADV-Datensätze für bevorstehende Auslieferungen kommen auf eine zweite Arbeitsliste. INVOIC-Nachrichten können bis zum finanziellen Annahmeschluss kontrolliert warten.

Nach Wiederherstellung des ERP ist es riskant, die gesamte Queue mit einem Befehl freizugeben. Das Team verarbeitet zuerst fünf ORDERS-Nachrichten und vergleicht deren Status mit den ERP-Datensätzen. Ist die Kontrolle erfolgreich, fährt es in kleinen Gruppen fort. Nach jeder Gruppe werden angenommene, abgelehnte und wartende Mengen protokolliert.

Anschließend folgen vier Abstimmungen: Anzahl der vom Gateway empfangenen Nachrichten, Anzahl der transformierten Nachrichten, vom ERP erstellte Geschäftsdokumente und gesendete Bestätigungen. Stimmen die Mengen nicht überein, wird die Differenz auf Ebene der Nachrichten-ID untersucht. So wird aus dem 90-minütigen Ausfall keine unübersichtliche Datenbereinigung.

Dieses Szenario ist kein Kapazitätsversprechen. Jedes Unternehmen sollte Queue-Grenze, Schichtvolumen und Prioritätsfolge anhand seiner eigenen Geschäftsauswirkungsanalyse bestimmen.

Wie wird ein EDI-Kontinuitätsplan getestet?

Laut Uptime Institute erlebten ungefähr 40 Prozent der Organisationen in den vorangegangenen drei Jahren einen größeren, durch menschliche Fehler verursachten Ausfall. 85 Prozent dieser Vorfälle standen mit der Nichtbefolgung oder Mängeln von Verfahren in Verbindung. Ein schriftlicher Plan, der nur auf dem Papier bleibt, ist daher ein messbares Risiko.

Planen Sie vierteljährlich eine 60- bis 90-minütige Übung. Unterbrechen Sie in der Testumgebung den ERP-Zugriff oder erzeugen Sie einen bestimmten Mapping-Fehler. Verwenden Sie keine echten Kundendaten. Das Team sollte messen, wie schnell der Alarm entsteht, ein Vorfallverantwortlicher zugewiesen, die Liste wartender Nachrichten erstellt und die kontrollierte Wiederaufnahme abgeschlossen wird.

Bewahren Sie nach der Übung folgende Nachweise auf:

• Erwartete und tatsächliche RTO
• Alter der ältesten Nachricht in der Queue
• Anzahl verlorener, doppelter und in falscher Reihenfolge verarbeiteter Nachrichten
• Zeit zwischen erstem Alarm und Zuweisung des Verantwortlichen
• Dauer bis zum Abschluss der Abstimmung
• Zu aktualisierende Verfahren, Mappings oder Alarmregeln

Wählen Sie als ersten Umsetzungsschritt die drei Dokumentabläufe mit den höchsten geschäftlichen Auswirkungen. Dokumentieren Sie für jeden Ablauf, wie der letzte nachweislich korrekte Datensatz gefunden wird und welche Mengen bei der kontrollierten Wiederaufnahme übereinstimmen müssen. Weitere Inhalte zur EDI-Geschäftskontinuität sowie zu Integration und Lieferketten finden Sie im MAP Blog.