El hardware rara vez es la causa del fracaso de un programa RFID. En los análisis posteriores que he leído, los lectores estaban instalados, las etiquetas aplicadas y el portal detectaba correctamente al 97 %. El proyecto murió igual, casi siempre en la hoja de cálculo donde alguien comparó el ahorro prometido con el realizado.

Estas son las diez trampas que explican la mayor parte de esa decepción, agrupadas por la fase en que aparecen.

Trampas 1 y 2: hardware antes que proceso, y capacidad antes que demanda

El error más caro es el primero, porque todo lo demás lo hereda.

Comprar lectores antes de definir el proceso: un lector es un componente, no una solución. Hasta que no puedas decir qué decisión de negocio dispara la lectura —una recepción, una excepción, una señal de reposición— cualquier elección de hardware es una apuesta.
Dimensionar para un pico que no existe: equipos que compran lectores de ocho puertos para un muelle que nunca verá más de 60 cajas por hora. Los puertos extra cuestan dinero y, peor, empujan a distribuciones de antenas que crean interferencia. Dimensione con el volumen medido más un 50 %, no con la diapositiva de la conferencia.

Trampas 3 y 4: la disciplina de etiquetado y ese 5 % que lo envenena todo

El etiquetado es poco glamuroso, está infrafinanciado y es decisivo.

Suponer que el proveedor etiquetará bien: el etiquetado en origen solo funciona si la posición se especifica en milímetros, el mapeo SKU a EPC está validado y se audita una muestra en cada entrega. De lo contrario hereda un 5 % de error que consume en silencio todo el ahorro de mano de obra.
Reutilizar EPC: los identificadores sobrantes y reciclados son la vía más rápida a corromper el historial. Un EPC debe ser único durante toda la vida del artículo y retirarse con él, no reasignarse a la siguiente caja.

Trampas 5 y 6: el layout de antenas y la puerta que nadie probó

La física no es complaciente y no le importa el render del propuesta.

Diseñar la zona de lectura sobre el papel: el plano muestra una zona limpia de dos metros. La realidad incluye una persiana metálica, una carretilla aparcada en el haz y el pasillo contiguo. Pruebe con palés reales, film real y tráfico real durante un turno completo.
Ignorar la zona adyacente: el ticket de soporte más común tras el arranque son lecturas fantasma de la sala vecina. Una antena extra cuesta menos que tres meses de conteos disputados.

Trampas 7 y 8: atajos de integración y el responsable de excepciones que falta

El proyecto suele sobrevivir al arranque y morir en el segundo mes, y es aquí.

Escribir directamente en el ERP: las escrituras directas o un middleware que publica cantidades en lugar de documentos omiten la auditoría y se rompen en la primera actualización. Envíe documentos y deje decidir a la lógica del ERP.
Nadie es dueño de las excepciones: todo despliegue genera entre el 1 y el 5 % de lecturas que no se resuelven solas. Si ninguna persona con nombre las cierra dentro de un SLA definido, se acumulan hasta que el equipo deja de confiar en el sistema, y un sistema en el que nadie confía es un sistema que se apaga.

Trampa 9: el piloto que no demuestra nada

Un piloto en un pasillo, con una antena, ejecutado por el equipo del proyecto, demuestra que el RFID funciona. No demuestra que su operación vaya a funcionar con RFID.

Un piloto útil tiene grupo de control, una línea base medida antes de etiquetar y al menos cuatro semanas de operación que incluyan un cierre de mes.
Mide las seis cifras que importan: tasa de lectura, ratio de duplicados, tasa de etiquetas desconocidas, latencia, tasa de ajustes y antigüedad de excepciones.
Incluye a quienes usarán el sistema, no solo a quienes lo instalarán.

Trampa 10: el caso de negocio construido sobre una sola cifra

Si toda la justificación es ahorro de mano de obra, el proyecto se cancelará el trimestre siguiente a la primera revisión de plantilla.

Modele al menos tres corrientes de beneficio —mano de obra, exactitud de stock y disponibilidad— y muestre cada una por separado.
Presente el escenario pesimista, no el optimista. Un caso que solo funciona con adopción del 100 % no es un caso de negocio.
Incluya los costes corrientes que llegan en el año dos: etiquetas, reparaciones, software y la persona que ahora debe ser dueña del dato.

Qué hacen en cambio los despliegues que funcionan

El patrón es coherente entre los proyectos que salieron bien.

Se parte de una decisión de negocio que hoy está mal, no de una tecnología que hoy resulta interesante.
Se etiqueta por completo una población pequeña y cerrada, en lugar de etiquetar a medias una grande.
Se mide una línea base antes de la primera etiqueta; sin ella, toda afirmación posterior es una opinión.
Se presupuestan las partes aburridas: aplicación de etiquetas, pruebas de antena, gestión de excepciones.
Se definen los criterios de salida antes de empezar y se acepta parar.