Make-or-Buy bei Fachanwendungen: Wie Sie die richtige Entscheidung treffen
Ob CRM, Auftragsmanagement, Qualitätssicherung oder branchenspezifische Planungstools – früher oder später steht jedes mittelständische Unternehmen vor der Frage: Kaufen wir eine fertige Lösung, oder entwickeln wir etwas Eigenes? Die Antwort hat erhebliche finanzielle und strategische Konsequenzen. Eine fundierte Entscheidung braucht deshalb mehr als ein Bauchgefühl.
Die Entscheidungsmatrix: Vier Fragen, die zählen
Eine bewährte Methode ist eine zweidimensionale Bewertung entlang zweier Achsen:
Achse 1 – Prozessspezifität: Wie stark weicht Ihr Prozess vom Marktstandard ab?
Achse 2 – Strategischer Wert: Ist dieser Prozess ein echter Wettbewerbsvorteil?
Daraus ergeben sich vier Felder:
| Niedriger strategischer Wert | Hoher strategischer Wert | |
|---|---|---|
| Standardprozess | Kauf – möglichst günstig | Kauf – aber mit Datenstrategie |
| Spezifischer Prozess | Prüfen – TCO entscheidet | Eigenentwicklung bevorzugt |
Ergänzend sollten Sie zwei weitere Fragen beantworten:
- Integrationsbedarf: Wie tief muss die Anwendung in bestehende Systeme (ERP, Datenbank, Maschinen) eingebunden werden?
- Veränderungsgeschwindigkeit: Wie oft ändern sich die fachlichen Anforderungen? Häufige Änderungen machen starre Standardlösungen teuer.
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 – bis man alle Kostenblöcke aufaddiert.
Kosten einer Standardlösung (Beispiel SaaS)
- Lizenz- oder Abogebühren (5–10 Jahre)
- Implementierungs- und Einführungsprojekt
- Customizing und Konfiguration
- Schulungsaufwand für Mitarbeitende
- Integrationskosten zu bestehenden Systemen
- Migrationskosten bei Anbieterwechsel (Vendor Lock-in)
- Preisanpassungen durch den Anbieter über die Zeit
Kosten einer Eigenentwicklung
- Initiale Entwicklungskosten
- Qualitätssicherung und Tests
- Betrieb und Hosting
- Weiterentwicklung und Wartung
- Internes oder externes Entwickler-Know-how
Der entscheidende Unterschied: Bei Eigenentwicklung sind die Kosten am Anfang hoch, danach aber gut planbar und kontrollierbar. Bei Standardsoftware verteilen sie sich über die Laufzeit – und können durch Anbieterpolitik steigen.
Wann Eigenentwicklung günstiger ist
Eigenentwicklung lohnt sich aus TCO-Perspektive typischerweise dann, wenn mehrere dieser Bedingungen zutreffen:
- Hoher Anpassungsgrad nötig: Wenn mehr als 30–40 % der Standardfunktionen durch Customizing verändert werden müssen, ist der Kaufvorteil weitgehend aufgebraucht.
- Tiefe Systemintegration erforderlich: Proprietäre Schnittstellen treiben Integrationskosten bei Fremdlösungen stark in die Höhe.
- Langfristige Nutzung geplant: Ab einem Zeithorizont von fünf bis sieben Jahren übersteigen kumulative Lizenzkosten häufig die Entwicklungsinvestition.
- Datensouveränität ist kritisch: Regulatorische oder strategische Anforderungen sprechen gegen externe Datenhaltung.
- Der Prozess ist Kern des Geschäftsmodells: Eine Standardlösung, die jeder Mitbewerber ebenso nutzt, kann keinen Differenzierungsvorteil liefern.
Hybridansatz: Nicht alles ist entweder-oder
In der Praxis ist die beste Lösung oft eine Kombination: Standardsoftware für Commodity-Prozesse (Buchhaltung, HR, E-Mail), Eigenentwicklung für die differenzierenden Kernprozesse. Entscheidend ist, dass Sie klar zwischen beiden Kategorien trennen – und die Eigenentwicklung konsequent dort einsetzen, wo sie echten Mehrwert schafft.
Fazit
Eine Make-or-Buy-Entscheidung ist keine IT-Frage, sondern eine strategische und betriebswirtschaftliche. Die Entscheidungsmatrix schafft Struktur, die TCO-Rechnung schafft Transparenz. Wer beide Werkzeuge konsequent einsetzt, vermeidet teure Fehlentscheidungen – in beide Richtungen.