Warum RFID-Projekte scheitern und wie Sie es vermeiden

Warum RFID-Projekte meist vor der Technik scheitern

RFID-Projekte scheitern selten daran, dass die Basistechnologie untauglich wäre. Meist scheitern sie daran, dass Unternehmen von RFID eine Art Magie erwarten, das Budget wie für ein Barcode-Upgrade planen und mit der Einführung beginnen, bevor die unspektakuläre Vorarbeit erledigt ist, die ein funktionierendes System überhaupt erst möglich macht. Auf dem Papier wirkt eine RFID-Implementierung einfach: RFID-Tags auf Artikel anbringen, RFID-Reader installieren, Daten mit der Software verbinden und Echtzeittransparenz gewinnen. In der Praxis reflektiert Metall jedoch Funksignale, Flüssigkeiten dämpfen sie, Mitarbeitende kürzen Abläufe ab, Stammdaten sind unvollständig und das Management erwartet Ergebnisse, noch bevor der Pilot eine stabile Leserate erreicht hat. Genau in dieser Lücke zwischen Präsentationsfolie und Lagerboden geraten viele RFID-Projekte ins Wanken.

Ein Käufer, mit dem wir bei SCIVAS gearbeitet haben, kam nach einem enttäuschenden RFID-Rollout einer regionalen Modehandelskette zu uns. Das Unternehmen hatte günstige Tags, feste Reader und Software von drei unterschiedlichen Anbietern beschafft und angenommen, die Komponenten würden schon automatisch zusammenspielen. Für die Systemintegration fühlte sich niemand eindeutig verantwortlich. Die Filialen lasen Kartons am Hintereingang, das ERP erwartete Bewegungen auf Artikelebene, und die Middleware enthielt keine sauberen Geschäftsregeln für Ausnahmen. Das Projekt scheiterte nicht, weil die Tags defekt waren. Es scheiterte, weil die RFID-Einführung wie ein Hardwarekauf behandelt wurde und nicht wie ein operatives System. Nachdem der Prozess abgebildet, ein gültiges Leseereignis neu definiert und die erste Phase auf die Bestandsverfolgung im Lagerbereich begrenzt wurde, lieferte dieselbe Technologie plötzlich nutzbare Daten.

Mit einem messbaren operativen Ziel starten

Genau hier liegt oft das erste große Problem: Unternehmen starten mit dem falschen Ziel. Sie sagen, sie wollen mehr Transparenz, doch Transparenz ist kein operatives Ziel. Sie ist eine Richtung. Ein echtes Ziel klingt konkreter: die Zeit für manuelle Inventuren um 70 Prozent senken, die Bestandsgenauigkeit von 84 auf 97 Prozent erhöhen, Wareneingangsdifferenzen reduzieren oder fehlende Mehrwegassets innerhalb von zehn Minuten lokalisieren. Ist das Ziel unklar, kann das Projektteam weder Tag-Typ noch Reader-Positionierung, Softwarelogik oder Erfolgskriterien sinnvoll festlegen. Ein RFID-System im Lager zur Palettenprüfung wird anders ausgelegt als Item-Level-RFID im Einzelhandel, Asset Tracking im Krankenhaus oder Rückverfolgbarkeit in der Fertigung. Der Anwendungsfall ist kein Detail. Er ist das Projekt.

Wenn der Anwendungsfall zu breit gefasst ist

Ein solches Beispiel haben wir bei einem Werkzeugmanagement-Programm eines Industrieunternehmens gesehen. Das Management sprach von Asset Tracking, meinte aber eigentlich die Verantwortlichkeit für hochwertige Drehmomentwerkzeuge, die immer wieder zwischen Fahrzeugen, Baustellen und temporären Lagerräumen verschwanden. Der erste Vorschlag sah weitreichende Portalreader an den Werktoren vor. Das klang eindrucksvoll, löste aber das tägliche Problem kaum. Nach einigen Workshops wurde der Umfang angepasst. Statt alles überall verfolgen zu wollen, kennzeichnete das Unternehmen die am häufigsten verlorenen Werkzeuge, stattete Bauleiter mit RFID-Handheld-Readern aus und verknüpfte die Scanereignisse mit der Ausgabeverantwortung. Die Verluste gingen zurück, weil das Projekt endlich zum tatsächlichen operativen Schmerzpunkt passte.

RFID-Tags nach Material und Bewegung auswählen

