“Aquí viene, otra herramienta Lean que no funcionará en terreno.”

Cada vez que trato de introducir la resolución de problemas con A3 en terreno esta es la respuesta que obtengo, justo después de algunas maldiciones y de mover los ojos para ponerlos en blanco. El pensamiento de utilizar un enfoque metódico para llegar a la causa raíz de un problema utilizando solo una hoja de papel para seguir un proceso de resolución de problemas parece que requerirá mucho tiempo y esfuerzo. Pero si logro que mis equipos realmente evalúen los problemas que ocurren en sus lugares de trabajo, ellos están normalmente lidiando con los mismos problemas una y otra vez. Eso es porque nuestro campo es un ambiente agitado y acelerado, y está establecida la cultura de tomar acciones en base a decisiones rápidas para tratar el siguiente problema que vendrá en los próximos minutos. El liderazgo en campo es forzado a combatir los síntomas que se ven cada día en vez de gastar tiempo analizando el problema atacando la causa raíz de manera que el problema no vuelva a ocurrir.

¿Podemos tener un cambio en la cultura para enfrentar los problemas en campo? Podemos si es que introducimos y practicamos una metodología de resolución de problemas fácil de seguir que pueda funcionar en problemas grandes y pequeños en un periodo de tiempo relativamente corto. Si buscas “Metodología de Resolución de Problemas A-3” en Google, tu búsqueda arrojará cientos de opciones. La mayoría tendrá algunos principios comunes que explicaré a continuación y espero que ayude a su organización a desarrollar una cultura de solucionadores de la causa raíz de los problemas.

Declaración del problema

Cualquier proceso de resolución de problemas necesita comenzar con una buena declaración del problema. Esto puede sonar fácil, pero esto hace tropezar equipos tras equipos porque requiere de reflexión y pensamiento crítico. La declaración del problema debe partir de una hipótesis que puede ser probada con datos y no ser simplemente una declaración en la que ya se declara una solución. Comience con términos como “parece que…” o “se siente como…” o “pienso que nosotros…”, después regrese atrás y cambie la redacción cuando demuestres que tu suposición es verdadera.

Normalmente un equipo declara algo como “necesitamos elegir otro proveedor para nuestro material” como una buena declaración del problema. Esto es una solución más que una declaración del problema.Ellos debieran declarar algo como “Pareciera que nuestro proveedor consistentemente entrega el material de manera tardía en nuestra obra”. Ahora esta es una hipótesis que debe ser demostrada con datos. El equipo deberá analizar con qué frecuencia este proveedor se retrasa y qué material se está entregando tarde, pero aquí es donde nuestros equipos en campo usualmente fallan. Si el equipo no está constantemente recolectando los datos necesarios para demostrar su hipótesis, ellos querrán saltar a una solución intuitiva que puede que no resuelva la causa raíz porque será más rápido y fácil. Después de analizar los datos, ellos podrían ver que el proveedor no se retrasa con todos los materiales, si no que solo con aquellos que son hechos a la medida. Si es así, ellos pueden volver atrás y cambiar su declaración del problema a algo como “nuestro proveedor ha fallado en la fecha de entrega en los ítems customizados en un promedio de 3.5 días durante los últimos 6 meses”. Ahora tenemos una declaración del problema que puede ser atacado con algunas contramedidas directas que nos llevarán a una mejora en el desempeño.

Determinar la Causa Raíz

No puedo enfatizar esto lo suficiente: no puedes resolver un problema desde tu escritorio. Toma a tu equipo de resolución de problemas y vayan a ver el proceso sin influir en él ni arreglarlo en el acto. Vayan a ver cómo se está realizando el proceso actualmente incluso si es doloroso de ver. Deje que los malos hábitos y ejecuciones incorrectas ocurran frente a sus ojos como si no estuvieras frente al equipo. Esto será especialmente duro si tu eres el dueño del proceso y tú entrenaste al equipo. Tú querrás guiarlos y recordarles todo el entrenamiento extraordinario que hiciste con ellos. para y deja que los errores ocurran. Esta es la única manera de ver la verdad. Una vez que el equipo de resolución de problemas realizó la observación del proceso actual, conduce un evento de lluvia de ideas para determinar la causa raíz del problema.

