Por Gustavo Huicochea Hernández. Reevo.
Hay gerentes que terminan el día agotados porque “resolvieron” una cotización atorada, una refacción equivocada, un técnico que no podía avanzar, una orden sin evidencia o una entrega en riesgo.
El taller sigue trabajando. El cliente se lleva su vehículo. El problema parece cerrado.
Hasta que vuelve a ocurrir.
Contener un incidente significa atender la situación inmediata para que no siga afectando la operación. Resolverlo de raíz exige algo más: cambiar la condición que lo produjo.
Si mañana necesitas la misma llamada, el mismo rescate o la misma excepción, probablemente atendiste la consecuencia, no la causa.
El análisis de causa raíz busca identificar por qué ocurre el problema para actuar sobre su origen. No exige dibujar un diagrama de pescado para cada falla. Exige no quedarse con la primera explicación ni con la primera solución.
Casi todo problema merece análisis. No todos necesitan el mismo nivel de revisión
Un problema pequeño puede analizarse mentalmente en pocos minutos. Uno que se repite, cuesta mucho, implica un riesgo o afecta varias partes de la operación puede necesitar datos, pruebas, otras personas y una revisión más formal.
El primer análisis corresponde al gerente de servicio. Su trabajo es definir el problema, distinguir los hechos de las interpretaciones y reconstruir dónde apareció.
Después formula las primeras hipótesis: posibles explicaciones que todavía necesitan comprobarse. Eso debe ocurrir antes de reunir a medio taller para elegir una solución.
Así se evita una trampa común. Cuando varias personas participan demasiado pronto, cada una puede proponer desde su puesto y sus propias dificultades.
El técnico pide herramientas, Refacciones solicita más inventario, el asesor pide otra persona y alguien propone comprar software. Todas pueden ser opciones válidas. Ninguna demuestra todavía cuál es la causa.
Una vez que el gerente organiza su primera hipótesis, necesita contrastarla con quienes realizan el trabajo. Debe escuchar información que no había considerado y comprobar si la solución propuesta funcionaría en condiciones reales.
No resuelvas el primer efecto y creas que arreglaste el sistema
“Tenemos retrasos. Compremos un software” es una solución de primer orden: se concentra en el efecto inmediato que esperamos conseguir.
Falta preguntar qué ocurrirá después. ¿Quién lo configurará? ¿El proceso que se va a programar está bien diseñado? ¿Las computadoras y los teléfonos pueden utilizarlo?
También hay que definir quién enseñará al equipo, cómo se comprobará que lo usa y qué actividad dejará de realizarse por separado para no duplicar el trabajo.
Una solución puede servir para corregir el problema y, aun así, fallar al ponerla en práctica. Comprar una plataforma y descubrir después que nadie sabe usarla puede revelar dos situaciones distintas.
Quizá se identificó bien la causa, pero no se preparó lo necesario para aplicar el cambio. O quizá la plataforma nunca atendió la causa real.
No conviene mezclar ambas situaciones. Primero comprueba si la solución modifica la condición que producía el problema. Después revisa si se puso en funcionamiento, si el equipo la incorporó a su trabajo y si la mantuvo.
Antes de comprometer recursos, considera por lo menos qué pasará después de aplicar la solución. Cuando el impacto lo justifique, revisa también las consecuencias que pueden aparecer en un segundo o tercer paso.
Ishikawa sirve para ampliar la mirada, no para decidir la causa
El diagrama de Ishikawa, también conocido como diagrama de pescado, permite organizar posibles causas. Puede ayudar cuando el problema es complejo, existen varias explicaciones o el equipo se está quedando demasiado pronto con una sola.
No hace falta limitarse a seis categorías fijas. En un taller, las posibles causas pueden estar en las personas y sus capacidades, el proceso, la información técnica, el equipo, las herramientas, las refacciones o los materiales.
También pueden estar en los proveedores, el software, las instalaciones, las políticas, la comunicación, la carga de trabajo, las autorizaciones o cualquier otra condición relevante.
Las categorías ayudan a evitar conclusiones anticipadas como “seguro fue el técnico”, “seguro fue el proveedor” o “seguro falta capacitación”.
Ishikawa no demuestra ninguna de esas causas. Ayuda a considerar más de una posibilidad y después buscar evidencia para comprobarlas.
Una explicación que parece lógica todavía no es una causa raíz
Decir “el técnico no hizo la prueba de ruta porque es descuidado” puede sonar lógico y seguir siendo una conclusión apresurada.
Primero hay que revisar si la prueba estaba definida para ese trabajo y si el sistema la mostraba como un requisito. ¿Había tiempo y estaba disponible el vehículo? ¿El técnico conocía el procedimiento y había demostrado que podía realizarlo?
¿Existía una ruta adecuada o alguna condición que impidiera hacer la prueba? ¿El jefe de taller comprobó que se cumpliera ese requisito antes de liberar la unidad? ¿Se omitió aun cuando todo lo necesario estaba disponible?
Cada respuesta permite descartar una hipótesis o encontrar razones para seguir investigándola.
Antes de atribuir la repetición del problema al desempeño de una persona, revisa lo que el taller puede organizar y controlar: recursos, información, secuencia del trabajo, autoridad, capacitación, avisos, herramientas, políticas y procesos.
No se trata de negar que una persona pueda ser la causa. Se trata de evitar que culparla demasiado pronto cierre la investigación cuando todavía existen condiciones que la gerencia puede corregir.
Si lo esperado está claro, los recursos existen, la persona demostró que sabe hacerlo y aun así sigue incumpliendo, ya hay evidencia para atender su desempeño.
En ese caso, la palabra “actitud” no está ocultando un problema de organización que quedó sin revisar.
Un problema puede tener varias causas. Una causa puede alimentar varios problemas
Lo que ocurre en el taller rara vez se explica con una sola relación de causa y efecto.
Un retraso puede combinar una solicitud tardía de refacciones, un proveedor lento, falta de visibilidad del avance e información incompleta. También puede influir que se haya ocupado una rampa antes de tener todas las piezas.
Corregir una de esas causas puede mejorar el resultado sin eliminar por completo el retraso.
También ocurre lo contrario: una misma causa puede producir problemas que parecen distintos.
La falta de información técnica disponible puede generar diagnósticos lentos, reparaciones interrumpidas, errores de torque —el apriete especificado— y demasiadas consultas al jefe de taller.
Un directorio limitado de proveedores puede retrasar las cotizaciones y el suministro, reducir la capacidad disponible y provocar incumplimientos de entrega.
Si la misma causa aparece en varios análisis, gana prioridad. Corregirla quizá no resuelva por completo un problema, pero puede mejorar varias partes de la operación al mismo tiempo.
Ésa es una forma más útil de elegir prioridades que atender únicamente el problema que hoy hizo más ruido.
Contener no es corregir la causa
Si llegó una refacción equivocada, conseguir la correcta hoy es una acción de contención: permite que la orden deje de estar detenida.
La acción correctiva busca evitar que vuelva a suceder. Para definirla, hay que investigar qué falló.
¿La solicitud indicaba la refacción correcta para el vehículo? ¿Se comprobó el número de parte? ¿El catálogo tenía un error? ¿El proveedor cambió la pieza sin avisar?
¿Se eligió sólo porque se parecía a la anterior? ¿Faltó evidencia? ¿El proceso permitía pedir sin comprobar suficientemente que correspondía?
Las dos acciones son necesarias. La primera protege la operación del momento. La segunda intenta evitar la repetición.
Muchos gerentes consumen todas sus horas en atender la urgencia. Se vuelven expertos en resolver la consecuencia, pero no reservan tiempo para entender por qué necesitan hacerlo una y otra vez.
Compara el tiempo que gastas atendiendo el problema con el que dedicas a entenderlo
Elige un problema que se haya repetido durante el último mes.
Calcula cuánto tiempo consumió entre llamadas, movimientos, búsquedas, correcciones, conversaciones con el cliente y participación del gerente.
Después compáralo con el tiempo que se dedicó expresamente a investigar la causa y diseñar una solución.
No necesitas una cifra perfecta. La comparación puede mostrar una contradicción: el taller dedica muchas horas a corregir la misma falla y casi ninguna a evitar que vuelva.
Por eso, analizar las causas debe formar parte de la rutina del gerente. Atender la urgencia no significa que el problema pueda desaparecer de su seguimiento.
Antes, alguien debe decidir si hace falta cambiar el proceso para evitar la repetición, qué hipótesis se pondrá a prueba y cuándo se revisará el resultado.
Primero hipótesis. Después evidencia. Después solución
Si aparecen cinco causas posibles, no se elige una por votación.
Cada posibilidad debe convertirse en una hipótesis que pueda comprobarse. ¿Qué dato mostraría que esa causa participa en el problema? ¿Qué orden, registro, evidencia, tiempo, prueba o comparación permitiría descartarla?
Para decidir qué investigar primero, considera con qué frecuencia ocurre, su impacto, qué tan fácil es comprobarla y si aparece en otros problemas.
Una causa compartida por varias fallas puede merecer atención antes que otra que sólo explica un incidente menor.
El gerente organiza el primer análisis y después incorpora a las personas necesarias para comprobar lo que sucede.
Así, la participación del equipo aporta mejores evidencias, en lugar de convertirse en una lista de soluciones costosas antes de entender el problema.
Poner en marcha la solución no cierra el problema
Después de aplicar una solución, necesitas volver a medir.
Si el taller compra software y el equipo no lo utiliza, todavía falta identificar qué falló. Si la herramienta atendía la causa, pero no se incorporó al trabajo, hay una brecha de implementación: una diferencia entre el cambio planeado y lo que realmente se puso en práctica.
Si el proceso que se programó era incorrecto, la causa sigue sin resolverse. Si se capacitó al equipo, pero el procedimiento continúa siendo poco claro, tampoco puedes saber si el problema está en lo que la persona sabe hacer o en cómo se diseñó el trabajo.
En cada intervención hay que distinguir tres cosas: si la solución era adecuada, si se aplicó correctamente y qué efecto tuvo sobre la repetición del problema.
Después del cambio, comprueba qué condición mejoró, qué parte quedó pendiente y si apareció un efecto nuevo. Algunas soluciones necesitan ajustar una segunda o tercera condición antes de funcionar de manera estable.
Resolver de raíz significa que el cambio ya forma parte del proceso, tiene un responsable y puede verificarse. Los casos siguientes deben mostrar que el problema disminuyó o dejó de repetirse dentro de lo razonablemente esperado.
“Ya hicimos algo” no demuestra que el problema esté resuelto.
La próxima vez que digas “otra vez”, revisa el problema además de atender el incidente
Resuelve primero lo necesario para proteger al cliente y mantener la operación. Después distingue esa atención inmediata del análisis que busca evitar la repetición.
En Reevo, esa secuencia se organiza con el método DMAICR:
DEFINE. Describe el problema con hechos y aclara qué parte de la operación abarca.
MIDE. Registra con qué frecuencia ocurre, qué impacto tiene y cuál es la condición actual.
ANALIZA. Revisa las hipótesis y la evidencia que permite confirmarlas o descartarlas.
IMPLEMENTA. Pon en práctica la intervención elegida.
CONTROLA. Comprueba si la nueva condición se mantiene y el problema se repite menos.
REEVOLUCIONA. Utiliza lo aprendido para elevar el estándar, documentar una nueva regla o atender la siguiente limitación del proceso.
La contención puede ocurrir antes de este ciclo para proteger al cliente. No lo sustituye.
Si la respuesta final sigue siendo únicamente “que la gente tenga más cuidado”, probablemente todavía no identificaste una causa sobre la que puedas actuar de manera concreta.
Revisa un problema repetido con DMAICR
Elige un problema que haya ocurrido al menos tres veces o que, aun con menor frecuencia, tenga un impacto alto.
Registra qué sucede exactamente, con qué frecuencia y qué costo, tiempo o riesgo implica. Identifica el último caso que se atendió para controlar la urgencia.
Después anota las hipótesis, la evidencia que puede confirmar o descartar cada una y la causa o las causas que ya se comprobaron.
Agrega la intervención, el responsable, la fecha de implementación, el indicador que se utilizará para dar seguimiento y el criterio para considerar resuelto el problema.
Si la solución depende de que el gerente recuerde insistir para que se cumpla, todavía no está controlada.
En RMX Control, relaciona los casos comparables cuando sea posible. Puedes agruparlos por etapa, bloqueo, garantía, proveedor, técnico, servicio o tipo de merma, es decir, la pérdida o el desperdicio observado.
La plataforma no debe decidir cuál es la causa. Debe permitir comparar hechos entre casos y comprobar si el cambio redujo la repetición.
En Reevo ayudamos a dueños y gerentes a convertir los problemas repetidos en hipótesis, evidencias, cambios de proceso y controles que puedan comprobarse.
El objetivo es que la operación dependa menos del rescate diario y más de una forma de trabajar que incorpore lo aprendido.
Resolver hoy mantiene el taller funcionando. Resolver de raíz evita que mañana vuelva a necesitarte por el mismo problema. Hablemos.
También te puede interesar
- El 80/20 no es una meta. Es una pista para buscar concentración.
- Antes de buscar una solución, desarma el problema.
- Si el cambio sólo funciona cuando tú estás, todavía no está implementado.
- Una encuesta no mejora el taller. Lo que haces después sí.