Ein weiterer häufiger Grund für das Scheitern von RFID-Projekten ist die falsche Tag-Auswahl. Manche Einkäufer gehen davon aus, dass jedes UHF-RFID-Tag auf jedem Produkt funktioniert. Das ist, als würde man annehmen, jeder Reifen sei für jede Straße und jede Jahreszeit geeignet. Die Tag-Leistung hängt vom Material, der Artikelgröße, der Ausrichtung, der Befestigung, der Lesedistanz, der Umgebung und sogar von der Packdichte ab. Ein Tag, das auf Wellpappkartons sehr gut funktioniert, kann auf Metallwerkzeugen versagen. Ein Etikett, das auf trockener Bekleidung zuverlässig gelesen wird, kann bei Kosmetik, Getränken oder medizinischen Flüssigkeiten deutlich schlechter abschneiden. Das ist keine technische Randnotiz, sondern einer der Hauptgründe, warum Pilotversuche häufig besser aussehen als der spätere Live-Betrieb.

Warum Pilotbedingungen dem echten Standort entsprechen müssen

Ein Händler für Automobilkomponenten musste diese Lektion teuer lernen. Im Pilotprojekt wurden ordentlich gepackte Kartons in einem Testraum verwendet, und die Leserate war stark. Das reale Lager zeigte ein anderes Bild. Tatsächliche Produkte enthielten Folienbeutel, ölige Metallteile, gemischte Palettenkonfigurationen und Staplerbewegungen, die die Lesewinkel ständig veränderten. Zunächst gab das Unternehmen der Reader-Leistung die Schuld, dann der Software und schließlich dem Personal. Das eigentliche Problem war, dass das ursprüngliche RFID-Tag nie für den realen Verpackungsmix qualifiziert worden war. Nach dem Wechsel auf ein Tag für schwierige Materialien, einer erneuten Standortanalyse und der Trennung der Prüfspur vom allgemeinen Verkehr verbesserte sich die Lesegenauigkeit schnell. Nicht RFID war gescheitert. Gescheitert war der Versuch, eine ideale Testwelt in eine unübersichtliche Realität zu übertragen.

Die physische Umgebung vor den Daten kontrollieren

Auch Standortbedingungen sind ein stiller Projekttreiber. Viele Teams sprechen gern über Chip-Speicher, EPC-Standards und Dashboard-Funktionen, doch viele RFID-Projekte entscheiden sich in der physischen Umgebung. Reader-Antennen dürfen nicht nach Bauchgefühl platziert werden. Portalgeometrie ist wichtig. Fördergeschwindigkeit ist wichtig. Metallregale in der Nähe sind wichtig. Dichte Reader-Zonen können Querlesungen erzeugen. Türen mit unkontrolliertem Verkehr können Fehlbuchungen auslösen. Wer eine saubere Standortanalyse überspringt und direkt installiert, lädt zufälliges Verhalten praktisch ein. Danach überrascht es nicht, wenn sich das System auch zufällig verhält.

Wir arbeiteten mit einem Verpackungshersteller, der Dock-Door-Portale zur automatisierten Versandprüfung installierte. Am ersten Tag wirkte das System zwar aktiv, aber unzuverlässig. Es las Stapler, die in der Nähe warteten, erfasste benachbarte Spuren und verfehlte einige ausgehende Paletten bei hoher Bewegung. Der ursprüngliche Integrator hatte Antennen dort montiert, wo die Verkabelung am einfachsten war. Nach der Überarbeitung grenzte das Unternehmen die Lesezone ein, passte Antennenwinkel an, ergänzte Abschirmungen und schrieb die Ereignislogik so um, dass eine Sendung nur bestätigt wurde, wenn der Palettenweg einem bekannten Bewegungsmuster entsprach. Plötzlich gingen die Fehlablesungen deutlich zurück. Das zeigt: RFID-Reader erzeugen nicht automatisch geschäftliche Wahrheit. Sie erzeugen Funkereignisse. Erst physische Disziplin und Softwaredisziplin machen daraus verlässliche Transaktionen.

Integration von Anfang an einplanen

Integrationsprobleme ruinieren ebenfalls viele RFID-Projekte. Ein RFID-System, das nicht sauber mit WMS, ERP, MES oder Instandhaltungssoftware kommuniziert, wird schnell zu einer isolierten Insel interessanter, aber wenig genutzter Daten. In einer Demo können Anwender beeindruckt sein. Sechs Monate später kehren sie dennoch zu Tabellen zurück, weil niemand die Arbeitsabläufe um die Daten herum aufgebaut hat. Gute RFID-Middleware sammelt nicht nur Tag-Lesungen. Sie filtert Rauschen, verarbeitet Ausnahmen, ordnet Lesungen Geschäftsobjekten zu und überträgt relevante Ereignisse in die Systeme, in denen die Mitarbeitenden ohnehin arbeiten. Ohne diese Ebene versinken Unternehmen in Rohdaten und klagen trotzdem über fehlende Transparenz.

RFID-Ereignisse brauchen geschäftlichen Kontext

Ein Vermieter medizinischer Geräte stellte dies fest, nachdem Infusionspumpen und Monitore über mehrere Service-Depots hinweg gekennzeichnet worden waren. Technisch konnte das Unternehmen Assets beim Ein- und Ausgang lesen. Das Betriebsteam konnte aber weiterhin nicht zuverlässig beantworten, wo sich ein Gerät befand und ob es verfügbar, in Wartung oder zur Reinigung vorgesehen war. Der Grund war einfach: Die RFID-Plattform wusste, dass ein Asset an einem Reader vorbeigegangen war. Das Wartungssystem kannte den Servicestatus. Die Mietplattform kannte die Kundenreservierung. Diese Systeme sprachen jedoch nicht dieselbe Sprache. Erst als das Datenmodell abgestimmt und Statusregeln zentralisiert wurden, hörte das Unternehmen auf, Phantomprobleme zu suchen, und nutzte RFID für echte Entscheidungen.

Nutzerakzeptanz nicht unterschätzen

Hinzu kommt die menschliche Seite, die viele technische Teams unterschätzen. RFID-Change-Management ist nicht glamourös, aber unverzichtbar. Wenn Mitarbeitende dem System nicht vertrauen, schaffen sie Umgehungslösungen. Wenn Wareneingangsteams glauben, RFID werde genutzt, um sie für jede Abweichung verantwortlich zu machen, bremsen sie die Einführung. Wenn Filialmitarbeitenden versprochen wird, Inventuren würden einfacher, der Kennzeichnungsprozess aber zunächst zusätzliche Arbeit ohne klaren Nutzen bringt, sinkt die Compliance. Selbst ein gut geplantes RFID-Projekt zur Bestandsverfolgung kann ins Stocken geraten, wenn die Menschen, die den Prozess täglich ausführen, erst am Ende berücksichtigt werden.

Eine Modemarke erlebte dies bei einem Item-Level-RFID-Rollout in fünfzig Filialen. Die Zentrale ging davon aus, dass die Filialteams den neuen Prozess lieben würden, weil Inventuren schneller liefen. Tatsächlich war der erste Monat für die Mitarbeitenden frustrierend. Sie mussten Ausnahmen neu etikettieren, beschädigte Labels aussortieren und einen neuen Nachschubprozess lernen, während die Verkaufsziele unverändert blieben. Einige Filialen ließen empfohlene Scanroutinen stillschweigend aus, wodurch die Bestandsgenauigkeit instabil wirkte. Das Projekt erholte sich erst, als Regionalmanager die Filialabläufe vereinfachten, kurze Schulungsvideos bereitstellten und die erste Erfolgskennzahl auf etwas legten, das dem Personal wirklich wichtig war: weniger zeitraubende Suchvorgänge im Lager während Stoßzeiten. Sobald Mitarbeitende spürten, dass das System ihnen half, statt sie zu bewerten, verbesserte sich die Einhaltung der Prozesse.

Die erste RFID-Phase bewusst klein halten

Scope Creep ist ein klassischer Weg, Projektenergie zu verlieren. Ein kluger RFID-Pilot startet fokussiert. Ein gefährdeter Pilot versucht dagegen, Wareneingang, Einlagerung, Inventur, Versandprüfung, Kundenretouren, Diebstahlschutz und automatische Nachschubplanung bereits in der ersten Phase zu lösen. Teams tun dies oft, weil sie die Investition mit einer großen Vision rechtfertigen wollen. Ironischerweise verzögert genau diese große Vision den Nutzen. Der schnellste Weg zum Wert besteht meist darin, einen messbaren Workflow auszuwählen, ihn zu beweisen, zu stabilisieren und dann zu erweitern.

