KI für Supply Chain Management Software: bauen oder kaufen?

Die Adoption von KI in der Supply Chain wächst, aber sie wächst ungleichmäßig. Die BCG-Studie Supply Chain Planning 2026 zeigt, dass die meisten Unternehmen den Sprung von ersten Pilotprojekten zur produktiven Nutzung noch nicht geschafft haben. Der PWC Digital Trends in Operations Survey 2025 benennt die häufigsten Ursachen klar: Datenqualität, Erklärbarkeit der Modelle und der Aufwand, der nach dem ersten Modell überhaupt erst beginnt. Vor diesem Hintergrund stellt sich in jedem Unternehmen, das eine KI-Lösung für seine Supply Chain Management Software evaluiert, die gleiche Frage: Bauen wir selbst oder kaufen wir ein? Die Antwort ist keine Technologiefrage. Sie hängt an vier Kriterien über das eigene Unternehmen. Dieser Beitrag arbeitet sie der Reihe nach durch. 

Wann KI selbst zu entwickeln eine rationale Entscheidung ist 

Eigenentwicklung gilt vielen Entscheidern als der aufwendigere und riskantere Weg. Das stimmt in den meisten Fällen, aber eben nicht in allen. Es gibt drei Konstellationen, in denen Make die rationale Entscheidung ist. In jeder dieser Konstellationen muss eine Bedingung erfüllt sein, sonst kippt das Argument in sein Gegenteil. 

KI als Kernkompetenz: Wenn der Algorithmus selbst Wettbewerbsvorteil ist 

Eigenentwicklung ergibt strategisch Sinn, wenn die Prognose oder die Planungslogik selbst zum Differenzierungsmerkmal des Unternehmens gehört. In der Praxis betrifft das eine kleine, aber klar abgrenzbare Gruppe: Handelsunternehmen mit proprietären Nachfragedaten, deren Vorhersagequalität direkt auf die Marge wirkt; Hersteller mit einzigartigen Prozessparametern, die kein externer Anbieter im Detail kennt; Logistikdienstleister, deren Routen- oder Kapazitätsmodelle Teil ihres Geschäftsmodells sind. 

In all diesen Fällen ist das Modell nicht Werkzeug, sondern Produkt. Wer es einkauft, gibt Kontrolle über einen Teil der eigenen Wertschöpfung ab. Wer es selbst entwickelt, hält die Wertschöpfung im Haus, mit allen Folgen für Personalbedarf, Roadmap-Hoheit und langfristige Pflege. 

Die Prüffrage, an der diese Argumentation steht oder fällt, lautet: Gibt es in Ihrem Unternehmen Planungswissen, das ein externer Anbieter nicht replizieren kann, weil es aus eigenen Daten oder eigener Erfahrung entstanden ist? Ein einzelner Data Scientist im Team ist hier kein Argument. Eine bewusste, vom Vorstand getragene Entscheidung, KI-Kompetenz dauerhaft als Kernkompetenz aufzubauen, ist eines. 

Datenprivatsphäre: Wenn Daten das Unternehmen nicht verlassen sollen 

Die zweite Konstellation ist juristisch oder vertraglich getrieben. Manche Unternehmen verarbeiten Daten, die nach interner Compliance, behördlichen Vorgaben oder Kundenvereinbarungen das Unternehmen nicht verlassen dürfen. Das betrifft typischerweise Pharmazulieferer mit Wirkstoffmischungen, Rüstungs- oder Sicherheitslieferketten, oder Unternehmen, deren Großkunden vertraglich eine On-Premise-Verarbeitung verlangen. 

In diesen Fällen ist Eigenentwicklung nicht zwingend die einzige Option, aber oft die wirtschaftlichere. Spezialisierte Anbieter bieten On-Premise-Deployment an, allerdings mit Aufschlägen, die über fünf Jahre durchaus die Hälfte der Eigenentwicklungskosten erreichen können. Wer die nötige IT-Infrastruktur und das Personal ohnehin hat, kann hier rechnen. 

Die Einschränkung bleibt allerdings deutlich: Datensouveränität ist ein nachvollziehbares Argument, aber sie löst nicht das Problem der laufenden Modellpflege. Ein on-premise betriebenes ML-Modell ist trotzdem ein ML-Modell, das Datendrift erfährt, neue Features braucht und überwacht werden muss. 

TCO langfristig: Wenn das Lizenzmodell teurer als die Entwicklung wird 

