Ein pragmatischer Fahrplan zur P2P-Automatisierung

Das Wichtigste in Kürze

• Procure-to-Pay bricht zwischen den Schritten, nicht in ihnen. Freigabe und Rechnungsbuchung laufen im ERP. Die Mail-Ketten dazwischen nicht.
• Die Reihenfolge richtet sich nach der Häufung von Ausnahmen, nicht nach dem Prozessverlauf. Zuerst kommt der Belegtyp, der am häufigsten angefasst wird, unabhängig von seiner Position im Ablauf.
• Die Bestellanforderung bleibt beim Menschen. Alles danach kann unbeaufsichtigt laufen, mit einer Person für die Ausnahmen. Genau das zeigt die Abbildung unten.
• Bei Klöckner werden 81 % der Bestellpositionen ohne manuelle Korrektur gebucht, über 150 Lieferanten und mehr als 1.100 Bestellpositionen pro Woche. Oatly verarbeitet rund 2.500 Aufträge im Monat, 80 % davon auf Autopilot.
• Bei einem stabilen Lieferantenstamm, der bereits über EDI angebunden ist, bringt dieser Fahrplan wenig. Er schließt die Lücke dort, wo Kommunikation als Prosa ankommt.

Wo Procure-to-Pay tatsächlich bricht

Procure-to-Pay liegt auf der Nahtstelle zwischen Einkauf, Finanzen und Operations. In Häusern mit SAP, Oracle oder Microsoft Dynamics trifft dort die Richtlinie auf den Arbeitstag. Eine Bestellanforderung, die im ERP saubere Daten hat, wird zur Mail-Kette, zur Excel-Liste und zur Freigabe auf Zuruf, sobald ein realer Lieferant, ein Eilbedarf oder eine Unterlieferung dazukommt. Die Symptome sind über Branchen hinweg dieselben: Durchlaufzeiten, die niemand vorhersagen kann, Beteiligte, die den Status telefonisch erfragen, und eine Finanzabteilung, die zum Monatsabschluss Belege sucht statt Liquidität zu steuern.

Es lohnt sich, genau zu benennen, welcher Teil manuell ist, denn es ist nicht der Teil, auf den die meisten Fahrpläne zielen. Freigabe-Workflows existieren. Die Rechnungsbuchung gegen die Bestellung existiert. Zahlläufe sind terminiert. Manuell ist das Bindegewebe: die Auftragsbestätigung lesen, die als PDF an einer Antwort an alle hängt, entscheiden, ob ein um fünf Tage verschobener Liefertermin bei diesem Material eine Rolle spielt, die Position im ERP nachziehen und daran denken, bei den zwölf Bestellungen erneut nachzufassen, die nie bestätigt wurden.

Diese Arbeit hat Kosten pro Beleg, und die fallen höher aus als vermutet, weil sie sich auf Personal, Nacharbeit und Aufsicht verteilt statt in einer Budgetzeile zu stehen. Manuelle Berührungspunkte in Lieferkettenprozessen liegen üblicherweise bei 30 bis 50 US-Dollar pro Vorgang, wenn Bearbeitungszeit und Fehlerkorrektur mitgerechnet werden. Ein Team mit einigen Tausend Belegen im Monat trägt damit sechsstellige Jahreskosten, die in keiner Position auftauchen, für die jemand verantwortlich ist.

Was eine Ausführungsschicht verändert

Die Alternative behandelt Procure-to-Pay als einen Fluss, der auf den vorhandenen Systemen läuft, und nicht als Folge von Masken, zwischen denen Menschen wechseln. Eine KI-Ausführungsschicht liest die eingehende Post samt Anhängen, liest die relevanten Felder aus, gleicht sie gegen den Stammdatenbestand ab, schreibt das Ergebnis ins ERP und fasst bei dem nach, der eine Antwort schuldet. SAP oder Oracle werden dadurch nicht ersetzt. Geschlossen wird der Abstand zwischen dem, was im ERP steht, und dem, was noch passieren muss.

Technisch ist das weniger invasiv, als es klingt. GeneralMind arbeitet über Ihr vorhandenes Postfach plus eine leichte API und passt sich an die Schnittstellen an, die jedes System schon bereitstellt; die Pflege dieser Verbindungen übernimmt GeneralMind selbst. Es gibt keine Datenmigration, keine neue Oberfläche, die das Team lernen muss, und keine Voraussetzung, das ERP vorher zu aktualisieren. Bei den Menschen, die vorher abgestimmt haben, bleiben die Ausnahmen, also der Teil ihrer Arbeit, der ohnehin Urteilsvermögen verlangt.

