El problema que no vuelve

La foto quedó buena: dieciocho personas con el cinturón verde recién entregado, el logo de la certificadora de fondo, sonrisas. Fue un jueves. La empresa había pagado el programa completo —cuatro módulos, dos facilitadores, coffee break incluido— y durante tres semanas todos hablaron de DMAIC y de causa raíz en los pasillos.

Al mes, la agenda volvió a comerse todo. A los tres meses, el defecto que había motivado el proyecto estrella del curso reapareció, casi idéntico. Nadie lo relacionó con el taller. Y sobre todo: nadie preguntó lo único que importaba. ¿Este problema ya lo habíamos resuelto?

Esa pregunta tiene respaldo en la evidencia. Y lo que dice no es tranquilizador.

El pasillo de los A3 congelados

Vimos en la primera entrega de esta serie por qué el sistema premia apagar incendios y no prevenirlos. En la segunda, vimos cuál es el método que separa de verdad el síntoma de la causa —el enunciado que no se casa con una solución, la verificación en el terreno, la contramedida con dueño. Falta la parte más difícil: que todo eso no se muera a los tres meses, cuando el entusiasmo del taller ya se evaporó y la operación volvió a su ritmo de siempre.

Porque ahí, en el pasillo de tantas empresas, cuelgan doce A3 enmarcados, impecables, con sus gráficos y sus contramedidas. Se hicieron el año pasado, en el impulso de mejora continua. Están perfectos. Y están congelados: a ninguno se lo volvió a mirar para confirmar si la contramedida aguantó. Son afiches, no aprendizaje.

La pregunta que nadie hizo en el taller de los cinturones —¿esto ya lo habíamos resuelto?— es exactamente la que separa a una organización que aprende de una que solo capacita gente.

El método bien aplicado una vez no es una capacidad

Hay una tentación cómoda: si el análisis de causa raíz identificó bien la causa, el problema está resuelto. La evidencia dice otra cosa.

Una revisión sistemática publicada en 2020 en Medical Principles and Practice puso número al problema. De 21 estudios sobre análisis de causa raíz, solo dos mostraron una mejora real. En la mitad, las recomendaciones no alcanzaban para impedir que el evento volviera a pasar. Dicho de otro modo: en la enorme mayoría de los casos, dar con la causa no bastó para que el evento dejara de repetirse.

El motivo aparece en otro lugar: cuando el análisis se hace como ritual —incidente por incidente, sin difundir lo que se aprendió—, los eventos parecidos vuelven a ocurrir. Como advirtieron Dixon-Woods y su equipo en BMJ Quality & Safety, la organización, literalmente, "olvida". Cada área resuelve su propio caso, archiva su propio A3, y nadie conecta los puntos con el área de al lado, ni siquiera con su propio pasado.

Una precisión necesaria: ambos hallazgos vienen de seguridad del paciente, un dominio donde el análisis de causa raíz está particularmente medido. No son una cifra de industria general, pero el principio se transfiere sin problema a una planta, una distribuidora o un banco: identificar la causa correctamente no es lo mismo que prevenir la recurrencia. Falta un paso.

La pregunta de management que se desprende de esto es simple y molesta: de los proyectos de mejora que su empresa celebró el último año, ¿cuántos se revisaron después para confirmar que el problema no volvió? Si la respuesta es cero, no tiene una capacidad instalada. Tiene un archivo de fotos.

Si el análisis solo no basta, ¿qué sí? Lo que le faltaba al lazo: la estación que lo cierra.

Cerrar el lazo: la estación que nadie instala

En la entrega anterior presentamos El Lazo Cerrado, el marco con el que ordenamos la resolución de problemas: Enunciar (definir la brecha, sin nombrar la solución), Verificar (probar la causa con datos en el terreno, hasta que explique todo lo que se observa) y Resolver (una contramedida con dueño y fecha, no una capacitación genérica). Quien entra por esta tercera entrega ya tiene lo esencial en esa frase.

Falta la cuarta estación, y es la que casi ninguna organización instala de verdad: Cerrar. Cerrar significa medir si el problema volvió, hacer el debrief de lo que se aprendió y dejar un registro que otro pueda encontrar. Si el problema reincide, el lazo no termina ahí: vuelve a Enunciar, con la información nueva de por qué la contramedida anterior no alcanzó.

El modelo de referencia lo tiene, sin buscarlo mucho, Amazon. La compañía no hace "postmortems": hace Correction of Errors (COE), con un campo obligatorio de recurrencia. Si el problema ya había pasado antes, hay que explicar por qué las acciones anteriores no lo evitaron. Y una causa raíz que diga simplemente "el ingeniero se equivocó" hace que el documento se devuelva sin aprobar. No es una causa: es una etiqueta que no explica nada y no enseña nada.

Ese campo obligatorio es, en esencia, la Estación 4 convertida en rutina de escritura. Obliga a preguntar lo que el taller de los cinturones nunca preguntó.

