Prozessautomatisierung für B2B-Unternehmen mit API-Workflows

B2B Prozessautomatisierung mit API-Workflows bedeutet, wiederkehrende Abläufe zwischen ERP, CRM, Shop, Portal und Buchhaltung so zu verbinden, dass Daten nicht mehr per Hand übertragen werden – und dass jeder Schritt nachvollziehbar, wiederholbar und bei Fehlern sichtbar bleibt. Der Nutzen entsteht nicht durch möglichst viele automatisierte Abläufe, sondern durch die richtigen: häufige, regelbasierte Prozesse mit klarer Datenhoheit. Im Folgenden zeigen wir, wie man diese findet, wie ein robuster Workflow technisch aufgebaut ist und woran Projekte in der Praxis scheitern.

Welche Prozesse sich lohnen

Ein Automatisierungs-Audit beginnt nicht mit Werkzeugen, sondern mit einer Liste der Abläufe, bei denen Mitarbeitende Daten zwischen Systemen kopieren. Für jeden Ablauf lohnt es sich, vier Fragen zu beantworten:

1. Wie oft kommt er vor? Täglich dutzendfach oder einmal im Quartal?
2. Wie regelbasiert ist er? Lassen sich die Entscheidungen als Bedingungen formulieren, oder braucht es Erfahrung und Rückfragen?
3. Welche Systeme sind beteiligt, und haben sie Schnittstellen? Eine dokumentierte REST-API ist etwas anderes als ein CSV-Export per FTP.
4. Was kostet ein Fehler? Eine falsche Lieferadresse ist ärgerlich, eine doppelt gebuchte Rechnung verursacht Aufwand in der Buchhaltung.

Gute Kandidaten für den Start sind typischerweise:

• Übernahme von Aufträgen aus Shop oder B2B-Portal ins ERP,
• Rückmeldung von Auftrags- und Versandstatus an Kunden,
• Anlage neuer Kunden aus dem CRM im ERP nach Freigabe,
• Abgleich von Preisen, Beständen und Produktdaten,
• Eingang, Prüfung und Weiterleitung von Lieferantenrechnungen.

Der letzte Punkt ist in Deutschland aktuell besonders relevant: Seit Januar 2025 müssen Unternehmen im B2B strukturierte E-Rechnungen nach EN 16931, etwa XRechnung oder ZUGFeRD, empfangen können; die Pflicht zur Ausstellung wird ab 2027 und 2028 stufenweise eingeführt. Wer den Rechnungseingang ohnehin umstellen muss, kann ihn gleich als durchgängigen Workflow aufsetzen.

Aufbau eines robusten API-Workflows

Ein Workflow, der „meistens funktioniert“, ist im B2B-Alltag gefährlicher als gar keiner, weil sich Mitarbeitende auf ihn verlassen. Bewährt hat sich folgender Aufbau.

Ereignisse statt Abfragen, wo möglich

Wenn ein System Webhooks anbietet, meldet es Änderungen selbst, etwa „Auftrag angelegt“. Das ist schneller und schonender als minütliches Abfragen. Viele ERP-Systeme bieten das nicht; dann wird ein zeitgesteuerter Abgleich mit Zeitstempel oder Änderungszähler eingesetzt, der nur neue Datensätze liest.

Jeder Schritt als eigener Auftrag

Statt einer langen Funktion, die alles nacheinander erledigt, wird der Ablauf in einzelne Jobs zerlegt: Auftrag empfangen, validieren, Kunde prüfen, im ERP anlegen, Bestätigung versenden. In Laravel übernehmen das Queues und Jobs, mit Redis oder einer Datenbank als Speicher und Horizon zur Überwachung. Scheitert ein Schritt, wird nur dieser wiederholt.

Idempotenz

Jeder Job muss so gebaut sein, dass eine doppelte Ausführung kein doppeltes Ergebnis erzeugt. In der Praxis heißt das: Jeder Auftrag trägt eine eindeutige externe Kennung, und vor dem Anlegen im Zielsystem wird geprüft, ob es diese Kennung schon gibt. Ohne diese Regel entstehen bei Netzwerkproblemen doppelte Aufträge.

Wiederholungen mit Grenzen

Vorübergehende Fehler wie Zeitüberschreitungen werden mit wachsenden Abständen wiederholt. Dauerhafte Fehler, etwa eine unbekannte Artikelnummer, werden nicht endlos wiederholt, sondern landen nach wenigen Versuchen in einer Fehlerliste mit verständlicher Meldung.

Protokoll und Oberfläche für Menschen

Zu jedem Vorgang sollte sichtbar sein, welche Schritte gelaufen sind, mit welchen Daten und mit welchem Ergebnis. Eine einfache Oberfläche mit „erneut ausführen“ und „als erledigt markieren“ spart im Betrieb mehr Zeit als jede zusätzliche Automatisierung.

Beispiel: Auftrag aus dem B2B-Portal ins ERP

