{"id":3844,"date":"2025-12-23T15:15:35","date_gmt":"2025-12-23T15:15:35","guid":{"rendered":"https:\/\/eccellenzedimpresa.it\/?post_type=cp_magazine&p=3844"},"modified":"2026-04-21T09:46:02","modified_gmt":"2026-04-21T09:46:02","slug":"quando-il-caos-organizzativo-nelle-aziende-diventa-performance","status":"publish","type":"cp_magazine","link":"https:\/\/eccellenzedimpresa.it\/el\/magazine\/quando-il-caos-organizzativo-nelle-aziende-diventa-performance\/","title":{"rendered":"Quando il caos organizzativo nelle aziende diventa performance"},"content":{"rendered":"\n

Pubblicato su:<\/strong>\u00a0Mit Sloan Management Review Italia, Agosto\/Settembre\/Ottobre 2025.Anno 4.Numero 4.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Tra scadenze che si accavallano e progetti che si moltiplicano, le aziende rischiano il ko.<\/p>\n\n\n\n

Per mantenere la competitivit\u00e0 necessaria a raggiungere i propri obiettivi di business, le aziende sono costrette ad affrontare un numero sempre maggiore di progetti.<\/strong> Sono infatti chiamate a proporre continuamente nuovi prodotti, a un ritmo pi\u00f9 serrato. Devono rispondere velocemente alle richieste dei clienti con soluzioni personalizzate e su misura, oltre a incrementare la loro offerta con servizi progettuali in grado di soddisfare le diverse esigenze dei clienti. Le tendenze che promuovono e spingono per la digitalizzazione sommergono le organizzazioni di molteplici progetti paralleli per introdurre le nuove tecnologie. Questo volume crescente di progetti si aggiunge agli sforzi gi\u00e0 in atto richiesti dai progetti di miglioramento continuo, di marketing, di manutenzione e di sviluppo del business.<\/p>\n\n\n\n

<\/div>\n\n\n\n

I team di progetto<\/strong> sono sotto pressione crescente<\/strong> per eseguire e completare un numero maggiore di progetti in tempi sempre pi\u00f9 stretti. Il\u00a0time-to-market<\/em>, la capacit\u00e0 di scalare rapidamente gli obiettivi per avere un ritorno rapido sugli investimenti, sono elementi critici per l\u2019organizzazione. Aggiungere risorse essenziali per far fronte a questa pressione pone spesso sfide significative. Ci sono richieste imperative per mantenere alta l\u2019efficienza e per tenere in controllo i costi e spesso le risorse necessarie non sono facilmente reperibili. Tutte queste pressioni si traducono nella necessit\u00e0 critica per le organizzazioni di eccellere nell\u2019esecuzione dei progetti. Accelerare il ritmo di completamento dei progetti, garantire l\u2019agilit\u00e0, l\u2019efficienza delle risorse e l\u2019allineamento con le richieste del mercato non \u00e8 pi\u00f9 un lusso, ma una necessit\u00e0 fondamentale che definir\u00e0 la capacit\u00e0 delle aziende di competere efficacemente.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Eppure, nonostante decenni di sforzi, numerose ricerche accademiche e diverse metodologie per supportare i Project manager, i tre obiettivi fondamentali dei progetti \u2013 consegnare in accordo alle specifiche, nei tempi e nei limiti del budget \u2013 sembrano spesso impossibili da raggiungere.<\/p>\n\n\n\n

<\/div>\n\n\n\n
<\/div>\n\n\n\n

Il circolo vizioso negli ambienti multiprogetto<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

In tutti i settori che scegliamo di analizzare, che si tratti di sviluppo software, ingegneria, IT, costruzioni, servizi o qualsiasi altro ambiente multiprogetto, i progetti finiscono quasi sempre con il richiedere pi\u00f9 tempo rispetto alle stime iniziali. Poich\u00e9 ci si impegna a rispettare delle date di scadenza, c\u2019\u00e8 una pressione a terminarli in tempo. Sappiamo tutti che se si inizia a lavorare in ritardo a un progetto, non vi sono speranze di portarlo a termine nei tempi previsti. Quando invece si inizia a lavorare al pi\u00f9 presto su un progetto, prima ancora di completare quelli in corso a cui si stava gi\u00e0 lavorando, ci si ritrova con l\u2019avere pi\u00f9 progetti concorrenti aperti nello stesso momento. Poich\u00e9 il cliente \u2013 sia esso interno o esterno \u2013 ha delle aspettative, per dimostrare che si stanno facendo progressi in tutti i progetti aperti si viene sottoposti a un\u2019enorme pressione per lavorare in multitasking<\/strong> tra di essi. Si finisce quindi per lavorare su alcuni progetti quando ci si sarebbe dovuti concentrare sul completamento di altri. Il che significa, inevitabilmente, che i progetti richiedono pi\u00f9 tempo del previsto. Questo circolo vizioso, che rappresenta la continua pressione ad avviare sempre pi\u00f9 progetti e a lavorare in multitasking tra di essi, gravando le stesse persone e risorse con sempre pi\u00f9 lavoro, riflette la realt\u00e0 odierna nella maggior parte degli ambienti multiprogetto.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Decenni di sforzi significativi per migliorare le prestazioni, considerevoli studi accademici e molteplici metodi e tecniche per una migliore pianificazione e una migliore esecuzione hanno portato molti a credere che questa sia la realt\u00e0 inevitabile dei progetti e che non si possa fare molto al riguardo. Molti sostengono che questa realt\u00e0 sia determinata dall\u2019incertezza insita nella natura dei progetti. Incertezza che si deve accettare come un dato di fatto ineluttabile.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Uno degli esperti che ha esaminato il ruolo chiave dell\u2019incertezza nei progetti e la necessit\u00e0 di affrontarla \u00e8 stato il dottor Eliyahu Goldratt<\/strong>, fondatore della Teoria dei vincoli<\/strong>, conosciuta anche come Toc<\/em>, acronimo del nome originario Theory of constraints<\/em>. Goldratt ha notato che, anche con la pianificazione e l\u2019esecuzione pi\u00f9 meticolose, la nostra capacit\u00e0 di ridurre l\u2019incertezza \u00e8 piuttosto limitata. Il suo metodo innovativo non consisteva nel tentare di imporre la certezza alle situazioni incerte, ma piuttosto nel riconoscerla e nel gestirla al meglio.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Che cos\u2019\u00e8 la Teoria dei vincoli?<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Eliyahu Goldratt, nel suo articolo\u00a0What is Toc? My perspective<\/em>, ricorda che una volta un giornalista gli chiese di descrivere la Teoria dei vincoli in cinque frasi. Lui rispose che non servivano cinque frasi, perch\u00e9 sarebbe stata sufficiente una sola parola: \u2018focus<\/strong>\u2019, ovvero focalizzazione. Goldratt defin\u00ec il concetto della focalizzazione come \u201cFare ci\u00f2 che deve essere fatto ed evitare di fare ci\u00f2 che non deve essere fatto\u201d<\/em>. Applicando questa definizione di focalizzazione, egli ha sviluppato soluzioni innovative per la produzione, il Project management, il Management accounting (chiamato Throughput accounting), la Supply chain, la distribuzione e per molti altri ambiti ancora. Soluzioni che sono state applicate in numerose organizzazioni in tutto il mondo.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt scrisse il suo primo libro, The goal<\/em>, (tradotto in italiano con il titolo L\u2019obiettivo<\/em>) per far conoscere il suo pensiero innovativo e per migliorare la gestione delle Operation in produzione. La convinzione comune, che egli ha sempre messo in discussione e osteggiato, \u00e8 che il massimo sfruttamento di ogni impianto e ogni risorsa sia un obiettivo da perseguire per avere processi produttivi pi\u00f9 efficienti. In forza di questa convinzione, i manager cercano di massimizzare l\u2019efficienza di ogni singola macchina e di ogni singolo reparto. Un obiettivo che richiede ingenti sforzi, che sfortunatamente non sono ripagati con i risultati sperati.<\/p>\n\n\n\n

<\/div>\n\n\n\n

I manager dovrebbero piuttosto fare qualcosa di completamente diverso.<\/strong> Dovrebbero sforzarsi di considerare il sistema nella sua interezza, identificarne i colli di bottiglia, le risorse con la capacit\u00e0 pi\u00f9 limitata, e concentrarsi esclusivamente sulla loro produttivit\u00e0. Egli ha richiamato l\u2019attenzione alla \u2018focalizzazione sull\u2019ottimo globale\u2019, in contrapposizione a una pluralit\u00e0 di sforzi inutili distribuiti alla ricerca di ottimizzazioni locali.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Scritto in forma di business novel, L\u2019obiettivo<\/em> \u00e8 diventato un best seller mondiale della letteratura manageriale ed \u00e8 reputato unanimemente come l\u2019introduzione alla Teoria dei vincoli. Sebbene molti concetti e soluzioni cardine della Teoria dei vincoli siano stati sviluppati anche successivamente all\u2019uscita del libro, i princ\u00ecpi fondanti non sono cambiati. In effetti, L\u2019obiettivo<\/em> \u00e8 rilevante oggi come lo era 40 anni fa.<\/p>\n\n\n\n

<\/div>\n\n\n\n
<\/div>\n\n\n\n

La soluzione della Teoria dei vincoli per il Project management<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Il Project management \u00e8 intrinsecamente diverso dalla produzione. Innanzitutto, perch\u00e9 i progetti non presentano le caratteristiche di ripetitivit\u00e0 della produzione. Ogni progetto \u00e8 diverso e quindi comporta molti pi\u00f9 rischi.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt, tuttavia, osserv\u00f2 che le persone impegnate nei progetti commettevano lo stesso errore di base: quello di gestire il rischio localmente invece di prestare attenzione al quadro complessivo. Si tende a salvaguardare ogni attivit\u00e0, pensando di proteggere l\u2019intero progetto, ma il modo in cui ci\u00f2 \u00e8 fatto finisce per sprecare il pi\u00f9 delle volte i margini di sicurezza adottati.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt chiam\u00f2 la nuova soluzione della Teoria dei vincoli per la gestione dei progetti con il nome di Critical chainproject management<\/strong> (abbreviato in Ccpm). Per presentarlo scrisse un\u2019altra business novel intitolata\u00a0Critical chain<\/em>. Questo approccio (anche chiamato Catena critica) non deve essere confuso con il Critical path (o Percorso critico). Originariamente, la soluzione della Catena critica includeva la pianificazione del progetto e il Buffer management.<\/p>\n\n\n\n

<\/div>\n\n\n\n

L\u2019assunto alla base del Buffer management \u00e8 semplice: poich\u00e9 i progetti sono in ritardo a causa di fattori imprevedibili, i manager dovrebbero utilizzare dei buffer<\/em> temporali per proteggersi dai ritardi causati da questi imprevisti. Per proteggere l\u2019intero progetto, il buffer<\/em> principale deve essere sempre posizionato alla fine del progetto.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Egli ha spiegato come creare dei buffer<\/em> di tempo senza allungare il tempo originariamente previsto per il progetto e come gestirli su base continuativa. Ogni volta che un collaboratore esaurisce il tempo a disposizione, deve rivolgersi al manager responsabile del buffer<\/em> e richiedere del tempo aggiuntivo. Il manager deve concedere il tempo, ma anche informarsi sui motivi del ritardo e chiedere conto dei ritardi non giustificati.<\/p>\n\n\n\n

<\/div>\n\n\n\n

L\u2019origine delle interruzioni nei progetti<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Con un numero sempre maggiore di implementazioni in tutto il mondo, il Ccpm si \u00e8 dimostrato una tecnica eccellente per la gestione dei progetti. Man mano che le implementazioni iniziavano a crescere di numero, Goldratt si accorse che c\u2019era tuttavia un problema. Se da un lato la tecnica permetteva di rappresentare chiaramente lo stato di salute del progetto, allo stesso tempo aveva portato alla luce il fatto che i\u00a0buffer<\/strong><\/em>\u00a0erano spesso sprecati senza evitare che i progetti finissero in ritardo. Inizialmente pens\u00f2 che si trattasse di mettere a punto alcuni dettagli. Furono profusi ingenti sforzi sia da lui, sia da molti altri esperti per capire come suddividere le attivit\u00e0, dove posizionare i\u00a0buffer<\/em>, come calcolare meglio la loro dimensione, eccetera. Tuttavia, i risultati rimanevano pi\u00f9 o meno gli stessi.\u00a0<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt inizi\u00f2 a sospettare che non si trattasse di dettagli<\/strong>; l\u2019assunto di base era errato. Prima di usare i\u00a0buffer<\/em>, il caos nei progetti era cos\u00ec grande che tutto ci\u00f2 che le persone potevano fare quando le cose andavano male era puntare il dito l\u2019uno contro l\u2019altro. Ma ora, il controllo dei\u00a0buffer<\/em>\u00a0e la documentazione delle cause dei ritardi avevano fornito una chiarezza che nessuno aveva prima. Goldratt \u00e8 stato in grado di esaminare le disfunzioni che provocavano il consumo anomalo dei\u00a0buffer<\/em>\u00a0e ci\u00f2 che ha scoperto \u00e8 stato davvero illuminante. L\u2019incertezza nei progetti \u00e8 senza dubbio una causa di interruzione, ma certamente non \u00e8 l\u2019unica e spesso non \u00e8 la principale.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Il tempo nei progetti era sprecato non solo a causa di ritardi imprevisti, ma principalmente come conseguenza di ostacoli intrinseci che rallentavano il flusso dei progetti.<\/strong> Fu una rivelazione sbalorditiva. Non si trattava pi\u00f9 di mettere a punto la gestione dei\u00a0buffer<\/em>; si trattava di sviluppare un nuovo corpo di conoscenze, identificando le cause invisibili che provocavano i ritardi nei progetti. Per riuscire a raggiungere questo risultato, Goldratt inizi\u00f2 a concentrarsi sul flusso nei sistemi.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Il concetto del flusso<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Il concetto del flusso \u00e8 piuttosto intuitivo. \u00c8 relativamente semplice visualizzare il flusso dei progetti che si snoda attraverso il sistema e comprendere che, quando qualcosa ne ostruisce l\u2019avanzamento, i progetti si accumulano. I tempi di esecuzione si dilatano e, di conseguenza, l\u2019affidabilit\u00e0 delle date promesse ne risente. Non \u00e8 altrettanto semplice individuare gli ostacoli specifici che rallentano il flusso e capire come rimuoverli. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Gli ostacoli possono essere visti come \u2018muri invisibili<\/strong>\u2019 che impediscono al flusso dei progetti di avanzare in modo regolare, senza interruzioni, fino al loro completamento. Questi ostacoli non sono un segreto. Li conosciamo tutti. Si tratta di abitudini o comportamenti specifici <\/strong>che sappiamo di mettere in atto, ma che crediamo non abbiano nulla a che fare con l\u2019avanzamento dei nostri progetti o, spesso, crediamo di fare la cosa giusta e che questi comportamenti siano utili. Scoprire questi ostacoli invisibili e risolverli pu\u00f2 accelerare notevolmente il completamento dei progetti.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Un esempio pratico<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

L\u2019effetto del multitasking<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Consideriamo un semplice esempio con tre progetti, ognuno dei quali richiede nove giorni per essere eseguito dall\u2019inizio alla fine. Se lavorassimo su di loro in sequenza, senza fare multitasking, il primo progetto verrebbe completato al nono giorno, il secondo al diciottesimo e il terzo al ventisettesimo giorno. Nella realt\u00e0, la maggior parte delle persone \u00e8 chiamata a fare multitasking. Per esempio, se dopo aver completato solo un terzo del primo progetto (tre giorni) fossimo chiamati a iniziare a lavorare sul secondo progetto e, dopo aver completato un terzo di questo, si venisse dirottati a lavorare sul terzo, dopo nove giorni avremmo completato solo un terzo di ogni progetto senza avere nulla da consegnare. Dopo 18 giorni, avremmo completato due terzi di ogni progetto, continuando a non avere nessun \u2018finito\u2019 da consegnare. Si fa notare che se si fosse lavorato sui progetti uno alla volta, a questo punto avremmo completato gi\u00e0 due di essi. Continuando a fare multitasking in questo modo, il primo progetto non sar\u00e0 completato prima di 21 giorni.<\/p>\n\n\n\n

<\/div>\n\n\n\n

In realt\u00e0, quanti di noi si destreggiano solamente tra tre progetti alla volta? Si crede che il multitasking ci aiuti a progredire su pi\u00f9 progetti, ma non si ha la consapevolezza del prezzo elevato che viene pagato in termini di tempo. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt diceva che il multitasking \u00e8 il principale killer del tempo nella gestione dei progetti. <\/strong>Nella maggior parte degli ambienti multiprogetto questo elemento invisibile \u00e8 una delle cause principali dei ritardi. Sebbene possa sembrare che il multitasking sia inevitabile, se vogliamo accelerare in modo significativo il completamento di un progetto dobbiamo controllare il numero di progetti aperti contemporaneamente e ridurre al minimo<\/strong> il multitasking tra di essi.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Riprendere il controllo sul completamento dei progetti<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Il controllo del numero di progetti a cui si lavora in parallelo non va preso alla leggera. Ci si deve assicurare di non lavorare su un numero troppo basso di progetti, perch\u00e9 ci\u00f2 comporterebbe uno spreco di risorse e una perdita di potenziali ricavi. Ma allo stesso tempo si deve stare attenti a non lavorare su troppi progetti, perch\u00e9 il multitasking causer\u00e0 inevitabilmente interruzioni e aumenter\u00e0 i tempi di esecuzione. In molti ambienti di progetto i manager sanno pi\u00f9 o meno qual \u00e8 la capacit\u00e0 del loro sistema e su quanti progetti dovrebbero lavorare in parallelo per massimizzare le prestazioni. In altri ambienti, i manager hanno un\u2019intuizione sufficiente per capirlo in modo relativamente veloce.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Per iniziare, \u00e8 necessario congelare alcuni progetti;<\/strong> se si nota un eccesso di capacit\u00e0 libera, \u00e8 possibile avviare altri progetti; se invece il multitasking \u00e8 ancora eccessivo si devono congelare altri progetti.\u00a0<\/p>\n\n\n\n

Per i sistemi pi\u00f9 complessi, dove \u00e8 necessario monitorare pi\u00f9 da vicino il numero di progetti attivi, la Toc offre un\u2019eccellente tecnica chiamata drum-buffer-rope<\/em>, la cui spiegazione esula dallo scopo di questo articolo. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Quando si decide di tenere in controllo il numero di progetti attivi su cui si lavora in parallelo, \u00e8 necessario proteggere la propria produttivit\u00e0. Ci si deve assicurare di completare tutti i progetti aperti il pi\u00f9 velocemente possibile. Non \u00e8 possibile tollerare ritardi inutili. Pertanto, si debbono identificare tutti gli altri elementi invisibili che consumano i buffer<\/em> di tempo. Nella maggior parte degli ambienti multiprogetto, non si tratta di un numero infinito di ostacoli al flusso che devono essere affrontati, ma piuttosto di tre-cinque ostacoli principali.<\/p>\n\n\n\n

<\/div>\n\n\n\n

\u201cNon possiamo procedere perch\u00e9 manca qualcosa di essenziale\u201d<\/em>. Avete mai sentito questa frase? Si tratta di un\u2019altra ragione molto comune che determina ritardi nei progetti. Pu\u00f2 capitare che le persone preparino tutto il materiale ma rimangano bloccate in attesa di una conferma o di un\u2019autorizzazione. Oppure tutto \u00e8 pronto, tranne una risorsa che \u00e8 impegnata altrove, ecc.\u00a0<\/p>\n\n\n\n

<\/div>\n\n\n\n

La convinzione di poter iniziare a lavorare sui progetti anche se ci manca qualcosa, e di raccogliere tutto ci\u00f2 che serve man mano che si procede, \u00e8 un altro comportamento comune che \u00e8 allo stesso tempo un ostacolo molto importante al flusso dei progetti. Anche in questo caso, siamo tutti consapevoli di questo comportamento, ma ci\u00f2 che non sappiamo \u00e8 quanto sia negativo per un rapido completamento dei progetti. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Per evitare questi ritardi, dobbiamo assicurarci di avere il\u00a0full-kit<\/strong><\/em>\u00a0prima di iniziare qualsiasi parte importante del progetto. Ci\u00f2 significa verificare di avere a disposizione tutti i materiali, le persone, le autorizzazioni, le risorse e tutto ci\u00f2 di cui si ha bisogno per completare il progetto. Se viene a mancare diligenza nel gestire il\u00a0full-kit<\/em>, il rischio di rimanere bloccati a met\u00e0 progetto, in attesa di cose essenziali, \u00e8 molto concreto. Quando ci si ritrova bloccati, per evitare di rimanere inattivi, si inizia a fare multitasking e il caos ritorna. Gestire scrupolosamente i\u00a0full-kit<\/em>\u00a0prima di iniziare un progetto (o parti importanti di esso) \u00e8 una delle regole principali del flusso e un modo efficace per accelerare il passo e garantire che i progetti siano completati in tempo.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Il multitasking e la mancanza di full-kit<\/em> sono due degli ostacoli comuni radicati nel nostro modo di gestire i progetti, che portano a ritardi significativi, ma non sono gli unici. Anche la mancanza di sincronizzazione o di standardizzazione, le rilavorazioni e altre ragioni legate al settore specifico possono causare ritardi. Questi problemi non hanno nulla a che fare con l\u2019incertezza. In effetti, di solito, si cerca di anticiparli.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Sulle spalle dei giganti<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Gli anni passarono e Goldratt continu\u00f2 a sviluppare la Teoria dei vincoli e a scrivere altri libri, mentre indagava il concetto del flusso. Ogni volta che parlava dei suoi libri, diceva che un giorno avrebbe rimpiazzato Critical chain<\/em>; lo avrebbe riscritto per introdurre le sue nuove intuizioni. Nel 2008 ha scritto il suo articolo, Sulle spalle dei giganti<\/em>, per celebrare il 25esimo anniversario de L\u2019obiettivo<\/em>. Questo articolo illustra le origini della focalizzazione su un flusso pi\u00f9 veloce per migliorare le performance nelle organizzazioni.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Pi\u00f9 o meno nello stesso periodo, pubblic\u00f2 l\u2019analisi strategica e tattica del Project management, il suo lavoro pi\u00f9 completo sull\u2019argomento. Sebbene si trattasse principalmente di Ccpm, le due principali Regole del flusso, ovvero limitare il numero di progetti in corso (controllo del Work in progress, Wip) e il full-kit<\/em>, svolgevano gi\u00e0 un ruolo chiave nel processo.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Erano oramai in molti a chiedergli se fosse finalmente arrivato il momento di riscrivere Critical chain<\/em>. La sua risposta fu che era impegnato a scrivere un altro libro, e in effetti lo era, ma il vero motivo era che sentiva di non aver ancora finito di approfondire le Regole del flusso e doveva accertarsi che la loro applicazione avrebbe effettivamente contribuito a ridurre i tempi di esecuzione dei progetti al punto che non avrebbe avuto pi\u00f9 bisogno di raccomandare l\u2019uso dei buffer<\/em> per questo.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Avrebbe avuto bisogno di un po\u2019 di tempo in pi\u00f9, ma sfortunatamente non lo ebbe. Dopo la sua scomparsa nel 2011, il suo lavoro \u00e8 stato portato avanti dagli esperti della Teoria dei vincoli di Goldratt Consulting e dai loro associati.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Dopo oltre un decennio di implementazioni di grande successo delle Regole del flusso, e 25 anni dopo la pubblicazione di Critical chain<\/em>, \u00e8 stato pubblicato il libro Le Regole del flusso di Goldratt <\/em>a cura <\/em>dottoressa Efrat Goldratt-Ashlag, sua figlia. \u00c8 un libro completamente nuovo che rende omaggio all\u2019originale.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Le Regole del flusso sono un nuovo approccio che vale la pena approfondire, soprattutto perch\u00e9 pretendono di essere una svolta decisiva per affrontare e risolvere i punti critici del Project management, sia per progetti singoli sia in ambienti multiprogetto.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Se siete decisi ad accelerare il flusso dei vostri progetti e a evitare di non rispettare le scadenze, la raccomandazione \u00e8 quella di applicare le Regole del flusso adatte al vostro ambiente di progetto, un modo efficace per gestire le vostre Operation. Utilizzando il Buffer management, potrete proteggere i vostri progetti da ritardi imprevisti, identificare le cause invisibili dei ritardi e affrontarle efficacemente.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Un esempio pratico<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

(nota dei traduttori)<\/em><\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Le diverse regole presentate nel libro Le Regole del flusso<\/em> di Goldratt e le tecniche della Critical chain hanno svolto un ruolo fondamentale nell\u2019affrontare molti progetti critici in tutto il mondo. Nella nostra esperienza, per esempio, hanno fatto la differenza per riportare dal caos a una situazione di flusso il pi\u00f9 grande programma globale di Digital sales. <\/p>\n\n\n\n

<\/div>\n\n\n\n

L\u2019obiettivo<\/em> del progetto era quello di digitalizzare il processo di Configure-price-quote (Cpq) di prodotti complessi e personalizzati, commercializzati da un importante operatore del settore dell\u2019automazione industriale. Prima dell\u2019adozione delle Regole del flusso, il progetto soffriva di tutti i sintomi negativi dei flussi non gestiti: mancanza di controllo sulle specifiche e sui requisiti critici; carico di lavoro delle risorse non visibile e vincoli non gestiti; spreco del tempo prezioso degli esperti in attivit\u00e0 emergenziali di fire-fighting<\/em>; eccessivo multitasking per gestire ci\u00f2 che stava andando in ritardo e ci\u00f2 che si doveva incominciare; date di scadenza non rispettate.<\/p>\n\n\n\n

<\/div>\n\n\n\n

La trasformazione del progetto in un caso di successo \u00e8 avvenuta applicando semplici Regole del flusso. \u00c8 stato introdotto il triage per tenere sotto controllo i requisiti e le specifiche: il triage \u00e8 stato utilizzato sia per la gestione delle nuove richieste sia per gestire la prioritizzazione dei potenziali difetti. Sono stati poi identificati i vincoli del flusso e si \u00e8 usato il drum-buffer-rope<\/em> per determinare quando immettere nuovo lavoro nel sistema per sfruttare al massimo la produttivit\u00e0 dei vincoli. \u00c8 stata quindi applicata la segregazione tra i team per concentrare i subject matter expert<\/em> sugli elementi pi\u00f9 complessi e critici, mentre le richieste semplici sono state affidate a ingegneri meno esperti. Il full-kit<\/em> \u00e8 stato esteso per includere il collaudo, per evitare attivit\u00e0 di test stop-and-go<\/em> e ridurre la scarsa qualit\u00e0.<\/p>\n\n\n\n

<\/div>\n\n\n\n

La corretta applicazione di queste regole ha trasformato un progetto che sin dall\u2019inizio non aveva rispettato alcuna milestone<\/em> in un perfetto \u2018orologio svizzero\u2019 che ha poi saputo rispettare tutte le scadenze. E con un ulteriore beneficio nascosto: il progetto ha risparmiato circa il 30% delle risorse e dei costi.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Bibliografia<\/strong><\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt-Ashlag, Efrat, Goldratt\u2019s Rules of Flow, The North River Press (2022) Goldratt-Ashlag, Efrat, Le Regole del flusso di Goldratt, Rgroup\u00e9 (2025)<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt, Rami., Kapoor, Ajai, Mastering Flow: Implementation Guidebook for Goldratt\u2019s Rules of Flow in Project Environments, The North River Press (2025)<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt, Eliyahu M., Critical chain, The North River Press (1997)<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt, Eliyahu M., What is Toc? My Perspective, in The Theory of Constraints Handbook, McGraw Hill (2010)<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt, Eliyahu M., Standing on the Shoulders of Giants. Questo articolo \u00e8 stato pubblicato originariamente nel numero di dicembre 2008 di Diamond Weekly, Giappone. \u00c8 stato aggiunto a The Goal nell\u2019edizione del 30\u00b0 anniversario in Goldratt, Eliyahu M., Cox, Jeff, The Goal: A Process of Ongoing Improvement, edizione del 30\u00b0 anniversario, North River Press (2014)<\/p>\n\n\n\n

<\/div>\n\n\n\n

Goldratt, Eliyahu M., Cox, Jeff, L\u2019obiettivo: un processo di miglioramento continuo, North River Press (1992)<\/p>\n","protected":false},"template":"","meta":{"_acf_changed":false},"acf":[],"_links":{"self":[{"href":"https:\/\/eccellenzedimpresa.it\/el\/wp-json\/wp\/v2\/cp_magazine\/3844"}],"collection":[{"href":"https:\/\/eccellenzedimpresa.it\/el\/wp-json\/wp\/v2\/cp_magazine"}],"about":[{"href":"https:\/\/eccellenzedimpresa.it\/el\/wp-json\/wp\/v2\/types\/cp_magazine"}],"wp:attachment":[{"href":"https:\/\/eccellenzedimpresa.it\/el\/wp-json\/wp\/v2\/media?parent=3844"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}