Bauen, Kaufen oder Kooperieren
Warum interne Eigenentwicklungen doppelt so oft scheitern – und wann man trotzdem selbst baut.
AI Strategie & Umsetzung · Experte · 7 Min. Lesezeit · 3 Quizfragen
Von Ronan Liedmeier, Fractional Head of Growth und Kursautor · Geprüft am 13. Oktober 2026
Was du lernen wirst
- Warum die 2:1-Kluft größer ist, als sie aussieht
- Was du bei „Kaufen“ tatsächlich aushandeln musst
- Das Build-Szenario, das wirklich standhält
Vorschau der Lektion
Das ist keine philosophische Debatte – das MIT liefert handfeste Basiswerte: Externe Partnerschaften mit spezialisierten Anbietern erreichten in rund 67 % der Fälle das vollständige Deployment. Interne Eigenentwicklungen („Build“) schafften es nur in etwa 33 % der Fälle. Das ist ein Unterschied von 2:1 – und er wird in den meisten „Wir haben doch eigene Engineers“-Diskussionen völlig ignoriert. Es gibt durchaus gute Gründe, trotzdem selbst zu bauen, aber der Korridor ist schmal: Der Workflow ist dein proprietärer Wettbewerbsvorteil (kein bloßer Standard), kein Anbieter bietet die nötige Tiefe, die Daten dürfen deine Infrastruktur rechtlich nicht verlassen und für das zweite Jahr ist ein namentlich benannter interner Owner fest budgetiert – nicht nur stillschweigend vorausgesetzt. Alles andere ist ein reines Prestigeprojekt. Die Schlagzeilen-Zahl – 67 % Deployment-Erfolg bei Anbietern gegenüber 33 % bei Eigenentwicklungen – untertreibt die wahre Kluft noch, weil sie nur misst, ob der Rollout überhaupt je erreicht wurde. Sie sagt nichts über die Wartungslast nach dem Go-Live aus, wo das Phänomen der „Verwaisten Systeme im 2. Jahr“ (eine Lösung, die zwar gut gestartet ist, aber keinen budgetierten Owner mehr hat) schleichend den Wert vernichtet. Das taucht in der anfänglichen Erfolgsstatistik nie auf. Die praktische Konsequenz für dich als Consultant: Wenn du „Build“ empfiehlst, behauptest du nicht nur, dass das Team das Ding ausrollen kann – du behauptest implizit auch, dass sich in 18 Monaten noch jemand darum kümmert. Wenn du diese Person im Angebot nicht namentlich benennen kannst, empfiehlst du etwas, das gegen die Faktenlage spricht – ganz egal, ob du es laut aussprichst oder nicht.
Wichtige Begriffe in diesem Modul
- Make-or-Buy bei KI
- Make-or-Buy bei KI ist die Entscheidung, ob du ein KI-Tool selbst entwickelst oder ein fertiges Produkt oder einen spezialisierten Anbieter bezahlst. Kaufen ist meist schneller und sicherer. Selbst bauen lohnt sich vor allem bei einem echten Wettbewerbsvorteil, den kein Anbieter abdeckt.
Häufig gestellte Fragen
- Für wen ist „Bauen, Kaufen oder Kooperieren“?
- Dieses Experte-Modul aus AI Strategie & Umsetzung ist für Operator, Gründerinnen und Gründer sowie Growth-Teams, die KI in echter Arbeit einsetzen und Urteilsvermögen auf Produktionsniveau wollen. Es dauert etwa 7 Minuten und endet mit einem Quiz aus 3 Fragen.
- Muss ich programmieren können?
- Nein. In diesem Modul geht es um Entscheidungen, Wirtschaftlichkeit und Umsetzungsplanung, Programmieren gehört nicht dazu.
- Was kommt vor und nach diesem Modul?
- Vor „Bauen, Kaufen oder Kooperieren“ solltest du „Auswahl von Anwendungsfällen: welche Workflows, welches Format“ machen (Modul 3 von AI Strategie & Umsetzung). Danach geht es weiter mit „Das Adoption-Playbook“.
Schalte diese Lektion und die gesamte Academy frei
- Monatlich€9.99 / month
- Jährlich€69.99 / year
- Lifetime€129.99 one time
Deine Lektion wird geladen…
Ähnliche Module
- PreviousAuswahl von Anwendungsfällen: welche Workflows, welches Format
Zwei Achsen, ein Bias zum Korrigieren und eine Form-Leiter – Schluss mit vagem „KI-Brainstorming“, her mit einer echten Methode.
- NextDas Adoption-Playbook
OpenAI × Anthropic – die ineinandergreifenden Belege der Frontier Labs.
- Gleiches ThemaDie Faktenlage: Warum die meisten KI-Initiativen scheitern
Die Misserfolgsquote liegt nicht an der Technologie. Jede größere Studie kommt zum selben Ergebnis: Organisationen, die nicht lernen.
- Gleiches ThemaWettbewerbsfähig im Zeitalter der KI
Das Framework von Iansiti & Lakhani – übersetzt auf den Maßstab deiner Kunden.