Schedule recovery: perché il programma non si recupera a mano

Era un mercoledì mattina come tanti. Il programma aveva perso undici giorni in tre settimane: una consegna di materiali slittata, un fronte liberato tardi, una squadra di un subappaltatore che aveva perso rendimento per motivi mai del tutto chiariti. Undici giorni non sono una catastrofe. Ma sommati su un percorso critico già tirato, erano diventati un problema serio.

Il planner aveva aggiornato il programma. Aveva ridistribuito le risorse, anticipato alcune lavorazioni, cercato di assorbire i giorni persi. Era una buona soluzione. Probabilmente l’unica soluzione che chiunque in quella stanza avrebbe potuto costruire in quel momento. Il problema era che nessuno poteva dire se fosse la migliore soluzione, o anche solo una delle migliori.

Questo è il punto cieco del recovery planning tradizionale. Non che manchi la competenza. È che le variabili da gestire simultaneamente sono troppe per essere ottimizzate a mano.

Come si inceppa davvero un programma

Raramente un progetto si ferma per una causa singola e grave. Si inceppa per accumulo: dieci piccole cose che vanno storte quasi nello stesso momento, in modo che i loro effetti si sommano invece di compensarsi.

Una consegna che slitta di tre giorni non sposta nulla da sola. Ma se in quella stessa settimana un’area di lavoro si libera tardi, una squadra perde due punti di rendimento e un subappaltatore ha un problema interno, il risultato è uno scostamento che sulle attività critiche non è più assorbibile con semplici aggiustamenti di sequenza.

Il meccanismo è noto. Quello che spesso si sottovaluta è la natura combinatoria del problema quando si tenta di recuperare. Su un cantiere con centinaia di attività interdipendenti, vincoli di spazio condivisi tra lavorazioni diverse e subappaltatori con proprie logiche produttive, ogni modifica al programma genera effetti a cascata. Anticipare un’attività libera un fronte ma crea interferenza con un’altra lavorazione. Aggiungere risorse su un percorso critico migliora la velocità ma cambia il profilo dei costi e può violare vincoli contrattuali con i subappaltatori.

Il planner deve inseguire questi effetti uno per uno, costruendo a mano uno scenario che tiene tutto insieme. È un lavoro fatto bene, spesso molto bene. Ma produce uno scenario, non un confronto tra scenari.

La differenza tra correggere e simulare

La schedulazione generativa parte da un’angolazione diversa rispetto all’aggiornamento manuale del programma.

Invece di prendere il programma vigente e cercare di correggerne i problemi, un motore generativo esplora sistematicamente lo spazio delle soluzioni possibili: simula milioni di combinazioni di sequenza, allocazione delle risorse e ordine delle lavorazioni per trovare quelle che rispettano tutti i vincoli dati — fisici, contrattuali, di produttività — ottimizzando rispetto all’obiettivo definito (data di completamento, costo, combinazione dei due).

Non è uno strumento di reporting. Non produce una baseline più bella da mostrare in un meeting. Produce un insieme di alternative comparabili, con i relativi trade-off esplicitati.

In termini pratici, la differenza si sente su tre livelli.

Velocità dell’analisi. Costruire a mano tre scenari di recovery realistici su un programma complesso può richiedere giorni. Un motore generativo li produce in ore, o meno. Questo non è un vantaggio di comfort: è un vantaggio decisionale. Significa che l’analisi può avvenire prima che il ritardo si consolidi, non dopo.

Qualità del confronto. Quando hai un solo scenario, la discussione è binaria: lo approvi o non lo approvi. Quando hai cinque scenari con costi e date diverse, la discussione diventa strategica: quale trade-off è accettabile per il progetto? Questa è la conversazione che dovrebbe avvenire in ogni sessione di recovery planning, e raramente avviene perché manca il materiale su cui farla.

Trasparenza sui vincoli. Un motore generativo rende visibili i vincoli che rendono certi scenari impossibili. Se non esiste combinazione di risorse che permette di recuperare i giorni persi entro una certa data, il sistema lo dice esplicitamente — e questo è un’informazione contrattuale rilevante, non solo pianificatoria.

Il ruolo del planner non sparisce: cambia

È il momento di essere precisi su cosa la schedulazione generativa non fa, perché il rischio di fraintendimento è reale.

