On-Shelf Availability: warum Bestand nicht Regalverfügbarkeit ist
Wie Händler mit OSA Phantom-Bestand erkennen, Regalverfügbarkeit messen und Nachbestellungen aus POS-, RFID- und CV-Signalen auslösen.
Die Kernaussagen auf einen Blick.
- On-Shelf Availability misst, ob ein Artikel zu einem bestimmten Zeitpunkt wirklich im Regal steht. Das ist etwas anderes als der Buchbestand im ERP.
- Der Nutzen entsteht erst, wenn POS-Daten, ERP-Bestand, RFID, Smart Shelf, Computer Vision und Planogramm zusammengeführt werden. Ein einzelner Sensor liefert nur ein Rohsignal.
- Der wichtigste Use Case ist Phantom-Bestand: Das System zeigt Bestand, aber der Artikel steht nicht im Regal. Dadurch greifen automatische Nachbestellungen oft zu spät oder gar nicht.
- Mein Vorschlag: OSA als Datenprodukt beim Data-Team aufbauen. Zuerst müssen Datenfluss, Feature-Layer und Trigger funktionieren. Die Sensorik-Auswahl ist eine eigene Entscheidung.
Inhaltsverzeichnis
Was ist On-Shelf Availability?
On-Shelf Availability beschreibt, ob gelistete Artikel zu einem bestimmten Zeitpunkt wirklich im Regal stehen und für Kunden erreichbar sind. Die ECR-Community-Forschung zu Retail Loss trennt OSA ausdrücklich von zwei anderen Verfügbarkeitsmessungen: Supply Chain Availability (das Produkt existiert im Distributionsnetz), In-Store Availability (das Produkt ist irgendwo in der Filiale) und True On-Shelf Availability (das Produkt steht am zugewiesenen Regalplatz und ist greifbar). Ein Artikel im Lager, auf dem Verräumwagen oder an der falschen Stelle hilft dem Kunden nicht. Für OSA zählt nur, ob er am richtigen Regalplatz verfügbar ist.
Als Datenprodukt zeigt OSA, wo Buchbestand und Regalrealität auseinanderlaufen und wo eine Aktion ausgelöst werden sollte. Dafür werden Kassendaten, Bestand, Sensorik und Bilder pro Filiale und Artikel zusammengeführt. Daraus können Regeln oder Modelle eine Nachbestellung, eine Verräumaufgabe oder eine Bestandskorrektur ableiten. Das Modell ersetzt keine Sensorik und keine Warenwirtschaft. Es macht nur sichtbar, wo die Signale nicht zusammenpassen. Es macht diese Abweichung messbar und nutzbar.
Wie sich der Sollbestand pro Filiale und SKU herleitet, klären wir im Überblick zu Demand Forecasting im Einzelhandel; den übergeordneten Rahmen für Retail-Use-Cases zeigen wir in der Customer-Intelligence-Übersicht.
Warum klassische OSA-Reports zu spät kommen
Klassische OSA-Reports laufen oft nachts. Sie prüfen Nullumsätze aus dem POS, vergleichen sie mit dem Bestand und landen am nächsten Morgen im Postfach. Dann ist das Problem aber schon passiert. Die Regallücke vom Vortag hat bereits Umsatz gekostet. Oft laufen parallel mehrere Piloten: RFID, Gewichtssensoren, Kameras oder Smart Shelves. Die Daten landen aber häufig in Vendor-Portalen und nicht in der eigenen Datenplattform. Selbst wenn ein Computer-Vision-Modell eine Lücke erkennt, folgt oft keine Aktion. Am Ende entsteht nur ein weiterer Report.
Das Problem entsteht immer dann, wenn mehrere Signalquellen nebeneinander laufen, aber nicht zusammengeführt werden. POS, ERP-Bestand, RFID, Smart Shelf und Computer Vision liegen dann in getrennten Systemen. Die entscheidenden Fragen bleiben ohne Antwort. Wo ist die Regallücke jetzt in Echtzeit? Welche Lücken sind echte Out-of-Stocks und welche Phantom-Bestand? Warum zeigt das ERP zwölf Stück, wenn im Regal null stehen und die Kasse seit zwei Stunden nichts mehr scannt? Außerdem bleibt unklar: Wer darf aus dem Signal eine Aktion machen? Store Ops, Category Management, IT oder Data-Team?
Regalverfügbarkeit ist nicht nur ein Sensorik-Thema. Der Sensor liefert Rohsignale. Der Nutzen entsteht erst, wenn Signale zusammengeführt werden und daraus eine konkrete Aktion entsteht: Verräumen, Bestand korrigieren oder nachbestellen. Das ist ein Datenprodukt mit klarer Ownership und einem eigenen SLA. Es ist kein Zusatzreport eines Hardware-Anbieters, sondern ein eigenes Datenprodukt.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Signale braucht ein OSA-Datenprodukt?
Ein belastbares OSA-Datenprodukt braucht mehrere Signalquellen.
| Signal | Was es kann | Was es nicht kann | Typische Latenz |
|---|---|---|---|
| POS-Kassenstrom | Verkaufsrate pro SKU/Filiale, Nullumsatz als Verdachtssignal | zeigt nicht, ob Regal leer oder Ware liegt im Backroom | Sekunden bis Minuten |
| ERP-/Warenwirtschafts-Bestand | Soll-Bestand pro SKU, Wareneingang, Umbuchungen | zeigt den Buchbestand, aber nicht, ob der Artikel wirklich im Regal steht | Batch/CDC, meist stündlich bis täglich |
| RFID-Events (GS1 EPCIS) | Item-genaue Ortungs-Events an Toren, Regalen, Kassen | erfasst nur getaggte Artikel; Non-Tag-Warengruppen bleiben blind | Streaming, Sekunden |
| Smart-Shelf-Sensorik (Gewicht, Infrarot) | Auffüll- und Entnahme-Events, Restfüllung | keine SKU-Identifikation im Mischsortiment; Kalibrierungs-Aufwand pro Regal | Streaming, Sekunden |
| Computer Vision auf Regal-Bild/Video | erkennt Regalflächen, Lücken und Abweichungen vom Planogramm | Trainingsdaten pro Sortiment und Regaltyp; Schatten/Reflexion drücken Genauigkeit | Bild-Batch (Minuten) bis Streaming (Sekunden) |
| Planogramm-Metadaten | Soll-Position, Facing-Zahl, Regal-Koordinaten | statisch; keine Ist-Aussage ohne Abgleich mit RFID/CV | Stammdaten, tägliche Aktualisierung |
Der GS1-EPCIS-2.0-Standard ist die zentrale Schnittstelle für RFID- und serialisierte Item-Events. EPCIS-Events beantworten immer vier Fragen:
Was
SGTIN identifiziert den Einzelartikel, SSCC die Palette.
Wann
Der eventTime-Zeitstempel in UTC markiert den Zeitpunkt des Events.
Wo
GLN und readPoint verorten das Event an Tor, Regal oder Kasse.
Warum
bizStep und disposition aus dem Core Business Vocabulary beschreiben den Geschäftsvorgang.
Die Version 2.0 nutzt JSON-LD-Payloads und REST-Endpunkte (/capture, /queries). Damit lässt sich die Einlese-Pipeline mit denselben Werkzeugen bauen wie jede andere Event-Ingestion.
Kein Signal reicht allein. Nur POS-Daten zu nutzen reicht nicht. Sie zeigen zwar fehlende Verkäufe, aber nicht, ob die Ware im Lager liegt, falsch verräumt wurde oder wirklich fehlt. Nur RFID hilft nichts, wenn 40 Prozent des Sortiments ungetaggt bleiben. Computer Vision ohne Planogramm erkennt zwar eine Lücke, weiß aber nicht zuverlässig, welcher Artikel dort stehen sollte. Erst die Zusammenführung macht daraus ein brauchbares Datenprodukt.
Feature-Layer pro Filiale · SKU · Zeitfenster
Wie läuft die OSA-Ingestion in Echtzeit?
Ein OSA-Datenprodukt sollte nicht nur nachts laufen. Jede Signalquelle braucht den passenden Datenfluss: Streaming, Micro-Batch oder Batch. Die Databricks-Referenz-Architektur für Real-Time Retail beschreibt einen Stack aus Delta Live Tables, Auto Loader und Photon; welche Technik passt, hängt von der jeweiligen Quelle ab.
POS-Daten kommen meist als Stream aus Kafka oder einer ähnlichen Plattform. Databricks Structured Streaming liest den Stream ein und schreibt ihn in die Bronze-Ebene. Wichtig ist, dass jede Kassenbuchung genau einmal ankommt und mit einem sauberen Zeitstempel versehen ist. Sonst kippen die Aggregationen im Feature-Layer.
Regalbilder und Videostills landen als Dateien im Cloud-Speicher. Auto Loader nimmt neue Dateien automatisch auf und schreibt sie in Bronze. Kein manuelles Partition-Management, keine Duplikate bei einem Rerun.
Sensorik wie Gewichtssensoren oder Edge-Kameras schickt ihre Daten meist über einen MQTT-Broker (zum Beispiel EMQX). Von dort landen die Nachrichten in Object Storage, Auto Loader übernimmt den Rest. Für neuere Setups geht das auch direkt über Zerobus per OpenTelemetry ins Lakehouse, ohne Zwischenstopp beim Observability-Vendor.
ERP-Bestand kommt selten als Stream. Für Warenwirtschaftssysteme mit Change-Data-Capture (SAP, Microsoft Dynamics, JD Edwards) ist Lakeflow Connect oder Fivetran die pragmatische Wahl; für ältere Systeme reicht ein täglicher Snapshot-Export in Object Storage plus Auto Loader.
Praktisch gibt es drei Latenzklassen.
| Klasse | Fenster | Wofür | Beispiel |
|---|---|---|---|
| Streaming | Sekunden bis 5 Minuten | RFID-Events, CV-Frames, MQTT-Sensorik, POS | Kassenstrom, Regal-Kamera |
| Micro-Batch | 5 bis 15 Minuten | Feature-Aggregation, Anomalie-Score | Filial-SKU-Delta-Fenster |
| Batch | stündlich bis täglich | Reporting, Retraining, ERP-CDC | Bestands-Snapshot, Modell-Retrain |
Die Regel: Nur so schnell wie nötig. Nicht jedes Signal braucht Sekundenlatenz. Für ein Randsortiment kann ein 15-Minuten-Fenster reichen. Für die Milch-Kühltruhe an einem Samstagvormittag nicht.
Wie entsteht der Feature-Layer für Regalverfügbarkeit?
Im Feature-Layer werden die Rohsignale zu einem nutzbaren OSA-Datenprodukt. Der Databricks Feature Store auf Unity Catalog trennt Offline-Features (für Training) und Online-Features (für Serving) und synchronisiert beide über Delta Change Data Feed.
Für OSA wird pro Filiale, Artikel und Zeitfenster eine Feature-Zeile aufgebaut. Diese Zeile fasst zusammen, was POS, ERP, Sensorik, Planogramm und Bilder zu diesem Zeitpunkt über den Artikel sagen:
- Bestand-System (aus ERP-CDC, Snapshot der letzten CDC-Version)
- Bestand-Sensor (aus RFID-Zählung oder Smart-Shelf-Gewicht, aggregiert im Fenster)
- Abweichung zwischen Buchbestand und Sensorsignal (die zentrale Anomalie-Größe)
- Anteil der sichtbaren Regalfläche (aus dem CV-Modell, letzter validierter Frame)
- Verkäufe im aktuellen Zeitfenster im Vergleich zur üblichen Verkaufsrate (POS-Umsätze pro SKU/Fenster, normalisiert auf historische Baseline)
- Zeit seit letzter Bewegung (letztes RFID-Event, letzter Verkauf, letzter CV-Frame mit Facing > 0)
- Soll-Bestand (aus der Bedarfsprognose, per Feature-Lookup)
- Aktions-/Planogramm-Kontext (aktiver Trade-Promo-Zeitraum, Planogramm-Slot)
Für das Training muss immer der Datenstand verwendet werden, der zu diesem Zeitpunkt wirklich bekannt war. So wird verhindert, dass spätere Informationen unbemerkt ins Training geraten. Für das Live-Scoring am Kassenband oder in der Filial-App kommen die Features aus einem Online-Store; Databricks bietet dafür Online Feature Stores mit Millisekunden-Latenz und automatischer Delta-CDF-Synchronisation. Auch ein eigener Online-Store mit Redis, DynamoDB oder Postgres funktioniert nach demselben Prinzip: die Offline-Wahrheit sitzt in Delta, die Online-Kopie hält die aktuelle Snapshot-Version fürs Serving.
Zwei Regeln sind im Betrieb besonders wichtig. Erstens: Features sollten immer für ein klares Zeitfenster gelten, nicht für irgendein einzelnes Sensorereignis. Zweitens: Jedes Feature sollte speichern, aus welcher Quelle es kommt und wann es zuletzt aktualisiert wurde, damit Alarme, die aus einem einzigen fehlenden Signal entstehen, im Trigger-Layer gefiltert werden können.
Wie erkennt man Phantom-Bestand?
Phantom-Bestand bedeutet: Im ERP steht noch Bestand, aber im Regal ist der Artikel nicht verfügbar. Die Ursachen sind bekannt: Diebstahl, Verräumfehler, Fehlbuchung im Wareneingang, Verderb, Umbuchungen ohne Systemabgleich. Das Problem: Das System bestellt nicht nach, weil rechnerisch noch Ware vorhanden ist. Kunden stehen trotzdem vor einem leeren Regal. Der SPS-Commerce-Report zu Phantom Inventory beschreibt genau dieses Muster als „silent profit killer". Oft fällt das erst auf, wenn Umsatz fehlt oder die Filiale manuell eingreift. Intel und Vispera dokumentieren, dass in Filial-Piloten bis zu zwei Drittel der fehlenden Artikel physisch in der Filiale liegen, nur eben nicht im Regal.
Phantom-Bestand lässt sich über drei Ansätze erkennen.
Nullumsatz trotz positivem Bestand
Verkauft sich ein stark drehender Artikel über Stunden nicht, obwohl Bestand vorhanden ist, ist das ein Warnsignal. Schnell umsetzbar, aber bei Long-Tail-Artikeln fehleranfällig.
Abweichung zwischen Sensor und ERP
Zeigt der Sensor null und das ERP Bestand, geht die Empfehlung an Store Ops zur Bestätigung, statt den Bestand automatisch zu ändern. Das ERP bleibt Owner der Bestandswahrheit.
Anomalie-Modelle für große Filialnetze
Federated Learning mit lokalen Autoencodern pro Filiale erkennt Abweichungen über den Rekonstruktionsfehler, ohne Rohdaten abfließen zu lassen. Lohnt sich erst mit MLOps-Reifegrad.
Die passende Aktion ist meist eine Bestandskorrektur-Empfehlung in der Filial-App. Falls nötig, kommt ein Zählauftrag dazu. Erst nach der Korrektur greift der Nachbestell-Trigger. Sonst schreibt das System eine Bestellung gegen einen Bestand, der real gar nicht null ist.
Wo Computer Vision für Regalverfügbarkeit funktioniert, und wo nicht
Computer Vision kann aus Regalbildern erkennen, wie voll ein Regal ist und ob Lücken sichtbar sind. Der Vision-Group-Retail-Leitfaden beschreibt das Ergebnis als „Realogramm". Dabei wird die tatsächliche Regalbelegung mit dem Planogramm verglichen. Für den Betrieb sind drei Schritte wichtig.
Datenerhebung und Annotation
Reflexionen, Schatten, gestapelte Produkte und ähnliche Verpackungen senken die Genauigkeit gegenüber dem Labor um 5 bis 15 Prozent. Das Modell braucht echte Filialbilder und lesbare Klassennamen wie empty-facing statt 100-O-O-S.
Modell-Architektur
Ein zweistufiger Ansatz reicht meist: Object-Detection (YOLO oder RF-DETR) findet leere Regal-Bereiche und Preisschilder, ein Klassifikator ordnet Verpackungen der SKU zu. Bei ähnlichen Verpackungen liegt der Engpass in der Klassifikation, die Detection läuft meist zuverlässig.
Edge vs. Central
Einfache Lückenerkennung läuft direkt auf der Kamera. Für Multi-Kamera-Auswertung und Planogramm-Compliance läuft das Modell zentral über Databricks Model Serving, MLflow und Lakehouse Monitoring mit automatischem Retraining bei Drift.
Die wichtigste Datenschutzregel: keine Personenerkennung. Face-Recognition-Modelle sind ausgeschlossen, Kunden-Track-Signale und Pfad-Analysen ebenfalls. Der Trainings-Datensatz enthält Regal-Bilder ohne Personen, oder Personen werden vor der Ablage gepixelt oder ausgeschnitten. Kamerapositionen zeigen das Regal auf Fläche und Facing, ohne den Gang mit Kundenfluss zu erfassen. Ohne diese Trennung wird aus einem Regalverfügbarkeitsprojekt schnell ein Datenschutzproblem.
Wie werden aus OSA-Signalen Nachbestell-Trigger?
Ein OSA-Datenprodukt ohne Aktion bleibt am Ende nur ein besserer Report. Der Nutzen entsteht erst, wenn eine erkannte Lücke eine konkrete Aufgabe auslöst: einem Verräum-Auftrag an einen Store Associate, einem Bestandskorrektur-Ticket, einer Nachbestellung in der Warenwirtschaft. Das Signal sollte eine Aktion in der Filial-App, im ERP oder beim Lieferanten auslösen, nicht nur eine Auswertung.
Die Logik sollte stufenweise prüfen, was zu tun ist. Erste Frage: Gibt es den Artikel noch im Lager oder im Pufferbestand? Wenn ja, wird ein Verräumauftrag in der Filial-App erstellt. Der Trigger schreibt dabei in ein Task-Management-Backend (Salesforce Field Service, ServiceNow, eigene Filial-App), noch nicht in die Warenwirtschaft. Zweite Frage: Ist der Artikel sowohl im System als auch physisch nicht verfügbar? Dann kann ein Nachbestellvorschlag an das ERP oder den Lieferanten gehen.
Die Absicherung ist der schwierige Teil. Ein ungebremster Trigger erzeugt schnell doppelte Aufgaben, unnötige Nachbestellungen und Überreaktionen in der Lieferkette: kleine Nachfrage-Schwankungen erzeugen große Überbestellungen upstream. Drei Schutzregeln sind besonders wichtig.
- Order-Batching und Frequenz-Limits. Statt bei jedem Trigger eine Bestellung zu erzeugen, aggregiert das System pro SKU und Filiale auf ein tägliches oder halb-tägliches Fenster. Doppel-Auslösungen im selben Fenster werden zu einer Empfehlung zusammengefasst.
- Promo-Kontext im Modell. Nachfrage-Spitzen aus Trade Promotions und Preis-Aktionen dürfen nicht als struktureller Nachfrage-Shift interpretiert werden. Der Trade-Kalender fließt als Feature in die Regel-Logik; wie sich Aktions-Regalpräsenz und -Compliance messen lassen, zeigen wir in Trade Promotion Effectiveness.
- Physische Bestätigung vor Nachbestellung. Eine Nachbestellung sollte nur ausgelöst werden, wenn die Regallücke durch Sensorik, Computer Vision oder eine manuelle Prüfung bestätigt wurde. Sonst bestellt das System gegen Phantom-Bestand nach, obwohl die Ware im Backroom liegt. Bei Überbestand-Risiko übernimmt die Markdown-Steuerung; die Entscheidungslogik dafür beschreiben wir in Dynamic Pricing im Einzelhandel.
Für Lieferanten-Kollaboration lohnt sich der Blick auf Delta Sharing als Kanal. Der OSA-Feature-Layer und Out-of-Stock-Risiko-Prognosen können gezielt für ausgewählte CPG-Partner freigegeben werden, ohne Rohdaten zu duplizieren. Das verkürzt die Reaktionszeit für Direct Store Delivery und macht den Nachbestell-Trigger auch upstream sichtbar.
Wer sollte Owner eines OSA-Datenprodukts sein?
Die Ownership entscheidet, ob OSA produktiv betrieben wird oder als POC liegen bleibt. Category Management sieht die Lücke, IT betreibt die Hardware, Store Ops verräumt die Ware und das Data-Team baut die Pipeline. Ohne klare Verantwortung bleiben Sensorfeeds liegen, Modelle veralten und Trigger brechen, sobald sich Schnittstellen ändern.
Praktisch sollte das Data-Team im Handelsbereich Owner des OSA-Datenprodukts sein. Der Owner definiert Metriken, Datenverträge, Feature-Layer, Modelle und die Schnittstelle für Trigger. Store Ops und Category Management nutzen das Produkt und definieren die fachlichen Anforderungen. Sensorik-Auswahl bleibt bei IT und Store Ops; das Data-Team spezifiziert die Signal-Verträge (Payload, Latenz, Retention) und akzeptiert, was diese Verträge einhalten kann.
Drei SLOs sind für den Betrieb besonders wichtig.
Datenfrische
99,5 Prozent aller Signal-Events müssen binnen 10 Minuten von der Bronze-Ingestion in der Silver-Feature-Tabelle stehen.
Serving-Verfügbarkeit
Der Online-Feature-Store-Endpoint bleibt zu 99,9 Prozent monatlich verfügbar; sonst fällt die Filial-App auf den letzten validen Snapshot zurück.
Signalqualität
Mehr als 5 Prozent unerklärte Sensor-System-Deltas in einer Filiale lösen ein wöchentliches Review aus, sonst wachsen die Fehlalarme.
Nach außen sollte das SLA einfacher formuliert sein: 98 Prozent der OSA-Signale werden binnen 15 Minuten nach Beobachtung als aktions-fähiges Feature zur Verfügung gestellt. Für eine Category-Sichtung reicht das; für eine Kassenband-Aktion nicht. Niedrigere Latenz-Anforderungen müssen den entsprechenden Signalpfad extra vertraglich absichern.
Wo OSA an Grenzen stößt
OSA macht Regalverfügbarkeit messbar und nutzbar. Für einen belastbaren Business Case reicht das aber nicht allein. Mehrere Grenzen sollten vor dem Rollout klar sein.
Sensorik-Auswahl bleibt eigene Entscheidung
Welche RFID-Frequenz, Kamera-Auflösung oder Sensor-Genauigkeit passt, ist zuerst eine Hardware- und Store-Ops-Frage. Die Datenplattform kann nur so gut sein wie die Signale, die Sensorik und Systeme liefern.
Kein Ersatz für Warenwirtschaft
Buchbestand, Wareneingang und Bestandsführung bleiben im ERP. Das Datenprodukt schlägt Bestandskorrekturen vor, Owner der Bestandswahrheit bleibt das Warenwirtschaftssystem.
CV-Modelle brauchen Trainingsdaten pro Sortiment
Ein Modell fürs Getränkeregal funktioniert nicht automatisch im Frischwareregal. Jede Warengruppe und jeder Regaltyp braucht einen eigenen Trainingszyklus mit echten Filialbildern, laufender Aufwand, den die Projektphase nicht abdeckt.
DSGVO bei Video
Personenerkennung gehört nicht in OSA. Kameras und Modelle müssen so ausgerichtet sein, dass Personen nicht erfasst werden, sonst übersteigt der Datenschutzaufwand schnell den Nutzen.
Nachbestell-Automatisierung braucht ERP-Freigabe
Ein Trigger ohne Freigabe wird vom ERP blockiert oder erzeugt Fehlbestellungen. Der Rollout braucht ein abgestimmtes Freigabe-Fenster, Human-in-the-Loop für die ersten Wochen und ein klares Fehlalarm-Budget.
Sollbestand, Abschriften und Aktionsprüfung sind eigene Themen
OSA zeigt die Lücke, aber nicht den Sollbestand, die Bestellmenge oder ob eine Markdown die klügere Aktion wäre. Diese Entscheidungen kommen aus Demand Forecasting, Dynamic Pricing und Trade Promotion Effectiveness.
Wenn diese Grenzen sauber geklärt sind, kann das Datenprodukt funktionieren. Wenn eine davon unklar bleibt, verwaist es zwischen Teams. Sobald der Rollout auf mehrere Filialen skaliert, gehören Feature-Layer, Modell-Registry und Trigger-Job in eine überwachte Pipeline mit reproduzierbaren Runs. Nicht in verstreute Notebooks.
Fazit
On-Shelf Availability wird erst zum Datenprodukt, wenn Signal-Fusion, Phantom-Bestand-Erkennung und Trigger-Logik beim Data-Team liegen, nicht bei einem einzelnen Sensor-Piloten.
OSA lohnt sich besonders, wenn bereits mehrere Signalquellen vorhanden sind, diese aber noch getrennt laufen. Mindestens zwei Signalquellen sollten produktiv verfügbar sein. Sonst bleibt OSA oft nur eine bessere POS-Heuristik. Für kleine Filialnetze mit wenigen schnell drehenden Artikeln kann eine einfache POS-Näherung ausreichen. Bei größeren Filialnetzen und schnell drehenden Sortimenten (FMCG, Getränke, Frischware) lohnt sich der Aufwand für Signal-Fusion, Phantom-Bestand-Erkennung und Trigger eher.
Drei Faktoren entscheiden über die Qualität:
- Die Signal-Fusion im Feature-Layer entscheidet, ob False Positives und False Negatives beherrschbar bleiben.
- Die Triggerlogik entscheidet, ob die Warenwirtschaft die Automatisierung akzeptiert oder blockiert.
- Klare Ownership entscheidet, ob das Produkt betrieben wird oder als POC liegen bleibt.
Mein Vorschlag: OSA als eigenes Datenprodukt beim Data-Team aufbauen. Der erste Schritt sollte POS plus mindestens eine Sensorquelle, ein Feature-Layer und ein einfacher Trigger sein. Der Pilot sollte klein starten: wenige schnell drehende Artikel, eine Referenzfiliale und eine klare Sensorquelle; Phantom-Bestand-Erkennung als erster messbarer Business-Case; Computer Vision nur dann ergänzen, wenn Regaltyp und Sortiment den Aufwand rechtfertigen. Die Sensorik-Auswahl bleibt bewusst außerhalb. IT und Store Ops klären die Hardware. Das Datenprodukt verarbeitet die Signale, die daraus zuverlässig entstehen.
Erster Schritt: Signalquellen, Feature-Layer und Trigger-Logik im Data-&-AI-Assessment prüfen lassen.
Regalverfügbarkeit strukturiert als Datenprodukt aufbauen
Ob OSA bei euch schon als Datenprodukt sinnvoll ist oder zuerst Signale, Sensorik und ERP-Anbindung geklärt werden müssen, lässt sich in einem Data & AI Assessment prüfen.
- Welche Signalquellen bereits produktiv laufen und welche Daten noch in Vendor-Portalen liegen
- Welche Daten-, Governance- und ERP-Risiken vor der Automatisierung geprüft werden sollten
- Wie ein sinnvoller Weg von der Referenzfiliale zum Rollout über das Filialnetz aussehen kann
FAQ
On-Shelf Availability beschreibt, ob gelistete Artikel zu einem bestimmten Zeitpunkt physisch am richtigen Regalplatz verfügbar sind. Der Buchbestand im ERP oder eine Palette im Backroom zählt nicht. Als Datenprodukt führt OSA POS-Daten, ERP-Bestand, RFID, Smart Shelf, Computer Vision und Planogramm pro Filiale und Artikel zusammen.
