Build vs. Buy ist die wohl älteste Entscheidung in der Unternehmens-IT — und sie war noch nie so komplex wie heute. Die Argumente haben sich verschoben: Auf der Buy-Seite locken SaaS-Plattformen mit schneller Implementierung und kontinuierlicher Innovation. Auf der Build-Seite ermöglichen Low-Code-Plattformen, Cloud-native Frameworks und KI-gestützte Entwicklung Eigenentwicklungen in einem Bruchteil der bisherigen Zeit und Kosten.
In der Praxis fällt die erste Analyse häufig zugunsten von "Buy" aus — und ein erheblicher Teil dieser Entscheidungen wird innerhalb weniger Jahre bereut, weil die Standardsoftware die spezifischen Prozessanforderungen nicht abbilden kann. Umgekehrt scheitert ein beträchtlicher Teil der Eigenentwicklungsprojekte an Budgetüberschreitungen oder verfehlten Anforderungen.
Die Lösung liegt nicht in einer pauschalen Antwort, sondern in einem strukturierten Entscheidungsrahmen, der die spezifischen Gegebenheiten Ihres Unternehmens berücksichtigt. Und zunehmend liegt die Antwort auch nicht mehr in einem strikten Entweder-Oder, sondern in einer Composable Architecture, die beide Ansätze intelligent kombiniert.
Der Entscheidungsrahmen
Eine fundierte Build-vs-Buy-Entscheidung basiert auf fünf Dimensionen:
1. Strategische Differenzierung: Ist die Anwendung ein Wettbewerbsvorteil? Wenn ja, spricht vieles für Build. Als Faustregel gilt: Eigenentwicklung lohnt sich nur für Software, die die eigene Kernkompetenz direkt unterstützt — alles andere ist ein Kandidat für Standardsoftware.
2. Prozesspassung: Wie stark weichen Ihre Prozesse vom Marktstandard ab? Wenn eine Standardsoftware 80 Prozent Ihrer Anforderungen abdeckt, sind die restlichen 20 Prozent oft günstiger durch Prozessanpassung als durch Eigenentwicklung zu lösen.
3. Total Cost of Ownership: Berücksichtigen Sie nicht nur Entwicklungs- oder Lizenzkosten, sondern den gesamten Lebenszyklus: Wartung, Updates, Sicherheitspatches, Infrastruktur, Personal. Erfahrungsgemäß übersteigen die Wartungs- und Weiterentwicklungskosten einer Eigenentwicklung über mehrere Jahre die initialen Entwicklungskosten um ein Mehrfaches.
4. Time-to-Market: Wie dringend ist die Lösung? Standardsoftware ist oft in Wochen produktiv, Eigenentwicklungen brauchen Monate. Aber: Eine schnell eingeführte Lösung, die nicht passt, kostet langfristig mehr.
5. Verfügbarkeit von Entwicklungskapazität: Haben Sie die internen Kompetenzen — oder müssten Sie erst ein Team aufbauen? Der IT-Fachkräftemangel macht diese Frage im deutschen Mittelstand besonders relevant.
Composable Architecture: Das Beste aus beiden Welten
Die MACH Alliance — Microservices, API-First, Cloud-Native, Headless — propagiert seit 2020 einen Architekturansatz, der die Build-vs-Buy-Dichotomie auflöst.[1] Statt sich für ein monolithisches System zu entscheiden, komponieren Sie Ihre IT-Landschaft aus spezialisierten Bausteinen:
- Standardkomponenten für nicht-differenzierende Funktionen: ERP-Kern, E-Mail, Buchhaltung, HR-Administration
- Eigenentwicklungen für differenzierende Funktionen: branchenspezifische Logik, kundenindividuelle Prozesse, proprietäre Algorithmen
- API-Layer als verbindendes Element: Ein Integration Layer (iPaaS) orchestriert den Datenaustausch zwischen Standard- und Eigenentwicklungen
Marktbeobachter erwarten, dass der Anteil neuer Unternehmensanwendungen, die auf Composable-Prinzipien basieren, in den kommenden Jahren deutlich steigen wird. Der Vorteil: Sie können einzelne Bausteine austauschen, ohne die gesamte Architektur zu gefährden.
Für den Mittelstand bedeutet das konkret: Investieren Sie in eine solide API-Infrastruktur und klare Schnittstellenstandards. Dann können Sie bei jeder neuen Anforderung flexibel entscheiden, ob Sie kaufen oder bauen — ohne sich langfristig festzulegen.
Die Frage lautet nicht mehr "Build oder Buy" — sondern: Welche Komponenten bauen, welche kaufen, und wie fügen sie sich zu einer kohärenten Architektur zusammen?
Build vs. Buy: Wann was?
Build empfohlen
- Kernkompetenz und strategische Differenzierung
- Hochspezifische Prozesse ohne Marktstandard
- Langfristige Wettbewerbsvorteile durch proprietäre Logik
- Ausreichende interne Entwicklungskapazität vorhanden
- Datenhoheit und Unabhängigkeit kritisch
- Integrationskomplexität mit Bestandssystemen zu hoch für Standardsoftware
Buy empfohlen
- Commodity-Funktionen ohne Differenzierungspotenzial
- Etablierte Marktstandards und Best Practices
- Schnelle Time-to-Market erforderlich
- Regulatorische Compliance durch Vendor sichergestellt
- Begrenzte interne Entwicklungsressourcen
- Kontinuierliche Innovation durch Vendor-Community gewünscht
TCO-Analyse: Die versteckten Kosten
Eine realistische Total-Cost-of-Ownership-Betrachtung muss über den offensichtlichen Lizenz- oder Entwicklungspreis hinausgehen. In Build-vs-Buy-Entscheidungen werden regelmäßig ganze Kostenkategorien unterschätzt:
Bei Build: Anforderungsanalyse und Design, Entwicklung und Testing, Infrastruktur und DevOps, laufende Wartung und Bugfixes, Security-Patches und Updates, Personalfluktuation und Wissenstransfer, technische Schulden über die Lebensdauer.
Bei Buy: Lizenzkosten und jährliche Steigerungen, Implementierung und Customizing, Schulung und Change Management, Integrationskosten mit Bestandssystemen, Kosten für Prozessanpassungen an die Software, Vendor-Lock-in und Exit-Kosten, Risiko der Vendor-Insolvenz oder strategischen Neuausrichtung.
Eine belastbare TCO-Analyse sollte einen Betrachtungszeitraum von fünf Jahren ansetzen und Opportunitätskosten einbeziehen: Was könnte Ihr Entwicklungsteam stattdessen bauen, wenn es nicht mit der Wartung einer Eigenentwicklung beschäftigt ist?
Handlungsempfehlungen für IT-Entscheider
Entscheidungsmatrix etablieren: Implementieren Sie einen standardisierten Bewertungsprozess mit den fünf Dimensionen (Differenzierung, Prozesspassung, TCO, Time-to-Market, Kapazität) für jede neue Softwareanforderung.
TCO-Template entwickeln: Erstellen Sie eine Vorlage für die Total-Cost-of-Ownership-Analyse über fünf Jahre, die sowohl Build- als auch Buy-Szenarien mit allen versteckten Kosten abbildet.
API-First-Strategie verankern: Definieren Sie Schnittstellenstandards für Ihre IT-Landschaft, damit neue Bausteine — ob gekauft oder gebaut — nahtlos integriert werden können.
Composable Roadmap erstellen: Kartieren Sie Ihre aktuelle IT-Landschaft in differenzierende und nicht-differenzierende Komponenten. Planen Sie die schrittweise Migration zu einer modularen Architektur.
Vendor-Exit-Strategie dokumentieren: Für jede Buy-Entscheidung definieren Sie vorab, wie ein Anbieterwechsel oder eine Migration technisch und vertraglich möglich ist.
Build-Kapazität sichern: Investieren Sie in ein internes Kernteam für strategische Eigenentwicklungen und nutzen Sie externe Kapazitäten für Spitzenlasten — nicht umgekehrt.
Quellen und Referenzen
- MACH Alliance: "MACH Principles." MACH Alliance. https://machalliance.org/mach-principles