Braucht es Bestellautomatisierung, wenn SAP schon läuft?
SAP ist das führende System und automatisiert die strukturierten Schritte der Beschaffung innerhalb des Systems zuverlässig. Was SAP nicht leistet: die unstrukturierte Lieferantenkommunikation lesen, die entsteht, bevor Daten überhaupt im System landen. Also die E-Mails, PDFs und Excel-Bestätigungen, die das Team weiterhin von Hand abarbeitet. Genau dort verschwinden die Stunden. Diese Lücke schließt kein Systemwechsel, sondern eine KI-Schicht darüber, ohne Migration.
Wer SAP betreibt und die SAP Bestellabwicklung automatisieren will, steht nicht vor der Frage eines Systemwechsels, sondern vor der Frage, ob SAP das bereits abdeckt oder ob dort eine echte Lücke bleibt. Hier verläuft die Grenze.
Das Wichtigste in Kürze
- SAP automatisiert den Teil des Zyklus, den es sieht: Der MRP-Lauf erzeugt die Bestellanforderung, daraus wird eine Bestellung, die Nachrichtenfindung versendet sie. Was per E-Mail zurückkommt, war nie Teil dieses Zyklus.
- Eine Bestellbestätigung, die als EDI-ORDRSP eintrifft, bucht sich selbst auf die Bestellposition. Dieselbe Bestätigung als PDF liest und tippt ein Mensch.
- SAP listet jede Bestellung auf, zu der die Bestätigung noch fehlt. Die Bestätigung im gemeinsamen Postfach kann es nicht öffnen.
- Die Lücke schließt eine Schicht darüber, über das Postfach und eine schlanke API: keine Migration, keine Stammdatenbereinigung, kein Warten auf S/4HANA.
- Bei Klöckner bucht diese Schicht 81 % der Bestellpositionen ohne jeden manuellen Eingriff, über 150 Lieferanten und mehr als 1.100 Bestellpositionen pro Woche.
Was SAP gut kann
Beginnen wir mit dem Teil, der von allein läuft. Ein MRP-Lauf macht aus einem Bedarf eine Bestellanforderung. Die Anforderung wird zur Bestellung, automatisch überall dort, wo Material und Lieferant dafür eingerichtet sind. Eine Freigabestrategie hält alles oberhalb der Wertgrenze zurück, bis die zuständige Person freigibt. Die Nachrichtenfindung schickt die fertige Bestellung per E-Mail, Druck oder EDI zum Lieferanten. Das ist echte Automatisierung im SAP-Einkauf, und sie läuft ohne Zutun, solange nichts Unerwartetes zurückkommt.
Wo SAP bereits ausreicht
Auf die Frage, ob SAP Bestellungen selbst abwickelt, lautet die genaue Antwort: Es wickelt jene ab, die durchgängig strukturiert bleiben. Schickt ein Lieferant seine Bestätigung als EDI-ORDRSP, aktualisiert das eingehende IDoc die Bestätigung auf der Bestellposition, die Disposition sieht den neuen Termin, niemand greift ein. Weiter hinten im Prozess gilt dasselbe: Die Rechnungsprüfung gleicht die Rechnung gegen Bestellung und Wareneingang ab, und die Toleranzschlüssel sperren alles, was außerhalb der konfigurierten Preis- und Mengengrenzen liegt.
Sobald Daten sauber strukturiert im System liegen, ist SAP stark: Es hält die Stammdaten, erzwingt die Freigabelogik, schreibt jeden Vorgang mit und liefert ein führendes System mit vollständigem Nachweis. Kämen alle Aufträge als saubere, strukturierte EDI-Ströme herein, die exakt zu den vorhandenen Stammdaten passen, bräuchte es darüber sehr wenig.
Was SAP dem Team überlässt
Das tun sie nicht. Lieferantenbestätigungen kommen als Fließtext-E-Mails, als PDF-Anhänge und als Tabellen, die zu keiner Vorlage passen. Ein Disponent legt die Bestellung in SAP an, schreibt den Lieferanten an, erhält eine unstrukturierte Antwort, liest sie und tippt die Änderungen von Hand zurück ins System. SAP kann diese E-Mail nicht lesen, nicht deuten und nicht buchen. Die Arbeit landet bei einem Menschen. Über Bestätigungen, Nachfassaktionen, Terminverschiebungen und Rechnungsabweichungen hochgerechnet ergibt das jene unübersichtliche Mitte, die Stunden kostet, ohne echtes Urteilsvermögen zu verlangen.
Eine dieser Antworten durchläuft immer denselben Weg. Das PDF wird geöffnet und die zugehörige Bestellung ermittelt, denn der Lieferant nennt seine eigene Auftragsnummer, nicht die Bestellnummer aus SAP. Dann folgt Position für Position. Die Artikelnummer des Lieferanten gehört auf die eigene Materialnummer aufgelöst, Stück in Meter umgerechnet. Bestätigte 480 gegen 500 bestellte Stück verlangen eine Entscheidung: Teillieferung mit Rest zum späteren Termin oder Fehlmenge, die heute eine E-Mail wert ist. Danach wandern bestätigte Menge und bestätigter Termin in den Reiter Bestätigungen jeder einzelnen Position, eine nach der anderen.
SAP ist für diese Lücke nicht blind, es kann sie nur nicht überbrücken. Der Bestätigungssteuerschlüssel auf der Bestellposition sagt dem System, dass eine Bestätigung erwartet wird, und eine Überwachungsliste zeigt jede Position, zu der sie noch fehlt. Diese Auswertung ist nützlich und endet genau dort, wo die Arbeit beginnt: Die Bestätigung, nach der sie fragt, liegt als Anhang in einem gemeinsamen Postfach, und SAP kann sie nicht öffnen, nicht deuten und das Ergebnis nicht zurückschreiben. Wer den Bestätigungen hinterherläuft, die nie eintreffen, tut das über eine Kalendererinnerung.
Das ist die Automatisierungslücke im ERP, nüchtern beschrieben. Es fehlt kein SAP-Modul. Es geht um eine Art von Eingang, für deren Verarbeitung SAP nie gebaut wurde. Teuer wird das durch die Menge, nicht durch die Schwierigkeit: Klöckner bewegt mehr als 1.100 Bestellpositionen pro Woche über 150 Lieferanten, bei Oatly laufen rund 2.500 Aufträge pro Monat ein. Bei 30 bis 50 US-Dollar, die ein manueller Vorgang in der Lieferkette üblicherweise kostet, sind einige hundert nachgetippte Positionen pro Woche ein Budgetposten und kein Ärgernis.
Warum die KI von SAP dort endet, wo sie endet
Auch die KI-Funktionen von SAP fassen Daten zusammen oder handeln auf ihnen, die bereits strukturiert und bereits im System sind. Den eingehenden, unstrukturierten Schriftverkehr, der die manuelle Arbeit überhaupt erst erzeugt, verarbeiten sie nicht selbstständig.
Wo sich die SAP Bestellabwicklung automatisieren lässt und wo nicht
Über den Lebenslauf einer einzelnen Bestellposition gelegt, ist die Trennlinie leicht zu erkennen.
| Schritt | Läuft in SAP | Erledigt ein Mensch |
|---|---|---|
| Bedarf zur Bestellanforderung | MRP-Lauf erzeugt die Anforderung | Nichts |
| Anforderung zur Bestellung | Automatische Umsetzung, wo Material und Lieferant es zulassen | Manuelle Umsetzung für alles Übrige |
| Freigabe | Freigabestrategie nach Wert und Organisationseinheit | Nichts |
| Bestellung versenden | Nachrichtenfindung per E-Mail, Druck oder EDI | Nichts |
| Bestätigung über EDI | Eingehendes ORDRSP aktualisiert die Positionsbestätigung | Nichts |
| Bestätigung per E-Mail oder PDF | Nichts | Lesen, zuordnen, beurteilen, eintippen |
| Terminverschiebung im laufenden Vorgang | Nichts, bis jemand sie erfasst | Mail lesen, Position ändern, Disposition warnen |
| Bestätigung trifft nie ein | Auswertung listet die offenen Fälle | Nachfassmail schreiben, Antwort verfolgen, eskalieren |
| Rechnungsabweichung | Drei-Wege-Abgleich und Toleranzsperren | Sperre prüfen und auflösen |
Die mittlere Spalte läuft von selbst. Die rechte Spalte ist der Vormittag im Einkauf.
Warum die Antwort nicht lautet, SAP zu ersetzen
Dafür gibt es keinen guten Grund. Jahre an SAP-Konfiguration herauszureißen, um ein Postfachproblem zu lösen, ist die falsch dimensionierte Antwort und holt Wechselkosten und Risiken ins Haus, die ein Postfachproblem nicht rechtfertigt. Richtig dimensioniert ist eine operative Schicht über SAP, die den unstrukturierten Eingang liest, ihn gegen die SAP-Stammdaten abgleicht und geprüfte Vorgänge zurückbucht. SAP bleibt damit das führende System, das es sein soll.
GeneralMind arbeitet dafür über Ihr vorhandenes Postfach und eine schlanke API. Das funktioniert auch auf stark angepasstem SAP (heute ECC, S/4-fähig), gelesen und geschrieben wird über die Schnittstellen, die das System schon bereitstellt. Keine Migration, keine vorgeschaltete Datenbereinigung, kein Halbjahresprojekt. Unterhalb des eingestellten Konfidenzwerts wird nichts nach SAP geschrieben; diese Fälle gehen mit vorbereiteter Antwort an einen Operator, und jede Aktion wird protokolliert.
Die Anbindung ist absichtlich unspektakulär. Wir richten uns nach den Schnittstellen, die das SAP-System bereits bereitstellt, und pflegen sie mit, wenn sich dieses System ändert. Ein Release-Wechsel ist damit unsere Wartung und kein Punkt auf Ihrer IT-Roadmap. Der Abgleich läuft gegen den aktuellen Materialstamm und den offenen Auftragsbestand und bewertet jede Position mit einem Konfidenzwert, sodass ein Operator eine fertig ausgefüllte Buchung bestätigt oder korrigiert, statt das PDF von oben zu lesen.
Genau das muss KI in SAP Einkauf bedeuten, damit sie ihr Geld wert ist: keine Änderung am ERP, keine parallelen Stammdaten, kein zweites System, das die Disposition lernen muss. Dieselbe Schicht läuft auf Microsoft Dynamics, Oracle, Infor und über 100 weiteren angebundenen Systemen, geschärft über rund 20 Unternehmenseinführungen in der Auftragserfassung auf SAP. Gehostet wird in Frankfurt mit Ausweichrechenzentrum in Stockholm, nach ISO 27001:2022, ISO 27701 und SOC 2 Type II.
Was das für den S/4HANA-Fahrplan bedeutet
In den meisten SAP-Häusern steht irgendwo eine Migration auf dem Plan, und der Reflex lautet, darauf zu warten. Warten bringt nichts und kostet jede Stunde dazwischen, denn das Postfachproblem ist auf ECC und auf S/4 identisch. Es liegt außerhalb von beiden. Ein Start auf ECC verliert dadurch nichts: Die Konnektoren wandern mit, und die Schwellen und lieferantenspezifischen Regeln, die dieses Jahr eingestellt werden, gelten nach der Migration weiter.
Wie die ersten sechs Wochen aussehen
Der Start ist eine Postfachregel und ein Servicebenutzer, kein Programm. Die Schicht läuft zunächst im Schattenbetrieb auf echten Belegen und schlägt Buchungen vor, die ein Operator einzeln bestätigt oder korrigiert. Jede Korrektur bringt ihr den Materialstamm, die Mengeneinheiten und die Eigenheiten einzelner Lieferanten bei. Über einen unbekannten Lieferantenmix liegt die Extraktion am ersten Tag bei etwa 85 % und erreicht innerhalb weniger Wochen 93 bis 95 %.
Von dort steigt der Anteil der Bestellabwicklung in SAP, der ohne manuellen Eingriff durchläuft. Mehr als 90 % im vollen Autopilot nach etwa sechs Wochen ist das typische Muster und keine Zusage; es hängt daran, wie einheitlich der Lieferantenstamm ist. Bei Oatly laufen rund 2.500 Aufträge pro Monat, davon 80 % im Autopilot. Teams gewinnen in den ersten drei Monaten etwa 60 % der manuellen Bearbeitungszeit zurück, und diese Zeit geht in Eskalationen und Terminverfolgung, also in die Arbeit, für die es das Urteil eines Einkäufers braucht.
Woran sich die Lücke erkennen lässt
Aussagekräftig ist eine Woche Mitschrift darüber, was außerhalb von SAP passiert: Bestätigungen lesen, fehlenden Terminen nachlaufen, Abweichungen klären, Lieferantenänderungen nachtippen. Fällt diese Liste dünn aus, reicht SAP. Kommen Stunden pro Person und Woche zusammen (der übliche Befund), dann ist genau das die Lücke, und genau die schließt eine KI-Schicht. Bei Klöckner bucht diese Schicht auf SAP 81 % der Bestellpositionen ohne jeden manuellen Eingriff.
Zwei Zählungen schärfen das Bild. Von den Bestellungen des letzten Monats: Wie viele kamen über EDI zurück, und wie viele als Mail, die ein Mensch lesen musste? Dazu die Nachfassmails, also jedes handgetippte „Gibt es ein Update zu Bestellung 45xxxxxxx?“. Die zweite Zahl jedes Paars ist die Lücke, und multipliziert mit den Kosten eines Vorgangs ergibt sie den Business Case ohne Workshop.
Wann die Rechnung nicht aufgeht
Die unvorteilhafte Variante gehört ausgesprochen. In einem Werk, das vierzig Bestellungen pro Woche an ein Dutzend Lieferanten schickt, die alle ein ORDRSP zurücksenden, und in dem niemand im Einkauf eine Bestätigung nennen kann, die er letzte Woche abgetippt hat, ist eine KI-Schicht Overhead. Richtig eingestellte Bestätigungssteuerschlüssel erledigen dort die Sache, und das Budget liegt anderswo besser. Die Rechnung geht erst auf, wenn die Wochenliste dick zurückkommt: Stunden pro Person, verteilt auf Bestätigungen, Terminverschiebungen und Nachfassmails, auf Belegen, deren Format niemand im eigenen Haus ausgesucht hat.
Häufig gestellte Fragen
Die strukturierten Schritte innerhalb des Systems: ja. Unstrukturierte Lieferanten-E-Mails, PDFs und Excel-Dateien liest und verarbeitet SAP nicht, und dort liegt der größte Teil der manuellen Bestellarbeit.
Nein. GeneralMind läuft heute auf angepasstem ECC, und die Konnektoren wandern bei einer späteren S/4-Migration mit.
Nein. Es ist eine operative Schicht darüber. SAP bleibt Ihr führendes System; GeneralMind versorgt es mit geprüften Daten aus der unstrukturierten Kommunikation, die es selbst nicht verarbeiten kann.
Ariba deckt strukturierte, netzwerkbasierte Beschaffung ab; Lieferanten außerhalb des Netzwerks schreiben weiterhin unstrukturierte E-Mails. Genau die übernimmt GeneralMind, neben Ariba. (Siehe den Vergleich GeneralMind vs. SAP Ariba.)
Über das Postfach, an das Ihre Lieferanten ohnehin schreiben, plus eine schlanke API gegen die Schnittstellen, die das SAP-System bereits bereitstellt. Es gibt keine Änderung am ERP und keine parallelen Stammdaten, und wir richten uns nach diesen Schnittstellen und pflegen sie mit, wenn sich das System ändert. Gelesen wird gegen die aktuellen Stammdaten und den offenen Auftragsbestand; geschrieben wird nur oberhalb des Konfidenzwerts, den Sie festlegen, und jede Aktion wird mit Zeitstempel und der zugrunde liegenden Begründung protokolliert.
Nein. Jede Position wird gegen die vorhandenen Stammdaten bewertet, und alles unterhalb der eingestellten Schwelle geht an einen Operator statt in eine Buchung. Lücken zeigen sich damit als Eskalation und nicht als Fehlbuchung. Über einen unbekannten Lieferantenmix startet die Genauigkeit bei etwa 85 % und erreicht innerhalb weniger Wochen 93 bis 95 %, sobald Korrekturen die Materialnummern und Mengeneinheiten des Hauses beigebracht haben.
