Make or Buy: Wann lohnt sich individuelle Software?

Wer als Softwareanbieter die Make-or-Buy-Frage beantwortet, ist befangen. Das weiß ich. Deshalb versuche ich hier das Gegenteil dessen zu tun, was die meisten Anbieter tun: ehrlich zu sein, wann Standardsoftware die bessere Wahl ist – und wann nicht.

Die Make-or-Buy-Entscheidung für Software ist eine der strategisch wichtigsten, die ein Unternehmen treffen kann. Sie beeinflusst Kosten, Agilität, Wettbewerbsposition und technische Schulden auf Jahre hinaus. Und sie wird in der Praxis häufig falsch gestellt.

Die falsche Frage, die fast alle stellen

Die häufig gestellte Frage lautet: "Kaufen oder entwickeln?" Das ist die falsche Framing. Die richtige Frage lautet: "Ist dieser Prozess generisch oder differenzierend?"

Generische Prozesse – also Prozesse, die in Ihrem Unternehmen genauso ablaufen wie in hundert anderen vergleichbaren Unternehmen – sind hervorragende Kandidaten für Standardsoftware. Buchhaltung, HR-Prozesse, CRM-Grundfunktionen, Standard-ERP-Module: Hier haben Standardanbieter über Jahrzehnte und Millionen von Kundenstunden investiert. Das können Sie nicht wiederholen und sollten es nicht versuchen.

Differenzierende Prozesse – also Prozesse, die Ihrem Unternehmen einen Wettbewerbsvorteil geben oder die so spezifisch sind, dass kein Standardprodukt sie abbilden kann – sind Kandidaten für individuelle Entwicklung. Hier ist die Logik umgekehrt: Wenn Sie sich einem Standardprodukt anpassen, passen Sie Ihren Wettbewerbsvorteil dem Marktdurchschnitt an.

Wann Standardsoftware die richtige Wahl ist

Standardsoftware ist die richtige Wahl, wenn:

• Der Prozess branchenstandard ist. Wenn Ihr Lohnbuchhaltungsprozess dem Ihrer 500 Mitbewerber gleicht, bringt eine Individualentwicklung keinen strategischen Vorteil.
• Die Anforderungen stabil sind. Wenn sich der Prozess in den nächsten fünf Jahren nicht wesentlich verändern wird, amortisiert sich der Aufwand für Individualsoftware schlechter.
• Die Nutzerzahl groß ist. Standardsoftware ist auf breite Nutzergruppen optimiert. Je mehr interne Nutzer mit ähnlichen Anforderungen, desto eher lohnt sich die Standardlösung.
• Kein differenzierendes Nutzungsmuster vorliegt. Wenn die Software "nur" effizienter arbeiten soll, aber nicht anders, reicht Standard oft.
• Knappe IT-Ressourcen vorhanden sind. Individualsoftware braucht dauerhaft technisches Ownership. Wer das nicht sicherstellen kann, erhöht sein Risiko erheblich.

Wann individuelle Entwicklung sinnvoll ist

Individuelle Software ist die bessere Wahl, wenn:

• Der Prozess ein Wettbewerbsvorteil ist. Wenn Ihre Produktionskonfiguration, Ihr Kundenservice-Workflow oder Ihr Qualitätssicherungssystem ein differenzierendes Merkmal darstellt, sollten Sie es nicht dem Marktstandard angleichen.
• Komplexe Integration in Bestandssysteme erforderlich ist. Wenn eine Standardlösung fünf proprietäre Schnittstellen zu Altsystemen braucht und die Anpassungskosten höher liegen als eine Neuentwicklung, kippt die Rechnung.
• Die Anforderungen sich schnell ändern. Bei dynamischen Märkten oder sich häufig ändernden regulatorischen Anforderungen ist die Flexibilität von Individualsoftware ein echter Vorteil. Roadmap-Abhängigkeit vom Anbieter kann teuer werden.
• Datensouveränität kritisch ist. In bestimmten Branchen (Verteidigung, kritische Infrastruktur, sensible Kundendaten) ist Kontrolle über den Code und die Hosting-Umgebung nicht verhandelbar.

Die versteckten Kosten beider Wege

Beide Optionen haben Kosten, die in Angeboten und Erstgesprächen systematisch unterrepräsentiert sind.

Versteckte Kosten bei Standardsoftware:

• Anpassungskosten (Customizing) können 50–200 % des Lizenzpreises erreichen.
• Migrations- und Upgrade-Kosten bei Hauptversionen: häufig erheblich und planungsunsicher.
• Schulungsaufwand und Produktivitätsverlust bei der Einführung: typisch 3–6 Monate bis zur vollen Produktivität.
• Abhängigkeit von Anbieter-Roadmap: Funktionen, die Sie brauchen, werden vielleicht nie gebaut.

Versteckte Kosten bei Individualsoftware:

• Technische Schulden, wenn kein konsequentes Refactoring und kein Code-Ownership etabliert wird.
• Know-how-Abfluss, wenn der Entwicklungspartner wechselt oder interne Entwickler das Unternehmen verlassen.
• Infrastrukturkosten (Hosting, Security, Monitoring), die häufig unterschätzt werden.
• Anforderungsänderungen: Wenn Anforderungen sich häufig ändern und das Projekt schlecht geführt wird, ist Scope Creep der größte Kostentreiber.

Fazit

Make or Buy ist keine Entweder-oder-Entscheidung. In den meisten Unternehmen ist die richtige Antwort ein hybrider Ansatz: Standardsoftware für generische Prozesse, individuelle Entwicklung für differenzierende Kernprozesse. Die Entscheidung sollte auf einer klaren Analyse basieren: Ist dieser Prozess generisch oder differenzierend? Wie dynamisch sind die Anforderungen? Welche Integrationsaufwände entstehen wirklich?

Wer diese Fragen ehrlich beantwortet – und nicht primär nach dem, was Anbieter versprechen –, trifft meistens die richtige Wahl.