Arregla el equipo antes de arreglar el proceso

Los problemas de rendimiento suelen abordarse como problemas de proceso, pero en muchos casos, la causa raíz reside en otro lugar. El autor reflexiona sobre un problema recurrente, aunque a menudo ignorado.

Hace unos años, dirigía una planta de reacondicionamiento que operaba en dos turnos: mañana y tarde. Ambos equipos estaban comprometidos, con líderes y operarios que participaban activamente en actividades kaizen, y la resolución de problemas formaba parte del trabajo diario. Sin embargo, el progreso era limitado. Algo no funcionaba. Los resultados eran aceptables, pero parecían haberse estancado. La fábrica estaba en funcionamiento, pero no avanzaba realmente.

Para abordar la situación, investigamos el proceso: la combinación de vehículos, la nivelación de la producción y el cumplimiento de los estándares. Dedicamos tiempo a observar el trabajo, a menudo justo detrás de las estaciones de trabajo, observando el flujo y hablando con los equipos en el gemba.

No encontramos ningún problema importante en el proceso. Así que la pregunta seguía en pie: ¿por qué un sistema con equipos comprometidos no mejoraba? Nada explicaba realmente lo que veíamos.

Cuando finalmente decidimos cambiar nuestro enfoque y comenzamos a prestar más atención a cómo trabajaban los equipos, surgió algo más. Los dos líderes de equipo no trabajaban realmente juntos. No había conflictos abiertos ni discusiones, pero tampoco había una verdadera cooperación. Cada líder de equipo se centraba en su propio equipo, lo que, con el tiempo, generó una sutil competencia.

Cada equipo quería obtener mejores resultados. En el tablero, la gente, naturalmente, miraba primero su propia columna. La otra se convirtió en una clasificación informal, lo que provocó que el comportamiento se deteriorara. A veces se preferían las soluciones más fáciles, no siempre se respetaba la nivelación planificada y las buenas soluciones ideadas por un equipo no se compartían con el otro.

Poco a poco, la mentalidad colectiva se fue erosionando. Los dos equipos comenzaron a comportarse como grupos separados y el objetivo común de la empresa —servir al cliente— pasó a un segundo plano. Creíamos que teníamos un problema de proceso; en realidad, teníamos un problema de equipo.

A partir de ese momento, cambiamos nuestro enfoque y abordamos la forma en que los equipos trabajaban juntos. Y fue entonces cuando las cosas empezaron a cambiar.

Al principio, no fue fácil. La gente seguía apegada a su propio equipo y a sus resultados. Las discusiones a veces eran tensas y estaba claro que reconstruir la confianza llevaría tiempo. Recuerdo una situación en la que teníamos retrasos recurrentes en vehículos que requerían intervenciones mecánicas prolongadas. Estos trabajos solían comenzar durante el turno de la mañana, pero no se terminaban antes de que el equipo de la tarde tomara el relevo.

El problema no era la complejidad de los trabajos, sino el traspaso de información. El equipo de la mañana se detenía en cierto punto, pero el estado exacto del vehículo, las dificultades encontradas y los siguientes pasos críticos no siempre se compartían con los compañeros del turno de la tarde. Como resultado, el equipo de la tarde a menudo tenía que dedicar tiempo a comprender mejor la situación —a veces incluso repitiendo comprobaciones, «solo para asegurarse»— antes de poder continuar trabajando.

Para fomentar la cooperación entre los dos equipos, implementamos una práctica sencilla. Antes del cambio de turno, el jefe de equipo y un operario del equipo de la mañana explicaban brevemente al equipo de la tarde el estado de los trabajos pendientes, centrándose en lo que se había hecho y lo que seguía siendo crítico.

Enseguida vimos el impacto de esto: el equipo de la tarde podía reanudar el trabajo sin dudarlo, evitar retrabajos innecesarios y completar más vehículos dentro de su turno. Esto resultó en un aumento de la producción de aproximadamente un 5%, sin añadir capacidad.

Gradualmente, la competencia dio paso a la cooperación y, sin modificar fundamentalmente el proceso, el rendimiento comenzó a mejorar de nuevo.

Esta experiencia me marcó porque reveló algo esencial. En la industria, dedicamos mucho tiempo a mejorar procesos, flujos, estándares y operaciones, pero el rendimiento del sistema también depende de algo mucho más frágil: la inteligencia colectiva del equipo.

