Die Frage hinter der Frage
Wenn ein Unternehmen eine neue Fachanwendung braucht – etwa für Auftragssteuerung, Qualitätssicherung oder eine branchenspezifische Kalkulation – lautet die erste Frage selten: „Was kostet uns das wirklich?" Sie lautet meist: „Gibt es dafür schon etwas?" Das ist verständlich, aber riskant. Denn die eigentliche Entscheidung – kaufen oder selbst entwickeln lassen – verdient eine deutlich strukturiertere Betrachtung.
Total Cost of Ownership: Der Listenpreis lügt
Der häufigste Fehler bei Make-or-Buy-Entscheidungen ist ein unvollständiger Kostenvergleich. Standardsoftware wirkt auf den ersten Blick günstig. Die TCO-Analyse zeigt jedoch, dass der initiale Lizenzpreis oft nur 20–40 % der tatsächlichen Gesamtkosten über die Nutzungsdauer ausmacht.
Typische Kostenpositionen bei Standardsoftware:
- Lizenzgebühren (einmalig oder laufend, oft pro User)
- Implementierung und Konfiguration
- Schnittstellenentwicklung zu bestehenden Systemen
- Schulungsaufwand
- Anpassungen an eigene Prozesse (oder umgekehrt: Prozessumbau)
- Wartungs- und Supportverträge
- Update-Zwänge, die interne Ressourcen binden
Typische Kostenpositionen bei Eigenentwicklung:
- Analyse und Konzeption
- Entwicklung und Test
- Einführung und Schulung
- Laufende Weiterentwicklung und Wartung
Der entscheidende Unterschied: Bei Eigenentwicklung fallen keine laufenden Lizenzgebühren an, und Weiterentwicklungen folgen dem eigenen Roadmap-Takt. Der Break-even liegt je nach Nutzerzahl und Komplexität typischerweise zwischen drei und fünf Jahren.
Die Entscheidungsmatrix: Vier Dimensionen, die zählen
Eine belastbare Make-or-Buy-Entscheidung sollte mindestens vier Dimensionen systematisch bewerten:
1. Prozesseinzigartigkeit
Ist der abzubildende Prozess ein echter Wettbewerbsvorteil? Wenn ja, ist eine Standardlösung strukturell nachteilig – sie zwingt zur Angleichung an den Marktstandard. Eigenentwicklung schützt das Differenzierungsmerkmal.
2. Anforderungsabdeckung durch Standardprodukte
Marktlösungen sollten mindestens 75–80 % der fachlichen Anforderungen ohne Anpassung abdecken. Liegt die Quote darunter, steigen Customizing-Kosten exponentiell – und die Lösung verliert langfristig an Wartbarkeit, weil individuelle Anpassungen bei jedem Versions-Update neu bewertet werden müssen.
3. Integrationstiefe
Je tiefer eine Anwendung in die bestehende Systemlandschaft eingebunden werden muss – etwa ERP, Produktionsdaten, CRM –, desto eher lohnt Eigenentwicklung. Schnittstellen zu Standardprodukten sind oft teuer, fragil und update-sensitiv.
4. Nutzungsdauer und Skalierung
Eine kurzfristig benötigte Lösung mit wenigen Nutzern und begrenzter Laufzeit spricht für den Kauf. Langfristige, unternehmensweit genutzte Fachanwendungen rechnen sich als Eigenentwicklung häufig bereits ab dem vierten Jahr.
Wann spricht alles für den Kauf?
Nicht jede Anforderung rechtfertigt eine Eigenentwicklung. Standardsoftware ist die richtige Wahl, wenn:
- der Prozess generisch ist und kein Alleinstellungsmerkmal darstellt,
- ein reifes Marktprodukt die Anforderungen zu über 80 % abdeckt,
- Geschwindigkeit entscheidend ist (Time-to-Market),
- interne IT-Ressourcen fehlen und kein geeigneter Partner kurzfristig verfügbar ist.
Praktisches Vorgehen: Erst analysieren, dann entscheiden
Eine gute Entscheidungsgrundlage entsteht in drei Schritten:
- Anforderungen vollständig dokumentieren – funktional und nicht-funktional, inklusive Schnittstellen und Compliance-Anforderungen.
- Marktrecherche mit Scoring – vorhandene Produkte gegen die Anforderungsliste bewerten, Abdeckungsgrad und Anpassungsaufwand schätzen.
- TCO-Vergleich über Laufzeit – beide Szenarien (Kauf und Entwicklung) über einen Zeithorizont von fünf bis sieben Jahren gegenüberstellen, inklusive versteckter Kosten.
Fazit
Make-or-Buy ist keine Glaubensfrage. Mit einer strukturierten Entscheidungsmatrix und einer ehrlichen TCO-Betrachtung lässt sich die Frage nüchtern beantworten – und in vielen Fällen zeigt sich, dass Individualsoftware über die Nutzungsdauer nicht nur günstiger, sondern auch strategisch überlegen ist.