Un lector RFID no mide inventario. Observa eventos de radio: entre diez y doscientas veces por segundo informa que cierta etiqueta era visible para cierta antena, sin saber si está en una estantería, en el bolsillo de un compañero, en el fondo de una furgoneta o en el suelo del pasillo contiguo.

El ERP, en cambio, necesita afirmaciones: este SKU, en esta ubicación, cantidad más uno. La brecha entre observación y afirmación es donde se gana o se pierde la exactitud, y ningún ajuste de lector la cierra. Se cierra con gobierno de datos deliberado.

Por qué los datos RFID fallan antes de llegar al ERP

Cinco mecanismos producen casi todos los datos malos, y ninguno es un error de software.

Lecturas múltiples: una etiqueta en el campo de lectura se informa decenas de veces por segundo. Sin supresión, una prenda se convierte en cuarenta movimientos.
Zonas solapadas: dos antenas cubren la misma puerta y el mismo cartón se atribuye a dos ubicaciones.
Lecturas perdidas: en palés densos, entre el 10 y el 20 % de las etiquetas son invisibles en una pasada. Una lectura perdida es indistinguible de un artículo ausente.
Etiquetas obsoletas: una etiqueta en una caja desechada, en un contenedor de devoluciones o en el suelo de un probador sigue emitiendo una ubicación que ya no es cierta.
Proceso humano: etiquetas aplicadas al SKU equivocado, en el momento equivocado o reutilizadas en dos artículos.

Las cuatro clases de defecto: duplicados, fantasmas, pérdidas y errores de estado

Clasifique antes de corregir, porque cada clase necesita un control distinto.

Duplicados: el mismo artículo físico genera más de un evento de negocio dentro de una ventana.
Fantasmas: un evento se refiere a un artículo que no está físicamente en la ubicación.
Pérdidas: el artículo está presente pero no generó ningún evento durante la ventana de conteo.
Errores de estado: cada evento es válido, pero la secuencia es imposible: salir antes de llegar, o dos ubicaciones reclamando el mismo artículo.

Los duplicados y los fantasmas inflan el stock; las pérdidas lo desinflan; los errores de estado corrompen el historial, lo cual es peor porque el error se propaga a todos los cálculos futuros.

Deduplicación: reglas que sobreviven al solapamiento

Deduplique en tres niveles y conserve el registro bruto para poder recalcular siempre.

Ventana temporal: el mismo EPC en el mismo lector dentro de N segundos cuenta una vez. N es de 3 a 10 segundos en un muelle y de 30 a 60 en un transportador lento.
Grupo espacial: las antenas que cubren la misma zona física forman un grupo. Una etiqueta vista por tres antenas del grupo es un evento, no tres.
Ventana de negocio: el mismo EPC en la misma ubicación dentro de una ventana móvil, a menudo de 10 a 30 minutos, cuenta una vez aunque intervengan lectores distintos.

Guarde las lecturas brutas. Proyecte los eventos deduplicados en una tabla aparte y trate esa proyección como recalculable. Cuando una regla resulte equivocada, cámbiela y reprocese, en lugar de buscar historial corrupto dentro del ERP.

Validación en el borde frente a validación en el núcleo

Reparta la validación según lo que cada capa puede saber a bajo coste.

En el borde: formato de EPC, suma de control, prefijo de empresa, presencia de TID, identidad de lector y antena, coherencia temporal. Rechaza lecturas malformadas antes de que consuman ancho de banda.
En el núcleo: si el SKU existe, si la ubicación es válida, si la cantidad no es negativa, si la transición es legal para ese tipo de operación y si el usuario está autorizado.
Nunca haga validación de núcleo en el borde. El borde no conoce el catálogo y, en cuanto intenta conocerlo, cachea datos maestros obsoletos.

Una regla útil: el borde rechaza errores de física y el núcleo rechaza errores de negocio. Todo lo que no sea ninguna de las dos cosas —una lectura plausible de una etiqueta real en una ubicación real— debe aceptarse o ponerse en cuarentena de forma explícita, nunca descartarse en silencio.

Gestión de anomalías: cuarentena, SLA y flujo humano

Las excepciones no desaparecen porque nadie las mire. Hay que darles un sitio.

Envíe cada registro fallido a una tabla de cuarentena con el código de motivo, la carga original y la marca de tiempo.
Publique un recuento diario por motivo. Un motivo que crece durante tres días es un problema de diseño, no de operario.
Defina un estado de revisión en el ERP: aceptado automáticamente, pendiente de revisión, rechazado. Solo el estado intermedio consume tiempo humano.
Fije el SLA en horas, no en días. Una excepción de más de 48 horas suele haberse convertido ya en una discrepancia física.
Todo ajuste manual debe registrarse con usuario, motivo y valor original; de lo contrario el sistema de gobierno se convierte en la siguiente fuente de datos malos.

Métricas que demuestran la salud del pipeline

Seis números, revisados semanalmente, detectan casi todo antes de que llegue el cierre de mes.

Tasa de lectura por zona: lecturas correctas sobre artículos esperados en una prueba controlada. Por debajo del 95 % en un portal, arregle la antena antes de culpar a la capa de datos.
Ratio de duplicados: lecturas brutas sobre eventos deduplicados. Si sube, hay solapamiento de antenas o una regla de supresión fallando.
Tasa de etiquetas desconocidas: EPC sin SKU asociado. Mide directamente la disciplina de etiquetado y la configuración del prefijo de empresa.
Latencia p95 desde la lectura hasta el documento en el ERP. Si el p95 se desvía, la cola se está llenando y la política de acumulación empezará a perder eventos.
Tasa de ajustes: ajustes manuales sobre el total de movimientos. Es la medida honesta de si el RFID está sustituyendo la corrección humana.
Antigüedad de excepciones: horas medias que una excepción permanece abierta. Predice el dolor de cierre mejor que cualquier otra métrica.

Modelo operativo: quién es dueño del dato

El gobierno falla cuando no es tarea de nadie y funciona cuando es tarea de una persona con nombre.

Un data steward es dueño de las reglas, los códigos de motivo y la revisión semanal. No el equipo de TI, que posee el pipeline pero no la semántica.
Operaciones es dueño de la calidad del etiquetado y de la limpieza de lectores. Una ventana de antena sucia explica más lecturas perdidas que cualquier parámetro de software.
Finanzas es dueño de la política de ajustes y firma los umbrales de tolerancia.
La reunión de revisión dura 30 minutos, es semanal y mira siempre las mismas seis métricas.

Conclusión

Los lectores producen eventos; el ERP necesita decisiones. La capa intermedia es un producto en sí mismo y merece el mismo esfuerzo de diseño que la disposición de antenas.

Clasifique los defectos antes de corregirlos.
Deduplique en tiempo, espacio y negocio, y conserve el registro bruto.
Valide la física en el borde y las reglas de negocio en el núcleo.
Dé a cada excepción un sitio, un responsable y un SLA.
Revise seis métricas cada semana y trate un número que sube como señal de diseño.

Con eso, la exactitud del inventario pasa a ser una propiedad del sistema y deja de ser una discusión mensual.