Agility at work: Actividad: Tablero kanban + concepto de WIP + Diagramas de Flujo Acumulado

El propósito de este post es describir una actividad que realizo en mis cursos para ilustrar cómo un proceso puede ser supervisado y mejorado mirándolo desde una perspectiva de flujo. Para una explicación más detallada del concepto de WIP (Work in Process) recomiendo leer Limitar el WIP, una buena idea, pero con matices y alternativas.

Un tablero kanban es la visualización de un proceso cuyas actividades son las columnas del tablero. Por defecto se asume que el flujo va de izquierda a derecha y de forma secuencial. Las excepciones a este comportamiento deberían ser establecidas como reglas del kanban pero no son visibles explícitamente en el tablero. Para conocer los desafíos asociados a la implantación de un tablero kanban leer Actividad: Lo básico de kanban y Scrum y Desafíos para la implantación efectiva de Scrum + Kanban. Para conocer algunas herramientas gratuitas que dan soporte básico a tableros kanban ver Kanban for free.

Usaré el término "unidades de trabajo" para referirme de forma genérica a los elementos de trabajo que fluyen en el tablero kanban, pasando de una columna a otra. En la práctica, una unidad de trabajo, dependiendo del contexto, podría ser un ticket de soporte al cliente, una incidencia asociada a una infraestructura, un expediente en un proceso administrativo, un cambio en un producto software, etc.

Recrearemos una cadena de producción de casas, simplificado a tres actividades; Armar Pared, Montar Puerta y Ventanas, y Armar y Montar Techo. Este ejercicio está pensado para realizarse en equipos de 5 a 8 personas. La duración estimada es de mínimo una hora y puede extenderse con tandas adicionales para mejorar el proceso mediante cambios y la correspondiente evaluación del resultado en base a los indicadores de flujo.

A continuación se describen los materiales que utilizados. Cada equipo deberá disponer de sus propios materiales.

Tablero kanban

Un tablero kanban puede hacerse con un tablero físico en una pared y usando post-it. Las columnas del tablero se corresponden con las actividades del proceso (en nuestro caso las indicadas antes), además añadiremos una primera columna denominada Pedidos Pendientes, la cual será una cola con los pedidos de casas que se vayan recibiendo, y una columna en el extremo derecho llamada Casas Terminadas, la cual acumulará los pedidos ya terminados.

Si bien para el ejercicio bastaría con un tablero kanban físico, prefiero utilizar una herramienta así me aseguro que el equipo tenga todo a mano pues el trabajo se estará desarrollando en una mesa. Recomiendo utilizar la herramienta Trello, definiendo en ella un tablero como el de la siguiente imagen:

Con post-it (cards en Trello) representaremos los pedidos de casas, los cuales se denominarán C01, C02, etc. La manipulación del tablero kanban es muy sencilla, en la columna Pedidos Pendientes se irán introduciendo nuevos pedidos, cuando un encargado de actividad se quede disponible cogerá trabajo desde la columna Pedidos Pendientes o desde alguna columna que tenga trabajo preparado para continuar el proceso. Las actividades Montar Puerta y Ventana, y la actividad Armar y Montar Techo tienen implícita una subcolumna TO DO. Así, los encargados de dichas actividades cogerán pedidos en dicha situación. La actividad Armar Pared no necesita una columna TO DO puesto que dicho papel lo desempeña la columna Pedidos Pendientes. En la mesa de trabajo cada encargado cogerá un pedido desde su izquierda y al finalizar su actividad lo dejará a su derecha (lo cual representará el TO DO para la actividad siguiente). De manera alternativa se podrían considerar columnas implícitas DONE para el trabajo finalizado en una actividad. Prefiero hacerlo con TO DO de manera que cuando calculemos el WIP, si hay una tendencia creciente en algún WIP de actividad, el posible cuello de botella esté en dicha actividad. Si lo hiciéramos con DONE el posible cuello de botella estaría en la actividad siguiente que no sería capaz de consumir desde el DONE de la actividad previa.

Gráfica de Flujo Acumulado

