Make vs. Buy: Die teuerste Entscheidung, die niemand analysiert
"Wir brauchen eine individuelle Lösung" – dieser Satz hat schon viele Unternehmen Hunderttausende gekostet. Genauso wie: "Standardsoftware reicht völlig aus" – wenn sie es dann doch nicht tat.
Die Make-vs-Buy-Entscheidung gehört zu den folgenreichsten IT-Entscheidungen. Und zu den am schlechtesten analysierten.
Warum diese Entscheidung so oft schiefgeht
Die "Eigenentwicklung"-Falle
- Initiale Unterschätzung: "Das ist doch nur ein CRUD-System"
- Scope Creep: Jede Woche neue Anforderungen
- Wartungskosten ignoriert: Nach 3 Jahren kostet die Wartung mehr als der Neubau
- Abhängigkeit: Der eine Entwickler, der es versteht, kündigt
Die "Standardsoftware"-Falle
- Anpassungskosten: "Out of the box" heißt selten ohne Customizing
- Prozessanpassung: Am Ende passen Sie sich der Software an
- Vendor Lock-in: Wechsel wird mit jedem Jahr teurer
- Lizenzkosten-Explosion: Was günstig begann, wird teuer skaliert
Der Total Cost of Ownership (TCO) Vergleich
Die ehrliche Rechnung über 5 Jahre:
Eigenentwicklung TCO
Jahr 1: Entwicklung
├─ Anforderungsanalyse: 20.000€
├─ Design & Architektur: 15.000€
├─ Entwicklung: 80.000€
├─ Testing: 20.000€
├─ Deployment: 10.000€
└─ Summe Jahr 1: 145.000€
Jahr 2-5: Wartung & Weiterentwicklung
├─ Bugfixes (20% p.a.): 16.000€/Jahr
├─ Sicherheitsupdates: 8.000€/Jahr
├─ Feature-Erweiterungen: 25.000€/Jahr
├─ Infrastruktur: 6.000€/Jahr
└─ Summe pro Jahr: 55.000€
5-Jahres-TCO: 145.000€ + 4 × 55.000€ = 365.000€
Standardsoftware TCO
Jahr 1: Implementierung
├─ Lizenzkosten: 24.000€
├─ Implementierung/Customizing: 40.000€
├─ Datenmigration: 15.000€
├─ Schulung: 10.000€
└─ Summe Jahr 1: 89.000€
Jahr 2-5: Laufende Kosten
├─ Lizenzkosten: 24.000€/Jahr
├─ Support-Vertrag: 8.000€/Jahr
├─ Updates/Upgrades: 5.000€/Jahr
├─ Anpassungen: 10.000€/Jahr
└─ Summe pro Jahr: 47.000€
5-Jahres-TCO: 89.000€ + 4 × 47.000€ = 277.000€
Aber: Diese Zahlen sind Durchschnittswerte. Ihre Situation kann völlig anders aussehen.
Berechnen Sie Ihren TCO: Unser Make-vs-Buy Entscheidungstool berechnet die Kosten für Ihre spezifische Situation.
Die 7 Entscheidungskriterien
1. Strategische Differenzierung
Frage: Ist die Software ein Wettbewerbsvorteil?
| Situation | Empfehlung |
|---|---|
| Software ist Kernprodukt | Make |
| Software differenziert vom Wettbewerb | Make |
| Software ist Commodity | Buy |
| Software ist Support-Funktion | Buy |
Beispiele:
- Online-Shop für einen Händler → Buy
- Algorithmus für ein Fintech → Make
- CRM für einen Dienstleister → Buy
- Konfigurationstool für einen Maschinenbauer → Prüfen
2. Passgenauigkeit verfügbarer Lösungen
Frage: Wie gut passt Standardsoftware zu Ihren Anforderungen?
| Fit | Empfehlung |
|---|---|
| > 80% Abdeckung | Buy |
| 60-80% Abdeckung | Buy + Customizing |
| 40-60% Abdeckung | Genau prüfen |
| < 40% Abdeckung | Make |
Warnung: "Wir sind anders" ist der häufigste Irrtum. Prüfen Sie kritisch, ob Ihre Anforderungen wirklich so einzigartig sind.
3. Time-to-Market
Frage: Wie schnell muss die Lösung verfügbar sein?
| Zeitrahmen | Tendenz |
|---|---|
| < 3 Monate | Buy |
| 3-6 Monate | Buy oder Low-Code |
| 6-12 Monate | Make möglich |
| > 12 Monate | Make |
Eigenentwicklung dauert fast immer länger als geplant. Faktor 1,5-2x ist realistisch.
4. Änderungsfrequenz
Frage: Wie oft ändern sich die Anforderungen?
Hohe Änderungsfrequenz → Make
- Eigene Entwicklung ermöglicht schnelle Anpassungen
- Keine Abhängigkeit von Vendor-Roadmaps
- Kosten pro Änderung oft geringer
Niedrige Änderungsfrequenz → Buy
- Stabile Anforderungen = Standard reicht
- Updates kommen vom Anbieter
- Weniger eigener Aufwand
5. Verfügbare Ressourcen
Frage: Haben Sie die Kapazitäten für Eigenentwicklung?
| Ressource | Für Make benötigt |
|---|---|
| Entwickler | Senior-Level, langfristig |
| Product Owner | Vollzeit für Anforderungen |
| DevOps | Für Betrieb und Deployment |
| Budget | Für unvorhergesehene Aufwände |
Realität: Die meisten Mittelständler haben diese Ressourcen nicht intern. Externe Entwicklung ist möglich, aber teurer und risikoreicher.
6. Integrationskomplexität
Frage: Wie muss die Software mit bestehenden Systemen kommunizieren?
Viele Integrationen → Tendenz Make
- Volle Kontrolle über Schnittstellen
- Keine Einschränkungen durch Standard-APIs
- Aber: Jede Integration muss selbst gebaut werden
Wenige/Standard-Integrationen → Tendenz Buy
- Standardsoftware hat oft fertige Konnektoren
- Etablierte Schnittstellen zu gängigen Systemen
- Schnellere Implementierung
7. Regulatorische Anforderungen
Frage: Gibt es spezielle Compliance-Anforderungen?
| Anforderung | Auswirkung |
|---|---|
| Zertifizierungen (ISO, SOC2) | Buy oft einfacher |
| Branchenspezifische Standards | Spezialsoftware prüfen |
| Datenhaltung on-premise | Einschränkt Buy-Optionen |
| Auditierbarkeit | Beide möglich |
Die Entscheidungsmatrix
Bewerten Sie jedes Kriterium von 1-5:
| Kriterium | Make (5) | Neutral (3) | Buy (1) |
|---|---|---|---|
| Strategische Differenzierung | Kernkompetenz | Wichtig | Commodity |
| Passgenauigkeit Standard | < 50% | 60-80% | > 80% |
| Time-to-Market | > 12 Monate | 6-12 Monate | < 6 Monate |
| Änderungsfrequenz | Wöchentlich | Monatlich | Jährlich |
| Interne Ressourcen | Vorhanden | Teilweise | Keine |
| Integrationskomplexität | Hoch | Mittel | Gering |
| Regulatorik | Speziell | Normal | Standard |
Auswertung:
- Score > 28: Tendenz Make
- Score 18-28: Detaillierte Analyse nötig
- Score < 18: Tendenz Buy
Die Hybrid-Option: Best of Both Worlds
Oft ist die Antwort nicht Make ODER Buy, sondern Make UND Buy:
Composable Architecture
- Standardsoftware für Basisfunktionen
- Eigenentwicklung für Differenzierung
- APIs verbinden die Komponenten
Low-Code als Mittelweg
- Schneller als klassische Entwicklung
- Flexibler als Standardsoftware
- Aber: Eigene Limitierungen
Build-on-Top
- SaaS als Plattform nutzen
- Eigene Logik per API/Extensions
- Beispiel: Shopify + Custom Apps
Häufige Fehler vermeiden
Fehler 1: Nur Initialkosten vergleichen
Eigenentwicklung wirkt initial günstiger, aber Wartung kostet.
Fehler 2: Opportunity Costs ignorieren
Was könnten Ihre Entwickler stattdessen bauen?
Fehler 3: Vendor-Präsentation glauben
"Out of the box" heißt selten "ohne Aufwand".
Fehler 4: Exit-Kosten vergessen
Wie teuer ist der Wechsel in 5 Jahren?
Fehler 5: Nicht prototypen
Vor großen Investitionen: POC machen!
Ihre nächsten Schritte
- Make-vs-Buy Tool nutzen – Berechnen Sie TCO und Risiken
- Anforderungen priorisieren – Was ist wirklich differenzierend?
- Markt sondieren – Welche Standardlösungen existieren?
- POC planen – Testen Sie 2-3 Optionen
Prozesskosten verstehen: Bevor Sie eine Lösung wählen, verstehen Sie mit unserem Prozesskosten-Analyzer die wahren Kosten Ihrer aktuellen Situation.
Fazit: Analyse schlägt Bauchgefühl
Die Make-vs-Buy-Entscheidung ist zu wichtig für Bauchgefühl. Mit einer strukturierten Analyse der sieben Kriterien und einer ehrlichen TCO-Rechnung treffen Sie fundierte Entscheidungen.
Und manchmal ist die beste Entscheidung: Noch nicht entscheiden. Sondern erst den Prozess verstehen, dann die Anforderungen klären, und dann die Optionen bewerten.
Sie stehen vor einer komplexen Make-vs-Buy-Entscheidung? Unser AI Adoption Audit hilft Ihnen, die strategischen Implikationen zu verstehen und die richtige Wahl zu treffen.
