De corregir el error a corregir la causa

En el flujo de producción de banking notes (documentos financieros de alto volumen y alta repetición), empecé a notar que ciertos errores de formato no eran incidentes aislados. Aparecían una y otra vez, en distintos documentos, distintos idiomas, a veces distintos miembros del equipo. Se corregían caso por caso en QA, pero volvían a aparecer al mes siguiente en un documento distinto.

Corregir el síntoma cada vez que aparecía estaba consumiendo tiempo de revisión que debería haberse ido en control de calidad real, no en repetir la misma corrección.

Como parte del equipo de DTP, trabajando junto a mi Team Lead y el PM del proyecto, me propuse dejar de tratar estos errores como incidentes puntuales y en cambio identificar su causa raíz, apoyándome en una certificación específica en Root Cause Analysis para aplicar un método estructurado en lugar de intuición.

De la corrección puntual al patrón. El primer paso fue simplemente llevar registro: cada vez que un error de formato se repetía, anotaba en qué tipo de documento aparecía, en qué etapa del flujo y qué lo disparaba. Después de unas semanas, el registro dejó de verse como una lista de incidentes sueltos y empezó a verse como un patrón.

Aplicar un método, no solo intuición. Con la certificación de Root Cause Analysis como marco, usé un enfoque de los 5 porqués adaptado al flujo de DTP. No quedarme en "el estilo no se aplicó bien" sino seguir preguntando hasta llegar a la causa estructural, por ejemplo si el problema real estaba en cómo llegaba el contenido traducido, en una plantilla desactualizada, o en un paso del flujo sin dueño claro.

Distinguir causa raíz de causa aparente. Muchas veces la causa obvia (un descuido puntual) no era la causa real. El método ayudó a separar lo que parecía la causa de lo que efectivamente la generaba, que era un paso del proceso, no una persona.

Proponer el cambio, no solo señalar el problema. Identificar la causa raíz no alcanza si no se traduce en un cambio concreto. Llevé el hallazgo a mi Team Lead y al PM con una propuesta específica de ajuste al flujo, en vez de solo reportar que esto seguía pasando.

• Registrar antes de sacar conclusiones. Resistí la tentación de diagnosticar la causa desde el primer caso; el patrón solo se vio con varios casos registrados en el tiempo.
• Buscar la causa estructural, no la persona responsable. El foco del análisis fue siempre el proceso, dónde fallaba el flujo, nunca quién cometió el error puntual.
• Cerrar el ciclo con una propuesta accionable. Un root cause analysis que termina en un diagnóstico sin una recomendación de cambio no cambia nada en la práctica.

Un ajuste concreto al flujo de producción, identificado a partir del patrón registrado y validado con el método de root cause analysis, presentado al equipo como propuesta de mejora de proceso y no como corrección de un caso individual.

El error recurrente dejó de reaparecer con la misma frecuencia, porque se atacó su origen y no su síntoma más reciente.

Un error que se repite ya no es un error, es información sobre el proceso.

Esa forma de mirar los problemas, preguntando por qué vuelve a pasar esto en vez de solo corregirlo de nuevo, es algo que ahora aplico como primer paso frente a cualquier problema recurrente, no solo en DTP.