Cuando los equipos trabajan juntos, con el tiempo desarrollan una comprensión profunda de su trabajo. Saben dónde tienden a surgir los problemas, reconocen las señales de alerta temprana y desarrollan reflejos compartidos para responder con rapidez. Este conocimiento no siempre está plasmado en estándares. Reside en el trabajo mismo, en forma de gestos, interacciones y experiencia acumulada.

He llegado a ver un sistema industrial como una orquesta. Los músicos pueden ser talentosos, pero a menos que toquen juntos, la música no sonará bien. Una fábrica no es diferente: los estándares son la partitura, las máquinas son los instrumentos, pero lo que hace que el sistema funcione es la capacidad del equipo para tocar en conjunto. Cuando existe esa coordinación, el trabajo fluye. Cuando desaparece, ni siquiera una buena puntuación es suficiente.

Al recordar mi tiempo en esa organización, he visto este mismo patrón manifestarse de diferentes maneras: a veces como falta de coordinación, a veces como falta de alineación y a veces como decisiones que parecían lógicas pero que se tomaron demasiado pronto.

Al inaugurar una nueva planta, por ejemplo, nos vimos sometidos a una fuerte presión para aumentar la producción rápidamente. La empresa había realizado una inversión significativa y alcanzar el punto de equilibrio cuanto antes era una prioridad clara. A medida que aumentaba el volumen de producción, decidimos implementar un segundo turno. En teoría, esto tenía mucho sentido; sin embargo, en la práctica, no fue así, porque el primer equipo aún no estaba consolidado. Algunas habilidades clave seguían estando distribuidas de forma desigual, las situaciones imprevistas no siempre se gestionaban correctamente y los principios básicos (5S, resolución de problemas, TPM, etc.) no se aplicaban de forma consistente.

Al implementar el segundo equipo, no habíamos acelerado el rendimiento, sino que habíamos incrementado la inestabilidad. Esto se hizo dolorosamente evidente durante las visitas a la planta. Los mismos problemas se presentaban en ambos equipos, a veces con ligeras variaciones. En lugar de tener un equipo aprendiendo y mejorando, ahora teníamos dos equipos luchando en paralelo. Tardamos en comprender que habíamos omitido un paso crucial. Antes de escalar, deberíamos haber estabilizado el equipo.

A veces, aunque se tenga un método establecido y se haya implementado una mejora, las cosas siguen sin funcionar. En una planta, habíamos trabajado en la compleja operación de reemplazar una correa de distribución. Mediante una iniciativa kaizen, logramos reducir el tiempo de operación de aproximadamente seis horas a unas dos. El método estaba definido y documentado, y el personal recibió capacitación.

En teoría, el problema estaba resuelto, pero en la práctica, los resultados eran diferentes. Algunos vehículos se completaban cerca del objetivo de dos horas, mientras que otros seguían tardando mucho más. El flujo de trabajo seguía siendo inestable y se formaban colas frente a la estación.

Durante una visita al lugar de trabajo, observamos que diferentes operarios realizaban la misma operación. El estándar existía, pero se interpretaba de forma distinta: se omitían algunos pasos, otros se realizaban en una secuencia diferente, y pequeñas variaciones se acumulaban hasta generar retrasos significativos.

El problema no era el método en sí, sino la falta de un entendimiento común sobre cómo aplicarlo. Para solucionarlo, reunimos al equipo en torno al trabajo. Los operarios comenzaron a observarse entre sí, a debatir las diferencias que detectaban y a consultar el estándar para aclarar lo que realmente importaba. Paso a paso, se alinearon en una forma común de realizar la operación; esta vez, no porque estuviera escrita en el estándar, sino porque la habían comprendido colectivamente.

Efectivamente, en poco tiempo, el rendimiento se volvió más consistente. La variabilidad disminuyó, el flujo mejoró y las mejoras del kaizen inicial finalmente se hicieron visibles a nivel del sistema. La solución técnica había estado presente desde el principio; lo que faltaba era la alineación del equipo en torno a ella.

Con el tiempo, una idea se hizo evidente. La mayoría de las veces, buscamos soluciones en los procesos porque son visibles, medibles y más fáciles de modificar. Pero detrás de cada proceso, siempre hay un equipo que aprende, comparte, desarrolla reflejos comunes y fomenta la inteligencia colectiva.

Cuando esta dinámica funciona, el sistema es robusto. Los problemas se detectan antes, las soluciones surgen con mayor rapidez y el rendimiento mejora de forma constante. Cuando no funciona, incluso el mejor proceso se vuelve frágil.

Con el tiempo, he aprendido a hacerme una pregunta cuando el rendimiento empieza a decaer: ¿es realmente el proceso o es el equipo?

Extraído de: Planet Lean