Build vs. Buy vs. Partner: Ein Entscheidungsrahmen für IT-Führungskräfte im Unternehmen

Jede bedeutende Technologieentscheidung in einem Unternehmen reduziert sich letztlich auf drei Optionen: selbst entwickeln, ein Produkt kaufen oder mit jemandem zusammenarbeiten, der es bereits umgesetzt hat.

Die Entscheidung klingt einfach. In der Praxis wird sie durch Anbieterversprechen, Engineering-Enthusiasmus, Budgetrestriktionen und Organisationspolitik getrübt. Teams, die entwickeln, wo sie kaufen sollten, verschwenden 18 Monate damit, Bestehendes neu zu erfinden. Teams, die kaufen, wo sie entwickeln sollten, verbringen Jahre damit, ein Produkt in etwas umzubauen, wofür es nie konzipiert wurde.

Dieses Framework bietet einen strukturierten Ansatz für die Entscheidung.

Die Entscheidungskriterien

Kriterium 1: Strategische Differenzierung

Bewertung 1-5: Wie stark differenziert diese Fähigkeit Ihr Unternehmen vom Wettbewerb?

• 5 — Kerndifferenzierung: Das macht Ihr Unternehmen einzigartig. Ihre Empfehlungs-Engine, Ihr proprietäres Risikomodell, Ihre Customer Experience.
• 3 — Wichtig, aber nicht einzigartig: Wichtig für den Betrieb, aber nicht das, wofür Kunden Sie wählen. CRM, HR-Systeme, Projektmanagement.
• 1 — Commodity: Jedes Unternehmen braucht es, keines differenziert sich damit. E-Mail, Dateispeicherung, Buchhaltung.

Leitlinie: Entwickeln Sie Differenzierungsmerkmale. Kaufen Sie Commodities. Der Bereich dazwischen ist, wo die Entscheidung interessant wird.

Kriterium 2: Team-Fähigkeit

Bewertung 1-5: Verfügt Ihr Team über die Expertise, dies zu entwickeln und zu betreiben?

• 5 — Tiefe Expertise: Ihr Team hat ähnliche Systeme zuvor gebaut und verfügt über den vollständigen Skill-Stack
• 3 — Teilweise Expertise: Ihr Team kann es entwickeln, müsste aber erheblich rekrutieren oder lernen
• 1 — Keine Expertise: Dies liegt komplett außerhalb der Domäne Ihres Teams

Leitlinie: Die Entwicklung mit einem Team ohne Expertise erzeugt ein System, das niemand warten kann, nachdem die ursprünglichen Entwickler das Unternehmen verlassen.

Kriterium 3: Time-to-Value

Bewertung 1-5: Wie dringend benötigen Sie die Fähigkeit?

• 5 — Keine Dringlichkeit: 12+ Monate sind akzeptabel
• 3 — Moderat: 3-6 Monate ist der Zielzeitraum
• 1 — Dringend: Benötigt innerhalb von Wochen

Leitlinie: Eigenentwicklung dauert am längsten. Kaufen ist schneller, aber die Implementierung dauert trotzdem Monate. Partnerschaft kann am schnellsten sein, wenn der Partner bewährte Beschleuniger hat.

Kriterium 4: Anforderungspassung

Bewertung 1-5: Wie gut passen verfügbare Produkte zu Ihren Anforderungen?

• 5 — Kein Produkt existiert: Ihre Anforderungen sind wirklich einzigartig
• 3 — Teilweise Passung: Produkte erfüllen 60-70 % der Anforderungen
• 1 — Perfekte Passung: Ein Produkt erfüllt 90 %+ der Anforderungen out-of-the-box

Leitlinie: Wenn ein Produkt 90 % abdeckt, sind die verbleibenden 10 % fast nie den Bau einer Individuallösung wert.

Kriterium 5: Gesamtbetriebskosten (5 Jahre)

Berechnen Sie die TCO für jede Option über 5 Jahre:

TCO Eigenentwicklung:

• Entwicklungskosten (Team × Monate × Vollkostensatz)
• Infrastrukturkosten (Cloud, Datenbanken, Monitoring)
• Wartung (typischerweise 20 % der initialen Entwicklungskosten pro Jahr)
• Akkumulation technischer Schulden
• Opportunitätskosten (was hätte das Team sonst entwickeln können?)

TCO Kauf:

• Lizenzkosten (Jahr 1 + jährliche Erhöhung von 5-8 %)
• Implementierungskosten (typischerweise das 2- bis 5-Fache der Lizenzkosten in Jahr 1)
• Integrationskosten
• Schulung und Change Management
• Laufende Anpassung und Supportverträge

TCO Partnerschaft:

• Engagement-Kosten (Festpreis oder Time-and-Materials)
• Investition in Wissenstransfer
• Laufender Supportvertrag
• Interner Team-Aufbau bis zur Eigenständigkeit

Die Entscheidungsmatrix

Kriterium	Gewichtung	Eigenentwicklung	Kauf	Partnerschaft
Strategische Differenzierung	30 %
Team-Fähigkeit	20 %
Time-to-Value	20 %
Anforderungspassung	15 %
5-Jahres-TCO	15 %
Gewichtete Gesamtsumme	100 %

