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 guía en la parte superior y un espacio de trabajo dedicado abajo para registrar los hallazgos. La plantilla impone una secuencia guiada por datos—los usuarios no deben pasar a Mejorar antes de que la fase Analizar haya sido verificada con datos.
Quién puede usarlo
Ingenieros de calidad, equipos de mejora de procesos, equipos de producto e ingeniería, gerentes de operaciones y practicantes de Six Sigma (Green Belt/Black Belt). Aplicable en manufactura, desarrollo de software, salud, finanzas y en cualquier industria centrada en reducir defectos o la variación de procesos.
Cómo usarlo
Avanza de izquierda a derecha por las cinco fases:
Definir – Expresar el problema, identificar al cliente, establecer la meta y el alcance.
Medir – Establecer una métrica de referencia y recopilar datos de desempeño actuales.
Analizar – Identificar las causas raíz usando 5 Whys o un Diagrama de Ishikawa; verificar las causas con datos. (Se puede adjuntar a esta fase un marco de 5 Whys o un marco con un Diagrama de Ishikawa.)
Mejorar – Desarrollar soluciones que apunten a las causas raíz verificadas; realizar un piloto antes de la implementación completa.
Controlar – Estandarizar la solución, supervisar los resultados y definir 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 los defectos escapados en un 50% para finales del cuarto trimestre; el alcance es el equipo de checkout y pagos.
Medir: Línea base de 14 defectos escapados por mes (may–jul); 60% atribuibles al módulo de checkout; el soporte dedica ~90 horas/mes a tickets de defectos.
Analizar: Un análisis de 5 Whys sobre los 10 defectos principales reveló que no había un paquete de regresión automatizado y que las revisiones previas al lanzamiento fueron apresuradas; 8 de los 10 defectos habrían sido detectados por las pruebas de regresión.
Mejorar: Se creó un paquete de regresión automatizado de 120 pruebas; se añadió un checklist para la 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 escapados/mes; el paquete de regresión quedó obligatorio en CI para todos los equipos desde octubre. Resultado: los defectos escapados cayeron de 14 a 6 por mes después del piloto.
¡Salud!
Khawaja Rizwan
