Build vs. Buy: Selbst entwickeln oder kaufen?

ERKLÄRUNG

Einfach erklärt

Build vs. Buy ist die Frage: Entwickeln wir eine Lösung selbst, oder kaufen wir eine fertige? Beide Wege haben Vor- und Nachteile.

Die Entscheidungsmatrix:

                    Differenzierung
                    Hoch          Niedrig
                ┌─────────────┬─────────────┐
Komplexität     │             │             │
    Hoch        │   BUILD     │   BUY       │
                │   (Kern)    │   (Partner) │
                ├─────────────┼─────────────┤
    Niedrig     │   BUILD     │   BUY       │
                │   (schnell) │   (SaaS)    │
                └─────────────┴─────────────┘

Vergleich:

Aspekt	Build	Buy
Time-to-Market	Monate-Jahre	Tage-Wochen
Kosten (initial)	Hoch	Niedrig-Mittel
Kosten (laufend)	Team, Wartung	Lizenzgebühren
Kontrolle	Voll	Begrenzt
Flexibilität	Unbegrenzt	Abhängig vom Anbieter
Risiko	Technisch	Vendor Lock-in

Technischer Deep Dive

Entscheidungskriterien

Build wenn:

✓ Kernkompetenz / Differenzierung
✓ Keine passende Lösung am Markt
✓ Spezielle Compliance-Anforderungen
✓ Langfristige strategische Bedeutung
✓ Internes Team vorhanden
✓ Zeit ist nicht kritisch

Buy wenn:

✓ Commodity (nicht differenzierend)
✓ Schneller Start wichtig
✓ Bewährte Lösung besser als Eigenentwicklung
✓ Kein internes Team
✓ Fokus auf Kerngeschäft
✓ Skalierung durch Anbieter

TCO-Vergleich (Beispiel ML-Plattform)

BUILD (3 Jahre):
─────────────────
Entwicklung:        €500.000
Team (3 ML Eng.):   €900.000
Infrastruktur:      €200.000
Wartung:            €150.000
─────────────────────────────
Gesamt:             €1.750.000

BUY (SageMaker, 3 Jahre):
─────────────────
Lizenz/Usage:       €300.000/Jahr = €900.000
Integration:        €100.000
Training:           €50.000
─────────────────────────────
Gesamt:             €1.050.000

→ Buy ist günstiger, ABER:
  - Weniger Kontrolle
  - Vendor Lock-in
  - Nicht differenzierend

Hybrid-Ansatz

Strategie: Buy the Commodity, Build the Differentiator

Beispiel E-Commerce:
├── BUY: Payment (Stripe)
├── BUY: E-Mail (SendGrid)
├── BUY: Analytics (GA4)
├── BUY: CRM (HubSpot)
└── BUILD: Recommendation Engine (Differenzierung!)

Open Source als Mittelweg

Aspekt	Proprietär (Buy)	Open Source	Eigenentwicklung (Build)
Lizenzkosten	Hoch	Keine	Keine
Implementierung	Gering	Mittel	Hoch
Wartung	Anbieter	Selbst	Selbst
Kontrolle	Niedrig	Hoch	Voll
Support	Inkludiert	Community/Paid	Selbst

Checkliste für die Entscheidung

## Strategische Fragen
- [ ] Ist es Kernkompetenz?
- [ ] Differenziert es uns vom Wettbewerb?
- [ ] Gibt es eine passende Lösung am Markt?
- [ ] Wie kritisch ist Time-to-Market?

## Ressourcen
- [ ] Haben wir das Team?
- [ ] Haben wir das Budget?
- [ ] Können wir langfristig warten?

## Risiken
- [ ] Vendor Lock-in akzeptabel?
- [ ] Compliance-Anforderungen erfüllt?
- [ ] Exit-Strategie vorhanden?

ANALOGIE

Build vs. Buy ist wie Kochen vs. Restaurant: Selbst kochen gibt dir volle Kontrolle über Zutaten und Geschmack, kostet aber Zeit. Das Restaurant ist schneller, aber du bekommst was auf der Karte steht.

WICHTIGSTE PUNKTE

Build: Volle Kontrolle, aber hohe Kosten und Zeit

Buy: Schneller Start, aber Abhängigkeit und weniger Flexibilität

Entscheidung hängt von Kernkompetenz und Differenzierung ab

ANWENDUNGSFÄLLE

ML-Plattform

Eigene MLOps-Plattform vs. SageMaker/Vertex AI

Chatbot

Eigenes LLM fine-tunen vs. ChatGPT API

CRM

Eigene Lösung vs. Salesforce

Daten

Eigenes Data Warehouse vs. Snowflake

HÄUFIGE FRAGEN

Wann sollte ich selbst bauen?

Wenn es Kernkompetenz ist, dich differenziert, oder keine passende Lösung existiert. Auch wenn Datenschutz/Compliance externe Lösungen ausschließt.

Wann sollte ich kaufen?

Wenn es Commodity ist (CRM, E-Mail), du schnell starten musst, oder das interne Team fehlt. Auch wenn die Lösung besser ist als du selbst bauen könntest.

Was ist mit Open Source?

Mittelweg: Keine Lizenzkosten, aber Implementierung und Wartung selbst. Oft guter Kompromiss, aber unterschätze den Aufwand nicht.

VERWANDTE BEGRIFFE

Business DevOps

Vendor Lock-in

Die Abhängigkeit von einem Anbieter, die einen Wechsel schwierig oder teuer macht – ein Risiko bei Cloud, SaaS und proprietären Technologien.

Business Digital

TCO (Total Cost of Ownership)

Die Gesamtkosten einer Lösung über ihren gesamten Lebenszyklus – nicht nur Anschaffung, sondern auch Betrieb, Wartung, Schulung und Ablösung.

Digital Praxis

Digital

Ein systematischer Plan, wie ein Unternehmen Künstliche Intelligenz einsetzen will – von der Identifizierung geeigneter Use Cases über den Aufbau von Kompetenzen bis zur Skalierung in Produktion.

DevOps Digital

SaaS, PaaS und IaaS

Die drei grundlegenden Cloud-Servicemodelle: Software as a Service (fertige Anwendungen), Platform as a Service (Entwicklungsplattform) und Infrastructure as a Service (virtuelle Infrastruktur).