Ein typischer Ablauf in einer Integrationsschicht auf Basis von Laravel sieht so aus:

1. Der Kunde bestellt im Portal. Das Portal speichert den Auftrag und löst ein Ereignis aus.
2. Ein Job prüft Pflichtfelder, Lieferadresse und Kreditlimit. Fehlt etwas, geht der Auftrag in den Status „Klärung“ und der Innendienst wird benachrichtigt.
3. Ein zweiter Job legt den Auftrag über die ERP-Schnittstelle an und speichert die zurückgegebene ERP-Auftragsnummer.
4. Ein zeitgesteuerter Abgleich liest Statusänderungen aus dem ERP: bestätigt, kommissioniert, versendet, fakturiert.
5. Bei jeder Statusänderung erhält der Kunde eine Nachricht, und im Portal erscheinen Sendungsnummer und Rechnung.

Wie ein solches Portal auf Kundenseite aufgebaut ist, beschreibt unser Beitrag zum B2B-Kundenportal mit Laravel und Vue.js.

Werkzeugwahl: No-Code, Middleware oder eigener Dienst

Es gibt keine allgemein richtige Antwort, aber klare Kriterien:

• No-Code-Plattformen eignen sich für Benachrichtigungen, einfache Übergaben zwischen Cloud-Diensten und Prototypen. Grenzen zeigen sich bei komplexer Fehlerbehandlung, großen Datenmengen und lokalen Systemen hinter der Firewall.
• Integrationsplattformen und Middleware lohnen sich, wenn viele Systeme mit standardisierten Konnektoren verbunden werden und ein Team für Betrieb und Lizenzen vorhanden ist.
• Ein eigener Integrationsdienst ist sinnvoll, wenn Geschäftslogik im Spiel ist, etwa Preisregeln, Freigaben oder mandantenspezifische Abläufe, wenn ein lokales ERP angebunden werden muss oder wenn volle Kontrolle über Protokolle und Daten gewünscht ist.

Häufig ist die Kombination sinnvoll: der Kernprozess in einem eigenen Dienst, einfache Benachrichtigungen über vorhandene Werkzeuge. Welche Integrationsmuster sich zwischen ERP, CRM und Shop bewährt haben, zeigt unser Überblick zu API-Integrationen für ERP, CRM und E-Commerce.

Typische Fehler

• Den Ist-Prozess eins zu eins automatisieren. Wenn ein Ablauf heute drei Freigaben hat, weil früher Fehler passiert sind, lohnt sich die Frage, ob sie mit sauberen Daten noch nötig sind.
• Keine eindeutige Datenhoheit. Wird eine Kundenadresse im CRM und im ERP gepflegt, synchronisiert der Workflow Widersprüche hin und her.
• Fehler nur in Logdateien. Wenn niemand sie liest, fallen Probleme erst auf, wenn Kunden anrufen.
• Zugangsdaten im Code. API-Schlüssel gehören in eine gesicherte Konfiguration mit minimalen Rechten, getrennt nach Test- und Produktivsystem.
• Kein Testsystem des ERP. Wer gegen das Produktivsystem entwickelt, riskiert echte Buchungen. Eine Testinstanz oder zumindest ein Testmandant ist Voraussetzung.

Betrieb und Überwachung

Nach dem Go-live beginnt die eigentliche Arbeit. Ein Workflow braucht eine verantwortliche Person, die Fehlerlisten regelmäßig sichtet, und Alarme, die nicht nur bei Abstürzen auslösen, sondern auch dann, wenn etwas ausbleibt: Kommt seit zwei Stunden kein Auftrag im ERP an, obwohl im Portal bestellt wird, stimmt etwas nicht. Ebenso wichtig ist ein Ablauf für Änderungen an angebundenen Systemen. Ein ERP-Update oder eine neue API-Version beim Versanddienstleister sollte vorher im Testsystem gegen die Workflows geprüft werden, statt erst im Betrieb aufzufallen.

Checkliste für den Start

• Liste der manuellen Übertragungen mit Häufigkeit und Aufwand
• Für jedes beteiligte System: Art der Schnittstelle, Dokumentation, Testzugang
• Festgelegte Datenhoheit je Datenfeld
• Definierte Status und Übergänge des Prozesses
• Verantwortliche Person für Fehlerfälle im Betrieb
• Messgröße für den Erfolg, etwa Durchlaufzeit oder Anzahl manueller Korrekturen

Nächster Schritt

Wählen Sie einen einzigen Ablauf, der täglich vorkommt und heute Daten zwischen zwei Systemen überträgt, und dokumentieren Sie ihn eine Woche lang: Wie oft, wie lange, welche Fehler. Diese Aufstellung reicht, um zu entscheiden, ob und wie er automatisiert werden sollte. Unser Vorgehen vom Audit bis zum Betrieb beschreiben wir auf der Seite unserer Leistung Prozessautomatisierung. Wenn Sie Ihre Aufstellung gemeinsam bewerten möchten, nehmen Sie Kontakt auf.