operaciones · simulación
¿Dónde se acumula la cola? Cómo encontrar el cuello de botella antes que tus clientes
Cada proceso tiene una etapa que marca su ritmo. Una guía breve para detectarla con la ley de Little y la utilización, por qué añadir personas en otro punto no ayuda y cómo simular un cambio antes de hacerlo.
Un equipo de soporte incorpora dos agentes y el backlog no se mueve. Un equipo de ingeniería duplica el número de historias en curso y no entrega más rápido. Ambos casos tienen la misma causa, y se ve en unos cinco minutos cuando sabes dónde mirar.
Cada proceso tiene una etapa que marca su ritmo
El trabajo fluye por etapas: comprobaciones rápidas, triaje, investigación, escalado, cierre. Cada etapa tiene una capacidad: personas × horas al día ÷ horas por elemento. La etapa con menor capacidad en relación con el trabajo que le llega es el cuello de botella, y el rendimiento de todo el proceso es el de esa etapa. Nada más importa tanto.
Añadir gente en cualquier otro sitio parece productivo y no cambia nada. Solo mueve la pila.
Dos números te dicen dónde está
Utilización — cuánto trabajo tiene una fase, como proporción de su capacidad. Por debajo de un 80% aproximadamente, la cola se mantiene corta. Por encima del 90%, crece con cada pequeña fluctuación, porque no hay margen para absorber una mañana con mucha carga. Al 100% la cola crece sin límite: el trabajo llega más rápido de lo que sale, para siempre.
Ley de Little — el número de elementos en un sistema es igual a la tasa de llegada multiplicada por el tiempo que cada uno pasa en él. Dicho al revés: plazo de entrega = trabajo en curso ÷ rendimiento. Si tu equipo tiene 120 tickets abiertos y termina 20 al día, el ticket medio tarda seis días, diga lo que diga el SLA. Esto es aritmética, no opinión, y es la forma más rápida de comprobar una afirmación como "estamos bien, es solo una semana con mucho trabajo".
Por qué el síntoma aparece en otro sitio
La cola se acumula delante del cuello de botella, pero las quejas llegan después: escalados tardíos, ventanas de lanzamiento perdidas, clientes reclamando. Los equipos reaccionan donde está la queja, no donde está la restricción. Ver cómo se mueve el proceso —no el panel, sino los elementos reales— es lo que te permite ver que el "problema de escalado" es en realidad una fase de investigación ocupada al 95%.
Simula antes de cambiar
La forma honesta de responder a "¿ayudaría una persona más en la clasificación?" es probarlo en un modelo antes de probarlo con personas. El modelo necesita muy pocos datos: elementos por día, personas por fase, horas por elemento, con qué frecuencia los elementos se bifurcan o vuelven para repetir el trabajo. Ejecútalo durante un mes de días laborables. Observa qué cola crece, qué hace el plazo de entrega, cuántos elementos incumplen el objetivo.
Después cambia un número y ejecútalo de nuevo. Un revisor más en la aprobación de QA. Un pico el lunes. Una tasa de repetición de trabajo del 20% en lugar del 10%. La comparación te dice dónde la siguiente persona se amortiza y dónde no. Es un modelo basado en tus supuestos —no predecirá la cola del jueves—, pero te dirá dónde se rompe la estructura, que es la decisión que realmente estás tomando.
Hemos puesto exactamente esto en Ovenbird: la simulación lee las fases de tu propio documento de proceso, ajusta los números por defecto para que la primera ejecución aguante, y te deja forzar hasta que deje de hacerlo. Prueba la demo en la página de inicio; sube los tickets por día de 20 a 30 y mira cómo "Clasificación por síntoma" se pone en rojo.
Tres hábitos que mantienen visible el cuello de botella
- Mide la utilización por fase, no por equipo. Un equipo al 70% puede tener una fase al 98%.
- Cuenta el trabajo en curso cada semana y divídelo por el rendimiento. Si el plazo de entrega que obtienes es peor que lo que prometes, ninguna urgencia lo arregla.
- Cuando el documento cambie un paso, vuelve a ejecutar el modelo. Añadir una aprobación a una fase es añadir demanda de capacidad; el documento rara vez dice de dónde sale esa capacidad.