El otro pilar es un lenguaje común para documentar el aprendizaje: el A3, la hoja de Toyota donde entran el problema, su análisis, las contramedidas y el plan de seguimiento. John Shook, en Managing to Learn, lo describe sin medias tintas. No es papelería: es la columna del sistema con el que Toyota desarrolla a su gente y aprende de su propio trabajo. La disciplina de escribirlo en una sola hoja —sin poder esconder vaguedad detrás de treinta diapositivas— es lo que fuerza a definir, observar, analizar y contramedir de verdad.

Ni el COE ni el A3 funcionan solos. Necesitan tres condiciones alrededor, que son las que de verdad distinguen a la organización que instala del taller que solo capacita:

Cadencia. Una revisión periódica de los problemas abiertos, no un evento anual con nombre en inglés.

Dueño. Un nombre y una fecha en cada problema, no "el área" ni "se está viendo".

Tablero. Un registro visible de problemas abiertos, cerrados y reincididos —no una carpeta de A3 archivados que nadie vuelve a abrir.

La rutina concreta para instalar esto mañana: agregue a su formato de cierre de problemas una casilla obligatoria —"¿esto ya había ocurrido antes? Si sí, ¿por qué la acción anterior no lo evitó?"— y prohíba "error humano" como causa raíz final. Es, literalmente, el campo que usa Amazon, adaptado a cualquier tablero de Excel.

Todo esto se apoya, al final, en una sola métrica.

La métrica que casi nadie mide en la región

Enunciar, Verificar y Resolver integran e implementan; Cerrar es lo que sostiene: la disciplina que convierte "resolver" en "que no vuelva".

Se mide con tres números simples. Problemas abiertos versus cerrados en una ventana de tiempo. Tiempo promedio hasta llegar a la causa raíz. Y, sobre todo, la tasa de reincidencia: cuántos de los problemas que se dieron por cerrados volvieron a aparecer en un período determinado. Es el número que el taller de los cinturones jamás calculó, porque nadie se quedó el tiempo suficiente para calcularlo.

El tablero mínimo viable tiene tres columnas: abiertos, cerrados, reincididos. No hace falta un software de gestión de calidad de seis cifras; alcanza con que exista, se actualice y alguien lo mire cada dos semanas.

La reincidencia es una métrica, y las métricas se corrompen cuando se convierten en objetivo. Si la dirección premia a ciegas "cero reincidencia", lo que va a conseguir es que la gente deje de reportar los problemas que vuelven —exactamente la disfunción de Goodhart que ya recorrimos en este blog. La métrica tiene que empujar a mejorar el sistema, no a esconder lo que reincide. Un tablero donde nunca reincide nada no es una señal de éxito: es la primera sospecha de que alguien dejó de anotar.

¿Existe esto instalado de verdad en la región, o es teoría de manual japonés traducida al español? Existe, y a 90 kilómetros de Buenos Aires.

Rutina, no evento: lo que pasa a 90 kilómetros de Buenos Aires

En la planta de Toyota Argentina en Zárate, resolver problemas no es un taller con fecha en el calendario. Es lo que se hace todos los días, en cada puesto. El año pasado, el 94% del personal de la planta aportó al menos una sugerencia de mejora dentro de sus círculos de trabajo —61.059 sugerencias en total en doce meses—, con una lógica de roles clara: los operarios resuelven y los ingenieros dan herramientas.

No hay foto de cinturón que sostenga ese volumen. Lo que lo sostiene es una rutina diaria de escucha y ajuste, con dueños de puesto que son, literalmente, quienes hacen el trabajo. Es el contra-caso positivo del taller con la foto: la resolución de problemas convertida en hábito de piso de planta, no en evento corporativo con catering.

Y hay una segunda pieza de evidencia, esta sí propiamente regional, que contradice un poco el sentido común del management. La evidencia sobre Lean y Six Sigma en pymes latinoamericanas coincide en un punto: lo que hace o rompe al método no es la herramienta —no es si se usa DMAIC o A3 o cinco eses. Es el compromiso de la alta dirección y si el método está atado a la estrategia del negocio. El tamaño de la empresa y la escasez de recursos son el principal motivo por el que estos programas se abandonan, más que cualquier resistencia técnica al método en sí.

Dicho de otro modo: la herramienta es la parte fácil. Lo difícil —y lo que realmente decide si el lazo se sostiene o se cae— es si la dirección la sostiene con presencia, no solo con presupuesto inicial.

La rutina de dirección que se desprende de esto: una cadencia fija, quincenal, de treinta minutos, revisando el tablero de problemas abiertos/cerrados/reincididos, con la dirección presente en la sala. No delegada. La evidencia regional es clara en un punto: sin esa presencia, el programa se abandona antes de rendir.

Ahora, la parte que ninguna foto de taller muestra: instalar esto duele antes de rendir.

El costo de hacerlo bien

Acá está el punto donde mueren la mayoría de los intentos serios de instalar esta capacidad. Repenning y Sterman lo llamaron, ya en 2001, "worse-before-better": invertir en mejora empeora los números en el corto plazo antes de mejorarlos. Sacar dos personas del incendio para que construyan la rutina de resolución significa, durante un tramo, que hay menos manos apagando fuego —y el fuego, mientras tanto, sigue prendiendo.

