Cómo aprendí PDCA tocando acero (y por qué hoy se lo exijo a la IA)

PDCA aplicado a la creación de software: iterar con cierre (desde el acero hasta la IA)

En la entrada anterior explicaba por qué este proyecto no es una web ni un CV ampliado, sino un sistema vivo.
Esa idea no surge de la nada. En mi caso, PDCA no es algo que haya descubierto ahora aplicándolo al software o a la IA. Lo llevo practicando —con otros nombres y otras herramientas— desde finales de los años 90, en calidad industrial real, tocando acero.

Antes de llamarlo PDCA, ya lo estábamos haciendo

Mi primer contacto serio con sistemas de calidad fue en 1998, implantando ISO 9002:94, mientras alternaba estudios en el IMH con trabajo en la tornillería familiar de Soraluze (Gipuzkoa).
Éramos una empresa de 12 personas, sin estructura formal, sin departamentos, sin cultura documental previa.

Pasamos de órdenes verbales a lo que en la planta se conocía como "los papeles de Jorge".
La resistencia inicial fue evidente. Con el tiempo, algo cambió:

"No pongo la máquina a fabricar si no me das mi Orden de Fabricación".

Ahí entendí una primera lección que hoy sigo aplicando: el método solo funciona cuando baja al taller.

La formación que recibí entonces —un curso de Euskalit sobre ISO 9002:94— no iba de gestión, ni de mejora continua. Eran 20 puntos rígidos de aseguramiento del producto. Cumplir o no cumplir. Sin épica. Sin storytelling.

De aseguramiento a gestión: ISO 9001 y responsabilidad real

En 2001 dimos el salto a ISO 9001, que mantuvimos hasta 2017. Durante ese periodo pasé de responsable de calidad a gerente de la pyme.
Y ahí la calidad dejó de ser "papeles" para convertirse en responsabilidad de la dirección.

Gestionábamos una empresa pequeña cuyos clientes eran multinacionales. Éramos, muchas veces, una cáscara de nuez en mitad de una tormenta. No teníamos datos limpios, ni sistemas sofisticados, ni ERP. Pero teníamos que planificar, cumplir y reaccionar.

Lo resolvimos con algo muy simple y muy efectivo: gestión visual.

Stocks:
- blanco: hay stock
- amarillo: punto de pedido
- rojo: riesgo de rotura
Productos y materiales:
- blanco: conforme
- verde: producto terminado liberado (hoy lo llamaría handoff)
- amarillo: no conforme
- naranja: reproceso
- rojo: defectuoso, bloqueado o a chatarra

Todo sostenido por un Excel cutre, una carpeta física y una o dos hojas por referencia.
Funcionaba. Y funcionaba bien.

Acciones correctivas, preventivas y el verdadero Act

Las acciones correctivas y preventivas eran el origen real de las mejoras. El Act del PDCA no era un concepto: era una necesidad diaria.

Nos costaba horrores hacer planes porque no teníamos datos consolidados. Revisarlos y extraer conclusiones llevaba tiempo que no teníamos. Aun así, avanzábamos con pasos pequeños, pero con sentido.

Aprendí más de calidad en la recepción de materiales de mi mejor cliente que en muchos cursos. Dos profesionales anónimos —uno de ellos con un bigote inconfundible— me enseñaron algo fundamental:

documentar compromisos,
no volver atrás una vez tomada una decisión,
anticiparse a las no conformidades,
bloquear lotes antes de que el problema explotara.

Alguna vez fui yo quien avisó para bloquear un lote antes de que ellos detectaran la desviación.
Eso es PDCA en estado puro, aunque no aparezca en ningún manual.

Datos, estadística y herramientas con consecuencias

Trabajábamos con:

PPMs,
control estadístico,
conceptos de 6 Sigma,
tablas de tolerancias.

Los pies de rey, tampones Pasa–NoPasa y galgas se enviaban a laboratorios certificados. Más adelante, la verificación la hacía yo mismo siguiendo normativa del Ministerio de Industria, como me enseñó un amigo que había estudiado Control de Calidad.

La diferencia con muchos entornos actuales es clara:
entonces la calidad se apoyaba en datos, acero y estadística.
Hoy, demasiadas veces, se apoya en objetivos voluntarios y gestión políticamente correcta.

Del acero al software (y a la IA)

Todo esto conecta directamente con el proyecto actual.

La IA, igual que un proveedor industrial, necesita especificaciones claras para entregar un producto conforme.
La calidad del software depende, en gran medida, de la calidad del proceso con el que se fabrica.

Antes de cada paso, hay que definir qué se espera.
Al terminar, hay que comprobar si se ha llegado.
Las desviaciones no se "corrigen sobre la marcha": se documentan.
El proceso se ajusta en la siguiente iteración.

Hoy no aprieto tuercas de acero.
Aprieto tuercas cognitivas a la IA: exijo contexto, delimitación, evidencia y cierre.

Iterar con cierre no es una moda

PDCA no es una metodología moderna ni una moda rescatada. Es una forma sobria y exigente de trabajar que llevo aplicando desde hace más de dos décadas, en entornos donde los errores costaban dinero, reputación y clientes.

Por eso, cuando en este proyecto se insiste en cerrar fases, documentar handoffs y no reabrir decisiones a mitad de iteración, no es rigidez: es memoria profesional.

En la siguiente entrada entraré en un punto delicado:
qué ocurre cuando el DO vuelve a Plan, cómo aparecen las alucinaciones en los agentes, y por qué definir roles claros entre humano e IA es tan importante como lo era, en su día, definir responsabilidades en una empresa de 12 personas.

El contexto ha cambiado.
La disciplina, no tanto.

Learning — ariznabarreta.eu