Last Planner System: non risolve i problemi di flusso, li rende visibili

Era un mercoledì mattina, riunione di lookahead, sala riunioni affollata di responsabili di fronte e coordinatori di subappaltatori. Sul monitor scorreva un programma a tre settimane aggiornato il giorno prima. Tutti annuivano. Nessuno faceva domande. Alla fine il planning manager chiuse la presentazione con un “ok, ci aggiorniamo la prossima settimana” che aveva il suono di una liturgia consumata.

Il mercoledì successivo, due fronti si erano fermati per problemi che erano già visibili in quella riunione — materiali non ancora ordinati, un’interferenza con le lavorazioni civili che nessuno aveva ancora formalizzato. Il programma li aveva registrati. Nessuno li aveva rimossi.

Questo è il problema che vedo più spesso nei cantieri che adottano il Last Planner System: il sistema funziona, nel senso che produce i documenti giusti. Ma viene usato come strumento di condivisione del piano, non come strumento di azione sui vincoli. E quella differenza cambia completamente il risultato finale.

Il LPS non è uno scheduler avanzato

Prima di entrare nel metodo, vale la pena chiarire cosa non è il Last Planner System. Non è un software. Non è un formato di riunione. Non è nemmeno un modo più collaborativo di fare il Gantt.

Il LPS è un sistema di impegni condivisi costruito su una premessa precisa: il piano a lungo termine è necessariamente incerto, e l’incertezza si riduce avvicinandosi all’esecuzione solo se qualcuno lavora attivamente per rimuovere i vincoli che la generano. La struttura gerarchica del sistema — Master Schedule, Phase Schedule, Lookahead, Weekly Work Plan — non è una complicazione burocratica. È la risposta a un problema reale: i piani vengono prodotti a livelli di dettaglio che non corrispondono al livello a cui vengono eseguiti.

Nei cantieri complessi — più fronti attivi, subappaltatori sovrapposti, sequenze rigide per interferenze o requisiti di sicurezza — questo disallineamento ha un costo misurabile. La lookahead a tre-sei settimane esiste esattamente per colmare quel gap: trasformare attività ancora vincolate in attività pronte all’esecuzione. Se la lookahead viene usata solo per mostrare cosa è pianificato, si perde il suo valore operativo.

La lookahead come strumento di constraint removal

Il cuore operativo del LPS sta nel processo di analisi dei vincoli che accompagna la costruzione della lookahead. Ogni attività che compare nella finestra di tre-sei settimane dovrebbe essere esaminata rispetto a una checklist di precondizioni: materiali disponibili, attrezzature prenotate, fronte fisicamente libero, manodopera qualificata disponibile, documentazione tecnica approvata, autorizzazioni ottenute.

Il passaggio che distingue un’applicazione matura da una formale è questo: ogni vincolo identificato non viene solo registrato, viene assegnato. Un owner nominato, una data di risoluzione attesa, uno stato aggiornato a ogni ciclo. Il constraint log smette di essere un elenco di cose note e diventa uno strumento di responsabilizzazione.

Owner nominato, non responsabilità collettiva. “Lo vediamo insieme” non funziona. Se un vincolo non ha un nome sopra, non ha nessuno che risponde della sua eliminazione. Nei cantieri dove questo processo è strutturato, ogni voce aperta nel constraint log ha un nome — e quel nome compare in riunione a riferire sullo stato.

Data di risoluzione, non “in lavorazione”. Un vincolo con stato “in corso” è un vincolo invisibile. Serve una data entro la quale il vincolo sarà eliminato — e se quella data non viene rispettata, l’attività esce dal piano settimanale.

Escalation esplicita. Quando un vincolo non si riesce a rimuovere a livello operativo, serve un meccanismo formale per portarlo al livello decisionale superiore. Questo non è fallimento del sistema: è il sistema che funziona. Il problema è quando i vincoli restano bloccati a livello operativo senza che nessuno intervenga.

PPC come segnale, non come obiettivo

Il Percent Plan Complete — la percentuale di attività completate rispetto a quelle pianificate nel weekly work plan — è la metrica principale del LPS. E come tutte le metriche, può essere usata bene o usata per produrre numeri confortanti.

