Die klassische Make-or-Buy-Rechnung trägt bei agentischen Systemen nicht mehr. Drei neue Dimensionen — Prozess-Nähe, Daten-Intensität, Veränderungs-Geschwindigkeit — führen zur Grundentscheidung, bevor Tool-Vergleiche beginnen.

Make or Buy in der Agenten-Ära. Ein Modell.

Essay #002 · 2026 · Lesezeit 6 min · Feld: Make/Buy · Markt: Mittelstand/Handwerk

Vor zehn Jahren war Make or Buy eine Entscheidung, die sich meistens gut rechnen ließ. Es gab eine Tabelle. Links die Kosten für Eigenentwicklung — Gehälter, Infrastruktur, Wartung, Opportunität. Rechts die Kosten für den Einkauf — Lizenz, Customizing, Abhängigkeit. Am Ende hatte eine Seite die bessere Zahl. Man unterschrieb.

In der Agenten-Ära funktioniert diese Tabelle nicht mehr.

Das liegt nicht daran, dass die Zahlen schwieriger geworden sind. Das liegt daran, dass sich die Kategorien unter der Tabelle verschoben haben. Was bei klassischer Software „Lizenz” war, ist bei agentischen Systemen ein Abonnement für einen Dienst, dessen Architektur sich monatlich ändert. Was „Eigenentwicklung” war, ist jetzt eher „Orchestrierung von Vorhandenem”. Was „Wartung” war, ist „permanente Rekonfiguration”. Die Begriffe tragen nicht mehr, was sie früher getragen haben.

Dieser Essay schlägt ein Modell vor, wie Make-or-Buy-Entscheidungen in der Agenten-Ära getroffen werden sollten. Es ist kein fertiges Framework. Es ist ein Denkraster, das ich in meinen eigenen Entscheidungen bei arocom und in der Arbeit mit Kunden als tragfähig empfunden habe.

Drei Dimensionen statt zwei

Die klassische Make-or-Buy-Frage kannte im Wesentlichen zwei Dimensionen: Kosten und Kontrolle. Man entschied zwischen Eigenbau (teuer, kontrolliert) und Einkauf (günstig, abhängig). Für agentische Systeme reicht das nicht. Es braucht drei Dimensionen.

Die erste: Prozess-Nähe. Wie nah ist das agentische System am Kerngeschäft? Ein Agent, der interne Rechnungen verarbeitet, ist weit vom Markt entfernt. Ein Agent, der Kundenkonversationen führt, ist mitten drin. Je näher am Markt, desto eigener sollte das System gebaut sein — nicht weil Eigenbau besser wäre, sondern weil Marktnähe bedeutet, dass Anpassungsgeschwindigkeit höher wiegt als Kosten.

Die zweite: Daten-Intensität. Welche Rolle spielen eigene Daten für das System? Wenn das System mit offenen, allgemein verfügbaren Daten arbeitet (Literaturrecherche, allgemeine Textzusammenfassung, Übersetzung), ist Einkauf günstiger und besser. Wenn das System mit firmeninternen, oft sensitiven Daten arbeitet (Kundendossiers, interne Finanzen, Prozess-Knowhow), wird die Frage schlagartig strategisch. Wer sensible Daten in eine Fremd-Architektur gibt, gibt mehr ab, als er denkt.

Die dritte: Veränderungs-Geschwindigkeit. Wie schnell ändert sich die Aufgabe, die das System erledigen soll? Ein Compliance-Check für Kreditverträge ändert sich langsam. Ein Marketing-Assistent ändert sich monatlich. Schnell ändernde Aufgaben wollen eine Architektur, die mitändert. Das ist nicht automatisch Eigenbau — aber es ist selten der große Enterprise-Einkauf.

Die drei Dimensionen zusammen ergeben acht Quadranten. Nicht alle acht sind gleich interessant. Einige sind fast immer „Buy” (niedrige Prozess-Nähe, niedrige Daten-Intensität, langsame Veränderung: das ist der Kalender-Assistent). Einige sind fast immer „Make” (hohe Prozess-Nähe, hohe Daten-Intensität, schnelle Veränderung: das ist der Vertriebsagent für ein Nischengeschäft). Die interessanten Entscheidungen liegen in den Mischbereichen — und dort hilft das Modell, den Schwerpunkt zu finden.

Ein Fall

Ein mittelständisches Industrieunternehmen. Zweihundert Mitarbeitende, spezialisierte Fertigung, viele Sonderkonstruktionen. Der Geschäftsführer steht vor der Frage: Sollen wir einen Agenten einsetzen, der technische Angebote erstellt?

Die Angebotsbearbeitung ist im Haus ein Engpass. Technische Klärung mit dem Kunden, Abgleich mit der Konstruktion, Vorkalkulation, Angebotsschreiben. Pro Angebot ein halber Arbeitstag eines Seniorkonstrukteurs. Bei steigendem Eingang ein Wachstumshindernis.

