Get best of the week

Método Kanban: Entendiendo su proceso como un proceso de construcción de conocimiento colectivo - Parte 1 (recetas)

Con esta publicación, vuelvo al tema de la visualización de procesos en servicios profesionales. Como escribí anteriormente, podemos interpretar procesos tales como la acumulación conjunta y el enriquecimiento del conocimiento , y di algunos ejemplos. Su parte clave es el énfasis en la acumulación de conocimiento y la obtención de información a través de una secuencia de actividades conjuntas, en lugar de centros de producción, pasos de proceso y delegación.

Ahora pasemos al problema asociado con esto: cómo comenzar con procesos de la vida real y crear la reflexión correcta en el sistema de gestión visual. Para los equipos y organizaciones que usan el sistema Kanban, dicha visualización representa una parte importante de su sistema. Para aquellos que desarrollan sus servicios utilizando el método Kanban, esta es una parte esencial de la práctica de visualización, que es una de las prácticas del método.

En pocas palabras, el diagrama de acumulación de conocimiento / información presentado de esta manera,


podemos imaginar una tabla Kanban así:



El método de mapeo de procesos tiene tres aspectos importantes:

  1. Qué hacer, de hecho, y cómo: una receta específica.
  2. Observaciones hechas trabajando realmente con grupos de personas: los pros, los contras, las sorpresas y las trampas: solo lo descubriremos en la práctica.
  3. La razón para hacer o no hacer algo de una manera específica es lo que necesitamos entender para ser más como chefs, no como chefs.

Antes de continuar, vale la pena señalar aquí que ya nos hemos alejado de la noción de que un proceso es una secuencia de pasos prescrita. Faltan diagramas de flujo creados en Visio y almacenados en SharePoint. Un proceso es lo que sucede en la vida real, y ocurre principalmente a través de la miríada de decisiones tomadas (en su mayoría irracionales) por personas que son de naturaleza imperfecta. Lo que sucede es la norma que queremos mejorar.

Cosas simples: qué hacer y cómo


Para comenzar a reflejar nuestro proceso, necesitamos información:

  • : , , ;
  • , ( ), ;
  • .

Es muy importante utilizar ejemplos reales de elementos de trabajo . Sin ellos, las personas solo discutirán su visión del proceso ideal, se referirán a la documentación existente sobre el proceso o discutirán cómo debería ocurrir este proceso. Usando ejemplos, podemos rastrear lo que realmente está sucediendo: diversas actividades y decisiones tomadas en el proceso de estas actividades. Por lo general, de tres a seis ejemplos son suficientes para cada tipo de elemento de trabajo. Debe haber personas que trabajaron directamente en estos elementos de trabajo. No confíe en la visión de un gerente, líder de equipo o entrenador de procesos.


Los elementos de trabajo deben estar alineados en el lado derecho de un tablero grande y vacío. En este caso, tenemos diez elementos recientemente establecidos de cuatro tipos.

Luego, cada persona en la sala toma una pila de calcomanías, registra las actividades en las que participó o las decisiones que toma que conducen a la entrega de cada uno de estos elementos de trabajo, y coloca su calcomanía en una pizarra blanca. Se debe prestar la atención principal a qué conocimiento o información se obtuvo como resultado de cada actividad, y no al hecho de los procedimientos y las reuniones. El facilitador pide a los participantes que peguen una pegatina a la vez y que los organicen en orden cronológico. Queremos hacer un seguimiento de lo que realmente sucedió durante el proceso de entrega.

Resulta que esta actividad es compleja y social.. Las personas no recuerdan mucho de lo que hicieron, pero tienden a estimular los recuerdos de los demás. Por ejemplo, un desarrollador de software puede escribir una etiqueta que indique que escribió el código para la función suministrada. El probador puede recordar que realmente probaron una función inacabada, encontraron errores en ella y proporcionaron un informe al desarrollador. Luego, el desarrollador puede recordar que esta función estaba realmente incompleta, que consultaron con su colega y planearon agregar varias pruebas automáticas para evitar la ocurrencia de tales errores y, en consecuencia, fue necesario implementar el plan. Es gracias a este complejo juego conjunto que se visualiza la actividad dominante del proceso existente, los puntos de inflexión, los patrones de interacción y emergen reglas explícitas.


Con el tiempo, el grupo comenzará a notar las similitudes entre ellos (por supuesto, dentro del mismo tipo de elemento de trabajo). El anfitrión debe aclarar con los participantes el orden de construir calcomanías con actividades similares. A veces, el orden se vuelve obvio lo suficientemente rápido, por lo que no es necesario anotar cada paso por separado para cada elemento de trabajo en la etiqueta. Los principales tipos de actividad dominantes pueden determinarse luego organizándolos en la línea de tiempo y agrupando las etiquetas según corresponda. Como recordatorio ( esto se describió en detalle en una publicación anterior ), uno de los principales tipos de actividad domina la acumulación de conocimiento por un tiempo, pero finalmente se desvanece y es reemplazado por un nuevo tipo dominante de actividad.


En este ejemplo, el grupo recreó la línea de tiempo para seis entregas de un tipo específico de elemento de trabajo e identificó cinco actividades dominantes.

Política explícita


Los resultados de este taller se pueden transferir fácilmente a la nueva placa Kanban. Cada actividad dominante identificada estará representada por una columna. El grupo debe decidir cómo nombrar cada actividad: estos nombres se convierten en los encabezados de las columnas en el tablero físico. Dado que hay varios tipos de elementos de trabajo y cada uno de ellos puede tener diferentes conjuntos de actividades dominantes, el tablero Kanban generalmente tendrá varias pistas, cada una de las cuales tiene un conjunto de columnas ligeramente diferente para mostrar diferencias en el proceso.

Este taller también ayuda a identificar reglas implícitas pero implícitas. Recuerde que una de las prácticas clave del método Kanban es hacer explícitas las reglas. Puede incluir:

  •  criterios de preparación (Definición de Listo);
  •  criterios de finalización (Definición de Hecho);
  • reglas para ordenar o seleccionar elementos para ejecutar (algunos llaman a esto priorización);
  • reposición y suministro de cadencia;
  • etc.

Todo esto puede detectarse y repararse en una nueva placa.

Un taller suele durar dos horas y media . En mi experiencia, es mejor no apresurarse, explicar bien, mantener la discusión con buenas preguntas y dar a las personas suficiente tiempo para comprender los pensamientos de los demás y comprender su proceso de trabajo. Solo en casos simples lo terminamos en menos de dos horas, y nunca hubo un caso cuando tomó más de tres horas. Creo que la complejidad del proceso se ve compensada por la cantidad limitada de atención y el grado en que las personas necesitan sumergirse en los detalles.

More articles:


All Articles