Wer hat die Kreditprüfung übersprungen? Auftragsabwicklung über fünf Systeme

Ein Kunde ruft am Donnerstagnachmittag an. Er hat 40 Stück einer Komponente bekommen, bestellt hatte er 4. Die Lieferung ist bereits verbaut worden, die Rücksendung wird teuer. Und nebenbei fragt der Innendienst intern: Wieso ist dieser Auftrag überhaupt rausgegangen — der Kunde steht doch seit zwei Monaten auf Kreditsperre?

Drei Stunden später weiß man das Wichtigste. Man weiß nicht, wer die Kreditprüfung übersprungen hat.

Das Muster ist typisch für ein mittelständisches B2B-Handelshaus: rund 180 Mitarbeitende, etwa 40 Mio. Euro Umsatz, technische Komponenten und Maschinen für Industrie- und Handwerkskunden in der DACH-Region. Ein Webshop, ein ERP, ein separates Lagerverwaltungssystem, ein Versand-Tool, ein CRM, ein Finanzsystem. Dazu Excel-Listen, geteilte Postfächer und ein paar Kolleginnen und Kollegen, die wissen, wie es wirklich läuft.

Der Weg eines Auftrags — und wo er unsichtbar wird

Der Ablauf ist unauffällig:

1. Der Kunde bestellt im Webshop, die Bestellung landet in der Shop-Datenbank.
2. Ein Job oder ein Mitarbeiter überträgt sie ins ERP. Status: „Neu".
3. Das Lager prüft die Verfügbarkeit, schreibt in die Lager-Datenbank und meldet einen Status zurück.
4. Passt alles, wird kommissioniert, gepackt und an das Versandsystem übergeben.
5. Das Finanzsystem erzeugt die Rechnung.
6. Das CRM bekommt eine Notiz: „Auftrag ausgeliefert".
7. Bei Rückfragen greifen fünf Abteilungen auf fünf verschiedene Systeme zu.

Jeder Schritt für sich ist sauber. Was fehlt, ist die Klammer. Jedes System kennt seinen eigenen letzten Zustand, keines kennt den Verlauf. Zwischen den Systemen liegen Schnittstellen, die Status übertragen — nicht Ereignisse mit Begründung, sondern Werte, die den vorherigen Wert überschreiben.

Deshalb beginnt bei jeder unangenehmen Frage dieselbe Forensik: Shop-Logs, Änderungshistorie im ERP, Transaktionsprotokolle im Lager, das E-Mail-Archiv, am Ende die privaten Notizen von Kolleginnen. Die Wahrheit lag nirgends, sie musste jedes Mal neu verhandelt werden. Dasselbe Muster in einem SaaS-Unternehmen haben wir in Wer hat was zugesagt? beschrieben — dort geht es um Zusagen, hier um Ware und Geld.

Was diese Suche kostet, wenn man sie hochrechnet

Rechnen wir konservativ: drei Stunden Suche pro strittigem Fall, zwei bis vier Fälle im Monat, beteiligt sind Innendienst, Lagerleitung, Buchhaltung und im Zweifel die Geschäftsführung. Das sind mehrere Personenwochen pro Jahr, die nichts verkaufen und nichts ausliefern.

Der teurere Posten steht daneben. Die Geschäftsführung möchte eine neue Regel: Ab 15.000 Euro Warenwert braucht es eine zweite Freigabe, und bei internationalen Lieferungen soll automatisch ein Zoll-Check laufen. Fachlich sind das zwei Sätze. Technisch heißt es: Schemaänderungen in mehreren Datenbanken, Migrationsskripte, Anpassungen an den Schnittstellen zwischen Shop, ERP, Lager und Versand, Tests über alle Systeme hinweg. Vier bis acht Wochen — und das Restrisiko, dass irgendwo etwas inkonsistent bleibt.

Dazu kommt ein Observability-Stack, der Logs aus fünf Quellen einsammelt, um nachträglich ein Bild zu bauen, das im Moment des Geschehens vollständig vorhanden war und nur nicht festgehalten wurde. Hochverfügbarkeit und Wiederanlauf sind eine Sammlung von Sonderlösungen: Replikation hier, Queue-Backup dort, ein Wiederherstellungsskript, das seit zwei Jahren niemand geprobt hat.

Viel Energie fließt in Systeme, die nur deshalb existieren, weil die eigentliche Wahrheit nirgendwo zentral und unveränderlich liegt.