Wir sahen dies bei einem Kunden aus der Lebensmittelverarbeitung, der Behälterverfolgung, Transparenz über Work-in-Progress, Kühlraumüberwachung und Rückverfolgbarkeit fertiger Waren in einem einzigen Start umsetzen wollte. Der ursprüngliche Zeitplan war unrealistisch. Das Werk hatte mehrere Produktlinien, Nassbereiche, Metallstrukturen und schichtabhängige Prozessvariationen. Der erste Workshop fühlte sich weniger wie Projektplanung an, sondern eher wie das Schreiben einer Wunschliste. Die Wende kam, als die Geschäftsleitung zustimmte, sich zunächst nur auf das Tracking von Mehrwegbehältern zwischen Verpackung und Versand zu konzentrieren. Dieses kleinere Projekt deckte Datenprobleme, Reader-Positionierungsfehler und operative Gewohnheiten auf, die eine breitere Einführung gefährdet hätten. Als RFID später auf die Prozessrückverfolgung ausgeweitet wurde, baute das Unternehmen auf einer stabilen Grundlage auf, statt zu hoffen, dass sich Komplexität von selbst organisiert.

Stammdaten bereinigen, bevor RFID kritisiert wird

Schlechte Daten können auch ein gutes RFID-Projekt defekt erscheinen lassen. Wenn Artikelstammdaten uneinheitlich sind, Verpackungshierarchien fehlen oder Lagerplatzcodes nicht zur Realität passen, macht das System Widersprüche schnell sichtbar. Das ist kein Systemversagen. Es ist die Offenlegung eines Problems, das durch manuelle Arbeit und geringe Transparenz bisher verborgen blieb. Manche Unternehmen geraten in dieser Phase in Panik, weil sie erwartet haben, dass mit dem RFID-Livegang automatisch saubere Daten entstehen. So funktioniert es nicht. RFID beschleunigt die Datenerfassung, kann aber keine Governance erfinden.

Ein Händler für Unterhaltungselektronik lieferte dafür ein gutes Beispiel. Das Unternehmen hatte seriennummerngeführte Produkte, gemischte Kartonmengen und häufige Etikettenänderungen durch Vertragspacker. Als Palettenlesungen nicht mit den erwarteten Sendungsinhalten übereinstimmten, ging das Projektteam zunächst von einer schwachen Leistung des RFID-Portals aus. Eine Prüfung zeigte jedoch, dass Stammdatenabweichungen das größere Problem waren. Die Kartons am Boden entsprachen nicht mehr den Verpackungsannahmen im WMS. Nachdem die Datensätze korrigiert und Regeln zur Kartonaggregation standardisiert wurden, ergaben die Leseereignisse plötzlich Sinn. RFID hatte die Inkonsistenz nicht geschaffen. Es hatte sie nur unmöglich gemacht, weiter zu ignorieren.

RFID-ROI mit den richtigen Signalen messen

Ein weiteres Problem ist ein unrealistisches ROI-Timing. Manche Führungskräfte erwarten die vollständige Amortisation nach wenigen Monaten, selbst in komplexen Umgebungen, in denen Prozessneugestaltung Teil der Arbeit ist. Dieser Druck führt dazu, dass Teams bei Tests, Schulungen und Middleware sparen, weil jede sichtbare Kostenposition reduziert werden soll. Danach bleibt das Projekt hinter den Erwartungen zurück, und das Management kommt zu dem Schluss, RFID funktioniere nicht. Tatsächlich hatte das Projekt nie die Struktur, die es zum Erfolg gebraucht hätte. Sinnvoller ist es, direkte Einsparungen von strategischen Vorteilen zu trennen. Direkte Einsparungen können aus weniger Arbeitsaufwand, weniger verlorenen Assets, höherer Versandgenauigkeit oder geringerem Schwund entstehen. Strategische Vorteile können schnellere Inventuren, bessere Nachschubsignale oder besseren Kundenservice umfassen. Beides zählt, reift aber nicht im gleichen Tempo.

