M365Con 2027 – conferencia online gratuita · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Value Stream Management en fabricación frente a entrega de software: mismo nombre, distinta función

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

Por ·

¿Qué es la gestión del flujo de valor (value stream management)? En una planta gestiona el flujo físico de una familia de productos; en la entrega de software, hace seguimiento de elementos de trabajo. Descubre en qué se diferencian.

Traducido automáticamente con IA a partir de la publicación original. Lee el original en inglés

¿Qué es value stream management? Depende de a quién le preguntes. En una planta, significa gestionar el flujo físico de una familia de productos desde el pedido del cliente hasta la entrega, con un responsable y unas pocas métricas compartidas. En la entrega de software, normalmente implica hacer seguimiento de los elementos de trabajo desde la idea hasta la publicación, a lo largo de un flujo de trabajo ágil y una canalización DevOps. Este artículo está pensado para responsables de excelencia operativa que se encuentran con ambos significados en los resultados de búsqueda, en charlas de proveedores o en una reunión con el departamento de TI, y que necesitan distinguirlos.

Puntos clave

  • En una planta, value stream management gestiona el flujo físico de una familia de productos desde el pedido hasta la entrega; en la entrega de software, hace seguimiento de elementos de trabajo desde la idea hasta la publicación.
  • Ambos campos comparten un origen lean: encontrar las esperas, eliminar el desperdicio y reducir el tiempo que tarda el valor en llegar al cliente.
  • Las herramientas de software usan métricas de flujo como el tiempo de flujo y la eficiencia de flujo, y las métricas DORA como el tiempo de entrega de cambios y la frecuencia de despliegue.
  • Una planta también gestiona inventario, máquinas, cambios de utillaje y transporte, que las métricas de flujo de software no cubren.
  • Cuando leas sobre value stream management, comprueba primero si la fuente se refiere a fabricación o a DevOps.

¿Qué es value stream management en cada campo?

Ambos campos usan las mismas palabras para una idea similar: gestionar el flujo completo que crea valor para el cliente, no solo pasos aislados.

En fabricación, un flujo de valor es el conjunto de acciones necesarias para llevar un producto desde el pedido hasta la entrega. El Lean Enterprise Institute (LEI) describe un flujo de valor como todas las acciones, las que crean valor y las que no, necesarias para llevar un producto desde el concepto hasta el lanzamiento o desde el pedido hasta la entrega. En una planta, el foco está en el flujo de pedido a entrega de una familia de productos. Gestionarlo implica un responsable con nombre, métricas compartidas y una revisión periódica.

En la entrega de software, un flujo de valor es el camino desde una idea hasta un software funcionando en manos de los usuarios. Planview describe el Flow Framework como "un enfoque estructurado y prescriptivo para value stream management en organizaciones de entrega de software". Planview es un proveedor de software, así que tómalo como la visión de un proveedor concreto. Los elementos de trabajo son funcionalidades, defectos, riesgos y deuda técnica, y las herramientas conectan los sistemas donde los equipos los registran.

Los nombres coinciden. El trabajo diario, no.

¿De dónde viene la idea?

La raíz es el pensamiento lean. Toyota afirma que su sistema de producción pretende eliminar a fondo el desperdicio y acortar los plazos de entrega. Toyota identifica tres tipos de problemas que hay que eliminar: muda (desperdicio), mura (irregularidad) y muri (exigencias poco razonables para las personas y las máquinas).

La definición del LEI citada más arriba ya abarca dos tipos de flujo: el flujo de valor operativo, de pedido a entrega, y el flujo de valor de desarrollo, de concepto a lanzamiento. Por tanto, la idea nunca se limitó al taller. El desarrollo de productos también es un flujo, y el desarrollo de software es un tipo de desarrollo de producto.

Por eso los dos mundos siguen hablando de las mismas cosas: esperas, traspasos, colas y silos. La diferencia está en lo que circula por el flujo.

¿Cómo gestiona una planta un flujo de valor?

Una planta gestiona un flujo físico. En la fabricación lean, los elementos típicos son:

  1. Una familia de productos. Productos que comparten pasos de proceso similares y equipos.
  2. Un mapa de flujo de valor. Un diagrama del flujo de material e información, en estado actual y futuro.
  3. Un responsable. A menudo llamado gestor del flujo de valor, con respaldo de la dirección de la planta.
  4. Métricas compartidas. Lead time, inventario, cumplimiento de entregas y first pass yield.
  5. Una revisión semanal. Acciones, responsables y fechas.

Lo que se mueve es material. Está almacenado en un almacén, espera delante de una máquina o viaja en un camión. Tiene coste y ocupa espacio, por eso el inventario es una métrica clave. Los cambios de formato, la capacidad de las máquinas y los turnos determinan el flujo. Muchas plantas también usan rutinas de gestión lean, como reuniones diarias frente al tablero, para mantener el flujo a la vista. La página de tema sobre lean management en M365.FM ofrece una visión más amplia.

¿Cómo gestiona el desarrollo de software un flujo de valor?

El desarrollo de software gestiona un flujo de información. Lo que circula es un elemento de trabajo: una idea, un ticket, un cambio de código. No tiene stock físico, pero sí espera a una revisión, a un entorno de pruebas o a una ventana de publicación.

Son habituales dos conjuntos de métricas:

  • Métricas de flujo. El Flow Framework define la velocidad del flujo, el tiempo de flujo, la eficiencia del flujo, la carga del flujo y la distribución del flujo. El resumen de Planview las plantea como preguntas: ¿se acelera la entrega de valor?, ¿se acorta el tiempo hasta obtener valor?, ¿hay trabajo esperando aguas arriba?, ¿la demanda supera la capacidad?, ¿la inversión se reparte entre valor nuevo y la protección del valor existente?
  • Métricas DORA. El programa de investigación DORA agrupa sus métricas de rendimiento en la entrega de software en rendimiento (lead time de cambios, frecuencia de despliegue, tiempo de recuperación tras un despliegue fallido) e inestabilidad (tasa de fallos en cambios, tasa de retrabajo por despliegue).

En este campo, una plataforma de gestión de flujos de valor conecta los sistemas de tickets, los repositorios de código y los pipelines de compilación para que los equipos vean cómo fluye el valor desde la idea hasta la publicación y entregan valor a los clientes antes. El resultado es un mapa de flujo de valor del proceso de entrega. Los stakeholders de negocio lo usan para ver dónde espera el trabajo y alinearse en torno al valor de negocio.

¿En qué se diferencian?

Una vista comparativa ayuda:

  • Qué fluye. Planta: material y pedidos. Software: elementos de trabajo y código.
  • Dónde espera. Planta: en colas, buffers y almacenes. Software: en backlogs, revisiones y entornos.
  • Métricas clave. Planta: lead time, inventario, cumplimiento de entregas, yield. Software: tiempo de flujo, eficiencia del flujo, lead time de cambios, frecuencia de despliegue.
  • Responsable habitual. Planta: un gestor del flujo de valor o un responsable de operaciones. Software: un product owner o platform owner, o un líder de TI.
  • Fuente de datos. Planta: ERP, MES, datos del taller. Software: sistemas de tickets y de compilación.
  • Objetivo habitual. Planta: un lead time más corto y entregas más estables. Software: publicar cambios más rápido y con más seguridad.

Lo que tienen en común es el hábito de mirar el flujo completo y preguntar dónde espera.

¿Qué significado aplica a tu búsqueda?

Usa una prueba rápida cuando leas una página o atiendas una llamada con un proveedor:

  • Si el texto habla de tickets, pipelines, releases o sprints, se refiere a desarrollo de software y DevOps.
  • Si habla de pedidos, máquinas, stock, turnos o takt (el ritmo marcado por la demanda del cliente), se refiere a fabricación.
  • Si habla de ambos, pregúntate qué datos lee la herramienta.

La abreviatura VSM añade confusión, porque puede significar mapping o management. Indica a tus compañeros qué significado usas. Los líderes de TI que trabajan con formas ágiles y DevOps suelen referirse al de software. El gestor del flujo de valor de tu planta se refiere al físico. Incluso la palabra cuello de botella cambia: en una planta es una máquina o un paso que limita la producción, y en software suele ser una revisión o una fase de pruebas. Ambos campos buscan eliminar el desperdicio y acortar el tiempo que tarda el valor en llegar al cliente, así que una buena idea de uno merece echarle un vistazo en el otro.

Ejemplo: la misma aritmética en ambos mundos

Este es un ejemplo inventado. Los números no son resultados medidos, y la métrica de abajo es una medida sencilla de planificación, no una fórmula de ningún proveedor.

Toma una medida que funcione en ambos ámbitos: la proporción del tiempo transcurrido en la que se trabaja activamente. Divide el tiempo activo entre el tiempo total transcurrido.

  • Planta. Un pedido pasa 10 días laborables en el flujo. El equipo comprueba que el producto se trabaja solo 1 día en total. La proporción es 1 entre 10, es decir, un 10 %.
  • Software. Una funcionalidad tarda 20 días naturales desde el inicio hasta la publicación. Desarrolladores y testers trabajan en ella 3 días en total. La proporción es 3 entre 20, es decir, un 15 %.

En ambos casos, la mayor parte del tiempo es espera. La solución también se parece: limitar el trabajo en curso, eliminar traspasos y publicar en lotes más pequeños. Lo que cambia es dónde buscar la espera: en una planta recorres la nave y cuentas los palés en cola; en software lees las marcas de tiempo del historial de la incidencia.

Errores comunes

  • Confundir resultados de búsqueda. Una página de un proveedor sobre gestión del flujo de valor en DevOps no le servirá a una planta.
  • Importar métricas de software a una planta. La frecuencia de despliegue no significa nada para una célula de mecanizado.
  • Importar métricas de planta al software. La rotación de inventario no se aplica a las incidencias de un backlog.
  • Ignorar las lecciones compartidas. Ambos lados pueden aprender a limitar el trabajo en curso y a acortar los ciclos de retroalimentación.
  • Comprar una herramienta antes de definir el flujo. En ambos ámbitos, primero van el responsable y las medidas.

Cómo puede ayudar el software

En una planta, las herramientas útiles gestionan datos de producción: pedidos, rutas, capacidad e inventario procedentes del ERP y del taller. Te ayudan a ver el flujo físico, no una cola de incidencias.

iFAKT es una consultora con sede en Stuttgart y especialista en software para la Industria 4.0, fundada en 2001. Ayuda a los fabricantes a planificar y optimizar sus procesos de producción y logística, y desarrolla el software Polaris. Sea cual sea el proveedor que consideres, pregunta si su modelo de datos encaja con el flujo físico.

Siguiente paso

¿Qué es para ti la gestión del flujo de valor? Si diriges una planta, es el flujo físico de una familia de productos, y los artículos sobre entrega de software son un tema secundario. Elige esta semana una familia de productos y comprueba si tiene un responsable y tres medidas compartidas.

Entidades en este artículo

iFAKT GmbH Lean management

Artículos relacionados

RSS

Patrocinado

iFAKT GmbH