Criterios de aceptación: convertir expectativas en pruebas verificables

Aceptar es verificar, no opinar

Muchos proyectos terminan con una discusión: el proveedor dice que entregó lo prometido y el cliente siente que no funciona como esperaba. Casi siempre el origen es que la expectativa nunca se escribió como prueba. Un criterio de aceptación es la frase que cierra esa brecha: describe una comprobación que cualquiera de las dos partes podría repetir y obtener el mismo resultado.

Este enfoque funciona con independencia del contrato. Si el contrato existe, los criterios lo complementan con detalle técnico; si todavía no se firma, los criterios ayudan a decidir qué incluir. No son consejo legal: las consecuencias contractuales de aprobar o rechazar deben revisarse con el área jurídica.

Anatomía de un criterio verificable

Cada criterio debería poder completarse con seis elementos. Si falta alguno, queda espacio para la discusión.

• Objeto: qué se evalúa (un portal, una zona, un lote de etiquetas, un flujo de la PDA).
• Métrica: qué se mide y cómo se define. Un conteo de lecturas no es lo mismo que artículos únicos ni que exactitud de inventario.
• Método: pasos, equipo usado y condiciones (turno, ocupación, interferencias).
• Muestra: tamaño, composición y quién la selecciona.
• Umbral: resultado mínimo, expresado por ustedes tras observar datos reales; no un número tomado de un folleto.
• Evidencia: registro, captura de pantalla firmada, exportación de datos.

De la frase vaga al criterio comprobable

Los corchetes son campos que cada organización llena con sus propios datos. Este artículo no sugiere umbrales ni valores de desempeño.

Precauciones técnicas al medir

Algunos errores de medición son comunes. En RFID pasiva, las etiquetas no miden temperatura ni entregan ubicación continua en tiempo real; si un criterio las pide, la solución debe ser otra o debe estar explicado cómo se obtiene ese dato. Una tasa de lectura se calcula con un universo conocido y no con la cantidad de lecturas: un lector puede registrar muchas veces la misma etiqueta. Para entender la base técnica, la RAIN RFID Alliance explica que la etiqueta suele contener un número que sirve de consulta en una base de datos, es decir, el resultado de negocio depende también del dato maestro y del software.

En ESL, que la etiqueta muestre un precio no equivale a que el cambio más reciente se haya sincronizado correctamente: se necesita comparar contra el estado informado por el sistema. En dispositivos, un grado de protección IP no demuestra resistencia a todo golpe o inmersión, y un sistema de gestión de dispositivos no garantiza seguridad por sí solo; los criterios deben ser específicos y comprobables. La guía NIST SP 800-124 Rev. 2 presenta la gestión de movilidad empresarial como una de varias medidas (análisis de amenazas, defensa contra amenazas móviles, revisión de aplicaciones), recomienda probar un piloto antes de producción y mantener actualizados el sistema operativo y las aplicaciones; un criterio razonable pide evidencia de esas políticas ya configuradas, no solo la presencia de la herramienta.

Cómo construirlos en equipo

Haga un taller breve con operaciones, TI, compras y el proveedor. Parta de las expectativas que se dijeron durante la venta o el diseño y conviértalas una por una. Si una expectativa no se puede convertir en prueba, o se elimina, o se acepta como riesgo explícito.

Distinga criterios obligatorios de deseables. Los primeros condicionan la aceptación; los segundos se registran como mejoras. Y acuerde qué ocurre cuando un criterio no se cumple: corrección con nueva prueba, aceptación condicionada con plazo o rechazo. Esa regla debe estar escrita antes de la primera prueba.

Datos de referencia y condiciones de la prueba

Antes de instalar, registre una línea base: cómo se hace hoy el proceso, qué errores ocurren, cuánto tiempo toma. Sin ella, cualquier mejora o empeoramiento queda sin comparación. Documente además las condiciones: quién operó, qué turno, qué configuración de software y qué versión. Una prueba sin versión no puede repetirse.

Si durante las pruebas se cambia configuración, las pruebas anteriores deben repetirse en lo que corresponda. Esto parece obvio hasta que una modificación menor altera un resultado ya aceptado.

Registro de resultados y manejo de desviaciones

Cada prueba debe dejar un registro con fecha, versión del sistema, responsable, resultado y evidencia anexa. Cuando una prueba no cumpla, anote la desviación con su causa probable (equipo, configuración, datos, entorno o criterio mal definido) y el compromiso de corrección. Distinguir esa causa evita rechazar un sistema por un criterio que estaba mal planteado, o aceptar uno que cumple solo porque la prueba era demasiado fácil.

Al final, resuma en un acta los criterios aprobados, los aprobados con condición y los rechazados, con firma de ambas partes. Esa acta es el entregable de este artículo; los documentos para pedir propuestas o comparar proveedores cumplen funciones anteriores y distintas.

Preguntas frecuentes

¿Puede el cliente cambiar criterios durante el proyecto?

Puede proponerlo, pero conviene un procedimiento de cambios con registro, porque modificar criterios altera tiempos y costos.

¿Quién mide?

Lo ideal es que mida personal del cliente con acompañamiento del proveedor, o ambos al mismo tiempo, y que los datos queden en un formato que las dos partes puedan revisar.

Siguiente paso

Tome las cinco expectativas más importantes de su proyecto y escriba cada una con los seis elementos. Compártalas con el proveedor antes de cotizar, no después de instalar.

Si quiere revisar sus criterios de aceptación, puede escribir a ARKCOM desde garkcom.com/contact.