Wer in einem Auswahlgespräch fragt, ob eine Software KI enthält, bekommt heute in aller Regel ein Ja. Die Antwort ist deshalb wertlos. Die brauchbare Frage lautet anders: Welches Verfahren löst welches konkrete Problem, mit welchen Eingangsdaten, mit welcher Ausgabe und mit welcher Möglichkeit, das Ergebnis zu prüfen? Diese vier Angaben lassen sich in jedem seriösen Gespräch beantworten. Wo sie nicht beantwortet werden, liegt entweder ein Marketingbegriff vor oder ein Anbieter, der sein eigenes Produkt nicht durchdrungen hat.
Der Kern der Sache ist unspektakulär. Nahezu alle produktiv nützlichen KI-Anwendungen in der Lieferkette tun eines von drei Dingen: Sie schätzen einen unbekannten Wert (etwa den Absatz der nächsten Wochen oder die Ankunftszeit einer Sendung), sie erkennen ein Muster oder eine Abweichung (etwa eine auffällige Rechnung oder einen beschädigten Karton), oder sie berechnen eine möglichst gute Handlungsoption unter Nebenbedingungen (etwa eine Tourenfolge oder eine Bestellmenge). Alles Weitere ist Verpackung um diese drei Grundfunktionen herum.
Die erste Klasse ist die klassische Statistik und Zeitreihenrechnung. Exponentielle Glättung, Saisonzerlegung, Regressionsmodelle und verwandte Verfahren sind seit Jahrzehnten in Planungssystemen verbaut. Sie sind sparsam im Datenbedarf, gut erklärbar und bei stabilen Verläufen erstaunlich schwer zu schlagen. In vielen Projekten stellt sich heraus, dass ein sauber parametriertes statistisches Verfahren mit gepflegten Stammdaten den größeren Sprung bringt als ein neues Modell – schlicht weil vorher niemand die Parameter gepflegt hat.
Die zweite Klasse ist das maschinelle Lernen im engeren Sinn. Verfahren wie Entscheidungsbaum-Ensembles, Gradient-Boosting-Modelle oder neuronale Netze lernen Zusammenhänge aus historischen Beispielen, ohne dass die Zusammenhänge vorab formuliert werden müssen. Ihre Stärke liegt dort, wo viele Einflussgrößen gleichzeitig wirken und sich nicht linear verhalten: Absatz mit Aktions-, Wetter-, Kalender- und Preiseinflüssen, Lieferzeiten mit Abhängigkeit von Route, Saison und Lieferant, Ausschusswahrscheinlichkeiten mit Abhängigkeit von Charge und Maschine. Der Preis dafür ist ein höherer Datenbedarf und eine geringere unmittelbare Erklärbarkeit.
Die dritte Klasse ist die generative KI, im Wesentlichen große Sprachmodelle und verwandte multimodale Modelle. Sie erzeugen Text, extrahieren Inhalte aus unstrukturierten Dokumenten, fassen zusammen, übersetzen und formulieren. Sie rechnen nicht – zumindest nicht zuverlässig – und sie planen nicht. Ihr Platz in der Lieferkette liegt an den Rändern des Prozesses, dort wo heute Menschen Dokumente lesen, Sachverhalte zusammenfassen und Nachrichten formulieren. Das ist ein großes Feld, aber es ist nicht das Feld der Disposition.
Die vierte Klasse ist die mathematische Optimierung. Lineare und gemischt-ganzzahlige Programmierung, Constraint-Verfahren und Heuristiken beantworten Entscheidungsfragen unter Nebenbedingungen: Welche Tour, welche Losgröße, welche Zuordnung von Aufträgen zu Standorten, welcher Produktionsplan bei begrenzter Kapazität. Diese Verfahren sind streng genommen keine lernenden Systeme, werden im Markt aber regelmäßig unter dem KI-Etikett verkauft. Für den Nutzer ist das nicht schlimm, solange klar bleibt, dass hier gerechnet und nicht gelernt wird – denn daraus folgt, dass Qualität und Vollständigkeit der Nebenbedingungen über das Ergebnis entscheiden.
Die folgenreichste Verwechslung in KI-Projekten der Lieferkette betrifft den Unterschied zwischen einer Vorhersage und einer Entscheidung. Ein Prognosemodell sagt, was voraussichtlich geschehen wird. Eine Entscheidung legt fest, was daraufhin zu tun ist. Zwischen beiden liegt eine betriebswirtschaftliche Bewertung, die das Modell nicht kennt: Was kostet ein Fehlbestand im Vergleich zu einem Überbestand, welche Kapitalbindung ist vertretbar, welcher Servicegrad ist versprochen, welche Mindestbestellmengen und Lieferrhythmen gelten.
Praktisch bedeutet das: Eine bessere Prognose führt nicht automatisch zu besseren Beständen. Wenn die Bestellregel dahinter unverändert bleibt, verpufft der Gewinn an Prognosegüte im Regelwerk. Umgekehrt kann eine mittelmäßige Prognose mit einer klug gesetzten Sicherheitsbestandslogik zu deutlich besseren Ergebnissen führen als eine exzellente Prognose mit einer starren Meldebestandsregel. Wer ein KI-Projekt in der Disposition plant, sollte deshalb Prognose und Entscheidungsregel immer als Paar betrachten und den Nutzen am Ergebnis der Kette messen, nicht an der Genauigkeit eines Zwischenschritts.
Dazu gehört auch die Einsicht, dass eine Punktprognose selten das nützlichste Ergebnis ist. Für die Bestandsdimensionierung ist die Unsicherheit der Prognose oft wichtiger als ihr Erwartungswert: Ein Artikel mit stabilem, gut prognostizierbarem Verlauf braucht wenig Sicherheitsbestand, ein sprunghafter Artikel braucht viel – selbst wenn beide im Mittel gleich viel verkaufen. Moderne Verfahren liefern deshalb Verteilungen oder Quantile statt einer einzelnen Zahl. Ob ein Anbieter das anbietet und ob die nachgelagerte Bestandslogik damit umgehen kann, ist eine der aufschlussreichsten Prüffragen überhaupt.
Nicht jedes Problem in der Lieferkette ist ein KI-Problem, und die meisten sind es nicht. Als Faustregel eignen sich lernende Verfahren dort, wo drei Bedingungen zusammenkommen: Es gibt eine wiederkehrende Entscheidung oder Einschätzung in nennenswerter Stückzahl, es existieren historische Daten darüber, wie diese Einschätzung ausgefallen ist und wie die Realität aussah, und der zugrunde liegende Zusammenhang ist zu komplex oder zu veränderlich, um ihn in ein festes Regelwerk zu gießen.
Fehlt die Wiederholung, lohnt der Aufwand nicht – für eine Entscheidung, die dreimal im Jahr ansteht, genügt ein Mensch mit einer Tabelle. Fehlen die historischen Daten, gibt es nichts zu lernen; dann steht am Anfang ein Datenprojekt und kein KI-Projekt. Und wenn der Zusammenhang einfach und stabil ist, ist ein transparentes Regelwerk der besseren Wahl, weil es billiger im Betrieb, leichter prüfbar und im Fehlerfall reparierbar ist. Ein gut gepflegtes Regelwerk ist keine rückständige Lösung, sondern häufig die wirtschaftlich richtige.
Umgekehrt gibt es Bereiche, in denen der Verzicht auf lernende Verfahren echte Nachteile bringt: die Absatzprognose in Sortimenten mit vielen Artikeln und Aktionseinflüssen, die Erkennung von Anomalien in großen Buchungs- und Bewegungsdatenmengen, die Auswertung von Bildern in der Wareneingangs- und Qualitätsprüfung und die Extraktion von Inhalten aus unstrukturierten Dokumenten. Diese vier Felder sind der realistische Kern dessen, was KI im Mittelstand heute leisten kann – und sie sind groß genug, um sich zu lohnen.
In der Beschaffung beginnt der Nutzen bei einer unspektakulären Frage: Wann kommt die Ware wirklich an? Viele Unternehmen rechnen mit einer im Lieferantenstamm hinterlegten Wiederbeschaffungszeit, die vor Jahren einmal geschätzt wurde und seither niemand überprüft hat. Die tatsächliche Lieferzeit variiert nach Lieferant, Artikelgruppe, Bestellmenge, Saison und Route erheblich. Ein Modell, das aus den eigenen Wareneingangsdaten lernt, wie sich diese Zeiten tatsächlich verteilt haben, ist regelmäßig die günstigste Verbesserung im gesamten Beschaffungsprozess – und es braucht dafür nur Daten, die ohnehin im ERP liegen.
Daran schließt die Lieferantenbewertung an. Termintreue, Mengentreue, Qualitätsreklamationen, Antwortzeiten und Preisentwicklung ergeben zusammen ein Risikobild, das sich fortschreiben lässt. Der Anspruch sollte dabei nüchtern bleiben: Ein Modell kann aus internen Daten erkennen, welche Lieferanten sich verschlechtern, und es kann externe Signale ergänzen. Es kann jedoch nicht die Insolvenz eines Zulieferers vorhersagen, über den keine belastbaren Informationen vorliegen. Wer Risikofrüherkennung als Hellsehen verkauft, überzieht.
In der Produktion ist die Datenlage oft besser als im Handel, weil Maschinen Daten erzeugen. Zustandsorientierte Instandhaltung, Ausschussprognosen und die visuelle Qualitätsprüfung sind hier die etabliertesten Anwendungen. Der Engpass liegt selten am Verfahren, sondern an drei anderen Punkten: Sind die Sensordaten überhaupt zugänglich und mit Auftrags- und Chargendaten verknüpfbar? Existieren genügend dokumentierte Fehlerfälle, um daraus zu lernen? Und lässt sich der Prozess so eingreifen, dass eine Vorhersage überhaupt eine Handlung auslöst? Ohne diese Kette bleibt auch ein gutes Modell ein Bildschirmwert.
Ein Sonderfall ist die Reihenfolge- und Kapazitätsplanung. Sie ist im Kern eine Optimierungsaufgabe mit Rüstzeiten, Kapazitäten, Terminen und Prioritäten. Lernende Verfahren spielen dort eine unterstützende Rolle, etwa indem sie realistische Bearbeitungs- und Rüstzeiten aus der Vergangenheit schätzen, mit denen die Optimierung dann rechnet. Diese Arbeitsteilung – lernen, was gilt, und rechnen, was zu tun ist – ist ein Muster, das in der gesamten Lieferkette wiederkehrt.
Im Lager ist der am schnellsten wirksame Anwendungsfall meist nicht die Robotik, sondern die Vorhersage der Arbeitslast. Wenn abschätzbar ist, wie viele Positionen am kommenden Dienstag zu kommissionieren sind und wie sie sich über Zonen verteilen, lässt sich Personal planen, statt es kurzfristig umzuverteilen. Die dafür nötigen Daten – Auftragseingänge, Vorlaufzeiten, saisonale Muster, Kalender und Aktionen – liegen im ERP oder Lagerverwaltungssystem vor. Der Nutzen entsteht nicht im Modell, sondern in der Schicht- und Leihkräfteplanung, die es ermöglicht.
Ein zweites Feld ist die Lagerplatzvergabe. Welche Artikel gehören in die schnell erreichbare Zone, welche paarweise nahe beieinander, welche saisonal umgelagert – das ist eine Kombination aus Prognose (was wird künftig häufig gegriffen) und Optimierung (welche Zuordnung minimiert Wege unter Platz- und Gewichtsrestriktionen). Der Effekt ist real, aber er hängt an der Umlagerungsdisziplin: Eine rechnerisch optimale Zuordnung, die niemand umsetzt, verändert nichts. Auch hier gilt: Der Engpass liegt im Prozess, nicht im Verfahren.
Im Transport dominiert die Optimierung. Tourenplanung, Laderaumnutzung, Zuordnung von Sendungen zu Dienstleistern und Relationen sind Rechenprobleme mit harten Nebenbedingungen – Lenkzeiten, Zeitfenster, Fahrzeugtypen, Gefahrgut, Kundenrestriktionen. Lernende Verfahren ergänzen sie an zwei Stellen: bei der Schätzung realistischer Fahr-, Warte- und Entladezeiten und bei der Prognose der voraussichtlichen Ankunft. Beides verbessert die Qualität der Planung, ersetzt sie aber nicht. Wer im Transport mit KI beginnen will, sollte zuerst prüfen, ob die vorhandene Planung überhaupt sauber parametriert ist, und wie ein Transportmanagementsystem in die eigene Systemlandschaft passt.
Der Absatz ist im Handel und in der Konsumgüterindustrie das Feld mit dem größten Hebel, weil jede Bestell- und Produktionsentscheidung stromaufwärts auf der Absatzerwartung aufsetzt. Ein Fehler an dieser Stelle pflanzt sich durch die gesamte Kette fort und wird auf jeder Stufe verstärkt. Entsprechend lohnt es sich, hier zuerst zu investieren – allerdings mit realistischer Erwartung: Nicht jeder Artikel ist prognostizierbar. Langsamdreher mit sporadischem Absatz, Neuprodukte ohne Historie und stark aktionsgetriebene Artikel folgen unterschiedlichen Logiken und brauchen unterschiedliche Verfahren.
Eine praktikable Segmentierung ist deshalb der eigentliche Anfang jedes Prognoseprojekts. Artikel mit regelmäßigem, gut erklärbarem Verlauf lassen sich weitgehend automatisch planen. Artikel mit unregelmäßigem, sporadischem Verlauf brauchen Verfahren, die für genau diesen Fall entwickelt wurden, und häufig ein anderes Bestandsziel. Neuprodukte werden über Ähnlichkeiten zu vergleichbaren Artikeln geschätzt, mit entsprechend breiter Unsicherheit. Und Aktionsartikel hängen an Informationen, die nicht im Absatzverlauf stehen, sondern in der Aktionsplanung – wenn diese nicht strukturiert vorliegt, kann kein Verfahren sie berücksichtigen.
Im After Sales schließlich liegt eine eigene Welt. Ersatzteilbedarf ist typischerweise sporadisch, teilweise über Jahre gleich null und dann plötzlich vorhanden; klassische Glättungsverfahren führen hier systematisch in die Irre. Gleichzeitig sind die Konsequenzen asymmetrisch: Ein fehlendes Ersatzteil legt eine Anlage still, ein überschüssiges kostet nur Kapitalbindung. Die passende Antwort ist deshalb selten eine bessere Punktprognose, sondern eine Bestandspolitik, die die Kostenasymmetrie explizit abbildet. Auf der Retourenseite lassen sich Rücksendequoten je Artikel und Kanal recht gut schätzen und in die Bestandsrechnung einbeziehen – ein Punkt, der im Onlinehandel regelmäßig übersehen wird.
Die Bedarfsprognose ist der bekannteste KI-Anwendungsfall der Lieferkette und zugleich der am häufigsten falsch aufgesetzte. Der erste und größte Fehler liegt vor jedem Modell: Verkaufsdaten sind nicht Nachfragedaten. Was in der Historie steht, ist das, was verkauft wurde – nicht das, was gewollt wurde. Jede Phase, in der ein Artikel nicht verfügbar war, erzeugt eine künstliche Absatzlücke, aus der ein Modell die falsche Lehre zieht: Es lernt, dass die Nachfrage niedrig war, prognostiziert entsprechend niedrig, führt zu weniger Bestand und damit zur nächsten Lücke. Diese Rückkopplung ist der klassische Weg, mit dem sich ein Prognosesystem selbst nach unten zieht.
Die Gegenmaßnahme ist unbequem, aber ohne Alternative: Nichtverfügbarkeiten müssen in der Historie erkennbar sein und bei der Modellbildung behandelt werden. Ebenso gehören einmalige Sondereffekte markiert – Großaufträge, Aktionen, Preisänderungen, Sortimentswechsel, Kanalstarts. Ein Datensatz, in dem ein Palettenverkauf an einen Einzelkunden ununterscheidbar neben dem laufenden Kleinmengengeschäft steht, produziert dauerhaft schiefe Prognosen. Diese Bereinigungsarbeit ist der unglamouröse Teil jedes Prognoseprojekts und regelmäßig der größte Aufwandsblock.
Ist die Prognose belastbar, folgt die Bestandsoptimierung. Sie übersetzt Erwartungswert und Streuung der Nachfrage zusammen mit der Streuung der Wiederbeschaffungszeit in einen Sicherheitsbestand und eine Bestellpolitik. Genau hier zeigt sich, ob ein Unternehmen seine Ziele kennt: Ein Sicherheitsbestand ist immer eine Antwort auf die Frage, welchen Servicegrad man für welchen Artikel anstrebt und was ein Fehlbestand kostet. In vielen Betrieben ist diese Frage nie beantwortet worden; die Bestände sind historisch gewachsen. Ein Optimierungsprojekt zwingt zur Beantwortung – und darin liegt oft sein eigentlicher Wert, unabhängig vom Modell.
Realistisch ist ein weiterer Punkt: Bestandsoptimierung führt nicht überall zu weniger Bestand. Sie führt zu anders verteiltem Bestand. Typischerweise sinkt der Bestand bei gut planbaren Artikeln und steigt bei kritischen Langsamdrehern mit hohem Fehlmengenrisiko. Der Nettoeffekt kann positiv sein, muss es aber nicht – und wer das Projekt allein mit einer Bestandssenkung begründet, erzeugt eine Erwartung, die möglicherweise nicht eintritt. Die ehrlichere Begründung lautet: gleiche oder bessere Lieferfähigkeit bei bewusster statt zufälliger Kapitalbindung.
Die Prognose voraussichtlicher Ankunftszeiten hat in den letzten Jahren an Bedeutung gewonnen, weil sie zwei Interessen gleichzeitig bedient: die interne Planung und die Kundenkommunikation. Auf der Beschaffungsseite ersetzt sie die statische Wiederbeschaffungszeit im Stammsatz durch eine dynamische Schätzung, die Lieferant, Artikelgruppe, Menge, Saison und gegebenenfalls Transportweg berücksichtigt. Auf der Distributionsseite gibt sie dem Kundenservice eine belastbarere Aussage als das pauschale Lieferzeitversprechen des Shops.
Voraussetzung ist eine Datenspur, die viele Unternehmen unterschätzen. Für eine Beschaffungs-ETA genügen meist die eigenen Bestell- und Wareneingangsdaten, sofern Bestelldatum, bestätigtes Datum und tatsächliches Eingangsdatum sauber getrennt geführt werden. Für eine Sendungs-ETA braucht es Statusmeldungen der Dienstleister, und deren Qualität schwankt erheblich: unterschiedliche Statuscodes, unterschiedliche Zeitpunkte der Meldung, Lücken bei Subunternehmern. Wer hier ohne Vorprüfung startet, baut ein Modell auf Sand. Eine Transportplattform oder ein Transportmanagementsystem kann diese Vereinheitlichung übernehmen und ist damit oft die sinnvollere erste Investition.
Beim Lieferantenrisiko ist zwischen zwei Ebenen zu unterscheiden. Die erste Ebene ist intern und gut zugänglich: Wie hat sich die Termintreue eines Lieferanten über die Zeit entwickelt, häufen sich Teillieferungen, steigen Reklamationen, verlängern sich Antwortzeiten. Solche Trends lassen sich aus den eigenen Daten erkennen und liefern belastbare Frühwarnungen, weil sich Probleme in der Regel ankündigen. Die zweite Ebene ist extern: Bonitätsinformationen, Nachrichtenlage, Standortrisiken, geopolitische Einflüsse. Hier existieren Datenanbieter, die Informationen aufbereiten – die Qualität variiert, die Abdeckung kleiner Zulieferer ist häufig dünn, und für die Verarbeitung personenbezogener Angaben gelten eigene Anforderungen.
Entscheidend ist bei beiden Ebenen dasselbe: Ein Risikosignal ohne hinterlegte Reaktion ist wertlos. Bevor ein Frühwarnsystem eingeführt wird, sollte festgelegt sein, was bei welcher Signalstärke geschieht – Gespräch mit dem Lieferanten, Erhöhung des Sicherheitsbestands, Aktivierung einer Zweitquelle, Vorziehen von Bestellungen. Ohne diese Zuordnung entsteht ein weiteres Dashboard, das nach einigen Wochen niemand mehr öffnet.
Die Analyse von Preisen und Konditionen ist ein Anwendungsfall, der selten unter dem KI-Etikett läuft, aber regelmäßig schnellen Nutzen bringt. Der Kern ist Anomalieerkennung auf Belegpositionen: Weicht ein berechneter Einkaufspreis von der Vereinbarung ab, wurde eine Staffel nicht angewendet, fehlt ein Bonus, taucht ein Zuschlag auf, der nicht vereinbart war, weicht eine Frachtrechnung vom Tarif ab? In Unternehmen mit vielen Belegpositionen sind solche Abweichungen praktisch unvermeidlich, und die manuelle Prüfung ist zu aufwendig, um sie flächendeckend zu leisten.
Die Hürde liegt fast nie im Verfahren, sondern in der Datenlage: Konditionen, Staffeln, Boni und Frachttarife existieren in vielen Betrieben als Dokumente in einem Ordner oder als Wissen einzelner Einkäufer, nicht als strukturierte, maschinell prüfbare Regelwerke. Ohne diese Strukturierung fehlt der Sollwert, gegen den geprüft werden kann. Ein sinnvoller Einstieg besteht deshalb darin, zunächst die wichtigsten Lieferanten- und Frachtvereinbarungen strukturiert zu erfassen – ein Schritt, der auch ohne jede KI Nutzen bringt und ihn erst ermöglicht.
Die visuelle Qualitätsprüfung ist die reifste Bilderkennungsanwendung in der Lieferkette. Sie kommt in zwei Ausprägungen vor: als Prüfung im Wareneingang und Versand, wo Beschädigungen, falsche Artikel, fehlende Teile oder unvollständige Paletten erkannt werden, und als Prüfung in der Fertigung, wo Oberflächen, Maße und Vollständigkeit kontrolliert werden. Technisch ist das Verfahren etabliert; der Erfolg hängt an drei praktischen Bedingungen.
Bemerkenswert ist, dass diese drei Bedingungen technikfern sind. Sie betreffen den Arbeitsplatz, die Dokumentationsdisziplin und die Prozessregel. Das ist kein Zufall, sondern das durchgehende Muster dieses Kapitels: Der begrenzende Faktor in KI-Projekten der Lieferkette ist fast nie das Modell.
Die Lieferkette ist voller unstrukturierter Kommunikation. Auftragsbestätigungen kommen als PDF, Lieferavise als E-Mail-Text, Frachtdokumente als Scan, Reklamationen als Freitext, Ausschreibungsunterlagen als Dokumentensammlung, Zollpapiere in unterschiedlichen Formaten. Ein erheblicher Teil der Arbeitszeit in diesen Abteilungen besteht darin, Informationen aus solchen Dokumenten zu lesen, zu bewerten und in ein System zu übertragen. Genau dort setzen Sprachmodelle an – nicht als Ersatz des Sachbearbeiters, sondern als Vorstufe, die den Rohstoff aufbereitet.
Der belastbarste Anwendungsfall ist die Dokumentenverarbeitung. Aus einer Auftragsbestätigung werden Positionen, Mengen, Preise und Termine extrahiert und gegen die eigene Bestellung abgeglichen; Abweichungen werden markiert, Übereinstimmungen können automatisch verbucht werden. Der Unterschied zu klassischer Belegerkennung liegt in der Robustheit gegenüber Formatvielfalt: Wo früher jedes Lieferantenlayout eine eigene Vorlage brauchte, kommen moderne Verfahren mit unbekannten Layouts deutlich besser zurecht. Das ist für Mittelständler mit hunderten Lieferanten und ebenso vielen Belegformen der entscheidende Fortschritt.
Der zweite Bereich ist die Unterstützung bei Ausschreibungen und Verträgen. Sprachmodelle können Ausschreibungsunterlagen zusammenfassen, Anforderungen extrahieren, Angebote strukturiert gegenüberstellen und auf fehlende Angaben hinweisen. Ebenso können sie Rahmenverträge nach Fristen, Kündigungsregelungen, Preisanpassungsklauseln und Haftungsgrenzen durchsuchen. Die Entlastung ist erheblich, weil es sich um Lesearbeit in großem Umfang handelt. Die Bewertung selbst bleibt beim Menschen – ein Modell kennt weder die strategische Bedeutung eines Lieferanten noch die Vorgeschichte einer Verhandlung.
Der dritte Bereich ist die Vorklassifikation und Vorformulierung in der Kommunikation. Eingehende Reklamationen, Statusanfragen und Störmeldungen lassen sich nach Art, Dringlichkeit und Zuständigkeit sortieren, mit dem passenden Vorgang verknüpfen und mit einem Antwortentwurf versehen. Der Gewinn liegt in der Vorsortierung und im ersten Entwurf, nicht im automatischen Versand. Wer generative KI unbeaufsichtigt mit Kunden kommunizieren lässt, riskiert Zusagen, die niemand geprüft hat – im Logistikkontext betrifft das häufig Liefertermine und Kulanz, also genau die Punkte, die Geld kosten.
Der vierte Bereich ist der Zugang zu den eigenen Daten in natürlicher Sprache. Ein Assistent, der auf Nachfrage erklärt, welche Sendungen heute kritisch sind, welche Aufträge ohne Bestandsdeckung offen stehen oder wie sich die Termintreue eines Lieferanten entwickelt hat, senkt die Schwelle zu Auswertungen erheblich. Wichtig ist die Architektur dahinter: Belastbar wird ein solcher Assistent nur, wenn er nicht frei antwortet, sondern definierte Abfragen gegen geprüfte Datenquellen ausführt und deren Ergebnis in Sprache übersetzt. Die Zahl muss aus dem System kommen, nicht aus dem Modell.
Unter Agenten versteht man Systeme, die nicht nur antworten, sondern mehrstufig handeln: Sie lesen eine Anfrage, rufen Systeme auf, treffen Zwischenentscheidungen und lösen Aktionen aus. Für die Lieferkette wird das häufig als Control Tower beschrieben, in dem ein Assistent Störungen erkennt, Optionen bewertet und Maßnahmen einleitet. Das Bild ist attraktiv, weil es die Zersplitterung der Systemlandschaft überbrückt. Die Realität in mittelständischen Umgebungen ist zurückhaltender einzuschätzen.
Drei Gründe sprechen für Vorsicht. Erstens summieren sich Fehler über mehrere Schritte: Wenn jeder Einzelschritt weitgehend zuverlässig ist, ist eine lange Kette es nicht mehr. Zweitens sind schreibende Zugriffe in Warenwirtschafts- und Lagersystemen folgenreich und schwer zurückzunehmen; eine fälschlich ausgelöste Umlagerung oder Bestellung erzeugt echten Aufwand. Drittens fehlt in vielen Fällen die saubere Schnittstellenlage, die ein Agent voraussetzt – wo Menschen zwischen Systemen manuell übertragen, kann auch ein Agent nur manuell übertragen.
Der praktikable Zuschnitt ist deshalb enger. Agentische Abläufe funktionieren gut, wenn sie lesend arbeiten, ein klar umgrenztes Ziel verfolgen und ihr Ergebnis einem Menschen zur Freigabe vorlegen: Informationen aus mehreren Systemen zu einem Vorgang zusammentragen, eine Abweichung aufbereiten, einen Vorschlag mit Begründung erzeugen. Schreibende Aktionen sollten auf eng definierte, reversible und protokollierte Vorgänge beschränkt bleiben, mit Wertgrenzen und Eskalationsregeln. So gebaut, ist der Nutzen real und das Risiko beherrschbar.
Sprachmodelle erzeugen plausiblen Text, nicht geprüfte Wahrheit. Sie können Werte erfinden, die richtig aussehen, Zusammenhänge behaupten, die nicht bestehen, und Angaben aus einem Dokument mit Angaben aus einem anderen vermischen. Im Logistikkontext ist das besonders heikel, weil Ergebnisse häufig Zahlen sind: Mengen, Termine, Preise, Gewichte. Eine falsche Zahl fällt weniger auf als ein falscher Satz, hat aber unmittelbare Folgen in der Buchung.
Die Gegenmaßnahmen sind bekannt und wirksam, wenn man sie konsequent anwendet. Erstens: Bezug auf Quellen. Jede extrahierte Angabe sollte auf die Stelle im Ausgangsdokument verweisen, aus der sie stammt, damit eine Prüfung in Sekunden möglich ist. Zweitens: rechnerische Gegenprüfung im Zielsystem statt im Modell – Summen, Positionsabgleiche und Plausibilitäten gehören in die Anwendung. Drittens: Schwellenwerte für automatische Verarbeitung. Belege unterhalb einer Wert- und Abweichungsgrenze laufen durch, alles darüber geht in die Prüfung. Viertens: Stichprobenkontrolle im laufenden Betrieb, nicht nur in der Einführungsphase.
Hinzu kommt eine organisatorische Regel, die sich bewährt hat: Für alle Vorgänge mit finanzieller oder vertraglicher Wirkung bleibt der Vier-Augen-Grundsatz bestehen, unabhängig davon, wie gut das System arbeitet. Das ist keine Misstrauenserklärung gegenüber der Technik, sondern die Fortschreibung eines Prinzips, das auch für menschliche Sachbearbeitung gilt. Wer diesen Grundsatz mit dem Argument aushebelt, die KI mache ohnehin keine Fehler, hat die Funktionsweise der Technik nicht verstanden.
Ein letzter Punkt betrifft die Frage, wohin die Daten fließen. Dokumente aus der Lieferkette enthalten Geschäftsgeheimnisse: Einkaufspreise, Konditionen, Kundennamen, Mengengerüste, teils personenbezogene Angaben von Ansprechpartnern und Fahrern. Wird ein Modell eines Anbieters außerhalb der EU genutzt, ist zu klären, in welcher Region verarbeitet wird, ob Eingaben zum Training verwendet werden, wie lange sie gespeichert bleiben und welche Unterauftragnehmer beteiligt sind. Viele Anbieter stellen inzwischen EU-Regionen bereit; daneben existieren europäische Anbieter und die Möglichkeit, offene Modelle im eigenen Rechenzentrum oder bei einem europäischen Hoster selbst zu betreiben. Für Dokumente mit hoher Vertraulichkeit ist die selbst betriebene oder EU-regionale Variante der datenschutzfreundlichere Weg.
Die nüchterne Erfahrung aus Projekten lautet: Der überwiegende Teil des Aufwands entfällt auf Beschaffung, Verknüpfung, Bereinigung und Plausibilisierung von Daten. Wer eine Zeitplanung aufstellt, in der die Modellentwicklung den größten Block einnimmt, hat noch nicht in die Daten geschaut. Das ist keine Aussage über Ineffizienz, sondern über die Natur der Aufgabe: Betriebliche Daten sind für den laufenden Betrieb erfasst worden, nicht für die Auswertung – und diese beiden Zwecke stellen unterschiedliche Anforderungen.
Stammdaten wirken unspektakulär, bestimmen aber, ob Auswertungen überhaupt sinnvoll aggregierbar sind. Für die Lieferkette sind vor allem vier Bereiche relevant. Erstens der Artikelstamm mit einer eindeutigen Identifikation, einer belastbaren Warengruppen- oder Sortimentshierarchie, Mengeneinheiten und Umrechnungen, physischen Attributen wie Gewicht und Maßen sowie Angaben zu Nachfolge- und Vorgängerartikeln. Fehlt die Nachfolgebeziehung, zerfällt die Historie eines Produkts bei jedem Artikelwechsel in unzusammenhängende Fragmente – und die Prognose beginnt jedes Mal bei null.
Zweitens der Lieferanten- und Bezugsquellenstamm mit Wiederbeschaffungszeiten, Mindestbestellmengen, Verpackungseinheiten, Lieferrhythmen und der Zuordnung, welcher Artikel über welche Quelle bezogen wird. Diese Angaben sind die Nebenbedingungen jeder Bestelloptimierung. Sind sie veraltet, rechnet auch ein hervorragendes Verfahren Bestellvorschläge aus, die der Einkauf anschließend von Hand korrigiert – womit der Nutzen verschwindet.
Drittens die Standort- und Lagerstruktur: Welche Lager gibt es, welche Bestände zählen für welchen Kanal, wie sind Lagerorte gegliedert, welche Bestände sind gesperrt, in Prüfung oder als Kommissionsware Dritter geführt. Viertens die Kalenderdaten: Betriebs- und Schließtage, Feiertage je Region, Schulferien, Werksferien der Lieferanten, Zeitzonen bei internationalen Lieferketten. Kalenderdaten sind einer der wirksamsten und zugleich am häufigsten fehlenden Bausteine in Prognosemodellen – Nachfrage folgt Kalendern.
Ein oft übersehener Punkt ist die Frage der historischen Gültigkeit. Stammdaten ändern sich, und für eine Auswertung ist regelmäßig entscheidend, welcher Wert zum damaligen Zeitpunkt galt – welcher Lieferant damals belieferte, welche Warengruppe damals zugeordnet war, welcher Preis galt. Systeme, die Stammdaten überschreiben statt zu historisieren, machen bestimmte Analysen dauerhaft unmöglich. Diese Frage sollte man früh stellen, weil sie sich nachträglich nicht mehr beantworten lässt.
Bei den Bewegungsdaten geht es um Aufträge, Lieferungen, Wareneingänge, Bestandsbewegungen, Rechnungen und Retouren. Sie liegen in aller Regel vor, aber vier Fragen entscheiden über ihre Brauchbarkeit. Die erste ist die Historientiefe: Für saisonale Muster braucht es mehrere vollständige Jahreszyklen; wer nur ein Jahr hat, kann Saison und Trend nicht sauber trennen. Systemwechsel, bei denen die Historie nicht übernommen wurde, sind hier ein häufiges und teures Hindernis.
Die zweite ist die Granularität. Für die Disposition sind Tages- oder Wochenwerte je Artikel und Standort nötig; monatlich aggregierte Zahlen genügen für Berichte, nicht für Planung. Die dritte ist die Bereinigung von Sondereffekten: Nichtverfügbarkeiten, Aktionen, Großaufträge, Testbestellungen, Storni, Umbuchungen und interne Verrechnungen müssen erkennbar und trennbar sein. Die vierte ist die Konsistenz über Systemgrenzen: Wenn der Umsatz im Vertriebsbericht, in der Warenwirtschaft und im Auswertungssystem drei verschiedene Zahlen liefert, wird die erste Projektsitzung mit der Klärung dieser Differenz verbracht – und das ist gut investierte Zeit, weil ungeklärte Differenzen später jedes Ergebnis in Zweifel ziehen.
Besondere Aufmerksamkeit verdient die Unterscheidung von Auftrags-, Liefer- und Rechnungsdatum. Für die Nachfrageanalyse zählt, wann der Kunde bestellt hat, nicht wann fakturiert wurde. Für die Lieferzeitanalyse zählt die Spanne zwischen Bestellung und Wareneingang, nicht die Spanne bis zur Rechnungsprüfung. Diese Unterscheidungen wirken pedantisch, verschieben aber Ergebnisse systematisch, wenn man sie ignoriert – besonders um Monats- und Jahreswechsel herum.
Externe Daten können Prognosen verbessern, werden aber häufig überschätzt. Die praktisch nützlichsten sind unspektakulär: Kalender und Feiertage, Wetterdaten bei witterungsabhängigen Sortimenten, Preis- und Wettbewerbsinformationen im Handel, Rohstoff- und Frachtratenindizes in der Beschaffung sowie Verkehrs- und Störungsinformationen im Transport. Aufwendiger und unsicherer sind makroökonomische Indikatoren, Stimmungsindizes und Nachrichtenanalysen; sie liefern in mittelständischen Anwendungen selten den Beitrag, der ihren Integrationsaufwand rechtfertigt.
Bei jeder externen Quelle sind drei Punkte zu klären, bevor man sie einbindet. Erstens die Verfügbarkeit im Prognosezeitpunkt: Ein Signal nützt nur, wenn es zum Zeitpunkt der Entscheidung bereits vorliegt – eine Wettervorhersage für nächste Woche ist verwertbar, eine rückblickende Messung nicht. Zweitens die Stabilität der Quelle: Ändert der Anbieter Format, Umfang oder Lizenzbedingungen, bricht das Modell im laufenden Betrieb. Drittens die rechtliche Seite: Nutzungsrechte, Weiterverarbeitung und gegebenenfalls Personenbezug.
Für die Integration hat sich ein einfaches Zielbild bewährt: eine zentrale, regelmäßig aktualisierte Auswertungsschicht, in der Daten aus ERP, Lagerverwaltung, Transportmanagement, Shop- und Kanalsystemen sowie externen Quellen zusammenlaufen und in einheitlicher Struktur bereitstehen. Ob das ein Data Warehouse, ein Data Lakehouse oder eine schlankere Datenbank ist, hängt von Volumen und Anspruch ab; die Bauform ist zweitrangig. Entscheidend sind vier Eigenschaften: Die Daten sind reproduzierbar erzeugt, ihre Herkunft ist nachvollziehbar, die Aktualisierung ist überwacht, und Kennzahlendefinitionen sind an einer Stelle festgelegt statt in jedem Bericht neu erfunden.
Ein Nebeneffekt ist bemerkenswert: Diese Auswertungsschicht ist auch ohne KI wertvoll. Sie verbessert Berichtswesen und Controlling, macht Kennzahlen vergleichbar und schafft die Grundlage für Automatisierung jeder Art. Wer die Investition allein mit einem KI-Anwendungsfall begründet, verkauft sie unter Wert – und riskiert, dass sie mit dem Anwendungsfall in Frage gestellt wird.
Die Bordmittel im ERP oder Warenwirtschaftssystem sind der naheliegendste Einstieg. Die Daten liegen bereits im System, es entsteht keine zusätzliche Schnittstelle, Berechtigungen und Betrieb sind geregelt, und im Störungsfall gibt es einen Ansprechpartner. Viele Systeme haben in den letzten Jahren Prognose- und Dispositionsfunktionen ausgebaut oder ergänzende Module vorgesehen. Die Grenze liegt üblicherweise in der Tiefe: Verfahrenswahl, Parametrierung, Umgang mit Sonderfällen und Transparenz über die Rechnung sind weniger ausgeprägt als bei spezialisierten Werkzeugen. Für einen Betrieb mit überschaubarem Sortiment ist das häufig ausreichend – und die Empfehlung lautet dann klar, hier zu beginnen, bevor eine zusätzliche Lösung eingeführt wird.
Die spezialisierten Planungsanbieter bringen fachliche Tiefe mit. Sie unterscheiden Verfahren nach Artikelverhalten, behandeln sporadische Bedarfe gesondert, rechnen Sicherheitsbestände auf Basis von Streuungen, bilden Mehrstufigkeit ab und liefern in der Regel einen ausgearbeiteten Planungsprozess mit. Der Preis dafür ist eine zusätzliche Lizenz, eine Integration in die bestehende Landschaft und ein Einführungsprojekt, das Fachwissen im eigenen Haus verlangt. Diese Anbieter sind dort im Vorteil, wo Planung eine eigene Funktion mit eigenen Rollen ist – nicht dort, wo sie nebenbei erledigt wird.
Die Netzwerk- und Plattformanbieter haben einen anderen Ausgangspunkt: Sie verbinden Unternehmen mit ihren Partnern – Lieferanten, Frachtführern, Dienstleistern – und gewinnen ihren Vorteil aus Daten, die über die Grenzen des einzelnen Unternehmens hinausreichen. Für Ankunftszeitprognosen, Transportvergaben und Beschaffungskommunikation ist das ein struktureller Vorteil, weil ein einzelnes Unternehmen diese Datenlage nicht herstellen kann. Zu klären ist im Gegenzug, welche eigenen Daten in das Netzwerk fließen, wie sie genutzt werden, wie leicht ein Wechsel möglich bleibt und ob die eigenen Partner überhaupt teilnehmen – ohne Beteiligung der Partner bleibt der Netzwerkvorteil theoretisch.
Die Eigenentwicklung auf Cloud-Diensten schließlich nutzt allgemein verfügbare Bausteine – Datenplattformen, Bibliotheken für maschinelles Lernen, Modell-Endpunkte – und baut daraus eine passgenaue Lösung. Der Vorteil ist maximale Anpassung an die eigene Fragestellung und volle Kontrolle über Daten und Verfahren. Der Nachteil wird regelmäßig unterschätzt: Ein Modell ist keine einmalige Lieferung, sondern ein Betriebsgegenstand mit Überwachung, Aktualisierung, Dokumentation und Nachfolgeregelung. Wer diesen Weg geht, braucht dauerhaft Personen, die ihn tragen – und einen Plan für den Fall, dass diese Personen das Unternehmen verlassen.
Die Entscheidung zwischen Kaufen und Selbstbauen wird oft als Kostenfrage geführt und ist in Wahrheit eine Frage der Wiederholbarkeit. Standardaufgaben, die viele Unternehmen ähnlich lösen – Absatzprognose, Sicherheitsbestandsrechnung, Belegextraktion, Tourenplanung –, sind in Standardprodukten besser aufgehoben, weil dort die Erfahrung vieler Anwender eingeflossen ist und die Weiterentwicklung nicht am eigenen Budget hängt. Aufgaben, die aus der Besonderheit des eigenen Geschäftsmodells entstehen und für die kein Markt existiert, sind Kandidaten für Eigenentwicklung.
Eine pragmatische Zwischenform hat sich bewährt: Standardprodukte für die Kernverfahren, ergänzt um eigene Vor- und Nachverarbeitung. Die Datenaufbereitung bleibt im eigenen Haus, weil sie die eigene Fachlogik enthält; die Verfahren kommen aus dem Produkt; die Übersetzung des Ergebnisses in die eigene Entscheidungsregel wiederum liegt intern. Diese Aufteilung hält die Abhängigkeit begrenzt und den Betriebsaufwand beherrschbar.
Unabhängig vom Weg gehören drei Architekturprinzipien früh festgelegt. Erstens die Datenhoheit: Die eigenen Daten müssen jederzeit vollständig und in verwertbarer Struktur exportierbar sein – vertraglich zugesichert, nicht nur technisch möglich. Zweitens die Trennung von Datenschicht und Anwendung: Wenn die aufbereiteten Daten in einer eigenen Schicht liegen, ist ein Anbieterwechsel eine Integrationsaufgabe und kein Neuanfang. Drittens die Protokollierung: Welche Version eines Verfahrens hat wann welches Ergebnis erzeugt, auf welcher Datengrundlage. Das ist keine Bürokratie, sondern die Voraussetzung dafür, Abweichungen später überhaupt erklären zu können – und je nach Anwendungsfall auch eine regulatorische Anforderung.
Anbieterpräsentationen zu KI folgen einem erkennbaren Muster: eine beeindruckende Oberfläche, ein Referenzfall aus einer anderen Branche und Kennzahlen ohne nachvollziehbare Herleitung. Fünf Fragen helfen, die Substanz dahinter zu prüfen.
Die letzte Frage verdient eine Ergänzung. Viele KI-Funktionen in Standardsoftware nutzen im Hintergrund Dienste großer, überwiegend nicht europäischer Anbieter. Das ist kein Ausschlusskriterium, aber es ist eine Tatsache, die im Auswahlprozess offengelegt und bewertet werden muss. Zu prüfen sind die verfügbare Verarbeitungsregion, die Möglichkeit, die Verarbeitung auf EU-Rechenzentren zu beschränken, sowie die vertragliche Zusicherung, dass Eingaben nicht für das Training allgemeiner Modelle verwendet werden. Für Unternehmen mit erhöhten Anforderungen an Vertraulichkeit oder Souveränität bleiben europäische Anbieter und der Eigenbetrieb offener Modelle die datenschutzfreundlicheren Alternativen – mit dem bekannten Preis, nämlich höherem eigenem Betriebsaufwand.
Die Sammlung von Anwendungsfällen sollte nicht in der IT beginnen, sondern in den Fachbereichen – und zwar mit einer Frage, die nicht nach Technologie klingt: Welche wiederkehrenden Einschätzungen kosten heute viel Zeit oder gehen häufig daneben? Aus den Antworten entsteht eine Liste, die anschließend nach vier Kriterien bewertet wird: erwarteter Nutzen, Datenlage, technische und organisatorische Umsetzbarkeit sowie laufender Betriebsaufwand. Die letzten beiden Kriterien werden regelmäßig vergessen, entscheiden aber darüber, ob eine Lösung nach einem Jahr noch läuft.
Für die Priorisierung gilt eine einfache Regel: Der erste Anwendungsfall soll nicht der wertvollste sein, sondern der lehrreichste bei überschaubarem Risiko. Er soll die Organisation durch den vollständigen Zyklus führen – Datenbeschaffung, Bewertung, Einführung, Betrieb – und dabei sichtbaren, aber begrenzten Nutzen stiften. Wer mit dem größten Vorhaben beginnt, bindet Kapazität über Monate, bevor irgendjemand ein Ergebnis gesehen hat, und riskiert, dass die Unterstützung im Haus verloren geht, bevor die erste Auswertung vorliegt.
Ebenso wichtig ist es, Kandidaten aktiv auszusortieren. Anwendungsfälle ohne verfügbare Historie, ohne definierte Entscheidung dahinter oder mit zu geringer Wiederholungshäufigkeit gehören dokumentiert abgelehnt – mit Begründung, damit sie nicht in sechs Monaten erneut auf der Liste stehen. Eine gepflegte Ablehnungsliste ist eines der nützlichsten Dokumente eines Digitalisierungsprogramms.
Die häufigste methodische Schwäche in Pilotprojekten ist ein Vergleich gegen nichts. Ein Modell liefert Zahlen, die Zahlen sehen plausibel aus, das Projekt gilt als Erfolg. Belastbar wird die Bewertung erst durch einen Vergleichsmaßstab, und der sollte bewusst anspruchslos gewählt sein: das heute eingesetzte Verfahren, eine einfache Regel wie der Vorjahreswert oder der Durchschnitt der letzten Wochen, oder die Einschätzung des Disponenten. Wenn ein aufwendiges Verfahren diese einfachen Vergleiche nicht deutlich schlägt, ist das ein wichtiges Ergebnis – und spart die Einführung.
Bei der Rückrechnung ist die zeitliche Trennung zwingend. Trainiert wird auf einem früheren Zeitraum, bewertet auf einem späteren, und in die Trainingsdaten darf keine Information einfließen, die zum damaligen Entscheidungszeitpunkt nicht vorlag. Dieser Fehler – im Fachjargon als Informationsvorgriff bezeichnet – ist der zuverlässigste Weg zu großartigen Testergebnissen und enttäuschendem Produktivbetrieb. Er tritt in der Praxis oft unauffällig auf, etwa wenn ein Feld nachträglich gepflegt wurde oder Stammdaten in ihrem heutigen statt ihrem damaligen Stand verwendet werden.
Der Schattenbetrieb ist der ehrlichste Test. Das System rechnet über mehrere Planungszyklen produktiv mit, seine Ergebnisse werden protokolliert, aber nicht umgesetzt. Anschließend wird verglichen: Wo hätte das System besser entschieden, wo schlechter, und in welchen Fällen? Diese Auswertung ist doppelt wertvoll, weil sie neben der Qualität auch die Fehlerarten sichtbar macht – und weil sie die Fachabteilung von Beginn an einbezieht, statt ihr am Ende ein fertiges System vorzusetzen.
Ein Modell ist kein Projektergebnis, sondern ein Betriebsgegenstand. Es altert, weil sich die Welt ändert: Sortimente wechseln, Lieferanten kommen und gehen, Kundenverhalten verschiebt sich, Prozesse werden angepasst. Diese schleichende Veränderung – üblicherweise als Drift bezeichnet – führt dazu, dass ein Modell ohne Pflege langsam schlechter wird, ohne dass eine Fehlermeldung erscheint. Genau das macht sie gefährlich: Ein technischer Ausfall fällt sofort auf, eine schleichende Qualitätsverschlechterung nicht.
Der Betrieb lernender Systeme braucht deshalb dieselbe Sorgfalt wie andere geschäftskritische Anwendungen, ergänzt um einige Besonderheiten. Zu überwachen sind nicht nur Verfügbarkeit und Laufzeiten, sondern auch die Eingangsdaten (Vollständigkeit, Wertebereiche, Anteil fehlender Werte) und die Ergebnisqualität im Zeitverlauf. Es braucht definierte Aktualisierungszyklen, eine Versionierung von Modell, Daten und Parametern, die Möglichkeit, auf eine frühere Version zurückzugehen, und eine Dokumentation, die verständlich macht, was das System tut, mit welchen Daten und mit welchen bekannten Schwächen.
Auf der Rollenseite braucht es weniger Personal als oft angenommen, aber klar zugeordnete Verantwortung. Vier Rollen sollten besetzt sein, teilweise in Personalunion: eine fachliche Verantwortung, die entscheidet, ob ein Ergebnis fachlich sinnvoll ist; eine datentechnische Verantwortung für Bereitstellung und Qualität; eine methodische Verantwortung für Verfahren und Bewertung; und eine betriebliche Verantwortung für Lauffähigkeit und Überwachung. Im Mittelstand liegen diese Rollen häufig bei zwei Personen plus einem Dienstleister – das funktioniert, solange die Zuständigkeiten schriftlich festgehalten und Vertretungen geregelt sind.
Der am meisten unterschätzte Erfolgsfaktor ist die Akzeptanz derjenigen, die täglich mit den Ergebnissen arbeiten. Disponenten und Planer haben oft jahrelange Erfahrung und wissen Dinge, die in keinem Datenfeld stehen: dass ein Kunde regelmäßig zu viel bestellt und storniert, dass ein Lieferant im August faktisch nicht liefert, dass ein Artikel demnächst ausläuft. Wird ihnen ein System vorgesetzt, das ihre Erfahrung ignoriert, entsteht nicht Widerstand, sondern etwas Schlimmeres: stille Umgehung. Vorschläge werden pauschal überschrieben, und das System läuft formal, ohne zu wirken.
Wirksam sind vier Maßnahmen. Erstens frühe Beteiligung: Wer den Schattenbetrieb mit auswertet, entwickelt ein realistisches Bild von Stärken und Schwächen. Zweitens Erklärbarkeit: Ein Vorschlag, dessen wichtigste Einflussgrößen sichtbar sind, wird geprüft; eine Zahl ohne Begründung wird ignoriert oder blind übernommen – beides ist schlecht. Drittens ein geregelter Abweichungsweg: Anwender müssen abweichen können, und die Begründung sollte erfasst werden. Diese Begründungen sind die wertvollste Rückmeldung überhaupt, weil sie systematische Lücken des Modells offenlegen. Viertens Entlastung statt Kontrolle: Das Ziel ist, Routinefälle abzunehmen, damit mehr Zeit für Ausnahmen bleibt.
Diese Botschaft muss auch tatsächlich stimmen. Wenn ein KI-Projekt in Wahrheit als Personalabbauprogramm gedacht ist, wird das im Haus früher bemerkt, als es die Projektleitung wahrhaben will, und die Mitarbeit endet. Umgekehrt gilt: In den meisten mittelständischen Betrieben ist der Engpass nicht zu viel Personal, sondern zu wenig – die entlastete Zeit fließt in Aufgaben, die bislang liegen bleiben. Wer das offen so benennt, hat die Diskussion in der Regel gewonnen.
Ein guter Einstieg erfüllt vier Bedingungen: Er nutzt Daten, die bereits vorhanden sind, er betrifft eine Entscheidung, die häufig getroffen wird, er ist auf einen Bereich begrenzbar, und sein Ergebnis ist innerhalb weniger Monate bewertbar. Drei Szenarien erfüllen diese Bedingungen besonders zuverlässig.
Erstes Szenario: Prognose und Disposition für das Kernsortiment. Nicht für alle Artikel, sondern für den planbaren Teil – jene Artikel, die regelmäßig laufen und einen wesentlichen Teil von Umsatz und Kapitalbindung ausmachen. Die Daten liegen im ERP, der Nutzen zeigt sich in Lieferfähigkeit und Bestandsstruktur, und der Bereich lässt sich klar abgrenzen. Wichtig ist, gleichzeitig die Bestellregel zu überarbeiten, sonst bleibt die bessere Prognose folgenlos.
Zweites Szenario: Dokumentenverarbeitung im Einkauf. Auftragsbestätigungen und Lieferavise werden extrahiert und automatisch gegen die Bestellung geprüft; Übereinstimmungen laufen durch, Abweichungen gehen in eine Klärungsliste. Der Nutzen ist unmittelbar spürbar, weil er Arbeitszeit ersetzt, die heute jeder Sachbearbeiter kennt. Der Aufwand ist überschaubar, und das Ergebnis ist leicht messbar: Anteil automatisch verarbeiteter Belege und Zahl der Klärungsfälle.
Drittes Szenario: Wareneingangs- und Versandprüfung per Bild. Voraussetzung ist ein Arbeitsplatz mit stabilen Aufnahmebedingungen. Der Einstieg gelingt am ehesten bei häufigen, gut sichtbaren Fehlerbildern – Transportschäden, offensichtliche Fehlteile, falsche Artikel. Auch hier gilt: Zunächst sammeln und dokumentieren, dann automatisieren. Wer sechs Monate lang systematisch Fehlerfälle fotografiert und ablegt, hat die Grundlage geschaffen, die später alles Weitere ermöglicht.
Ausdrücklich nicht zu empfehlen sind für den Einstieg Vorhaben, die mehrere Systeme gleichzeitig verändern, die von der Datenlieferung externer Partner abhängen, oder die eine autonome Entscheidung ohne menschliche Freigabe vorsehen. Alle drei sind machbar, aber keiner davon eignet sich als erstes Projekt in einer Organisation, die noch keine Erfahrung mit dem Betrieb solcher Lösungen hat.
Für Betriebe ohne eigenes Datenteam ist die Antwort in der Regel eindeutig: kaufen, wo es Standard gibt, und die eigene Energie in Datenqualität und Prozessgestaltung stecken. Der Grund ist nicht mangelndes Zutrauen, sondern die Betriebsfrage. Eine selbst gebaute Lösung, die von einer einzelnen Person getragen wird, ist ein Risiko, das viele Betriebe unterschätzen – bis diese Person kündigt, längere Zeit ausfällt oder in ein anderes Projekt wechselt.
Sinnvoll ist Eigenentwicklung dort, wo eine Aufgabe aus der Besonderheit des eigenen Geschäftsmodells entsteht und kein Markt dafür existiert, und wo gleichzeitig die nötige Kompetenz dauerhaft im Haus ist oder über einen verlässlichen Partner mit vertraglich geregelter Verfügbarkeit abgesichert wird. Auch dann gilt: klein anfangen, dokumentieren, Übergabefähigkeit von Beginn an mitdenken. Eine Lösung, die niemand außer ihrem Autor versteht, ist keine Lösung, sondern eine spätere Altlast.
Eine dritte Variante wird häufig übersehen: Vieles, was als KI-Bedarf formuliert wird, lässt sich mit besserer Nutzung vorhandener Systeme lösen. Bevor eine zusätzliche Software eingeführt wird, lohnt die Prüfung, ob die Dispositionsparameter im ERP überhaupt gepflegt sind, ob vorhandene Prognosefunktionen genutzt werden, ob Auswertungen existieren, die niemand kennt. Diese Prüfung kostet wenige Tage und beendet manches KI-Projekt, bevor es beginnt – zugunsten einer schnelleren und billigeren Verbesserung.
In der Praxis werden Vorhaben oft nach ihrer Sichtbarkeit ausgewählt: Ein Assistent mit Chatoberfläche wirkt eindrucksvoller als eine überarbeitete Sicherheitsbestandsrechnung. Wirtschaftlich verhält es sich meist umgekehrt. Für die Priorisierung eignen sich drei Fragen: Wie oft wird die betroffene Entscheidung getroffen? Wie groß ist der finanzielle Effekt einer Verbesserung je Entscheidung? Und wie hoch ist der Aufwand, bis die Verbesserung wirkt?
Aus diesen drei Größen ergibt sich eine belastbare Rangfolge, die häufig überrascht. Entscheidungen mit kleinem Einzeleffekt, aber sehr hoher Häufigkeit – Bestellvorschläge, Belegprüfungen, Zuordnungen – summieren sich zu erheblichen Beträgen. Entscheidungen mit großem Einzeleffekt und geringer Häufigkeit – Standortwahl, Lieferantenstrategie – sind wichtig, aber keine Automatisierungskandidaten; sie profitieren von besseren Auswertungen, nicht von Modellen.
Ein letzter Hinweis zur Erwartungshaltung: Der Nutzen zeigt sich in der Lieferkette selten schlagartig, sondern über Zyklen. Eine verbesserte Disposition wirkt erst, wenn die Wiederbeschaffungszeiten durchlaufen sind; eine bessere Prognose zeigt sich über eine Saison. Wer nach vier Wochen eine Bilanz zieht, misst Rauschen. Sinnvoll ist es, den Bewertungszeitraum vorab festzulegen – abgeleitet vom Rhythmus des eigenen Geschäfts – und in dieser Zeit auf die Fehlerarten zu schauen statt auf den Gesamteffekt.
Der sichtbare Block ist die Software: Lizenz oder Abonnement für ein Planungswerkzeug, ein Modul im ERP, eine Dokumentenverarbeitung oder die Nutzung von Modell-Endpunkten nach Verbrauch. Dieser Block ist planbar, solange die Abrechnungslogik verstanden ist. Bei verbrauchsabhängiger Abrechnung – etwa nach verarbeiteten Dokumenten, Belegpositionen, Artikeln oder Textmengen – lohnt eine Hochrechnung auf Spitzenlast: Ein Saisonhoch oder eine Sortimentsausweitung verschiebt die Kosten deutlicher, als der Durchschnittswert vermuten lässt.
Der zweite Block ist die Einführung: Datenbeschaffung und Bereinigung, Aufbau oder Erweiterung der Auswertungsschicht, Schnittstellen, Konfiguration, Rückrechnung und Bewertung, Schulung, Prozessanpassung und Dokumentation. Dieser Block ist in KI-Projekten typischerweise größer als der Softwareblock und hängt fast ausschließlich an der Ausgangsqualität der Daten. Deshalb ist die Datenprüfung vor der Angebotseinholung kein Formalismus, sondern die Grundlage jeder seriösen Kalkulation.
Der dritte Block ist der laufende Betrieb – und er wird am zuverlässigsten vergessen. Er umfasst Überwachung, regelmäßige Aktualisierung von Modellen und Parametern, Pflege der Datenstrecken bei Systemänderungen, Nachdokumentation, Anpassung bei Sortiments- und Prozessänderungen, Rechenzeit im laufenden Einsatz und die interne Arbeitszeit derjenigen, die Ergebnisse prüfen und Ausnahmen bearbeiten. Eine ehrliche Betrachtung rechnet diesen Block über mehrere Jahre mit und vergleicht ihn mit dem erwarteten Nutzen. Nur so entsteht ein realistisches Bild – und nur so lassen sich Vorhaben vergleichen, deren Einführungskosten ähnlich, deren Betriebskosten aber sehr unterschiedlich sind.
Auf der Nutzenseite empfiehlt sich dieselbe Nüchternheit. Belastbar sind Nutzenkategorien, nicht Prozentangaben aus Anbieterunterlagen: eingesparte Bearbeitungszeit je Vorgang mal Vorgangsmenge, vermiedene Fehlmengen und deren Folgekosten, geringere oder bewusster gesteuerte Kapitalbindung, vermiedene Sonderfahrten und Eilzuschläge, reduzierte Reklamations- und Nachbearbeitungsfälle. Wer diese Größen für den eigenen Betrieb schätzt und die Annahmen offenlegt, hat eine Grundlage, die einer Nachrechnung standhält.
Das erste Risiko ist die Modellverschlechterung im Betrieb. Sie ist unvermeidlich und wird durch Überwachung beherrschbar: definierte Qualitätskennzahlen, regelmäßige Auswertung, festgelegte Schwellen, ab denen nachtrainiert oder abgeschaltet wird. Wichtig ist ein Rückfallpfad – die Möglichkeit, kurzfristig auf das bisherige Verfahren oder eine einfache Regel umzuschalten, ohne dass der Betrieb stillsteht.
Das zweite Risiko ist die Abhängigkeit von Anbietern. Sie entsteht schleichend: Daten liegen im System des Anbieters, Modelle sind dort trainiert, Prozesse sind auf die Oberfläche zugeschnitten. Gegenmittel sind der vertraglich gesicherte, vollständige und strukturierte Export der eigenen Daten, eine eigene Datenschicht außerhalb der Anwendung und die Dokumentation der fachlichen Logik unabhängig vom Produkt.
Das dritte Risiko ist die Personenabhängigkeit, insbesondere bei Eigenentwicklungen. Dokumentation, Codeverwaltung, nachvollziehbare Datenstrecken und eine benannte Vertretung sind die üblichen und wirksamen Antworten. Das vierte Risiko ist falsches Vertrauen: Sobald ein System als zuverlässig gilt, sinkt die Prüfbereitschaft. Stichprobenkontrollen, Freigabegrenzen und die Beibehaltung des Vier-Augen-Grundsatzes bei finanzwirksamen Vorgängen halten dieses Risiko klein.
Das fünfte Risiko ist Verzerrung in den Daten. Modelle lernen aus der Vergangenheit und schreiben deren Muster fort – einschließlich der Muster, die man nicht fortschreiben will. Wenn ein Lieferant in der Vergangenheit selten berücksichtigt wurde, erscheint er in der Auswertung als wenig relevant, unabhängig von seiner Leistungsfähigkeit. Wenn bestimmte Artikel systematisch untergeplant waren, bestätigt das Modell diese Untergewichtung. Solche Rückkopplungen erkennt man nur, wenn man gezielt danach sucht.
Mit der KI-Verordnung der Europäischen Union existiert erstmals ein horizontaler Rechtsrahmen für KI-Systeme, der gestaffelt anwendbar wird und einem risikobasierten Ansatz folgt. Vereinfacht dargestellt unterscheidet er vier Stufen: verbotene Praktiken, Hochrisiko-Anwendungen mit umfangreichen Pflichten, Anwendungen mit Transparenzpflichten und Anwendungen mit geringem Risiko, für die im Wesentlichen keine besonderen Anforderungen gelten. Für Anbieter allgemeiner KI-Modelle bestehen zusätzlich eigene Pflichten.
Für die klassischen Anwendungsfälle der Lieferkette ist die praktische Einordnung meist entspannt: Eine Bedarfsprognose, eine Bestandsoptimierung, eine Tourenplanung oder eine Belegextraktion fällt regelmäßig nicht in den Hochrisikobereich, weil sie weder Grundrechte betrifft noch in den in der Verordnung aufgeführten sensiblen Bereichen liegt. Das entbindet nicht von Sorgfalt, verschiebt die Anforderungen aber in den Bereich guter Praxis statt formaler Konformitätsverfahren.
Aufmerksamkeit verdienen jedoch drei Konstellationen. Erstens Anwendungen im Beschäftigtenkontext: Systeme, die zur Auswahl von Bewerbern, zur Zuweisung von Aufgaben, zur Leistungsbewertung oder zur Überwachung von Beschäftigten eingesetzt werden, sind regulatorisch deutlich sensibler einzuordnen. Im Lagerumfeld ist das schneller berührt, als man denkt – etwa wenn eine Arbeitslastprognose mit einer individuellen Leistungsauswertung verknüpft wird. Zweitens Anwendungen mit Bezug zu natürlichen Personen, etwa in der Bonitäts- oder Risikobewertung von Einzelunternehmern. Drittens der Einsatz generativer Systeme, für die Transparenzpflichten gelten können – Menschen sollen erkennen können, dass sie mit einem KI-System interagieren oder dass ein Inhalt maschinell erzeugt wurde.
Hinzu kommt eine Anforderung, die alle Einsatzformen betrifft: Unternehmen sollen dafür sorgen, dass die Personen, die KI-Systeme betreiben und nutzen, über ausreichende Kompetenz im Umgang damit verfügen. Praktisch heißt das Schulung – zu Funktionsweise, Grenzen, typischen Fehlern und dem richtigen Umgang mit Ergebnissen. Für den Mittelstand ist das ein überschaubarer, aber verbindlicher Punkt, der in die Projektplanung gehört. Die konkreten Fristen, die Einstufung des eigenen Einsatzes und die daraus folgenden Pflichten gehören im Einzelfall geprüft.
Der Datenschutz kommt in Supply-Chain-Anwendungen über drei Wege ins Spiel, die häufig unterschätzt werden. Der erste sind Beschäftigtendaten: Kommissionierleistungen, Scanvorgänge, Fahrzeiten, Telematikdaten, Schichtzuordnungen. Sobald solche Daten einzelnen Personen zuordenbar sind und ausgewertet werden, liegt eine Verarbeitung mit erhöhter Sensibilität vor. Zu klären sind Rechtsgrundlage, Erforderlichkeit, Datenminimierung, Aufbewahrungsdauer und – in Betrieben mit Betriebsrat – die Mitbestimmung bei Systemen, die zur Verhaltens- oder Leistungskontrolle geeignet sind. Diese Eignung genügt bereits; eine tatsächliche Kontrollabsicht ist nicht erforderlich. Wer den Betriebsrat früh einbindet, vermeidet Projektstopps kurz vor dem Start.
Der zweite Weg sind Kontaktdaten bei Lieferanten und Dienstleistern: Ansprechpartner, Disponenten, Fahrer. Auch bei Geschäftskontakten handelt es sich um personenbezogene Daten, wenn sie natürlichen Personen zuordenbar sind. Der dritte Weg sind Kundendaten in Absatz-, Retouren- und Reklamationsanalysen. Für Prognosezwecke werden personenbezogene Angaben meist nicht benötigt – Aggregation und Pseudonymisierung sind hier der einfachste und wirksamste Weg, das Thema klein zu halten.
Zur Souveränitätsfrage gehört eine sachliche Einordnung. Viele KI-Funktionen in gängiger Unternehmenssoftware greifen im Hintergrund auf Dienste großer, überwiegend außerhalb der EU ansässiger Anbieter zurück. Das ist verbreitet und nicht per se unzulässig, verlangt aber Transparenz: Welcher Dienst wird genutzt, in welcher Region wird verarbeitet, welche Vertragsgrundlage besteht, welche zusätzlichen Maßnahmen sind vereinbart. Wo Anbieter eine EU-Region anbieten, ist deren Nutzung der datenschutzfreundlichere Weg; wo besonders sensible Daten verarbeitet werden, sind europäische Anbieter oder der Eigenbetrieb offener Modelle in einem europäischen Rechenzentrum die konsequentere Option.
Der Eigenbetrieb hat einen weiteren Vorteil, der selten genannt wird: Er macht die Kosten planbar und die Abhängigkeit von Preisänderungen und Produktentscheidungen eines externen Anbieters geringer. Er hat auch einen klaren Preis, nämlich eigenen Betriebsaufwand und den Verzicht auf die jeweils leistungsfähigsten kommerziellen Modelle. Für Dokumentenextraktion, Klassifikation und Zusammenfassung im eigenen Haus reichen offene Modelle in vielen Fällen aus; für anspruchsvolle Sprachaufgaben ist der Abstand größer. Diese Abwägung sollte bewusst getroffen und dokumentiert werden – sie ist Teil der Architekturentscheidung, nicht ihrer Fußnote.
