Die Frage „selbst bauen oder kaufen?“ wird meist über das Werkzeug gestellt. Sie sollte über den Prozess gestellt werden. Entscheidend ist nicht, ob eine Standardsoftware KI-Funktionen hat, sondern ob der Ablauf, den sie unterstützen soll, das Unternehmen von anderen unterscheidet oder ob er ohne Nachteil so laufen darf wie bei allen anderen auch.
Drei Wege statt zwei
| Weg | Passt, wenn | Typische Risiken | Verantwortung im Betrieb |
|---|---|---|---|
| Standardsoftware mit KI-Funktion | Der Prozess ist standardisierbar und der freigegebene Funktionsumfang deckt den Bedarf | Anpassungsgrenzen, Datenwege des Anbieters, Abhängigkeit bei Preis und Roadmap | Anbieter und interne Administration |
| Eigenentwicklung durch internes Team | Der Prozess differenziert, ein Team ist vorhanden und der Betrieb ist dauerhaft leistbar | Unterschätzter Betrieb, Abhängigkeit von einzelnen Entwicklern, fehlende Dokumentation | Vollständig intern |
| Individuelle Entwicklung durch einen Partner | Der Prozess differenziert, interne Kapazität fehlt | Ausweitung des Umfangs, unklare Übergabe, Wartungslücke nach Projektende | Vereinbarter Scope mit geregelter Übergabe |
Der dritte Weg wird in Entscheidungsvorlagen häufig vergessen. Dabei ist er für mittelständische Unternehmen ohne eigene Entwicklung oft der einzige realistische Zugang zu einer Lösung, die den Kernprozess wirklich abbildet.
Muss, Soll, Komfort: Anforderungen ehrlich sortieren
Die meisten Anforderungslisten scheitern daran, dass alles als unverzichtbar gilt. Eine belastbare Sortierung folgt drei Fragen: Ohne welche Funktion ist der Prozess nicht arbeitsfähig? Welche Funktion spart nachweisbar Zeit oder Fehler? Welche Funktion ist angenehm, aber ersetzbar?
Anschließend wird die Standardsoftware nur gegen die Muss-Liste geprüft. Deckt sie alle Muss-Anforderungen ab, ist Standard die richtige Wahl, auch wenn Komfortfunktionen fehlen. Scheitert sie an einer Muss-Anforderung, die im differenzierenden Kernprozess liegt, ist Individualentwicklung begründet. Scheitert sie nur an Komfort, ist der Wunsch nach Eigenbau meist ein Wunsch nach Gewohnheit.
Der schlechteste Weg: der unklare Mittelweg
Am teuersten wird es, wenn eine Standardsoftware mit umfangreichen Sonderanpassungen versehen wird, ohne dass jemand die Produktverantwortung dafür trägt. Jedes Update des Anbieters bricht etwas, der ursprüngliche Dienstleister ist nicht mehr erreichbar und die interne IT kennt die Anpassungen nur aus Ticketverläufen. Diese Konstellation vereint die Nachteile beider Welten: die Abhängigkeit des Kaufs und den Betriebsaufwand des Baus.
Lebenszykluskosten statt Angebotspreis
Ein Vergleich über drei Jahre sollte mindestens diese Kostenblöcke enthalten, unabhängig davon, welcher Weg gewählt wird:
- Lizenzen oder nutzungsabhängige Gebühren, einschließlich erwarteter Steigerungen.
- Integration in bestehende Systeme und Aufbereitung der Daten.
- Qualifizierung der Nutzer und Aufbau der Prüfroutinen.
- Betrieb, Monitoring und Reaktion auf Störungen.
- Änderungen nach dem ersten Jahr, wenn sich der Prozess weiterentwickelt.
- Ausstieg, also Datenexport, Ablösung und Parallelbetrieb.
Der EU Data Act stärkt seit September 2025 das Recht auf einen Wechsel zwischen Datenverarbeitungsdiensten. Technisch bleibt der Ausstieg trotzdem eine Frage der Architektur und sollte vor der Entscheidung durchgespielt werden.
Beispiel: Reklamationsbearbeitung in einem Fertigungsbetrieb
Ein Hersteller möchte Reklamationen schneller bearbeiten. Annahme, Status und Kommunikation mit dem Kunden sind Standard und werden von jedem Ticketsystem abgedeckt. Die technische Bewertung der Reklamation anhand eigener Prüfdaten und Fertigungsparameter ist dagegen der differenzierende Teil. Die tragfähige Entscheidung: Standard für das Ticketsystem, eine kleine individuelle Komponente für die Bewertung, verbunden über eine dokumentierte Schnittstelle. Weder „alles kaufen“ noch „alles bauen“ hätte diesen Prozess sauber abgebildet.
Kaufen, was gleich sein darf. Bauen, was anders sein muss. Und nichts bauen, was nach dem Projekt niemand betreiben kann.
Vor der Entscheidung
Zwei oder drei reale Szenarien mit echten Daten, ein Kostenvergleich über den Lebenszyklus, eine benannte Person für den Betrieb und ein beschriebener Ausstiegspfad sind die Mindestgrundlage. Wie die Integration in bestehende Systeme geplant wird, beschreibt der Beitrag zur KI-Integration; welche Abhängigkeiten dabei früh sichtbar werden sollten, der Beitrag zu Cloud-Wechsel und KI-Lock-in.