El documento describe el mapeo de flujo de valor, un proceso para mapear los pasos en el trabajo que produce un producto o servicio. Explica los seis pasos para crear un mapa de flujo de valor: 1) identificar las acciones, 2) especificar los tiempos, 3) especificar el tiempo de trabajo vs espera, 4) especificar tiempos entre pasos, 5) identificar ciclos, y 6) calcular la eficiencia. A modo de ejemplo, aplica estos pasos para mapear un proceso hipotético y calcular una eficiencia del 14.9

1. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Mapeo de flujo de valor
Por Alan Shalloway
El Mapeo de flujo de valor (VSM, por las siglas en inglés de Value Stream Mapping) es una
actividad que cataloga los pasos en el trabajo que produce un producto o entrega un
servicio. Revela dónde están las interfaces entre las actividades, así como los tiempos
involucrados en y entre los pasos del proceso.
Entendiendo el flujo de valor
Un flujo de valor1
es esencialmente todo el trabajo que se lleva a cabo desde el inicio de
una idea hasta que el cliente la ha creado y consumido. Para el desarrollo de software, este
es ilustrado en la figura 1.
1
El conjunto de acciones que tienen lugar para agregar valor a un cliente desde la solicitud inicial hasta la
entrega. El flujo de valor comienza con el concepto inicial, se mueve a través de varias etapas para uno o más
equipos de desarrollo (donde comienzan los métodos Agile), y hasta la entrega final y el soporte. El mapeo del
flujo de valor permite visibilizar el cómo sucede el flujo del valor.

2. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Figura 1 Diagrama conceptual de un flujo de valor.
Este diagrama ilustra el alcance del desarrollo de software y cuánto de este suele omitirse en
los métodos ágiles. Al observar el diagrama, podemos ver que comienza con el inicio de una
idea que ayudará al cliente. Puede ser que el cliente no entienda la idea, pero el valor deseado
está enfocado en él. En algún momento, el negocio discute esto y decide sobre un conjunto
de funcionalidades que se construirán. El equipo de desarrollo toma el proyecto, lo construye
y lo entrega al cliente para que lo consuma. El rol de la gerencia, que se ignora con demasiada
frecuencia en el espacio Agile, tiene el importante papel de garantizar que el trabajo que se
lleva a cabo en el flujo de valor no se vea obstaculizado.
Es interesante ver dónde se enfocan los populares métodos Lean-Agile en la corriente de
valor. XP2
se ocupa principalmente del equipo de desarrollo y del cliente. XP no tiene la
intención de proporcionar información sobre cómo se inician los proyectos. Más bien, XP se
2
Extreme Programming (XP) fue la primera metodología ágil de desarrollo de software que alcanzó relevancia
en la industria. Pueden saber más en http://wiki.c2.com/?ExtremeProgramming (N.d.T.)

3. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
trata de construirlos después de que se haya decidido que deben ser construidos. Scrum3
es
un poco diferente de esto. Una vez que se inicia un proyecto, Scrum se enfoca en el equipo
de desarrollo con solo un foco tangencial en las consideraciones del impacto en el
negocio. Este impacto sólo ocurrirá si el equipo se encuentra con impedimentos causado por
el lado comercial.
Kanban4
se ha enfocado principalmente desde la fase de desarrollo hasta la fase de
despliegue5
. Sin embargo, debido a que Kanban hace visible sus métodos al negocio, y
porque impone un tamaño acotado en la cola de entrada, puede llegar a tener mayor
influencia en el negocio de la que Scrum logra usualmente. De hecho, fue viendo este
fenómeno (los gerentes de productos cambiando sus hábitos de interrupción de los equipos
debido a la visibilidad que los equipos dieron a los gerentes de productos) lo que aceleró mi
interés en Kanban.
Lean, por supuesto, cubre todo el mapa de flujo de valor. El aspecto clave de un mapa de
flujo de valor es que crea visibilidad en el trabajo que se está realizando. Si bien algunas
personas discuten sobre la efectividad de usar métricas para guiar la toma de decisiones, creo
que no hay oposición posible a la idea de que no es posible gestionar lo que no se puede
ver. Los mapas de flujo de valor existen ante todo para hacer visible nuestro trabajo.
Creación de un mapa de flujo de valor
Antes de comenzar un mapa de flujo de valor , es importante recordar que es un mapa sobre
cómo se está trabajando en una petición en particular. No estamos mapeando la cantidad de
tiempo que las personas están trabajando en diferentes peticiones.
3
https://www.scrum.org/resources/what-is-scrum (N.d.T.)
4
https://leankanban.com/project/wkanban/ (N.d.T.)
5
Desde que se escribió este artículo, la comunidad Kanban ha propuesto formas explícitas de gestionar “aguas
arriba” de la fase de construcción, abarcando y modelando el proceso de decisión y descarte previo a la decisión
de construir. Ver https://leankanban.com/upstream/

4. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
No hay una única forma de crear un mapa de flujo de valor. Pero habiendo liderado a cientos
de personas en la creación de mapas de flujo de valor, he visto que este proceso de seis
pasos funciona bastante bien. Estos son:
1. Identificar las acciones que tienen lugar.
2. Especificar el tiempo calendario en el que se trabajan estas acciones.
3. Especifique cuanto tiempo dedicado a esas acciones se ocupó en trabajo real y cuánto
tiempo se pasó esperando.
4. Especificar la cantidad de tiempo entre estos pasos
5. Mire, y marcar, cualquier ciclo presente en el flujo de trabajo
6. Totalizar el tiempo promedio de trabajo en la petición.
La mejor manera de entender esto es, por supuesto, con un ejemplo, así que veamos uno.
Paso 1: Identificar las acciones que tienen lugar.
Imaginemos que tenemos un proceso en el que las acciones que tienen lugar pasan por estas
actividades:
[Petición] → [Aprobación] → [Requisitos] → [Compromiso] → [Análisis] → [Diseño]
→ [Revisar] → [Construcción] → [Prueba] → [Entrega].
Este es sólo un ejemplo, no estoy sugiriendo que este sea un buen flujo de trabajo. Sólo
estamos mapeando el flujo, no estamos evaluando si es bueno o no.
Podemos anotar las seis actividades en cuadros para representar el flujo como se muestra en
la Figura 2.

5. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Figura 2: Paso 1: identifique las acciones tomadas en el flujo de valor
Nota: cuando asigna un flujo de valor real, sugiero usar notas adhesivas en una pizarra
blanca. De esa manera puedes mover las actividades de forma muy sencilla.
Paso 2: Especifique el tiempo real de inicio a fin de la
actividad del flujo.
Después de escribir las actividades del flujo, debe considerarse cuánto tiempo toma cada una
de ellas. En otras palabras, desde el inicio de la petición hasta su finalización, ¿cuántos días
tarda? No es obligatorio para usar horas para medir los tiempos en un mapa de flujo de valor,
pero es mucho más fácil si las usa consistentemente. Recomiendo usar 8 horas por día y 40
horas a la semana. Hace que las conversiones entre días y semanas sean bastante sencillas. Si
cambias las unidades de medida, es decir, a veces usa horas y otras veces días, estarás
propenso a cometer errores de conversión. La Figura 3 muestra el mapa de flujo de valor
después medir las horas que ha tomado cada actividad del flujo.

6. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Figura 3: Paso 2: especifique el tiempo real de inicio a fin de la acción
Paso 3: Especificar cuánto del tiempo total se
estuvorealmentetrabajando en esto
Ahora viene la parte delicada. Lean sugiere que investiguemos las demoras que pueden estar
sucediendo en nuestro flujo de trabajo. A veces es difícil ver estos retrasos porque todo el
mundo está ocupado trabajando. Por ejemplo, si alguien está trabajando en dos peticiones al
mismo tiempo, en cierto sentido, cuando está trabajando en uno, está retrasando el otro. Es
más fácil medir cuando consideramos a una sola persona trabajando, así que tomemos ese
caso primero. Si una persona trabaja 60 horas de las 160 horas en la actividad [Requisitos],
pondremos 60/100 para indicar 60 horas de trabajo en este proyecto y 100 horas sin trabajar
en este proyecto durante este paso.
¿Qué pasaría si tuviéramos 2 personas trabajando en [Requisitos]?. Digamos que uno trabajó
50 horas y otro trabajó 70 horas. Lo que queremos es comparar el tiempo de trabajo
activamente trabajado en relación con el no trabajado. La primera persona trabajó en otra
cosa durante 110 horas, mientras que la segunda persona trabajó en otra cosa durante 90
horas. Podríamos escribir 120 200 para indicar los totales, pero esto no tendría sentido
cuando tratáramos de comparar eso con las 120 horas del calendario. Lo que queremos saber
durante este paso es cuánto tiempo trabajó alguien en este proyecto y cuánto tiempo hizo otra

7. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
cosa. Ese sería el promedio de estos números. Por lo tanto, escribiríamos 60:100 como se
muestra en la Figura 4.
Figura 4: Paso 3: especifique cuánto del tiempo total se gastó trabajando realmente en la actividad
Paso 4: Especificar el tiempo entre las actividades
Figura 5: Paso 4: especifique el tiempo entre las actividades. El resto es ahora bastante
sencillo. Una acción no comienza inmediatamente después de que finaliza la acción
anterior. Necesitamos grabar eso también. Se muestra en la Figura 5.
Figura 5: Especificar las demoras entre las actividades

8. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Paso 5: Identificar todos los ciclos de vuelta atrás
requeridos
El último paso de mapeo es buscar los ciclos de vuelta atrás y la frecuencia con la que
ocurren. Esto se muestra en la Figura 5.
Figura 6: Paso 5: Identifique cualquier bucle requerido
Paso 6a: Calcule la eficiencia del tiempo del ciclo (tiempo
del calendario)
Finalmente , tenemos que calcular la eficiencia de flujo del proceso. Esta será la relación
entre cuánto tiempo se trabajó en contraste con la cantidad de tiempo total utilizado. Este
último es el tiempo calendario medido de principio a fin, y se puede calcular
sumando todos los cuadros y los tiempos entre los cuadros, incluidos los ciclos de vuelta
atrás. Si este valor no coincide con el tiempo calendario que tomó, entonces la medida de
tiempos en el mapa está desajustada.
El tiempo real (tiempo de calendario) del proyecto debería ser simplemente la suma de los
tiempos en los que trabajamos más los tiempos entre los pasos, incluidos los tiempos de los
bucles. Mostramos esto con los tiempos sombreados en la Figura 7.

9. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Figura 7: Paso 6a: calcule el tiempo del calendario del proyecto
El tiempo trabajado sin los bucles de vuelta sería:
0,5 + 320 + 8 + 80 + 160 + 320 + 8 + 80 + 100 + 80 + 120 + 160 + 2 + 80 + 280 + 80 + 240 + 80 + 8 = 2206,5
Los tiempos de vuelta atrás del se calcularían como:
1x 20%*(120+160+2) y 3x65%*(280+80+240) = 56,4+1170.
Sumando estos tres números, obtendremos 3433.
Paso 6b: Calcular la eficiencia de flujo (tiempo trabajado)
La Figura 8 nos muestra qué números usar para el tiempo realmente trabajado . Tener en
cuenta que estamos incluyendo el tiempo trabajado durante los ciclos. Técnicamente, Lean
diría que no se incluyan estos tiempos, ya que representan un re-trabajo, pero nuestro punto
se explicará simplemente al analizar el tiempo trabajado en contraste con el tiempo total. No
es necesito argumentar sobre si el trabajo es valioso o no.

10. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Figura 8: Paso 6b: calcule la hora en que se trabajó en el proyecto
Haciendo esto por el tiempo trabajado nos pone:
.5 + .1 + 60 + 1 + 40 + 40 + 2 + 80 + 40 + 3 = 266,6
y
1x 20% * (40 + 2) y 3x .65 * (80 + 40) para 8,4 y 234.
Suma estos juntos y obtienes 509 horas.
La eficiencia del flujo del proceso es, por lo tanto, de 509 horas / 3433 o 14.9%.
Esto no significa que las personas sólo trabajen 1 de 7 horas. Significa más bien que están
trabajando aproximadamente 1 de cada 7 horas en esta petición.
¿Es este un número normal? Eso depende un poco de tu proceso. Cuando comencé a hacer
mapeo de flujo de valor hace aproximadamente 7 años, la mayoría de las compañías con las
que trabajé no hacían ningún tipo de método ágil. En estos casos, entre el 5 y el 20% fueron
comunes. Los proyectos de mantenimiento con ciclos de lanzamiento de 6 meses podrían ser
tan bajos como 0,1% (2 horas de trabajo esperando un tiempo de lanzamiento de 1000 horas
sería de 0,2%). Cuando los equipos aplican algún tipo de método ágil, este porcentaje
aumenta entre 50 y 70%. Esto se debe principalmente a las personas que trabajan en un
proyecto a la vez con un nivel menor de interrupciones.

11. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Donde gastamos nuestro tiempo
El flujo de valor nos muestra que pasamos la mayor parte del tiempo esperando a alguien o
algo más. Esto no debería ser ninguna sorpresa. Imagina cuántas veces envías un correo
electrónico y luego te vas y haces otra cosa hasta que recibas una respuesta. La mayor parte
de nuestro tiempo en equipos no compartidos se pasa esperando para obtener información de
otro lugar. Si su organización está separada en silos, es probable que las personas trabajen en
múltiples proyectos. Cuando uno considera cómo los retrasos literalmente generan
desperdicio6
, toda esta demora puede estar causando más trabajo adicional de lo que
pensamos.
Consideremos las siguientes preguntas. Digamos que este proceso que acabamos de mapear
había sido organizado para una funcionalidad muy importante. Imagínese yendo al sponsor
de negocio que lo estaba promoviendo y les preguntó si estarían dispuestos a aumentar el
costo del proyecto en un 20% si pudieran reducir el tiempo de 1,75 años (las 3433 horas) a
un año (aproximadamente 2000 horas). . Cuando pregunto esto, la mayoría de la
gente dice "si, seguro ". El tiempo de entrega anterior vale más que un aumento del 20% en
el costo si el proyecto es importante.
Pero ahora déjame hacerte otra pregunta. ¿Qué pasaría si el tiempo del proyecto se redujera
desde 2 años a 1 año? Claramente, la única forma de hacerlo sería eliminar los retrasos entre
los pasos y reducir la cantidad de trabajo que distrae mientras se trabaja en este
proyecto. Pero si disminuimos las demoras, ¿cómo afectará eso nuestro trabajo por hacer?
Tengamos en cuenta que los retrasos se crean en la retroalimentación, el flujo de trabajo y el
uso de la información crea un trabajo adicional. Así que eliminar los retrasos debería
permitirnos hacer el proyecto en menos tiempo. En cualquier caso, ciertamente no debería
subir.
6
Ver https://www.netobjectives.biz/files/collaboration%26planning/Why-Looking-at-Time-Is-So-
Important.pdf

12. Versión original https://portal.netobjectives.com/articles-public/value-stream-mapping/
Traducción de Agustín Villena
Esta es la "magia" del flujo Lean. Al centrarnos en el valor más importante que se creará,
mejoramos el tiempo de comercialización y lo hacemos con menos trabajo.
¿Qué nos entrega un mejor retorno?
El análisis del flujo de valor nos enfoca en la eliminación de los retrasos en nuestro flujo de
trabajo en vez de mejorar cada uno de los pasos. Por supuesto, esto no significa ignorar la
mejora de estos últimos. Irónicamente, cuando empezamos a analizar los retrasos, muchos
métodos nuevos (ATDD, TDD, patrones de diseño) que se aplican al interior de pasos del
desarrollo ágil, demuestran ser una buena manera de eliminar estos retrasos.