Make or Buy: KI-Automatisierung in der Bestellabwicklung 2026

Der stärkste Wettbewerber jedes Automatisierungsanbieters ist gar kein Anbieter: Es ist der Satz „Das bauen wir selbst.“ Mit den heutigen Modellen ist dieser Reflex nachvollziehbar. Hier die ehrliche Rechnung.

Was folgt, ist die Rechnung, die Make or Buy KI-Automatisierung an den eigenen Zahlen entscheidet: woran sich der Aufwand vor der Festlegung messen lässt, welche Kosten regelmäßig unter den Tisch fallen und unter welchen Bedingungen die Bestellabwicklung besser selbst automatisiert wird. Auf die Reihenfolge kommt es an. Die meisten Teams legen sich zuerst fest und rechnen erst danach.

Die Demo ist einfach, die letzte Meile bringt Projekte zu Fall

Einen Prototyp aufzusetzen, der eine saubere Bestellung liest, ist schnell erledigt. Verlässlich über 90 % Autopilot zu erreichen, ist es nicht. Die letzte Meile besteht aus Grenzfällen, Ausnahmen, wechselnden Formaten und dem Lieferanten, der die Terminverschiebung in den dritten Absatz schreibt. Dazu gehört die Position, die in zwei Teillieferungen zerfällt, der Preis, dessen Abweichung entweder Rundung oder Streitfall ist, und die Bestätigung, die gar keine Bestellnummer nennt. Dieser Weg kostet Quartale an Iteration über Modellauswahl, Evaluationsschleifen, Abläufe und Anbindungen. Den meisten internen Projekten geht vorher die Zeit aus, und was live geht, hält ein Team von da an dauerhaft am Leben.

Wie lang die letzte Meile ist, lässt sich vorab messen

Es gibt einen günstigen Weg zu dieser Zahl. Jedes Auftragsdokument, das in einem Monat im Sammelpostfach eingegangen ist, lässt sich exportieren und auf drei Stapel sortieren: sauber und maschinenlesbar; lesbar, aber mit Abgleich gegen die Stammdaten; und Fälle, in denen erst jemand beim Lieferanten nachfragen musste, bevor überhaupt gebucht werden konnte. Den ersten Stapel schafft ein Prototyp in zwei Wochen. Stapel zwei und drei sind das Projekt. Notiert man je Stapel zusätzlich die durchschnittliche Bearbeitungsdauer, trägt der Ausläufer neben der Stückzahl eine Zeitangabe, und die Rechnung im nächsten Abschnitt lässt sich damit führen. Liegt ein Viertel des Volumens in diesem Ausläufer, steckt in diesem Viertel die Entwicklungsarbeit von Quartalen, und dort sitzen auch die manuellen Stunden von heute. Nur dieser Teil ist es wert, automatisiert zu werden.

Nicht das Modell war die harte Arbeit, sondern das Harness

Teams nehmen oft an, sie bräuchten bessere KI. Doch die Modelle haben die Zuverlässigkeitsschwelle für mehrstufige Arbeit längst überschritten und sind untereinander weitgehend austauschbar. Was eine Demo vom Produktivbetrieb trennt, ist das Harness: die Entwicklungsarbeit, die festlegt, welchen Kontext das Modell sieht, wie es auf Stammdaten zugreift, wie die Ausgabe kontrolliert wird und wie das System lernt. Kontrolle heißt hier: eine Schwelle, ab der gebucht wird, ein Weg, auf dem ein unsicherer Fall bei einer Person landet, die ihn in Sekunden klären kann, und ein Nachweis darüber, was auf welcher Grundlage geschehen ist. Als benannte Disziplin ist das kaum ein Jahr alt. Wenige Teams haben diese Schicht aufgebaut, noch wenigere betreiben sie im Unternehmensmaßstab. Diese Schicht von null an zu bauen, ist das eigentliche Projekt hinter jeder Unterschrift.

Eine Frage macht das Harness greifbar: Wem gehört es im dritten Jahr? Nicht, wer es schreibt, sondern wer Rufbereitschaft hat, wenn ein Lieferant über Nacht sein Abrechnungssystem wechselt, wer die Automatisierungsquote verantwortet, wenn sie um zwei Punkte fällt, und wer der Prüferin die Falschbuchung erklärt. Bei einer gekauften Lösung stehen hinter diesen Rollen Namen beim Anbieter. GeneralMind arbeitet über Ihr bestehendes Postfach und eine leichtgewichtige API, richtet sich nach den Schnittstellen, die jedes System ohnehin bereitstellt, und pflegt sie selbst. Bei einer Eigenentwicklung stehen alle diese Namen im eigenen Organigramm, und dort bleiben sie. Diesen Posten enthält keine Aufwandsschätzung für eine Software zur Bestellabwicklung, denn er ist kein Funktionsumfang. Er ist eine dauerhafte Verpflichtung.

