ERP-Ausfall: Shop im Notbetrieb verkaufsfähig halten

Die Rechnung fällt in drei Teilen an, und der sichtbarste Teil ist selten der größte. Zuerst fehlt der Umsatz der Stunden, in denen niemand bestellen konnte. Dann folgt die Nacharbeit: Anfragen, die per Telefon und E-Mail hereinkommen, von Hand erfasste Aufträge, Bestandskorrekturen und Gutschriften. Zuletzt kommt der Vertrauensverlust bei Stammkunden, die im B2B ihre Beschaffung an Ihren Kanal gehängt haben. Die Größenordnung ist erheblich: In der aktuellen Auswertung liegt der letzte größere Ausfall bei 57 Prozent (Uptime Institute, 2026) der Befragten über 100.000 US-Dollar, und bei jedem Fünften über einer Million US-Dollar. Im deutschen B2B-Handel steht dem ein Markt gegenüber, der 2024 rund 509 Milliarden Euro erreichte und um 7 Prozent wuchs (ECC Köln) - Ausfallzeit trifft hier auf Volumen, das sich nicht beliebig nachholen lässt.

Bemerkenswert ist, wie viel davon organisatorisch bedingt ist. Rund 60 Prozent (Uptime Institute, 2019) der Befragten waren der Ansicht, ihr letzter größerer Ausfall hätte sich mit besserem Management, besseren Verfahren oder einer besseren Konfiguration verhindern lassen. Übertragen auf die Schnittstellenanbindung heißt das: Der Unterschied zwischen einem Shop, der während eines achtstündigen Wartungsfensters still steht, und einem, der weiterverkauft, liegt selten in der Technik. Er liegt in der Frage, ob jemand vorher entschieden hat, was ohne ERP-Antwort passieren soll. Wer diese Entscheidung nicht trifft, überlässt sie dem Standardverhalten der Bibliothek, die den Aufruf ausführt - und das lautet in aller Regel: Ausnahme werfen, Seite abbrechen.

Ein zwischengespeicherter Wert ohne Alterskennzeichnung ist im Notbetrieb gefährlicher als gar kein Wert, weil er Aktualität vortäuscht. Deshalb bekommt jeder gespiegelte Datensatz zwei zusätzliche Felder: den Zeitpunkt der letzten Bestätigung durch das ERP und die Quelle der Bestätigung. Aus beidem lässt sich im Shop eine verständliche Aussage bilden, etwa dass der Bestand vom Vormittag stammt. Das ist ehrlicher als eine Zahl ohne Kontext und erfahrungsgemäß besser als eine Fehlermeldung. Wichtig ist die Staffelung nach Datenart: Ein Preis, der seit vier Stunden nicht bestätigt wurde, ist meist unkritisch, ein Bestand desselben Alters ist es nicht. Wie stark Bestände auseinanderlaufen, hängt an der Lagerstruktur; der Beitrag zur Bestandssynchronisation über mehrere Lager beschreibt die Mechanik im Normalbetrieb, die im Notbetrieb nur noch einseitig läuft.

Zwei Prüfungen im B2B-Checkout hängen besonders eng am ERP, und beide brechen ohne Vorkehrung den Kauf ab. Die erste ist die Bonität. Ohne Antwort auf die Frage nach Limit und offenen Posten fällt der Rechnungskauf weg, und mit ihm in vielen Sortimenten der größte Teil des Umsatzes. Die konservative Regel lautet: Rechnungskauf bleibt möglich, solange der Bestellwert eine aus dem Spiegel abgeleitete Schwelle nicht überschreitet, etwa den zuletzt bekannten freien Rahmen abzüglich eines Puffers und begrenzt auf einen Höchstbetrag je Kunde und Tag. Alles darüber wird angenommen, aber als freigabepflichtig markiert. Die Mechanik der Prüfung im Normalbetrieb beschreibt der Beitrag zum Kreditlimit-Check im B2B-Checkout; im Notbetrieb ändert sich nicht die Logik, sondern die Datenquelle und die Schwelle.

Die zweite Prüfung ist die Steuerfindung. Ob eine Lieferung mit deutschem Steuersatz, als innergemeinschaftliche Lieferung oder im Reverse-Charge-Verfahren abzurechnen ist, entscheidet im Normalfall das ERP anhand von Kundenstamm, Lieferland und geprüfter USt-IdNr. Fällt diese Auskunft aus, ist die belastbare Rückfallebene das zuletzt bestätigte Kennzeichen je Kunde und Lieferland samt Prüfdatum. Weicht die aktuelle Bestellung davon ab - anderes Lieferland, neue Lieferadresse, erstmalige Bestellung -, wird der Auftrag angenommen und zur kaufmännischen Prüfung markiert, statt eine Steuerentscheidung zu erfinden. Die Details der Findung stehen im Beitrag zur Steuerfindung im B2B-Shop. Für den Notbetrieb zählt vor allem, dass die Rechnung erst nach dem Wiederanlauf erzeugt wird.

Der Wiederanlauf ist der Teil, an dem die meisten Notbetriebe scheitern, weil er in der Ruhe der Planung harmlos aussieht. Drei Regeln entscheiden über das Ergebnis. Erstens die Reihenfolge: Aufträge desselben Kunden müssen in Eingangsreihenfolge übergeben werden, sonst greifen Kreditrahmen und Nummernkreise in der falschen Abfolge. Zweitens die Drosselung: Ein gerade wieder angelaufenes ERP verträgt keinen Stoß von mehreren tausend Aufträgen. Drittens der Duplikatschutz. Ein Zeitüberschreitungsfehler sagt nicht, ob das ERP den Auftrag angelegt hat; ein erheblicher Teil der Fehler in serviceorientierten Architekturen ist vorübergehender Natur und damit wiederholbar - aber nur, wenn der Empfänger idempotent ist. Die Muster dafür beschreibt der Beitrag zu Idempotenz und Retry-Strategien.

Nach dem Nachfahren folgt der Abgleich, und er ist keine Formsache. Verglichen werden Spiegel und ERP für Bestände, Preise, Kreditrahmen und Auftragsstatus; jede Abweichung wird protokolliert und einer Zuständigkeit zugewiesen. Typische Funde sind Artikel, deren Bestand während der Blindphase in einem anderen Kanal verkauft wurde, Preisänderungen, die im ERP gepflegt, aber nicht übertragen wurden, und Aufträge, die doppelt angelegt aussehen, aber unterschiedliche Idempotenzschlüssel tragen. Am Ende steht ein Bericht mit Dauer der Blindphase, Zahl der gepufferten Aufträge, Zahl der Abweichungen und der Zeit bis zum vollständigen Abgleich. Wie sich diese Kennzahlen dauerhaft sichtbar machen lassen, steht im Beitrag zu Observability für Schnittstellen. Weil Gartner für 2025 erwartete, dass rund 80 Prozent (Gartner 2020) der B2B-Kaufinteraktionen in digitalen Kanälen stattfinden, ist der Statuskanal zum Kunden Teil des Wiederanlaufs und nicht sein Anhang.