Build vs. Buy bei KI-Workflow-Automatisierung: Wann eine Plattform reicht und wann nicht

Build vs. Buy ist bei KI-Workflow-Automatisierung die falsche erste Frage

Jede Anbieterauswahl für KI-Workflow-Automatisierung landet irgendwann an derselben Weggabelung: eine Plattformlizenz kaufen und konfigurieren oder etwas auf den Systemen bauen, die Sie bereits betreiben. Beide Lager haben eine überzeugende Präsentation. Der Plattformanbieter zeigt eine Demo, die eine saubere, wohlgeformte Version Ihres Prozesses an einem Nachmittag automatisiert. Das Build-Lager zeigt ein Diagramm Ihres tatsächlichen Stacks mit Pfeilen in einen neuen Kasten. Keine der beiden Präsentationen beantwortet die Frage, die darüber entscheidet, ob sich das Geld rechnet: Wie viel dieses Workflows braucht überhaupt ein Modell?

Diese Frage hat eine messbare Antwort, und die Antwort ist meist eine kleine Zahl. Im Workflow zur Auftragsabwicklung eines europäischen Herstellers, den SUPALABS Schritt für Schritt kartiert hat, benötigten drei von elf Schritten tatsächlich ein Modell. Die übrigen acht waren Parsing, Abfragen, Validierung und Routing, also Arbeit, die gewöhnliche Software günstiger und schneller erledigt, mit einem Ergebnis, das Sie morgen reproduzieren können (SUPALABS-Projektdaten, 2024–2026). Sobald Sie diese Zahl für Ihren eigenen Prozess kennen, entscheidet sich die Frage nach Build oder Buy weitgehend von selbst, denn eine Plattform ist so bepreist, als wäre jeder Schritt einer von der schwierigen Sorte.

Warum die Plattform-Demo funktioniert und der Rollout nicht

Die Plattform-Demo funktioniert, weil sie auf dem dokumentierten Prozess läuft. Fragen Sie ein Unternehmen, was Schritt eins der Auftragsabwicklung ist, und Sie hören: „Eine E-Mail kommt an.“ Das ist wahr und nutzlos. Der reale Schritt eins sind vierzig Absender, keine zwei gleich, manche mit dem Auftrag im Mailtext, manche in einem angehängten PDF, manche in einer Tabelle, deren Spalten sich jedes Quartal ändern, und ein Großkunde, der anruft und erwartet, dass der Vertriebsmitarbeiter alles abtippt. Die Demo automatisiert die erste Version. Der Rollout trifft auf die zweite.

Genau dieses Muster steckt hinter der Zahl des MIT. Für die NANDA-Studie wurden 52 Führungskräfte interviewt, 153 Entscheider befragt und 300 öffentlich bekannte Implementierungen analysiert. Das Fazit: Die Kluft zwischen den 5 %, die Wert schaffen, und den 95 %, die es nicht tun, liegt nicht an Talenten, Infrastruktur oder Regulierung. Sie liegt am Fehlen von Lernfähigkeit, Integration und Anpassung an den Kontext: Das System nimmt kein Feedback auf, passt nicht zu dem Workflow, in den es gesetzt wurde, und kennt die Ausnahmen nicht, die den Workflow real machen. Eine Plattformlizenz behebt nichts davon von allein, denn der Anbieter hat Ihre Ausnahmen nie gesehen. Eine interne Umsetzung ebenso wenig, wenn sie vom selben dokumentierten Prozess ausgeht wie die Demo.

Praktisch folgt daraus, dass die Wahl zwischen Kaufen und Bauen weniger wichtig ist als das, was ihr vorausgeht: eine schriftliche Darstellung, wie der Workflow tatsächlich abläuft, Ausnahme für Ausnahme, bevor Geld gebunden wird. Warum der dokumentierte Prozess nie der reale Prozess ist, haben wir separat beschrieben; bei der Entscheidung zwischen Build und Buy wird diese Lücke teuer.

Wann der Kauf einer Plattform die richtige Antwort ist

Plattformen verdienen ihre Lizenz unter ganz bestimmten Bedingungen, und es lohnt sich, sie klar zu benennen, statt so zu tun, als wäre eine eigene Umsetzung immer besser. Kaufen Sie, wenn:

