¿Les ha sucedido que encuentran a una persona tan buena en lo que hace, que simplemente da gusto verla trabajar? En mi caso, esa persona es mi papá. Crecí viendo cómo convertía la madera en muebles de una calidad excepcional. Desde niño, me sentaba junto a mi hermano mayor en el taller, observando cómo creaba cosas. Aunque no es escultor, en ocasiones parecía que lo fuera. Su habilidad para manejar un formón y un martillo es increíble; con solo esas dos herramientas, logra maravillas en su trabajo. Claro, mi padre ha pasado años usando esas herramientas, alcanzando un nivel de maestría que no se consigue de la noche a la mañana. Este tipo de ejemplos hace que, nos convirtamos en amantes de las herramientas, sin embargo, no todo es “color de rosa” al pensar en las mismas.
La herramienta para el proceso, no el proceso para la herramienta
Una de las frases que uso cuando enseño herramientas de resolución de problemas es: “La herramienta no hace al ingeniero, el ingeniero hace la herramienta.” Suelo mencionarla con el propósito de fomentar el pensamiento crítico, para evitar que las personas implementen por implementar, sin detenerse a evaluar si van en la dirección correcta y alineados al propósito. El uso de una herramienta no es un fin en sí mismo, o al menos, no debería serlo. En nuestro trabajo, las herramientas son un medio para alcanzar un resultado, sin embargo, he observado cómo en las organizaciones a veces nos dejamos llevar por las modas y olvidamos el verdadero objetivo. Es así como nos convertimos en “herramientistas”.
Tratar de ver el panorama completo antes de tomar una decisión es mi humilde consejo. En un proceso de crédito y cobro para un cliente importante, teníamos un equipo de desarrolladores expertos en SQL, Python, Visual Basic, entre otras herramientas. El más experimentado fue asignado para crear una herramienta personalizada que permitiera registrar el progreso de las llamadas y mensajes a clientes morosos con el fin de evidenciar el trabajo de cada agente de cobro. Sin embargo, la herramienta fracasó, no por culpa del desarrollador, sino por la falta de un análisis adecuado del proceso (importante recordar que en mejora continua no culpamos personas si no que buscamos mejorar el proceso).
Mi equipo de mejora continua intervino cuando la operación notó que los agentes seguían utilizando tablas en Excel en vez de la herramienta originalmente creada. La opción ahora era analizar el proceso, comprender la voz del cliente (los agentes) y mapear los requerimientos necesarios. El resultado fue muy distinto. En palabras de los agentes: “A diferencia de la herramienta anterior, nos crearon una herramienta que nos ayuda, en lugar de controlarnos”. Ir al genba para entender las necesidades de los agentes fue clave, junto con iteraciones ágiles que permitieron mostrar el progreso del producto. La herramienta resultó ser mucho más sencilla en programación y, lo más importante, se ajustó al proceso, no al revés.
Sistemas
No estoy diciendo que no se deben usar herramientas; lo que quiero resaltar es que cada herramienta tiene su lugar. Nosotros, los “Shingo Lovers”, solemos predicar que los sistemas seleccionan las herramientas, y estas, a su vez, habilitan los sistemas. Entendamos un sistema como un conjunto de herramientas que buscan un fin común. Las herramientas no responden al “por qué”, sino que se enfocan en el “cómo”. Cuando comprendemos el propósito (el por qué), se vuelve más fácil elegir el “cómo”. En resumen, no se trata de adaptar mi proceso a una herramienta de moda, sino de ajustar la herramienta a las necesidades de mi proceso para lograr los mejores resultados posibles.
La próxima vez que le propongan una herramienta, tómese un momento, piense en el propósito y evalúe la herramienta con objetividad. Si está alineada, úsela tanto como pueda hasta alcanzar un nivel de maestría; quién sabe, tal vez algún día sus hijos terminen escribiendo sobre eso.
