Lead Time

Imagen trablero Kanban donde se refleja el tiempo de entrega interno y el tiempo de entrega real para el cliente

—Entonces, ¿para cuándo tendréis lista la campaña? —dijo el cliente.
La responsable del departamento sumó mentalmente el tiempo que lleva hacer el briefing, la sesión de brainstorming, y la ejecución.
—En unas dos semanas —respondió.
—Bueno, espero que esta vez cumpláis —añadió el cliente.

Dos semanas después la campaña de marketing no estaba lista aún, el cliente había estado llamando insistentemente los últimos días, nervioso porque sospechaba que no iban a llegar a tiempo, creyendo que por mucho insistir podría forzar el cumplimiento del plazo previsto…

El resto de la historia seguro que podemos imaginarla: prisas, cambios de prioridad, esfuerzos extra, cansancio, falta de motivación, pérdida de confianza del cliente, etc. Desafortunadamente nada que nos sea demasiado ajeno, ¿verdad?

Definición de tiempo de entrega

Estamos acostumbrados a estimar el tiempo que nos llevará hacer un trabajo complejo sumando el tiempo que nos suele llevar cada una de las actividades necesarias para completarlo. Pero generalmente no incluimos los tiempos de espera, aquellos que tienen lugar, por ejemplo, porque hacemos varios trabajos a la vez y mientras estamos con uno no atendemos al resto, o porque quien puede hacer la actividad siguiente no está disponible para seguir.

Para colmo, comprometemos los plazos de entrega obviando o despreciando esos tiempos de espera, y luego nos asombramos de que no los cumplimos por más esfuerzo que pongamos de nuestra parte.

Sin embargo, cuando en Kanban nos piden responder a la pregunta “¿Para cuándo me lo tienes?”, contestamos con el tiempo de entrega. El tiempo de entrega (en inglés, Lead Time, aunque ciertos autores prefieren Cycle Time) se define como el tiempo que pasa desde que comprometemos la realización de la petición de un cliente hasta que se la entregamos terminada conforme a sus expectativas, y es la métrica de flujo por excelencia.

El tiempo de entrega de una petición incluye, por tanto, el tiempo que activamente estamos trabajando sobre esa petición pero además los tiempos de espera en que incurrimos. Bien pudiera ser, que la realización de una petición nos haya llevado 2 horas de trabajo activo, pero la hayamos entregado en 10 días, el tiempo de entrega es 10 días, aunque sólo hayamos dedicado 2 horas.

Registrando tiempos de entrega

Registrar tiempos de entrega es sencillo, basta anotar la fecha en que comprometemos la petición o elemento de trabajo (día de inicio) y la fecha en que lo terminamos (día de fin). La diferencia entre ambas es el tiempo de entrega (en número de días). Habitualmente sumamos 1 a la diferencia si consideramos días completos, asumiendo que empezamos a primera hora del día de inicio y acabamos a última hora del día de fin.

Desde la perspectiva del movimiento de las tarjetas en el tablero kanban, el tiempo de entrega empieza a contar desde que el elemento de trabajo pasa a la columna Comprometido (Punto de Compromiso), hasta que llega a la columna Prototipo Terminado (Figura 1).

Ilustración Tablero Kanban donde se reflejan Tiempo de entrega del sistema y tiempo de entrega del cliente
Figura 1

Por supuesto, lo anterior sigue siendo válido si la finalización del elemento de trabajo lleva horas y no días, en tal caso, el registro de la fecha incluye la hora y el tiempo de entrega se medirá en horas.