Die Aufteilung der Arbeit ist die wichtige Entscheidung im Entwurf, und sie ist nicht gleichmäßig. In der Bestellanforderung werden Richtlinie, Budget und Absicht festgelegt, deshalb bleibt sie bei einer Person. Von der Bestellung an ist jeder Schritt eine Frage von Regeln auf Belegen, und jeder davon kann unbeaufsichtigt laufen, bis eine Prüfung fehlschlägt.

Welcher Schritt zuerst automatisiert wird

Der Reflex ist, am Anfang des Prozesses zu beginnen, und dieser Reflex führt in die falsche Richtung. Bestellanforderungen sind der am stärksten geregelte Teil im Procure-to-Pay, ihre Automatisierung bringt am wenigsten. Sinnvoller ist der Einstieg dort, wo sich Ausnahmen häufen, denn das Ausnahmevolumen bestimmt, wie der Arbeitstag des Teams aussieht.

In der Praxis heißt das: die Auftragsbestätigung. Sie ist in den meisten Einkaufsorganisationen der häufigste eingehende Beleg, sie kommt in dem Format, das der Lieferant gerade wählt, und jede einzelne muss gegen das Bestellte gehalten werden. Es ist zugleich der Schritt, an dem der Vergleich mechanisch ist: Preis, Menge, Liefertermin, gegen die ursprüngliche Bestellung. Wer bei den Bestätigungen anfängt, sieht den Unterschied innerhalb von Wochen, weil das Volumen jeden Tag anfällt.

Der zweite Kandidat ist das Nachfassen. Bei Bestellungen hinterherzugehen, die nie bestätigt wurden, ist reine Abstimmungsarbeit ohne Ermessen, und sie fällt als Erstes weg, wenn ein Team unter Druck steht, also genau dann, wenn sie zählt. Automatisiertes Nachfassen kostet kein Risiko: das schlechteste Ergebnis einer unnötigen Erinnerung ist ein leicht genervter Lieferant.

Dreifachabgleich und Rechnungsausnahmen kommen an dritter Stelle, nicht weil sie weniger wert sind, sondern weil sie davon abhängen, dass die beiden vorherigen saubere Daten liefern. Eine Rechnung gegen Bestellung und Wareneingang zu prüfen ist nur verlässlich, wenn die Bestellung das Vereinbarte abbildet, einschließlich der Terminverschiebung, die der Lieferant in Woche drei per Mail geschickt hat. Wer den Abgleich vor der Bestätigung automatisiert, automatisiert einen Vergleich gegen veraltete Daten.

Zwei Dinge gehören auf eine Ausschlussliste. Freigabegrenzen und Richtlinienausnahmen bleiben besser manuell, denn ihre Automatisierung schreibt die aktuelle Richtlinie fest, samt der Teile, die falsch sind. Und die Lieferantenanbindung, in der Konditionen verhandelt und nicht verarbeitet werden, ist überhaupt kein Belegproblem.

Aussagekräftig ist die Durchlaufquote, nicht die Erkennungsgenauigkeit. Die Genauigkeit ist die Zahl, die Anbieter nennen, und die sich am wenigsten bewegt: eine Verbesserung der Feldgenauigkeit von 92 % auf 96 % verändert kaum, wie lange ein Beleg braucht, weil das Abtippen nie der Engpass war. Die Frage ist, welcher Anteil der Belege das ERP erreicht, ohne dass jemand sie öffnet.

Wie die Zahlen in der Praxis aussehen

Benchmarks von APQC zeigen seit Jahren, dass ein vollständig automatisiertes Procure-to-Pay die Ausnahme bleibt, während die Organisationen, die dort ankommen, deutlich niedrigere Prozesskosten und kürzere Durchlaufzeiten berichten als ihre Vergleichsgruppe. Dieser Abstand ist die Chance, und er hat weniger mit der Verfügbarkeit von Technik zu tun als mit der Reihenfolge: die meisten Programme automatisieren die Schritte, die schon vorher günstig waren.

