Flujo de valor: ¿dónde se atora tu operación?

Cuando una organización detecta que sus entregas se retrasan, que los proyectos exceden los plazos o que los clientes esperan demasiado, la reacción más común es intervenir en el área que parece más lenta. Se contrata más personal para el equipo que “no da abasto,” se implementan herramientas de productividad, se establecen metas más agresivas. Y el problema persiste — o se desplaza a otro punto del proceso — porque la intervención se hizo sobre el síntoma visible, no sobre la restricción real del sistema.

Goldratt (1984), en “The Goal,” formalizó un principio que debería ser fundacional en cualquier conversación sobre eficiencia operativa: el rendimiento de un sistema está determinado por su restricción — el punto más estrecho del flujo. Mejorar cualquier otro punto del sistema que no sea la restricción no mejora el rendimiento del sistema; solo acumula inventario antes de la restricción o deja capacidad ociosa después de ella. Esta idea, que tiene más de cuatro décadas, sigue siendo contraintuitiva para organizaciones que gestionan por áreas funcionales en lugar de gestionar por flujo de valor.

Un flujo de valor es la secuencia completa de actividades necesarias para entregar un resultado a un cliente — desde la solicitud inicial hasta la entrega final. En una empresa de seguros, el flujo de valor de emisión de pólizas incluye la recepción de la solicitud, la evaluación de riesgo, la cotización, la aprobación, la emisión del documento y la entrega al cliente. Cada paso es responsabilidad de un área funcional diferente — ventas, suscripción, operaciones, tecnología — y cada área optimiza su propio paso sin visibilidad del flujo completo. El resultado es que cada área puede reportar “eficiencia” en su segmento mientras el tiempo total de emisión excede lo que el cliente considera aceptable. Womack y Jones (1996), en “Lean Thinking,” llamaron a esto el problema de la optimización local que degrada el rendimiento global.

La primera herramienta para hacer visible este problema es el mapeo de flujo de valor (Value Stream Mapping, VSM), una técnica que documenta el flujo real — no el diseñado — de un proceso end-to-end, incluyendo tiempos de procesamiento, tiempos de espera, transferencias entre áreas y puntos de decisión. El hallazgo más consistente cuando se aplica VSM en organizaciones de servicios es que el tiempo de espera — el tiempo que el trabajo pasa sin ser procesado, en colas, esperando aprobaciones o esperando información — representa entre el 70% y el 90% del tiempo total del flujo. Reinertsen (2009), en “The Principles of Product Development Flow,” documentó que en entornos de trabajo de conocimiento, las colas invisibles son la fuente dominante de retraso, y que la mayoría de las organizaciones ni siquiera las miden.

Esto tiene una implicación directa para las intervenciones de mejora: si el 80% del tiempo total es espera y el 20% es procesamiento, mejorar la velocidad de procesamiento en un 50% reduce el tiempo total en un 10%. Pero reducir el tiempo de espera en un 25% reduce el tiempo total en un 20%. Las organizaciones invierten consistentemente en automatizar y acelerar el procesamiento — que es visible, medible y técnicamente satisfactorio — mientras ignoran las colas y esperas — que son invisibles, difíciles de medir y políticamente incómodas porque frecuentemente apuntan a problemas de coordinación entre áreas.

Las colas en trabajo de conocimiento son particularmente insidiosas porque son invisibles. En una fábrica, el inventario en proceso es físicamente visible — cajas acumuladas entre estaciones de trabajo. En una organización de servicios, el “inventario” son solicitudes, aprobaciones pendientes, emails sin responder, tickets en espera, y documentos en colas de revisión. Este inventario no ocupa espacio físico pero consume algo más valioso: capacidad cognitiva y tiempo de ciclo. Little (1961) formalizó la relación entre estas variables: el tiempo promedio que un ítem pasa en un sistema es proporcional al número de ítems en el sistema dividido por la tasa de procesamiento. Reducir la cantidad de trabajo en proceso (WIP) reduce directamente el tiempo de ciclo, incluso sin mejorar la velocidad de procesamiento.

La gestión del WIP es uno de los principios más poderosos y menos implementados en organizaciones de servicios. Anderson (2010), al desarrollar el método Kanban para trabajo de conocimiento, propuso que hacer visible el trabajo en proceso y limitar la cantidad de trabajo simultáneo es la intervención de mayor impacto que una organización puede hacer sobre su flujo. La razón es contraintuitiva: las organizaciones asumen que tener más trabajo en proceso significa producir más. En la práctica, tener más trabajo en proceso significa que cada ítem individual avanza más lento porque compite por los mismos recursos — atención de personas, capacidad de revisión, disponibilidad de aprobadores.

