KI selbst bauen oder kaufen? Make-or-Buy für KMU
KI-Software entwickeln lassen oder Standard kaufen? Die Make-or-Buy-Entscheidung für KMU: 5 Kriterien, ehrliche Risiken beider Wege, Entscheidungshilfe.
Es ist die strategischste Frage der ganzen KI-Diskussion, und sie wird am seltensten sauber gestellt: Standard-Software mieten oder eigene Systeme bauen lassen? Beide Lager predigen, beide haben Recht, jeweils für bestimmte Fälle. Hier der Entscheidungsrahmen, mit dem wir selbst arbeiten, inklusive der Argumente gegen unser eigenes Geschäftsmodell.
Vorab: Die Rechnung hat sich geändert
Die alte Make-or-Buy-Weisheit ("Eigenentwicklung nur für das Kerngeschäft, alles andere kaufen") stammt aus einer Zeit, in der individuelle Software 12 bis 18 Monate dauerte und sechsstellig kostete. KI-gestützte Entwicklung hat diese Rechnung gekippt: Was früher ein Konzernprojekt war, ist heute in Wochen baubar. Das verschiebt die Grenze, ab der sich Bauen lohnt, dramatisch nach unten. Es hebt sie aber nicht auf.
Wann Kaufen die richtige Antwort ist
Ehrlichkeit zuerst, hier sind die Fälle, in denen wir selbst zum Standard raten:
- Commodity-Funktionen. Buchhaltungssoftware fürs Finanzamt, Lohnverrechnung, Office, Videokonferenzen: ausgereifte Massenware, regulatorisch gepflegt, spottbillig pro Nutzer. Bauen wäre Unsinn.
- Du bist der Standardfall. Wenn Deine Prozesse tatsächlich dem Branchenstandard entsprechen und Du keinen Prozessvorteil gegenüber Wettbewerbern hast oder willst, ist Standardsoftware effizient.
- Werkzeuge der Ebene 1. Assistenz-Tools wie ChatGPT oder Copilot für einzelne Mitarbeiter: mieten, nutzen, fertig.
Wann Bauen gewinnt
- Der Prozess IST der Wettbewerbsvorteil. Wenn Du schneller lieferst, besser kalkulierst oder enger am Kunden bist als der Wettbewerb, dann steckt dieser Vorsprung in Deinen Prozessen. Standardsoftware normiert Prozesse, und damit normiert sie Deinen Vorsprung weg.
- Der Flickenteppich frisst Dich. Fünf Systeme, die nicht miteinander reden, plus Excel-Brücken dazwischen: Ab diesem Punkt ist ein integriertes eigenes System meist günstiger als die Summe der Mieten plus die manuellen Kosten der Lücken. Die Rechnung dazu steht im Beitrag Was kostet KI-Automatisierung?
- Lock-in ist ein reales Risiko geworden. Preiserhöhungen nach Übernahmen, abgekündigte Produkte, Funktionen hinter neuen Lizenzstufen: Wer die letzten Jahre Software eingekauft hat, kennt alle drei. Eigener Code ist gegen alle drei immun.
- Deine Daten sind sensibel. On-Premise-Pflichten, Geheimhaltungsvereinbarungen, Berufsgeheimnisse: Je strenger die Datenanforderungen, desto schneller scheidet Standard-SaaS aus.
Die fünf Prüffragen
Vor jeder Entscheidung, egal in welche Richtung:
- Differenziert mich dieser Prozess im Markt? Ja → bauen tendiert. Nein → kaufen tendiert.
- Wie viele Systeme ersetzt oder verbindet die Lösung? Eines → kaufen möglich. Drei und mehr → bauen rechnet sich fast immer.
- Was kostet der Status quo wirklich? Lizenz- plus Wartungs- plus manuelle Prozesskosten über fünf Jahre. Erst diese Zahl macht Angebote vergleichbar.
- Wem gehört am Ende was? Code, Daten, Wissensbasis. Schriftlich.
- Wer betreibt es in drei Jahren? Eigenentwicklung ohne Betriebskonzept ist die teuerste Variante von allen. Bauen heißt heute sinnvollerweise Build and Operate: ein Partner, der baut UND laufend weiterentwickelt.
Das ehrliche Risiko des Bauens
Damit das hier kein Verkaufsprospekt wird: Individuelle Entwicklung kann schiefgehen. Die drei realen Risiken sind Abhängigkeit vom falschen Partner (deshalb: Code-Eigentum und Dokumentation vertraglich sichern, dann ist der Partner austauschbar), unterschätzte Datenqualität (deshalb: Discovery vor Festpreis) und der Big-Bang-Reflex (deshalb: modulweise live gehen, alle vier bis sechs Wochen ein nutzbares Ergebnis). Wer diese drei Punkte im Vertrag und im Vorgehen adressiert hat, hat das Risiko des Bauens unter das Risiko des Lock-ins gesenkt.
Der dritte Weg: Erst Layer, dann entscheiden
In der Praxis ist Make or Buy selten binär. Der bewährte Mittelweg: Das bestehende Standard-System bleibt, darüber entsteht eine eigene KI-Schicht (Auswertungen, Agenten, Automatisierung), die schon Dir gehört. Funktioniert die Schicht, wächst sie. Module des Altsystems werden erst ersetzt, wenn der Nutzen bewiesen ist. Wie das konkret aussieht, zeigt der Beitrag KI im ERP-System, die Standard-gegen-Eigenbau-Abwägung speziell beim ERP vertieft Standard-ERP vs. eigenes System.
Konkret werden? Bring die Frage mit, an der Du gerade hängst. Wir rechnen beide Wege durch, und wenn Kaufen für Dich die bessere Antwort ist, sagen wir Dir das auch. Ein Kunde, der in zwei Jahren wechseln muss, ist kein guter Kunde.
Häufige Fragen
Wie lange dauert es, KI-Software für ein KMU entwickeln zu lassen?
Durch KI-gestützte Entwicklung haben sich die Zeiträume um eine Größenordnung verkürzt: Ein klar abgegrenzter erster Anwendungsfall (z. B. ein Agent oder eine Wissensplattform) ist in vier bis sechs Wochen produktiv, ein kompletter Stack-Ersatz je nach Umfang in Wochen bis wenigen Monaten statt der früher üblichen 12 bis 18 Monate. Voraussetzung ist eine saubere Discovery-Phase und ein schrittweiser Rollout statt Big Bang.
Wem gehört der Code bei individuell entwickelter KI-Software?
Das regelt der Vertrag, und genau dort sollte man hinschauen: Seriös ist die vollständige Übertragung des kundenspezifischen Codes an den Auftraggeber nach Bezahlung. Vorbestehende Werkzeuge des Dienstleisters bleiben üblicherweise dessen Eigentum mit Nutzungsrecht für den Kunden. Wer diese Klausel nicht schriftlich bekommt, kauft ein Mietverhältnis mit anderem Namen.