Veröffentlicht am 23. Oktober 2026
Fragt man die meisten Werksleiter, ob die Bestandszahlen im ERP mit dem übereinstimmen, was tatsächlich auf dem Shop Floor vorhanden ist, lautet die ehrliche Antwort meist: „nahe dran, aber nicht exakt“. Bei Zykluszählungen tauchen regelmäßig Abweichungen auf — eine Komponente, die das ERP als verfügbar führt, liegt nicht im Regal, eine in der Produktion verbrauchte Baugruppe wurde noch nicht aus dem Bestand ausgebucht, eine Wareneingangsabweichung wurde nie korrigiert. Jede einzelne Lücke ist klein. Über Tausende von SKUs und mehrere Fertigungsbereiche hinweg ist es genau diese aufsummierte Abweichung, die zu Expressversand, Produktionsstopps und Planern führt, die dem führenden System nicht mehr vollständig vertrauen.
Das ist ein Abstimmungsproblem, und genau für solche Probleme sind AI Agents gut geeignet — nicht weil die Mathematik kompliziert wäre, sondern weil die Eingaben über Systeme und Formate verteilt sind, die nicht sauber miteinander sprechen.
Warum es zu Abweichungen zwischen ERP und Shop Floor kommt
Bestandsabweichungen entstehen selten durch einen einzigen großen Fehler. Sie summieren sich aus mehreren kleinen, laufenden Lücken. Abweichungen beim Wareneingang zwischen dem, was ein Bestellauftrag sagt, und dem, was tatsächlich ankommt, vor allem wenn Teillieferungen oder Ersatzartikel nicht konsistent erfasst werden. Verzögerte manuelle Transaktionserfassung, bei der Material physisch bewegt oder verbraucht wird, bevor die zugehörige ERP-Transaktion erfasst ist — manchmal Stunden oder Schichten später. Ausschuss und Nacharbeit, die auf einem Papierlaufzettel oder in einer Tabelle des Schichtleiters dokumentiert werden, statt in Echtzeit ins ERP zurückzufließen. Und Umlaufbestände, die sich in einem unklaren, schwer zählbaren Zustand auf dem Shop Floor zwischen definierten Stufen befinden, während das ERP einen Status annehmen muss, der mit der Realität möglicherweise nicht übereinstimmt.
Keine dieser Lücken ist für sich allein sichtbar, bis eine Zykluszählung oder — schlimmer noch — ein Lagerausfall die Frage zwingend aufwirft.
Was ein AI-Agent in diesem Workflow tatsächlich übernimmt
Die Aufgabe eines Abstimmungs-Agenten ist es, Bestandsignale aus mehreren Quellen kontinuierlich zu vergleichen — ERP, MES oder Datenerfassungssysteme am Shop Floor, Wareneingangsprotokolle und manchmal Scanner- oder Barcode-Daten — und Abweichungen zu markieren, bevor daraus ein Produktionsproblem wird, statt auf die nächste geplante Zykluszählung zu warten, um sie sichtbar zu machen.
Kontinuierliche Abweichungserkennung
Statt dass nur eine monatliche oder quartalsweise Zykluszählung als Kontrolle dient, vergleicht der Agent laufend den erwarteten Bestandsstatus mit eingehenden Signalen und markiert SKUs, bei denen die Abweichung einen prüfungsrelevanten Schwellenwert überschreitet — priorisiert nach den Teilen, bei denen tatsächlich ein Produktionsstopp droht.
Ursachenklassifizierung statt nur einer Abweichungszahl
Ein reiner Abweichungsbericht sagt Ihnen, dass etwas nicht stimmt, aber nicht warum. Ein Agent mit Zugriff auf Transaktionshistorie, Wareneingangsdaten und Produktionsprotokolle kann häufig die wahrscheinliche Ursache einordnen — Zeitverzug versus echter Verlust versus Datenerfassungsfehler — und genau das macht den Unterschied zwischen einem Bericht, den jemand manuell prüfen muss, und einem, der dem Planer sagt, was zuerst zu kontrollieren ist.
Dokumenten- und unstrukturierte Datenerfassung
Ein erheblicher Teil der Quelldaten für die Abstimmung sind keine sauberen strukturierten Daten — Packzettel, handschriftliche Laufzettel, Lieferantenzertifikate, gescannte Wareneingangsdokumente. Genau hier leistet Document Intelligence echte Arbeit: Mengen, Teilenummern und Losdaten aus Dokumenten zu extrahieren, die niemals konsistent von Hand erfasst worden wären, und diese automatisch in die Abstimmungslogik einzuspeisen.
Genau solche Systeme entwickeln wir im Rahmen unserer Manufacturing- und Industrial-AI-Arbeit: Agents, die sich über ERP, MES und Daten auf dem Shop Floor erstrecken, statt ein einziges einheitliches System vorauszusetzen, das die meisten Werke in der Praxis gar nicht haben.
Womit dies an reale Systeme angebunden werden muss
Der schwierige Teil dieses Projekts ist selten die Abstimmungslogik selbst. Es ist die Integrationsfläche: Die meisten Werke nutzen ein ERP (SAP, Oracle, Epicor, Infor oder eine branchenspezifische Lösung), oft eine separate MES- oder Datenerfassungsebene am Shop Floor und häufig ein Scanner- oder Barcode-System, das zu einem anderen Zeitpunkt von einem anderen Anbieter ergänzt wurde. Ein Agent, der Bestände sauber abstimmt, muss zuverlässig auf alle diese Systeme zugreifen können. Das bedeutet in der Regel, sich an den APIs oder den Datenbankzugriffen auszurichten, die die jeweiligen Systeme tatsächlich bereitstellen, statt anzunehmen, dass eine saubere, einheitliche Datenebene vorhanden ist. Genau das ist bei diesen Projekten oft der eigentliche Umfangstreiber — mehr noch als die AI-Logik selbst.
Wo sich das auszahlt — und wo noch nicht
Kontinuierliche Abstimmung rechnet sich am schnellsten in Umgebungen mit vielen SKUs, engen Just-in-time-Produktionsplänen, bei denen ein Lagerausfall teuer ist, oder in Lieferketten mit viel Substitutions- und Teillieferungskomplexität. Weniger dringlich ist sie für Betriebe mit wenigen SKUs und geringer Komplexität, in denen eine quartalsweise Zykluszählung die Abweichung bereits in einem tolerierbaren Rahmen hält und die Kosten für ein kontinuierliches Monitoring höher wären als der Nutzen.
Das Datenqualitätsproblem ehrlich angehen
Jedes Reconciliation-System ist nur so gut wie die Daten, die es miteinander vergleicht, und in Fertigungsumgebungen gibt es von Anfang an selten saubere, konsistente Daten über alle Quellen hinweg. Teilenummern werden in den Systemen uneinheitlich erfasst, Umrechnungen von Maßeinheiten stimmen zwischen dem ERP und dem Shopfloor-System nicht immer überein, und manche älteren Anlagen oder Prozesse haben überhaupt keine digitalen Datenspuren und laufen vollständig auf Papier. Einen Reconciliation-Agenten zu bauen, ohne das zu berücksichtigen, führt meist dazu, dass das System in den ersten Wochen eine Flut von falsch-positiven Abweichungen erzeugt — Differenzen, die in Wahrheit nur Datenabweichungen und keine echten Bestandsprobleme sind — und damit schnell das Vertrauen in die Ausgabe des Systems untergräbt.
Der realistischere Ansatz behandelt die erste Phase des Projekts als Aufgabe der Datenzuordnung und Normalisierung: zu identifizieren, wo sich Teilenummern, Einheiten und Standortcodes zwischen den Systemen unterscheiden, und die Abgleichlogik so aufzubauen, dass bekannte Inkonsistenzen berücksichtigt werden, bevor die Abweichungserkennung live geht. Das bedeutet auch, den Agenten zunächst im Beratungsmodus zu betreiben — markierte Abweichungen für einen Planer sichtbar zu machen, damit dieser sie prüft und bestätigt — statt seine Ergebnisse direkt in automatisierte Nachbestellungs- oder Produktionsentscheidungen einfließen zu lassen, bis seine Genauigkeit über mehrere Cycle-Count-Phasen anhand realer Ergebnisse validiert wurde.
Wer diesen Schritt überspringt und direkt auf Vollautomatisierung setzt, landet meist wieder dort, wo alles begann: bei einem System, dem niemand vertraut und das zugunsten des manuellen Prozesses umgangen wird, den es eigentlich ersetzen sollte.
Fragen, die Sie vor dem Scoping dazu stellen sollten
Bevor Sie sich auf ein Reconciliation-Projekt festlegen, sollten Sie klären, was Ihre aktuelle Abweichung tatsächlich kostet — etwa durch Eilfracht, Produktionsstopps oder Abschreibungen — denn diese Zahl bestimmt den realistischen ROI. Ebenso sinnvoll ist es zu prüfen, welche Daten Ihre ERP- und Shopfloor-Systeme tatsächlich per API bereitstellen können und was eine eigene Extraktionsschicht erfordern würde, da genau diese Lücke meist der eigentliche Kostentreiber ist. Und es lohnt sich zu fragen, wer derzeit die Untersuchung von Abweichungen verantwortet und wie sich ihr Workflow ändern sollte, sobald gemeldete Differenzen nicht mehr nur als nackte Zahl erscheinen, sondern direkt mit einer wahrscheinlichen Ursache verknüpft sind.
Erste Schritte
Wir starten solche Projekte, indem wir die tatsächlichen Systeme in Ihrer Umgebung kartieren — ERP, MES, Scanning und alle noch genutzten papierbasierten Prozesse — bevor wir vorschlagen, wo die Reconciliation-Logik verankert werden sollte. Wenn Sie einen strukturierten Blick darauf möchten, was eine durchgängige Bestandsabstimmung in Ihrer konkreten Fertigungsumgebung erfordert, ist der ASTACKRA Project Planner ein schneller Weg, Ihre Systeme zu beschreiben und eine konkrete Empfehlung zu erhalten, oder Sie wenden sich direkt über unsere Kontaktseite an das Team.
Verwandt