Obeya Management: 10 consejos prácticos para crear un centro de mando para el éxito

Según Jim Morgan, ex ejecutivo de desarrollo de productos de Fortune 25, la falta de gestión de las interfaces entre disciplinas funcionales puede ser la mayor fuente de desperdicio, frustración y fracaso en el desarrollo de productos. Al menos parte de la solución es un sistema de gestión obeya. En este artículo, Jim ofrece diez consejos para lograr una gestión correcta de la obeya basándose en su experiencia con cientos de proyectos en diversos sectores.

Al igual que los diseños de sistemas complejos, la mayoría de los programas de desarrollo tienen dificultades en las interfaces. Es decir, gestionar las dependencias entre las distintas disciplinas requeridas, como el diseño, el software, la ingeniería, la fabricación y otras, es el mayor desafío del desarrollo. Esto es especialmente cierto cuando las empresas intentan trabajar simultáneamente sin comprender estas dependencias. En mi experiencia, esta puede ser la mayor fuente de repetición de trabajos, rotación de personal, retrasos, sobrecostes y pérdidas de calidad, lo que a menudo conduce a un entorno de trabajo divisivo, combativo y frustrante para todos los involucrados.

El desarrollo de procesos y productos lean (LPPD, por sus siglas en inglés) es un conjunto de principios, prácticas y herramientas diseñadas para permitir que personas de diversas disciplinas trabajen juntas para crear nuevos flujos de valor exitosos. Una de esas herramientas es el sistema de gestión obeya. Obeya, como casi todo el mundo sabe, es una palabra japonesa que significa “sala grande”. Pero, como dice mi amigo Andy Houk, vicepresidente y director general de Schilling Robotics, es mucho más. Es donde el programa se une en cadencia para mejorar la colaboración, la comunicación y la coordinación a través de la gestión transparente y proactiva de esas interfaces. Cuando se hace correctamente, es un poderoso sistema de gestión que ayuda a las personas a trabajar juntas de manera más efectiva, no solo un lugar para colgar cosas en las paredes.

Actualmente existe un debate (sin importancia) sobre la génesis de obeya, pero mi primera experiencia con él como sistema de gestión fue en 2003, cuando mi coautor Jeff Liker y yo tuvimos varias reuniones con Takeshi Uchiyamada, el ingeniero jefe que dirigió el desarrollo del Toyota Prius original. Este producto innovador exigía una gestión rigurosa y eficaz de las muchas interdependencias en las múltiples disciplinas necesarias para integrar las tecnologías necesarias para crear este producto que revolucionó la industria. La obeya proporcionó exactamente lo que el equipo de Prius necesitaba para lograr su éxito.

10 lecciones prácticas de la experiencia

Desde entonces, he participado, ayudado a crear u observado cientos de obeyas en las industrias automotriz, aeroespacial, de sanidad, electrónica, tecnología energética, electrodomésticos y muchas más. Me gustaría compartir algunas reflexiones sobre lo que he aprendido acerca de obeyas exitosas.

1. La obeya no es un entretenimiento para la alta dirección. Es una herramienta para que el equipo de desarrollo gestione su proyecto y debe diseñarse en consecuencia. Por lo general, lo mejor es adoptar un enfoque fijo y flexible para el diseño de obeyas. Proporcione pautas y mejores prácticas a los equipos, tal vez incluso algunos requisitos mínimos, pero deje al equipo mucho espacio para personalizar el espacio para satisfacer sus necesidades específicas.

2. Está bien estar en “rojo”. No está bien permanecer en rojo. Las cosas salen mal en el desarrollo, muchas cosas. La obeya requiere transparencia. Las personas no serán comunicativas si se las critica con dureza cada vez que plantean un problema. En consecuencia, debe ser seguro (normal) plantear un problema. Sin embargo, no puede terminar allí. La obeya no es un lugar para simplemente arrojar sus problemas. Si está informando un estado de proyecto en rojo, también debería poder responder lo siguiente: ¿Cuál es su plan para llegar a verde? ¿Cuál es la fecha para llegar a verde? ¿Qué ayuda se requiere? ¿Cuáles son las implicaciones para el resto del programa?

3. Haga que el plan y el objetivo sean obvios, incluidas todas las rutas de planeamiento críticas. ¿Quién es el cliente? ¿Qué estamos tratando de hacer? ¿Cómo nos proponemos hacerlo? ¿Cuáles son los atributos críticos de este producto o servicio? ¿Cuál es nuestro plan para entregar? ¿Quién es el propietario de qué parte del plan? Recuerde, la obeya es más que un cronograma.