La metáfora más precisa es la de una autopista: cuando el tráfico es bajo, cada vehículo viaja a velocidad máxima. A medida que se agregan más vehículos (más WIP), la velocidad promedio disminuye. Pasado cierto punto — el punto de congestión — agregar más vehículos no solo no aumenta el throughput sino que lo reduce. Las organizaciones que lanzan 30 proyectos simultáneos con capacidad para ejecutar 10 están operando en congestión permanente, y la respuesta habitual — presionar más, exigir más horas, contratar más personas — no resuelve el problema si la restricción no es la capacidad individual sino la cantidad de trabajo compitiendo por recursos compartidos.

La identificación de la restricción real del sistema requiere datos que la mayoría de las organizaciones no recolectan. Las métricas de flujo fundamentales — lead time (tiempo total desde solicitud hasta entrega), cycle time (tiempo de procesamiento activo), throughput (cantidad de ítems completados por unidad de tiempo), y WIP (trabajo en proceso) — son rara vez medidas fuera de contextos de manufactura o desarrollo de software. En organizaciones de servicios, la métrica dominante es el cumplimiento del cronograma (¿entregamos en la fecha prometida?) que es una medida de salida pero no dice nada sobre por qué el flujo se comporta como se comporta. Es como medir la temperatura del paciente sin buscar la causa de la fiebre.

Cuando se miden las métricas de flujo, los patrones que emergen son consistentes. En organizaciones que operan sin gestión explícita del flujo, el lead time tiene alta variabilidad — un mismo tipo de solicitud puede tardar 3 días o 30 dependiendo de quién la procese, qué más esté en la cola, y si la persona que debe aprobar está disponible. Esta variabilidad es destructiva porque hace impredecible el servicio al cliente y porque las organizaciones responden a la impredecibilidad agregando buffers de tiempo — promesas de entrega infladas que reducen la competitividad.

Los cuellos de botella en organizaciones de servicios se concentran en tres puntos recurrentes. El primero es la aprobación jerárquica: procesos que requieren firmas o visto bueno de personas que tienen más solicitudes de aprobación que capacidad de atención, creando colas que el sistema no hace visibles. El segundo es la transferencia entre áreas: cada handoff introduce un retraso porque el trabajo entra en la cola del área receptora, pierde contexto en la transferencia, y frecuentemente requiere clarificación que genera otro ciclo de espera. El tercero son los recursos compartidos: especialistas que son necesarios en múltiples flujos simultáneamente — el actuario que evalúa riesgo en varios productos, el legal que revisa contratos de diferentes áreas, el arquitecto de TI que debe aprobar cambios en varios sistemas.

La intervención más efectiva sobre estos cuellos de botella no es la más intuitiva. No es agregar más capacidad en el cuello de botella (más aprobadores, más especialistas) — eso es costoso y frecuentemente impracticable en el corto plazo. La intervención más efectiva es reducir la demanda sobre el cuello de botella: eliminar aprobaciones que no agregan valor, automatizar las que son mecánicas, reducir la cantidad de trabajo que llega simultáneamente al recurso compartido, o rediseñar el proceso para que el cuello de botella solo intervenga cuando es estrictamente necesario.

En la práctica de consultoría en sectores regulados, el mapeo de flujo revela consistentemente que entre el 30% y el 50% de los pasos en un proceso no agregan valor desde la perspectiva del cliente — son controles redundantes, transferencias innecesarias, retrabajos por falta de información completa en el primer paso, o esperas generadas por políticas diseñadas para un contexto que ya no existe. Eliminar estos pasos no requiere tecnología nueva; requiere que alguien con autoridad suficiente examine el flujo completo y pregunte, para cada paso: “¿qué pasaría si dejáramos de hacer esto?”

Esa pregunta es más difícil de lo que parece, porque cada paso en un proceso existe porque alguien, en algún momento, decidió que era necesario. Frecuentemente en respuesta a un problema real que ocurrió una vez y generó un control permanente. El control que se agregó después de que una póliza se emitió con un error sigue existiendo 10 años después, aplicándose a todas las pólizas, aunque el sistema ya tiene validaciones automáticas que hacen redundante la revisión manual. Nadie elimina el control porque nadie tiene visibilidad de que es redundante — cada área ve su paso, no el flujo completo.

La gestión por flujo de valor no reemplaza la gestión por áreas funcionales. Las áreas funcionales siguen siendo necesarias para desarrollar expertise, gestionar personas y mantener estándares profesionales. Lo que la gestión por flujo agrega es una capa de coordinación que hace visible cómo el trabajo cruza las fronteras funcionales y dónde se degrada en esas fronteras. Las organizaciones que operan solo por áreas optimizan los segmentos; las que agregan gestión por flujo optimizan la entrega. Ambas son necesarias, pero sin la segunda, la primera produce eficiencias locales que no se traducen en resultados para el cliente.

Referencias

Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. North River Press.
Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383-387.
Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.
Womack, J. P., & Jones, D. T. (1996). Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Free Press.