Un motore generativo non conosce il cantiere. Non sa che quella squadra di cassaristi in realtà rende il venti percento in meno di quanto dice il programma. Non sa che quel subappaltatore ha un problema di liquidità che lo renderà lento nelle prossime settimane. Non sa che quella clausola contrattuale impedisce di anticipare certe lavorazioni senza accordo scritto.

Queste informazioni devono entrare come vincoli e parametri. Chi le inserisce, e chi valuta se il risultato è realistico, è ancora il planner — con la sua esperienza, la sua conoscenza del cantiere, la sua capacità di leggere le situazioni che non compaiono su nessun software.

Quello che cambia è la natura del lavoro. Il planner smette di essere il costruttore manuale dell’unico scenario possibile e diventa il valutatore critico di scenari generati algoritmicamente. È un ruolo con più leva, non con meno responsabilità.

Su questo punto vale la pena richiamare anche il rapporto con il Last Planner System: la schedulazione generativa opera a un livello di aggregazione diverso rispetto alla pianificazione settimanale collaborativa. Non la sostituisce. La supporta a monte, producendo un quadro di medio periodo che il team può poi dettagliare con il metodo lean.

I vincoli contrattuali che il programma deve rispettare

C’è un aspetto del recovery planning che nelle discussioni sulla tecnologia rimane spesso sullo sfondo, e invece è centrale: i vincoli contrattuali.

Su progetti infrastrutturali complessi, il programma non è solo uno strumento di gestione interna. È un documento contrattuale, con implicazioni su penali, notice, claim e diritti di accelerazione.

I milestone contrattuali sono fissi. Un’analisi di recovery che li ignora produce scenari tecnicamente coerenti ma contrattualmente inutilizzabili. I parametri del motore generativo devono includere questi vincoli come hard constraint, non come obiettivi da ottimizzare.

Le modifiche alla sequenza possono violare obblighi verso i subappaltatori. Anticipare o posticipare lavorazioni cambia le condizioni di accesso al fronte per i subappaltatori. Questo può generare claim se non gestito con gli strumenti contrattuali appropriati — e su questo le clausole del contratto di subappalto contano enormemente.

Il programma aggiornato è parte del record documentale. In caso di dispute, la sequenza delle revisioni del programma racconta come il contractor ha gestito i problemi. Un recovery plan costruito in modo sistematico e documentato vale più di uno costruito in emergenza su un foglio di calcolo.

Perché continuiamo a usare gli stessi strumenti

La domanda pratica è perché, di fronte a un problema strutturale noto, il recovery planning in larga parte dei cantieri rimanga ancora un processo manuale.

Le ragioni sono più semplici di quanto sembri. Gli strumenti generativi richiedono dati di input strutturati e affidabili — produttività reale per lavorazione, vincoli fisici codificati, disponibilità delle risorse aggiornata. Su molti cantieri questi dati non esistono in forma utilizzabile da un algoritmo. Esistono nella testa dei responsabili di produzione, in fogli Excel non standardizzati, in email sparse.

Il problema non è tecnologico: è di qualità del dato. E questo rimanda a una questione più ampia, che riguarda come si raccolgono e strutturano le informazioni di cantiere fin dalla fase di impostazione del progetto — un tema che tocca direttamente il ruolo del project control fin dalla preconstruction.

Il secondo ostacolo è culturale. Il recovery planning è vissuto come un’attività di emergenza, da fare in fretta sotto pressione. Investire in un processo più strutturato — raccogliere i dati, codificare i vincoli, impostare lo strumento — sembra incompatibile con l’urgenza percepita. È un’inversione di priorità difficile da fare nel mezzo di un problema.

Eppure è esattamente il momento in cui la qualità del processo fa la differenza tra un recupero reale e uno spostamento del problema di qualche settimana.

Gestire la schedule recovery con gli stessi strumenti di vent’anni fa non è un errore di competenza. È un limite di metodo che la tecnologia disponibile oggi permette di superare — a condizione di investire nell’infrastruttura di dati che lo rende possibile.

Come gestisci oggi la ripianificazione quando il programma scosta in modo significativo? È ancora un processo prevalentemente manuale, o hai già introdotto approcci più strutturati?