Letzte Woche sass ich mit einem CIO zusammen. Drittes ERP-Modul in vier Jahren. Erst selbst gebaut: Team konnte nicht liefern. Dann eingekauft: Vendor hat die Hälfte der Features nicht wie versprochen umgesetzt. Jetzt outsourced, und die Kosten laufen aus dem Ruder.

Sein Fazit: "Jede Option war falsch."

Mein Fazit: Die Optionen waren nicht das Problem. Der Entscheidungsprozess war es.

Warum alle drei Optionen scheitern (wenn der Prozess fehlt)

Die Entscheidung zwischen Build, Buy und Outsource folgt einem vorhersehbaren Muster.

Das Build-Szenario: Das Entwicklerteam ist begeistert. "Wir können das selbst, besser und günstiger." Sechs Monate später hat sich der Scope verdreifacht, das Budget ist aufgebraucht, und die Wartung frisst jede freie Kapazität.

Laut dem Exclaimer Report 2025 (über 2'000 IT-Entscheider befragt): 71% der internen IT-Builds werden am Ende aufgegeben. Nur 8% werden termingerecht fertig. Nur 11% bleiben im Budget.

Das Buy-Szenario: Die Demo war beeindruckend. Der Preis schien fair. Dann kommt die Integration, und plötzlich kostet das Projekt 150-200% mehr als die Lizenzgebühr. Schulungen, Customizing, Schnittstellen: der Sticker-Preis war nur 40-60% der tatsächlichen Kosten.

Das Outsource-Szenario: "Wir lagern das aus und sparen 30%." Klingt logisch. Aber versteckte Kosten fressen bis zu 20% des Outsourcing-Budgets. Scope Creep, Vertragsänderungen, Währungsschwankungen. Und die versprochene Flexibilität? Die gibt's nur, wenn du von Anfang an die richtigen Vertragsklauseln hast.

Abbildung: Die drei Optionen versprechen viel, aber jede hat ihren versteckten Preis

Das eigentliche Problem sitzt weiter vorne

Das Problem ist nicht Build vs Buy vs Outsource. Das Problem ist, wie die Entscheidung getroffen wird.

Fünf Muster erklären fast jede Fehlentscheidung:

1. Demo-getriebene Begeisterung. Jemand sieht eine beeindruckende Produktdemo. Das Team ist überzeugt. Der Kauf wird beschlossen, ohne die Integration, die Wartung oder die langfristigen Kosten zu modellieren. Zwölf Monate später ist die Realität eine andere.

2. Der Not-Invented-Here-Effekt. Das technische Team will alles selbst bauen. "Wir kennen unsere Anforderungen am besten." Stimmt oft. Aber es gibt ausgereifte Open-Source-Lösungen mit hunderten Contributors und Jahren Vorsprung.

3. Preis statt TCO. Die günstigste Option gewinnt. Aber die ersten 12 Monate lügen. Die wahren Kosten zeigen sich in Jahr 2-5: Wartung, Updates, Schulung, Integration, Exit. Forrester schätzt, dass 80% der Software-Gesamtkosten nach dem initialen Launch anfallen.

4. Keine Exit-Strategie. Du kaufst ein Tool, integrierst es tief in deine Prozesse, und hast keinen Plan für den Fall, dass der Vendor die Preise verdoppelt. 9.3% durchschnittliche SaaS-Preiserhöhung 2024 lassen grüssen.

5. Emotion schlägt Methodik. CEO hat auf einer Konferenz etwas gesehen. CTO will bauen. CFO will das Billigste. Keine strukturierte Evaluation, keine gewichteten Kriterien, kein gemeinsamer Entscheidungsrahmen.

Abbildung: Links der typische Entscheidungsweg, rechts der strukturierte Ansatz

Die Frage, die du stattdessen stellen solltest

Nicht: "Sollen wir bauen, kaufen oder auslagern?"

Sondern: "Was ist diese Fähigkeit strategisch wert, und welche Abhängigkeiten können wir uns leisten?"

Sechs Fragen verhindern den Grossteil der Fehlentscheidungen:

Ist das ein Wettbewerbsvorteil? Wenn ja: Build oder Operate (Open Source selbst betreiben). Wenn nein: Buy oder Outsource, ohne schlechtes Gewissen.

Haben wir die funktionale Expertise jetzt? Nicht technische Skills. Funktionales Fachwissen. Versteht jemand im Team das Problem gut genug, um eine Lösung zu spezifizieren?

Gibt es eine reife Open-Source-Alternative? Keycloak für Identity, PostgreSQL für Datenbanken, Kafka für Messaging. Diese Projekte haben Jahre Vorsprung. Selbst bauen ist hier Verschwendung.

Was ist der 5-Jahres-TCO, ehrlich gerechnet? Nicht der Lizenzpreis. Alles: Integration, Wartung, Schulung, Opportunity Cost, Exit.

Wie hoch ist das akzeptable Abhängigkeitsrisiko? Bei jedem Vendor entsteht Abhängigkeit. Die Frage ist nicht ob, sondern wie viel, und ob es eine Exit-Route gibt.

Wie dringend ist die Lösung wirklich? Buy braucht 2-8 Wochen für Integration. Build braucht 6-18 Monate. Manchmal ist Geschwindigkeit der entscheidende Faktor.

Abbildung: Die sechs Fragen als Entscheidungsrahmen

Der Elefant im Raum: KI verändert die Gleichung

Was die meisten Build-vs-Buy-Diskussionen ignorieren: KI verschiebt die Spielregeln auf beiden Seiten.

Build wird günstiger. KI-gestützte Entwicklung senkt die Kosten für Custom Software. Was vor zwei Jahren ein 12-Monats-Projekt war, kann heute in Wochen prototypisiert werden.

Aber Buy wird "klebriger". KI-Plattformen schaffen neues Lock-in. Wer seine Prozesse auf eine KI-Lösung trainiert, hat hohe Wechselkosten. Die nächste Generation Vendor-Abhängigkeit heisst AI Lock-in.

Laut Deloitte nutzen bereits 83% der Führungskräfte KI als Teil ihrer ausgelagerten Services. Gleichzeitig bleiben die konkreten Vorteile begrenzt, weil Governance und Vertragsgestaltung für KI-Requirements noch nicht reif sind.

Wer 2026 eine Sourcing-Entscheidung trifft, ohne den KI-Faktor einzubeziehen, arbeitet mit einer veralteten Karte.

Die ehrliche Frage

Du stehst vor einer Build-vs-Buy-vs-Outsource-Entscheidung? Beantworte eine Frage: Hast du die Entscheidung analysiert, oder hast du auf eine Demo, einen Preis oder ein Bauchgefühl reagiert?

Wenn es Letzteres ist, bist du in guter Gesellschaft. Aber auch in der Gesellschaft derer, die in zwei Jahren wieder wechseln.

Wir helfen Schweizer Unternehmen, diese Entscheidungen strukturiert und vendor-neutral zu treffen. Nicht weil wir bessere Antworten haben, sondern weil wir bessere Fragen stellen. Sourcing-Beratung →