Un PPC alto ottenuto abbassando il livello di impegno settimanale non misura niente di utile. Un PPC basso analizzato per capire le cause di mancato completamento è uno strumento di miglioramento. La differenza sta nell’uso che si fa dei dati.

Le cause di mancato completamento dovrebbero essere categorizzate — vincolo non rimosso, problema tecnico imprevisto, problema di subappaltatore, interferenza esterna — e tracciate nel tempo. Se la categoria “vincolo non rimosso” appare sistematicamente, significa che il processo di constraint removal non funziona. Se appare “problema imprevisto” con alta frequenza, significa che la lookahead non sta identificando i rischi in anticipo.

Questo è il tipo di analisi che trasforma il LPS da sistema di pianificazione a sistema di apprendimento organizzativo. Ne ho scritto in modo più esteso ragionando su quando il planning diventa teatro: il rischio è sempre quello di produrre documenti invece di prendere decisioni.

L’integrazione con il TAKT Planning

In cantieri dove il flusso di lavoro è strutturato per zone — tipico nelle gallerie, nelle stazioni metropolitane, nei viadotti ripetuti — il LPS e il TAKT Planning non sono sistemi alternativi. Sono complementari, e usarli insieme aumenta significativamente la capacità previsionale del team.

Il TAKT definisce il ritmo: ogni zona avanza in un tempo predeterminato, le squadre si muovono in sequenza, il flusso è continuo. Ma il ritmo TAKT si interrompe se una zona non è pronta quando la squadra arriva. La lookahead del LPS diventa lo strumento per proteggere quella readiness: ogni zona che entra nella finestra di tre settimane deve avere tutti i vincoli rimossi prima che la squadra vi acceda.

In questo schema, il constraint log non è solo un documento interno al team di planning. Diventa l’interfaccia tra il livello di progettazione del flusso e il livello di esecuzione quotidiana. I subappaltatori che lavorano in sequenza hanno un interesse diretto nel rimuovere i propri vincoli in tempo — perché il ritardo di uno impatta l’ingresso del successivo.

Questo collegamento tra LPS e TAKT rafforza anche la responsabilizzazione del caposquadra, che smette di essere un esecutore di ordini dall’alto e diventa il presidio reale del piano settimanale. Su questo tema vale la pena rileggere il caposquadra come fulcro del Last Planner System: il sistema non regge se chi sta in cantiere non è coinvolto nella costruzione del piano a breve termine.

Cosa cambia quando il sistema funziona davvero

Quando il LPS viene applicato con rigore — lookahead costruita con i responsabili di fronte, constraint log aggiornato e assegnato, PPC analizzato per cause e non solo misurato — si producono alcuni effetti concreti che vale la pena nominare.

Le sorprese diminuiscono. Non scompaiono, ma la quota di problemi che emergono a ridosso dell’esecuzione si riduce. I vincoli vengono identificati con settimane di anticipo, quando c’è ancora tempo per rimuoverli.

Le riunioni cambiano contenuto. Si passa dal “ecco cosa faremo” al “ecco cosa blocca il piano e chi lo risolve”. È un cambiamento culturale non banale, e richiede che il project manager o il planning manager lo pretenda esplicitamente.

La comunicazione con i subappaltatori diventa strutturata. Le interferenze, le dipendenze, i vincoli condivisi hanno un luogo formale dove vengono discussi — non nelle chiamate di emergenza, ma nella riunione settimanale con tre settimane di anticipo.

Il programma master smette di essere solo un documento contrattuale. Diventa qualcosa che le persone guardano e usano, perché il livello operativo è collegato ad esso in modo esplicito.

Il Last Planner System non pianifica al posto tuo. Ti obbliga a pianificare meglio — e a rispondere quando non lo fai. La differenza tra i cantieri dove funziona e quelli dove è diventato una formalità sta quasi sempre in un solo punto: qualcuno ha deciso che i vincoli aperti non erano accettabili, e ha costruito il processo per eliminarli.

Nella tua esperienza, il constraint log viene aggiornato con owner e date di scadenza reali, o tende a diventare un elenco di problemi noti che nessuno ha la responsabilità di risolvere?