Il caposquadra è il fulcro del Last Planner System — non il software

In un cantiere AV/AC su cui ho lavorato, i Weekly Work Plan erano precisi, il PPC veniva misurato ogni settimana, le riunioni di pull planning si tenevano regolarmente. Eppure il flusso si inceppava sempre nello stesso punto. I fronti avanzavano a singhiozzo, i constraint emergevano solo quando erano già diventati ritardi, e il construction manager passava le giornate a spegnere incendi che, a guardare il lookahead, non avrebbero dovuto esistere.

Il problema non era il piano. Era dove il piano finiva.

Finiva sulla scrivania del caposquadra — già fatto, già deciso, già consegnato da eseguire. E lì si fermava.

Il caposquadra non è un destinatario, è una fonte

Nel Last Planner System, il nome non è casuale: il last planner è letteralmente l’ultimo pianificatore della catena, cioè chi assegna il lavoro in modo diretto alle squadre. In teoria, è il cuore del sistema. In pratica, in molti cantieri infrastrutturali viene trattato come l’ultimo ricevente — quello a cui si comunica cosa fare, non quello che contribuisce a decidere come farlo.

Il paradosso è evidente: il caposquadra è la figura che conosce meglio la realtà operativa. Sa che una determinata sequenza funziona solo con un certo numero di operai in spazio confinato. Sa che il fornitore di calcestruzzo arriva sempre in ritardo il lunedì mattina. Sa che tra due attività apparentemente consecutive c’è un’interferenza che il programma non registra. Queste informazioni — se non entrano nel lookahead — si trasformano in varianze che si scopriranno solo a consuntivo.

Il Lean Construction funziona quando il caposquadra entra nel processo di pianificazione, non quando lo riceve.

Come si integra il caposquadra nel lookahead: tre pratiche operative

Parlare di “coinvolgimento” rischia di restare vago. Nella pratica, ci sono modi concreti per strutturare questa integrazione senza stravolgere l’organizzazione del cantiere.

Prima: il caposquadra partecipa alla sessione di constraint analysis del lookahead a 3-6 settimane. Non all’intera riunione di pianificazione — che spesso ha un livello di astrazione che non gli appartiene — ma alla parte in cui si identificano i vincoli che potrebbero bloccare le attività previste. Logistica di approvvigionamento, disponibilità di attrezzatura, sequenze dipendenti da altri fronti: su tutto questo, il caposquadra ha informazioni di prima mano che il project engineer, per quanto preparato, non può avere seduto in ufficio.

Secondo: le sue segnalazioni vengono registrate come constraint formali, non come feedback informale. Questo è un passaggio culturale importante quanto quello tecnico. Se il caposquadra dice “quella lavorazione non si fa in tre giorni, ne servono cinque” e questa informazione non entra nel piano aggiornato, il messaggio implicito è che la sua voce non conta. Se invece viene registrata nel constraint log e diventa input per la revisione del lookahead, il ciclo di fiducia si costruisce.

Terzo: il PPC viene discusso con lui, non solo calcolato sopra di lui. Il Percent Plan Complete misura quante attività pianificate vengono completate. Ma se chi ha eseguito le attività non partecipa all’analisi delle cause di scostamento, il PPC resta un indicatore di controllo anziché uno strumento di apprendimento. La domanda “perché questa attività non è stata completata?” ha risposte molto diverse a seconda di chi la pone — e chi lavora sul fronte spesso ha la risposta più utile.

Cosa cambia per il construction manager

Quando il caposquadra entra davvero nel processo, il ruolo del construction manager — e del project engineer — si trasforma in modo tangibile.

Il CM smette di fare firefighting e inizia a fare gestione predittiva. I constraint che prima emergevano come emergenze operative arrivano ora con tre o quattro settimane di anticipo, in tempo per essere rimossi: un’autorizzazione da sollecitare, un subappaltatore da anticipare, un problema di interferenza da risolvere prima che blocchi il fronte. Questo non è un cambiamento marginale di efficienza: è la differenza tra un progetto che si gestisce e un progetto che gestisce te.

C’è anche un effetto collaterale che riguarda la qualità delle decisioni contrattuali. In un contesto con subappaltatori numerosi — come nelle grandi infrastrutture — i ritardi di flusso si trasformano spesso in claim. Avere un sistema in cui i vincoli vengono identificati in anticipo e documentati formalmente costruisce una base di evidenza molto più solida per la gestione degli imprevisti. Non è un caso che i cantieri con una cultura Lean più matura tendano ad avere meno dispute aperte a fine progetto.

Se vuoi approfondire il rapporto tra pianificazione e gestione dei claim, ho scritto su questo in Un claim non è un conflitto: è uno strumento di riequilibrio.

La dimensione relazionale che i manuali non descrivono

C’è un aspetto del coinvolgimento del caposquadra che nei libri sul Last Planner System viene citato ma raramente approfondito: richiede da parte del management una forma di apertura che nei cantieri tradizionali non è affatto scontata.

Coinvolgere il caposquadra nella pianificazione significa, in modo esplicito o implicito, riconoscere che il programma non contiene tutta la realtà. Significa dire: “Il tuo sapere operativo vale più della stima che abbiamo fatto in ufficio.” In Lean si usa l’espressione vulnerability-based trust — la disponibilità a mostrare i limiti del proprio punto di vista per ricevere informazioni che altrimenti resterebbero bloccate in basso nella gerarchia.

Non è una concessione sentimentale. È una scelta di efficienza. Nei cantieri in cui questa apertura non c’è, le informazioni critiche salgono la catena di comando solo quando è troppo tardi per agire su di esse — e finiscono sui rapporti di avanzamento come varianze da spiegare, non come segnali da intercettare.

Il problema è che questa cultura non si decreta. Si costruisce attraverso episodi ripetuti in cui la segnalazione del caposquadra viene ascoltata, registrata, e — quando ha ragione — riconosciuta pubblicamente come tale. È un processo lento, ma non esiste scorciatoia.

Il nodo che decide tutto

Il Last Planner System, il TAKT Planning, i pull planning meeting: sono strumenti potenti. Ma tutti presuppongono che le informazioni reali del cantiere entrino nel sistema di pianificazione con continuità e tempestività. E l’unica figura che può garantire questo flusso — perché è l’unica che si trova all’intersezione tra il piano e l’esecuzione — è il caposquadra.

Investire in software di scheduling, in dashboard di project control, in sessioni di pianificazione sempre più sofisticate ha senso. Ma se il nodo tra il lookahead e il cantiere reale rimane passivo, quegli investimenti producono piani sempre più accurati che si confrontano con una realtà che non riescono a rappresentare. Il risultato è un planning che somiglia sempre di più a un teatro — e su questo vale la pena rileggere Quando il planning diventa teatro — e come pianificare davvero.

La qualità di un sistema Lean si misura da quanto è robusto il suo anello più debole. In quasi tutti i cantieri che ho visto, quell’anello è il passaggio tra il plan e chi lo esegue.

Nel tuo cantiere, il caposquadra partecipa alla constraint analysis del lookahead, o riceve il piano già definito? E quando viene coinvolto in anticipo, cosa cambia concretamente nel flusso del lavoro?