Publiziert:

Make or Buy

Make or Buy: bauen, was differenziert, kaufen, was der Markt löst

Standardware (Commodity) kaufen, nur das selbst bauen, was differenziert, und jede Abhängigkeit bewusst eingehen, mit einem kalkulierten Ausstiegspfad.

Der erste Reflex lautet meist: "Wir kaufen alles und konzentrieren uns auf unser Geschäft." Das ist die falsche Frage. Make or Buy, also die Wahl zwischen Eigenentwicklung (Make) und Zukauf (Buy), ist keine reine Kostenentscheidung. Sie ist eine Frage von Differenzierung, Lebenszyklus-Kosten und Souveränität. Wer alles kauft, was die Konkurrenz auch kauft, kann nicht besser sein als die Konkurrenz. Wer alles selbst baut, verbrennt Budget an Problemen, die der Markt längst besser gelöst hat. Diese Seite gibt kein Glaubensbekenntnis, sondern eine Methode für den konkreten Fall.

Vier Kriterien treiben die Entscheidung

Nicht der Lizenzpreis entscheidet, sondern vier Kriterien, in dieser Reihenfolge:

  • Differenzierungswert: Ist der Prozess ein echter Wettbewerbsvorteil, einzigartig oder geheim? Nur dann lohnt Eigenentwicklung. Alles andere ist Standardware.
  • Marktverfügbarkeit: Gibt es mindestens drei gute Anbieter für das Problem? Ein funktionierender Markt heisst: kaufen, nicht bauen. Die Zwischenform zwischen Kaufen und Selbstbetreiben behandelt das Thema Managed Services.
  • Interne Kompetenz über 10 Jahre: Ist das Team vorhanden, um die Lösung über den gesamten Lebenszyklus zu pflegen, abzusichern und weiterzuentwickeln, nicht nur sie einmal zu bauen?
  • Markteinführungszeit (Time-to-Market): Muss das System in vier Wochen live sein? Dann scheidet Eigenentwicklung faktisch aus, egal wie differenzierend das Thema ist.

Diese vier Kriterien sind die Wirbelsäule der Entscheidung. Alles Weitere (Lebenszyklus-Kosten, Vendor Lock-in, Souveränität) präzisiert sie, ersetzt sie aber nicht.

Die Wardley-Logik: Genesis, Product, Commodity

Hinter Kriterium 1 steht die Evolutions-Logik von Simon Wardley. Jede Fähigkeit wandert über die Zeit durch drei Stadien, und das Stadium bestimmt, ob Eigenentwicklung, Zukauf oder eine reine Utility richtig ist:

  1. Genesis (Make): Neuartige, hochspezialisierte Lösungen für Probleme, für die es am Markt noch nichts gibt. Hier liegt die Innovation, und nur hier rechtfertigt sich Eigenentwicklung.
  2. Product (Buy / SaaS): Etablierte Produkte für bekannte Probleme. Der Fokus verschiebt sich von Code auf Integration und Konfiguration.
  3. Commodity / Utility: Standard-Dienste wie Strom oder Cloud-Infrastruktur, die einfach bezogen werden. Eigenbau verschwendet hier Ressourcen.

Der Fehler ist fast immer derselbe: Man behandelt eine Standardware wie Genesis (Eigenbau eines CRM) oder einen differenzierenden Kernprozess wie eine Standardware (Standard-Maske für das einzigartige Geschäftsmodell). Wardley macht sichtbar, in welchem Stadium ein Prozess wirklich steckt.

Der Entscheidungsfluss

Der folgende Entscheidungsbaum macht die vier Kriterien anwendbar. Der konkrete Prozess wird von oben nach unten hindurchgeführt und landet bei einem von drei Urteilen: Buy, Make oder Buy mit Ausstiegspfad. Entscheidend ist die zweite Verzweigung. Differenzierung allein begründet kein Make, wenn die Kompetenz für zehn Jahre Pflege fehlt.

flowchart TD
    A["Prozess bewerten"] --> B{"Differenzierender<br/>Kernprozess?"}
    B -->|"Nein, Standardware"| D["Buy:<br/>Standard / SaaS"]
    B -->|"Ja"| C{"Kompetenz für<br/>10 Jahre Pflege?"}
    C -->|"Ja"| E["Make: Eigenentwicklung"]
    C -->|"Nein"| F["Buy mit<br/>Ausstiegspfad"]
    D --> G["Lebenszyklus-<br/>Kosten rechnen"]
    E --> G
    F --> G

Gesamtkosten über den Lebenszyklus

"Make" sieht am Tag des Kaufs günstig aus, denn es gibt keine Lizenzrechnung. Der Trugschluss liegt im Zeithorizont. Eigenentwicklung lässt sich nur fair kalkulieren, wenn die Lebenszyklus-Kosten über fünf bis zehn Jahre angesetzt werden, nicht der Initialaufwand. Zu den Initialkosten kommen:

  • Wartung und Weiterentwicklung. Code altert, Anforderungen ändern sich.
  • Sicherheits-Patches. Jede selbst gebaute Komponente ist ein Posten, der dauerhaft abgesichert werden muss.
  • Personal und Wissen. Die Lösung steht und fällt mit Leuten, die sie über Jahre tragen. Fluktuation ist ein realer Kostenfaktor.
  • Plattform und Betrieb. Hosting, Updates der Abhängigkeiten, Compliance.

