Todo sistema de calidad promete que las lecciones aprendidas se aplican al proyecto siguiente. Casi ninguno puede demostrarlo. La lección va a un registro, y el registro se consulta cuando alguien se acuerda de consultarlo.

Este ejercicio comprobó si KF lo hace mejor, y puso el listón alto: no «¿puede un proyecto nuevo heredar una lección?» sino «¿llega una lección a un proyecto que ya existía?»

Qué se construyó

Un ciclo de resolución de problemas reutilizable como tipo — las ocho disciplinas, de PS0 a PS8, cada una una tarea con sus propias obligaciones. Instanciarlo da al equipo todo el esqueleto 8D sin nada que recordar.

Junto a él, una biblioteca de causas candidatas: causas raíz recurrentes, agrupadas como las agrupa un diagrama de espina — material fuera de especificación, instrucción de trabajo inadecuada, herramienta o utillaje desgastado más allá del límite, frecuencia de inspección insuficiente para detectar el defecto. Cada una un ítem, reutilizable, enlazable desde cualquier investigación.

Y después un proceso real del que colgarlo: dos soportes mecanizados, cada uno con las mismas cuatro operaciones —mecanizar, desbarbar, inspeccionar, expedir— y un defecto real. Rebabas que permanecen tras el desbarbado, atribuidas a una herramienta desgastada más allá de su límite, sin ningún límite de vida de herramienta definido.

La prueba que lo decidió

La acción correctiva para ese defecto es específica del Soporte A. La acción preventiva no lo es: definir y vigilar un límite de vida de herramienta pertenece al desbarbado como operación, ocurra donde ocurra.

Así que la lección se promovió al tipo Deburring operation — y no se tocó nada más.

El Soporte B se había tipado contra esa operación antes de que la lección existiera. No se le escribió nada, ni antes ni después. Su checklist se guardó en disco a ambos lados de la promoción.

Antes: la columna de comprobaciones estaba vacía. Después: una fila que dice Deburr ← Deburring operation | Define and monitor a tool-life limit.

La misma fila apareció a la vez en la operación de desbarbado del Soporte A, tipado aún antes. Se verificó que todas las aristas que tocan al Soporte B eran idénticas antes y después: la herencia se calcula al leer, no se copia al escribir.

Veredicto: el bucle de reutilización es real, y es retroactivo. Las seis comprobaciones de aceptación pasaron.

Por qué esta es la versión difícil de la afirmación

Un sistema que empuja una lección hacia las instancias futuras está haciendo expansión de plantillas. Es útil, pero significa que la lección queda congelada en el momento de copiar, y todo lo que ya está en marcha se la pierde.

KF resuelve el checklist cuando usted lo pide. Añada hoy un requisito a un tipo y todas las instancias lo deben desde ese instante — incluido el proyecto que empezó hace dieciocho meses y va camino de expedirse. Esa es exactamente la población a la que un registro de lecciones aprendidas nunca llega.

Lo que no hizo

El ejercicio encontró defectos reales, que hubo que corregir antes de que la ejecución terminara limpia. Ese es el sentido de ejecutarlo en vez de describirlo.

Los límites honestos que conviene declarar:

• El paquete 8D es una convención, no un flujo forzado. KF no le impedirá cerrar D5 antes que D4. Si necesita control de puertas, la biblioteca de tipos expresa la forma pero no la secuencia.
• Promover sigue siendo un juicio profesional. KF le muestra qué lecciones no se han generalizado —eso es el checklist invertido— pero decidir que una lección es general y no local es trabajo de ingeniería, y debe serlo.