SAP Lieferkette automatisieren: autonome Workflows in 7 Schritten

Autonome Workflows entstehen in einer SAP Lieferkette dadurch, dass eine KI-Schicht über Postfach und SAP gelegt wird, nicht durch Migration und nicht durch Austausch von Systemen. Der Weg dorthin besteht aus fünf Bewegungen: Bestandsaufnahme der manuellen Ausnahmearbeit, ein hochvolumiger Prozess als Anfang (die Auftragsbestätigung ist üblicherweise der erste Erfolg), Anbindung über eine leichtgewichtige API, Kalibrierung im Schattenmodus, dann Autopilot für die Fälle mit hoher Konfidenz. Live in wenigen Wochen, über 90 % Autopilot typischerweise nach etwa sechs Wochen.
SAP erledigt die strukturierte Arbeit. Die Stunden verschwinden im unübersichtlichen Bereich zwischen ERP und Betrieb: Auftragsbestätigungen treffen per E-Mail ein, Rechnungsabweichungen brauchen manuelle Sortierung, Lieferantennachrichten verteilen sich über mehrere Postfächer. Wer die SAP Lieferkette automatisieren will, arbeitet genau an dieser Lücke, und zwar ohne IT-Projekt. Die folgenden sieben Schritte beschreiben, wie das abläuft.
Kurzüberblick: SAP Lieferkette automatisieren in 7 Schritten
- Bestandsaufnahme der heutigen Ausnahmebehandlung.
- Auswahl der hochvolumigen, repetitiven Aufgaben.
- Karte der Datenflüsse und manuellen Übergaben.
- Festlegung der Integrationspunkte in SAP.
- Konfiguration der Regeln autonomer Workflows (Konfidenzschwellen).
- Rollout der KI-Schicht und Kalibrierung im Schattenmodus.
- Messung der Leistung und Umlenkung der Kapazität.
1. Bestandsaufnahme der heutigen Ausnahmebehandlung
Der erste Schritt ist eine Bestandsaufnahme: wohin die Zeit tatsächlich geht. Postfach öffnen, Bestätigung lesen, Artikelnummer suchen, Menge prüfen, gegen das ERP abgleichen, Position buchen, von vorn. Dazu gehört ein Durchgang durch jede Art von Ausnahme, also Rechnungsabweichungen, fehlende Wareneingänge, Währungsdifferenzen, und ein Protokoll über eine Woche mit Ausnahmeart, Bearbeitungszeit und Ergebnis. Diese Basislinie ist später der Maßstab für die Wirkung.
Gezählt werden Belege, nicht Stunden, und daneben steht das Ergebnis: passte exakt zur Bestellung, ein Feld war zu korrigieren, es brauchte zuerst eine E-Mail an den Lieferanten. Der dritte Fall ist der teure. Manuelle Berührungspunkte in der Lieferkette liegen häufig bei 30 bis 50 US-Dollar pro Vorgang, sobald Rückfrage, Wartezeit und erneutes Eintippen mitgerechnet werden. Den Nutzen spürt jedes Team sofort, belegen lässt er sich schwer. Diese eine Woche macht ihn belegbar.
2. Auswahl der hochvolumigen, repetitiven Aufgaben
Interessant ist die Arbeit in der Mittelzone: zu strukturiert für „das braucht einen Menschen“, zu unstrukturiert für RPA, die bricht, sobald eine Spalte umzieht. Typische Kandidaten sind Auftragsbestätigungen in ständig wechselnden E-Mail-Formaten, der Abgleich zwischen Bestellung, Wareneingang und Rechnung, das Nachfassen bei fehlenden Bestätigungen und die Vorsortierung von Ausnahmen. Nach Menge und Zeitaufwand sortiert zeigt diese Liste, wo die Stunden liegen.
Dann einer davon. Nicht drei. Der Anfang liegt dort, wo das Positionsvolumen am höchsten und der Entscheidungsraum am engsten ist. In den meisten SAP-Landschaften ist das die Auftragsbestätigung: Der Beleg kommt unaufgefordert, er trifft auf Zeilen, die in EKKO/EKPO längst existieren, und die Entscheidung ist ein Vergleich gegen Toleranzen, die sich in drei Zeilen aufschreiben lassen. Ausnahmen in der Kreditorenbuchhaltung bringen pro Fall mehr, greifen aber in FI, in Genehmigungswege und in die Freigabe gesperrter Rechnungen. Das ist der zweite Prozess, nicht der erste.
3. Karte der Datenflüsse und manuellen Übergaben
Hier wird eine Bestellung von der Anlage bis zur Zahlung verfolgt: SAP erzeugt sie, sie geht per E-Mail oder EDI an den Lieferanten, die Bestätigung landet in einem Postfach, ein Mensch tippt die Daten zurück in SAP. Jede Stelle, an der ein Mensch der Kitt zwischen zwei Systemen ist, ist ein Kandidat für Automatisierung. Eine einfache Übersicht mit Quelle, Belegart, Ziel und heutigem Weg genügt als Grundlage für die Einrichtung.
Die Spalte Belegart verträgt Strenge, denn E-Mail ist keine Belegart. Getrennt gehören PDF-Anhang, Text im Nachrichtenkörper, Excel-Tabelle und Scan eines Ausdrucks. Die zweite Frage lautet, was passiert, wenn nichts eintrifft: Wem fällt am dritten Tag auf, dass eine Bestätigung fehlt, und was tut diese Person daraufhin? Die Lieferantenkommunikation steht selten auf einer Prozesskarte und macht oft ein Viertel der Last aus: das Nachfassen, die Rückfrage, die Antwort, die vier Tage später in einem anderen Verlauf ankommt.
4. Festlegung der Integrationspunkte in SAP
Das ist eine kleine Standardintegration. Keine Migration. In der Praxis genügen eine leichtgewichtige REST API und Zugriff auf das Postfach. GeneralMind liefert ECC-fähige Konnektoren, die auch nach einem späteren Wechsel auf S/4HANA weiter tragen, und nutzt die Standardschnittstellen von SAP, wo ein Anwendungsfall sie braucht: BAPI und RFC für Transaktionen, IDocs für Belegflüsse. GeneralMind passt sich an die Schnittstellen an, die Ihr System bereits bereitstellt, und pflegt sie selbst. Dazu kommt ein dedizierter API-Benutzer aus dem Basis-Team, damit Berechtigungen und Audit-Trail von Anfang an sauber bleiben. Die IT gehört früh in ein kurzes technisches Gespräch, und eine Zahl an Personentagen kursiert besser erst, wenn die Technik sie bestätigt hat.
Was das Basis-Team tatsächlich tut
Ein API-Benutzer mit Leserechten auf die Einkaufs- und Rechnungsobjekte aus Schritt 3, mit Schreibrechten begrenzt auf die Transaktionen, die der Workflow bucht, und mit Zugriff auf das Postfach, in das die Lieferanten ohnehin schreiben. Die Kalenderzeit geht hier in die Berechtigungen, nicht in die Verbindung. Dieser Benutzer trennt außerdem maschinelle Buchungen von denen des Teams, und danach fragt eine Prüfung als Erstes. Zwei Dinge lohnen in dem Gespräch die ausdrückliche Erwähnung: Das ERP wird nicht verändert, und der Schreibpfad ist enger als der Lesepfad. Der Widerstand im Raum richtet sich meist gegen einen Umbau, den niemand vorgeschlagen hat.
5. Konfiguration der Regeln autonomer Workflows
In diesem Schritt entsteht die Entscheidungslogik: Bei hoher Konfidenz bucht das System direkt, bei Unklarheit geht der Fall mit Kontext und vorformuliertem Antwortvorschlag an Ihr Team. Das ist eine Ermessensfrage, kein Fehlercode. Konfiguriert werden Toleranzen für Abweichungen bei Menge, Preis und Liefertermin, zunächst eng, dann weiter, sobald Vertrauen entsteht. Bei Klöckner bucht diese Logik 81 % der Bestellpositionen ohne jede manuelle Korrektur.
Erst die Toleranzen, dann die Konfidenz
Das sind zwei Regler, nicht einer. Eine Toleranz sagt, dass eine Preissteigerung von 2 % in dieser Materialgruppe akzeptabel ist. Ein Konfidenzwert sagt, wie sicher das System ist, dass es tatsächlich 2 % gelesen und die richtige Bestellposition getroffen hat. Die Toleranzen entstehen gemeinsam mit dem Einkauf: Mengenabweichung je Materialgruppe, Preiskorridor aus dem Vertrag, und wie weit ein bestätigter Liefertermin rutschen darf, bevor ein Mensch hinsieht, was bei einem Lagerartikel anders ausfällt als bei einer produktionskritischen Position. Das ist der Teil, den Leute meinen, wenn sie von Prozessautomatisierung in SAP sprechen. Nicht die Anbindung. Die Entscheidungslogik.
Der Start fällt erfahrungsgemäß enger aus, als es nötig scheint. Eine Schwelle, die zu viel weiterleitet, kostet das Team eine Stunde Prüfung pro Tag. Eine Schwelle, die zu viel bucht, kostet Glaubwürdigkeit, und die kommt erst über Wochen zurück.
6. Rollout und Kalibrierung im Schattenmodus
Kein IT-Projekt, keine sechs Monate Laufzeit. Angebunden wird das Postfach, die Erkennung wird auf die vorhandenen Formate eingestellt, die Verbindung zu SAP steht, und dann läuft das Ganze parallel zum Team, bevor irgendetwas nach SAP schreibt. Damit wird der Konfidenzwert gegen die tatsächliche Trefferquote kalibriert. Vortrainierte Modelle laufen am ersten Tag zu rund 85 % ohne Eingriff durch und erreichen innerhalb weniger Wochen 93 bis 95 %, sobald Ihre Artikelnummern, Lieferantenbezeichnungen und Layouts gelernt sind. Danach gehen die Vorgänge mit hoher Konfidenz auf Autopilot. Über 90 % Autopilot nach etwa sechs Wochen ist die typische Erfahrung, keine Zusage.
Diese Parallelphase trägt das gesamte Sicherheitsargument. Echte Belege hinein, die Buchung, die das System vorgenommen hätte, heraus, und nichts erreicht SAP. Wo die Vorschläge des Systems und die Entscheidungen des Teams bei hoher Konfidenz übereinstimmen, liegt die Autopilot-Menge. Wo das System sicher und falsch war, liegt eine Lücke in den Stammdaten oder eine Toleranz, die im Kopf einer Kollegin anders aussieht als in der Konfiguration. Niemand gibt KI auf SAP wegen einer Demo frei. Freigegeben wird, weil zwei Wochen Ausgabe aus dem Schattenmodus zu den Entscheidungen des eigenen Teams passen.
Wo die sechs Wochen kippen
Diese Zeitachse setzt voraus, dass die unspektakulären Dinge klappen: Auf Ihrer Seite gibt es einen Verantwortlichen, der API-Benutzer existiert in Woche eins, und die Person, die weiß, warum die Bestätigungen eines bestimmten Lieferanten seltsam aussehen, ist erreichbar. Wenn es kippt, liegt es fast nie am Modell. Es liegt an Berechtigungen, die auf ein Change-Fenster warten, oder an einer Stammdatenbereinigung, die niemand eingeplant hat.
7. Messung der Leistung und Umlenkung der Kapazität
Vier Kennzahlen tragen diesen Schritt: der Anteil der Vorgänge ohne manuellen Eingriff, die Zeit vom Eingang bis zur Buchung in SAP, die Ausnahmequote je Kategorie und die gewonnenen Stunden. In produktiven Einführungen gewinnen Teams in den ersten drei Monaten rund 60 % der manuellen Bearbeitungszeit zurück. Ziel ist nicht, Stellen abzubauen. Ziel ist, Kapazität auf Lieferantenbeziehungen, Eskalationen und die Fälle zu lenken, die Urteilsvermögen brauchen. Dashboards für offene Bestellungen, Ausgaben und Ausnahmelisten erlauben dem Team, nach dem Ausnahmeprinzip zu steuern.
Diese Sicht entsteht besser vor dem Go-live als danach: die Basislinie aus Schritt 1 plus dieselben Zahlen an jedem Montag sind der Business Case, und rückwirkend lässt sich das kaum zusammentragen. In der Ausnahmeliste zählt die Zusammensetzung mehr als die Länge, denn eine Liste, die gleich lang bleibt, sich aber von „Format nicht lesbar“ zu „Lieferant widerspricht dem Preis“ verschiebt, ist besser geworden. Und die Frage, wofür die gewonnenen Stunden gedacht sind, gehört ins Team, bevor der erste automatisierte Vorgang läuft. Bei Oatly laufen rund 80 % von etwa 2.500 Aufträgen pro Monat im Autopilot, und die Kolleginnen und Kollegen, die sie früher erfasst haben, arbeiten heute an dem Fünftel der Fälle, in dem jemand etwas entscheiden muss.
Welche SAP-Ausnahmen können autonome Workflows übernehmen?
Den Drei-Wege-Abgleich automatisieren ist der klarste Fall, weil die Regel längst niedergeschrieben ist: Bestellung, Wareneingang und Rechnung müssen innerhalb der Toleranz übereinstimmen, und wenn sie das tun, ist die Buchung mechanisch. Was ihn blockiert, ist selten die Regel. Einer der drei Belege kommt zu spät, eine Teillieferung hat eine Bestellposition in zwei Wareneingänge zerlegt, oder die Rechnung nennt die Belegnummer des Lieferanten statt der eigenen.
Geeignet sind strukturierte Ausnahmen, die einem Muster folgen: Rechnungsabweichungen innerhalb der Toleranz werden geklärt und gebucht, fehlende Wareneingänge lösen automatisch eine Nachfassaktion beim Lieferanten aus, Währungsabweichungen über der Schwelle gehen zur Prüfung. Gesperrte Rechnungen, Abweichungen im Drei-Wege-Abgleich und schwellenbasierte Genehmigungswege bringen den größten Hebel, und zwar sämtlich innerhalb von Procure-to-Pay. Echte Ermessensfälle wie strittige Belastungen oder das Onboarding eines neuen Lieferanten werden vorformuliert und an das Team übergeben. Das Urteil bleibt beim Menschen, die Wiederholarbeit verschwindet.
Warum klassische RPA an Ausnahmen in der SAP Lieferkette scheitert
RPA bricht, sobald die Eingänge variieren: eine Bestätigung als E-Mail-Anhang statt über EDI, eine verschobene Excel-Spalte, ein Wareneingang auf Deutsch. Solche Abweichungen passieren ständig, und templategebundene Skripte fallen in dem Moment aus, in dem sich ein Format ändert. Am Ende pflegt jemand mit der IT für jede Anpassung eines einzelnen Lieferanten ein Skript nach. Autonome Workflows lesen die Absicht und nicht nur die Struktur: Ein solcher Workflow erkennt, dass „PO Number“, „Purchase Order #“ und „Bestellnummer“ dasselbe Feld bezeichnen, und kommt damit mit der unübersichtlichen Realität aus vielen Lieferanten und vielen Formaten zurecht.
Wie GeneralMind dabei hilft
GeneralMind setzt KI-Mitarbeiter ein, die Bestellungen und Rechnungen in jedem Format lesen, ob E-Mail, PDF, Excel oder Scan, sie gegen Ihre SAP-Stammdaten abgleichen und ERP-fähige Vorgänge durchgängig buchen. Routinefälle laufen im Autopilot, Ausnahmen gehen mit fertig vorbereitetem Antwortvorschlag an Ihr Team. Bei Klöckner buchen 81 % der Bestellpositionen ohne jeden manuellen Eingriff, über mehr als 1.100 Bestellpositionen pro Woche. Sie gehen in wenigen Wochen live und zahlen pro Vorgang erst ab dem Go-live, ohne Vorabkosten.
Häufig gestellte Fragen
Nein. GeneralMind arbeitet heute auf einem angepassten ECC-System, und die Konnektoren tragen auch nach einem späteren Wechsel auf S/4 weiter.
Typischerweise MM, FI und SD. Der Workflow liest und schreibt Bestelldaten (EKKO/EKPO), Rechnungsköpfe (RBKP) und Buchhaltungsbelege (BSEG) über die Standardanbindung per BAPI, RFC und IDoc. Das ist eine Standardintegration, kein Umbau.
Unterhalb Ihrer Konfidenzschwelle wird nichts geschrieben. Diese Fälle gehen mit vorformuliertem Antwortvorschlag an einen Operator, und jede Aktion ist nachvollziehbar protokolliert.
Ja. Die Absicht eines Belegs wird auf Deutsch, auf Englisch und in weiteren Sprachen erfasst, und die Felder werden unabhängig von der jeweils verwendeten Bezeichnung zugeordnet.
Lange genug, dass das System jeden hochvolumigen Lieferanten mehrfach gesehen hat, statt eine vorher festgelegte Zahl von Tagen. Verglichen werden die vorgeschlagenen Buchungen mit dem, was das Team tatsächlich getan hat; auf Autopilot geht zuerst die Menge, in der beide bei hoher Konfidenz übereinstimmen.
Erste Vorgänge im Autopilot nach wenigen Wochen, über 90 % Autopilot im ersten Prozess nach etwa sechs Wochen, während das System lernt. Das ist die typische Erfahrung, keine Zusage.


