Análisis de causa raíz DMAIC de Six Sigma
Resumen
La plantilla de Análisis de causa raíz DMAIC de Six Sigma es un marco estructurado de resolución de problemas en cinco fases, organizado de izquierda a derecha en cinco columnas: Definir, Medir, Analizar, Mejorar y Controlar. Cada fase contiene preguntas orientadoras en la parte superior y un espacio de trabajo dedicado debajo para registrar los hallazgos. La plantilla exige una secuencia guiada por datos: los usuarios no deben pasar a Mejorar antes de que la fase de Analizar haya sido verificada con datos.
Quiénes pueden usarla
Ingenieros de calidad, equipos de mejora de procesos, equipos de producto y de ingeniería, gerentes de operaciones y practicantes de Six Sigma (Green Belt/Black Belt). Aplicable en la manufactura, el desarrollo de software, la atención médica, las finanzas y en cualquier industria enfocada en reducir defectos o la variación de procesos.
Cómo usarlo
Recorre de izquierda a derecha las cinco fases:
Definir – Define el problema, identifica al cliente, establece el objetivo y el alcance.
Medir – Establece una métrica de referencia y recopila datos de rendimiento actuales.
Analizar – Identifica las causas raíz usando los 5 porqués o un Diagrama de Ishikawa; verifica las causas con datos. (Se puede adjuntar un marco de 5 porqués o de Diagrama de Ishikawa a esta fase.)
Mejorar – Desarrolla soluciones que apunten a las causas raíz verificadas; haz un piloto antes de la implementación completa.
Controlar – Estandariza la solución, monitorea los resultados y define un plan de respuesta para mantener la mejora.
Ejemplo
Un equipo de producto que aborda defectos de software que llegan a producción:
Definir: Demasiados defectos llegan a los usuarios finales; el objetivo es reducir en 50% los defectos que llegan a producción para finales del cuarto trimestre; el alcance es el equipo de checkout y pagos.
Medir: Línea base de 14 defectos que llegan a producción por mes (mayo–julio); 60% rastreados al módulo de checkout; soporte dedica ~90 horas/mes a tickets de defectos.
Analizar: Un análisis "5 Whys" de los 10 defectos principales reveló que no existía un paquete automatizado de regresión y que las revisiones previas al lanzamiento se hacían apresuradas; 8 de los 10 defectos habrían sido detectados por las pruebas de regresión.
Mejorar: Se construyó un paquete automatizado de regresión de 120 pruebas; se agregó un checklist de revisión de PR y un congelamiento de lanzamientos de 24 horas; se pilotó con el equipo de checkout en septiembre.
Controlar: Panel semanal de defectos; umbral de alerta establecido en 5 defectos que llegan a producción por mes; paquete de regresión obligatorio en CI para todos los equipos desde octubre. Resultado: los defectos que llegan a producción bajaron de 14 a 6 por mes después del piloto.
¡Saludos!
Khawaja Rizwan
