Desarrollo de productos y procesos Lean

Lean Institute Chile

Desarrollo de productos y procesos Lean a escala: implementación de Obeya en equipos globales

Al implementar los lugares de trabajo de obeya a nivel mundial, una trampa fácil de caer es exigir que cada ubicación tenga la misma apariencia, sensación y métricas. Steve Shoemaker, ex vicepresidente de ingeniería de la División de Movimiento de Tierras de Caterpillar, ofrece consejos sobre cómo eludir esta trampa en función de su experiencia en la gestión de equipos multinacionales de ingenieros.

Por Steve Shoemaker

Sea uno de los primeros en obtener los últimos conocimientos de los líderes de opinión y profesionales de Lean Product and Process Development (LPPD) de LEI. Este artículo fue entregado a los suscriptores de The Design Brief, el boletín de LEI dedicado a mejorar la capacidad de innovación de las organizaciones. Es el primero de cuatro de una serie centrada en obeya, una forma de gestión visual que es especialmente poderosa en el desarrollo de productos. Al representar información crítica del programa e involucrar a los equipos multifuncionales en reuniones cadenciales, el obeya facilita la comunicación rápida, crea alineación y permite la resolución rápida de problemas para mantener los programas según lo programado.

"Hazlo visible" son las palabras que más recuerdo de las conversaciones que he tenido con Jim Morgan, PhD, un experto mundialmente reconocido en desarrollo de productos y coautor de Designing the Future y The Toyota Product Development System. "Eso" es el trabajo. Verlo, el trabajo, en una fábrica es relativamente sencillo. Verlo en el mundo del desarrollo de productos es difícil en el mejor de los casos y se vuelve cada vez más difícil con la complejidad del proyecto, incluidas las ubicaciones involucradas en el proyecto.

Nuestra división saltó a Lean Product and Process Development (LPPD) en el verano de 2018, aprovechando la oportunidad de asistir a la primera conferencia "Designing the Future" en Traverse City, MI. Elegí enviar ingenieros de los campus de EE. UU. y Francia, un total de cinco ubicaciones y 17 ingenieros. Esto expuso todas las líneas de productos por igual a este nuevo enfoque de desarrollo. Además de estas cinco ubicaciones principales, había equipos en Italia, Brasil, India, Tailandia y China que estaban entrelazados.

Cuando digo saltó, me refiero exactamente a eso. El enfoque convencional para introducir lean es desarrollar un solo experimento que demuestre el éxito para que luego pueda replicarse en toda la organización. En el caso de la división de movimiento de tierras de Caterpillar, no tenía la confianza de que este enfoque funcionaría dadas nuestras circunstancias. Estábamos bajo una tremenda presión de costos, tanto de costos variables como de período. La gerencia estaba impaciente por el cambio, por lo que la acción en todos los frentes era vital.

La división tenía una bandera común para impulsar un sentimiento de unidad. Sin embargo, cada ubicación operaba bajo su propio administrador y conjunto de finanzas. Esta independencia fue una fuente de orgullo y una barrera para las ideas de otros lugares. No inventado aquí reinaba supremo. En consecuencia, las semillas tuvieron que plantarse en cada lugar para que florecieran a la luz de los equipos locales. Encontrar un terreno común para compartir las mejores prácticas llegaría con el tiempo.

Hazlo visible

El obeya es un punto de partida común para la mayoría de los viajes de LPPD. Se basa en el mapa de flujo de valor y ayuda rápidamente al equipo a ver el flujo de trabajo para una mejor creación de valor. También ayuda a los miembros del equipo a ver quiénes son sus clientes desde una perspectiva de creación de valor. Es fácil pensar solo en el usuario final como el cliente en el ciclo de desarrollo. Sin duda, esta es la persona que cambia la moneda por su producto. Sin embargo, a partir de un ciclo de desarrollo, hay muchos clientes a lo largo del proceso. En el caso de un ingeniero, él o ella podría estar diseñando una pieza que será fabricada por un proveedor externo y luego enviada a una fábrica para su ensamblaje final en una máquina o automóvil. En este caso, el ingeniero tendría que colaborar estrechamente con el proveedor para crear un diseño exitoso.

El obeya sirve como centro de coordinación para garantizar que el flujo de valor fluya sin problemas. Permite al equipo ver el desarrollo en tiempo real y responder a los problemas como colinas de topos antes de que se conviertan en montañas.

Diferentes golpes para diferentes personas