Bewerten Sie jede Option 1-5 pro Kriterium. Multiplizieren Sie mit der Gewichtung. Die höchste gewichtete Gesamtsumme gewinnt.

Entscheidungsfluss

Loading diagram...

Wann welche Option gewinnt

Eigenentwicklung gewinnt, wenn:

• Die Fähigkeit ein Kerndifferenzierungsmerkmal ist (Bewertung 4-5)
• Ihr Team über tiefe Expertise verfügt (Bewertung 4-5)
• Kein Produkt mehr als 60 % der Anforderungen erfüllt
• Sie sich 6-12 Monate Entwicklungszeit leisten können
• Sie bereit sind, in langfristige Wartung zu investieren

Praxisszenario: Ein Logistikunternehmen, das eine proprietäre Routenoptimierungs-Engine entwickelt, die seine einzigartigen Flotteneinschränkungen und Kunden-SLAs berücksichtigt. Kein Standardprodukt deckt ihre spezifischen Anforderungen ab.

Kauf gewinnt, wenn:

• Die Fähigkeit kein Differenzierungsmerkmal ist (Bewertung 1-2)
• Reife Produkte mit 80 %+ Anforderungspassung existieren
• Sie die Fähigkeit innerhalb von 3 Monaten benötigen
• Das Anbieter-Ökosystem zertifizierte Implementierungspartner bietet
• Ihr Team den Engineering-Aufwand anderweitig einsetzen möchte

Praxisszenario: Ein Unternehmen, das ServiceNow für IT-Service-Management einführt. ITSM ist wichtig, aber kein Differenzierungsmerkmal. ServiceNow deckt 90 % der Anforderungen ab. Eine eigene ITSM-Plattform zu entwickeln, würde 18 Monate dauern und ein unterlegenes Produkt liefern.

Partnerschaft gewinnt, wenn:

• Sie die Fähigkeit dringend benötigen, aber Ihrem Team die Expertise fehlt
• Der Umfang klar definiert ist mit einem eindeutigen Zielzustand
• Sie durch Wissenstransfer interne Fähigkeiten aufbauen möchten
• Das Engagement einen Ansatz validiert, bevor Sie sich langfristig zur Eigenentwicklung verpflichten
• Regulatorische Anforderungen Spezialexpertise erfordern (Sicherheit, Compliance)

Praxisszenario: Ein Unternehmen beauftragt eine Beratung mit Design und Implementierung seiner Azure Landing Zone. Dem Team fehlt Cloud-Architektur-Expertise, der Umfang ist klar definiert (4-8 Wochen), und das Ergebnis ist eine produktionsreife Plattform mit Dokumentation, die das interne Team betreiben kann.

Häufige Fehler

Fehler 1: Nicht-differenzierende Fähigkeiten selbst entwickeln

Engineering-Teams lieben es zu entwickeln. Ein eigenes Authentifizierungssystem, eine maßgeschneiderte Monitoring-Plattform oder eine proprietäre CI/CD-Pipeline zu entwickeln, ist selten gerechtfertigt, wenn reife Produkte existieren.

Fehler 2: Kaufen und dann bis zur Unkenntlichkeit anpassen

Wenn Sie ein Produkt um mehr als 30 % anpassen müssen, kaufen Sie nicht — Sie entwickeln auf einem feindlichen Fundament. Der Upgrade-Pfad des Produkts wird mit Ihren Anpassungen kollidieren.

Fehler 3: Partnerschaft ohne Wissenstransfer

Wenn der Partner geht und Ihr Team die Lösung nicht betreiben kann, haben Sie keine Partnerschaft geschlossen — Sie haben mit einer Abhängigkeit ausgelagert. Bestehen Sie auf Dokumentation, Pair Programming und operativer Übergabe.

Fehler 4: Laufende Kosten ignorieren

Befürworter der Eigenentwicklung unterschätzen die Wartung. Kaufbefürworter unterschätzen Lizenzerhöhungen. Partnerschaftsbefürworter unterschätzen die Kosten für den internen Kompetenzaufbau nach dem Engagement.

Übersicht häufiger Fehler

Loading diagram...

Die Entscheidung überprüfen

Die Build-vs.-Buy-vs.-Partner-Entscheidung ist nicht permanent. Überprüfen Sie sie, wenn:

• Sich Geschäftsanforderungen wesentlich ändern
• Sich die Team-Fähigkeit ändert (neue Mitarbeiter, Abgänge)
• Sich Marktbedingungen ändern (neue Produkte, Anbieterakquisitionen)
• Der Wartungsaufwand der aktuellen Lösung untragbar wird

Was vor zwei Jahren die richtige Entscheidung war, muss heute nicht die richtige Entscheidung sein. Das Framework hilft Ihnen, systematisch statt emotional neu zu bewerten.

---

Stehen Sie vor einer Build-vs.-Buy-Entscheidung für eine kritische Fähigkeit? Kontaktieren Sie uns — wir helfen Unternehmen, Technologie-Sourcing-Entscheidungen auf Basis von Fakten zu treffen, nicht auf Basis von Annahmen.