Eine nachvollziehbare Make-or-Buy-Entscheidung vergleicht Eigenentwicklung, Fremdbezug und hybride Lösungen anhand einheitlicher Kriterien. Neben Kosten zählen strategische Bedeutung, Time-to-Market, Know-how, Security, Integration, Skalierbarkeit und Exit-Fähigkeit. Das Ergebnis sollte nicht nur eine Punktzahl, sondern eine dokumentierte und überprüfbare Entscheidung sein.
Ausgangssituation & Zielbild
Unternehmen und Behörden stehen regelmäßig vor der Frage, ob sie eine Anwendung, Plattform oder technische Fähigkeit selbst entwickeln oder am Markt beschaffen sollen. Häufig wird die Diskussion auf Lizenzpreis und Entwicklungsbudget reduziert. Dabei werden Betriebsaufwand, Abhängigkeiten, Änderungsfähigkeit und langfristiger Kompetenzbedarf unterschätzt.
Das Hauptkeyword „Make-or-Buy-Entscheidung“ bezeichnet einen strukturierten Vergleich verschiedener Bereitstellungsmodelle über den gesamten Lebenszyklus.
Make-or-Buy ist selten eine rein wirtschaftliche Entscheidung. Sie verbindet Produktstrategie, Architektur, Beschaffung, Security, Betrieb und Personalentwicklung.
Das Zielbild ist eine Entscheidung, deren Annahmen, Kriterien, Risiken und Konsequenzen auch später nachvollziehbar bleiben.
Wie entwickle ich eine Make-or-Buy-Entscheidung anhand nachvollziehbarer Kriterien?
Eine belastbare Make-or-Buy-Entscheidung vergleicht Eigenentwicklung, Fremdbezug und hybride Modelle über den gesamten Lebenszyklus. Neben Kosten zählen strategische Bedeutung, Time-to-Market, Know-how, Security, Integration, Betriebsfähigkeit und Exit-Fähigkeit.
Die zentrale Empfehlung: Bewerten Sie nicht nur Make und Buy, sondern immer auch eine hybride Option. Definieren Sie zunächst lösungsneutrale Anforderungen, legen Sie Ausschlusskriterien fest und bewerten Sie die verbleibenden Modelle anhand gewichteter Kriterien, einer TCO-Betrachtung und einer Sensitivitätsanalyse.
Welche Fragen muss die Entscheidung beantworten?
Make-or-Buy ist keine reine Preisentscheidung. Die Organisation muss klären, welche Fähigkeiten strategisch kontrolliert werden sollen, wie schnell eine Lösung benötigt wird und welche Abhängigkeiten über mehrere Jahre tragbar sind.
Differenziert die Fähigkeit die Organisation oder handelt es sich um eine weitgehend standardisierte Unterstützungsfunktion?
Welche Gesamtlebenskosten entstehen für Einführung, Integration, Betrieb, Support, Weiterentwicklung, Migration und Exit?
Wie werden Security, Datenschutz, Compliance, Auditierbarkeit, Verfügbarkeit und Lieferantenrisiken beherrscht?
Sind internes Know-how, Kapazität, Architekturkompetenz und Betriebsressourcen in der benötigten Zeit verfügbar?
Make, Buy oder Hybrid?
| Modell | Typische Vorteile | Typische Herausforderungen | Geeignet, wenn … |
|---|---|---|---|
| Make | Hohe Kontrolle, individuelle Differenzierung und Aufbau eigenen Know-hows | Personalbedarf, längere Umsetzung und vollständige Betriebsverantwortung | die Fähigkeit strategisch wichtig und intern beherrschbar ist |
| Buy | Schnellerer Start, vorhandene Produktreife und etablierter Support | Lizenzkosten, Anpassungsgrenzen und Herstellerabhängigkeit | Standardfunktionen genügen und Time-to-Market besonders wichtig ist |
| Hybrid | Kombination aus Standardplattform und eigenen differenzierenden Komponenten | Zusätzliche Integrations-, Governance- und Verantwortlichkeitsfragen | Basisfunktionen beschafft, strategische Fähigkeiten aber selbst entwickelt werden sollen |
Make-or-Buy-Entscheidung in sechs Schritten
Ziel und Fähigkeit beschreiben
Formulieren Sie den benötigten Geschäftsnutzen lösungsneutral. Produktnamen oder bevorzugte Technologien gehören noch nicht in die Anforderung.
Ausschlusskriterien festlegen
Definieren Sie Mindestanforderungen an Datenschutz, Security, Schnittstellen, Datenhaltung, Verfügbarkeit und Auditierbarkeit.
Kriterien gewichten
Priorisieren Sie strategische Passung, Time-to-Market, TCO, Integration, Know-how, Betrieb und Exit-Fähigkeit.
Optionen bewerten
Bewerten Sie Make, Buy und Hybrid mit derselben Skala und dokumentieren Sie für jede Punktzahl die zugrunde liegenden Nachweise.
Annahmen validieren
Prüfen Sie kritische Annahmen durch Marktanalyse, Anbieterworkshop, Referenzen, technischen Proof of Concept oder Prototyp.
Entscheidung dokumentieren
Halten Sie Kontext, Optionen, Kriterien, Annahmen, Konsequenzen, Verantwortlichkeiten und Review-Termin in einem Decision Record fest.
Geeignete Bewertungskriterien
| Kriterium | Leitfrage | Möglicher Nachweis |
|---|---|---|
| Strategische Passung | Entsteht ein relevanter Wettbewerbsvorteil oder eine organisationsspezifische Kernfähigkeit? | Produktstrategie, Zielarchitektur, Geschäftsziele |
| Time-to-Market | Wann kann die benötigte Fähigkeit produktiv genutzt werden? | Projektplan, Implementierungsangebot, Pilot |
| Total Cost of Ownership | Welche Kosten entstehen über Einführung, Betrieb, Weiterentwicklung und Exit? | Mehrjährige TCO-Rechnung |
| Know-how und Kapazität | Sind Kompetenzen und Ressourcen dauerhaft verfügbar? | Skill-Matrix, Kapazitätsplanung, Recruiting-Risiko |
| Integration und Betrieb | Passt die Lösung zu Schnittstellen, Datenmodellen, Monitoring und Supportprozessen? | Architekturreview, Integrationsprototyp |
| Exit-Fähigkeit | Können Daten, Konfigurationen und Prozesse später kontrolliert migriert werden? | Exit-Konzept, Vertragsklauseln, Exporttest |
Total Cost of Ownership vollständig betrachten
Entwicklung, Lizenzierung, Beratung, Beschaffung, Migration, Konfiguration, Tests und Projektmanagement
APIs, Datenmigration, Identity Management, Schnittstellen, Customizing und Anpassungen
Infrastruktur, Cloud-Nutzung, Support, Monitoring, Security, Updates und Personal
Weiterentwicklung, Schulung, Vertragsänderung, Datenexport, Ablösung und Übergabe
Häufige Fehler
Integration, Betrieb, Weiterentwicklung, Schulung und Exit können den ursprünglichen Preis deutlich übersteigen.
Entwicklungsaufwand, Personalverfügbarkeit und langfristige Wartungsverantwortung werden häufig zu optimistisch bewertet.
Proprietäre Schnittstellen und Datenformate können einen späteren Anbieterwechsel erheblich erschweren.
Eine Bewertungsmatrix bleibt subjektiv, wenn Nachweise, Annahmen und Unsicherheiten nicht dokumentiert werden.
Best Practices
- Anforderungen lösungsneutral und aus Sicht des benötigten Nutzens formulieren.
- Make, Buy und Hybrid mit identischen Kriterien vergleichen.
- Kritische Security-, Datenschutz- und Architekturvorgaben als Ausschlusskriterien behandeln.
- TCO über einen realistischen Zeitraum einschließlich Migration und Exit berechnen.
- Fachbereich, Architektur, Entwicklung, Betrieb, Security, Einkauf und Controlling beteiligen.
- Unsichere Annahmen durch Proof of Concept oder Marktvalidierung prüfen.
- Datenportabilität, Vertragsausstieg und Übergabefähigkeit frühzeitig bewerten.
- Die Entscheidung mit Annahmen, Konsequenzen und Review-Termin dokumentieren.
Empfehlung für Unternehmen und Behörden
In Enterprise- und Behördenumgebungen sollte die Make-or-Buy-Entscheidung frühzeitig mit Zielarchitektur, Vergabeverfahren, Datenschutz, Informationssicherheit und Betriebsmodell verbunden werden.
Besonders tragfähig ist häufig ein hybrider Ansatz: Standardisierte Basisfunktionen werden beschafft, während strategisch relevante Prozesse, Integrationen oder Benutzererlebnisse unter eigener Kontrolle bleiben.
Zusammenfassung
Eine nachvollziehbare Make-or-Buy-Entscheidung beginnt mit einer lösungsneutralen Beschreibung der benötigten Fähigkeit. Anschließend werden Ausschlusskriterien, gewichtete Entscheidungskriterien und realistische Gesamtlebenskosten definiert.
Die beste Option ist nicht automatisch die mit der höchsten Punktzahl. Entscheidend ist, ob Annahmen, Risiken, Abhängigkeiten und Konsequenzen transparent dokumentiert und durch belastbare Nachweise gestützt werden.
Häufige Fragen
Welche Kriterien sind bei einer Make-or-Buy-Entscheidung besonders wichtig?
Besonders wichtig sind strategische Passung, Time-to-Market, Gesamtlebenskosten, Know-how, Security, Integration, Betriebsfähigkeit und Exit-Fähigkeit.
Wann ist eine hybride Lösung sinnvoll?
Ein hybrides Modell eignet sich, wenn standardisierte Basisfunktionen schnell beschafft, strategisch relevante Komponenten aber selbst entwickelt oder kontrolliert werden sollen.
Wie vermeidet man subjektive Entscheidungen?
Durch ein interdisziplinäres Bewertungsteam, einheitliche Kriterien, dokumentierte Nachweise, Sensitivitätsanalysen und die Validierung kritischer Annahmen.
Autor
Florian Deinhard
Artikel erstellt: 05.08.2026
Artikel aktualisiert: 05.08.2026
