Make-or-Buy bei Software: Wann selbst bauen, wann kaufen?

Kaum eine Frage spaltet Geschäftsleitungen so zuverlässig wie diese: Bauen wir die Software selbst oder kaufen wir sie ein? Die einen schwören auf den perfekten Fit einer Eigenentwicklung, die jeden Prozess genau so abbildet, wie er gelebt wird. Die anderen verweisen auf gescheiterte IT-Projekte, gesprengte Budgets und Systeme, die nach drei Jahren niemand mehr pflegen kann.

Beide haben recht, und genau das macht die Entscheidung so heikel. Sie hängt nicht von Vorlieben ab, sondern von der konkreten Situation. Dieser Artikel liefert einen Entscheidungsrahmen, mit dem ein Schweizer KMU die Frage rational beantwortet, statt sich vom Bauchgefühl oder vom letzten Verkaufsgespräch treiben zu lassen.

Die falsche und die richtige Frage

Die meisten stellen die Frage so: Was kann unser Prozess Besonderes, das keine Standardsoftware abbildet? Diese Frage führt fast immer zur Eigenentwicklung, weil jedes Unternehmen seine Abläufe für einzigartig hält. In Wahrheit sind die wenigsten Prozesse so speziell, wie sie sich anfühlen. Eine Rechnung bleibt eine Rechnung, ein Lead bleibt ein Lead.

Die bessere Frage lautet: Trägt dieser Prozess direkt zu dem bei, womit wir uns am Markt unterscheiden? Buchhaltung, Lohnabrechnung und E-Mail unterscheiden euch nicht von der Konkurrenz, egal wie gut ihr sie macht. Wer für solche Commodity-Aufgaben selbst baut, zahlt teures Lehrgeld für etwas, das es fertig und besser gibt.

Anders sieht es aus, wenn ein Prozess euer Geschäft ist. Ein spezialisierter Logistiker mit einer einzigartigen Tourenplanung, ein Handwerksbetrieb mit einer eigenen Kalkulationslogik, die kein Standardtool kennt: Hier kann massgeschneiderte Software ein echtes Asset sein, das den Wettbewerb auf Distanz hält.

Total Cost of Ownership: Der Vergleich, den niemand macht

Der grösste Fehler beim Make-or-Buy-Vergleich ist, nur die Anschaffung zu betrachten. Eine Lizenz für 200 Franken im Monat wirkt teurer als eine einmalige Eigenentwicklung für 30'000 Franken, bis man rechnet, was danach kommt.

Eigenentwickelte Software ist nie fertig. Sie braucht Wartung, wenn sich Betriebssysteme und Bibliotheken ändern. Sie braucht Sicherheitsupdates, sonst wird sie zum Einfallstor. Sie braucht Anpassungen, sobald sich Anforderungen verschieben, und das tun sie immer. Und sie braucht Menschen, die sie verstehen. Genau hier liegt das gefährlichste Risiko: Wenn das Wissen an einer einzigen Person hängt, die das System gebaut hat, wird ihr Weggang zum Notfall.

Standardsoftware verlagert all das auf den Anbieter. Updates, Sicherheit, neue Funktionen und Support sind im Abopreis enthalten. Über fünf Jahre gerechnet kippt der Vergleich häufig zugunsten des Kaufens, selbst wenn die laufenden Lizenzkosten zunächst abschrecken. Wer Make-or-Buy sauber vergleichen will, rechnet beide Optionen über mindestens fünf Jahre durch, inklusive aller versteckten Folgekosten.

Die fünf Fragen für die Entscheidung

In der Praxis lässt sich die Entscheidung auf fünf Fragen verdichten, die jedes KMU für die konkrete Software durchgehen sollte.

Erstens: Differenziert uns dieser Prozess? Wenn nein, kaufen. Zweitens: Gibt es eine Standardlösung, die achtzig Prozent unserer Anforderungen abdeckt? Wenn ja, kaufen und die restlichen zwanzig Prozent entweder anpassen oder den Prozess anpassen. Drittens: Haben wir die Kompetenz, eine Eigenentwicklung über Jahre zu warten, nicht nur zu bauen? Wenn nein, kaufen oder das Wartungsrisiko einpreisen. Viertens: Wie schnell brauchen wir eine Lösung? Kaufen ist in Tagen produktiv, Bauen dauert Monate. Fünftens: Wie stark werden sich unsere Anforderungen ändern? Bei hoher Veränderungsrate ist die Flexibilität eigener Software ein Argument, bei stabilen Anforderungen ist sie überflüssig.

Diese Fragen ersetzen kein Detailgespräch, aber sie verhindern die häufigsten Fehlentscheidungen. Die meisten KMU, die ehrlich durch diese Liste gehen, landen öfter beim Kaufen, als sie ursprünglich dachten.

Der dritte Weg: Hybrid

Die Make-or-Buy-Frage wird oft als Entweder-oder verkauft, ist es aber nicht. Für viele Schweizer KMU liegt die beste Antwort dazwischen. Eine bewährte Standardlösung bildet die Basis, und das wirklich Eigene wird über offene Schnittstellen ergänzt.

Das CRM kommt von der Stange, aber die Anbindung an das eigene Branchensystem und die spezielle Automatisierung baut man selbst dazu. Die Buchhaltung ist Standard, doch der Datenaustausch mit dem Lager läuft über einen eigenen kleinen Connector. So bekommt man die Stabilität, Sicherheit und Update-Fähigkeit gekaufter Software und ergänzt nur dort eigene Logik, wo sie echten Mehrwert bringt.

Dieser Ansatz hat einen weiteren Vorteil: Das Risiko bleibt überschaubar. Eine kleine Integration ist im Notfall ersetzbar oder neu zu bauen, ein komplettes Eigensystem nicht. Voraussetzung ist, dass die gewählte Standardsoftware offene Schnittstellen bietet, ein Kriterium, das bei der Auswahl oft unterschätzt wird, aber über die langfristige Flexibilität entscheidet.

Fazit für die Praxis

Make-or-Buy ist keine technische, sondern eine strategische Entscheidung. Sie beginnt mit der Frage, ob ein Prozess euch wirklich differenziert, und sie endet mit einer ehrlichen Rechnung über fünf Jahre Gesamtkosten. Für Commodity-Aufgaben gewinnt fast immer der Kauf. Für das, was euer Geschäft ausmacht, kann Eigenentwicklung ein Wettbewerbsvorteil sein, sofern ihr die Wartung über Jahre stemmen könnt.

Im Zweifel ist der Hybrid die klügste Wahl: kaufen, was es gut gibt, und nur das selbst bauen, was euch einzigartig macht. Wer so vorgeht, vermeidet sowohl die teure Bastellösung, die niemand mehr pflegt, als auch die Standardsoftware, die das eigene Geschäft in ein fremdes Korsett zwängt.