Make or Buy KI-Automatisierung: der ehrliche Kostenvergleich

Eigenentwicklungen wirken auf dem Papier günstiger, weil das Papier einiges auslässt: die Zeit erfahrener Entwickler, die Laufzeit über mehrere Quartale, die laufende Wartung und die Kosten jeder Störung und jedes Genauigkeitsrückgangs im Betrieb. Dazu kommen die Posten, die selten in einer Schätzung stehen, weil sie auf andere Kostenstellen fallen: Projektsteuerung, Abstimmungsrunden mit dem Einkauf und der IT, Rufbereitschaft und die Zeit, die der Fachbereich für Tests und Abnahmen aufbringt. Rechnet man das mit, liegt eine gekaufte Lösung typischerweise rund 80 % günstiger. Bei ergebnisorientierter Abrechnung zahlen Sie pro verarbeiteter Transaktion, und die Kosten starten erst zum Go-live; das Umsetzungsrisiko der Aufbauphase liegt damit beim Anbieter. Ein sprödes internes System dagegen wird an dem Tag zur eigenen Verantwortung, an dem es in Betrieb geht.

Der Vergleich rechnet sich nur am eigenen Transaktionsvolumen

Beide Optionen treten gegen die Kosten der Handarbeit an, und dort beginnt die Rechnung: die Auftragsvorgänge des letzten Monats, multipliziert mit den Vollkosten pro Vorgang. Manuelle Vorgänge in der Lieferkette liegen üblicherweise bei 30 bis 50 US-Dollar, sobald die Sachbearbeitung, die Rückfrage per E-Mail, die Nacharbeit und die Eskalation vollständig mitgezählt sind. Dieser Betrag ist die Obergrenze für alles, was sich bei den Kosten der Beschaffungsautomatisierung auf beiden Wegen rechtfertigen lässt. Er fällt meist höher aus, als beide Kalkulationen vermuten lassen, weil niemand die vier Minuten abrechnet, in denen jemand herausfindet, auf welche Bestellposition sich eine Bestätigung bezieht.

Woran die Wirtschaftlichkeit von KI-Projekten meist scheitert

Interne Wirtschaftlichkeitsrechnungen stellen gern die Grenzkosten eines API-Aufrufs dem Stundensatz einer Sachbearbeiterin gegenüber und schließen daraus, dass Selberbauen fast nichts kostet. Der Fehler liegt auf der Zeitachse. Jeder Monat, in dem die Eigenentwicklung nicht produktiv ist, ist ein Monat ohne Einsparung, und über mehrere Quartale hinweg wiegt dieser verlorene Zeitraum oft mehr als der Bau selbst. Als Zahlungsstrom über vierundzwanzig Monate gerechnet statt als Stückkosten pro Transaktion, sehen die beiden Optionen einander nicht mehr ähnlich.

Eine Position auf der Kaufseite verdient genaues Lesen. Die ergebnisorientierte Abrechnung beginnt zum Go-live, erfolgt pro verarbeiteter Transaktion und hat in den ersten drei Monaten eine verkürzte Kündigungsfrist. Bleibt die Automatisierungsquote aus, endet die Zahlung, und der Vertrag endet mit ihr. Eine Eigenentwicklung kennt diesen Ausgang nicht: Die versunkenen Kosten sind die eigene Lohnsumme.

Was sich nicht abkürzen lässt

Jede produktive Einführung erzeugt Betriebserfahrung, geprüfte Referenzdatensätze und ein Gedächtnis, das nur wächst. Dieses Wissen ist unspektakulär und genau deshalb wertvoll: welche Lieferantenvorlage regelmäßig einen Sonderfall erzeugt, welche Toleranz bei Mengen und Preisen sich im Betrieb bewährt hat, welche Rückfrage beim Lieferanten eine Antwort bringt und welche unbeantwortet bleibt. Eine gekaufte Lösung, die über rund 20 Unternehmensimplementierungen der Auftragserfassung auf SAP nachgeschärft wurde, beginnt dort, wo Ihre Eigenentwicklung enden würde, sofern sie enden würde. Dieser Vorsprung ist nicht käuflich und nicht kopierbar. Er entsteht im Produktivbetrieb.