Der Wissenshüter ist kein Personalproblem

Die erfahrene Sachbearbeiterin weiß, dass bei bestimmten Kunden die Kreditprüfung manuell im Finanzsystem angestoßen werden muss, bevor das Lager loslegt. Der technische Vertrieb weiß, welche Artikel erst nach interner Freigabe rausgehen dürfen. Beides steht nirgends sauber.

Wenn diese Personen im Urlaub sind, stockt der Prozess — oder er läuft weiter und produziert genau den Fall vom Donnerstagnachmittag. Das ist keine Nachlässigkeit von Einzelnen. Es ist eine Geschäftsregel, die nie in ein System gekommen ist, weil es keine Stelle gab, an der sie hingehört hätte. Solange nur Zustände gespeichert werden, gibt es für „unter dieser Bedingung darf nicht weitergegangen werden" keinen natürlichen Ort.

Genau hier setzt Modellierung an, bevor Code entsteht: Event Modeling ist in erster Linie ein Adoption-Werkzeug. Der Wert liegt nicht im Diagramm, sondern darin, dass Vertrieb, Lager und Buchhaltung zum ersten Mal denselben Ablauf mit denselben Begriffen beschreiben.

Derselbe Prozess auf einem Ereignisfundament

Nehmen wir an, die Auftragsabwicklung stünde auf einem Fundament aus Event Sourcing und CQRS. Alles fachlich Relevante wird als unveränderliches Ereignis geschrieben:

• OrderPlaced — Positionen, Kundenreferenz, Lieferadresse, Wunschtermin
• CreditCheckRequested, CreditCheckPassed, CreditCheckFailed
• StockReserved, StockReservationFailed
• PickingStarted, PickingCompleted, PackageCreated
• ShipmentDispatched — mit Sendungsnummer und Dienstleister
• InvoiceGenerated, DeliveryConfirmedByCustomer, ReturnInitiated

Diese Ereignisse landen in einem zentralen, nur anfügbaren Speicher. Es gibt keine führende „aktuelle Bestellung"-Tabelle mehr. Der aktuelle Zustand eines Auftrags ist eine Projektion — eine aus den Ereignissen berechnete Sicht, von denen es beliebig viele geben darf: eine für den Innendienst, eine für das Lager, eine für die Buchhaltung.

Am Donnerstagnachmittag lautet die Frage dann nicht „wo suchen wir?", sondern: zeige alle Ereignisse zu Auftrag 45821 in chronologischer Reihenfolge. Sichtbar wird, dass nie ein CreditCheckPassed existiert hat — die Reservierung lief trotzdem, weil ein Schnittstellenjob den Status ohne Prüfung gesetzt hat. Die Menge stimmt ebenfalls nicht mit OrderPlaced überein. Forensik wird zur Abfrage statt zur Detektivarbeit.

Was dabei dünner wird:

• Fachliche Audit-Logs werden überflüssig, weil der Ereignisstrom das Audit-Log ist. Technische Logs für Infrastruktur und Zugriffe bleiben — die ersetzt das nicht.
• Statussynchronisation zwischen Systemen entfällt weitgehend. Systeme abonnieren die Ereignisse, die sie brauchen, und pflegen ihre eigene Projektion.
• Wiederanlauf wird nicht magisch gelöst, aber das Problem verengt sich: ein Speicher, der wiederhergestellt werden muss, statt fünf Datenbanken, deren Konsistenz zueinander niemand garantieren kann. Backups und geprobte Wiederanläufe bleiben Pflicht.

Warum das strukturell und nicht nur ordentlicher ist, steht ausführlich auf der Seite Event Sourcing.

Warum Änderungen billiger werden

Die Regel „ab 15.000 Euro zweite Freigabe, bei internationalen Lieferungen Zoll-Check" wird auf diesem Fundament so umgesetzt:

• Neue Ereignistypen und Handler kommen dazu: SecondApprovalRequired, SecondApprovalGranted, CustomsCheckTriggered.
• Bestehende Ereignisse bleiben unangetastet. Es gibt keine Migration alter Aufträge.
• Eine neue Projektion „Aufträge mit offener Zweitfreigabe" entsteht, und die Oberfläche für die Genehmiger liest daraus.
• Aufträge, die vor der Regeländerung liefen, bleiben korrekt, weil ihre Geschichte nicht umgeschrieben wird.

Statt eines Umbaus über fünf Systeme ist es eine neue Interpretation derselben Geschichte.