In unseren Einführungen ist das Muster stabil. Ein neuer Prozess läuft am ersten Tag zu rund 85 % durch und erreicht 93 bis 95 % innerhalb weniger Wochen, sobald er die Stammdaten, die Eigenheiten der Lieferanten und die Ausnahmen kennt, die im Haus als normal gelten. Bis 90 % oder mehr auf Autopilot laufen, dauert es erfahrungsgemäß etwa sechs Wochen, und rund 60 % der manuellen Bearbeitungszeit werden in den ersten drei Monaten frei. Das sind typische Werte und keine Zusagen; sie hängen daran, dass genug Belegvolumen vorhanden ist, um schnell zu lernen.

Die genannten Beispiele sagen mehr als die Durchschnitte. Bei Klöckner, einem der größten Stahl- und Metalldistributeure Europas, werden 81 % der Bestellpositionen ohne manuelle Korrektur gebucht, über 150 Lieferanten und mehr als 1.100 Bestellpositionen pro Woche, direkt auf der bestehenden SAP-Installation und ohne Migration. Oatly verarbeitet rund 2.500 Aufträge im Monat, 80 % davon auf Autopilot. In beiden Fällen wurde das Team nicht kleiner; das Volumen, das es bewältigt, wurde größer.

Wann dieser Fahrplan der falsche Plan ist

Ist der Eingang bereits strukturiert, erübrigt sich der Rest. Eine Einkaufsorganisation, deren fünfzig größte Lieferanten alle ORDRSP-IDocs über EDI senden, hat das Problem gelöst, um das es hier geht, und eine KI-Schicht auf saubere EDI-Daten ist Zusatzaufwand mit Zwischenschritten. Interessant ist der lange Schwanz: die Lieferanten, die zu klein für eine EDI-Anbindung sind und zusammen die meisten Ausnahmen schicken.

Auch das Volumen entscheidet. Unter einigen Hundert Belegen im Monat geht die Rechnung nicht auf. Es fehlt die Wiederholung, aus der ein System schnell lernt, und die Abstimmungskosten, um die es geht, sind ein Bruchteil einer Personenwoche. In dieser Größe ist eine Einstellung die günstigere Antwort, und das sagen wir im Gespräch auch so.

Der dritte Fall ist der Zeitpunkt. Läuft gerade eine Migration nach S/4HANA, ist Warten richtig. Gegen Schnittstellen zu automatisieren, die kurz vor dem Austausch stehen, heißt zweimal zahlen, und die Migration bindet ohnehin die interne Aufmerksamkeit, die diese Arbeit braucht. Erst umziehen, dann auf dem System automatisieren, das dauerhaft bleibt.

Der vierte Fall ist der unangenehme. Liegt das eigentliche Problem bei falsch gesetzten Freigabegrenzen oder daran, dass drei Abteilungen den Lieferantenstamm unterschiedlich pflegen, macht Automatisierung das vorhandene Durcheinander schneller und schwerer sichtbar. Dann kommt die Richtlinie zuerst. Software, die eine schlechte Regel zuverlässig ausführt, ist schlechter als ein Mensch, der sie stillschweigend umgeht.

Warum sich der Zeitpunkt verschoben hat

Das Argument für jetzt ist strukturell, nicht technisch. Die Belegvolumen steigen, Beteiligte erwarten Status, ohne danach zu fragen, und der Arbeitsmarkt für erfahrene Sachbearbeitung in der Auftragsabwicklung ist in jedem Markt eng, in dem wir verkaufen. Diese drei zusammen nehmen dem Wachstum über Köpfe die Grundlage, und das ist ein anderes Argument als eine neu verfügbare Technik.

Dazu kommt die Steuerbarkeit. Springt das Volumen oder kommt eine neue Gesellschaft dazu, nimmt ein autonomer Fluss das ohne Einstellungsrunde auf. Ändern Lieferanten ihre Konditionen, sieht die Finanzabteilung Obligo und Verbindlichkeiten in dem Moment, in dem sie sich bewegen, und nicht nach dem Monatsabschluss. Unter Druck auf das Working Capital wiegt eine kürzere Durchlaufzeit ohne gelockerte Kontrollen mehr als die Personalersparnis, die üblicherweise zitiert wird.

Wer bewusst anfängt, wählt selbst, welcher Prozess zuerst geht, welche Ausnahmen beim Menschen bleiben und wie der Prüfpfad aussieht. Wer wartet, startet meist unter Zwang, nach einem Rückstand oder einem Prüfungsbefund, und nimmt die Reihenfolge, die die Lage vorgibt. Zwischen diesen beiden Positionen liegen ein paar Monate Entscheidung, kein Technikunterschied.