Die ehrliche Gegenrechnung lautet also nicht "Entwicklungskosten gegen Lizenzpreis", sondern kumulierter Aufwand für Make über fünf bis zehn Jahre gegen kumulierte Abo- und Wechselkosten für Buy. Die Detail-Kategorien und eine durchgerechnete Lebenszyklus-Betrachtung liefert das Thema Gesamtbetriebskosten (TCO). Die technische Sicht der Buy-Seite vertieft Standardsoftware.

Vendor Lock-in und der bewusste Ausstieg

Buy kauft still eine Abhängigkeit mit. Das ist kein Argument gegen Buy, aber gegen unbewusstes Buy. Anbieter können Vertragsbedingungen einseitig anpassen, Preise erhöhen oder den Zugriff auf die eigenen Daten an fremdes Recht binden. Vendor Lock-in ist legitim, solange er bewusst eingegangen wird und einen kalkulierten Ausstiegspfad hat:

  • Welche Daten- und Schnittstellen-Standards sichern den Wechsel?
  • Was kostet der Ausstieg konkret, in Geld, Zeit und Risiko?
  • Gibt es einen geprüften Migrationspfad oder nur die Hoffnung darauf?

Genau diese Fragen unterscheiden eine souveräne Buy-Entscheidung von einer Falle. Der bewusste Ausstieg ist Teil der Entscheidung, nicht ein späteres Problem. Mehr dazu im Thema Vendor Lock-in.

Zur bewussten Buy-Entscheidung gehört auch eine nüchterne Prüfung des Anbieters selbst, bevor die Abhängigkeit eingegangen wird: technologische Reife, finanzielle Stabilität und die Einhaltung der lokalen Compliance. Ein Anbieter, der heute funktioniert, aber finanziell wackelt, verschiebt das Risiko nur nach hinten.

Drei klare Fälle: Buy, Make, gefährliche Mitte

  • Buy gewinnt, die Standardware: Bekanntes Problem, funktionierender Markt, kein Differenzierungswert. CRM, HR, Mail, Office. Hier ist Eigenbau Ressourcenverschwendung. Wer Standardware wie CRM oder ERP trotzdem sauber und herstellerneutral auswählen will, folgt der Methode der unabhängigen Technologieauswahl und findet die angewandte Form als Dienstleistung: Unabhängige Software-Auswahl.
  • Make gewinnt, der Differenzierer: Ein einzigartiger Kernprozess, der vom Wettbewerb abhebt, und die Kompetenz, ihn über zehn Jahre zu pflegen. Nur wenn beides zutrifft.
  • Die gefährliche Mitte, die angepasste Standardsoftware: Standard-Software wird gekauft und so stark angepasst, bis sie "perfekt passt". Das ist der riskanteste Weg. Die Update-Fähigkeit des Standards geht verloren, die Wartungskosten von Individualcode bleiben trotzdem. Beide Rechnungen fallen an, die Vorteile keiner Seite. Diese Mitte ist der häufigste reale Fehlschlag. Sie gehört als Falle benannt, bevor man hineinläuft.

Souveränität als Entscheidungskriterium

Make or Buy ist für eine Organisation mehr als eine wirtschaftliche Entscheidung: Wer eine Lösung einkauft, entscheidet zugleich, wer am Ende die Kontrolle über die eigenen Daten hat. Genau hier wird die digitale Souveränität zu einem Kriterium der Wahl. In der Schweiz ist "Buy" oft gleichbedeutend mit "US-SaaS", und das revidierte Datenschutzgesetz (revDSG), die DSGVO und der US-Cloud Act verschieben die Make-or-Buy-Frage damit in den Bereich der Souveränität. Wer bei einem US-Hyperscaler kauft, bindet seine Daten potenziell an fremdes Recht.

  • Die Konferenz der schweizerischen Datenschutzbeauftragten (Privatim) hat die Nutzung internationaler Cloud-Dienste für Behörden bei besonders schützenswerten Daten faktisch stark eingeschränkt. Zentrales Argument ist der Cloud Act, der US-Anbieter zur Datenherausgabe zwingen kann, selbst wenn die Server in der Schweiz stehen.
  • Die Digitale Gesellschaft fordert, die öffentliche Beschaffung konsequent nach Souveränitäts-Kriterien und dem Open-Source-Prinzip auszurichten, weg von der immer tieferen Integration ins Microsoft-365-Universum. Wie sich der Open-Source-Gedanke in der Beschaffung verankern lässt, behandelt Public Code und SBOM.
  • Mit dem European Sovereign Stack Standard (ES3), der auf dem EU Cloud Sovereignty Framework aufsetzt, wird Souveränität über neun Dimensionen messbar, ein Reifegradmodell, das sich sauber auf eine Entscheidungsmatrix abbilden lässt.

Das verschiebt das Kalkül: Eigenentwicklung, Eigenbetrieb oder ein EU-Hosting kann selbst der Differenzierer sein, nicht trotz, sondern wegen der Souveränität. Ehrlich bleiben gehört dazu. Eine Studie der Stadt Zürich und der Berner Fachhochschule kommt zum Schluss, dass die Open-Source-Alternative OpenDesk Microsoft 365 noch nicht vollständig ersetzt. Souveränität ist ein bewertbares Kriterium der Make-or-Buy-Entscheidung, kein Automatismus. Genau diese Abwägung prägt Make-or-Buy-Entscheide und Anbieter-Management. Vertiefung im Thema Digitale Souveränität.

Referenzen

Verwandte Themen