Búsqueda


19 de diciembre de 2018

Las amebas y la estrategia

¿Has visto alguna vez una ameba? Al microscopio, en vivo y en directo… en la EGB, quizás? en el Instituto?

Una ameba es un ser vivo unicelular, no tiene cilios ni flagelos, como podrían tenerlos un paramecio o un vibrión colérico. Una ameba se mueve emitiendo pseudópodos, arrastrando lentamente parte de la masa celular en el sentido en que se quiere desplazar y luego moviendo el resto de la célula completa hacia allí.

Cuando se quiere alimentar, emite dos pseudópodos que rodean la partícula que quiere absorber hasta que éstos se unen y fusionan, dejando a la particula dentro de la ameba.


Pues las empresas son como las amebas.

Llevo años explicando esto en mis clases, primero cuando hablaba de mejora continua en ITIL, después cuando hablaba de mejora continua en ISO/IEC 20000, luego cuando hablaba de mejora continua en Lean y últimamente cuando hablo de mejora continua en Agile. Es mi forma de ver la importancia que tiene el impacto que tiene desplegar el pensamiento estratégico hacia toda la organización cuando estamos fomentando una cultura de mejora continua. Y sin embargo, repasando este blog nunca había escrito sobre la ameba.

Pero hoy he visto un post de Txell Costa donde hace una metáfora parecida pero con una goma elástica… y por eso me he decidido a escribir sobre la relación que hay entre un ser unicelular, microscópico, sin cilios ni flagelos, que se mueve por medio de pseudópodos … y tu empresa.

Las empresas son como las amebas. Emiten un pseudópodo y exploran nuevos territorios, como tú cuando tocas el agua de la playa con la punta del pie antes de meterte, tanteando a ver si está demasiado fría. Estos nuevos territorios pueden ser nuevos mercados, nuevos productos, nuevas maneras de hacer, nuevas maneras de organizar… emiten un pseudópodo y tantean y, si les parece que el agua está de su gusto, se tiran (algunas de cabeza y otras de culo… ya sabemos cómo va esto...)

En un entorno tradicional y jerarquizado, la alta direccion sabe a dónde quiere ir, y cuáles son los planes estratégicos para los próximos 5 años. La visión es clara y dirige el timón con mano férrea hacia ese horizonte que se ha planteado. En estos casos, transmitir la estrategia a los trabajadores no es necesario, es incluso contraproducente, no vaya a ser que alguien se vaya de la lengua, cuente nuestros planes y la competencia acabe adelantándonos.<ironic mode off>

Y qué pasa con la mejora continua? Los pequeños movimientos evolutivos no forman parte de aquellos grandes planes estratégicos, asi que aparece otra manera de avanzar: el modo ameba, en el que pequeños grupos de personas dentro de la organización se plantean pequeñas mejoras que hacen más eficiente el sistema o más valioso el producto final. Esas pequeñas mejoras se plantean como pruebas o experimentos (Da igual cuál sea el modelo de mejora continua que uses, más tarde o más temprano aparece el Dr. Deming con su ciclo PDCA y el planteamiento de experimentos… no conozco ningún modelo de mejora continua que no pase por ahí)

Bien. Ya he puesto en tu cabeza la imagen de la amena extendiendo sus pseudópodos para experimentar un nuevo terreno.

¿Funcionará bien la nueva manera de gestionar pedidos? Hacemos un piloto, probamos un MVP, hacemos una prueba con un par de clientes, extendemos a “friends & family” y si todo va como debe ir, pues ¡adelante!

Pero los métodos modernos de mejora continua tratan de conseguir un factor multiplicador involucrando a todo el personal de la organización (a lavez que potencian la cultura, empoderan al personal y un buen atado de otras ventajas). Se trata de paralelizar el modelo evolutivo y conseguir un pipeline continuo de experimentos. Hasta llegar al extremo asombroso de booking.com y sus 2^1000 versiones concurrentes de la web. Esto significa que estamos montando modelos de mejora continua que tratan de conseguir multitud de pequeños equipos distribuidos por la organización haciendo experimentos y provocando pequeños cambios que, en algunos casos, pueden resultar interesantes y provocar una tensión de movimiento “hacia allí"

Pero ¡atención! No estamos hablando de un ser pluricelular que hace muchos experimentos, sino de una pobre y triste ameba, unicelular y sin cilios ni flagelos.

¿Qué le pasa a la ameba si de repente emite 50 pseudópodos en direcciones opuestas y se empeña en moverse?

Lo mismo que le pasa a tu empresa cuando no se ha transmitido la estrategia y se montan grupos de mejora: cada vez que un grupo de mejora encuentra algo interesante (es decir, realiza un experimento exitoso) provoca una tensión hacia aquello que ha descubierto. Una empresa cuyos equipos no conocen la estrategia y tiene pocos experimentos exitosos se moverá como un tronco a la deriva en medio del océano: en el mejor de los casos, se deja llevar por los resultados de estos experimentos.

Pero una empresa que no ha transmitido la estrategia a sus colaboradores, que fomenta un entorno de mejora continua con gran parte de su personal y que además consigue multitud de éxitos en los experimentos, puede terminar intentando avanzar de forma simultánea en direcciones contrarias. En el mejor de los casos no se mueve y en el peor de los casos se rompe, se parte la pared celular y todo citoplasma queda por ahí desparramado. ¡Qué triste!

