Gestión de cambios y validación

En una línea de producción, la gestión de cambios ya existe para las máquinas y los procesos. Un sistema con modelo añade cosas que también son cambios, aunque no toquen el código: una versión nueva del modelo, un umbral de decisión distinto, otro recorte o preprocesado de la imagen, una cámara, un lente o una lámpara nuevos, y una referencia de producto que el modelo no conoce. Todo lo que cambia lo que el modelo recibe o lo que hace con su salida cambia su decisión.

En cambio, no todo lo que se registra en la estación es un cambio de ese tipo. Una copia de seguridad o el color de una pantalla no mueven la decisión del modelo. Saber separar unos de otros evita dos errores: pedir una validación para todo y no pedirla para lo que importa.

Un procedimiento de cambios sirve si se cumple también con prisa. La señal típica de que se saltó es una validación que «se completa después»: la versión entra a producción con un resultado que no cumple los criterios, porque alguien con presión de producción decidió que podía esperar.

Cruza el resultado de cada validación con los criterios.

La separación de funciones vale también aquí: quien sufre la presión de producir no debería ser quien decide que una versión es suficientemente buena para producir. El procedimiento de Tamarillo dice quién firma la entrada a producción.

El impacto de una versión no validada depende de cuánto tiempo decidió sobre piezas reales. Ese número va al informe porque define cuánta producción hay que revisar: lotes, clientes y reclamos de ese periodo.

Los eventos de configuración muestran lo que se movió en la estación desde que se desplegó la versión actual. Algunos llevan solicitud de cambio, otros no; algunos afectan la decisión del modelo, otros no. Lo que hay que contar son los que cambian lo que decide el modelo y no tienen solicitud: son los cambios que nadie validó.

Una solicitud de cambio que existe pero no pide validar el modelo es otro problema, y se anota aparte; para esta cuenta, tiene solicitud.