Das dritte und am häufigsten vorgebrachte Argument ist betriebswirtschaftlich. Bei sehr hohem Transaktionsvolumen oder einer großen Zahl von Modellen können die laufenden Lizenzkosten einer kommerziellen Lösung über fünf bis sieben Jahre die Kosten einer Eigenentwicklung übersteigen. Die Total Cost of Ownership, also die Summe aller Kosten über den Lebenszyklus, kippt dann zugunsten der Eigenentwicklung. 

Die Deloitte-Studie 2026 Manufacturing Industry Outlook macht aber gleichzeitig auf einen Punkt aufmerksam, an dem viele Build-Rechnungen scheitern: Die Wartungs- und Weiterentwicklungskosten werden häufig zu niedrig angesetzt. Ein produktives ML-Modell kostet im laufenden Betrieb erfahrungsgemäß zwischen 30 und 50 Prozent dessen, was seine Erstentwicklung gekostet hat. Wer mit fünf Modellen plant, plant in Wirklichkeit mit fünf Modellen plus einem laufenden MLOps-Aufwand, der mit jeder weiteren produktiven Anwendung wächst. 

Das TCO-Argument trägt also unter zwei Bedingungen. Erstens müssen die Anforderungen so stabil sein, dass kein häufiger Methodenwechsel nötig wird. Zweitens muss die Wartungskostenseite der Rechnung realistisch angesetzt sein. Wer hier optimistisch rechnet, baut sich seine eigene Falle. 

Wann eine spezialisierte Lösung schneller und nachhaltiger zum Ziel führt 

Der Kauf einer Lösung wird oft als Kontrollverzicht beschrieben. In der Praxis bedeutet er etwas anderes, nämlich eine bewusste Fokusverlagerung. Statt Algorithmus-Entwicklung übernimmt das Unternehmen die Verantwortung für Datenqualität, Prozessintegration und die Übersetzung von Prognose in Entscheidung. Drei Argumente sprechen für diesen Weg, jedes hat eine Gegenposition, die ehrlich benannt werden muss. 

Time-to-Value: Wenn Ergebnisse in Monaten, nicht Jahren nötig sind 

Eine Eigenentwicklung von einem produktiven KI-Modell für die Absatzprognose oder Bestelloptimierung dauert in der Praxis typischerweise zwölf bis vierundzwanzig Monate, gerechnet von der Entscheidung bis zum stabilen produktiven Betrieb. Diese Spanne enthält die Datenaufbereitung, das Feature Engineering, die Modellauswahl, die Validierung, die Anbindung an das ERP und die organisatorische Einführung. 

Eine spezialisierte Lösung erreicht denselben Punkt typischerweise in drei bis sechs Monaten, vorausgesetzt, die Datenbasis ist verfügbar und sauber. Die Differenz von neun bis achtzehn Monaten ist nicht nur ein Komfortunterschied. Sie wirkt sich direkt auf den ROI aus. Wenn ein Unternehmen in einem volatilen Markt operiert und auf Nachfrageveränderungen schnell reagieren muss, ist diese Differenz unter Umständen geschäftsentscheidend. 

Die BCG-Studie 2026 weist darauf hin, dass Time-to-Value für die Mehrheit der Unternehmen das gewichtigste Argument für den Buy-Weg ist. Die Einschränkung gilt allerdings auch hier: Eine kürzere Time-to-Value bringt nichts, wenn die Datenbasis fehlt. Drei Monate Implementierung setzen mindestens zwei Jahre strukturierter Verkaufs- und Bestelldaten voraus. 

MLOps: Der Dauerbetrieb, der nach dem Modell beginnt 

Wer KI selbst entwickelt, übernimmt nicht nur die Modellentwicklung, sondern auch den dauerhaften Betrieb. Der Fachbegriff dafür ist MLOps, also die Disziplin, die den Betrieb und die Pflege von Machine-Learning-Modellen in produktiven Umgebungen organisiert. MLOps umfasst das Monitoring der Modellgüte, die Erkennung von Datendrift, das Nachtrainieren bei veränderten Eingabedaten, das Versionsmanagement und die Anpassung von Features bei neuen Geschäftsanforderungen. 