¿Nunca has tenido la sensación de que en tu empresa tienes varios jefes y que estos jefes estiran de ti en direcciones opuestas como si te estuviesen torturando al estilo mongol con 4 caballos?


Una buena transmisión de la estrategia corporativa ayuda a que los experimentos vayan en direcciones similares al menos, reduciendo el riesgo de que la empresa se parta, los trabajadores se quemen o la goma elástica de Txell salte por los aires.

Finalmente y por aterrizar esto a un terreno más práctico: si te imaginas una empresa que tiene varios equipos de desarrollo usando Scrum y estos equipos hacen retrospectivas y plantean pequeñas mejoras, te recomiendo que:

  1. Los equipos tengan claro hacia dónde vamos
  2. Hagas Retros de Retros uniendo representantes de los equipos o una comunidad de Scrum Masters para que vean periódicamente si las mejoras propuestas por el equipo A no le están haciendo la vida imposible al equipo B o al departamento C

20 de septiembre de 2018

Scrum en organizaciones Lean: más madera para el Product Owner!

Dentro de mi viaje particular al Nirvana del Flow, esta semana he tenido un momento importante. Facilitando un evento Kaizen para el equipo de almacén de un cliente, intentando corregir unos “problemillas” que había con unos bultos que se traspapelaban por el camino hemos seguido todos los pasos de rigor: plantear el problema, hacer un VSM, identificar oportunidades de mejora, análisis de causas etc etc.

Lo de siempre en el mundo Lean, siempre tan interesante gracias a la participación de todos. Aparte de todo lo que aprendí del mundo de los almacenes y la logística, que es impresionante, pude vivir (otra vez!) la excitación que te genera ver que el equipo Kaizen no se enfoca en las guerras personales y empieza a trabajar de manera creativa en comprender el problema y plantear contramedidas, siempre de manera transversal y cross-departamental. ¡Es alucinante!

Pero por el camino empecé a notar que la cosa se podía complicar. En seguida aparecieron propuestas de pequeños cambios en el proceso, pequeñas modificaciones en la operativa (con el consiguiente problema de Gestión del Cambio con el personal y sus diferentes turnos) y el nacimiento de nuevas necesidades de información, controles y sistemas de información.

¿Quien dijo que los procesos industriales son más fáciles de gestionar porque están estandarizados?

Este proceso que estábamos analizando es fácil de comprender, pero la cantidad de casuísticas que tiene es impresionante y ahí aparecía una de las lecciones importantes del Kaizen… recuerdas? “Kaizen … yo me flagelo y hago un sacrificio por el bien común”.

Para conseguir un proceso más homogéneo y sin tantas excepciones y casos especiales todos deben hacer pequeñas concesiones para conseguir optimizar el proceso de forma global en lugar de perseguir las optimizaciones locales e independientes para cada uno de los interesados. En este caso, el equipo de almacén se ve afectado por los requisitos, limitaciones o presiones impuestas en el proceso aguas arriba (por ejemplo, presiones en la planificación establecidas dos o tres eslabones antes de llegar a la preparacion de un pallet que debe ser expedido).

Y ahora vamos a pensar un poco más allá; este post no pretendía ser una explicación sobre una sesión de Kaizen. ¿Te imaginas una empresa en la que los diferentes equipos hacen sesiones de Kaizen para ir mejorando poco a poco los procesos de negocio? En el almacén, en compras, en logísticas, en pedidos… en todas partes gente haciendo pequeñas modificaciones y pequeñas mejoras sobre los procesos, haciendo que la empresa lentamente vaya evolucionando a mejores cotas de calidad, eficiencia y valor para el cliente. ¿Mola, no?

¿Y dónde están los informáticos?

¡Esa es la reflexión clave! Si los procesos evolucionan continuamente, informática debe ser capaz de soportar esas modificaciones de forma continua, debe facilitar la adaptación permanente de los sistemas de información a las necesidades y a los cambios provocados por la mejora contínua del negocio.

Es lo que hacemos siempre, no? Desde luego, no me cabe la menor duda de que siempre estamos intentando mantener un ritmo decente de modificaciones/evoluciones a nuestros sistemas de información, pero en un entorno Lean donde la evolución y el cambio son constantes el nivel de exigencia es mucho mayor.

¿Y cómo respondemos en informática a esta situación de elevada demanda de pequeños cambios sobre los mismos sistemas de información?

Con equipos especializados en esos sistemas de información, focalizados en el proceso, orientados a la ejecución de tareas que finalizan con un incremento de producto totalmente funcional.. respondemos a las células de producción con células de producción. Los equipos ágiles son especialmente necesarios en estos entornos donde no dar respuesta incremental a estas demandas significa frenar la mejora de los procesos de negocio.

Por eso es tan y tan importante provocar la transformación ágil en los entornos Lean para hacer que flujo, valor y calidad vayan de la mano en todos los sentidos. Y cuando tengas en marcha equipos ágiles, si usas Scrum por favor, asegúrate de que al menos el Product Owner asiste a las sesiones Kaizen de su cliente.

Ni te imaginas el aprendizaje y la cantidad de información y de ideas enriquecedoras que el equipo de desarrollo se va a llevar de esas sesiones: es ver a tus usuarios tratando de resolver sus problemas utilizando tus herramientas.


Postdata: en este evento Kaizen que estoy facilitando está presente la Product Owner y varias personas del equipo de desarrollo… está siendo una experiencia super enriquecedora para todos!