El tablero kanban permite visualizar en qué actividad se encuentra cada unidad de trabajo (en nuestro ejemplo pedido) y junto con esto, podemos conocer el WIP de cada actividad. Toda esta información es del instante en el cual observamos el tablero kanban. Si queremos conocer la tendencia del WIP de las actividades del tablero necesitamos coleccionar snapshots con dichos datos. La Gráfica de Flujo Acumulado (Cumulative Flow Diagram o CFD) es representación adecuada para observar dichas tendencias. Descargar la hoja de cálculo para apoyar este ejercicio. A continuación describo cada una de las partes de dicha hoja de cálculo (usando la hoja de ejemplo incluida en el fichero).

(A) Métricas de flujo. Production Rate es el promedio de unidades de trabajo terminadas en cada snapshot (los snapshots se realizarían periódicamente, por ejemplo, cada hora, día, semana, etc). En nuestro ejemplo sugiero realizar snapshots después de 30 segundos de trabajo. Cycle Time es la cantidad promedio de snapshots que se tarda en terminar una unidad de trabajo a partir del momento que se coge para entrar en la cadena de producción (en nuestro caso cuando se coge para realizarle la actividad Armar Pared). Lead Time es similar a Cycle Time pero el cálculo se hace con el snapshot en el cual la unidad de trabajo llega a estar pendiente para entrar en la línea de producción (en nuestro caso es cuando llega a la actividad Pedidos Pendientes).
(B) Cada columna S1 ... S10 corresponde a un snapshot. En las filas se contabiliza el WIP de la correspondiente actividad. Es decir, contabilizaremos en la mesa de trabajo cuántos pedidos tenemos en cada punto del proceso. Este WIP es el que será será representado en la Gráfica de Flujo Acumulado. En la hoja de cálculo automáticamente se obtiene el número de pedidos terminados en cada snapshot para con ello calcular el Production Rate.
(C) Cada columna C01,..., C30 refleja información de los snapshots en los cuales un pedido fue creado (colocado en Pedidos Pendientes), comenzado a procesar (cogido para aplicarle la actividad Montar Pared9 y terminado (puesto en Pedidos Terminados). Es decir, los número en dichas celdas corresponden al número del snapshot (S1, ..., S10) en el cual ocurrió el evento. Las filas inferiones Cycle Time x Pedido y Lead Time x Pedido calculan para cada pedido esos indicadores (los cuales son luego promediados para obtener los correspondientes indicadores globales).
(D) Gráfica de Flujo Acumulado muestra en franjas el WIP de cada actividad en cada snapshot. También se ilustra la contabilización de Pedidos Pendientes (la franja superior) y de Pedidos Terminados (franja inferior). Si se mantiene una demanda constante en tiempo y cantidad el flujo ideal correspondería a una serie de franjas apiladas en diagonal de un ancho similar (excepto la franja más baja que acumula las unidades de trabajo terminadas). Este es el caso reflejado en la gráfica mostrada en el panel D. Si la demanda está fija y establecida al comenzar un período de trabajo (por ejemplo, un Sprint de desarrollo) las franjas superiores deberían irse extinguiendo hasta quedar sólo la franja de unidades de trabajo terminadas. Si una franja (que no sea la de trabajo terminado) tiende a aumentar de grosor podría tratarse de un cuello de botella. Si una franja tiende a ponerse horizontal más que diagonal puede tratarse de una detención del flujo, es decir, puede que no se esté trabajando o no esté reflejando el paso del trabajo de una actividad a otra.

Mesa de Trabajo

Lo ideal es tener una mesa de trabajo larga para poner en ella la línea de producción con tres puntos de trabajo, más la cola de Pedidos Pendientes y de Pedidos Terminados. Es necesario contar con un ordenador para visualizar el tablero kanban y para visualizar el Gráfico de Flujo Acumulado (o si es posible, dos ordenadores, uno para cada visualización). Con post-its iremos etiquetando el trabajo, es decir, cada pedido pendiente se pondrá al principio de la línea de producción y desde allí acompañará a la casa en construcción hasta que llegue a la posición Pedidos Terminados.

Piezas de LEGO

Si bien las piezas de LEGO son bastante caras pero tengo por ellas una especial afición :-). De todas formas, el ejercicio podría ser fácilmente adaptado reemplazando las actividades de construcción con piezas de LEGO por manualidades que incluyan dibujar, recortar, pegar y pintar hasta conseguir una pequeña maqueta de casa u otro producto como resultado. A continuación se muestra la maqueta de casa propuesta para ser construida en nuestra línea de producción. Con las condiciones dadas en este ejercicio me ha bastado con disponer material para construir 8 de dichas fachadas de casa por cada equipo, además, en la medida que se vayan terminando puede desmontarse para reutilizarse en los nuevos pedidos (basta que quede en Pedidos Terminados el post-it que refleje que una determinada casa ha sido terminada).