Mit einer Einschränkung, die man kennen sollte: Das gilt, wenn der fachliche Schnitt stimmt. Wenn der Auftrag als ein einziges riesiges Aggregat modelliert wurde, in dem Preisfindung, Lagerlogik und Versand zusammenfallen, ist die Änderung genauso teuer wie eine Schemamigration — nur mit unbekannterem Werkzeug. Der Schnitt entscheidet, nicht die Technologie.

Was das nicht löst

Regeln, die niemand ausspricht, werden nicht sichtbar. Wenn im Modellierungsworkshop niemand sagt, dass bei drei Kunden die Kreditprüfung anders läuft, steht es auch in keinem Ereignis. Das System erzwingt die Klärung an einer Stelle — es ersetzt sie nicht.

Fremdsysteme bleiben Fremdsysteme. ERP, Finanzsystem und der Versanddienstleister werden nicht event-sourced, nur weil man es sich wünscht. Man braucht an ihrer Grenze eine Übersetzungsschicht, die ihre Zustandsmeldungen in fachliche Ereignisse überführt — und die muss man bauen und pflegen. Der Ereignisstrom endet dort, wo die Fremdsysteme anfangen.

Es ist kein Werkzeugkauf. Der aufwendige Teil ist die Einigung darauf, welche Ereignisse fachlich zählen und wie sie heißen. Wer grundsätzlich prüfen will, ob sich das lohnt, findet die Abgrenzung in Event Sourcing ohne Angst.

Die Fragen, die dann kommen

Aufbewahrung. Abgeschlossene Vorgänge dürfen archiviert werden, Snapshots verkürzen das Nachrechnen. Die Frist folgt der Fachlichkeit und der Handelsbilanz, nicht der Bequemlichkeit.

Berechtigungen. Einkaufspreise und Margen stehen in denselben Vorgängen wie Liefermengen. Wer was sieht, wird auf Projektionsebene entschieden, nicht in der Oberfläche — dieselbe Logik wie bei Multi-Tenancy mit Keycloak.

Personenbezogene Daten. Lieferadressen und Ansprechpartner gehören nicht roh in den Strom. Pseudonymisierung oder Crypto-Shredding lösen den Konflikt zwischen Unveränderlichkeit und Löschpflicht; ausführlich steht das im ersten Praxisbeispiel.

Wo man realistisch anfängt

Nicht mit der gesamten Auftragsabwicklung. Vier bis sechs Wochen bis zum ersten produktiven Strom sind machbar, wenn der Zuschnitt eng ist:

1. Eine Domäne wählen, in der die Frage „Was ist passiert?" heute regelmäßig gestellt wird und teuer ist — Auftragsfreigabe und Kreditprüfung sind die üblichen Kandidaten.
2. Die Ereignisse gemeinsam modellieren: Vertrieb, Lager, Buchhaltung, Technik an einem Tisch, auf Papier, bevor gebaut wird. Genau dafür gibt es den Event-Modeling-Sprint.
3. Einen Strom produktiv setzen, mit sauberen Causation- und Correlation-Kennungen von Anfang an. Für die Umsetzung mit einem spezialisierten Ereignisspeicher gibt es das EventSourcingDB-Angebot.
4. Eine Projektion bauen, die eine reale Frage beantwortet — die Zeitleiste eines Auftrags, kein Dashboard.
5. Das Read-Model in ERP und CRM zurückspiegeln, damit die Teams dort bleiben, wo sie arbeiten. Dieselbe schrittweise Logik wie beim Modernisieren eines Monolithen.

Wenn zuerst geklärt werden muss, ob der Zuschnitt überhaupt trägt, ist eine Architektur-Zweitmeinung der günstigere Einstieg als ein Projekt.

Was bleibt

Das ist keine Automatisierung um der Automatisierung willen. Es ist die Reduktion der Reibung, die entsteht, wenn die betriebliche Realität und ihre Abbildung im System auseinanderlaufen. Die Geschichte dessen, was passiert ist, liegt einmal sauber und unveränderlich; aktuelle Zustände, Berichte, Freigabeworkflows, Kundensicht und Audit sind davon abgeleitete, austauschbare Sichten.

Die Prüfung dauert eine Minute: Nehmen Sie die letzte Reklamation, bei der Sie rekonstruieren mussten, was tatsächlich passiert ist. Wie lange hat es gedauert — und wussten Sie am Ende, wer entschieden hat?