Mi primera visita obeya fue a las instalaciones de Solar Turbine en San Diego, CA. En ese momento, tenía mi sede en Carolina del Norte en nuestra división de máquinas pequeñas y estaba ansioso por aprovechar el impulso de otra parte de la empresa. Estaba intrigado por el proceso y las métricas utilizadas para ejecutar la obedece. Mientras tomaba fotos para que pudiéramos replicarlo en casa, Howard Kinkade, el líder responsable de la obediencia, comentó: "Toma todas las fotos que quieras, pero no creo que te ayuden mucho". Me quedé estupefacto. "Funciona aquí. ¿Por qué no deberíamos tomar lo que tienes y correr con él?" —repliqué. "El equipo necesita ser dueño de la obeya y parte de ser dueño de la obeya es decidir qué se usa para ejecutar el proyecto", enfatizó Kinkade.

La sabiduría convencional sugiere que cada equipo y ubicación debe tener la misma apariencia. Todos deben trabajar con las mismas métricas. Todos deberían tener los mismos gráficos. Esta es una trampa fácil de caer. La intención no es mala, pero puede negar la creatividad. La mayoría de los equipos tienen sus propias ideas y parte del aspecto de creatividad y desarrollo de conocimientos de lean es aprender haciendo. Crear un propósito obediente adecuado para un equipo o proyecto común permite al equipo probar ideas y adoptar lo que funciona y tirar a la basura lo que no.

Rara vez un proyecto se ejecuta completamente en un solo lugar. El obeya debe ser flexible para acomodar a los miembros del equipo de múltiples sitios, a veces en diferentes ubicaciones en la misma instalación o ciudad y, a veces, en diferentes estados o países.

En nuestro caso, era común tener equipos de todo el mundo involucrados en el mismo proyecto. Por ejemplo, los miembros del equipo en China, India, Francia y EE. UU. Estarían trabajando en el mismo programa de excavadoras. Aquí es donde la visibilidad que permite el mapa de flujo de valor en la obeya es crucial. Las entradas y salidas (hacia y desde diferentes ubicaciones) se hacen visibles y se convierten en parte del proceso de desarrollo. La tecnología ha simplificado esto significativamente y sigue siendo imperativo que alguien sea parte del proceso de obedecer que sea responsable de representar el flujo de trabajo (entradas y salidas) incluso para ubicaciones remotas. Esto puede ser un desafío y, a veces, requerirá un esfuerzo especial para adaptarse a las zonas horarias. Vale la pena el esfuerzo de incluir todas las ubicaciones, incluso si es difícil. La inclusión genera responsabilidad en el equipo y es vital para una obediencia bien administrada.

Los proyectos obeyas son para equipos (no para la administración)

Una ecuación importante introducida en el libro Diseñando el futuro es:

MS = OS x LB

Significa que un Sistema de Gestión (MS) es un producto del Sistema Operativo (SO) y los Comportamientos de Liderazgo (LB). Cuando los comportamientos de liderazgo son buenos, tienen un impacto compuesto. Los malos comportamientos de liderazgo tienen un impacto de deterioro y se vuelven difíciles de superar.

Sugerí anteriormente que introdujéramos LPPD en múltiples ubicaciones al mismo tiempo. Esto permitió que varios equipos experimentaran esta nueva forma de desarrollo juntos y, sin embargo, en sus propias ubicaciones. Teníamos muchas obeyas corriendo y, naturalmente, no eran las mismas. Les pedí a los ingenieros jefes que compartieran con sus compañeros lo que funcionaba y lo que no funcionaba en sus ubicaciones. Esto permitió que el aprendizaje entre sitios fuera retirado en lugar de empujado (por mí) y la adopción de lo que cada equipo consideraba una mejor práctica. En consecuencia, les permitió resolver problemas al tiempo que mejoraba el aprendizaje organizacional.

Jim Lancaster compartió una lección similar en su libro The Work of Management. Destacó que en su fábrica no requería gráficos comunes que le facilitaran el paso de una zona a otra, sino que quería asegurarse la propiedad del equipo para mejorar continuamente su trabajo: "Decidimos algunos estándares para presentar la información en el tablero. Las actividades de mejora para elevar el nivel de rendimiento siempre iban en el lado derecho del tablero, mientras que los problemas diarios sobre el mantenimiento del rendimiento iban en el lado izquierdo. Pero sobre todo, queríamos que esas tablas fueran útiles para las personas en primera línea".1

Me consideré bendecido por experimentar la innovación que demostró cada equipo cuando lanzaron sus obeyas en sitios de todo el mundo. Mi personal de liderazgo y yo no podríamos haber prescrito la solución que mejor sirviera a cada equipo. Naturalmente, se desarrollaron temas comunes en torno a la calidad, la velocidad (también conocida como línea de tiempo), los recursos y las prioridades. Con el tiempo, gran parte del contenido migró para ser similar y, a menudo, el mismo. Esto fue por elección de los equipos y no por un mandato de gestión.