Puedes usar un diagrama causa efecto, como una espina de pescado, o puedes usar un mapa de proceso para encontrar pasos que no agregan valor, o puedes usar la experiencia colectiva del grupo. Como sea que lo hagas, determina una o dos causas raíces de tu problema. El equipo deberá enfocarse en una o dos cosas que tienen el mayor impacto en el problema. Si tratas de arreglar muchas cosas al mismo tiempo te llevará a lidiar solo con los síntomas y no con la causa raíz. Por lo general esto es por qué siguen ocurriendo los mismos problemas en terreno porque solo se ocupan de los síntomas y no de la causa raíz.

Desarrolla Contramedidas… ¡Y REALMENTE APLICALAS!

Ahora que tu equipo tiene una o dos causas raíces para tu problema, ¿Qué vas a hacer al respecto? Las contramedidas deben estar dirigidas directamente a la causa raíz para que el equipo pueda enfocar los recursos directamente a resolver el problema.Con mucha frecuencia veo equipos desarrollar contramedidas que atacan a los síntomas en vez de a la causa raíz. Esto lleva al desperdicio de esfuerzo y frustración por el problema se volverá a repetir si la causa raíz no es abordada de manera apropiada. Por ejemplo, si tu equipo determina que la causa raíz del retraso de un proveedor es que el programa de trabajo cambia continuamente, las contramedidas deben enfocarse en prevenir los cambios en la programación. Pero normalmente el equipo intentará que el proveedor haga mejoras para entregar el material a tiempo. Esto llevará a la frustración porque no importa cuantos cambios haga el proveedor, ellos continuarán fallando si el programa se mueve constantemente.

Sin embargo, la pieza más crítica en el desarrollo de contramedidas es donde veo fallar los procesos de resolución de problemas. La mayoría de los equipos hacen un gran trabajo en identificar lo que se necesita hacer para abordar el problema pero donde fallan es en la toma de acciones. Los equipos identifican una contramedida, asignan a una persona responsable, y dan un plazo razonable para que la contramedida sea completada. Pero normalmente la mayoría de las contramedidas no llegan a ser completadas y el equipo no es capaz de avanzar en la resolución del problema. La parte más crítica de la resolución de problemas es implementar las contramedidas que han sido asignadas.

No olvides “Chequear”

Los procesos de resolución de problemas no se detienen después de que se implementan las contramedidas. Es muy común ver una mejora en el desempeño justo después de un proceso de resolución de problemas. Esto es por el “Efecto Hawthorne”. Las personas se desempeñan mejor cuando están siendo observadas. Los equipos necesitan definir un periodo apropiado en el que el problema será chequeado para tener una idea real de que tan bien se mantienen las contramedidas en el tiempo. Quizás tu equipo verificará el proceso a los 30, 60 y 90 días. Puedes esperar un aumento en el desempeño en 30 días pero no te dejes engañar por esto. Puedes estar experimentando una falsa sensación de éxito. Chequealo nuevamente a los 60 y a los 90 días, aquí es cuando verás el verdadero impacto de tus contramedidas. Si ves que el problema persiste, haz ajustes y verifica nuevamente.

No tengas miedo del A3

Un A3 es solamente una hoja de papel que se utiliza para seguir el paso a paso del proceso de resolución de problemas. Fuerza al equipo a ser metódico en su abordaje enfocándose en las pocas contramedidas críticas que tendrán mayor impacto en la causa raíz del problema. La mayoría de los A3s que veo tratan de cubrir demasiada información. Aquí están mis 5 preguntas básicas que deben ser contestadas en cada A3:

1. ¿Qué problema estás tratando de resolver?

2. ¿Cómo sabes que es un problema?

3. ¿Y qué? ¿Cuál te está costando el problema o cuál es el costo de arreglarlo?

4. ¿Cómo vas a medir el éxito?

5. ¿Qué vas a hacer para solucionar el problema?

Si tu equipo no puede contestar todas estas preguntas, probablemente no necesites llevar a cabo un proceso de resolución de problemas. Si puedes resolver todas esas preguntas, siga una metodología de resolución de problemas sucinta y ataca la causa raíz del problema. Con práctica y un buen facilitador, puedes crear una cultura de solucionadores de problemas en terreno.