• Der Workflow regelmäßig ist und die Eingaben bereits strukturiert vorliegen. Rechnungen, die über das italienische Austauschsystem SDI eingehen, Tickets aus einem Helpdesk mit Pflichtfeldern, Bestellungen aus einem B2B-Portal mit festem Schema. Wenn die Daten sauber ankommen, können Konnektor und Regel-Engine einer Plattform die Arbeit tragen, und die Teile, die ein Modell brauchen, sind klein genug, um sie zu konfigurieren.
• Die nativen Konnektoren der Plattform die Systeme abdecken, die Sie tatsächlich betreiben. Nicht „hat eine API“, sondern „hat einen gepflegten Konnektor für diese ERP-Version, dieses CRM, dieses Dokumentenmanagement“. Zwischen beidem liegt die Lücke, in der die meisten Rollouts stecken bleiben.
• Das Volumen hoch und die Varianz gering ist. Zehntausend identische Transaktionen im Monat rechtfertigen eine Lizenz; zweihundert Transaktionen in zweihundert Varianten nicht.
• Sie günstig herausfinden müssen, ob die Idee trägt. Ein Monat Lizenzgebühren, um herauszufinden, dass der Prozess nicht so ist, wie alle dachten, ist ein gutes Geschäft. Die Falle besteht darin, bei der Lizenz zu bleiben, nachdem dieser Monat die Frage beantwortet hat.

So eingesetzt ist eine Plattform ebenso sehr ein Messinstrument wie ein Produkt. Der Fehler liegt darin, die Lizenz als Ziel zu betrachten statt als Experiment.

Wann die eigene Umsetzung die richtige Antwort ist

Bauen Sie, wenn die Ausnahmen der Prozess sind. Das klingt nach Slogan, deshalb hier der Test. Setzen Sie sich einen Tag lang neben die Person, die den Workflow betreibt, und notieren Sie jedes Mal, wenn der dokumentierte Weg nicht der tatsächlich gegangene ist: der Kunde, der Bestellungen als Foto einer handschriftlichen Notiz schickt, die Lieferantenrechnung mit einer Bestellnummer, die es nicht gibt, die Freigabe, die freitags an eine andere Führungskraft geht, weil die zuständige außer Haus ist. Zählen Sie mit. Sind es eine Handvoll, fängt die Ausnahmebehandlung einer Plattform sie auf. Sind es Dutzende, und jede folgt einer Regel, die im Kopf von jemandem liegt, dann läuft es auf eine eigene Umsetzung hinaus, denn die Arbeit besteht dann nicht darin, den Prozess zu automatisieren, sondern ihn zum ersten Mal aufzuschreiben.

Die zweite Bedingung für eine eigene Umsetzung ist ein System, das Sie behalten wollen. Plattformen bringen oft eine stillschweigende Migration mit: Verlagern Sie die Daten hierher, leiten Sie den Workflow über uns, lassen Sie uns für diesen Teil des Geschäfts das führende System werden. Für ein Unternehmen, dessen ERP- oder Warenwirtschaftssystem seit fünfzehn Jahren Fakturierung, Produktion und Lohnabrechnung trägt, ist das kein Feature. Es ist das größte Karriererisiko, das eine Führungskraft in Operations oder IT eingehen kann, und es ist fast nie das, was das Problem tatsächlich erfordert. Eine Umsetzung auf den bestehenden Systemen, über deren Schnittstellen, lässt das führende System, wo es ist, und ergänzt die fehlenden Schritte daneben. Diese Zusage geben wir zu Beginn jedes Projekts schriftlich, denn die Frage „Heißt das, wir müssen unsere Software ersetzen?“ stellt ein CIO als Erstes, und ihr weichen Anbieter am häufigsten aus.

Die Zahl, die es entscheidet: die Determinismus-Quote

Hier ist die Kennzahl, die Anbieter auf beiden Seiten lieber nicht ausrechnen, weil sie beide Präsentationen untergräbt. Nehmen Sie den Workflow, listen Sie seine Schritte auf und ordnen Sie jeden als deterministischen Code, Modellurteil oder Entscheidung ein, die bei einem Menschen bleibt. Der Anteil der deterministischen Schritte ist die Determinismus-Quote, und sie ist meist hoch. In der oben erwähnten Auftragsabwicklung des Herstellers lag sie bei acht von elf. In einem Quote-to-Cash-Prozess mit fünf Übergaben lag sie höher. Bei rechercheintensiver Beratungsarbeit ist sie niedriger, weil das Rohmaterial Text ist und das Modell den Großteil der Entwürfe schreibt; dort hat SUPALABS eine um 30–50 % schnellere Erstellung von Arbeitsergebnissen gemessen, konzentriert auf Recherche und ersten Entwurf (SUPALABS-Projektdaten, 2024–2026).

Warum entscheidet die Quote über Build oder Buy? Weil eine Plattform für die schwierigen Schritte bepreist ist. Die Lizenz, die Gebühr pro Nutzer, die Nutzungsstufe: All das unterstellt, dass das Modell die Arbeit macht. Wenn das Modell drei von elf Schritten übernimmt, zahlen Sie Modellpreise für die anderen acht, die aus Abfragen und Validierung bestehen, die eine gut gebaute Integration für die Kosten eines Servers erledigt. Umgekehrt gilt: Wenn die Quote niedrig ist und die meisten Schritte tatsächlich Urteilsvermögen erfordern, kann eine Plattform mit ausgereiften Werkzeugen für Evaluation und Monitoring der günstigere Weg sein, sofern ihre Konnektoren Ihre Systeme erreichen.