In Gesprächen mit Mittelständlern wird dieser Block regelmäßig unterschätzt, manchmal vergessen. Die typische Erstplanung umfasst Data Scientist, Dateninfrastruktur und ein erstes Modell. Was nach dem Go-live kommt, fehlt in der Rechnung. Genau hier liegt der unsichtbare Kostenblock, der TCO-Vergleiche kippen kann. 

Die Buy-Entscheidung zieht diesen Block aus dem eigenen Verantwortungsbereich heraus. Der Anbieter trägt die Modellpflege, die Anpassung an neue Datenmuster und die Weiterentwicklung der Algorithmen. Was beim Käufer bleibt, ist die Verantwortung für die eigenen Daten und für die Übersetzung der Prognose in Bestellentscheidungen. Beides sind Aufgaben, die ohnehin bleiben, auch im Buy-Modell. 

Vendor Lock-in: Wie real das Risiko wirklich ist 

Das wichtigste Gegenargument zum Kauf ist Vendor Lock-in, also die Abhängigkeit von einem einzelnen Anbieter, die einen Wechsel schwierig oder kostspielig macht. Das Risiko ist real, aber es wird häufig pauschal überzeichnet. Wer nüchtern bewertet, findet drei Faktoren, die das tatsächliche Lock-in-Risiko bestimmen. 

Erstens das Datenformat: Sind Eingabedaten und Ergebnisse über offene Schnittstellen exportierbar, oder bleiben sie in einem proprietären Format? Zweitens die Modelltransparenz: Versteht das Unternehmen, welche Features das Modell verwendet, oder ist es eine Blackbox? Drittens die Vertragsstruktur: Sind Kündigungsfristen und Datenrückgabe vertraglich klar geregelt? 

Bei einer Lösung mit standardisierten APIs, dokumentierten Datenformaten und sauberen Vertragsbedingungen ist ein Wechsel zwar aufwendig, aber möglich. Bei einer geschlossenen Plattform ohne offene Schnittstellen ist er es nicht. Vendor Lock-in ist also keine Eigenschaft des Buy-Wegs an sich, sondern eine Eigenschaft konkreter Anbieter. Wer diese Faktoren in der Auswahl prüft, reduziert das Risiko deutlich, ohne deshalb auf Eigenentwicklung umsteigen zu müssen. 

Vier Fragen, die die Make-or-Buy-Entscheidung im SCM klären 

Die bisherigen Argumente lassen sich auf vier Fragen verdichten, die sich jedes Unternehmen vor der Entscheidung stellen sollte. Sie sind in dieser Reihenfolge zu beantworten, weil jede folgende Frage nur dann sinnvoll ist, wenn die vorhergehende geklärt wurde. 

Kriterium 1: Ist KI-Entwicklung eine Kernkompetenz, die wir aufbauen wollen? 

Diese Frage ist nicht identisch mit der Frage, ob das Unternehmen einen Data Scientist hat. Ein Data Scientist im Team beweist, dass das Wissen vorhanden ist, aber er beweist nicht, dass das Unternehmen daraus eine dauerhafte, skalierbare Kompetenz aufbauen will. Letzteres ist eine strategische Entscheidung, die der Vorstand trägt, nicht eine HR-Frage. 

Die Antwort fällt unterschiedlich aus, je nachdem, ob KI-Lösungen zum Produktportfolio gehören sollen oder ein internes Werkzeug bleiben. Im ersten Fall lohnt sich Aufbau, im zweiten nicht. Ein Industrieunternehmen, das seine Forecasting-Lösung auch an Lieferanten oder Kunden weitergeben könnte, hat einen anderen Business Case als ein Großhändler, der nur seine eigene Disposition optimieren will. 

Kriterium 2: Wie lang ist der akzeptable Zeithorizont? 

Die zweite Frage betrifft den Zeitdruck. Wer Ergebnisse in den nächsten sechs Monaten braucht, weil ein Markt sich verändert oder ein Kostenproblem akut ist, kann nicht auf eine Eigenentwicklung warten. Wer einen strategischen Aufbau über zwei bis drei Jahre plant, kann es. 

Diese Frage ist deshalb wichtig, weil sie selten ehrlich beantwortet wird. Viele Build-Entscheidungen werden mit langen Zeithorizonten begründet, die in der Praxis nie eingehalten werden. Wenn nach achtzehn Monaten kein produktives Modell läuft und der Druck wächst, wird das Projekt entweder gestoppt oder nachträglich durch einen Anbieter ersetzt, was die TCO-Rechnung am Ende kippt. 