Por eso la mayoría de los programas de mejora no muere de resistencia. Muere de apuro: alguien mira el tablero a la semana, ve que no mejoró nada —o que empeoró un poco— y aborta, exactamente en el peor momento posible, justo antes de que la inversión empiece a devolver algo.

Sostenerlo requiere coraje de dirección —el mismo que la evidencia regional de la sección anterior identifica como el verdadero factor crítico. Y hay un premio, del lado de la economía, que lo justifica con un número que no es menor. Un estudio de 2019 sobre 35.000 plantas del censo de Estados Unidos encontró que las prácticas de gestión estructurada explicaban más del 20% de las diferencias de productividad entre plantas: tanto o más que la inversión en I+D o en tecnología. Esas prácticas incluyen fijación de metas, monitoreo con datos y rutinas de resolución de problemas.

Vale la aclaración: ese estudio mide "gestión estructurada" en sentido amplio, no "resolución de problemas" como etiqueta exacta. Pero la resolución estructurada —enunciar, verificar, resolver, cerrar, con cadencia y dueño— es precisamente el tipo de práctica que ese paraguas describe. No es casualidad que la disciplina más barata de instalar sea también una de las más ignoradas: ya lo vimos con el debrief en el cierre de la serie sobre equipos de este blog —la rutina de aprendizaje más barata suele ser también la primera que se cancela cuando aprieta la agenda.

La decisión de dirección que hay que tomar antes de empezar: presupuestar el worse-before-better de antemano. Aceptar, por escrito si hace falta, que durante dos o tres meses los números no van a mejorar —y comprometerse a no abortar en ese tramo. Sacar a dos personas del incendio y protegerlas de que las vuelvan a meter adentro a la primera semana difícil.

Un último apunte, para no confundir velocidad con capacidad, sobre la moda del momento.

El espejismo de la IA

En 2026 ya circulan sistemas de análisis de causa raíz asistidos por inteligencia artificial que reducen drásticamente el tiempo de localizar la causa en entornos técnicos complejos —arquitecturas de microservicios, por ejemplo, donde encontrar el origen de una falla puede llevar horas de rastreo manual entre logs.

Es un avance real, pero no hay que confundirlo con lo que resuelve esta serie. Esos sistemas automatizan el análisis —la Estación 2, Verificar—, no la definición del problema —la Estación 1, Enunciar—. Y mucho menos la Estación 4, Cerrar, que exige juicio humano sobre si la contramedida aguantó. Un sistema que encuentra la causa raíz más rápido de un problema mal enunciado simplemente ayuda a resolver más rápido el problema equivocado. Vale la cautela: es investigación de 2026 todavía sin revisión por pares, en el dominio específico de software, no un resultado consolidado para operaciones en general. Como color de lo que viene, sirve. Como sustituto de la capacidad instalada, no.

Con esto en la mesa, quedan dos objeciones por desarmar.

Las objeciones que frenan al directorio

"Ya hicimos la capacitación de mejora continua, tenemos los cinturones." ¿Cuántos de esos proyectos se revisaron después para ver si el problema volvió? Si la respuesta es ninguno, la empresa tiene cinturones. No tiene una capacidad.

"No tengo gente para sacar del día a día y ponerla a esto." Es exactamente la trampa que describimos en la primera entrega de esta serie: nunca hay gente disponible porque nunca se previene, y nunca se previene porque no hay gente disponible. El lazo se corta sacando a dos personas del incendio hoy, no esperando a que sobre tiempo —tiempo que, en un sistema que nunca previene, no va a sobrar nunca.

El comité que dejó de reunirse

Vuelva, por un momento, al comité de quiebres del lunes con el que abrió esta serie. Mismo lunes, misma planilla de faltantes, hace dos años que se repite. Con el lazo cerrado instalado —enunciado sin solución prematura, causa verificada en el depósito, contramedida con dueño, y ahora sí, alguien que mide si el problema vuelve—, por fin alguien hace la pregunta que nunca se había hecho: ¿por qué esos SKUs quiebran siempre, los mismos, mes tras mes?

La causa resulta ser un parámetro de reorden mal cargado en el sistema, heredado de una migración de tres años atrás. No un problema de demanda, no un problema de logística, no "el proveedor que no cumple". Se corrige una vez, con un dueño y una fecha. Y el comité de los lunes, con el tiempo, deja de tener sentido de existir.

Ese comité que ya no se reúne es, exactamente, el problema que no vuelve. Y nadie va a recibir una felicitación por él, ningún ascenso, ninguna mención en la reunión de directorio —porque un problema que dejó de ocurrir no deja rastro para aplaudir. Esa es, justamente, la señal de que el sistema funcionó.

Nueve preguntas para el lunes

Un autodiagnóstico que cierra las tres entregas de esta serie. Antes de la próxima reunión de comité, respóndalas con honestidad: