Mese: Giugno 2026

Pubblicato il

L’onda arriva ogni anno. Perché ci sorprende ancora?

In molte organizzazioni, l’arrivo di un picco di lavoro scatena una reazione prevedibile: dichiarazione di emergenza, straordinari improvvisati, la solita discussione sul personale insufficiente. E la frase che si sente più spesso in questi momenti è qualcosa del tipo: “Cosa possiamo farci? Ci è piombato addosso”.

Il problema è che raramente è vero.

I dati tolgono l’alibi

Guardiamo il caso reale in figura. Il dataset copre agosto 2024 – marzo 2026 e mostra il volume settimanale delle richieste in arrivo su un servizio operativo. Il grafico non mostra un andamento caotico: mostra un pattern.

A settembre 2024 il volume settimanale sale da una media di ~37 unità a 117–126. A giugno 2025 il picco è ancora più marcato: 178, poi 144, poi 200 nella settimana di punta. A settembre 2025 si ripete: 174 in una settimana. Il dataset si ferma a marzo 2026, ma se qualcuno in quella organizzazione stesse aspettando di “vedere come va” a giugno 2026, starebbe solo perdendo tempo.

L’onda arriva due volte l’anno, arriva sempre nello stesso periodo, e la sua magnitudo è nell’ordine di 4–5 volte il volume ordinario. Non è una sorpresa: è un appuntamento fisso scritto nei grafici dell’anno precedente.

Dalla sensazione alla misurazione

La differenza tra un’organizzazione che subisce i picchi e una che li gestisce non è la dimensione del team: è la cultura del dato.

Fino a quando l’unica fonte di informazione è la percezione soggettiva della fatica – “ci sembra di essere sommersi” – non c’è modo di quantificare quanto sia grande l’onda né di prepararsi in anticipo. Quando invece si lavora con dati storici strutturati, il ragionamento cambia: si può misurare la magnitudo del picco, si può confrontarla con la capacità disponibile, e si può calcolare quanto margine serve.

Il metodo Kanban fornisce esattamente questa infrastruttura di misura. Ma la misura da sola non basta: bisogna incrociare i dati della domanda con quelli della capacità. E qui entra in gioco il secondo fattore spesso trascurato.

I picchi di domanda tendono a coincidere con i periodi di minore disponibilità interna: le ferie estive si sovrappongono al picco di giugno, la stagione influenzale autunnale arriva insieme al picco di settembre. I dati storici delle Risorse Umane sull’incidenza delle assenze – se li si incrocia con la curva della domanda – permettono di anticipare questo combinato disposto di fattori con mesi di anticipo. Non servono modelli sofisticati: basta voler guardare i numeri.

La strategia: capacità flessibile, non eroismo individuale

Una volta accettato che i picchi sono prevedibili, la domanda diventa operativa: come si struttura la risposta?

La soluzione non è aumentare l’organico fisso per coprire i momenti di punta – sarebbe capacità sprecata per undici mesi l’anno. La soluzione è progettare una capacità flessibile, che si espande sui picchi e si contrae nei periodi ordinari.

In pratica questo si può realizzare in due modi:

  • Con fornitori esterni dimensionati in anticipo – partner già contrattualizzati, istruiti sul processo, pronti a subentrare quando il volume supera la soglia.
  • Con riserve interne trasversali – colleghi di altri reparti che in quel periodo hanno un carico inferiore, formati preventivamente sulle attività di supporto, attivabili su richiesta.

Il punto critico è preventivamente. Formare qualcuno durante un picco è inutile: il tempo di formazione va sottratto alla capacità già sotto pressione. La formazione va fatta nei mesi di calma, quando c’è il margine per farlo bene.

Nel caso reale dell’esempio, affrontato con questo approccio, la calibrazione non è avvenuta con un modello matematico ma con sperimentazione empirica: si è provato, si è osservato e misurato cosa succedeva al flusso, si è calibrata la capacità di riserva fino a trovare il punto di equilibrio. Quanta capacità in più serve esattamente per non essere sommersi? La risposta è nei dati della domanda durante i picchi passati.

Due tipi di variabilità, due risposte diverse

Arrivati a questo punto e alla luce degli articoli scritti precedentemente sul tema, è utile distinguere tra due nature diverse della variabilità, perché richiedono risposte diverse.

La variabilità stocastica – il rumore quotidiano, le fluttuazioni casuali intorno alla media – si gestisce con i principi classici della teoria delle code. Non si satura il sistema: si mantiene un buffer di capacità, si lavora sulla riduzione del WIP, si applica la formula di Kingman per tenere sotto controllo i tempi di attesa. Qui il problema è di calibrazione continua.

La variabilità stagionale è un fenomeno diverso. Non si tratta di rumore attorno a una media: si tratta di una variazione strutturale della scala del problema. La risposta non è ottimizzare i parametri interni – è cambiare la capacità del sistema. E questa è una decisione di pianificazione, non di gestione operativa.

Confondere le due cose è il principale errore che porta a rincorrere i picchi invece di prepararsi.

Vale la pena osservare che entrambe le forme di variabilità discusse in questo articolo – il rumore stocastico quotidiano e i picchi stagionali – rientrano nel dominio che Nassim Taleb chiama Mediocristan: la media è significativa, i pattern sono stabili, la distribuzione del lead time è prevedibile. È precisamente questo che rende possibile pianificare. In un sistema in Extremistan, dove un singolo elemento di lavoro può durare cento volte la mediana, nessuna delle strategie descritte qui funzionerebbe allo stesso modo. Come scegliere la strategia giusta in base alla natura statistica del proprio flusso è l’argomento dell’articolo precedente Anticipare o differire? Come leggere il proprio flusso per decidere al momento giusto.

Il lavoro di riserva: cosa fare se l’onda non arriva

L’obiezione più comune che ricevo per questo approccio è legittima: “e se quest’anno il picco è meno intenso del solito? Abbiamo pagato capacità in eccesso inutilmente.”

Il rischio esiste, ma si può mitigare. A chi è stato ingaggiato nella riserva si assegnano in parallelo attività a bassa priorità – miglioramenti, arretrati di manutenzione, documentazione, formazione interna – classificabili come lavoro intangible secondo le Classi di Servizio Kanban. Se il picco arriva nella sua forma attesa, queste attività vengono sospese e la capacità viene dirottata sul flusso principale. Se il picco è più contenuto, il team ha comunque generato valore su attività che altrimenti sarebbero rimaste indefinitamente in coda.

In entrambi i casi, l’organizzazione è in una posizione migliore rispetto a quella di chi non si è preparato.

Conclusione

I grafici in questo articolo mostrano dati reali di un servizio operativo. Chi gestisce quel servizio sa che a giugno c’è da aspettarsi un picco intorno a 150–200 unità di lavoro settimanali. La domanda non è se l’onda arriva, ma se l’organizzazione ha scelto di vederla in anticipo o di scoprirla quando si è già stati travolti.

In molti casi, gestire l’imprevedibile è soprattutto una questione di volontà di guardare i propri dati. Il caos non nasce dai picchi: nasce dalla scelta di ignorarli fino a quando non è troppo tardi.

Pubblicato il

Anticipare o differire? Come leggere il proprio flusso per decidere al momento giusto

Nel management operativo si confrontano costantemente due impulsi opposti: agire subito per non farsi trovare impreparati, oppure aspettare per decidere con più informazioni. Entrambi gli impulsi sono razionali. Entrambi possono essere sbagliati.

Il metodo Kanban non sceglie dogmaticamente tra i due. In articoli precedenti abbiamo esplorato la logica del differimento – perché posticipare le decisioni è un vantaggio competitivo, come calcolare il Last Responsible Moment – e la logica dell’anticipazione – come la Teoria dei Vincoli protegge il collo di bottiglia, perché i buffer condivisi del Critical Chain reggono meglio dei margini individuali.

La domanda che questi articoli lasciano aperta è: come si sceglie tra le due strategie? La risposta non è di gusto, né di filosofia manageriale. È statistica. Dipende da come si comporta il flusso di lavoro della propria organizzazione e dalle caratteristiche del contesto in cui ci si trova ad operare.

Due logiche, entrambe valide, in contesti diversi

La Teoria dei Vincoli dice: identifica il collo di bottiglia, ottimizza il suo carico di lavoro, proteggilo con un buffer immediatamente a monte, sincronizza tutto il resto al suo ritmo. Come abbiamo visto nell’articolo sul Drum-Buffer-Rope, questa logica funziona bene quando il collo di bottiglia è stabile e identificabile.

Lean e Kanban dicono invece: non impegnarti finché non devi, tieni aperte le opzioni, usa il Last Responsible Moment come punto limite di impegno. Il differimento riduce il lavoro abortito, migliora la qualità delle decisioni, libera capacità per le urgenze reali.

Il Critical Chain Project Management – che abbiamo esplorato di recente – trova una sintesi parziale: elimina i buffer individuali (fonte di spreco) e li aggrega in buffer condivisi di progetto, che vengono però allocati in anticipo. È anticipazione al servizio del sistema, non del singolo elemento di lavoro.

Queste logiche non si contraddicono: operano bene in domini diversi. Il problema è che molte organizzazioni applicano l’una o l’altra per abitudine, senza chiedersi quale sia appropriata al loro contesto specifico.

Il criterio: leggere la distribuzione del Lead Time

Nell’articolo sulla gestione proattiva dei rischi abbiamo introdotto la distinzione di Nassim Taleb tra Mediocristan ed Extremistan come modello di riferimento per classificare il rischio organizzativo. Quella distinzione diventa qui uno strumento operativo per la scelta strategica tra anticipazione e differimento.

Mediocristan è il dominio in cui le distribuzioni sono gaussiane o super-esponenziali (thin-tail): la media è significativa, la variabilità è contenuta entro limiti prevedibili, gli eventi estremi sono rari e di impatto limitato. Tecnicamente, il rapporto tra il valore di coda e la mediana è inferiore a 5.6. In questo dominio la Legge di Little funziona come strumento previsionale affidabile – a patto di avere almeno 70-100 punti dati per validare il tipo di distribuzione.

In Mediocristan l’anticipazione è una copertura legittima del rischio. I buffer della Teoria dei Vincoli hanno senso, la Critical Chain funziona, le scadenze fisse sono gestibili perché la distribuzione dei tempi di completamento è prevedibile. Impegnarsi in anticipo non è una scommessa: è una protezione calcolata.

Extremistan è il dominio delle distribuzioni a coda lunga (fat-tail), dove la variabilità non è contenuta e gli eventi estremi sono frequenti e di impatto sproporzionato. Il rapporto coda/mediana supera 5.6: un singolo elemento di lavoro può durare 10 o 100 volte la mediana, e la media non rappresenta nulla di utile.

In Extremistan anticipare è pericoloso. Chi pianifica su una media che non rappresenta la distribuzione reale si espone sistematicamente ai cosiddetti Cigni Neri: eventi nella coda lunga che distruggono le previsioni e con esse la fiducia del cliente. La strategia corretta è il differimento estremo: mantenere l’opzionalità il più a lungo possibile, impegnarsi solo quando l’incertezza si è sufficientemente ridotta.

Lo strumento diagnostico è già a disposizione di qualsiasi organizzazione che misuri i propri Lead Time: l’istogramma della distribuzione. Una distribuzione con una coda lunga e asimmetrica verso destra – magari con un picco visibile tra il corpo principale e pochi valori anomali molto distanti – è il segnale che si opera in Extremistan. Una distribuzione più compatta e simmetrica indica Mediocristan. Prima di scegliere la strategia, bisogna guardare la forma della curva e il rapporto coda/mediana.

Il principale motore che spinge un flusso verso Extremistan sono le dipendenze esterne: fornitori, approvazioni regolamentari, decisioni di terze parti. Una singola dipendenza esterna non governata può allungare la coda in modo molto significativo. In questi casi i sistemi di prenotazione (Reservation Systems) sono lo strumento per mitigare il rischio di coda senza rinunciare all’opzionalità.

Le implicazioni per le Classi di Servizio

La distinzione Mediocristan/Extremistan non è solo teorica: cambia concretamente il significato del triage e le sue politiche per ciascuna classe di servizio.

Le classi Expedite e Fixed Date funzionano nel Mediocristan, dove la scadenza ha un fondamento statistico. La data fissa è gestibile perché la distribuzione dei tempi di completamento è prevedibile; la classe Expedite indica un’urgenza reale perché il costo del ritardo cresce in modo identificabile. In Extremistan, una Fixed Date è spesso una scommessa: si fissa una data attesa senza sapere se la distribuzione dei tempi di completamento permetterà di rispettarla. Tra una data attesa e una data prevista c’è una grande differenza. L’urgenza Expedite rischia di diventare la norma, non l’eccezione.

La classe Standard segue il Last Responsible Moment in entrambi i domini, ma con una differenza critica: il calcolo del 50° percentile è significativo solo in Mediocristan, dove la mediana è stabile e rappresentativa. In Extremistan la mediana stessa può essere instabile con campioni ridotti.

La classe Intangible diventa il rifugio naturale per gli elementi di lavoro in Extremistan: si entra nel flusso solo quando l’incertezza è scesa a un livello gestibile, trattando il lavoro come opzione reale fino a quel momento. È la classe che meglio preserva l’opzionalità in condizioni di alta variabilità.

La maturità organizzativa come percorso verso la scelta consapevole

Il Kanban Maturity Model (KMM) descrive un percorso di evoluzione organizzativa che è anche, in questo contesto, un percorso verso la capacità di scegliere consapevolmente tra anticipazione e differimento.

Nelle organizzazioni che si affacciano per la prima volta alla gestione del flusso, la misurazione sistematica del Lead Time è assente o sporadica. Non si ha nemmeno l’istogramma per capire in quale dominio si opera. La scelta tra anticipazione e differimento è inconsapevole: si anticipa per ansia, si differisce per inerzia, senza un criterio. L’urgenza Expedite è endemica perché nessuno ha mai separato le urgenze vere dalle urgenze percepite.

Man mano che l’organizzazione matura – introducendo limiti al lavoro in corso, misurando i Lead Time, stabilizzando il flusso – emerge la capacità di leggere la distribuzione. A quel punto la scelta diventa informata: si può identificare se si opera in Mediocristan o Extremistan, applicare la politica di triage appropriata, calcolare il Last Responsible Moment con basi statistiche solide.

Le organizzazioni più mature compiono un passo ulteriore: lavorano attivamente per spostare il proprio flusso verso Mediocristan attraverso il trimming della coda – l’eliminazione sistematica dei valori anomali che allungano la distribuzione. La resilienza non si costruisce accettando la coda lunga come un dato di fatto: si costruisce attrezzando il sistema per identificarla e ridurla. A quel livello, l’anticipazione diventa possibile su basi sempre più ampie.

Il Two-Phase Commit come sintesi pratica

Come convivere con entrambe le logiche in un sistema reale? La risposta operativa è la separazione dell’impegno in due fasi distinte – un concetto introdotto nell’articolo sul Last Responsible Moment e che trova qui la sua collocazione strategica più ampia.

La prima fase – l’impegno a fare il lavoro – è possibile in entrambi i domini. L’organizzazione accetta la richiesta e la inserisce nel flusso, garantendo al cliente che il lavoro verrà fatto. Questo impegno non dipende dalla prevedibilità della distribuzione.

La seconda fase – l’impegno su una data di consegna specifica – è affidabile solo in Mediocristan, o quando un elemento di lavoro in Extremistan ha percorso abbastanza strada all’interno del flusso da uscire dalla coda lunga e diventare più prevedibile. Dare una data prima di questo punto non è trasparenza verso il cliente: è una scommessa che si scarica sul cliente stesso quando la previsione fallisce.

Questa separazione è la risposta concreta alla domanda di apertura. Non si tratta di scegliere una volta per tutte tra anticipazione e differimento: si tratta di applicare la logica giusta al momento giusto, su basi statistiche, con la consapevolezza di quale dominio si sta attraversando.

Pubblicato il

Gestire l’incertezza nei progetti: come il Critical Chain Project Management supporta il metodo Kanban

Chi lavora con il metodo Kanban impara presto a gestire il flusso: visualizza il lavoro, limita il WIP, misura il lead time. Quando il lavoro si fa più complesso – progetti con scadenze fisse, risorse condivise tra più attività e dipendenze articolate – è utile affiancare anche il Critical Chain Project Management (CCPM).

Sviluppato da Eliyahu M. Goldratt, il padre della Teoria dei Vincoli, il CCPM parte da una domanda scomoda: perché, nonostante pianificazioni meticolose e stime prudenti, i progetti finiscono quasi sempre in ritardo? La risposta di Goldratt ribalta alcune delle convinzioni più radicate su come gestiamo il tempo e le risorse – e per chi lavora con Kanban, più di un punto risulterà familiare.

La vera causa dei ritardi: non le attività, ma le risorse

La gestione dei progetti tradizionale, basata sul Metodo del Percorso Critico (CPM), si concentra esclusivamente sulla sequenza di attività più lunga per determinare la durata del progetto. L’innovazione fondamentale del CCPM è identificare, invece, la Catena Critica: la sequenza più lunga che considera sia le dipendenze tra i compiti sia le limitazioni delle risorse.

Questo è un cambio di prospettiva radicale. Il vero collo di bottiglia che determina la durata di un progetto non è quasi mai la lista delle cose da fare, ma una persona, un team o un’attrezzatura specifica condivisa tra più attività.

Per capire la differenza, immaginiamo un progetto semplice. Due attività possono partire in parallelo dopo una fase iniziale comune, ma richiedono entrambe la stessa risorsa critica: l’ingegnere capo. Il Metodo del Percorso Critico non vedrebbe problemi, ma il CCPM riconosce subito che le due attività non possono avvenire contemporaneamente. La vera sequenza più lunga – la Catena Critica – deve quindi includere la scelta di quale attività fare prima, rivelando un vincolo che altrimenti resterebbe invisibile fino al momento dell’esecuzione.

L’illusione della sicurezza: come i margini individuali rallentano tutto

