Openness

Midiendo la eficiencia de nuestro flujo de entrega en Kanban (I)

El método Kanban nace para ayudar a definir o mejorar sistemas que consisten en flujos de entrega de valor, tal como puede ser un sistema de venta de correo, un servicio de comida o un servicio de mantenimiento de aplicaciones informáticas. Kanban pone énfasis en conseguir una entrega de valor temprana y rápida al cliente, proponiendo distintas prácticas que tienen por objeto conseguir que el flujo de entrega en nuestro sistema sea eficiente y lo más estable, continuo y rápido posible.

La primera pregunta que nos surge es cómo podemos medir la eficiencia de nuestro flujo. Kanban propone para ello el uso de dos métricas principales:

– Lead time (tiempo de entrega): Es el tiempo transcurrido desde que entra la orden de trabajo a nuestro sistema hasta que se realiza la entrega de la misma. Se suele medir en días de trabajo.

– Cycle time (tiempo de desarrollo): Es el tiempo transcurrido desde que empezamos a trabajar en una orden de trabajo hasta que lo dejamos listo para su entrega. Igualmente, se suele medir en días de trabajo.

Dado que el volumen de órdenes de trabajo que se procesa en un periodo de tiempo tiende a ser elevado, no se suelen manejar estos tiempos para las órdenes individuales sino su promedio para todas las órdenes tratadas en un periodo (tampoco tiene mucho sentido tratar con los tiempos individuales de órdenes concretas porque cada una tiene una complejidad propia asociada). A la hora de calcular estos promedios se debe tener cuidado con tomar periodos de tiempo demasiado amplios, pues el promedio que obtengamos puede contener sesgos de tiempos pasados. Por ello, es más recomendable manejar el concepto de media móvil (rolling average), que evita estos sesgos calculando los promedios en el entorno de la muestra inmediato al dato. 

Nota: En nuestro caso, sería en el entorno temporal inmediato. Se debe tener en cuenta que si estamos inmersos en un proceso de mejora evolutiva y continua de nuestro proceso, tal y como propone Kanban, irnos demasiado atrás en el tiempo puede falsear nuestros promedios actuales, deseablemente mejores que los de tiempos pasados. 

Igualmente, conviene recordar que, cuando se analiza la media estadística de una muestra, se debe considerar siempre la dispersión de los datos de la muestra alrededor de ese valor medio, dispersión que viene dada por la desviación típica o estándar. Este parámetro nos va a permitir determinar la predictibilidad de nuestro flujo:

 – Promedios temporales con desviaciones típicas pequeñas indican pequeñas variaciones alrededor del valor medio, es decir, es un valor muy predecible.

 – Promedios temporales con desviaciones típicas grandes implican variaciones grandes alrededor del valor medio, es decir, es un valor poco predecible.

Lead Time versus Cycle Time: Cabe decir que el Lead Time es siempre mayor o igual que el Cycle Time. Una diferencia apreciable entre uno y otro puede evidenciar ciertos problemas en nuestro flujo de entrega, aunque no tanto en el procesamiento de la orden en sí mismo, sino en las fases previas o posteriores:

– ya sea por no existir una demanda equilibrada de trabajo con respecto a la capacidad del equipo para absorberlo,es decir, llega más trabajo del que el equipo puede asumir y se tarda mucho en empezar a trabajar sobre las órdenes que entran.

– ya sea porque existe una demora en la entrega de valor por los mecanismos que estén establecidos para ello, por ejemplo, si existe una limitación temporal en la realización de las entregas.

Por otro lado, el estudio de la variabilidad en el tiempo de estas métricas nos da información sobre las tendencias existentes en el sistema

Veamos primero que nos dicen las variaciones del Lead Time:

– Un Lead Time que crece en el tiempo puede indicar que hay un crecimiento de demanda (con un equipo infradimensionado para ella) y/o una demora en la entrega (el ritmo de trabajo no es suficiente o el mecanismo de entrega está limitándola, haciendo crecer el Lead Time). 

– Por el contrario, un Lead Time decreciente en el tiempo implica lo contrario: poca demanda (o equipo sobredimensionado para ella) y/o fluidez en la entrega (ritmo rápido de trabajo y mecanismo de entrega eficiente).

Respecto a las variaciones del Cycle Time:

–  Un Cycle Time que crece en el tiempo puede deberse a varias cosas. 

      Puede indicar la existencia de cuellos de botella en el procesamiento de la orden,

      puede indicar un crecimiento en la complejidad de las órdenes de trabajo que se procesan,

      puede indicar que el equipo se encuentra desmotivado.

– Un Cycle Time que baja en el tiempo es muestra de un equipo que mejora en el tiempo, alcanzando cotas cada vez más altas de eficiencia que hacen el que el flujo de entrega sea más fluido.

– Un Cycle Time que tiene una alta variabilidad en el tiempo, alternando periodos de crecimiento y decrecimiento, indica que la complejidad de las órdenes de trabajo que se procesan es muy distinta.

Como vemos, el estudio de estas métricas y su evolución nos da una información muy valiosa sobre cómo está funcionando el flujo de entrega, ayudando a identificar posibles problemas que tendremos que intentar atajar. Puede parecer que intentar obtener esta información para nuestro flujo es una tarea costosa que implica cálculo engorrosos. Afortunadamente, para eso tenemos JIRA. En posteriores artículos, veremos cómo podemos obtener esta información de JIRA.