Die Quote ist auch eine Governance-Kennzahl. Jeder Schritt, der aus dem Modell herausgehalten wird, lässt sich einem Wirtschaftsprüfer als Regel zeigen, statt als Stichprobe begründet werden zu müssen. Für ein Unternehmen, das eines Tages einer Aufsichtsbehörde, einer Werksleitung oder dem Due-Diligence-Team eines Käufers eine automatisierte Entscheidung erklären muss, ist das keine technische Vorliebe. Es ist der Unterschied zwischen einem Entscheidungsprotokoll und einem Achselzucken.

Was eine Umsetzung Ihnen übergeben sollte, damit Sie in keinem Fall gebunden sind

Der ehrliche Einwand gegen eine eigene Umsetzung ist ein Lock-in anderer Art: die Abhängigkeit von den Menschen, die sie gebaut haben. Dieser Einwand ist berechtigt, wenn die Umsetzung als Blackbox geliefert wird. Er ist es nicht, wenn sie mit den Dokumenten geliefert wird, die sie prüfbar machen. Eine Umsetzung, die ihr Geld wert ist, kommt mit einem Ausnahmeregister (jede reale Abweichung vom dokumentierten Prozess, wie oft sie vorkommt, wer sie auffängt), einer KI-Grenzkarte (die schrittweise Einordnung, aus der die Determinismus-Quote hervorgeht), einer Evaluationssuite mit Golden Dataset und monatlichem Genauigkeitsbericht sowie einem Entscheidungsprotokoll, das ein Compliance-Verantwortlicher öffnen kann, ohne einen Entwickler zu fragen. Diese vier, zusammen mit der schriftlichen Zusage, die Systeme, die Sie betreiben, nicht zu ersetzen, sind die fünf Artefakte, die die SUPALABS-Methode in jedem Projekt liefert. Sie sind der Grund, warum eine Umsetzung beendet werden kann, ohne verloren zu gehen: Das System läuft in Ihren Accounts, das Golden Dataset bleibt bei Ihnen, und das Einzige, was mit dem Service endet, ist der monatliche Bericht.

Fragen Sie jeden Umsetzungspartner vor der Unterschrift namentlich nach diesen Dokumenten. Fragen Sie jeden Plattformanbieter, wie Sie sie aus seinem Produkt heraus erstellen würden. Die Antworten sagen Ihnen mehr als jede der beiden Präsentationen.

Eine Reihenfolge für die Bewertung

Wenn die Entscheidung wirklich offen ist, ist dies die günstigste Reihenfolge. Erstens: Kartieren Sie den Workflow mit den Menschen, die ihn betreiben, und zwar lange genug, um das Ausnahmeregister und die Grenzkarte zu erstellen. Fünf Tage reichen für einen Workflow; ein ganzes Quartal Analyse ist nicht nötig und meist ein Zeichen dafür, dass der Partner Zeit abrechnet, statt Antworten zu finden. Zweitens: Lesen Sie die Determinismus-Quote an der Karte ab. Drittens: Ist die Quote hoch und sind die Systeme solche, die Sie behalten wollen, bauen Sie darauf auf, zum Festpreis und mit einem Umfang, der aus der Karte abgeleitet ist statt aus einer Schätzung. Ist die Quote niedrig, sind die Eingaben strukturiert und erreichen die Konnektoren einer Plattform Ihren Stack, kaufen Sie die Lizenz für einen Monat und lassen Sie sich von derselben Karte zeigen, ob die Plattform die Ausnahmen überstanden hat. So oder so ist die Karte das eigentliche Asset, und sie ist genau das, was keine der beiden Präsentationen angeboten hat.

Die BCG-Umfrage vom Juli 2026 unter 152 CEOs von Unternehmen mit mindestens 500 Mio. $ Umsatz ergab, dass zwei Drittel KI-Pilotprojekte verfolgen und nur 26 % KI in eine umfassendere Transformation eingebettet haben. Das ist das Marktsegment mit dem Budget, jede beliebige Plattform zu kaufen, und dem Personal, alles Gewünschte selbst zu bauen, und es steckt trotzdem fest. Der Engpass ist nicht die Kaufentscheidung. Er besteht darin, dass niemand aufgeschrieben hat, wie die Arbeit tatsächlich abläuft, bevor sie verändert werden sollte.

Quellen & Referenzen