L’idea controintuitiva più potente del CCPM riguarda i margini di sicurezza. Tradizionalmente, ogni membro del team aggiunge un margine di tempo alla stima di ogni singola attività per proteggersi dagli imprevisti. Fred, uno dei personaggi del romanzo Critical Chain di Goldratt, porta dati reali della sua azienda: quasi metà delle attività finisce esattamente alla scadenza, pochissime finiscono prima, e circa un terzo finisce con un 10-20% di ritardo rispetto alla stima originale. La sua conclusione è che il margine di sicurezza individuale non protegge né il singolo step né il progetto nel suo insieme.

Questa tolleranza incoraggia comportamenti controproducenti. La sindrome dello studente – termine coniato da Goldratt – descrive il meccanismo per cui, avendo tempo a disposizione, si procrastina fino all’ultimo: quando si inizia a lavorare, il cuscinetto è già stato consumato, e l’attività finisce comunque in ritardo. A questo si aggiunge la Legge di Parkinson: il lavoro si espande fino a occupare tutto il tempo disponibile.

Il CCPM elimina questi margini individuali nascosti. Le stime delle attività diventano più aggressive, basate sul tempo effettivamente necessario per completarle. La sicurezza rimossa viene aggregata e resa esplicita in “buffer” condivisi che proteggono l’intero progetto:

  • Project Buffer: posto alla fine della catena critica per proteggere la data di consegna finale dall’incertezza accumulata.
  • Feeding Buffer: inseriti dove le catene di attività secondarie si collegano alla catena critica, per evitare che i ritardi su percorsi non critici impattino su quello principale.
  • Resource Buffer: utilizzati per garantire che le risorse critiche siano pronte e disponibili esattamente nel momento in cui sono necessarie.

Questo approccio trasforma l’incertezza da un problema individuale a una responsabilità collettiva.

La figura mostra un esempio di rete CCPM. La catena critica – in giallo – segue il percorso A→C→E→F→H. Due percorsi non critici convergono su di essa: il primo attraverso B e D, che si aggancia in H tramite feeding buffer; il secondo attraverso G e I, che si aggancia in F tramite feeding buffer. Il project buffer finale protegge la data di consegna dall’incertezza accumulata sull’intero progetto.

La psicologia del progetto efficace: il project multitasking come causa sistemica dei ritardi

Il CCPM scoraggia attivamente il multitasking, e non si riferisce solo all’abitudine individuale di saltare da un compito all’altro. La forma più dannosa è quella organizzativa: aprire troppi progetti in contemporanea. È una dinamica comune – ogni progetto sembra urgente al momento dell’approvazione, il portfolio cresce, le stesse risorse critiche vengono distribuite su tutto. Il risultato è che nessun progetto avanza davvero, perché ogni risorsa chiave è costantemente interrotta, richiamata, riassegnata.

Goldratt dimostra questo con un esempio quantitativo: una persona che lavora in multitasking su tre attività da dieci giorni ciascuna, alternandosi ogni cinque giorni, vede il Lead Time di ognuna raddoppiare – e questo senza considerare il tempo perso nei cambi di contesto. Il meccanismo diventa poi sistemico: più progetti aperti allungano i Lead Time, Lead Time più lunghi significano più progetti in corso contemporaneamente, e il ciclo si autoalimenta. Goldratt lo definisce esplicitamente “il principale killer del Lead Time”.

La soluzione proposta è controintuitiva: aprire meno progetti contemporaneamente. Non per fare meno, ma per finire di più – perché le risorse critiche possono finalmente completare un lavoro prima di passare al successivo. Chi conosce il metodo Kanban riconoscerà qui la logica dei WIP limit: ridurre il lavoro in corso non è una limitazione, ma la condizione che rende stabile il flusso.

La figura mostra l’effetto in modo immediato: lavorare sulle attività di tre progetti in parallelo raddoppia il lead time di ciascuno. Lo stesso principio del WIP limit si applica sia alle singole attività, che ai progetti presenti nel portfolio.

Un nuovo modo di misurare: non le scadenze, ma il consumo del buffer

Nel project management tradizionale, la domanda chiave è: “Siamo in linea con la tabella di marcia?”. Nel CCPM diventa: “Quanta parte del nostro buffer abbiamo consumato rispetto ai progressi fatti?”.

Per rispondere, il CCPM introduce il Fever Chart (“grafico della febbre”): un grafico che mette in relazione la percentuale di completamento della catena critica con la percentuale di buffer consumato. Le tre zone (verde, gialla e rossa) funzionano come un termometro. La sua forza è predittiva: trovarsi nella zona gialla non significa che il progetto è in ritardo, ma che il rischio di un futuro ritardo è aumentato. Un approccio familiare a chi usa le metriche di flusso del Kanban, come i CFD: anche lì l’obiettivo è anticipare i problemi, non certificare i ritardi.

