Build or Buy: Wann Software kaufen, wann selbst entwickeln lassen?
„Selber bauen“ ist selten die günstigste Option und „Kaufen“ selten die schnellste. Wie Unternehmen die Build-or-Buy-Frage entscheiden, ohne sie zu raten.
Die Build-or-Buy-Frage wird meistens falsch gestellt. Sie lautet nicht „bauen wir das selbst oder kaufen wir es", sondern „ist dieser Prozess der, mit dem wir uns vom Wettbewerb unterscheiden — oder nicht".
Wer das nicht zuerst klärt, baut Standardprozesse teuer nach oder kauft genau die Differenzierung weg, die das Geschäft tragen sollte.
Warum „selber bauen" selten am günstigsten ist
Eigenentwicklung fühlt sich nach Kontrolle an. Aber die Rechnung endet nicht beim Bau. Sie geht weiter mit Betrieb, Sicherheit, Updates, Wissen, das an Personen hängt, und jeder zukünftigen Änderung. Ein gekauftes Standardprodukt verteilt genau diese Kosten auf viele Kunden.
Der Accelerate State of DevOps Report 2024 von DORA zeigt indirekt, warum: Was zählt, ist nicht das einmalige Liefern, sondern wie billig und stabil die nächste Änderung ist. Selbstgebaute Standardteile sind dauerhaft teuer in genau dieser Achse.
Warum „kaufen" selten am schnellsten ist
Umgekehrt täuscht „Kaufen" Geschwindigkeit vor. Die Lizenz ist schnell. Aber die Anpassung an echte Prozesse, die Integration in bestehende Systeme und das Verbiegen der Organisation an die Software fressen die gesparte Zeit oft wieder auf — und hinterlassen Abhängigkeit.
Die einzige Frage, die wirklich zählt
Differenziert dieser Prozess uns im Markt?
- Ja → eher selbst bauen. Hier ist Standardsoftware ein Nachteil, weil sie alle gleich macht.
- Nein → eher kaufen. Hier ist Eigenbau ein Nachteil, weil er teures Geld in etwas steckt, das niemanden überzeugt.
Alles andere — Kosten, Zeit, Technologie — folgt aus dieser Antwort, nicht umgekehrt.
Vier Kriterien hinter der Entscheidung
1. Differenzierung
Macht dieser Prozess den Unterschied beim Kunden? Differenzierende Prozesse gehören selten in fremde Standardsoftware.
2. Abhängigkeit
Wie schwer kommt man wieder heraus? Ein gekauftes System mit eigenem Datenmodell und ohne Export ist eine strategische Fessel, kein Werkzeug.
3. Integrationsfähigkeit
Hat das Produkt eine echte API, oder endet die Verbindung beim Excel-Export? Was sich nicht sauber anbinden lässt, erzeugt genau die Insellösungen, die man ablösen wollte.
4. Gesamtkosten über die Zeit
Nicht Anschaffung gegen Projektpreis, sondern fünf Jahre Betrieb, Updates und Änderungen gegen fünf Jahre Lizenz, Anpassung und Abhängigkeit.
Der dritte, oft beste Weg
Die Entscheidung ist selten reines Entweder-oder. Häufig ist die beste Lösung: Standard kaufen für das Standardhafte, selbst bauen für das Differenzierende — und beides über eine saubere Schnittstelle verbinden (siehe API-Integration für Unternehmen). Genau die Frage, was Standard und was Eigenentwicklung ist, behandelt auch Custom oder Standard? im Detail.
Checkliste für die Build-or-Buy-Entscheidung
- Ist klar, ob dieser Prozess uns differenziert oder nicht?
- Würde Standardsoftware uns hier austauschbar machen?
- Wie hoch ist die Abhängigkeit vom Anbieter — und der Ausstieg?
- Hat das Kaufprodukt eine echte API, nicht nur Export?
- Rechnen wir Gesamtkosten über fünf Jahre, nicht nur Anschaffung?
- Ist die hybride Variante (kaufen + bauen + verbinden) geprüft?
- Bauen wir nur das Differenzierende selbst?
Häufige Fragen
Ist Eigenentwicklung nicht immer teurer? In der Anschaffung oft ja, über die Laufzeit nicht zwingend — vor allem nicht bei differenzierenden Prozessen, wo Standardsoftware einen Wettbewerbsnachteil erzeugt.
Spart Kaufen nicht immer Zeit? Nur scheinbar. Die Lizenz ist schnell, die Anpassung an reale Prozesse und die Integration nicht. Gespart wird Zeit nur dort, wo der Standard wirklich passt.
Was, wenn wir uns nicht sicher sind, ob es uns differenziert? Dann ist das die erste Frage, nicht eine technische. Ohne diese Klärung ist jede Build-or-Buy-Entscheidung geraten.
Geht auch beides? Meistens ja — und oft ist genau das die beste Wahl: Standard für das Übliche, Eigenbau für das Besondere, verbunden über eine API.
Fazit
Build or Buy ist keine Technik-, sondern eine Strategiefrage. Wer zuerst klärt, ob ein Prozess differenziert, entscheidet richtig: kaufen, wo man wie alle sein darf, selbst bauen, wo man anders sein muss — und beides sauber verbinden, statt es zu raten.
Weiterlesen
- Individuelle Softwareentwicklung: Custom oder Standard? — wann Eigenentwicklung den Unterschied macht.
- Was kostet individuelle Softwareentwicklung? — Gesamtkosten ehrlich gerechnet.
Nächster Schritt
Sie stehen vor einer Build-or-Buy-Entscheidung? Beginnen Sie mit einer kurzen Einschätzung Ihrer Anforderungen. Wir klären zuerst, was Sie differenziert — und entscheiden dann kaufen, bauen oder verbinden.
Quellen
- DORA, Accelerate State of DevOps Report 2024 — dora.dev
- Thoughtworks, Technology Radar — thoughtworks.com
- Atlassian, Agiles Projektmanagement — atlassian.com