Make or Buy in der IT: Wie CIOs in 2026 Entscheidungen treffen, die in 5 Jahren noch tragen
Make or Buy ist keine einmalige Frage, sondern ein Prozess. Wer 2026 entscheidet, muss in 2031 erklären können, warum. Ohne sauberes Solution Directory wird das zur Glaubensfrage.
Typischer Stack
Solution Directory
Single Source of Truth für alle eingesetzten Systeme
Capability Map
Welche Geschäftsfähigkeiten sind heute abgedeckt — und wie oft
Kostenstellen-Sicht
Wer zahlt für welches System und welche Abteilung nutzt es wirklich
Anforderungs-Backlog
Neue Bedarfe gegen Bestand prüfen, bevor RFPs starten
Die typischen Probleme
Doppelinvestition durch Schatten-IT
In jedem mittelständischen Unternehmen sind 25–40 % der Software-Ausgaben vermeidbar, weil Capabilities mehrfach lizenziert sind.
Buy-Entscheidung ohne Inventar
RFPs starten, bevor jemand geprüft hat, ob die Anforderung mit Boardmitteln abgedeckt ist. Ergebnis: ein weiteres Tool, das niemand integriert.
Make-Entscheidung ohne Wartungsplan
Eigenentwicklung wird gewählt, weil sie billiger wirkt — bis nach 18 Monaten der Entwickler kündigt und niemand das System versteht.
Reuse-Blindheit
Die mächtigste Make-or-Buy-Option ist 'reuse'. Sie wird übersehen, weil das Inventar fehlt.
Was es konkret kostet
Eine falsche Make-or-Buy-Entscheidung kostet im Schnitt das 3–5-fache des ursprünglichen Lizenzpreises über 5 Jahre — durch Migration, Schatten-Wartung und entgangene Skalierung.
Wie SolutionArc das löst
SolutionArc macht jedes System, jede Capability, jede Schnittstelle und jede Kostenstelle sichtbar. Bei einer neuen Anforderung sieht der Solution Architect in Sekunden: 'Das können wir heute mit Tool X erweitern' oder 'Hier müssen wir wirklich kaufen' — inklusive Begründung, die in fünf Jahren noch trägt.
Pilot werden →FAQ
Was ist die wichtigste Frage vor einer Make-or-Buy-Entscheidung?
Haben wir die Capability heute schon im Haus — und wenn ja, in welcher Tiefe? Diese Frage ist ohne Solution Directory nicht beantwortbar.
Wie messe ich, ob meine Make-or-Buy-Entscheidungen gut waren?
Über die Time-to-Value pro Anforderung und die Quote 'Anforderungen mit Bestand abgedeckt'. Beides liefert ein gepflegtes Directory automatisch.
Wann lohnt sich Eigenentwicklung wirklich?
Nur wenn die Capability differenzierend für das Geschäftsmodell ist und am Markt keine spezialisierte Lösung existiert. In allen anderen Fällen ist 'buy' günstiger.