Volumen ist ein Teil dessen, was sich ansammelt. Oatly führt rund 2.500 Aufträge pro Monat über diesen Weg, davon 80 % auf Autopilot. Klöckner bucht 81 % der Bestellpositionen ohne manuelle Korrektur, über 150 Lieferanten und mehr als 1.100 Bestellpositionen pro Woche. Beides sind Ergebnisse der Kurve und nicht ihr Anfang: Einführungen liegen am ersten Tag typischerweise bei rund 85 % durchgehender Verarbeitung, erreichen innerhalb weniger Wochen 93 bis 95 % und übersteigen nach etwa sechs Wochen 90 % Autopilot. Das sind typische Werte, keine Garantie. Eine Eigenentwicklung startet diesen Aufstieg bei null, mit dem eigenen Posteingang als einzigem Signal.

Wann die Eigenentwicklung die richtige Entscheidung ist

Um der Eigenentwicklung gerecht zu werden: Ist der Ablauf tatsächlich einzigartig, macht er im Wettbewerb einen Unterschied, und gibt es reichlich eigene Kapazität in Machine Learning und Entwicklung, die über Jahre gebunden werden kann, dann ist Selberbauen die richtige Entscheidung. Sie behalten die volle Kontrolle und die Rechte am Ergebnis. Und diese Kontrolle ist mehr als ein Prinzip: Das Verhalten ändert sich in Tagen statt im Rhythmus einer fremden Roadmap, jede Regel liegt dort, wo Ihr Geschäft sie braucht, und niemand Drittes sitzt im Datenpfad. Der Test ist ehrlich zu stellen: Trägt dieser Ablauf wirklich zur Unterscheidung bei, oder ist es die Standardabwicklung von Bestellungen und Aufträgen, die Hunderte anderer Unternehmen genauso betreiben? Im zweiten Fall setzt Kaufen die besten Entwickler für die Probleme frei, die wirklich die eigenen sind.

Zwei weitere Situationen gehören klar in die Spalte der Eigenentwicklung. Die erste sind strukturierte Eingänge unter eigener Kontrolle: Kommen die Aufträge per EDI von vier langjährigen Partnern oder über ein Portal, das Ihnen gehört, gibt es kaum eine letzte Meile, und der KI-Anteil schrumpft auf etwas, das ein kleines Team tragen kann. Die zweite ist ein Prozess, der noch erfunden wird: Ändern sich die Regeln jede zweite Woche, hält kein Anbietervertrag und keine Roadmap dieses Tempo, und ein Skript, das Ihr eigenes Team am Dienstag umschreiben kann, ist das bessere Werkzeug.

Wie eine faire Aufwandsschätzung aussieht

Eine belastbare Schätzung entsteht vor der Festlegung und hat drei Bestandteile. Der Umfang bemisst sich an der Autonomiequote, die der Betrieb wirklich braucht, und nicht an einer laufenden Demo, denn der Abstand zwischen beiden ist das ganze Projekt. Der Evaluationsdatensatz existiert vor der ersten Zeile Code: einige Hundert eigene Dokumente mit der jeweils richtigen Antwort daneben. Ohne ihn kann niemand sagen, ob die Version dieser Woche besser oder schlechter geworden ist. Und die Verantwortlichen für das dritte Jahr stehen im Organigramm, mit dem Wartungsaufwand in der Stellenbeschreibung. An diesem dritten Bestandteil scheitern die meisten Schätzungen.

Checkliste für die Entscheidung

• Ist dieser Ablauf ein Wettbewerbsvorteil oder gewöhnliche Betriebsinfrastruktur?
• Haben wir erfahrene Kapazität in Machine Learning und Entwicklung, die wir über mehrere Quartale binden und danach dauerhaft für die Wartung stellen können?
• Verkraften wir die Zeit bis zum Nutzen: mehrere Quartale Bauzeit gegenüber wenigen Wochen bis zum Go-live?
• Haben wir die letzte Meile und die laufende Wartung eingerechnet und nicht nur die Demo?
• Wer verantwortet das System und den Audit-Trail, wenn die Person geht, die es gebaut hat?

Die Entscheidung fällt im Vergleichstest, nicht im Business Case

Die Frage nach Make or Buy wird meist in einer Präsentation entschieden, und das ist der falsche Ort. Aussagekräftig ist der Vergleich auf demselben Monat echter Post: vier Wochen Spike für das interne Team, parallel ein Pilotbetrieb beim Anbieter, am Ende eine einzige Zahl. Diese Zahl ist der Anteil der Vorgänge, die ohne menschliches Zutun im ERP gelandet sind. Die Extraktionsgenauigkeit ist sie nicht, und wer darauf vergleicht, redet sich die Eigenentwicklung schön. Zwei Hilfsgrößen lohnen die Aufnahme: die Zeit vom Eingang eines Dokuments bis zur Buchung, und wer die ersten drei Fehler behoben hat und wie lange er dafür gebraucht hat. Ein Spike, der Ihre Messlatte auf dem gesamten Eingang erreicht und nicht nur auf dem sauberen Teil, hat die Entscheidung verdient.