Il Fever Chart mette in relazione l’avanzamento del progetto con il consumo del project buffer. La curva bianca mostra l’andamento reale: nel nostro esempio il progetto entra in zona rossa nella prima metà, per poi rientrare in zona gialla verso la fine – uno strumento predittivo che non certifica i ritardi, ma li anticipa in tempo utile per intervenire.

Risultati concreti: cosa dicono i casi reali

Il CCPM non è un esperimento accademico. La NASA lo ha utilizzato per gestire le gallerie del vento al Langley Research Center, riuscendo a mantenere il volume di test nonostante un taglio del 50% del personale. Procter & Gamble Pharmaceuticals lo ha adottato nel 2004 per gestire un aumento del carico di lavoro senza risorse aggiuntive, riducendo i tempi di ciclo nei trial clinici. In letteratura le riduzioni documentate delle durate di progetto vanno dal 20% al 40% rispetto ai metodi tradizionali.

Conclusione

Il CCPM è molto più di una tecnica di pianificazione: è una filosofia manageriale che rende l’incertezza visibile, misurabile e gestibile. La vera sfida non è tecnica ma culturale: rinunciare alla protezione individuale per contribuire a una riserva comune. È un cambio di mentalità che richiede fiducia nel sistema – e nella capacità collettiva di tenere insieme ciò che il lavoro individuale tende a frammentare.

Bibliografia

  1. Eliyahu M. Goldratt, Critical Chain, Gower Publishing, 1997.
  2. Andrew G. Hagemann, Use of the Critical Chain Project Management Technique at NASA Langley Research Center, 20th Digital Avionics Systems Conference (DASC), IEEE, 2001.
  3. Michelle Smith, CCPM: A Sustaining Strategy at Procter & Gamble Pharmaceuticals, Pharmaceutical Processing World, 2004.
Pubblicato il

Sotto il 65%: quando la variabilità abbassa la soglia di efficienza del flusso

In un articolo precedente ho utilizzato la Teoria delle Code – e nello specifico la Legge di Little come caso particolare – per spiegare perché un sistema di flusso raggiunga la sua massima efficienza intorno al 65% del carico massimo teorico. Questo articolo si rivolge a chi vuole approfondire le basi matematiche di quel risultato e capire cosa succede quando le ipotesi semplificatrici del modello di partenza vengono rilassate.

Il modello sottostante, che ora possiamo nominare esplicitamente, si chiama M/M/1: una coda con un unico canale di servizio (1), arrivi casuali senza memoria secondo una distribuzione di Poisson (la prima M, da Markovian) e tempi di servizio con distribuzione esponenziale (la seconda M). In notazione estesa di Kendall si scriverebbe M/M/1/∞, dove ∞ indica che non c’è limite alla lunghezza della coda, ma per convenzione il quarto elemento si omette quando è infinito.

C’è però un’assunzione nascosta, che vale la pena portare in superficie: il modello M/M/1 fissa la variabilità del sistema a un valore preciso e implicito. Il 65% è corretto, ma solo per quel livello di variabilità. Se il sistema è più regolare, la soglia si alza. Se è più caotico, si abbassa.

La formula che permette di generalizzare questo risultato si chiama formula di Kingman, o equazione VUT. È il punto di arrivo naturale del ragionamento che abbiamo iniziato.

Cosa mancava nel modello precedente

Nel modello M/M/1, sia gli arrivi che i tempi di servizio seguono distribuzioni con una proprietà specifica: il loro coefficiente di variazione – il rapporto tra deviazione standard e media – è esattamente pari a 1.

Questo significa che stavamo implicitamente assumendo una variabilità “standard” sia per gli arrivi che per i tempi di lavorazione. Nella realtà queste assunzioni reggono raramente. Un sistema in cui gli elementi di lavoro (work item) arrivano a ondate – fine mese, fine sprint, richieste urgenti in cluster – ha una variabilità degli arrivi ben superiore a 1. Un sistema in cui alcuni task richiedono un’ora e altri una settimana ha una variabilità dei tempi di servizio anch’essa superiore a 1.

La domanda diventa: come cambia il Tempo di Ciclo quando la variabilità non è quella “standard” del modello M/M/1?

La formula di Kingman

La risposta la fornisce John Kingman, matematico britannico, con una formula che generalizza M/M/1 a sistemi con distribuzioni arbitrarie di arrivi e servizi. La formula calcola una approssimazione accettabile del tempo medio di attesa in coda (Wq), cioè il tempo che un work item trascorre in attesa prima di essere preso in carico:

  • Ca² = quadrato del coefficiente di variazione degli arrivi
  • Cs² = quadrato del coefficiente di variazione dei tempi di servizio
  • ρ = λ / μ = tasso di utilizzazione del sistema, dove λ è il tasso di arrivo dei work item e μ è la capacità produttiva
  • Te = tempo medio di servizio

