operazioni · simulazione
Dove si accumula la coda? Trovare il collo di bottiglia prima dei clienti
Ogni processo ha una fase che ne determina il ritmo. Una breve guida per individuarla con la legge di Little e il tasso di utilizzo, perché aggiungere persone altrove non aiuta e come simulare una modifica prima di farla.
Un team di supporto aggiunge due agenti e il backlog non si muove. Un team di engineering raddoppia il numero di storie in corso e non rilascia più in fretta. Entrambi hanno la stessa causa, ed è visibile in circa cinque minuti, una volta che sai dove guardare.
Ogni processo ha una fase che ne determina il ritmo
Il lavoro scorre attraverso le fasi: controlli rapidi, triage, analisi, escalation, chiusura. Ogni fase ha una capacità: persone × ore al giorno ÷ ore per elemento. La fase con la capacità più bassa rispetto al lavoro che le arriva è il collo di bottiglia, e il throughput dell'intero processo è quello di quella fase. Nient'altro conta altrettanto.
Aggiungere persone altrove sembra produttivo e non cambia nulla. Sposta solo la pila.
Due numeri ti dicono dov'è
Utilizzo — quanto è occupata una fase, in percentuale della sua capacità. Sotto circa l'80% la coda resta corta. Sopra il 90% cresce a ogni piccola oscillazione, perché non c'è margine per assorbire una mattinata intensa. Al 100% la coda cresce senza limite: il lavoro arriva più in fretta di quanto riesca a uscire, per sempre.
Legge di Little — il numero di elementi in un sistema è uguale al tasso di arrivo moltiplicato per il tempo che ciascuno vi trascorre. Detto al contrario: lead time = lavoro in corso ÷ throughput. Se il tuo team ha 120 ticket aperti e ne chiude 20 al giorno, il ticket medio richiede sei giorni, qualunque cosa dica lo SLA. È aritmetica, non opinione, ed è il modo più rapido per verificare un'affermazione come "stiamo bene, è solo una settimana intensa".
Perché il sintomo compare altrove
La coda si accumula davanti al collo di bottiglia, ma i reclami arrivano dopo: escalation in ritardo, finestre di rilascio mancate, clienti che sollecitano. I team reagiscono dove si trova il reclamo, non dove si trova il vincolo. Osservare il processo in movimento — non la dashboard, gli elementi reali — è il modo per capire che il "problema delle escalation" è in realtà una fase di indagine occupata al 95%.
Simula prima di cambiare
Il modo onesto per rispondere a "una persona in più al triage aiuterebbe?" è provarlo su un modello prima di provarlo sulle persone. Il modello richiede pochissimi input: elementi al giorno, persone per fase, ore per elemento, quanto spesso gli elementi si ramificano o tornano indietro per essere rilavorati. Eseguilo per un mese di giorni lavorativi. Osserva quale coda cresce, cosa fa il lead time, quanti elementi mancano l'obiettivo.
Poi cambia un numero e rieseguilo. Un revisore in più all'approvazione QA. Un picco del lunedì. Un tasso di rilavorazione del 20% invece del 10%. Il confronto ti dice dove la persona successiva si ripaga e dove no. È un modello basato sulle tue ipotesi — non prevede la coda di giovedì — ma ti dice dove la struttura cede, che è la decisione che stai davvero prendendo.
Abbiamo messo esattamente questo in Ovenbird: la simulazione legge le fasi dal tuo documento di processo, imposta valori predefiniti in modo che la prima esecuzione regga, e ti lascia spingere finché non regge più. Prova la demo nella home page; porta i ticket al giorno da 20 a 30 e guarda "Triage per sintomo" diventare rosso.
Tre abitudini che mantengono visibile il collo di bottiglia
- Misura l'utilizzo per fase, non per team. Un team al 70% può avere una fase al 98%.
- Conta il lavoro in corso ogni settimana e dividilo per il throughput. Se il lead time che ottieni è peggiore di quello che prometti, nessuna urgenza lo risolve.
- Quando il documento cambia un passaggio, riesegui il modello. Aggiungere un'approvazione a una fase significa aggiungere domanda di capacità; il documento raramente dice da dove arriva la capacità.