KI Make-or-Buy: das Rechenmodell.

Die Frage „selbst bauen oder einkaufen?“ wird in KI-Projekten oft zu früh und zu emotional entschieden. Entweder ist die IT-Leitung überzeugt, dass eine Eigenentwicklung „strategischer“ sei, oder die Fachseite drängt auf eine schnelle SaaS-Lösung, weil die Demo so überzeugend war. Beide Wege haben Sinn — aber nicht ohne Zahlen. Wer eine KI-Anwendung über fünf Jahre rechnet, sieht ein anderes Bild als jemand, der nur das erste Jahr betrachtet. Lizenzkosten skalieren mit Nutzern und Volumen. Eigenentwicklungen haben einen hohen Initialaufwand, aber niedrigere Grenzkosten. Dazu kommen Posten, die in keiner Anbieter-Präsentation auftauchen: Integration, Datenaufbereitung, Compliance, Betrieb, Wartung. Dieser Artikel zeigt, wie ein belastbares Rechenmodell für die Make-or-Buy-Entscheidung aufgebaut wird — mit den Posten, die wirklich entscheiden, und einer Methodik, die sich in Excel sauber abbilden lässt.

Warum die meisten Make-or-Buy-Rechnungen schief gehen.

In der Beratungspraxis zeigt sich ein wiederkehrendes Muster: Make-or-Buy-Entscheidungen werden auf Basis von zwei Zahlen getroffen — der Jahreslizenz eines Anbieters und einer geschätzten Entwicklungssumme für die Eigenlösung. Beides ist unvollständig. Die Lizenz enthält selten alle Kosten, die Eigenentwicklung wird systematisch unterschätzt.

Auf der Buy-Seite fehlen meist Integration, Datenanbindung, Premium-Module, Support-Pakete, Nutzerlizenzen oberhalb des Standard-Tarifs und Token-Verbrauch bei nutzungsbasierter Abrechnung. Auf der Make-Seite fehlen interner Aufwand für Spezifikation und Tests, laufender Betrieb, Modell-Updates, Sicherheitsprüfungen, Skalierungskosten und der Aufwand für Datenaufbereitung, ohne den weder Make noch Buy funktioniert.

Ein zweites Problem ist der Zeithorizont. Wer nur das erste Jahr betrachtet, gewichtet Initialinvestitionen zu hoch. Eine Eigenentwicklung mit 180.000 Euro Initialaufwand und 30.000 Euro jährlichem Betrieb sieht im ersten Jahr teurer aus als eine SaaS-Lösung mit 60.000 Euro Jahresgebühr. Über fünf Jahre dreht sich das Bild — die Eigenentwicklung kostet kumuliert 300.000 Euro, die SaaS-Lösung 300.000 bis 450.000 Euro je nach Preissteigerung und Nutzerwachstum.

Die Postenliste auf beiden Seiten.

Ein belastbares Rechenmodell beginnt mit einer vollständigen Postenliste. Beide Seiten brauchen die gleiche Kategorienstruktur, damit die Vergleichbarkeit gewährleistet ist. Folgende Tabelle zeigt die Posten, die in der Praxis erfahrungsgemäß den Ausschlag geben.

Wichtig ist die Position „Datenaufbereitung“. Sie wird oft als Make-Argument missverstanden — als ob eine SaaS-Lösung das Datenproblem mitlöst. Sie löst es nicht. Wer schmutzige, fragmentierte Daten in ein SaaS-Tool gibt, bekommt schmutzige, fragmentierte Ergebnisse zurück. Diese Position ist auf beiden Seiten in vergleichbarer Höhe anzusetzen.

Der Fünfjahres-Horizont und seine Tücken.

Ein Rechenmodell für KI-Projekte sollte mindestens fünf Jahre umfassen. Drei Jahre sind zu kurz, weil Eigenentwicklungen ihre Stärke erst im zweiten und dritten Betriebsjahr ausspielen. Sieben Jahre sind zu lang, weil die Annahmen über Nutzerzahlen, Volumen und Anbieter-Preise dann nur noch Spekulation sind.