La formula si legge come il prodotto di tre fattori distinti:

  1. Il fattore di variabilità: (Ca² + Cs²) / 2 – cresce all’aumentare dell’irregolarità del sistema
  2. Il fattore di utilizzazione: ρ / (1 − ρ) – esplode quando ci si avvicina al 100% di carico
  3. Il tempo di servizio base: Te – scala il risultato all’unità di misura del sistema

Il tempo totale di permanenza nel sistema – il Tempo di Ciclo che ci interessa (W) – si ottiene sommando il tempo di attesa in coda con il tempo di servizio: W = Wq + Te.

M/M/1 come caso particolare

Se sostituiamo nella formula di Kingman i valori propri del modello M/M/1, ovvero Ca² = 1 e Cs² = 1, otteniamo come tempo medio di attesa in coda (Wq):

Il tempo totale nel sistema (W), che include anche il tempo di servizio, diventa:

Sostituendo Te = 1/μ e ρ = λ/μ:

Che è esattamente la formula del Ws usata nell’articolo precedente. M/M/1 è dunque un caso particolare di Kingman, valido quando la variabilità di arrivi e servizi è esattamente pari a 1.

Per completezza vale la pena notare che le formule esatte per code con distribuzioni specifiche furono sviluppate da Agner Krarup Erlang già a inizio ‘900. Kingman generalizza quel lavoro a distribuzioni arbitrarie, al prezzo di un’approssimazione, sufficientemente accurata per le analisi che ci interessano. Più recentemente Donald Reinertsen in The Principles of Product Development Flow si riferisce alla formula di Allen-Cuneen, che esprime lo stesso risultato in termini di lunghezza media della coda (Lq) anziché di tempo di attesa (Wq) – le due formule sono equivalenti e collegate dalla Legge di Little: Lq = λ · Wq.

Cosa cambia con la variabilità

Il fattore (Ca² + Cs²) / 2 è il moltiplicatore che modifica il tempo di attesa in coda (Wq) rispetto al caso M/M/1. Se è uguale a 1, siamo nel caso precedente. Se è maggiore di 1, Wq cresce proporzionalmente. Se è minore di 1, il sistema regge meglio il carico. Il tempo totale W = Wq + Te cambia di conseguenza, ma in misura attenuata perché Te rimane fisso.

Riprendiamo il sistema dell’articolo precedente: capacità produttiva μ = 10 work item al giorno per ogni giornata lavorativa di 8 ore.

Carico (λ)Utilizzo (ρ)W – bassa variabilità (Ca²=Cs²=0,5)W – M/M/1 (Ca²=Cs²=1)W – alta variabilità (Ca²=Cs²=2)
550%1h 12min1h 36min2h 24min
660%1h 24min2h3h 12min
770%1h 44min2h 40min4h 32min
880%2h 24min4h7h 12min
990%4h 24min8h15h 12min

La struttura è la stessa: il Tempo di Ciclo esplode avvicinandosi al 100%. Ma la scala cambia in modo significativo. Con alta variabilità, già al 50% di carico il sistema impiega quasi due ore e mezza per evadere un singolo work item e al 70% di carico il sistema impiega quasi cinque ore, laddove con bassa variabilità lo stesso carico del 70% sarebbe invece ancora ampiamente gestibile.

Il 65% potrebbe essere ottimistico

Il risultato pratico è diretto: la soglia del 65% vale per il caso M/M/1, cioè per un sistema con variabilità “standard”. Nel lavoro di concetto (knowledge work) e nei servizi dove le richieste arrivano in modo irregolare e i tempi di lavorazione possono variare molto da un task all’altro, Ca² e Cs² sono tipicamente superiori a 1.

Questo significa che il 65% è, in molti contesti reali, una stima ottimistica. La soglia di efficienza reale si abbassa. Un sistema con alta variabilità può richiedere di operare al 50% o anche meno per mantenere Tempi di Ciclo accettabili.

Le leve per migliorare il flusso

“Festina lente” (Affrettati lentamente – Svetonio)

Reinertsen suggerisce e rende esplicite tre leve distinte per la gestione delle code, con efficacia e natura diverse. Vale la pena passarle in rassegna.

1. Ridurre il carico (ρ) – leva dominante

È la leva del limite al lavoro in corso (WIP limit): tenere il sistema al di sotto della soglia di saturazione. Il fattore di utilizzazione ρ/(1−ρ) cresce in modo superlineare, a ρ=0,9 vale 9, a ρ=0,95 vale 19. Agire su ρ produce effetti sproporzionatamente grandi rispetto all’entità dell’intervento.

