Pruebas de aceptación para RFID y ESL: casos que deben funcionar antes de arrancar

Qué debe demostrar una prueba de aceptación

La aceptación no es una demostración del proveedor ni una prueba de laboratorio: es el momento en que el cliente comprueba que, con sus productos, su red, sus usuarios y sus datos, el sistema hace lo que se acordó. Debe ocurrir antes de la puesta en marcha y con criterios escritos antes de empezar. Si los criterios se redactan después de ver los resultados, la prueba pierde valor.

También conviene separar lo que se prueba de lo que se mide en piloto. La exactitud de lectura, por ejemplo, depende de etiquetas, producto y colocación, y se determina con muestras propias; la aceptación comprueba que el criterio acordado se cumple y que existe un procedimiento para actuar si no.

Matriz de casos por categoría

Una condición esencial: una etiqueta que sigue mostrando un precio no prueba que el cambio nuevo se aplicó. En ESL, valida cada cambio con una confirmación de sincronización y con revisión visual en una muestra.

Cómo definir los criterios de aprobación

Cada caso necesita un criterio verificable y un responsable que firme. En lugar de copiar cifras de folletos, define tus umbrales así:

• Mide con una muestra propia durante el piloto y registra el resultado observado y las condiciones.
• Acuerda con el proveedor qué desviación es aceptable y qué ocurre si se supera: corrección, nueva prueba o ajuste del alcance.
• Distingue entre fallas bloqueantes (impiden operar) y observaciones (se corrigen con plan y fecha).
• Usa la lectura repetida y el conteo manual como contraste, y recuerda que las lecturas totales no equivalen a artículos únicos ni a exactitud de inventario.

La guía de implementación de EPCIS y CBV es una referencia útil para acordar qué eventos deben existir y con qué contenido, si tu solución los comparte con terceros; no define umbrales de desempeño.

Ejemplo hipotético: aceptación de una recepción con RFID

Ejemplo ilustrativo. El equipo prepara 3 tarimas de prueba con composición conocida: una con producto uniforme, otra con productos mezclados y una con material que puede interferir con la lectura. Define, antes de empezar, que el evento de recepción debe reflejar todos los artículos esperados o listar los faltantes con su motivo, que los artículos ajenos deben aparecer como excepciones y que el inventario no puede cambiar dos veces ante un reenvío.

Durante la prueba, la tarima con material difícil produce una lectura incompleta. El resultado no se oculta: se registra como observación, se prueba un cambio de colocación de etiqueta o de posición de antena, y se repite. La decisión final consta en un acta con firma de operaciones y TI, incluyendo las observaciones abiertas y su plazo.

Errores frecuentes al aceptar un proyecto

• Probar solo con datos limpios y producto ideal, y no con los casos que dan problemas a diario.
• No probar la caída de red, de servidor o de energía en la zona de captura.
• No ensayar a los usuarios reales: la prueba la hace el proveedor y no el operador del turno.
• Aprobar con observaciones sin plan, fecha ni responsable.
• No guardar evidencia, de modo que luego nadie puede demostrar qué se probó.

Si alguna prueba no puede ejecutarse por falta de entorno, déjala anotada como riesgo abierto y define una verificación posterior al arranque.

Evidencia, acta y manejo de hallazgos

Una prueba sin evidencia se convierte en opinión. Para cada caso de la matriz guarda la fecha, quién ejecutó, quién verificó, el resultado y un enlace o archivo con la prueba: captura, registro, foto o acta. Centraliza todo en una carpeta compartida con nombres consistentes, de modo que meses después se pueda responder qué se probó y con qué resultado.

Los hallazgos se clasifican al momento. Un hallazgo bloqueante detiene la aceptación hasta corregirse y volver a probar el caso. Una observación se documenta con responsable, fecha y criterio de cierre. Evita aceptar “en principio” con la promesa de corregir después sin fecha; esa es la causa más común de proyectos que arrancan con problemas conocidos y sin dueño.

Incluye en el acta quién del lado del cliente aprueba y quién del lado del proveedor recibe los hallazgos, y programa una revisión corta a las dos semanas del arranque para comprobar que lo observado se cerró. Cualquier plazo concreto debe acordarse entre las partes y no darse por sabido.

Siguiente paso

Copia la matriz, ajusta los casos a tus procesos reales y añade una columna de responsable y fecha. Revísala con el proveedor antes del piloto para que ambos conozcan las reglas de la aprobación. Si quieres comentar los casos de tu proyecto con ARKCOM, escribe desde garkcom.com/contact.