Make or Buy bei Unternehmenssoftware: Ein Entscheidungsrahmen für CTOs

Die falsch gestellte Frage

Früher oder später findet in jedem Unternehmen dieselbe Sitzung statt: Bauen wir dieses System selbst, oder kaufen wir es? Die Debatte wird meist als Kostenvergleich inszeniert — ein Anbieterangebot gegen eine interne Schätzung — und meist auf Basis der falschen Zahlen entschieden. Kaufpreis und initiale Entwicklungskosten sind die beiden kleinsten Posten der Gleichung. Die eigentliche Entscheidung betrifft die Eigentumsfrage: Wer kontrolliert das Änderungstempo einer Fähigkeit, von der Ihr Geschäft abhängt, und was kostet diese Kontrolle über ein Jahrzehnt?

Dieser Beitrag zeigt, wie wir diese Analyse mit CTOs durchführen: Gesamtbetriebskosten ehrlich gerechnet, Integrationsschulden vor der Unterschrift eingepreist und ein Differenzierungstest, der zeigt, wo sich individuelle Entwicklung tatsächlich lohnt.

Gesamtbetriebskosten, ehrlich gerechnet

Beide Lager schönen ihre Zahlen. Interne Teams schätzen die Entwicklung und verschweigen die Jahre der Wartung; Anbieter nennen die Lizenz des ersten Jahres und verschweigen alles Weitere. Ein ehrliches TCO-Modell bepreist den vollständigen Lebenszyklus auf beiden Seiten:

• Eigenbau: die initiale Entwicklung plus 15–20 % der Entwicklungskosten pro Jahr für Wartung, Abhängigkeits-Updates und Sicherheitsarbeit — über die gesamte Lebensdauer des Systems
• Eigenbau: das Team. Ein System, das ein Projektteam baut und dann verwaist zurücklässt, verfällt schneller als jede gekaufte Lösung
• Kauf: Preise pro Arbeitsplatz, die mit Ihrer Belegschaft wachsen, nicht mit Ihrem Nutzen — rechnen Sie den Vertrag mit dem Dreifachen der heutigen Lizenzen durch
• Kauf: Customizing- und Beratungskosten, die bei großen Plattformen die Lizenz regelmäßig übersteigen
• Beides: Ausstiegskosten. Die Migration weg von einem System im fünften Jahr ist ein Projekt, das im ersten Jahr niemand budgetiert

Rechnen Sie das Modell über sieben bis zehn Jahre, nicht über drei. Die meisten gekauften Systeme wirken über drei Jahre günstig und über zehn Jahre teuer; bei Eigenbauten ist es tendenziell umgekehrt. Der gewählte Zeithorizont ist die Entscheidung.

Integrationsschulden: der versteckte Posten

Kein Unternehmenssystem läuft allein. Jeder Kauf fügt Ihrem Integrationsgraphen einen Knoten hinzu, und an den Kanten sterben die Budgets: Identität, Stammdaten, Reporting-Pipelines und die Punkt-zu-Punkt-Synchronisationen, die sich um jedes gekaufte Produkt ansammeln. Gekaufte Plattformen integrieren sich zu den Bedingungen des Anbieters — dessen API-Limits, dessen Update-Rhythmus, dessen Datenmodell. Jede zusätzliche Anpassung bewegt Sie in Richtung des Schlechtesten beider Welten: Wartungskosten wie beim Eigenbau, Kontrolle wie beim Kauf.

Bepreisen Sie die Integrationsarbeit explizit vor der Entscheidung, nicht danach. Kostet die Anbindung einer gekauften Plattform an Ihre Systemlandschaft mehr als die Hälfte des Eigenbaus, war die Kaufoption nie wirklich ein Kauf.

Der Differenzierungstest

Der stärkste Filter ist nicht finanzieller Natur. Fragen Sie, ob die Fähigkeit Sie im Markt differenziert. Commodity-Fähigkeiten — Gehaltsabrechnung, Ticketing, E-Mail, Spesenabrechnung — kauft man ohne Zeremonie; niemand wählt einen Lieferanten wegen seines Spesentools. Fähigkeiten, die in Ihrem Vertriebsargument, Ihren Margen oder Ihrer Kundenerfahrung auftauchen, verdienen individuelle Entwicklung — denn das Eigentum am Änderungstempo ist genau der Punkt.

• Kaufen, wo Gleichstand genügt — Gehaltsabrechnung, HR, Ticketing, Dokumentenmanagement
• Bauen, wo der Vorsprung entsteht — Preis-Engines, kundennahe Prozesse, der Ablauf, den nur Sie so betreiben
• Die Grauzone hinterfragen: Wer schwere Anpassungen in ein gekauftes Produkt schreibt, dem sagt der Markt, dass diese Fähigkeit zum Kern gehört

Hybride Strategien, die tragen

In der Praxis ist die reife Antwort selten rein. Die hybriden Muster, die wir erfolgreich sehen, teilen eine Eigenschaft: eine saubere Naht zwischen dem, was man besitzt, und dem, was man mietet.

• Die Engine kaufen, das Nutzererlebnis bauen — ein gekauftes führendes System hinter einer individuellen Oberfläche, die Teams und Kunden tatsächlich nutzen
• Den Kern bauen, die Ränder kaufen — individuelle Domänenlogik, umgeben von Standarddiensten für Identität, Messaging und Analytik
• Kapseln vor dem Ersetzen — eine eigene API-Schicht über einem Alt- oder Anbietersystem, damit es später ausgetauscht werden kann, ohne seine Konsumenten anzufassen

Das Muster, das scheitert, ist das tiefe Verbiegen einer Anbieterplattform, bis jedes Update zur Migration wird. Es verbindet das Kostenprofil des Eigenbaus mit den Beschränkungen des Kaufs.

Ein Rahmen für eine einzige Sitzung

Legen Sie vor der nächsten Make-or-Buy-Diskussion fünf Fragen auf den Tisch:

• Differenziert uns diese Fähigkeit, oder genügt Gleichstand mit allen anderen?
• Ändern sich unsere Anforderungen schneller als die Roadmap jedes Anbieters?
• Wie sehen die ehrlichen Gesamtkosten über zehn Jahre aus — Wartung, Lizenzen, Customizing, Integration, Ausstieg?
• Können wir ein Team für die Lebensdauer des Systems aufbauen und halten, nicht nur für die Entwicklung?
• Was kostet der Ausstieg — in Monat 36, auf beiden Wegen?

Lauten die Antworten differenzierend, schnelllebig und personell tragbar, spricht das für den Eigenbau. Gleichstand, stabile Anforderungen und dünne Integration sprechen für den Kauf. Alles dazwischen spricht für einen Hybrid mit bewusst gezogener Naht. Unternehmenssysteme sind ein Teil der Ingenieursarbeit von Vendenis — und ob die Analyse bauen ergibt oder kaufen und integrieren: Wir begleiten Organisationen auf beiden Wegen.