KI selbst bauen oder einkaufen
Die Vorführung des Anbieters beantwortet die Frage nicht. Entscheidend sind Vorlaufzeit, wer die Lösung in zwei Jahren pflegt und was du beim Ausstieg zurückbekommst.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Frage wird zu früh gestellt und zu spät entschieden
Der übliche Ablauf sieht so aus: Ein Fachbereich hat einen Anwendungsfall, die IT sagt, das bauen wir selbst, parallel führt ein Anbieter etwas vor, das beeindruckend aussieht. Entschieden wird dann anhand der Vorführung, also anhand des am besten vorbereiteten Falls. Was danach kommt, hat mit diesem Fall wenig zu tun.
Ein halbes Jahr später steht in vielen Häusern dasselbe Bild: Das eingekaufte Werkzeug läuft bei zwölf Leuten, weil die Anbindung an die Bestandssysteme fehlt, und die Eigenentwicklung hat keinen Eigentümer mehr, weil die Person, die sie gebaut hat, im nächsten Projekt steckt.
Teuer ist daran nicht die Lizenz. Teuer ist das verlorene Jahr und der zweite Anlauf, der mit deutlich weniger Rückenwind startet, weil im Haus inzwischen alle wissen, dass KI bei uns nicht funktioniert.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der direkte Vergleich
Eigenentwicklung
selbst gebaut und mit eigenem Team betrieben
Fertiges Produkt
eingekauft und vom Anbieter gepflegt
Low-Code-Plattform
zusammengesteckt, meist direkt im Fachbereich
| Entscheidungsfrage | Eigenentwicklung | Fertiges Produkt | Low-Code-Plattform |
|---|---|---|---|
| Wie schnell ist der erste echte Nutzen da? | Schwäche Bis eine Eigenentwicklung mehr kann als die Vorführung, vergehen Monate, in denen niemand im Fachbereich etwas davon hat. | Stärke Die Grundfunktionen stehen sofort, gebremst wird nur durch Konten, Rechte und die Anbindung an eure Systeme. | Stärke Ein erster Ablauf steht oft in Tagen, weil der Fachbereich ihn ohne Entwicklungsslot selbst zusammenstellt. |
| Wie genau passt es auf euren Ablauf? | Stärke Der Ablauf wird genau so abgebildet, wie er bei euch läuft, samt der Ausnahmen, die es sonst nirgends gibt. | Kommt darauf an Das Produkt bildet den Standard ab, und meist müsst ihr euch bewegen, nicht das Produkt. Das ist oft kein Nachteil. | Kommt darauf an Vieles lässt sich nachbauen, bis eine Anforderung kommt, die die Plattform nicht vorgesehen hat. Dann wird es umständlich. |
| Wer trägt die Pflege in zwei Jahren? | Schwäche Das eigene Haus, dauerhaft und ohne Ende, samt Auswertung, Sonderfällen und Anpassung nach jedem Modellwechsel. | Stärke Der Anbieter, das ist der Kern des Geschäfts. Bei euch bleibt die Pflege von Konten, Rechten und Schnittstellen. | Kommt darauf an Formal der Fachbereich, tatsächlich oft die eine Person, die es gebaut hat. Genau hier entstehen die stillen Ausfälle. |
| Wie leicht kommst du wieder heraus? | Stärke Code, Daten und Regeln gehören euch, ein Wechsel des Modells darunter ist eine Änderung an einer Stelle. | Schwäche Der Datenexport ist meist geregelt, Konfiguration, Regeln und gesammelte Korrekturen bleiben oft beim Anbieter. | Schwäche Der zusammengesteckte Ablauf ist an die Plattform gebunden und muss anderswo komplett neu gebaut werden. |
| Welche Kompetenz musst du dauerhaft im Haus halten? | Schwäche Entwicklung, Betrieb und jemand, der die Qualität der Ergebnisse fachlich beurteilen kann. Drei Rollen, nicht eine. | Stärke Fachliche Betreuung und ein Verständnis für Rechte und Schnittstellen reichen für den laufenden Betrieb aus. | Kommt darauf an Der Fachbereich kann viel selbst, braucht aber jemanden, der bei Rechten, Daten und Grenzen der Plattform einschätzt. |
| Was passiert, wenn das Modell darunter abgelöst wird? | Kommt darauf an Du musst nachziehen, kannst den Zeitpunkt aber selbst wählen und vorher gegen eigene Testfälle prüfen. | Schwäche Der Wechsel passiert, wenn der Anbieter ihn plant, und das Verhalten eurer eingespielten Abläufe ändert sich mit. | Kommt darauf an Meist merkt ihr es an veränderten Ergebnissen, und die Anpassung liegt beim Fachbereich, der sie selten testet. |
Wie schnell ist der erste echte Nutzen da?
Bis eine Eigenentwicklung mehr kann als die Vorführung, vergehen Monate, in denen niemand im Fachbereich etwas davon hat.
Die Grundfunktionen stehen sofort, gebremst wird nur durch Konten, Rechte und die Anbindung an eure Systeme.
Ein erster Ablauf steht oft in Tagen, weil der Fachbereich ihn ohne Entwicklungsslot selbst zusammenstellt.
Wie genau passt es auf euren Ablauf?
Der Ablauf wird genau so abgebildet, wie er bei euch läuft, samt der Ausnahmen, die es sonst nirgends gibt.
Das Produkt bildet den Standard ab, und meist müsst ihr euch bewegen, nicht das Produkt. Das ist oft kein Nachteil.
Vieles lässt sich nachbauen, bis eine Anforderung kommt, die die Plattform nicht vorgesehen hat. Dann wird es umständlich.
Wer trägt die Pflege in zwei Jahren?
Das eigene Haus, dauerhaft und ohne Ende, samt Auswertung, Sonderfällen und Anpassung nach jedem Modellwechsel.
Der Anbieter, das ist der Kern des Geschäfts. Bei euch bleibt die Pflege von Konten, Rechten und Schnittstellen.
Formal der Fachbereich, tatsächlich oft die eine Person, die es gebaut hat. Genau hier entstehen die stillen Ausfälle.
Wie leicht kommst du wieder heraus?
Code, Daten und Regeln gehören euch, ein Wechsel des Modells darunter ist eine Änderung an einer Stelle.
Der Datenexport ist meist geregelt, Konfiguration, Regeln und gesammelte Korrekturen bleiben oft beim Anbieter.
Der zusammengesteckte Ablauf ist an die Plattform gebunden und muss anderswo komplett neu gebaut werden.
Welche Kompetenz musst du dauerhaft im Haus halten?
Entwicklung, Betrieb und jemand, der die Qualität der Ergebnisse fachlich beurteilen kann. Drei Rollen, nicht eine.
Fachliche Betreuung und ein Verständnis für Rechte und Schnittstellen reichen für den laufenden Betrieb aus.
Der Fachbereich kann viel selbst, braucht aber jemanden, der bei Rechten, Daten und Grenzen der Plattform einschätzt.
Was passiert, wenn das Modell darunter abgelöst wird?
Du musst nachziehen, kannst den Zeitpunkt aber selbst wählen und vorher gegen eigene Testfälle prüfen.
Der Wechsel passiert, wenn der Anbieter ihn plant, und das Verhalten eurer eingespielten Abläufe ändert sich mit.
Meist merkt ihr es an veränderten Ergebnissen, und die Anpassung liegt beim Fachbereich, der sie selten testet.
Was passt wann
- Wenn der Ablauf in jedem Unternehmen deiner Branche ungefähr gleich aussieht
- kauf ihn ein und steck die gesparte Zeit in die Anbindung an eure Systeme
- Wenn genau dieser Ablauf das ist, womit ihr euch von anderen unterscheidet
- bau ihn selbst, aber besetze vorher die Rolle, die ihn danach betreibt
- Wenn noch niemand weiß, ob der Anwendungsfall überhaupt trägt
- bau ihn in einer Low-Code-Umgebung mit einem festen Datum für Ausbau oder Abschaltung
Fünf Fragen vor der Entscheidung zwischen Bauen und Kaufen
- 01 Läuft dieser Ablauf bei anderen Unternehmen genauso wie bei euch?
- 02 Wann muss der erste echte Nutzen im Betrieb ankommen?
- 03 Wer pflegt die Lösung, wenn das Projekt beendet ist?
- 04 Welche Daten und Regeln bekommst du beim Ausstieg zurück?
- 05 Welche Kompetenz musst du dafür dauerhaft im Haus halten?
Was du danach entscheiden kannst
Die Entscheidung wird beherrschbar, wenn du sie in fünf einzeln beantwortbare Fragen zerlegst. Keine davon braucht eine Vorführung, alle brauchen Ehrlichkeit über den eigenen Ablauf.
Standard erkennen
Du prüfst, ob sich euer Ablauf ohne Sonderregeln beschreiben lässt. Wenn du dabei viele Sätze brauchst, die mit „bei uns ist das anders“ beginnen, prüf zuerst, ob diese Ausnahmen noch nötig sind.
Betrieb vorher besetzen
Du benennst die Person, die die Lösung in zwei Jahren pflegt, bevor gebaut wird. Ohne diesen Namen ist die Bau-Entscheidung eine Wette auf Personalkontinuität.
Anbindung mitrechnen
Du planst Rechte, Stammdaten und Schnittstellen als eigenes Arbeitspaket ein. Dieser Teil fällt bei jedem der drei Wege an und wird bei allen dreien unterschätzt.
Ausstieg konkret prüfen
Du fragst, ob du geprüfte Daten, Regeln und Korrekturen in nutzbarer Form zurückbekommst. Ein Export, der nur beim Anbieter wieder einlesbar ist, zählt nicht.
Versuche befristen
Du gibst jedem Low-Code-Fall ein Datum für Ausbau oder Abschaltung mit. Damit verhinderst du den stillen Übergang vom Versuch zum geschäftskritischen System.
Modellwechsel einplanen
Du klärst für jeden Weg, was passiert, wenn das zugrunde liegende Modell getauscht wird. Wer eigene Testfälle hat, merkt den Unterschied vor den Nutzenden.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was der Einkauf tatsächlich einschließt
Kaufen heißt selten installieren und fertig. Die Arbeit verschiebt sich, sie verschwindet nicht: Benutzerkonten und Rollen, Anbindung an Stammdaten, Schnittstellen zum führenden System, eine Testumgebung und die Abstimmung darüber, wer welche Daten sehen darf. Rechne damit, dass dieser Teil nicht kleiner ist als der Lizenzbetrag, und schneide ihn als eigenes Arbeitspaket.
Mit dem Produkt kaufst du außerdem die Entwicklungsrichtung des Anbieters. Solange sie zu deiner passt, ist das der größte Vorteil überhaupt, weil dein Werkzeug besser wird, ohne dass jemand bei dir etwas tut. Es wird an dem Tag zum Problem, an dem der Anbieter seine Prioritäten verschiebt und dein wichtigster Fall nicht mehr auf seiner Liste steht.
Eine Frage, die selten gestellt wird und viel verrät: Was passiert, wenn das Modell unter dem Produkt ausgetauscht wird? Bei vielen Werkzeugen ändert sich damit das Verhalten spürbar, und der Zeitpunkt liegt nicht bei dir.
Was Eigenentwicklung nach der ersten Version kostet
Die erste Fassung ist erstaunlich schnell fertig, und das ist die Falle. Was danach folgt, steht in keinem Projektplan: eine Auswertung, an der du merkst, wenn die Qualität nachlässt, die Pflege der Anweisungen beim Modellwechsel, die Behandlung der Sonderfälle, Unterstützung für Nutzende, Dokumentation und eine Stelle, an die man sich wendet, wenn etwas falsch ist.
Die Faustregel dafür ist unbequem, aber sie hält: Wer baut, betreibt auch. Und Betrieb endet nicht. Wenn im Unternehmen niemand diese Rolle dauerhaft übernimmt, wird die Eigenentwicklung stillgelegt, sobald die bauende Person das Team wechselt.
Deshalb gehört die Frage nach dem Eigentümer vor die Entscheidung, nicht danach. Wenn du keinen Namen für die kommenden zwei Jahre nennen kannst, ist die Antwort auf die Bau-Frage bereits gefallen.
Low-Code als dritter Weg, mit Verfallsdatum
Low-Code-Plattformen senken die Einstiegshürde deutlich, weil ein Fachbereich einen Ablauf selbst zusammenstecken kann, ohne auf einen freien Entwicklungstermin zu warten. Für die Frage, ob ein Anwendungsfall überhaupt trägt, ist das der schnellste und billigste Weg, den es gibt.
Die Falle ist der schleichende Übergang: Der Versuch wird benutzt, dann gebraucht, dann geschäftskritisch, und niemand hat den Moment bemerkt. Dann gibt es keine Testumgebung, keine Versionierung, keine Vertretung und keine Dokumentation, aber eine Abteilung, die ohne das Ding nicht mehr arbeiten kann.
Gib jedem Low-Code-Fall deshalb ein Datum mit. An diesem Tag wird entschieden, ob er ein richtiges Zuhause mit Betrieb und Verantwortung bekommt oder abgeschaltet wird. Ein drittes Ergebnis darf es nicht geben.
Die Abhängigkeit sitzt nicht nur in den Daten
Über den Ausstieg wird meist als Datenexport gesprochen, und der ist der einfachste Teil. Schwerer wiegt alles, was um die Daten herum entstanden ist: die Konfiguration, die formulierten Anweisungen, die Regeln für Sonderfälle und vor allem die gesammelten Korrekturen. Diese Korrekturen sind über Monate entstanden und sind der eigentliche Wert.
Stell die Frage deshalb konkret: Bekomme ich meine geprüften und korrigierten Datensätze heraus, in einem Format, mit dem ein anderes System etwas anfangen kann? Ein Export, der nur im Werkzeug des Anbieters wieder einlesbar ist, ist kein Ausstieg.
Der dritte Teil ist Prozesswissen. Was im Werkzeug an Ausnahmen und Zuständigkeiten hinterlegt wurde, existiert oft nirgendwo sonst. Halte die Regeln außerhalb des Werkzeugs fest, dann überlebt das Wissen einen Anbieterwechsel.
Dazu passende Kurse
Wie du einen Anwendungsfall vorab so zuschneidest, dass die Frage überhaupt entscheidbar wird, behandeln die Weiterbildungen für die Planung erster KI-Vorhaben .
Die Zahlen hinter Vorlaufzeit und laufendem Aufwand rechnest du in den Kurse zur Wirtschaftlichkeitsrechnung von KI an einem eigenen Fall durch.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Die Inhalte wurden sehr gut vermittelt und Fragen wurden perfekt beantwortet.
Marco ist ein extrem guter Trainer, der mit seinem Fachwissen zum Thema KI sehr viel Expertise mitbringt.
Seminarleiter war sehr gut vorbereitet, Den Lehrstoff hat er ausführlich und praxisorientiert vorgetragen.
Häufige Fragen
Woran erkenne ich, dass ein Anwendungsfall Standard ist?
Lohnt es sich, ein eigenes Modell zu trainieren?
Was gehört in ein Angebot, das wir vergleichen wollen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem KI-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Entscheidung einmal sauber durchgerechnet
In den Kursen gehst du deinen eigenen Anwendungsfall entlang der Kriterien durch und kommst mit einer begründeten Empfehlung statt mit einem Bauchgefühl heraus.