Si utilizamos una herramienta Kanban electrónica (como Kanbanize, la herramienta llevará el registro por nosotros, y además lo hará no solo de las fechas-horas de inicio y fin, sino también de las fechas-horas en que el elemento de trabajo entra o sale de cada columna del tablero que representa una actividad o cola.

Mejorar los tiempos de entrega

Es claro que los clientes quieren que sus peticiones sean entregadas lo antes posible, es decir, con un tiempo de entrega corto, pero es igualmente relevante para ellos que seamos fiables, es decir, que a la hora de contestar cuándo lo tendremos listo podamos dar un rango de tiempos de entrega estrecho.

Supongamos que el proveedor A nos dice “Me llevará terminarlo entre 5 y 20 días” y el proveedor B nos dice “Lo tendrás listo entre 7 y 9 días”, ¿qué proveedor elegimos?, ¿cuál resulta más fiable? Sin duda, el proveedor B es más fiable, aunque el proveedor A pueda terminarlo antes en algún caso, la confianza en que vaya a conseguirlo es menor.

Decimos que aspiramos a gestionar nuestro flujo de trabajo para que éste sea predecible y los tiempos de entrega suficientemente cortos. Una interpretación más formal de lo anterior, en términos de la distribución de tiempos de entrega.

Por otra parte, la Ley de Little nos revela lo qué podemos hacer para reducir nuestro tiempo de entrega: reducir el número de elementos de trabajo en curso, o dicho de otro modo, reducir el WIP (Work In Progress).

Interpretando diagramas de tiempos de entrega

El registro y posterior análisis de los tiempos de entrega nos servirá para entender qué tal lo estamos haciendo, ¿estamos entregando antes?, ¿somos más predecibles?; y también para pronosticar cuándo podremos entregar los nuevos compromisos.

Una forma de empezar el análisis es representar los tiempos de entrega en un diagrama de dispersión (en inglés, scatterplot). Revisando el diagrama de dispersión podemos ver patrones y tendencias que nos pueden sugerir cambios en las políticas con las que gestionamos el flujo de trabajo. En la Figura 2, se tiene un ejemplo de diagrama de dispersión, y en él podemos observar y cuestionarnos por ejemplo lo siguiente:
La forma triangular del diagrama implica que los tiempos de entrega están aumentando, ¿se debe esto a que la tasa de llegada de peticiones es mayor que la tasa de entrega, o se debe a que estamos pagando deuda de flujo?
Los elementos de trabajo con tiempos de entrega mayores, ¿son elementos que han envejecido innecesariamente en nuestro sistema?

Cycle Time ScatterplotFigura 2

En el margen derecho del diagrama de la Figura 2, se han señalado los percentiles. Por ejemplo, el percentil 85% corresponde con un tiempo de entrega de 93 días, lo que significa que en el 85% de los casos, las peticiones se entregan en 93 días o menos. Esta conclusión ya nos permite avanzar una respuesta al cliente cuando nos pregunte para cuándo tendremos listas sus próximas peticiones.

Otro diagrama interesante es el histograma de frecuencias absolutas de tiempos de entrega (Figura 3) que nos da una idea de la forma de la distribución de los tiempos de entrega. En este tipo de diagrama podemos analizar cómo es la cola de la distribución, la dispersión de la distribución, si ésta es o no multimodal, y a partir de ahí identificar categorías de elementos de trabajo (tipos de trabajo) o razonar sobre las Clases de Servicio. Al igual que en el diagrama de dispersión, también podemos representar los percentiles sobre el histograma.

Cycle Time HistogramaFigura 3

El tiempo de entrega desde el punto de vista del cliente

La definición de tiempo de entrega dada más arriba corresponde a lo que se conoce en Kanban como Tiempo de entrega del sistema, refiriéndonos al sistema de gestión del flujo de trabajo considerado, que empieza en el punto de compromiso y termina en la primera cola sin limitación del WIP que en la Figura 1 es la columna “Prototipo Terminado».

No obstante, desde la perspectiva del cliente, el tiempo empieza a contar desde el momento en que él hace la petición y ésta empieza a prepararse (columna “Preparación”) y termina cuando ésta es entregada (columna “Entregado”), y posiblemente incluye una etapa de validación del ciente después de “Prototipo Terminado” (ver Figura 1).

A este otro tiempo de entrega se le conoce por Tiempo de entrega del Cliente (en inglés, Customer lead time).

Relación con otras métricas

La relación entre el tiempo de entrega y otras métricas de flujo, como la tasa de entrega y el WIP queda establecida en la Ley de Little [enlace a postLey de Little y sistemas Kanban] y puede verse reflejada gráficamente en los Diagramas de Flujo Acumulativo (en inglés, CFD, Cumulative Flow Diagram).

Es interesante además tener presente que la Eficiencia de Flujo (en inglés, Flow Efficiency) se define como la razón del Tiempo de trabajo activo (en inglés, Touch time) y el Tiempo de entrega. Si calculamos este cociente para cierto proceso, ponemos en evidencia las ineficiencias del flujo de trabajo que llevan necesariamente a inútiles tiempos de espera.

La eficiencia de flujo nos da una perspectiva de cómo mejorar la gestión del trabajo poniendo el foco en el cliente, algo bien distinto a lo que resulta del enfoque en la eficiencia de recursos.

 

Antonio Menchero Fernández
Accredited Kanban Trainer
Accredited Kanban Coach
www.berriprocess.com

Artículos relacionados:

Comentarios cerrados.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad