jueves, 29 de junio de 2017

Tableros kanban en dos niveles: desde pedidos de una pizzería a gestión de portafolio

Advierto que este post no va de cómo se cocinan los proyectos :-), sino de unas interesantes analogías entre la gestión de pedidos en una pizzería y un portafolio de proyectos respecto de trabajar con tableros kanban sincronizados, en este caso tableros en dos niveles, un kanban general (pedidos de pizzas o portafolio de proyectos) y otro kanban detallado (pizzas y trabajo dentro de un proyecto).

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.


Pero la pregunta clave es ¿qué ítems son los que aparecen en el kanban? ¿Representan los pedidos de pizzas o cada una de las pizzas de los pedidos?. Hay algunas columnas que delatan que el trabajo se hace a nivel de pedido (por ejemplo: Tomar "Pedido" o Entregar "Pedido") y otras en las que el trabajo se hace a nivel de pizzas (por ejemplo, Añadir Ingredientes). Claramente hay dos perspectivas del proceso, de cara al cliente es importante saber cómo va la elaboración de su pedido como un todo, y desde el punto de vista del trabajo interno de la pizzería lo que se manejan son pizzas. Entonces las alternativas de ítems a utilizar en nuestro tablero kanban serían: Pedidos, Pizzas (de un pedido) o incluso Pedidos y Pizzas (ambos tipos de ítems). Veamos las ventajas e inconvenientes de cada alternativa:

  • Í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

www.tuneupprocess.com 

1 comentario:

  1. Ofrecemos lo major software gestion stock y facturación electrónica en Argentina. Software gestion
    WynGes facturación electrónica, fiscal, servicio técnico y transporte gestión.

    Visit Now - http://wynges.com/

    ResponderEliminar