Kriterium 3: Wie sieht der TCO über fünf Jahre ehrlich aus? 

Die dritte Frage ist quantitativ. Sie verlangt zwei realistische Rechnungen über fünf Jahre. Die Build-Rechnung umfasst Personalkosten für Entwicklung und MLOps, Infrastrukturkosten, Lizenzkosten für genutzte Bibliotheken und Tools, Schulung und Weiterentwicklung. Die Buy-Rechnung umfasst Lizenzgebühren, Implementierung, Schulung, Eigenleistung für Datenaufbereitung und gegebenenfalls Anbindung. 

Entscheidend ist die Ehrlichkeit beider Rechnungen. Wer die Wartungskosten auf der Build-Seite niedrig ansetzt oder die Schulung auf der Buy-Seite vergisst, vergleicht keine vergleichbaren Größen. Eine seriöse Faustregel: Plant ein Unternehmen mit weniger als 30 Prozent Wartungsanteil pro Jahr auf den Erstentwicklungskosten, ist die Build-Rechnung mit hoher Wahrscheinlichkeit zu optimistisch. 

Auch die BVL-Studie Trends und Strategien in Logistik und Supply Chain Management 2025/26 zeigt, dass viele KI-Initiativen im Mittelstand am unterschätzten Betriebsaufwand scheitern, nicht an der Modellqualität. 

Kriterium 4: Ist ein Hybridansatz der dritte Weg? 

Make oder Buy ist keine binäre Entscheidung. In der Praxis hat sich für viele mittelständische Unternehmen ein Hybridansatz bewährt, bei dem die spezialisierte Lösung den Algorithmus liefert, während das Unternehmen Datenpipelines, Feature Engineering und die Übersetzung in Geschäftsregeln selbst gestaltet. 

Dieser Weg vereint zwei Vorteile. Erstens bleibt die Time-to-Value kurz, weil das Modell als getestete Komponente eingekauft wird. Zweitens bleibt die Domänenkompetenz im Unternehmen, weil die Datenarbeit und die Geschäftslogik nicht ausgelagert werden. Der Hybridansatz ist deshalb interessant, weil er gegen die häufigsten Fehler beider Extremwege schützt: gegen den unterschätzten MLOps-Block beim Make und gegen die schleichende Entkoppelung von der eigenen Datenrealität beim Buy. 

Voraussetzung ist allerdings, dass der gewählte Anbieter den Hybridansatz technisch unterstützt, also offene Schnittstellen für eigene Datenpipelines und Konfigurierbarkeit der Geschäftsregeln bietet. Eine geschlossene Plattform mit Blackbox-Modell schließt diesen Weg aus, was ihn wieder zum Auswahlkriterium für die Anbieterauswahl macht. 

Drei Schritte, mit denen Sie die Entscheidung sauber treffen 

Die Make-or-Buy-Entscheidung lässt sich nicht in einer Sitzung klären. Sie erfordert drei aufeinander aufbauende Schritte, die in dieser Reihenfolge tragen. 

Zuerst die strategische Frage klären: Soll KI-Entwicklung Kernkompetenz werden oder bleibt sie Werkzeug? Diese Entscheidung gehört auf Vorstandsebene und ist nicht delegierbar. Wenn die Antwort Kernkompetenz lautet, folgt der zweite Schritt: eine ehrliche TCO-Rechnung über fünf Jahre, mit realistischem Wartungs- und MLOps-Anteil. Wenn die Antwort Werkzeug lautet, folgt stattdessen die Anbieterauswahl mit Schwerpunkt auf offenen Schnittstellen, Datenexportfähigkeit und Hybridfähigkeit. Erst der dritte Schritt ist die Implementierung selbst, gleich auf welchem Weg. Wer die Reihenfolge umkehrt und zuerst eine Lösung auswählt oder ein Team einstellt, kauft sich nicht Geschwindigkeit, sondern eine Korrekturschleife. Die richtige Entscheidung beginnt nicht mit der Technologie, sondern mit der Frage nach dem eigenen Fokus. 

Weiterführende Quellen

1. BCG (2026): Supply Chain Planning 2026: Why AI Alone Isn't Enough 

2. Deloitte (2026): 2026 Manufacturing Industry Outlook 

3. PWC (2025): Digital Trends in Operations Survey 

4. BVL (2025): Trends und Strategien in Logistik und Supply Chain Management 2025/26 

FAQ