Lean: El bar de Pepe

 

El bar de Pepe es atendido por un Barman que prepara pedidos de bebidas a sus clientes. Un día, el Barman comenzó a leer un libro acerca del pensamiento 'Lean', y así comprendió algunos conceptos nuevos para él, aunque datan de muchos años atrás.

Cuatro de estos conceptos son los siguientes: el trabajo en proceso o WIP, que indica los pedidos que se están preparando; el tiempo de entrega de una bebida, o también denominado Lead Time, que es el tiempo total desde el momento en que le hacen un pedido hasta el momento en que lo sirve y entrega al cliente; el tiempo de ciclo o Cycle Time, es el intervalo de tiempo entre dos bebidas que salen de la barra y son entregadas al cliente o tiempo que se tarda el Barman en completar la preparación de una bebida; y el rendimiento o Throughput, que es el número de bebidas que se entregan en un período de tiempo, como si se tratase de su velocidad de entrega.

Proceso Kanban del bar de Pepe y sus métricas relevantes

Con estos conceptos aplicó la famosa Ley de Little que dice que "la cantidad promedio de elementos de trabajo en proceso (WIP) en un sistema estable, con WIP fijo, es igual a la tasa de entrega (Throughput) promedio multiplicada por el tiempo promedio que pasan en el sistema (Lead Time)".

Así que calculó su tiempo de entrega basado en su rendimiento individual, estimando una media de seis bebidas entregadas por hora, preparando una bebida a la vez (WIP=1).

WIP = Throughput x Lead Time

1 = 6 bebidas x hora * Lead Time

Lead Time = 1 / 6 x hora

Lead Time =  0,16 hora = 10 min

Así supo que el tiempo en que se demoraba en satisfacer las necesidades de sus clientes era de 10 minutos, su Lead Time.

Pepe, quien gestionaba el bar, le pidió al Barman que trabajara más duro y que atendiera a varios clientes a la vez, porque así sería más eficiente. Le pidió que hiciera 3 pedidos en paralelo.

Luego de un tiempo el Barman hizo el cálculo de su Lead Time considerando el mismo rendimiento individual.

3 = 6 x hora * Lead Time

Lead Time = 3 / 6 x hora

Lead Time =  1/2 hora = 30 minutos

Resulta que descubrió que lo que parecía más eficiente para el gerente era todo lo contrario para el cliente, porque ahora se demoraba media hora en entregar cada pedido.

Así es como el Barman comenzó a convertirse en Bartender aplicando 'Lean'.

Gestiona el sistema, no las personas

Con John Little y su ley se viene contando esta historia de diferentes maneras y diferentes autores, como Cliyahu Goldratt con “The Goal” o Caroli con sus "Whisky, Sushi, Systems and Flow". Pero contar historias es fácil, lo difícil es implementar sus enseñanzas. Este ejemplo es muy simple, pues en las organizaciones el flujo de trabajo es mucho más complejo, con mayores dependencias, diferentes roles, tipos de trabajo y muchas variables en juego. A pesar de la complejidad en la mayoría de organizaciones, las ideas de Little se pueden aplicar en el día a día en cualquier equipo de trabajo o área. Principalmente porque es un principio sistémico y todas las organizaciones y sub-organizaciones son sistemas.

Estos conceptos son útiles para entender el sistema de trabajo de una organización. Utilizando el ejemplo del Barman se dimensiona el funcionamiento del sistema usando estos conceptos, entendiendo que para el cliente el Lead Time es lo más importante, incluyendo tanto el tiempo de espera como el tiempo de proceso. Este último, el Cycle Time, indica el tiempo en el cual el 'ítem de trabajo' fue realmente procesado sin cola de espera. Muchas veces los administradores se centran mucho en el Cycle Time sin prestar atención al tiempo de espera, olvidándose así que en sistemas complejos la suma de todos los tiempos de espera generan un alto costo de retraso. Sin embargo, con Lean se sabe que lo que importa son ambos (tiempos de espera y Cycle Time), y que la felicidad del Barman y del cliente dependen de lograr un sistema estable de flujo con cadencia. Si a la barra del bar llegan más pedidos de los que se puede atender, se dejarán clientes insatisfechos y se exigirá al sistema de más, generando mala calidad del producto, errores o agotamiento del personal. Por el contrario, si su velocidad de entrega (Throughput) es mayor a la velocidad de llegada de pedidos, tendrá demasiada ociosidad. Por lo tanto, la eficiencia está en el balance, donde la tasa de arribos (AAR) debe ser equivalente a la tasa de entregas (ADR). 

