“Aquí viene, otra herramienta Lean que posiblemente no podría funcionar en el campo”.
Cada vez que trato de introducir la resolución de problemas de causa raíz A-3 en el campo, esta es normalmente la respuesta que obtengo, justo después de algunas maldiciones y poner los ojos en blanco. La idea de usar un enfoque metódico para llegar a la causa raíz de un problema mientras se usa una sola hoja de papel para rastrear un evento de resolución de problemas parece demasiado tiempo y esfuerzo. Pero si puedo hacer que mis equipos evalúen realmente los problemas que ocurren en sus sitios de trabajo, normalmente se enfrentan a los mismos problemas repetidamente. Esto se debe a que nuestro campo es un entorno agitado y acelerado, y la cultura establecida se presta a tomar decisiones de acción rápida para enfrentar el próximo problema que se les presente. El liderazgo de campo se ve obligado a combatir los síntomas tal como los ven todos los días en lugar de dedicar tiempo a analizar el problema y atacar la causa raíz.
A-3 Metodología de resolución de problemas
¿Podemos tener un cambio de cultura cuando se trata de lidiar con problemas en el campo? Podemos si introducimos y practicamos una metodología de resolución de problemas fácil de seguir que puede funcionar en problemas pequeños o grandes en un período de tiempo relativamente corto. Si busca "Metodología de resolución de problemas A-3" en Google, su búsqueda arrojará cientos de opciones. La mayoría tendrá algunos principios comunes que explicaré a continuación, que espero ayuden a su organización a desarrollar una cultura de solucionadores de problemas de causa raíz.
Planteamiento del problema
Cualquier evento de resolución de problemas debe comenzar con una buena declaración del problema. Esto puede sonar fácil, pero hace tropezar equipo tras equipo porque requiere reflexión y pensamiento sucinto. La declaración de un problema debe comenzar como una hipótesis que se puede probar con datos y no ser simplemente una declaración que ya declara una solución. Comience con términos como "Parece que..." o "Se siente como..." o "Creo que nosotros...", luego regrese y cambie la redacción después de probar que su suposición es cierta. Normalmente, un equipo declarará algo como “Necesitamos elegir otro proveedor para nuestro material” como una buena declaración del problema. Esta es una solución más que un enunciado del problema.
Lo que deberían estar declarando es: "Parece que nuestro proveedor constantemente entrega material tarde en este lugar de trabajo". Esa es una hipótesis que se puede probar con datos. El equipo debe analizar con qué frecuencia su proveedor llega tarde y qué material se entrega tarde, pero aquí es donde nuestros equipos en el campo suelen fallar. Si el equipo no está rastreando los datos necesarios para probar su hipótesis, querrán pasar a una solución automática que sea más fácil y rápida, pero que quizás no resuelva la causa raíz del problema. Después de analizar los datos, es posible que vean que el proveedor no se retrasa en la entrega de todo el material, sino solo en los artículos hechos a medida. Si es así, el equipo puede regresar y cambiar su declaración del problema a algo como: “Nuestro proveedor no cumplió con la fecha de vencimiento de los artículos personalizados en un promedio de 3,5 días durante los últimos 6 meses.
Determinar la causa raíz
No puedo enfatizar esto lo suficiente: no puede resolver un problema de proceso desde su escritorio. Lleve a su equipo de resolución de problemas y salga y observe el proceso sin influir en él o arreglarlo en el acto. Ve a ver cómo se está realizando el proceso actualmente, incluso si es doloroso de presenciar. Permita que todos los malos hábitos y la ejecución incorrecta sucedan frente a sus ojos como si no estuviera frente al equipo. Esto será especialmente difícil si usted es el propietario del proceso y capacitó al equipo. Querrás guiarlos y recordarles toda la excelente capacitación que brindaste. Deténgase y deje que los errores sucedan. Esta es la única manera de ver la verdad. Una vez que su equipo de resolución de problemas haya terminado de observar el proceso actual, realice un evento de lluvia de ideas para determinar la causa raíz del problema. Puede usar un diagrama de causa y efecto, como una espina de pescado; un mapa de proceso para encontrar pasos sin valor; o la experiencia colectiva del grupo para determinar una o dos causas fundamentales de su problema. El equipo debe enfocarse en esas una o dos cosas que tienen el mayor impacto en el problema. Si trata de arreglar demasiadas cosas a la vez, tendrá que lidiar solo con los síntomas y no con la causa raíz. Por lo general, esta es la razón por la cual los mismos problemas en el campo siguen ocurriendo en un sitio de trabajo porque solo se ocupan de los síntomas y no de la causa raíz.
Desarrolle contramedidas... ¡Y REALMENTE HÁGALAS!
Ahora que su equipo tiene una o dos causas raíz de su problema, ¿qué va a hacer al respecto? Las contramedidas deben dirigirse directamente a la causa raíz para que el equipo pueda concentrar los recursos en resolver el problema directamente. Con demasiada frecuencia veo equipos que desarrollan contramedidas que atacan los síntomas en lugar de la causa raíz. Esto conduce a un esfuerzo desperdiciado y a la frustración porque el problema ciertamente volverá a aparecer si la causa raíz no se aborda adecuadamente. Por ejemplo, si su equipo determina que la causa principal de que un proveedor entregue artículos tarde se debe a que el cronograma de trabajo sigue cambiando, las contramedidas deben centrarse en evitar cambios en el cronograma. Pero normalmente un equipo intentará que el proveedor realice mejoras para entregar el material a tiempo. Esto conducirá a la frustración porque no importa cuántos cambios haga el proveedor,
Sin embargo, la pieza más crítica en el desarrollo de contramedidas es donde veo que fallan la mayoría de los eventos de resolución de problemas. La mayoría de los equipos hacen un gran trabajo al identificar lo que se debe hacer para abordar el problema, pero donde fallan es en la acción. Los equipos identificarán una contramedida, asignarán una persona responsable y darán una fecha de vencimiento razonable para que se complete la contramedida. Pero normalmente, la mayoría de las contramedidas nunca se completan y el equipo no puede avanzar en la resolución del problema. La parte más crítica de la resolución de problemas es tomar las contramedidas que se han asignado.
No te olvides de "Comprobar"
Los eventos de resolución de problemas no se detienen después de que se implementan las contramedidas. Es muy común ver un aumento inicial en el rendimiento justo después de un evento de resolución de problemas. Esto se debe al “ Efecto Hawthorne ”. Las personas se desempeñan mejor cuando son observadas. Los equipos deben establecer un período apropiado en el que se verificará el problema para tener una idea real de qué tan bien se mantienen las contramedidas con el tiempo. Quizás su equipo verifique el proceso a los 30, 60 y 90 días. Puede esperar un aumento en el rendimiento a los 30 días, pero no se deje engañar por esto. Es posible que esté experimentando una falsa sensación de éxito. Compruébelo nuevamente a los 60 días y a los 90 días, ahí es cuando verá el verdadero impacto duradero de sus contramedidas. Si ve que el problema persiste, haga un ajuste y regrese para verificarlo nuevamente.
No le tengas miedo a la A-3
Un A-3 es solo una hoja de papel que se utiliza para seguir los pasos del evento de resolución de problemas. Obliga al equipo a ser metódico en su enfoque mientras se enfoca en las pocas contramedidas críticas que tendrán el mayor impacto en la raíz del problema. La mayoría de los A-3 que veo tratan de cubrir demasiada información. Aquí están mis 5 preguntas básicas que deben responderse en cada A-3:
¿Que problema estas tratando de resolver?
¿Cómo sabes que es un problema?
¿Y qué? ¿Cuánto le está costando el problema, o cuál es el costo de arreglarlo?
¿Cómo medirás el éxito?
¿Qué vas a hacer para solucionar el problema?
Si su equipo no puede responder a todas estas preguntas, probablemente no necesite realizar un evento de resolución de problemas. Si puede responder a todas estas preguntas, siga una metodología sucinta de resolución de problemas y ataque la causa raíz de su problema.
Con práctica y un buen facilitador, puede crear una cultura de solucionadores de problemas en el campo.
ACERCA DEL AUTOR.
Michael actualmente se desempeña como director Lean en Nevell Group, Inc. NGi es un contratista de sistemas de paredes interiores y exteriores con sede en Brea, California y oficinas en el norte de California y San Diego. Michael es responsable de desarrollar toda la capacitación Lean para el campo y la oficina, así como un programa de certificación interno. Es un piloto retirado de helicópteros de la Marina que anteriormente trabajó como Lean Manger en Oakley, Inc y Con-Way Freight. Michael comenzó su trabajo en la industria de la construcción como Gerente de Mejora de Procesos en los contratistas de KHS&S. Es un cinturón negro maestro de Lean Six Sigma y es muy activo en el Lean Construction Institute. Es instructor certificado por LCI en Last Planner System®, Lean Project Delivery y Mindset of Effective Big Room. Ha sido orador destacado e instructor en el Congreso de LCI, Fue miembro del equipo de planificación del Congreso durante los últimos cuatro años, es miembro del grupo central de la CoP de LA/OC y ha desarrollado capacitación en cultura, 5-S, gestión visual, resolución de problemas, trabajo estándar y 8 desperdicios. . A Michael le apasiona promover Lean dentro de la industria de la construcción y es un gran defensor del campo. Él cree que el enfoque de cada esfuerzo Lean debe beneficiar directamente al campo y debe garantizar que el trabajo se realice de manera más eficiente y efectiva.
TRANSCRIPCIÓN: Areli Álvarez Lean Construction México®
Comments