Es importante destacar que en cada punto de trabajo la piezas deben estar completamente desensambladas de manera que en en el trabajo previo a un snapshots una persona no pueda finalizar demasiadas actividades.

Antes de comenzar

El espacio de trabajo se ilustra en la siguiente figura:

Previo a la sesión de trabajo asegurarse de que cada equipo dispondrá de al menos un ordenador, de una mesa de trabajo adecuada y de post-its. Es recomendable que antes del ejercicio los participantes conozcan lo básico de kanban y de la gráfica de Flujo Acumulado. Para esto bastaría con que leyesen los posts antes indicados.
Cada equipo debe preparar su tablero kanban (físico o en Trello).
Cada equipo descarga la hoja de cálculo para elaborar el Gráfico de Flujo Acumulado.
Cada equipo prepara unos 20 post-its etiquetándolos con C01, C02, etc.
Cada equipo pone en su mesa de trabajo, en cada punto de actividad de construcción, el material necesario totalmente desensamblado.
Dejar unos 5-10 minutos para que cada equipo practique construyendo una casa guiándose con la imagen mostrada antes. Asegurarse que cada equipo entiende el modelo y el resultado que debe obtener. Así, evitamos tener re-trabajo asociado a devolver casas defectuosas a puntos previos de la línea de producción.
Una primera configuración para poner en marcha la línea de producción se muestra en la figura annterior. Existirá un encargado de registrar el estado en el kanban y otro de registrar los datos en la hoja de cálculo. Establecer un encargado para cada una de las 3 actividades de construcción. Establecer un encargado para generar pedidos, teniendo un ritmo más o menos constante de 2 pedidos adicionales en cada snapshot. Esta persona también estará encargada de controlar el tiempo de cada snapshot, esperará a que todos estén preparados, avisará y activará el cronómetro, y luego a los 30 segundos dirá STOP, momento en el cual los encargados de actividades de producción deben detener el trabajo que estaban haciendo. Para las casas terminadas una persona tiene que encargarse de completar con el snapshot de término y que esto también se registre en la hoja de cálculo. Para no tener que disponer de demasiado material lego, una persona puede ir desensamblando las casas que lleguen a Pedidos Terminados, devolviendo las piezas a los puntos correspondientes. Otros participantes podrían ir pensando en posibles mejoras para implantar en las siguientes tandas de producción (haremos al menos 2 rondas de 10 snapshots). Es importante vigilar que las casas que se vayan construyendo siempre estén acompañadas del post-it de su correspondiente pedido. Además, entre tandas podrían irse intercambiando los encargados de las actividades de construcción con los que han quedado de observadores, ...
Hacer un ensayo. Antes de echar a andar el cronómetro poner 2 pedidos en Pedidos Pendientes. Cada vez que se pase un pedido a la actividad siguiente debe actualizarse el tablero kanban para que siempre refleje la posición de cara pedido en la mesa de trabajo. Al cumplirse 30 segundos detener el tiempo y con ello la construcción, y recopilar la información para registrarla en la hoja de cálculo. En la hoja de cálculo, en la columna del snapshot (por ejemplo en el ensayo sería S1) registrar el WIP de cada actividad (la contabilización de los pedidos en dicha actividad, incluyendo aquellos qe todavía no se procesan). Además, para cada pedido que ha entrado en la línea de producción rellenar el número del snapshot en el cual se puso en Pedidos Pendientes, si es el caso en cual snapshot se puso en Montar Pared y finalmente cuando corresponda, en qué snapshot llegó a Pedidos Terminados. Al finalizar el ensayo borrar los datos introducidos.

Puesta en marcha

Primera Ronda. Sincronizar a todos los equipos para que comiencen al mismo tiempo. utilizar la hoja de cálculo Ronda1. Deberán realizarse 10 snapshots, cada uno después de 30 segundos de trabajo. Supervisar que el registro posterior al snapshot sea rápido y que los equipos no se atasquen en dudas o discusiones para que todos los equipos terminen más o menos a la vez. Cada ronda duraría alrededor de 20 minutos.
Evaluación de la Primera Ronda. Hacer una breve puesta en común del resultado obtenido por cada equipo. Comparar primero las métricas de flujo, resaltando posibles diferencias. Comentar respecto del WIP de cada actividad. En caso de detectar ensanchamientos en alguna franja revisar si se trata de posibles cuellos de botella en el proceso. De forma similar, si alguna franja desaparece es porque la actividad tiene WIP = 0 en algún momento, lo cual podría significar que en esa actividad el encargado podría no tener trabajo. Comentar respecto de la Teoría de las Restricciones (Theory of Constraints de E.Goldratt) la cual nos dice que tenemos que tener presente las limitaciones (restricciones) del sistema, es decir, los puntos que constituyen un cuello de botella. El rendimiento de la línea de producción al completo está limitado por el punto de más bajo rendimiento (el cuello de botella). Las posibles mejoras deben concentrarse en sacar el máximo rendimiento en el punto que constituye la limitación del sistema, una vez mejorada o resuelta la limitación, los esfuerzos deben concentrarse en una nueva limitación, y así sucesivamente. Una forma de "proteger" la limitación del sistema es limitando su WIP, es decir, que no se permita tener en dicha actividad más de un determinado número de unidades de trabajo, esto obligaría por ejemplo a que, si hay actividades previas, éstas deberían bajar su ritmo o incluso llegar a detenerse, aprovechando quizás dichos recursos para mejorar el punto cuello de botella, y evitando generar inventario de trabajo no finalizado. En base a estos comentarios, que cada equipo reflexione respecto de su proceso y plantee cambios para aplicarlos en una segunda tanda. Que cada equipo decida una o dos mejoras, no más (luego si existe la posibilidad se podrían aplicar otras). Algunas mejoras típicas podrían ser: (a) Poner más de un encargado en la actividad que pueda ser cuello de botella, quizás asumiendo uno el ensamble parcial de piezas, por ejemplo, preparando trozos de pared, ensamblando ventanas o puertas en los marcos, o pre-ensamblando el techo.(b) Hacer lo anterior de forma dinámica, es decir, cuando una actividad acumule tenga un bajo rendimiento, apoyar ese punto con más gente, incluso dejando detenidas otras actividades previas. (c) Reorganizar a los encargados de las actividades para que en cada puesto esté quien mejor lo hace, es decir, favorecer la especialización. (d) Crear actividades, pero no lo recomiendo pues implicaría modificar el kanban y la hoja de cálculo, y esto puede hacer retrasar el trabajo del equipo en el ejercicio. (e) Otras ...
Segunda Ronda y su Evaluación. Preparar el tablero kanban para empezar de nuevo. Utilizar la hoja de cálculo Ronda2. Repetir 10 snapshots. hacer una nueva puesta en común de los resultados de cada equipo. En la hoja Ronda2 se calculan los porcentajes de mejora respecto de la hoja Ronda1. Evaluar las mejoras aplicadas según los cambios en los valores de las métricas ¿ha mejorado (aumentado) el Production Rate? ¿ha mejorado (disminuido) el Cycle Time? ¿ha mejorado (disminuido) el Lead Time?. En caso de empeorar, habría que cuestionar la utilidad de las supuestas mejoras introducidas pues en caso de hacer una nueva ronda podrían descartarse.
Otras rondas. Si hay tiempo y ganas puede hacerse una tanda más.

Comentarios Finales

Es importante reservar unos 10 minutos finales para comentar y hacer extrapolaciones al contexto de trabajo que interese. Algunas ideas para discutir.

