Arranquemos con el ejemplo de la pizzería donde se reciben pedidos de pizzas. Un pedido puede incluir una o más pizzas de diferente tipo y tamaño (por ejemplo, pedido del Sr. Pérez: 2 margaritas medianas y una cuatro estaciones grande). Supongamos que en el trabajo de la pizzería para atención de sus clientes se identifican las siguientes actividades: Tomar Pedido, Preparar Masa, Añadir Ingredientes, Hornear, Armar Pedido y Entregar. El siguiente tablero kanban podría servir para visualizar el estado del trabajo.
- Ítems=Pedidos: Es más sencillo conocer el estado del pedido. Es más fácil la gestión de información pues siempre habrá menos pedidos que pizzas con lo cual el tablero tendrá menos ítems. Sin embargo, físicamente todas las pizzas del pedido deberían estar en la misma actividad a la vez (en la actividad que esté su Pedido) o tener algún truco para indicar que un pedido está en más de una actividad.
- Ítems=Pizzas: Puede ser más difícil de gestionar el pedido pues las pizzas como ítems podrían estar en diferentes actividades, pero deben entregarse todas en conjunto (y calientes :-) ). Además, podemos llegar a tener muchos ítems en el tablero.
- Ítems=Pedidos y Pizzas: Podría pensarse como una solución más detallada que combina algunas ventajas de las dos anteriores y aparentemenre reduciría sus inconvenientes, pero puede ser peor esta alternativa porque hay que gestionar dos típos de ítems a la vez y conjuntamente (el ítem Pedido y sus ítems Pizzas).
Probablemente ninguna de las alternativas anteriores resultará del todo cómoda pues lo que hay detrás de esta situación es que estamos mezclando dos niveles de trabajo (Pedidos y Pizzas incluidas en los pedidos). El trabajo y la gestión de ambos debe estar coordinado pero probablemente es más sencillo y fácil de gestionar si se representan estos dos niveles como dos tableros kanban coordinados. La siguiente figura muestra un ejemplo de lo que podrían ser estos dos tableros kanban.
Como en el kanban detallado tendremos pizzas de diferentes pedidos, deberíamos contar con un mecanismo para diferenciar los ítems e identificar fácilmente cuáles son de un mismo pedido (por ejemplo, con colores o etiquetas). En cualquier caso, y ya poniéndonos en terreno, sea cual sean los tableros e ítems utilizados, las pizzas en la cadena de producción normalmente se acompañan del ticket del pedido durante todo el proceso, y son los encargados quienes van verificando el avance en conjunto de todas las pizzas del pedido.
Una vez explicada la situación de la pizzería, llevémoslo al contexto de un portafolio de proyectos. En organizaciones con un cierto grado de madurez en la gestión de sus proyectos es normal que tengan definido un flujo de trabajo para sus proyectos, que incluya estados tales como: Propuesto, En Evaluación, En Ejecución, Cerrado, etc.. Los nombres y el detalle de estado pueden obviamente ser diferentes. Sin embargo, estos estados corresponderían con las columnas del tablero kanban que ilustraría el estado de los proyectos (el estado del portafolio de proyectos), es decir, sería un equivalente a los pedidos de la pizzería. Y además, la columna "En Ejecución" estaría detallada en otro(s) tablero(s) kanban que representarían el estado de ejecución de cada uno de los ítems en los proyectos. Por ejemplo, si fuera un proyecto de desarrollo de software el tablero kanban detallado (el equivalente al de las pizzas) contendría ítems del tipo Nuevo Requisito, Mejora o Corrección de fallo, y las actividades serían del tipo Especificación, Programación, Pruebas, etc. Así, en algún momento los ítems de un proyecto se terminan y el proyecto como un todo (en el kanban de proyectos) saldría del estado "En ejecución" pasando al siguiente estado en el kanban de portafolio. Tal como en el caso de las pizzas, los ítems de cada proyecto deberían poder distinguirse o filtrarse fácilmente (para evitar tener un kanban para cada proyecto).
Patricio Letelier