Innerhalb des Fünfjahres-Horizonts gibt es drei Effekte, die das Bild stark verändern. Erstens: Lizenz-Preissteigerungen. SaaS-Anbieter erhöhen ihre Preise jährlich, im KI-Umfeld aktuell um 8 bis 15 Prozent. Wer mit konstanten Preisen rechnet, unterschätzt die Kosten massiv. Zweitens: Nutzerwachstum. Eine Lösung, die im ersten Jahr von 30 Mitarbeitenden genutzt wird, hat im dritten Jahr oft 80 bis 120 Nutzer. Drittens: Volumenwachstum. Token-basierte Abrechnungen skalieren mit der Nutzungsintensität, die fast immer steigt.

Demgegenüber stehen auf der Make-Seite drei dämpfende Effekte: Fallende LLM-API-Kosten (in den letzten drei Jahren um 60 bis 80 Prozent gesunken), Lerneffekte im Betrieb (ab Jahr zwei sinkt der Betriebsaufwand um 20 bis 30 Prozent), und Wiederverwendung der entwickelten Infrastruktur für andere Anwendungsfälle. Diese Effekte machen die Eigenentwicklung über die Distanz attraktiver — aber nur, wenn sie sauber gerechnet werden.

Beispielrechnung: Vertriebs-Assistent für 80 Nutzer.

Eine konkrete Rechnung macht das Modell greifbar. Ausgangslage: Ein mittelständischer Maschinenbauer will einen KI-gestützten Vertriebs-Assistenten einführen, der Angebote vorbereitet, technische Anfragen klassifiziert und auf historische Projektdaten zugreift. Geplante Nutzerzahl: 80 im Vertrieb und Service. Volumen: rund 200 komplexere Anfragen pro Tag.

Die Buy-Lösung ist im ersten Jahr 100.000 Euro günstiger, über fünf Jahre aber rund 85.000 Euro teurer. Das Bild kann sich verschieben — wenn die Nutzerzahl niedriger bleibt, gewinnt Buy; wenn sie steigt, gewinnt Make. Ohne Rechenmodell wird diese Sensitivität nicht sichtbar.

Die fünf Sensitivitäten, die das Ergebnis kippen.

Ein Rechenmodell ist nur so gut wie seine Sensitivitäten. In der Beratungspraxis sind es fünf Variablen, deren Veränderung das Ergebnis von Make-or-Buy regelmäßig dreht — und die deshalb in jedem Excel-Modell als veränderbare Parameter sichtbar sein müssen.

• Nutzerzahl: Bei nutzerbasierten Lizenzen verändert eine Verdopplung der Nutzer die Buy-Seite linear, die Make-Seite kaum. Schon kleine Abweichungen kippen die Entscheidung.
• Volumenwachstum: Bei Token-Abrechnung treibt steigendes Volumen die Buy-Kosten überproportional. Eigenentwicklungen profitieren von fallenden API-Preisen.
• Lizenz-Preissteigerung: 5 Prozent oder 15 Prozent jährliche Erhöhung machen über fünf Jahre einen Unterschied von 50.000 bis 150.000 Euro.
• Entwicklungsdauer: Verzögert sich die Eigenentwicklung um drei Monate, verschiebt sich nicht nur der Start des Nutzens, sondern auch die Personalkosten.
• Personalkostensatz: Interne Entwicklung mit 800 € Tagessatz oder externe Dienstleister mit 1.400 € sind eine andere Welt.

Ein gutes Rechenmodell zeigt diese Sensitivitäten in einer Tabelle: Was passiert mit dem Fünfjahres-Total, wenn jede Variable um plus/minus 20 Prozent abweicht? Wer diese Tabelle sieht, versteht, wo die Entscheidung wirklich entschieden wird.

Hybridmodelle: Build on top of Buy.

In vielen Fällen ist die richtige Antwort nicht Make oder Buy, sondern eine Mischung. Das gängigste Muster: Eine kommerzielle Basis-Plattform wird eingekauft, darauf werden eigene Komponenten gebaut, die das unternehmensspezifische Wissen kapseln. Beispiele sind Microsoft Copilot Studio mit eigenen Konnektoren, oder eine LLM-API von OpenAI/Anthropic mit eigener Vector-Datenbank und Retrieval-Schicht.