Establecer las analogías con producción de software. Los post-it son unidades de trabajo, los snapshots son días de trabajo, las rondas son sprints, las actividades en el contexto software serían por ejemplo: especificar requisitos, diseñar y estimar, programar, testear, etc. No hemos hecho énfasis en la calidad, pero aplicaría en cualquier contexto, es decir, habría ciertas actividades durante y al final del proceso para asegurar la calidad.
Establecer las NO analogías con producción de software. La más importante es que en desarrollo y mantenimiento de software el tamaño y/o complejidad (y por consecuencia el esfuerzo) asociados a una unidad de trabajo es diverso, cada unidad de trabajo de software tiene un esfuerzo asociado diferente pues no se generan productos iguales ni independiente, sino que corresponden a componentes de un mismo producto software, que deben además irse integrando y probando para asegurar que se mantenga el comportamiento de componentes antes integrados. Por esto es que las métricas de flujo no son directamente aplicables pues pueden carecer de sentido si las unidades de trabajo son muy diversas. Asociado a lo anterior, aunque en la actividad realizada se puede enfatizar la competencia entre los equipos para motivarlos, si se tratara de equipos de desarrollo de software no tendría sentido hacer comparaciones basándose en las métricas de flujo. Finalmente, si bien es importante promover la mejora de la productividad, un proceso de mejora continua también puede y debe considerar otros aspectos mejorables tales como calidad, costos, clima laboral, motivación y compromiso de los participantes, etc.
Nuestro proceso ha sido estrictamente secuencial. Esto puede no ser así en el contexto que nos interese aplicar estos conceptos. Es normal que sea conveniente paralelizar actividades.
No hemos considerado re-trabajo, en contextos como el desarrollo o mantenimiento de software el re-trabajo es habitual. Por ejemplo, se presenta re-trabajo cuando en la actividad de Testeo se detecta un fallo y la unidad de trabajo se devuelve a la actividad de Programación, o incluso puede devolverse más atrás en el workflow cuando se trata de defectos de Requisitos. Podría haberse establecido una actividad adicional al final de la línea de producción que fuese algo así como "Control de Calidad", en la cual se aplicaran pruebas al producto resultante.
Limitar el WIP puede ser efectivo en ciertos casos, sin embargo, lo que considero más importante y siempre útil para descubrir deficiencias en el proceso, es el realizar una supervisión constante del WIP, detectando oportunamente posibles cuellos de botella, y tomando decisiones sobre la marcha para resolver dicha situación.
Hemos trabajado (al menos en la primera ronda) con pre-asignación de responsables en cada actividad, y es más, con roles fijos (cada uno realiza sólo una actividad). El concepto Self-organizing Team promueve que todos los miembros de un equipo estén dispuestos a realizar cualquier actividad (aunque cada uno pueda tener más protagonismo o especialización en ciertas actividades). La idea sería que todos los participantes en la línea de producción no estén fijos en un puesto de la línea y que vayan cogiendo trabajo de diferentes actividades, de forma que por encima de todo se privilegie la terminación de pedidos. Esto podría plantearse como una mejora en una de las tandas posteriores a la primera, aunque quizás el tiempo del ejercicio y sus pocas actividades no dan mucho juego para visualizar estas ventajas.
Esa interesante destacar que al arrancar cada ronda los puntos hacia el final de la línea de producción están "ociosos" pues aún no les llega trabajo. Esta situación podría invertirse al final de cada ronda si trabajáramos con una cantidad fija de pedidos, y si estos se agotaran ya empezarían a quedar "ociosos" los encargados de las primeras actividades de la línea de producción. Este fenómeno es usual cuando se trabaja con Sprints, al arrancar cada Sprint y al acercarse al su término. Esto puede generar que puntualmente algunos encargados queden "ociosos" respecto del trabajo del Sprint, con lo podrían echar una mano a otros compañeros o podrían preparar trabajo para el siguiente Sprint.
Con este ejercicio queda en evidencia el importante esfuerzo requerido para aplicar estos conceptos en un contexto real. La aplicación eficiente y efectiva sólo se consigue con un apoyo automatizado para la recolección de los datos necesarios, para su representación en la Gráfica de Flujo Acumulado, y para el cálculo de las métricas asociadas al flujo. Además, no es sostenible el registrar información en el tablero kanban y a la vez en la Gráfica de Flujo Acumulado. En nuestra metodología y herramienta TUNE-UP Process hemos abordado y resuelto estos desafíos.