Proceso Kanban del bar de Pepe y tasas de entrada y salida del sistema

En un sistema estable, balanceado, no hay divergencia ni convergencia entre tasas de arribos y entregas. El Barman trabaja a su capacidad, saludablemente, en un tiempo óptimo de entrega, satisfaciendo las necesidades de sus clientes. Así el bar se mantiene y puede prosperar.

Diagrama de tasas de entrada y salida de un sistema balanceado y estable

Pero todo sistema tiende a desbalancearse. Si el sistema está desbalanceado, no sirve de nada que Pepe presione al Barman para que trabaje más rápido, haga pedidos en paralelo o realice horas extras. La clave está en el balance, y parte de balancear es controlar el WIP y no a la gente. Gran parte de las veces, el rendimiento del sistema depende más de la estructura del sistema que de los rendimientos individuales de las personas que participan en el sistema.

En un sistema desbalanceado, una tasa de divergencia positiva (entre la tasa de arribos y la de entrega) sugiere que el WIP es demasiado alto y estamos sobrecargados (entran más pedidos de lo que salen). 

Diagrama de tasas de entrada y salida de un sistema desbalanceado

Por otro lado, una divergencia negativa (entran menos pedidos de los que pueden salir) sugiere que el límite WIP es bajo y que la productividad es baja (desaprovechando capacidad).

Sistema desbalanceado con divergencia negativa

Hay algo peor que un sistema desbalanceado y es un sistema muerto. Si una línea se vuelve plana, eso significa que no llega nada a la etapa correspondiente o que nada sale; y cuando nada entra y nada sale es cuando prácticamente un sistema muere. Si un bar no recibe pedidos y no entrega bebidas muere.

Sistema sin actividad

¿Para qué nos sirven entender estos gráficos anteriores? Pues, nos ayudan a comprender una de las herramientas analíticas más usada en gestión Lean, el Diagrama de Flujo Acumulado (CFD). El CFD nos muestra el nivel de estabilidad del flujo en un sistema de trabajo, ya sea un bar, un restaurante, un equipo de desarrollo de software o un equipo de reclutamiento. 

Ejemplo de un Cumulative Flow Diagram – CFD

En resumen, como indica John Little (1961) "el número medio de elementos de trabajo en un sistema estable es igual a su tasa de terminación promedio, multiplicada por su tiempo promedio en el sistema".

Finalizando con el ejemplo, si Pepe comienza a tener la mirada Lean como el Barman hará suya una frase que dice: "Gestiona el sistema, no las personas" (Management 3.0). Más gerentes deberían aplicar la ley de Little y gestionar el sistema: minimizar Cycle Time y Lead Time, maximizar Throughput (promedio), limitar el WIP a un óptimo y balancear (igualar tendencias AAR y ADR).

Referencias:

• https://blog.andrefaria.com/agilebr-7-maneiras-de-controlar-o-lead-time-com-whisky-por-paulocaroli

• https://agileramblings.com/2013/01/13/what-should-my-wip-limit-be-super-easy-method-to-find-out/

Kanban: Las tres reglas básicas del Método Kanban

En este post quería comentar didácticamente las bases del método Kanban. Pues el mismo, es un sistema de trabajo, con una mirada sistémica orientada al proceso de trabajo con el fin de optimizarlo. A "Kanban básico" se lo puede entender por sus tres tres reglas principales:

1. Mostrar el proceso,
2. Limitar el trabajo en curso; y
3. Optimizar el flujo.

Para “mostrar el proceso” de trabajo y sus ítems se suele usar un tablero físico o herramienta digital equivalente con tarjetas representando los ítems de trabajo.

Para “limitar el trabajo en curso” se busca acordar entre los involucrados límites sobre la cantidad de ítems de trabajo que pueden encararse a la vez. A este volumen de trabajo en curso se lo llama WIP (Work in Progress).