Im Rechenmodell bedeutet das eine dritte Spalte. Sie nimmt auf der Lizenz-Seite reduzierte Posten auf (etwa nur API-Kosten statt vollständiger Plattform-Gebühr), auf der Make-Seite reduziert sie Initial- und Betriebskosten (etwa kein eigenes Hosting der Modelle, kein eigenes Training). Häufig liegt der Fünfjahres-Total dieser Hybridvariante 15 bis 30 Prozent unter beiden Reinformen — bei vergleichbarer Funktionalität.

Aufpassen sollte man beim Lock-in. Hybridmodelle binden das Unternehmen an die Basis-Plattform. Wechselt diese die Preise oder die Lizenzbedingungen, ist die ganze Aufbauarbeit gefährdet. Im Rechenmodell sollte daher ein Sensitivitäts-Szenario „Plattform-Wechsel“ enthalten sein, das die Kosten eines Wechsels nach drei Jahren modelliert. Wer mit dieser Zahl unwohl ist, sollte die Eigenanteile reduzieren oder eine andere Plattform-Architektur wählen.

Was das Rechenmodell nicht kann.

So nützlich ein Excel-Modell ist — es entscheidet nicht alleine. In der Praxis zeigen sich drei Grenzen, die ein Geschäftsführer kennen muss, bevor er die Zahl aus dem Modell zur Grundlage seiner Entscheidung macht.

Erstens: Strategische Aspekte lassen sich nicht in Euro fassen. Wenn die KI-Komponente Teil des eigenen Produkts wird oder ein Wettbewerbsvorteil daraus entsteht, ist eine 100.000-Euro-Mehrinvestition in den Eigenbau möglicherweise gerechtfertigt, obwohl das Rechenmodell SaaS empfiehlt. Zweitens: Datenschutz und Souveränität. Bestimmte Daten dürfen nicht über externe APIs verarbeitet werden, unabhängig von der wirtschaftlichen Logik. Das ist eine Ja/Nein-Entscheidung, kein Posten im Modell.

Drittens: Risiko. Ein Eigenbau hat Umsetzungsrisiko — er kann scheitern, sich verzögern, das Ergebnis kann hinter den Erwartungen bleiben. Eine SaaS-Lösung hat Anbieter-Risiko — Preissprünge, Lizenzänderungen, Übernahmen, Abkündigung des Produkts. Beide Risiken sind real, aber unterschiedlich. Ein gutes Rechenmodell macht sie sichtbar, etwa durch Szenarien für „Eigenbau dauert 50 Prozent länger“ und „Anbieter erhöht Preis um 25 Prozent in Jahr 3“.

Was Entscheider als nächstes tun sollten.

Wer vor einer Make-or-Buy-Entscheidung steht, sollte nicht mit der Tool-Auswahl beginnen, sondern mit dem Rechenmodell. In der Praxis hat sich folgende Reihenfolge bewährt: Anwendungsfall sauber beschreiben (was soll die KI lösen, für wen, in welchem Volumen), Postenliste vervollständigen, Annahmen dokumentieren, Sensitivitäten rechnen, dann erst die Entscheidung treffen.

Das Modell selbst sollte nicht von einer einzigen Person gebaut werden. Die Fachseite kennt das Volumen und die Nutzerzahlen, die IT kennt Integration und Betrieb, der Einkauf kennt die Lizenzlogik, die Geschäftsführung kennt die strategische Einordnung. Wenn diese vier Perspektiven nicht im Modell vertreten sind, fehlt etwas. Ein guter Workshop von einem halben Tag reicht oft aus, um die Annahmen zusammenzutragen.

Die Entscheidung selbst sollte am Ende nicht „weil das Modell so sagt“ begründet werden, sondern „weil unsere Annahmen so sind“. Wenn jemand die Annahmen begründet ändert, ändert sich auch das Ergebnis. Diese Transparenz ist der eigentliche Wert eines belastbaren Rechenmodells — sie macht aus einer Bauchentscheidung ein nachvollziehbares Argument, das auch ein Jahr später noch trägt.

Sie wollen für eine konkrete KI-Anwendung ein belastbares Make-or-Buy-Modell aufbauen? Unverbindlich anfragen — wir bauen gemeinsam die Postenliste, sammeln die Annahmen und prüfen die Sensitivitäten.