Obeya Room
Recientemente, en el equipo de la Coordinación Lean se ha estado hablando de los obeya room, también llamados big room, debido a que en un concurso, se solicitó contemplarlo específicamente. Si bien es posible hacer una sala exclusiva de big room, se ha visto que cualquier equipo puede implementarlo, es su departamento u obra designado, con el equipo y presupuesto que tenga disponible, lo verdaderamente importante, es darle el carácter y el uso para el que está designado.
Como parte del modelo, nosotros contemplamos que se puedan realizar en las salas de juntas de las obras este modelo de gestión visual tan emblemático. Cada vez que acudimos a una visita de obra o que iniciamos algún proyecto, sugerimos que dedique un tiempo a poder hacer de este espacio un lugar que invite a leer el proyecto; sin embargo, no siempre se tiene el tiempo o la idea específica de como realizarlo y, muchas más veces, no se tiene el ejemplo de alguien más a quien le haya funcionado y nos perdemos de implementarlo por pensar que es difícil o que simplemente no funciona,¡Pero si funciona!
Hasta hoy, yo sabía que funcionaba porque lo había hecho en otro par de obras, pero no había escuchado experiencias de nadie más, hasta este artículo, con 3 consejos de Steve Shoemaker, ex vicepresidente de ingeniería de la división de movimiento de tierras de Caterpillar, sobre la implementación de múltiples Obeya Rooms dentro de una organización.
Espero pueda inspirarles un poco para que vayamos desarrollando esta gestión visual en nuestras obras, aquí les dejo la experiencia y los tres consejos esenciales para la su implementación.
-Martha Belén Márquez Alderete, Coordinadora Lean Abitat
3 consejos de Steve Shoemaker
- Hacerlo visible
La obeya sirve de 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 rápidamente a los problemas antes de que se conviertan en montañas.
Obeya es un punto de partida habitual en la mayoría de los procesos de LPPD (Lean product & process Development). Se basa en el mapa de flujo de valor y ayuda al equipo a ver rápidamente 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 la perspectiva del valor. Es fácil pensar que el cliente del ciclo de desarrollo es únicamente el usuario final. Sin duda, se trata de la persona que intercambia dinero por tu producto. Sin embargo, desde el punto de vista del ciclo de desarrollo, hay muchos clientes a lo largo del proceso.
En el caso de un ingeniero, podría estar diseñando una pieza que será fabricada por un proveedor externo y luego enviada a una fábrica para su montaje final en una máquina o un automóvil. En este caso, el ingeniero tendría que colaborar estrechamente con el proveedor para crear un diseño satisfactorio.
2. Diferentes estilos para diferentes personas
Mi primera visita a Obeya fue a las instalaciones de Solar Turbine en San Diego, California. Por aquel entonces, yo trabajaba 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. Me intrigaban el proceso y las métricas utilizadas para hacer funcionar la obeya. Mientras sacaba fotos para poder reproducirlo en casa, Howard Kinkade, el líder responsable de la obeya, comentó: “Haz todas las fotos que quieras, pero no creo que te sirvan de mucho”. Me quedé boquiabierto. “Aquí funciona. ¿Por qué no vamos a coger lo que tienes y a correr con ello?”. repliqué. “El equipo tiene que ser dueño de la obeya, y parte de serlo es decidir qué se utiliza para ejecutar el proyecto”, recalcó Kinkade.
La sabiduría convencional sugiere que todos los equipos y ubicaciones deben tener el mismo aspecto. Todos deben trabajar con las mismas métricas. Todos deben tener los mismos gráficos. Es fácil caer en esta trampa. La intención no es mala, pero puede acabar con la creatividad. La mayoría de los equipos tienen sus propias ideas y parte del aspecto de creatividad y desarrollo de conocimientos de Lean, consiste en aprender haciendo. Crear un propósito acorde con el equipo o proyecto común permite probar ideas y adoptar lo que funciona y desechar lo que no.
Rara vez un proyecto se ejecuta íntegramente en un solo lugar. La obeya debe ser flexible para dar cabida a miembros del equipo de varias sedes, a veces en distintos lugares de la misma instalación o ciudad y a veces en distintos estados o países.
En nuestro caso, era habitual tener equipos de todo el mundo dedicados al mismo proyecto. Por ejemplo, miembros de equipos de China, India, Francia y Estados Unidos trabajaban en el mismo programa de excavadoras. Aquí es donde la visibilidad que permite el mapa de flujo de valor en obeya es crucial. Las entradas y salidas (hacia y desde distintos lugares) se hacen visibles y pasan a formar parte del proceso de desarrollo. La tecnología ha simplificado esto de forma significativa y sigue siendo imprescindible que alguien forme parte del proceso de obeya que sea responsable de representar el flujo de trabajo (entradas y salidas) incluso para ubicaciones remotas. Esto puede suponer un reto y, en ocasiones, requerirá un esfuerzo especial para adaptarse a las zonas horarias. Vale la pena hacer el esfuerzo de incluir todas las ubicaciones, aunque sea difícil. La inclusión fomenta la responsabilidad del equipo y es vital para una obeya bien gestionada.
3. Las obeya de proyecto son para los equipos
Una ecuación importante introducida en el libro Diseñar el futuro es MS = OS x LB
Significa que un Sistema de Gestión (SG) es un producto del Sistema Operativo (SO) y de los Comportamientos de Liderazgo (CL). Cuando los comportamientos de liderazgo son buenos, tienen un impacto multiplicador. Los malos comportamientos de liderazgo tienen un impacto deteriorante y se convierten en un reto a superar.
Antes sugerí que introdujéramos el LPPD en varios lugares al mismo tiempo. Esto permitió que varios equipos experimentaran esta nueva forma de desarrollo juntos y, sin embargo, en sus propios emplazamientos. Teníamos muchas obeyas en marcha y, naturalmente, no eran iguales. Pedí a los ingenieros jefe que compartieran con sus compañeros lo que funcionaba y lo que no funcionaba en sus sedes. Esto permitió que el aprendizaje entre las sedes fuera impulsado en lugar de empujado (por mí) y que se adoptará lo que cada equipo consideraba una mejor práctica. En consecuencia, les permitió resolver problemas al tiempo que mejoraba el aprendizaje organizativo.
Jim Lancaster compartió una lección similar en su libro The Work of Management. Destacó que en su fábrica no exigía gráficos comunes que le facilitaran el paso de una zona a otra, sino que quería garantizar la implicación del equipo para mejorar continuamente su trabajo: “Decidimos unas normas para presentar la información en el tablero. Las actividades de mejora para elevar el nivel de rendimiento siempre iban a la derecha del tablero, mientras que las cuestiones cotidianas sobre el mantenimiento del rendimiento iban a la izquierda. Pero, sobre todo, queríamos que esos tableros fueran útiles para las personas que estaban en primera línea”.
Me sentí bendecido al experimentar la innovación que cada equipo demostró al poner en marcha sus obeyas en centros de todo el mundo. Ni mi equipo directivo ni yo hubiéramos podido prescribir la solución más adecuada para cada equipo. Naturalmente, se desarrollaron temas comunes en torno a la calidad, la velocidad (es decir, los plazos), los recursos y las prioridades. Con el tiempo, gran parte del contenido pasó a ser similar y, a menudo, el mismo. Pero esto fue por elección de los equipos y no por mandato de la dirección.
Referencias
0 comments
Write a comment