Ein Anbieter preist eine fertige Lösung an. Sie verspricht, mit interner Datenquelle trainiert zu werden. Preis: 60.000 Euro Einführung, 4.000 Euro monatlich. Attraktiv, weil schnell.

Ein eigenes Team schlägt Eigenbau vor: 140.000 Euro im ersten Jahr, danach 50.000 pro Jahr. Teurer, langsamer, aber maßgeschneidert.

Was sagt das Modell?

• Prozess-Nähe: hoch. Angebotsschreiben sind direkte Kundenkommunikation. Jede Ungenauigkeit wird sichtbar.
• Daten-Intensität: sehr hoch. Die Qualität hängt davon ab, wie gut das System Kundenhistorie, frühere Projekte, interne Margen-Logik kennt. Diese Daten sind hochsensibel.
• Veränderungs-Geschwindigkeit: mittel. Die Struktur von Angeboten ändert sich selten. Was sich ändert, sind Preise, Materialien, Randbedingungen — Stammdaten, nicht Agenten-Logik.

Die Entscheidung nach dem Modell: Kauf-Lösung ist riskant, weil Prozess-Nähe und Daten-Intensität zu hoch sind. Eigenbau ist nötig — aber weil Veränderungs-Geschwindigkeit nur mittel ist, muss der Eigenbau nicht aufwändig sein. Ein schlanker, hybrider Ansatz: Basis-Framework aus dem Markt, Integration und Anpassung im Haus. Das kostet vielleicht 80.000 im ersten Jahr, deutlich weniger pro Folgejahr.

Das Modell hat hier nicht die teuerste und nicht die billigste Variante empfohlen. Es hat die strukturell richtigste empfohlen.

Was das Modell nicht leistet

Das Modell ist kein Kalkulator. Es sagt nicht, welchen Anbieter Sie kaufen oder welche Architektur Sie bauen sollen. Es sagt Ihnen, wo die Grundentscheidung liegt — und welche Fragen Sie Ihren Leuten stellen müssen, bevor Sie diese Grundentscheidung fällen.

Das ist viel. Denn der Fehler der meisten Make-or-Buy-Entscheidungen in der Agenten-Ära ist nicht, dass die falsche Variante gewählt wurde. Der Fehler ist, dass die Entscheidung zu früh technisch wurde. Man hat Anbieter verglichen, bevor man verstanden hat, was eigentlich entschieden werden musste. Man hat über Integrations-Schnittstellen diskutiert, während die eigentliche Frage war, ob man die Daten überhaupt aus dem Haus geben will.

Das Modell erzwingt, dass diese Fragen vor den Tool-Fragen gestellt werden.

Drei Fehlmuster, die ich wiederholt gesehen habe

„Wir kaufen jetzt, bauen dann später.” Das ist die Entscheidung, die kurzfristig billig aussieht und langfristig teuer wird. Wer kauft, baut auf einer Architektur, die er nicht kontrolliert. Der Wechsel ist meist teurer als der ursprüngliche Eigenbau gewesen wäre.

„Wir bauen alles selbst.” Das ist die Entscheidung aus Kontrollangst. Auch sie ist teuer — und sie bindet Kapazität, die woanders besser eingesetzt wäre. Nicht jede Aufgabe ist Kern. Nicht jede Aufgabe braucht Maßanfertigung.

„Wir entscheiden, wenn die Technik reifer ist.” Das ist die Entscheidung des Abwartens. Sie klingt klug. Sie ist meist die schlechteste von allen. Während Sie warten, lernen Ihre Wettbewerber. Während Sie warten, gewöhnt sich Ihre Belegschaft an, dass keine klare Richtung vorgegeben wird. Während Sie warten, werden Entscheidungen irgendwo im Haus getroffen — aber nicht von Ihnen.

Der eigentliche Punkt

Das Make-or-Buy-Modell ist ein Werkzeug. Es löst keine Entscheidung — es strukturiert sie. Aber die Entscheidung selbst bleibt beim Entscheider. Und das ist der Punkt, auf den der erste Essay dieses Archivs hingewiesen hat: Wer die Make-or-Buy-Frage an externe Experten oder an interne IT-Leute delegiert, delegiert die strategische Kernfrage des Unternehmens. Die Entscheidung, wo im Unternehmen agentisch gearbeitet wird und wo nicht, ist keine IT-Entscheidung. Sie ist eine Architektur-Entscheidung im wörtlichsten Sinn: Sie formt, wie das Unternehmen in fünf Jahren aussehen wird.

Dafür braucht es ein Modell. Dafür braucht es den eigenen Kopf.

Dafür braucht es beides — getrennt.

— Axel Roth