Vom Auftragseingang bis zur bezahlten Rechnung: ein Verlauf für jeden Auftrag.
Order-to-Cash, Procure-to-Pay und der Weg vom Serviceauftrag zur Rechnung führen durch ERP, CRM, Webshop, Lager, Transport und Buchhaltung. Wir verbinden diese Systeme über dokumentierte APIs und Ereignisse. Jeder Auftrag hat dann einen Status, der überall gleich ist. Jede Ausnahme geht an einen KI-Agenten, der eine Lösung vorbereitet, und ein Mensch gibt sie frei.
Für Betriebe und öffentliche Auftraggeber in Belgien, deren Aufträge und Rechnungen durch ERP, Webshop, Lager und Peppol laufen, oft mit Kunden auch in Deutschland, Luxemburg oder den Niederlanden.
Ein Kundenauftrag, eine Bestellung beim Lieferanten oder ein Serviceauftrag wird einmal in dem System erfasst, das dafür maßgeblich ist. Dokumentierte APIs und Ereignisse verteilen ihn an die übrigen Systeme. Aus den Statusmeldungen entsteht je Auftrag ein Verlauf. Scheitert ein Schritt oder überschreitet er eine Toleranz, trägt ein KI-Agent den Kontext zusammen und schlägt eine Lösung vor. Erst wenn ein Mensch zustimmt, wird sie im maßgeblichen System ausgeführt. Rechnungen laufen als strukturierte E-Rechnungen und werden abgeglichen, und die Prozessverantwortlichen behalten Durchlauf und Schnittstellen im Blick.
Vorher und nachher
Was sich im Alltag von Verkauf, Lager und Buchhaltung ändert
Heute
Mit dem System
Heute
Heute: Bei jeder Übergabe neu getippt
Ein Auftrag aus dem Webshop oder vom Außendienst wird im ERP ein zweites Mal erfasst. Liefer- und Rechnungsangaben überträgt jemand von Hand in Lagerverwaltung, Transport und Buchhaltung.
Mit dem System
Mit dem System: Einmal erfasst, überall verfügbar
Aufträge, Lieferungen und Rechnungen entstehen in dem System, dem sie gehören, und werden als Ereignis veröffentlicht. Die anderen Systeme abonnieren dieses Ereignis, statt die Daten neu einzutippen.
Heute
Heute: Der Stand der letzten Nacht
Schnittstellen laufen einmal pro Nacht im Stapel. Kundendienst, Planung und Buchhaltung arbeiten deshalb mit unterschiedlichen, überholten Ständen ein und desselben Auftrags. Wer wissen will, wo eine Lieferung bleibt, bekommt einen Rückruf.
Mit dem System
Mit dem System: Ein Stand für alle
Jeder Auftrag hat einen Verlauf, der sich aus den Ereignissen aller beteiligten Systeme zusammensetzt. Kundendienst, Planung und Buchhaltung sehen dieselben Fakten, und eine Serviceassistenz kann Fragen zum Stand daraus beantworten.
Heute
Heute: Klärung per E-Mail
Fehlbestände, Preisabweichungen, missglückte Zustellungen und abgelehnte E-Rechnungen klärt man per E-Mail und Tabelle. Wer was entschieden hat, weiß hinterher niemand.
Mit dem System
Mit dem System: Ausnahmen kommen mit einem Vorschlag
Ein KI-Agent sammelt die Daten hinter jeder Ausnahme und schlägt eine Lösung vor. In der Klärungsliste entscheidet ein Mensch, ob er den Vorschlag übernimmt, anpasst oder verwirft, und diese Entscheidung bleibt dokumentiert.
Heute
Heute: Widersprüchliche Stammdaten
Ein Kunde, ein Lieferant, ein Artikel oder ein Preis steht in mehreren Systemen mit verschiedenen Werten. Wer festlegt, welcher Wert gilt, ist nicht geregelt.
Mit dem System
Mit dem System: Klare Zuständigkeit für Stammdaten
Für Kunden, Lieferanten, Artikel und Preise ist jeweils ein maßgebliches System vereinbart, mit einer namentlich benannten verantwortlichen Person. Dubletten und Widersprüche landen bei ihr, statt weiter hinten im Prozess stillschweigend korrigiert zu werden.
Heute
Heute: Jede Änderung, eine Schnittstelle mehr
Ein neuer Verkaufskanal, ein Marktplatz oder eine weitere Gesellschaft bringt eine zusätzliche Punkt-zu-Punkt-Verbindung. Dazu kommen die Peppol-Pflicht in Belgien und Kunden in Deutschland, die oft eine XRechnung erwarten: Jeder Prozess braucht so noch ein strukturiertes Format und ein Netzwerk mehr.
Mit dem System
Mit dem System: Neue Anschlüsse auf denselben Verträgen
Ein neuer Kanal, eine weitere Gesellschaft oder ein E-Rechnungsnetz wird einmal an die dokumentierten APIs und Ereignisse angeschlossen, nicht an jedes System für sich.
Workflow
So läuft ein Auftrag durch die Systeme
Bei sauberen Daten läuft der Hauptweg ohne Handarbeit. Gibt es bei Auftrag, Lieferung oder Rechnung eine Abweichung, bringt die Klärungsschleife den Fall mit Belegen und Vorschlag zu einem Menschen. Die freigegebene Korrektur fließt über dieselbe Integrationsschicht zurück.
Beispielhafter Ablauf
7 Schritte · 1 menschliche Prüfung
Legende
System
Agent
Person
Menschliche Prüfung
Ausnahmepfad
Vernetzte Abläufe: Beispiel mit Klärungsschleife
Diagramm als Text lesen
Der Hauptweg beginnt damit, dass ein Geschäftsereignis einmal im maßgeblichen System erfasst wird. Es wird über APIs und Ereignisse an die übrigen Systeme verteilt, und je Auftrag entsteht ein Verlauf. Es folgen Fakturierung, Abgleich und Zahlung. Am Ende prüfen Prozessverantwortliche den Durchlauf und beheben die Ursachen von Ausnahmen.
Scheitert ein Schritt, kommt er zu spät oder liegt er außerhalb der Toleranz, zweigt die Ausnahme nach dem Verlaufsschritt vom Hauptweg ab. Ein KI-Agent sammelt den Kontext und macht einen Vorschlag, und eine Person entscheidet, ob sie ihn übernimmt, anpasst oder verwirft. Die freigegebene Aktion läuft im maßgeblichen System und kehrt als neues Ereignis zum Verteilungsschritt zurück.
Der menschliche Kontrollpunkt ist die Freigabe: Ohne einen Menschen gibt es keine Finanzbuchung, keine Änderung von Preis oder Kreditlimit und keine Zusage an Kunden.
01
Schritt 1: Einmal erfassenSystem
Ein Kundenauftrag aus Webshop, Marktplatz, EDI oder Außendienst, eine Bestellung beim Lieferanten oder ein Serviceauftrag entsteht in dem System, dem er gehört. Dieses System veröffentlicht ein Geschäftsereignis im CloudEvents-Format, beschrieben in einem AsyncAPI-Vertrag. Papier- und PDF-Aufträge sowie Lieferantenrechnungen gehen vorher durch die Dokumentenverarbeitung mit KI.
02
Schritt 2: Über APIs und Ereignisse verteilenSystem
Die Integrationsschicht stellt das Ereignis den Systemen für Lager, Transport, Buchhaltung und CRM zu, jeweils über deren dokumentierte API (OpenAPI). Die Empfänger arbeiten idempotent: Kommt eine Nachricht doppelt an, entsteht trotzdem keine zweite Sendung und keine zweite Rechnung. Was sich nicht zustellen lässt, wartet in einer eigenen Fehlerablage darauf, erneut eingespielt zu werden.
03
Schritt 3: Einen Verlauf je Auftrag bildenSystem
Die Statusmeldungen aller Systeme (bestätigt, kommissioniert, verschickt, geliefert, fakturiert, bezahlt) werden über die Geschäftsreferenz zu einem Verlauf verknüpft. Regeln für Meilensteine und Toleranzen melden eine Ausnahme, wenn ein Schritt scheitert, zu spät kommt oder nicht stimmt. Typische Fälle sind ein Fehlbestand, ein Preis außerhalb der vereinbarten Toleranz, eine missglückte Zustellung oder eine abgelehnte E-Rechnung.
Für jede Ausnahme holt sich ein KI-Agent, was er aus den beteiligten Systemen braucht: Auftrag, Lagerbestand, Preisabsprache, Status beim Spediteur und die Konditionen des Kunden. Er schlägt eine Lösung vor und legt Begründung und verwendete Daten offen. Das kann ein Ersatzartikel sein, ein korrigierter Preis, ein neuer Liefertermin oder eine berichtigte Rechnung.
Ausnahmepfad: Schritt gescheitert oder Toleranz überschritten
05
Schritt 5: Innerhalb der Freigabegrenzen freigebenPerson
Eine Person aus Kundendienst, Logistik oder Buchhaltung sieht Ausnahme, Belege und Vorschlag in der Klärungsliste. Sie übernimmt den Vorschlag, passt ihn an oder verwirft ihn. Die freigegebene Aktion läuft über die API des maßgeblichen Systems, das die Änderung als neues Ereignis veröffentlicht.
Ausnahmepfad: Schritt gescheitert oder Toleranz überschritten· Zurück zu Schritt 2
Menschliche Prüfung
Ohne Freigabe bucht ein Agent keine Finanztransaktion, ändert keinen Preis und kein Kreditlimit und sagt einem Kunden nichts zu. Freigabegrenzen je Aktionsart legen fest, wer zustimmen muss. Alle Vorschläge und Entscheidungen landen im Protokoll.
Ausgangsrechnungen gehen als strukturierte E-Rechnung im Format Peppol BIS Billing 3.0 nach EN 16931 aus dem ERP an einen Peppol-Zugangspunkt. Eingangsrechnungen von Lieferanten werden mit Bestellung und Wareneingang abgeglichen. Mit dem Zahlungsstatus von Bank oder Zahlungsdienstleister ist der Verlauf abgeschlossen.
07
Schritt 7: Abläufe prüfen, Ursachen behebenPerson
In festen Abständen sehen sich Prozessverantwortliche und Integrationsteam die Ausnahmen nach Grund, die Schnittstellenfehler und die Stammdatenkonflikte an. Sie beheben die Ursache dort, wo sie entsteht, sei es in einem Stammdatensatz, einer Toleranzregel oder einem Mapping. So muss niemand dieselbe Ausnahme wieder und wieder klären.
Komponenten
Was wir bauen würden
01
Ereignisbasierte Integrationsschicht
APIs und Ereignisse zwischen ERP, CRM, Webshop, Lager, Transport und Buchhaltung, zuerst als Vertrag beschrieben (Contract-first) in OpenAPI und AsyncAPI mit CloudEvents-Hülle. Gebaut auf Ihrer vorhandenen Integrationsplattform oder cloudnativ.
Je Datenobjekt ein vereinbartes maßgebliches System und eine verantwortliche Person, Abgleichregeln für Kunden, Lieferanten und Artikel sowie Berichte über Dubletten und Widersprüche an die Verantwortlichen.
Ein Dienst, der Ereignisse je Auftrag oder Anfrage zu einem Verlauf verknüpft, Regeln für Meilensteine und Toleranzen anwendet und den Prozessverantwortlichen Durchlauf und Ausnahmen zeigt.
Eine Liste offener Ausnahmen mit gesammeltem Kontext und dem Vorschlag des Agenten, dazu die Aktionen Übernehmen, Anpassen und Verwerfen. Die Freigabegrenzen je Aktionsart greifen dort, wo die Aktion tatsächlich ausgeführt wird.
Rechnungen nach Peppol BIS Billing 3.0 und EN 16931 im UBL-Format, vor dem Versand validiert und über einen Zugangspunkt verschickt und empfangen. Abgelehnte Rechnungen landen in der Klärungsliste.
Überwachung und Alarme je Schnittstelle, Betriebshandbücher für das Betriebsteam und kontrolliertes Wiedereinspielen fehlgeschlagener Nachrichten. Bereitgestellt als Infrastructure as Code in Ihrer Cloud-Umgebung.
Einkaufsbestellungen und Bestätigungen der Lieferanten
Serviceaufträge und Berichte aus dem Außendienst
Sendungsverfolgung und Zustellmeldungen der Spediteure
Peppol-E-Rechnungen und Statusantworten
Kontoauszüge und Zahlungsmitteilungen
Kern der Lösung
Vernetzte Abläufe
Angebundene Systeme
SAP S/4HANA für Verkauf, Einkauf und FinanzenPlattformSAP
Salesforce mit Sales, Service und Commerce CloudPlattformSalesforce
Odoo mit Verkauf, Einkauf, Lager und BuchhaltungPlattformOdoo
Webshop-Plattformen, Marktplätze und APIs der Spediteure
Systeme für Lagerverwaltung und Transport
Banken, Zahlungsdienstleister und Peppol-Zugangspunkt
PIM-System und Datenplattform
Kontrollen
Eingebaute Kontrollen
Zugriffsgrenzen
Jede Integration und der KI-Agent haben je System eine eigene Dienstidentität, die nur die nötigen API-Operationen erlaubt. Lesen darf der Agent systemübergreifend, um Kontext zu sammeln. Schreiben kann er nur über eine kurze Liste genehmigter Aktionen, die die API des maßgeblichen Systems ausführt, nie über einen direkten Datenbankzugriff.
Menschliche Prüfung
Mit den Prozessverantwortlichen legen wir je Aktionsart fest, was der Agent nur vorschlagen darf, was ein Teammitglied freigibt und wofür es eine zweite Freigabe braucht. Finanzbuchungen, Preis- und Kreditlimitänderungen sowie Zusagen an Kunden warten immer auf einen Menschen. Kleine, umkehrbare Aktionen wie das erneute Senden einer fehlgeschlagenen Nachricht dürfen ohne Freigabe laufen, wenn die Verantwortlichen zustimmen.
Nachvollziehbarkeit
Ereignisse, Vorschläge, Freigaben, Ablehnungen und ausgeführte Aktionen protokollieren wir zur Referenz des Auftrags oder der Anfrage, zusammen mit den Daten, die der Agent genutzt hat, der Modell- und Prompt-Version und der Person, die freigegeben hat. So lässt sich eine strittige Rechnung oder eine Reklamation Schritt für Schritt zurückverfolgen.
Datenschutz
Kontaktdaten von Kunden und Lieferanten gehen nur an die Systeme, die sie brauchen. Der Verlauf speichert Geschäftsreferenzen und Status, keine vollständigen Datensätze, und Protokolle bleiben so lange erhalten, wie Sie es festlegen. Verarbeitet wird in der vereinbarten Region.
KI-Transparenz
In der Klärungsliste sind Vorschläge des Agenten klar als solche markiert, mit Belegen und Begründung daneben. Maßgeblich bleiben die Quellsysteme: Der Verlauf gibt wieder, was diese Systeme melden, und setzt sich nie über sie hinweg.
Kennzahlen
Was wir messen würden
Die Messgrößen stimmen wir in der Analyse mit Ihnen ab. Den Ausgangswert nehmen wir aus Ihren heutigen Protokollen von Systemen und Schnittstellen, noch bevor wir etwas umstellen.
Was wir messen würden
Kennzahl
Warum sie zählt
Wie wir sie messen würden
01Durchlaufzeit je Auftrag
Warum sie zähltDiese Zahl bemerken Kunden zuerst, und sie zeigt, wo Aufträge liegen bleiben.
Wie wir sie messen würdenTage zwischen Auftragseingang und Lieferung sowie zwischen Auftragseingang und Zahlung, getrennt nach Kanal und Gesellschaft, aus den Verlaufsereignissen.
02Aufträge ohne Handarbeit
Warum sie zähltMacht sichtbar, welcher Teil des Geschäfts mit sauberen Daten und abgestimmten Regeln auskommt.
Wie wir sie messen würdenAnteil der Aufträge und Anfragen, die ganz ohne Eingriff und ohne Ausnahme bis zur Zahlung durchlaufen, gemessen am Verlauf.
03Ausnahmen nach Grund und Lösungsdauer
Warum sie zähltSagt Ihnen, welche Ursachen Sie zuerst angehen sollten und ob die Klärungsliste nachkommt.
Wie wir sie messen würdenZahl der Ausnahmen je Grundcode und Zeit von der Erkennung bis zur umgesetzten Lösung, aus den Protokollen der Klärungsliste.
04Ablehnungsquote der E-Rechnungen
Warum sie zähltAbgelehnte Rechnungen verzögern die Zahlung und gehen meist auf Fehler in Stammdaten oder Zuordnungen zurück.
Wie wir sie messen würdenAnteil abgelehnter E-Rechnungen beim Versand und beim Empfang, nach Grund, laut den Rückmeldungen des Peppol-Zugangspunkts.
05Schnittstellenfehler und Behebungszeit
Warum sie zähltZeigt, ob die Integrationsschicht verlässlich arbeitet und Fehler rasch auffallen und behoben werden.
Wie wir sie messen würdenFehlgeschlagene Nachrichten je Schnittstelle und die Zeit bis zum erfolgreichen Wiedereinspielen, aus dem Monitoring der Integration.
06Doppelte und widersprüchliche Stammdaten
Warum sie zähltDie meisten Ausnahmen haben ihren Ursprung in Daten, die von System zu System abweichen.
Wie wir sie messen würdenZahl offener Dubletten und abweichender Werte, je System und Datenobjekt, aus den Abgleichberichten.
Ziele werden erst nach einer Ausgangsmessung festgelegt.
Einführung
Einführung in Etappen
Phase 01
Analyse und Prozesskarte
Ein Prozess, etwa Order-to-Cash für einen Verkaufskanal, und eine Art von Ausnahme. Wir halten fest, welche Systeme, Schnittstellen und Datenverantwortlichen beteiligt sind und wie Ausnahmen heute gelöst werden.
Abschlusskriterien
Prozess, Systeme und Datenverantwortliche dokumentiert
Erste Ausnahmeart und Freigabegrenzen abgestimmt
Ausgangswert aus den heutigen Protokollen gemessen
Phase 02
Integration und Verlauf
Dokumentierte APIs und Ereignisse für die betroffenen Systeme. Der Verlauf läuft parallel zu den bestehenden Schnittstellen mit, ohne sie zu verändern.
Abschlusskriterien
Ereignisverträge veröffentlicht und versioniert
Verlauf stimmt bei Stichproben mit den maßgeblichen Systemen überein
Wiedereinspielen und Betriebshandbücher getestet
Phase 03
Pilot mit der Klärungsliste
Der Agent schlägt Lösungen für die gewählte Ausnahmeart vor, und jeder Vorschlag braucht eine menschliche Freigabe. Wir vergleichen die Vorschläge mit dem, was das Team selbst entschieden hätte.
Abschlusskriterien
Vorschläge erfüllen die vereinbarten Qualitätskriterien
Freigabegrenzen und Freigebende je Aktionsart festgelegt
Buchhaltung und interne Kontrolle haben den Prüfpfad abgenommen
Phase 04
Ausbauen und Altes abschalten
Weitere Ausnahmearten, Kanäle, Gesellschaften und Prozesse wie Procure-to-Pay, alle auf denselben Verträgen. Alte Punkt-zu-Punkt-Schnittstellen werden eine nach der anderen abgeschaltet.
Abschlusskriterien
Jeder neue Ablauf nutzt dieselben Verträge und dasselbe Monitoring
Auftragsfertigung und Ersatzteilgeschäft vom ERP bis zum Lager und zum Spediteur, mit Lieferantenbestätigungen und E-Rechnungen, die gegen Bestellungen geprüft werden, auch für Betriebe in Ostbelgien mit Kunden in Deutschland.
Anschluss- und Installationsaufträge vom Arbeitsauftrag über den Einsatz vor Ort bis zur Rechnung, dazu Material, das über Rahmenverträge eingekauft wird.
Procure-to-Pay mit E-Rechnungen über Peppol und Mercurius an und von öffentlichen Einrichtungen, vor der Zahlung mit Bestellung und Wareneingang abgeglichen.
Beispiel zur Veranschaulichung
Ein Baustoffgroßhändler mit Kundschaft im ganzen Land
Ausgangslage
Ein Großhändler für Baustoffe beliefert Handwerksbetriebe und Gemeinden in Flandern, der Wallonie und Ostbelgien aus zwei Lagern, über Webshop und Außendienst. Aufträge werden von Hand ins ERP übernommen, Zustellprobleme melden die Spediteure per E-Mail, und abgelehnte Peppol-Rechnungen sammeln sich in einem gemeinsamen Postfach.
System
Aufträge, Bestände, Sendungen und Rechnungen fließen als Ereignisse zwischen Webshop, ERP, Lagerverwaltung und Spediteuren, und jeder Auftrag hat einen Verlauf. Rechnungen gehen als Peppol-E-Rechnung über einen Zugangspunkt hinaus. Rechnungen an Gemeinden nehmen den Weg für öffentliche Auftraggeber, über Mercurius und Peppol.
Menschliche Kontrolle
Fehlbestände und missglückte Zustellungen landen in der Klärungsliste. Dort schlägt ein KI-Agent einen Ersatzartikel oder einen neuen Liefertermin vor, und der Innendienst entscheidet über jeden Vorschlag. Für Preisänderungen und Gutschriften braucht es die Zustimmung der Buchhaltung.
Was wir messen würden
Anteil der Aufträge ohne Handarbeit je Kanal, Ausnahmen nach Grund und Lösungsdauer sowie Ablehnungsquote der Peppol-Rechnungen.
Belgien
Peppol im Prozess, nicht daneben
Seit dem 1. Januar 2026 müssen Unternehmen mit belgischer MwSt.-Nummer untereinander strukturierte E-Rechnungen austauschen, standardmäßig über Peppol. Die Toleranzfrist des FÖD Finanzen endete am 31. März 2026. Rechnungen an öffentliche Auftraggeber laufen über Mercurius und Peppol. Wer aus Ostbelgien Kunden in Deutschland beliefert, wird dort oft zusätzlich nach einer XRechnung gefragt.
Für uns ist die E-Rechnung ein Ereignis im Prozess: Sie entsteht im ERP, geht über einen Zugangspunkt hinaus und landet bei einer Ablehnung in der Klärungsliste. Seit dem 12. September 2025 gilt der Data Act mit Regeln für den Wechsel zwischen Datenverarbeitungsdiensten; Ereignisverträge und Datenexporte halten wir deshalb portabel. Den KI-Agenten der Klärungsliste legen wir mit Blick auf die KI-Verordnung aus. Integrationen liefern wir mit protokolliertem Zugriff und dokumentierten Komponenten, damit Kunden, die unter das belgische NIS2-Gesetz fallen, die Sicherheit ihrer Lieferkette belegen können.
Nein. ERP, CRM, Webshop und Lagerverwaltung behalten ihre jeweilige Aufgabe. Wir integrieren rund um diese maßgeblichen Systeme, legen fest, welches System welche Daten führt, und geben dem Prozess einen gemeinsamen Verlauf. Blockiert ein altes Auftrags- oder ERP-System jede Änderung, holt die Seite Altsysteme erneuern zuerst eine API-Schicht davor.
02Müssen wir unsere Middleware ersetzen?
Nicht, solange sie ihre Arbeit tut. Ihre vorhandene Integrationsplattform oder Ihren Message Broker nutzen wir weiter und ergänzen Verträge, Monitoring und Wiedereinspielen, wo es daran fehlt. Gibt es noch keine Plattform, bauen wir cloudnativ. Mehr dazu bei unseren Leistungen für Integrationen und APIs.
03Dürfen KI-Agenten allein handeln?
Nur innerhalb der Grenzen, die Sie je Aktionsart festlegen, und nur bei kleinen, umkehrbaren Aktionen wie dem erneuten Senden einer fehlgeschlagenen Nachricht. Bei Buchungen, Preisen, Kreditlimits und Zusagen an Kunden entscheidet immer ein Mensch. Mehr dazu im Beitrag wann KI-Agenten eine menschliche Freigabe brauchen.
04Wie passt die Peppol-Pflicht in den Ablauf?
In Belgien ist der Austausch strukturierter E-Rechnungen zwischen Unternehmen mit belgischer MwSt.-Nummer seit dem 1. Januar 2026 Pflicht, standardmäßig über Peppol. Andere Länder führen ihre Pflichten zu anderen Terminen ein. Ab dem 1. Juli 2030 wird die strukturierte E-Rechnung mit dem EU-Paket „Mehrwertsteuer im digitalen Zeitalter“ auch bei B2B-Lieferungen innerhalb der EU zum Standard. Für uns ist die E-Rechnung ein weiteres Ereignis im Prozess: im ERP erstellt, über einen Zugangspunkt verschickt und bei Ablehnung in der Klärungsliste bearbeitet. Mehr dazu in unserem Leitfaden zur E-Rechnung über Peppol.
05Entsteht so nicht wieder ein Knäuel aus Direktverbindungen?
Nein, denn die Systeme veröffentlichen und nutzen dokumentierte Ereignisse und APIs über eine gemeinsame Schicht, statt direkt miteinander verbunden zu sein. Verträge sind versioniert, Empfänger idempotent, fehlgeschlagene Nachrichten lassen sich wieder einspielen, und jeder Ablauf hat eine namentlich verantwortliche Person. Ein neuer Kanal abonniert vorhandene Ereignisse, statt eine Leitung zu jedem System zu ziehen.
06Womit beginnt man am besten?
Mit einem Prozess und einer Ausnahmeart, etwa Order-to-Cash in einem einzigen Verkaufskanal und als erste Ausnahme fehlender Lagerbestand. Daran bewähren sich Ereignisse, Verlauf und Freigabe, bevor mehr dazukommt. Wie wir Projekte aufbauen, beschreibt unser Vorgehen.
Ein Prozess, ein erstes Release
Nennen Sie uns einen Prozess und die Systeme, durch die er führt. Gemeinsam erfassen wir Schnittstellen und Ausnahmen und schlagen ein erstes Release vor, in dem der Peppol-Austausch von Anfang an mitläuft. Das erste Gespräch gern auf Deutsch.