Hardware ist selten der Grund, warum ein RFID-Programm scheitert. In den Nachbetrachtungen, die ich gelesen habe, waren die Lesegeräte installiert, die Etiketten angebracht und das Tor erkannte zu 97 % korrekt. Das Projekt starb trotzdem — meistens in der Tabelle, in der jemand die versprochene Ersparnis mit der tatsächlichen verglich.

Das sind die zehn Stolperfallen, die den Großteil dieser Enttäuschung erklären, gruppiert nach der Phase, in der sie auftreten.

Fallen 1 und 2: Hardware vor Prozess, Kapazität vor Bedarf

Der teuerste Fehler ist der erste, weil alles Nachgelagerte ihn erbt.

Lesegeräte kaufen, bevor der Prozess definiert ist: Ein Lesegerät ist eine Komponente, keine Lösung. Solange Sie nicht sagen können, welche Geschäftsentscheidung die Lesung auslöst — Wareneingang, Ausnahme, Nachbestellsignal —, ist jede Hardwarewahl eine Vermutung.
Für Spitzenlast dimensionieren, die es nicht gibt: Teams kaufen Acht-Port-Leser für ein Tor, das nie mehr als 60 Kartons pro Stunde sieht. Die zusätzlichen Ports kosten Geld und verleiten zu Antennenlayouts, die Interferenzen erzeugen. Dimensionieren Sie nach gemessenem Volumen plus 50 %, nicht nach der Konferenzfolie.

Fallen 3 und 4: Etikettdisziplin und die 5 %, die alles vergiften

Die Etikettierung ist unspektakulär, unterfinanziert und entscheidend.

Annehmen, der Lieferant etikettiere korrekt: Quellen-Etikettierung funktioniert nur, wenn die Position millimetergenau spezifiziert, die SKU-EPC-Zuordnung validiert und je Lieferung eine Stichprobe geprüft wird. Sonst erben Sie 5 % Fehlerquote, die still die gesamte Personaleinsparung auffressen.
EPCs wiederverwenden: Rest- und Recyclingkennungen sind der schnellste Weg, die Bestandshistorie zu beschädigen. Ein EPC muss für die Lebensdauer des Artikels eindeutig sein und mit ihm auslaufen, nicht an die nächste Kiste weitergegeben werden.

Fallen 5 und 6: Antennenlayout und das Tor, das niemand getestet hat

Die Physik ist unbarmherzig und kümmert sich nicht um das Rendering im Angebot.

Die Lesezone auf Papier entwerfen: Die Zeichnung zeigt eine saubere Zwei-Meter-Zone. Die Realität enthält ein Metallrolltor, einen Stapler, der im Strahl parkt, und den Nachbargang. Testen Sie mit echten Paletten, echter Folie und echtem Verkehr über eine ganze Schicht.
Die Nachbarzone ignorieren: Das häufigste Support-Ticket nach dem Start sind Geisterlesungen aus dem Nebenraum. Eine zusätzliche Antenne ist billiger als drei Monate umstrittener Zählungen.

Fallen 7 und 8: Integrationsabkürzungen und der fehlende Ausnahmenverantwortliche

Das Projekt überlebt meist den Start und scheitert im zweiten Monat, und zwar hier.

Direkt ins ERP schreiben: Datenbankschreibzugriffe oder Middleware, die Mengen statt Belege bucht, umgehen den Prüfpfad und brechen beim ersten Upgrade. Reichen Sie Belege ein und lassen Sie die ERP-Logik entscheiden.
Niemand ist für Ausnahmen zuständig: Jede Einführung erzeugt 1 bis 5 % nicht automatisch auflösbarer Lesungen. Schließt sie keine benannte Person innerhalb einer definierten SLA, sammeln sie sich an, bis das Team dem System nicht mehr traut — und ein System, dem niemand traut, wird abgeschaltet.

Falle 9: der Pilot, der nichts beweist

Ein Pilot in einem Gang, mit einer Antenne, vom Projektteam durchgeführt, beweist, dass RFID funktioniert. Er beweist nicht, dass Ihr Betrieb mit RFID funktioniert.

Ein brauchbarer Pilot hat eine Kontrollgruppe, eine vor der Etikettierung gemessene Baseline und mindestens vier Wochen Laufzeit inklusive eines Monatsabschlusses.
Er misst die sechs Kennzahlen, die zählen: Lesequote, Duplikatverhältnis, Quote unbekannter Etiketten, Latenz, Korrekturquote und Ausnahmenalter.
Er bezieht die Menschen ein, die das System nutzen werden, nicht nur die, die es installieren.

Falle 10: der Business Case auf einer einzigen Zahl

Wenn die gesamte Begründung Personaleinsparung ist, wird das Projekt im Quartal nach der ersten Personalprüfung gestrichen.

Modellieren Sie mindestens drei Nutzenströme — Personal, Bestandsgenauigkeit, Verfügbarkeit — und weisen Sie jeden getrennt aus.
Präsentieren Sie das pessimistische Szenario, nicht das optimistische. Ein Business Case, der nur bei 100 % Akzeptanz funktioniert, ist keiner.
Rechnen Sie die laufenden Kosten des zweiten Jahres ein: Etiketten, Reparaturen, Software und die Person, die jetzt die Daten verantworten muss.

Was funktionierende Einführungen stattdessen tun

Das Muster ist über die erfolgreichen Projekte hinweg konsistent.

Von einer Geschäftsentscheidung ausgehen, die heute falsch ist, nicht von einer Technologie, die heute interessant ist.
Eine kleine, geschlossene Grundgesamtheit vollständig etikettieren statt einer großen teilweise.
Vor dem ersten Etikett eine Baseline messen; ohne sie ist jede spätere Aussage eine Meinung.
Für die langweiligen Teile budgetieren: Etikettierung, Antennentests, Ausnahmenbehandlung.
Die Abbruchkriterien vor dem Pilot definieren und bereit sein, wirklich zu stoppen.