4. Concéntrese en los indicadores adelantados, no en los rezagados. Dé tiempo al equipo para reaccionar y solucionar los problemas. No ayuda saber que algo se retrasará cinco semanas, el día de entrega. No hay mucho que pueda hacer entonces. Trabaje a partir del evento crítico: ¿qué paso es más probable que determine el resultado de ese entregable?

5. Utilice puntos de integración efectivos definidos por los criterios de calidad del evento, no solo por la actividad. Demasiados programas definen puntos de integración o hitos únicamente por una actividad. Por ejemplo, tomemos la primera construcción virtual. En ese sistema, usted realiza la actividad, por lo que se cumple el hito. Eso puede ser increíblemente engañoso. ¿Cuántos diseños estaban en el nivel adecuado de madurez? ¿Cuántos problemas abiertos tenía? ¿Cuál era el nivel de preparación de los proveedores o de la fabricación? (es decir, ¿podemos siquiera entregar esos diseños?). Establezca umbrales mínimos de calidad.

6. Transparencia + Cadencia = Responsabilidad – Drama. En mis inicios, participé en más reuniones de programas en las que se golpeaba la mesa, se amenazaba e incluso se tiraban sillas. Era un drama que decía mucho más sobre el líder que sobre el equipo del programa. Y creaba un entorno en el que el objetivo de informar sobre el estado era bajarse del escenario y no ser la gacela más lenta.

Comparen eso con el “Está bien, volveremos la semana que viene y sé que tendrán un plan mejor” de Alan Mulally en sus famosas Revisiones de planes de negocios. Ese es el poder de la transparencia y la cadencia. Sin gritos, sin amenazas, pero tampoco ningún lugar donde esconderse porque seguiremos uniéndonos.

Solo una nota rápida sobre la cadencia y la ubicación de la obeya. Ambas pueden variar según las necesidades del proyecto/programa. Al principio del programa, es posible que el equipo solo deba reunirse cada dos semanas. Pero durante los períodos de pruebas intensas, construcción o lanzamiento, es posible que el equipo deba reunirse todos los días. De manera similar, la obeya puede estar ubicada en el diseño al comienzo del programa, el taller de prototipos en el medio y la planta de fabricación durante el lanzamiento.

7. La participación no es opcional. Todos están incluidos. Todos comprenden el plan y sus responsabilidades. Todos participan. Esto incluye a los proveedores clave o líderes de la cadena de suministro según sea necesario.

8. Los líderes de flujo de trabajo individuales hablan con los miembros de su flujo de trabajo. Ellos saben más y son las personas responsables.

9. Establezca y utilice una cadena de ayuda eficaz. En ocasiones, los problemas requerirán ayuda que excede la capacidad de un equipo individual. Debe haber un método predefinido y eficaz para plantear los problemas y ayudar al equipo de manera oportuna. Consejo: no se trata de añadir más informes a la gerencia superior.

10. Revise el programa en el nivel adecuado. No desperdicie el tiempo de todos en los detalles resolviendo un problema individual. Hágalo después. Su enfoque debe estar en gestionar las interfaces. Pero al mismo tiempo, debe resistirse a “viajar con esperanza” con grandes bloques de tiempo indefinidos. Como muchas cosas, es un equilibrio que debe mantener un liderazgo capacitado.

Aprovechar la velocidad y la precisión

El trabajo conjunto de varias disciplinas al mismo tiempo es la clave para aumentar la velocidad de comercialización. No tiene por qué conducir a enormes cantidades de retrabajo y desperdicio. La clave del éxito es comprender el trabajo real que se debe realizar y las dependencias entre flujos de trabajo. Diseñar su proceso de desarrollo para aprovechar estas dependencias es el primer paso para hacerlo bien.

Pero su proceso de desarrollo no puede prever todos los modos de fallo potenciales ni diseñar contramedidas. Tampoco debería hacerlo. Esto crearía un proceso burocrático que, en el mejor de los casos, tomaría incluso más tiempo que un proceso en serie y, en el peor, sería completamente imposible de ejecutar. La obeya le permite administrar sus dependencias en tiempo real. Verá un posible conflicto en el horizonte y tendrá un foro listo para reaccionar, corregir el rumbo y mantener a todos en la misma página.

Cuando se toman en conjunto, el diseño eficaz del proceso de desarrollo y el sistema de gestión obeya ayudarán a sus equipos de desarrollo a ejecutar con un nivel de velocidad y precisión que servirá como una ventaja competitiva.

Su desafío este mes es sencillo. Utilice las experiencias compartidas por John Drogosz, Steve Shoemaker y el equipo de TechnipFMC para mejorar la forma en que sus equipos de desarrollo se comunican, colaboran y coordinan.

Buena suerte.

Dr. Jim Morgan. Asesor senior en Lean Enterprise Institute