Wie man Open Source ausbremst, ohne es zu verbieten
Benedikt Langer
6 Min. Lesezeit Das schärfste Argument gegen Chinas beste offene KI kommt von einem Mann bei OpenAI. ...
Zum Beitrag
7 Min. Lesezeit
Die teuerste Build-vs-Buy-Entscheidung ist die, die niemand bewusst getroffen hat. In den meisten Häusern fällt sie implizit: Ein Team baut, weil es bauen kann, oder kauft, weil ein Anbieter gerade präsentiert hat. Die saubere Rechnung gehört vor die Strategie-Folie. Wer Build, Buy und Partner als drei kalkulierbare Optionen behandelt, entscheidet schneller und revidiert seltener.
Das Wichtigste in Kürze
- Das Prinzip schlägt das Bauchgefühl. Kaufe das Übliche, baue das Einzigartige. Standardfunktionen wie Zahlung oder Authentifizierung gehören eingekauft, interne Baukapazität gehört auf die 10 bis 20 Prozent, die das Geschäft unterscheidbar machen.
- Partner ist die unterschätzte dritte Option. Zwischen Eigenbau und Lizenzkauf liegt das Co-Development oder der Managed-Service. Es senkt das Risiko, wenn die Kompetenz fehlt, und hält die Differenzierung näher am eigenen Haus als ein reines Standardprodukt.
- Die Lizenz ist nur die Spitze. Integration, Schulung und Pflege verschieben die Gesamtkosten über fünf Jahre erheblich. Eine Entscheidung, die nur die Lizenzgebühr gegen die Entwicklerstunden stellt, rechnet an der Realität vorbei.
Verwandt:Das Operating Model, das die Reorg überlebt / Managed Security Services: CISO haftet nicht allein
Was ist die Build-vs-Buy-Entscheidung? Build vs Buy beschreibt die Wahl, eine benötigte Software-Fähigkeit selbst zu entwickeln, fertig einzukaufen oder über einen Partner zu beziehen. Sie betrifft Kosten, Tempo, Kontrolle und Abhängigkeit zugleich. Die Entscheidung ist keine reine IT-Frage, sondern bestimmt, wo ein Unternehmen seine knappe Entwicklungskraft bündelt.
Warum die Frage zu spät auf den Tisch kommt
In der Praxis steht die Build-vs-Buy-Frage selten am Anfang. Sie taucht auf, wenn ein Projekt schon läuft, ein Team bereits eine Vorliebe hat oder ein Anbieter den Termin bekommen hat. Damit ist die Entscheidung faktisch gefallen, bevor jemand sie gerechnet hat. Die eigentliche Arbeit beginnt deshalb früher: bei der Frage, ob die fragliche Fähigkeit das Geschäft überhaupt unterscheidbar macht.
Diese Einordnung verlangt eine ehrliche Selbstauskunft. Ein Zahlungsabwickler, ein Identitätsdienst oder ein Content-System sind gelöste Probleme. Hier konkurriert internes Bauen gegen Anbieter, die seit Jahren nichts anderes tun. Wer trotzdem selbst baut, finanziert ein zweitklassiges Standardprodukt und bindet Kapazität, die kein Wettbewerber je zu Gesicht bekommt.
Drei Wege, ein Prinzip
Das tragende Prinzip lautet: kaufe das Übliche, baue das Einzigartige. Best-in-Class-Dienste übernehmen die Standardfunktionen, angebunden über Schnittstellen. Die interne Baukapazität konzentriert sich als grobe Heuristik auf die 10 bis 20 Prozent, die das Geschäft tatsächlich unterscheiden, etwa eine Preis-Engine, eine Logistiklogik oder ein eigener Matching-Algorithmus.
Zwischen Build und Buy liegt der oft übersehene dritte Weg. Ein Partner-Modell, ob Co-Development oder Managed-Service, greift, wenn die Fähigkeit differenzierend ist, das eigene Haus die Kompetenz aber noch nicht hat. Es teilt das Umsetzungsrisiko und hält die fachliche Hoheit näher am Haus, schafft aber eine neue Abhängigkeit und die Frage, wer am Ende verantwortet. Genau diese Managed-Variante wählen viele Häuser bei Security, wo Eigenbetrieb selten und reiner Standard zu unflexibel wäre.
Wer das Übliche selbst baut, bezahlt seine Differenzierung mit den Stunden, die ihr dann fehlen.
Die Faustregel, die die Matrix ordnet
Commodity kaufen, Differenzierung bauen, Lücke verpartnern. Die Zuordnung jeder Fähigkeit zu einer dieser drei Kategorien klärt die Entscheidung schneller als jede TCO-Tabelle. Die Rechnung kommt danach und bestätigt meist, was die Einordnung schon nahegelegt hat.
Was die Optionen wirklich kosten
Die sichtbaren Zahlen täuschen in beide Richtungen. Bei Buy steht eine überschaubare Lizenzgebühr im Angebot, doch Integration, Anpassung, Schulung und Migration legen über die Jahre erheblich darauf. Bei Build wirkt der erste Sprint günstig, bis Wartung, Sicherheits-Updates, Feature-Pflege und die Bindung knapper Entwickler die Bilanz drehen. Der Partner-Weg verschiebt diese Posten nur, er löscht sie nicht: Vendor-Management, vertragliche Exit-Klauseln, Service-Level, geteilte Verantwortung und der Wissenstransfer ins eigene Haus gehören in dieselbe Rechnung. Eine belastbare Entscheidung rechnet alle drei Optionen über fünf Jahre durch, inklusive der Kosten, die im Angebot nie auftauchen.
Der teuerste Posten steht in keiner Tabelle: die Opportunitätskosten. Jede Entwicklerstunde an einem Standardproblem ist eine Stunde, die der unterscheidbaren Fähigkeit fehlt. Diese verpasste Differenzierung schlägt langfristig härter durch als jede Lizenzgebühr. Wer das einpreist, bewertet Build bei Commodity-Themen automatisch strenger.
Der DACH-Faktor: Ressourcen und Lock-in
Im deutschen Mittelstand kippt die Rechnung oft an der Personalfrage. Wer baut, braucht ein Team, das die Lösung über Jahre trägt, nicht nur baut. Auf einem leergefegten Arbeitsmarkt ist dieses Team teurer und unsicherer als jede Lizenz. Im Mittelstand sprechen diese Halten-Kosten oft für Buy oder Partner, weil ein dauerhaftes Entwicklungsteam schwerer zu sichern ist als eine Lizenz.
Im Konzern dominiert dagegen die Lock-in-Sorge. Ein tief integriertes Standardprodukt bindet über Datenmodelle und Prozesse, und der Wechsel wird mit jedem Jahr teurer. Hier lohnt es, die Differenzierungslogik um eine Souveränitätslogik zu ergänzen: Schnittstellen offenhalten, Datenhoheit sichern und bei kritischen Bausteinen die Partner-Option prüfen, bevor ein einzelner Anbieter die Konditionen diktiert. Wer Entscheidungsrechte dafür klar verteilt, entscheidet schneller, wie das Operating Model zeigt.
Die Matrix, bevor die Folie steht
Der erste Schritt ist eine Liste der fraglichen Fähigkeiten, jede mit zwei ehrlichen Bewertungen: Wie stark unterscheidet sie das Geschäft, und wie reif ist die eigene Kompetenz dafür. Daraus folgt die Zuordnung fast von selbst. Geringe Differenzierung führt zu Buy, hohe Differenzierung mit reifer Kompetenz zu Build, hohe Differenzierung ohne Kompetenz zu Partner. Erst für die so vorsortierten Kandidaten lohnt die Fünf-Jahres-Rechnung, inklusive Integration, Pflege und Opportunitätskosten. Diese Reihenfolge dreht die übliche Praxis um: erst die strategische Einordnung, dann die Zahlen, zuletzt die Anbieterauswahl. Die Strategie-Folie steht dann am Ende des Prozesses, nicht an seinem Anfang.
Häufige Fragen
Wann lohnt sich Eigenentwicklung statt Kauf?
Wenn die Fähigkeit das Geschäft unterscheidbar macht und die eigene Kompetenz reif genug ist, sie über Jahre zu tragen. Für Standardfunktionen wie Zahlung, Authentifizierung oder ein Content-System gilt das selten. Dort konkurriert Eigenbau gegen spezialisierte Anbieter und bindet Kapazität, die der Differenzierung fehlt.
Was bringt die Partner-Option gegenüber Build und Buy?
Sie passt, wenn eine Fähigkeit differenzierend ist, die Kompetenz im Haus aber fehlt. Co-Development oder ein Managed-Service verschieben das Umsetzungsrisiko nach außen und halten die fachliche Hoheit drinnen. So lässt sich eine unterscheidbare Lösung aufbauen, ohne ein komplettes Team neu einzustellen.
Warum reicht der Lizenzvergleich für die Entscheidung nicht?
Weil die Lizenz nur die sichtbare Spitze ist. Integration, Anpassung, Schulung und Migration legen über fünf Jahre erheblich darauf, und bei Eigenbau kommen Wartung und Opportunitätskosten hinzu. Eine belastbare Rechnung betrachtet die Gesamtkosten über den gesamten Lebenszyklus, vom ersten Jahr bis zur Ablösung.
Wie startet man die Entscheidung sauber?
Mit einer Liste der fraglichen Fähigkeiten, jede bewertet nach Differenzierungsgrad und eigener Kompetenz. Daraus ergibt sich die Vorsortierung in Buy, Build oder Partner. Erst danach folgt die Fünf-Jahres-Kostenrechnung für die Kandidaten und zuletzt die Anbieterauswahl.
Weiterlesen auf Digital Chiefs
Digital ChiefsDas Operating Model, das die Reorg überlebtDigital ChiefsGolden Gate: Apple macht KI zum BurggrabenDigital ChiefsDer Weltmarkt zerfällt – Europas Stärke wird zur FalleMehr aus dem MBF Media Netzwerk
cloudmagazinCloud-Repatriation: Wann sich Rückholen rechnet mybusinessfutureCloud oder On-Prem, was betriebswirtschaftlich zählt securitytodaySecurity Awareness: die Klickrate misst das FalscheBildquelle: KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt