Inventarroboter und Odoo: eine Abstimmung synchronisieren, keine Zahl

Ein Roboter, der um zwei Uhr nachts durch die Gänge fährt und tausend Lagerorte zählt, klingt nach dem Ende der Bestandsprobleme. Tatsächlich erzeugt er etwas Bescheideneres und Nützlicheres: einen nächtlichen Vergleich zwischen dem, was das ERP annimmt, und dem, was eine Maschine beobachtet hat - mit Position und Zeitstempel hinter jeder Zeile.

Der Wert des Projekts steckt fast vollständig darin, wie dieser Vergleich modelliert wird.

Was ein Nachtroboter tatsächlich liefert

Er ist eine fahrende Sensorplattform, kein Orakel.

• Die Plattform trägt einen Mast, eine oder mehrere Antennen und einen Lokalisierungsstack, meist Lidar plus Radodometrie.
• Er liest Lagerortkennungen am Regal und, je nach Konfiguration, Artikelanhänger, Regaletiketten oder beides.
• Jede Erfassung ist an eine Pose gebunden: Gang, Modul, Höhe und Seite.
• Die Ausgabe ist eine Menge von Beobachtungen, kein Bestandswert, und Beobachtungen brauchen Deutung.
• Wer die Beobachtung als Bestandswert behandelt, schaltet den Roboter nach einem Quartal ab.

Der nächtliche Lauf ist eine Abstimmung

Das nützliche Artefakt ist die Differenz zwischen Soll und Ist, mit Gründen.

• Die Erwartungsliste je Lagerort bei Missionsbeginn aus Odoo-Quants bauen, nicht beim Import.
• Beobachtete Lesungen Lagerort für Lagerort mit der Liste vergleichen und Übereinstimmung wie Abweichung festhalten.
• Jeder Beobachtung eine Konfidenz geben: vollständige Lesung, TeilLesung, unklare Position, keine Lesung.
• Den Vergleich veröffentlichen, bevor eine Bestandsbuchung vorgeschlagen wird.
• Die Momentaufnahme behalten, denn das Regal verändert sich während der Prüfung.

Missionen, Routen und Sitzungen ausdrücklich modellieren

Eine Lesung ohne Mission ist eine Anekdote; eine Lesung innerhalb einer Mission ist ein Nachweis.

• Die Mission speichern: Roboter, Kartenversion, Beginn und Ende, Bediener oder Zeitplan, Abdeckungsplan.
• Wegpunkte und den je erwarteten Lagerort speichern.
• Die Erfassungssitzung mit Sequenznummer speichern, damit Wiederholungen nachvollziehbar bleiben.
• Die Karte versionieren, denn Regale wandern und eine veraltete Karte etikettiert Lesungen falsch.
• Odoo auf die Missionskennung verweisen lassen, damit eine strittige Menge auf eine Nacht zurückführbar ist.

Position und Zeit sind die schwierigen Felder

Ein Anhänger im falschen Modul gelesen ist schlimmer als keine Lesung, denn er sieht nach echter Abweichung aus.

• Die Pose im Moment der Lesung erfassen, nicht am Ende des Halts.
• Die Roboteruhr zu Missionsbeginn synchronisieren und Erfassungen mit unplausiblen Zeiten ablehnen.
• Zeit in UTC halten und nur zur Anzeige einmal umrechnen.
• Die Beobachtungszeit mit der letzten Bestandsbewegung für Produkt und Lagerort vergleichen.
• Hat das ERP nach der Erfassung Ware bewegt, ist die Abweichung wohl Geschichte, nicht Fehler.

Daten zuerst in Staging landen

Direktes Schreiben von der Roboter-API in die Quants zerstört am schnellsten das Vertrauen in beide Systeme.

• RohErfassungen in eine Staging-Tabelle mit Mission, Pose, Zeitstempel, Anhänger und Signalstärke einlesen.
• In Staging validieren: Produkt, Lagerort, Charge existieren, Menge plausibel.
• Abgelehnte Beobachtungen sichtbar halten, denn Lesefehler häufen sich in bestimmten Gängen.
• In Stapeln mit deterministischem Missionsschlüssel verarbeiten, damit ein erneuter Upload harmlos ist.
• Von Staging in ein Abweichungsdokument überführen; erst danach Bestandskorrekturen erwägen.

Lesungen ehrlich mit ERP-Datensätzen abgleichen

Die Abgleichschicht trägt das meiste technische Risiko.

• Eine ausdrückliche Zuordnung von Lagerortkennung zu Odoo-Lagerort pflegen, inklusive Höhenebenen.
• Anhänger-Produkt-Bindungen pflegen und ungebundene Anhänger als Ausnahme behandeln, nicht als neues Produkt.
• Eine Anhängerlesung nur dann als mehrere Einheiten deuten, wenn der Prozess es sagt; ein Anhänger ist keine Menge.
• Doppellesungen innerhalb eines Durchlaufs durch die stärkste Beobachtung auflösen und den Rest protokollieren.
• Mehrdeutige Treffer aufzeigen, wenn eine Lesung zu zwei Kandidaten passt, statt still zu wählen.

Abweichung klassifizieren, bevor gehandelt wird

Nicht jede Differenz verdient eine Korrektur, und der Klassifizierer macht den Bericht nutzbar.

• Eine Mengendifferenz mit konsistenten Lesungen am richtigen Ort deutet auf ein echtes Bestandsproblem.
• Ein Produkt im falschen Modul deutet auf Verstellung, nicht auf Verlust.
• Eine fehlende Lesung an einem auch in der Vornacht ungelesenen Ort deutet auf defekten Anhänger oder blockiertes Regal.
• Eine Differenz, die erst nach dem Schichtwechsel auftritt, deutet auf eine nicht erfasste Bewegung.
• Jede Klasse einem anderen Verantwortlichen zuleiten, denn die Lösungen unterscheiden sich.

Menschen im Kreis behalten

Automatisierung soll Aufmerksamkeit bündeln, nicht abschaffen.

• Abweichungen in Odoo-Aufgaben überführen, mit Lagerort, Soll, Ist und Pose- oder Fotoreferenz.
• Den Bediener bestätigen, korrigieren oder mit Grundcode verwerfen lassen.
• Für hochwertige oder stark abweichende Lagerorte einen mobilen Prüfdurchlauf vor der Korrektur nutzen.
• Automatische Korrekturen nur für Kategorien mit niedrigem Wert und belegter Falschpositivrate.
• Verfolgen, wie oft Bediener den Roboter überstimmen; steigende Quote heißt falsches Modell oder falsche Karte.

Betriebliche Grenzen, die niemand budgetiert

Der Roboter teilt den Boden mit Menschen, Gabelstaplern und Ladestationen.

• Die Nachtschicht ist ruhiger, aber nicht leer; Sicherheitsregeln und Tempolimits gelten weiter.
• Akku und Ladezeiten begrenzen, wie viele Gänge eine Mission schafft.
• Beleuchtung und Bodenbeschaffenheit beeinflussen die Lokalisierung stärker als RFID.
• WLAN-Lücken lassen Daten puffern; die Synchronisation muss späte Ankunft tolerieren.
• Regaländerungen, überstehende Paletten und Schrumpffolie verändern, was der Roboter sieht.

Kennzahlen und Rollout-Reihenfolge

Messen Sie, ob der Roboter den Bestand verbessert, nicht ob er beeindruckt.

• Abdeckung: Anteil der tatsächlich beobachteten Lagerorte pro Nacht gegenüber der geplanten Route.
• Übereinstimmungsrate: Lagerorte, an denen die Beobachtung der ERP-Erwartung entspricht.
• Falschpositivrate: später von Menschen verworfene Abweichungen, die den Automatisierungsumfang bestimmt.
• Abschlusszeit einer Abweichung, von Erkennung bis Lösung.
• Mit einer Zone und einer Kategorie beginnen, einen Monat nur im Berichtsmodus, dann Aufgaben freigeben.

Teams, die im reinen Berichtsmodus starten, entdecken meist, dass ein Drittel der scheinbaren Abweichungen Mapping- oder Anhängerprobleme sind - genau die Information, die vor jeder automatischen Bestandskorrektur nötig ist.