Ein RFID-Lesegerät misst keinen Bestand. Es beobachtet Funkereignisse: Zehn- bis zweihundertmal pro Sekunde meldet es, dass irgendein Etikett für irgendeine Antenne sichtbar war — ohne zu wissen, ob dieses Etikett im Regal, in der Tasche eines Kollegen, im Laderaum eines Transporters oder auf dem Boden des Nachbargangs liegt.

Das ERP dagegen braucht Aussagen: dieser SKU, an diesem Standort, Menge plus eins. Zwischen Beobachtung und Aussage entscheidet sich die Bestandsgenauigkeit, und keine Lesegeräteinstellung schließt diese Lücke. Sie lässt sich nur durch bewusste Data Governance schließen.

Warum RFID-Daten scheitern, bevor das ERP sie sieht

Fünf Mechanismen erzeugen fast alle schlechten Daten, und keiner davon ist ein Softwarefehler.

Mehrfachlesungen: Ein Etikett im Lesefeld wird dutzendfach pro Sekunde gemeldet. Ohne Unterdrückung wird aus einem Kleidungsstück vierzig Bewegungen.
Überlappende Zonen: Zwei Antennen decken dieselbe Tür ab, und derselbe Karton wird zwei Standorten zugerechnet.
Fehllesungen: In dichten Paletten sind 10 bis 20 % der Etiketten bei einer Vorbeifahrt unsichtbar. Eine Fehllesung ist von einem fehlenden Artikel nicht zu unterscheiden.
Veraltete Etiketten: Ein Etikett auf einem entsorgten Karton, in einer Rückgabekiste oder auf dem Boden einer Umkleide strahlt weiter einen Standort aus, der nicht mehr stimmt.
Menschlicher Prozess: Etiketten am falschen SKU, zur falschen Zeit oder für zwei Artikel wiederverwendet.

Die vier Fehlerklassen: Duplikate, Geister, Fehllesungen und Zustandsfehler

Klassifizieren Sie die Fehler, bevor Sie sie beheben wollen, denn jede Klasse braucht eine andere Kontrolle.

Duplikate: Derselbe physische Artikel erzeugt innerhalb eines Fensters mehr als ein Geschäftsereignis.
Geister: Ein Ereignis verweist auf einen Artikel, der physisch nicht am Standort ist — veraltetes Etikett, Nachbarzone oder zurückgelassenes Etikett.
Fehllesungen: Der Artikel ist vorhanden, erzeugte im Zählfenster aber kein Ereignis.
Zustandsfehler: Jedes einzelne Ereignis ist gültig, die Reihenfolge ist unmöglich — Abgang vor Zugang, oder zwei Standorte beanspruchen denselben Artikel.

Duplikate und Geister blähen den Bestand auf, Fehllesungen drücken ihn, und Zustandsfehler beschädigen die Historie. Letzteres ist schlimmer, weil der Fehler in jede künftige Berechnung weiterläuft.

Deduplizierung: Regeln, die Überlappungen überstehen

Deduplizieren Sie auf drei Ebenen und bewahren Sie das Rohprotokoll, damit jederzeit neu abgeleitet werden kann.

Zeitfenster: Derselbe EPC am selben Lesegerät innerhalb von N Sekunden zählt einmal. N liegt an einem Tor bei 3 bis 10 Sekunden, auf einem langsamen Förderband bei 30 bis 60.
Raumgruppe: Antennen, die dieselbe physische Zone abdecken, bilden eine Gruppe. Ein Etikett, das drei Antennen dieser Gruppe sehen, ist ein Ereignis, nicht drei.
Geschäftsfenster: Derselbe EPC am selben Standort innerhalb eines gleitenden Fensters, oft 10 bis 30 Minuten, zählt einmal — auch über verschiedene Lesegeräte hinweg.

Speichern Sie die Rohlesungen. Projizieren Sie die deduplizierten Ereignisse in eine eigene Tabelle und behandeln Sie diese Projektion als neu berechenbar. Wenn eine Regel falsch ist, ändern Sie die Regel und spielen erneut ein, statt im ERP nach beschädigter Historie zu suchen.

Validierung am Rand gegenüber Validierung im Kern

Teilen Sie die Validierung danach auf, was jede Schicht preiswert wissen kann.

Am Rand: EPC-Format, Prüfsumme, Firmenpräfix, TID-Präsenz, Identität von Lesegerät und Antenne, Plausibilität des Zeitstempels. Das weist fehlerhafte Lesungen ab, bevor sie Bandbreite verbrauchen.
Im Kern: Existiert der SKU, ist der Standort gültig, ist die Menge nicht negativ, ist der Übergang für diesen Vorgangstyp zulässig, ist der Benutzer berechtigt.
Validieren Sie niemals Kernregeln am Rand. Der Rand kennt den Artikelstamm nicht, und sobald er ihn zu kennen versucht, cached er veraltete Stammdaten.