Ein uns bekannter Logistikdienstleister wollte RFID nach sechs Monaten beinahe aufgeben, weil das Finanzteam keinen dramatischen Sofortertrag sah. Der Rollout betraf Mehrwegtransportmittel, die über mehrere Depots verteilt waren, und die Akzeptanz war noch uneinheitlich. Als das Unternehmen die richtigen Kennzahlen betrachtete, änderte sich das Bild. Es gab weniger Notkäufe fehlender Rollbehälter, weniger Streitfälle mit Subunternehmern und weniger manuelle Abstimmung an Übergabepunkten. Im ersten Dashboard war das kaum sichtbar, weil das ursprüngliche KPI-Set zu eng war. Als der Business Case nicht mehr nur über Arbeitsminuten, sondern über operative Verluste betrachtet wurde, wirkte das Projekt deutlich plausibler.

RFID-Anbieter wählen, die kritische Fragen stellen

Auch die Lieferantenauswahl ist entscheidend, allerdings nicht so simpel, wie oft angenommen wird. Die falsche Wahl ist nicht immer der günstigste Anbieter. Manchmal ist es der Anbieter, der einen reibungslosen Rollout verspricht, ohne schwierige Fragen zu stellen. Gute RFID-Lieferanten sind am Anfang etwas unbequem, weil sie Muster, Umgebungstests, Zielwerte für Lesereichweiten, Prozessabbildung und die Prüfung von Sonderfällen einfordern. Diese Reibung ist gesund. Wenn ein Anbieter bereit ist, eine komplette RFID-Lösung zu kalkulieren, ohne Materialien, Arbeitsabläufe, Softwareumgebung und Erfolgskriterien zu verstehen, sollte das ein Warnsignal sein.

So vermeiden Sie das Scheitern von RFID-Projekten

Der praktische Weg zur Vermeidung von RFID-Projektfehlern ist nicht geheimnisvoll. Beginnen Sie mit einem Geschäftsproblem, nicht mit einem Technologietrend. Definieren Sie den Workflow, die Nutzer, die Umgebung und die Entscheidung, die das System unterstützen soll. Bauen Sie den RFID-Piloten um einen engen und messbaren Prozess herum auf. Testen Sie mit realen Produkten, realen Verpackungen, realen Mitarbeitenden und realen Bewegungsbedingungen. Führen Sie eine professionelle Standortanalyse durch. Wählen Sie RFID-Tags nach Material und Anwendungsfall aus, nicht nur nach Stückpreis. Behandeln Sie Middleware und Systemintegration als Kerninfrastruktur, nicht als optionale Ergänzung. Bereinigen Sie Stammdaten frühzeitig. Schulen Sie Mitarbeitende in verständlicher Sprache. Messen Sie den Erfolg mit Geschäftskennzahlen, nicht nur mit Leseraten. Eine Leserate von 99 Prozent kann trotzdem zu einem enttäuschenden Projekt führen, wenn sie keinen echten Workflow verbessert.

RFID funktioniert am besten mit Prozessdisziplin

Hilfreich ist außerdem ein ehrlicher Blick darauf, was RFID leisten kann und was nicht. RFID eignet sich hervorragend, um gekennzeichnete Objekte ohne Sichtkontakt zu identifizieren, die Bestandsgenauigkeit zu verbessern, Asset Tracking zu unterstützen und in der passenden Umgebung manuelle Arbeit zu reduzieren. RFID ersetzt jedoch keine Prozessverantwortung, keine Softwarelogik und keine disziplinierten Abläufe. Wenn ein Unternehmen erwartet, dass RFID schwache Prozesse, unklare Verantwortlichkeiten und schlechte Datenqualität von allein repariert, ist Enttäuschung nahezu vorprogrammiert. Wird RFID dagegen als Teil eines gut gestalteten Betriebsmodells eingeführt, wird es häufig zu einem der praktischsten Transparenzwerkzeuge, die ein Unternehmen einsetzen kann.

Fazit

Genau darum geht es im Kern: RFID-Projekte scheitern weniger an Funkwellen als an Annahmen. Unternehmen nehmen an, dass das Ziel offensichtlich ist, Tags austauschbar sind, die Umgebung nachsichtig ist, Daten sauber sind, Mitarbeitende sich automatisch anpassen und der ROI auf Kommando erscheint. In der Realität darf nichts davon vorausgesetzt werden. Es muss geplant, getestet, gemessen und gesteuert werden. Unternehmen, die diese Realität respektieren, erzielen mit RFID in der Regel gute Ergebnisse. Unternehmen, die nur der Schlagzeile folgen und die Grundlagen überspringen, sagen am Ende oft, die Technologie habe nicht funktioniert. Tatsächlich war das Projekt von Anfang an nicht so aufgesetzt, dass es funktionieren konnte.