Y para “optimizar el flujo” se monitorea y sigue el avance de los ítems de trabajo en el flujo del proceso, para determinar si el progreso sigue un ritmo regular, estable y óptimo. Para ello se usan métricas tales como el Cycle time (Ct), Lead time (Lt) y el Throughput.

Métricas

Las métricas de Kanban provienen de teoría de colas y son las siguientes:

El Cycle time (Ct) es el tiempo de ciclo cuando el trabajo real comienza hasta cuándo está listo para entregarse (tiempo que sucede entre el inicio y el final del proceso, para un ítem de trabajo dado sin los tiemos de cola o espera). El Cycle time es más una medida mecánica de la capacidad del proceso de trabajo del sistema.

El Lead time (Lt) es el tiempo total de espera del demandante o tiempo total de procesamiento de todo el sistema en que una tarea o ítem es introducido en el sistema hasta que el trabajo está completado y es entregado. El Lead time comienza cuando es hecha la petición y termina cuando se entrega el trabajo listo. Ver el siguiente gráfico ejemplo:

El Touch Time (Tt) es la métrica que registra el tiempo en el cual un ítem de trabajo fue realmente trabajado (o "tocado") por el equipo (cuantos días hábiles pasó este ítem en columnas de "trabajo en curso", en oposición con columnas de cola / buffer y estado bloqueado o sin trabajo del equipo sobre el mismo).

La relación entre estas tres métricas es: Tt <= Ct <= Lt

Por otro lado, el Throughput es el rendimiento del sistema de trabajo, como capacidad de producción, que consta de el número medio de unidades procesadas en un tiempo determinado.  O sea que, representa la cantidad de ítems que un equipo puede terminar en un periodo dado, por ejemplo 4 ítems por semana.

Finalmente y complementariamente, para optimizar el flujo, se pueden utilizar diferentes herramientas de análisis como el CFD. El CFD o Diagrama de Flujo Acumulado, es una herramienta que permite evidenciar cuellos de botella mostrando el flujo de trabajo en el sistem según períodos de tiempo. Esta herramienta es muy utilizada en Kanban.

Resumen

En fin, esto es Kanban y lo bajé a un gráfico auto-explicativo.

Quería recordar que Kanban puro es una alternativa a la agilidad o una técnica a sumar en un marco ágil, pero no es ágil por definición. De los cuatro valores del manifiesto ágil, el único que se puede argumentar que si sigue Kanban por naturaleza es el de responder al cambio frente a seguir un plan.

Kanban en Ingeniería de Software

Hay que aclarar que en Ingeniería de Software se usa el "Método Kanban" definido por David Anderson. El mismo agrega tres prácticas más a las básicas anteriores: 

• Dirigir y gestionar el flujo.
• Hacer las Políticas (reglas y directrices de su trabajo) de Proceso Explícitas.
• Utilizar modelos para reconocer oportunidades de mejora.

Además fundamenta el método Kanban en cuatro principios:

1. Comience con lo que hace ahora.
2. Se acuerda perseguir el cambio incremental y evolutivo.
3. Respetar el proceso actual, los roles, las responsabilidades y los cargos.
4. Liderazgo en todos los niveles.

Y, además, propone los roles de Product Owner y Flow Master (facilitador).



Referencias: 

• Kanban In Action, by Marcus Hammarberg, Joakim Sunden, Publisher: Manning Publications.
• Kanban: Successful Evolutionary Change for your Technology Business, by David J. Anderson, Publisher: Blue Hole Press.
• Blog: Kanban - Definition of Lead Time and Cycle Time.
• The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen.
• Kanban, an alternative path to agility by David Anderson.
• Kanban… ¿realmente es ágil?
• Anderson, David (septiembre de 2003). Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall. ISBN 0-13-142460-2.
• Anderson, David (abril de 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. ISBN 0-9845214-0-2.
  http://web.archive.org/web/http://www.djaa.com/principles-kanban-method 
• David Anderson "The principles of the Kanban method" December 10, 2010
• Anderson, David (septiembre de 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. ISBN 978-0-9845214-0-1.