Eine brauchbare Regel: Der Rand weist Physikfehler ab, der Kern weist Geschäftsfehler ab. Alles, was keines von beidem ist — eine plausible Lesung eines echten Etiketts an einem echten Standort — muss akzeptiert oder ausdrücklich quarantänisiert werden, niemals stillschweigend verworfen.

Ausnahmenbehandlung: Quarantäne, SLA und menschlicher Workflow

Ausnahmen verschwinden nicht, weil niemand sie ansieht. Geben Sie ihnen einen Ort.

Leiten Sie jeden fehlgeschlagenen Datensatz in eine Quarantänetabelle mit Ursachencode, Rohdaten und Zeitstempel.
Veröffentlichen Sie täglich eine Anzahl je Ursachencode. Ein Code, der drei Tage wächst, ist ein Designproblem und kein Bedienerproblem.
Definieren Sie im ERP einen Prüfstatus: automatisch akzeptiert, zu prüfen, abgelehnt. Nur der mittlere Zustand kostet menschliche Zeit.
Setzen Sie die SLA in Stunden, nicht in Tagen. Eine Ausnahme älter als 48 Stunden ist meist schon eine physische Differenz.
Jede manuelle Übersteuerung muss mit Benutzer, Begründung und ursprünglichem Wert protokolliert werden, sonst wird das Governance-System zur nächsten Quelle schlechter Daten.

Kennzahlen, die einen gesunden Datenpfad belegen

Sechs Zahlen, wöchentlich geprüft, fangen fast alles ab, bevor der Monatsabschluss es tut.

Lesequote je Zone: erfolgreiche Lesungen geteilt durch erwartete Artikel in einem kontrollierten Test. Unter 95 % an einem Tor reparieren Sie die Antenne, bevor Sie die Datenschicht beschuldigen.
Duplikatverhältnis: Rohlesungen geteilt durch deduplizierte Ereignisse. Ein steigender Wert bedeutet Antennenüberlappung oder eine ausfallende Unterdrückungsregel.
Quote unbekannter Etiketten: EPCs ohne passenden SKU. Diese Zahl misst direkt die Etikettierungsdisziplin und die Konfiguration des Firmenpräfix.
Latenz p95 von der Lesung bis zum ERP-Beleg. Driftet das p95, läuft die Warteschlange voll und die Rückstandsregel beginnt, Ereignisse zu verlieren.
Korrekturquote: manuelle Bestandskorrekturen im Verhältnis zu allen Bewegungen. Das ist die ehrliche Messung, ob RFID die menschliche Korrektur ersetzt.
Ausnahmenalter: durchschnittliche Stunden, die eine Ausnahme offen bleibt. Diese Kennzahl sagt den Schmerz am Monatsende besser voraus als jede andere.

Betriebsmodell: Wem gehören die Daten?

Governance scheitert, wenn sie niemandes Aufgabe ist, und gelingt, wenn sie die Aufgabe einer benannten Person ist.

Ein Data Steward verantwortet Regeln, Ursachencodes und die Wochenprüfung. Nicht das IT-Team, das die Strecke besitzt, aber nicht die Semantik.
Der Betrieb verantwortet die Etikettierqualität und die Sauberkeit der Lesegeräte. Ein verschmutztes Antennenfenster erklärt mehr Fehllesungen als jede Softwareeinstellung.
Die Finanzabteilung verantwortet die Korrekturpolitik und zeichnet die Toleranzschwellen ab.
Die Prüfbesprechung dauert 30 Minuten, findet wöchentlich statt und betrachtet immer dieselben sechs Kennzahlen.

Fazit

Lesegeräte erzeugen Ereignisse, das ERP braucht Entscheidungen. Die Schicht dazwischen ist selbst ein Produkt und verdient denselben Designaufwand wie das Antennenlayout.

Klassifizieren Sie Fehler, bevor Sie sie beheben.
Deduplizieren Sie in Zeit, Raum und Geschäft und bewahren Sie das Rohprotokoll.
Validieren Sie Physik am Rand und Geschäftsregeln im Kern.
Geben Sie jeder Ausnahme einen Ort, einen Verantwortlichen und eine SLA.
Prüfen Sie sechs Kennzahlen wöchentlich und behandeln Sie eine steigende Zahl als Designs Signal.

Dann wird Bestandsgenauigkeit eine Eigenschaft des Systems statt einer monatlichen Debatte.