2. Ridurre la variabilità (Ca² e Cs²) – leva incrementale

Il fattore di variabilità entra nella formula in modo lineare rispetto a Ca² e Cs²: raddoppiare la variabilità raddoppia Wq, nulla di più. Nel concreto significa regolarizzare il flusso degli arrivi e ridurre la dispersione dei tempi di lavorazione – standardizzazione, suddivisione dei task in unità più omogenee. Nel knowledge work tuttavia la variabilità è difficile da comprimere per ragioni strutturali: è nella natura del lavoro cognitivo. La riduzione della variabilità è un miglioramento incrementale sopra la leva dominante, non un’alternativa ad essa.

3. Gestire la sequenza della coda – leva compensativa

Quando la coda esiste, l’ordine con cui i work item vengono processati ha un valore economico misurabile. Nel manifatturiero, dove i job sono di solito omogenei per durata e costo del ritardo, FIFO (First-In-First-Out) è ottimale e non c’è nulla da ottimizzare nella sequenza. Nel lavoro di concetto i work item sono eterogenei per definizione, e una disciplina di gestione della coda (queueing discipline) esplicita crea valore. Le due euristiche di base: a parità di durata, prima il job con costo del ritardo più alto; a parità di costo del ritardo, prima il job più corto. Nel linguaggio Kanban, questa leva si traduce in classi di servizio e policy di replenishment.

Vale però sottolineare che la queueing discipline è uno strumento compensativo: serve perché siamo lontani dall’ottimo, non è una soluzione strutturale. L’obiettivo ideale è avere code così piccole da non richiedere discipline di priorità e ci si arriva agendo sulle prime due leve.

Un vantaggio comune alle leve 1 e 3

Limitare il WIP e gestire la sequenza della coda sono interventi su variabili soft: si attuano con una decisione di policy, sono immediati e reversibili. Aumentare la capacità produttiva (μ) è invece una variabile hard: assumere, formare, riorganizzare sono azioni lente e costose. Questa asimmetria pratica rafforza ulteriormente la priorità delle leve operative rispetto all’investimento in capacità.

Quanto costa non avere capacità in eccesso

Fino a qui abbiamo ragionato in termini di flusso. C’è però una formalizzazione economica del problema che vale la pena esplicitare, particolarmente utile quando si deve giustificare una scelta di capacity management a un imprenditore o un responsabile aziendale.

Il costo totale di un sistema in coda è la somma di due componenti che si muovono in direzioni opposte:

  • Cc = costo unitario della capacità (il costo di avere una persona in più, un server in più)
  • CD = costo unitario del ritardo (il valore economico del tempo perso in attesa)
  • Cc·μ = costo totale della capacità, che cresce linearmente con μ
  • CD·λ/(μ−λ) = costo totale del ritardo, che decresce all’aumentare di μ e diverge quando μ converge verso il valore di λ

Il minimo del costo totale si trova in:

La lettura è diretta: la capacità ottimale è sempre superiore al tasso di arrivo – operare al 100% non è mai ottimale economicamente. La distanza dall’ottimo dipende dal rapporto CD/Cc: quanto più il costo del ritardo è alto rispetto al costo della capacità, tanto più conviene investire in capacità in eccesso.

Per chi deve prendere queste decisioni, il ragionamento si traduce in una domanda concreta: quanto costa, nella mia organizzazione, un giorno di ritardo su un work item tipico? Se la risposta è “molto” – cliente che aspetta, opportunità che sfuma, deadline contrattuale a rischio – allora la capacità in eccesso non è uno spreco, è un investimento con un rendimento calcolabile. Operare “al risparmio” sulla capacità può essere la scelta economicamente peggiore.

Conclusione

La Legge di Little ci dice che WIP (L), tasso di arrivo (λ) e Tempo di Ciclo (W) sono legati. Il modello M/M/1 mostra come il Tempo di Ciclo esploda avvicinandosi alla saturazione. Kingman completa il quadro: l’esplosione è amplificata dalla variabilità, e variabilità e utilizzazione si moltiplicano, non si sommano.

Il 65% rimane un riferimento utile. Ma in un sistema ad alta variabilità, come può essere il knowledge work, è una soglia da cui partire verso il basso, non un obiettivo da raggiungere. Le leve per migliorare il flusso esistono, hanno efficacia diversa, e – cosa non trascurabile – le più potenti sono anche le più facili da azionare.

Bibliografia

  1. John F.C. Kingman, The single server queue in heavy traffic, Mathematical Proceedings of the Cambridge Philosophical Society, 1961
  2. Paul Newbold, Principles of Management Science, Prentice-Hall, 1986
  3. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing, 2009