I 7 Muda del BIM

La frenesia del contesto attuale ci porta ad un sovraffollamento di informazioni tale da rimanere, talvolta, senza alcuna informazione utile. Si ascoltano podcast, guardano webinar, scrollano notizie, tutto alla velocità della luce. Un pregio, la quarantena delle settimane scorse l'ha pure avuto: la possibilità di leggere. Leggere per davvero, non guardare una riga si e due no, come ormai siamo abituati a fare: per capire, per apprendere, per farsi un'opinione.

Tra le varie, segnalo due libri di grande attualità e interesse: "Fare il doppio nella metà del tempo" di J.Sutherland, testo discorsivo e piacevole sulla genesi e definizione di Scrum, e "Lo spirito Toyota" di Taiichi Ohno, volume un po' più tecnico ma mai barocco (beh, stiamo pur sempre parlando di un ingegnere. Giapponese). Se Scrum sta coinvolgendo molti professionisti del BIM, anche a ragione, rimango convinto che l'esempio di Toyota possa comunque rimanere un riferimento importante, non solo per il mondo dell'industria.

Ovvio, stiamo mischiando concetti legati ad una logica di produzione industriale con altri legati al lavoro intellettuale, non un'antitesi dichiarata ma poco ci manca. Ma, in fondo in fondo, non sono poi così diversi l'uno dall'altro. Teniamo in considerazione che il metodo Toyota è stato studiato ed analizzato molto dal settore delle costruzioni, riproponendo il Just-in-Time e l'ottimizzazione dei processi in quella che viene definita Lean Construction. La filosofia di Ohno per cui occorre "pensare all'inverso", ossia partire dal prodotto e risalire la corrente per definire forniture, processi, tempistiche e risorse, è di fatto alla base di metodi come il Last Planner System, adottato con successo in molti cantieri (più all'estero che da noi, per la verità). Ma possiamo andare oltre: un team di ricerca guidato da Rafael Sacks ha provato addirittura a declinare il kanban nel campo del digitale, coniando il sistema kanBim (per chi fosse interessato, qui il paper scientifico). Esiste insomma un'intera letteratura di articoli, ricerche, casi concreti e proposte che riconoscono nel metodo Toyota una struttura concettuale replicabile nel settore AEC.

Uno dei capitoli di maggior interesse del metodo Toyota è legato all'individuazione (e successiva eliminazione) degli sprechi. Taiichi Ohno ha analizzato a fondo la sua realtà aziendale e ha individuato 7 tipologie diverse, i cosiddetti Muda: sovraproduzione, tempi morti, trasporti e manutenzioni inutili, processi lavorativi inutili o inopportuni, stoccaggio eccessivo, movimenti inutili, produzione di pezzi difettosi. Proviamo a darne una declinazione in ottica BIM.

1. Sovraproduzione. Tradotto: overmodeling e overinformation (concetto già visto, con accezione diversa, in introduzione). Un modello con un livello di definizione geometrica superiore al necessario non è un modello fatto meglio, così come un modello con una dose di contenuti informativi superiore a quelli richiesti non si traduce in un modello migliore. Anzi: avere troppe informazioni richiede sempre più tempo per poterle leggere, analizzare, valutare. I contenuti informativi devono essere mappati, compilati, verificati e validati: potrebbero essere ore preziose sottratte al BIM Coordinator, già alle prese con interferenze, meeting e reportistica. Riguardo le geometrie, bisogna sempre tenere a mente che un LOD elevato comporta ore di modellazione e, in sede di variante o revisione, comporta ancora più ore di modellazione (e probabile ri-editing grafico). Su questo punto è fondamentale pensare sempre all'inverso, ovvero partire dal Capitolato Informativo o dal Piano di Gestione Informativa. Ecco, qui non andiamo benissimo: i numeri dicono che l'80% dei bandi pubblici chiedono il BIM senza allegare Capitolati Informativi...
2. Tempi morti. Le tipologie di tempi morti possono essere molteplici, in parte legate agli strumenti, in parte all'organizzazione del lavoro. Innanzi tutto, è fondamentale adeguare le componenti hardware rispetto ai software che si intendono utilizzare. Le macchine devono essere performanti, altrimenti aumenta il rischio di dimezzare la produttività causa rallentamenti o, peggio, bug improvvisi. Lavorare poi con modelli leggeri, passaggio scontato fino ad un certo punto (i famosi 200 MB dichiarati nei PGI come dimensione massima dei file di lavoro): è fondamentale pensare bene la scomposizione del progetto in parti più piccole, considerando ambiti omogenei come la disciplina di riferimento (architettonica, strutture, impianti...), il corpo di fabbrica, l'autore, il livello ecc... Una volta organizzata la parte strumentale, attenzione all'organizzazione del gruppo di lavoro. Non entreremo nel dettaglio di questo aspetto, perché servirebbe una trattazione apposita; ci limiteremo a dire come la comunicazione sia essenziale per qualsiasi lavoro in team. Deve essere chiaro chi trasferisce informazioni e chi deve recepirle, inoltre devono essere trasferite le informazioni corrette nelle modalità opportune (poche informazioni limitano il raggio d'azione, troppe informazioni riducono l'efficacia di chi deve recepirle). L'ormai noto "chi fa che cosa", cui aggiungere quando e come.
3. Trasporti e manutenzioni inutili. Qui forziamo un po' il passaggio, perché l'accezione originaria è chiaramente relativa agli spostamenti di prodotti o materiali. Se paragonassimo però un modello digitale ad un prodotto, l'analogia diventa più evidente: ridurre al minimo il trasferimento di file, dati e informazioni. Se più professionisti lavorano ad un unico progetto, è bene che lavorino il più possibile in parallelo e possibilmente su un unico file (o ecosistema di file). Capita spesso che si produca un file di lavorazione, ad un certo punto lo si considera quasi definitivo e quindi lo si duplica per permettere ad altri collaboratori di svolgere le proprie attività. Nella maggior parte dei casi, il file viene duplicato così che il singolo operatore possa apportare qualsiasi tipo di modifica senza interferire sulle attività altrui. Risultato? Quasi sempre sopraggiungeranno modifiche in corsa che a) non verranno recepite nei duplicati b) dovranno essere recepite n volte per quanti sono i duplicati. Senza contare il tempo per salvare i file, magari organizzati con link esterni che potrebbero perdersi nel trasferimento da un collaboratore all'altro. Sicuramente richiede uno sforzo, ma investire in piattaforme collaborative o di condivisione dati garantisce vantaggi considerevoli durante lo svolgimento di un progetto, specie se coinvolge molteplici figure. La centralizzazione dei dati è il primo step per favorire trasparenza, efficacia e quindi produttività.
4. Processi lavorativi inutili o inopportuni. Un aspetto sottovalutato nella transizione dalla progettazione CAD 2D al 3D è probabilmente la sostanziale perdita del concetto di scala: disegnare una pianta al 200 o al 50 faceva una certa differenza in termini di ore lavorate, mentre, quando si lavora con il modello, lo si fa praticamente in scala 1:1 in quanto la rappresentazione sugli elaborati può essere gestita in modo parametrico. Capita quindi di vedere piante in scala 1:100 con la rappresentazione di tutte gli strati di un muro (anche la barriera a vapore...), serramenti LOD 500 nei preliminari (tanto c'è già la famiglia...) e così via. Ad oggi non esiste una corrispondenza certa tra fase progettuale ed evoluzione informativa del modello, ma questo non significa saltare i passaggi. Non ha senso rifinire all'estremo modelli ed elaborati per il semplice motivo che la tecnologia lo permette: non si aggiunge valore al progetto e non si tratta di attività ad impatto zero sulla produttività. Qualcosa di simile accade anche con le clash detection in-progress: è vero, prima si individuano le interferenze su un progetto e meglio è, ma è fondamentale che le verifiche vengano fatte su parti di modello consolidate, sia da un punto di vista geometrico che informativo. Si possono spendere ore, giorni, settimane sulla creazione di rulesets più o meno raffinati, ma se poi si danno in pasto modelli approssimativi sarà impossibile distinguere un'interferenza di progetto da un errore di modellazione. Con annesse ripercussioni sulla credibilità del lavoro del BIM Coordinator. Considerazione analoga sull'estrazione delle quantità.
5. Stoccaggio eccessivo. Esiste un detto: non rimandare a domani quello che puoi fare oggi. Vero, ma fino ad un certo punto. Nel galateo, ad esempio, nel momento in cui si programma un appuntamento, è sicuramente maleducazione presentarsi in ritardo; tuttavia, è altrettanto scortese presentarsi in anticipo, perché in entrambi i casi la persona che si presenta puntuale sarà messa a disagio. In produzione vale lo stesso principio: in caso di ritardi sulle consegne si potrebbero avere lamentele (o penali) da parte del committente, tuttavia, nel caso in cui si producesse molto più di quanto richiesto, si potrebbe avere poi difficoltà a vendere quanto prodotto (in sintesi: si sono generate spese per non avere ricavi). Per questo motivo Ohno coniò il concetto di Just-in-Time. Analogamente, se il modello BIM fosse più avanti dell'evoluzione progettuale, i rischi legati alla ri-modellazione informativa aumenterebbero esponenzialmente (tradotto: quello che viene modellato oggi probabilmente sarà ri-modellato domani). Un esempio molto pratico: anticipare la messa in tavola prima di aver coordinato un modello quasi certamente provocherà la perdita, nei successivi aggiornamenti, di quote ed etichette. In caso di revisione delle tavole, al tempo previsto per i commenti progettuali, dovrete aggiungere altro tempo per quotare ed etichettare disegni che già lo erano... Per ogni fase di lavorazione è quindi fondamentale comprendere il reale stato di avanzamento del progetto e proseguire con attività coerenti con lo stato dell'arte, senza anticipare attività che non sono ancora mature per essere eseguite. Su questo punto Scrum propone una metodologia molto convincente: spacchettare sempre i progetti in parti più piccole che producano qualcosa di concreto, verificabile, misurabile. Nel momento in cui le singole parti vengono condivise con il cliente è più facile capire se si sta andando nella direzione giusta; diversamente, è possibile intervenire per tempo riducendo la dispersione di tempo e risorse.
6. Movimenti inutili. Ad oggi siamo in una fase di transizione, è impensabile ottenere tutto e subito. Devono convivere due categorie distinte di professionisti: una prima, composta prevalentemente da figure esperte, che hanno vissuto i cantieri, i progetti, che sono in grado di guardare una struttura e dimensionarla ad occhio, ed una seconda, più giovane, che ha ovviamente più dimestichezza con il digitale ma non ha quel know-how sufficiente per governare a 360° una commessa. Queste figure devono lavorare a stretto contatto, contaminarsi a vicenda, acquisire una il know-how dell'altra e viceversa. Tanti colossi mondiali hanno avviato la loro crescita eliminando le barriere tra i diversi dipartimenti, ad esempio tra progettisti e produzione: allo stesso modo, il digitale oggi non deve costituire un muro di separazione tra "progetto" e "modello". Domani avremo, auspicabilmente, professionisti completi, che governano le leggi della disciplina ingegneristica o architettonica allo stesso modo di algoritmi e megabyte, ma oggi l'integrazione disciplinare fa la differenza rispetto sia alla qualità finale del progetto, sia alla qualità della vita lavorativa.
7. Produzione di pezzi difettosi. Per quanto digitale, il modello informativo è pur sempre un prodotto. Chi produce deve avere la consapevolezza di aver consegnato un prodotto corretto, fatto bene, che soddisfi le esigenze del cliente. Si tratta di un passaggio critico, perché sicuramente il digitale fa perdere al professionista il controllo fisico di quello che sta facendo. Un esempio: il computista tradizionale misura manualmente le lunghezze, calcola le aree, i pesi e nella sua testa procede con un ordine logico che gli permette di sapere cosa ha contato e cosa no. In un processo di QTO, gli stessi numeri escono da soli: da una parte, si abbattono i tempi di misurazione/calcolo, ma, dall'altra, è complesso capire se il numero ottenuto sia giusto o sbagliato. Per questo motivo, uno dei compiti più delicati del BIM Coordinator o del BIM Specialist è quello di verificare costantemente dati e informazioni del modello: che gli oggetti siano modellati con il comando giusto, che le proprietà siano compilate, che non ci siano duplicati, refusi ecc... Per dare un'idea, uno dei pilastri del metodo Toyota è il principio di autoattivazione, ossia qualsiasi operatore, nel momento in cui riscontra una non conformità, ha il dovere di fermare la produzione intera. La prima motivazione è legata alle logiche di montaggio, perché se non si risolve da subito il problema, questo può causare problemi sia sui pezzi successivi che nei montaggi con altri pezzi, provocando ripercussioni molto più significative. La seconda motivazione è legata invece all'importanza del lavoro in team: fermando la produzione, tutti sono informati del problema e della sua risoluzione, in modo che, nel caso si ripeta lo stesso problema, tutti siano in grado di risolverlo o comprenderne l'origine.

__________________________________________________________________________

Andrea Fronk è un ingegnere che si occupa di digitalizzazione nel Settore delle Costruzioni. Come direttore tecnico di Bimfactory si occupa di consulenza e formazione, portando in dote l'esperienza acquisita negli anni su progetti BIM. Dal 2019 è BIM Manager certificato ICMQ e Project Manager ISIPM. E' membro inoltre del BUG Italy (BIM User Group Italia) e partecipa attivamente alla Commissione Innovazione presso l'Ordine degli Ingegneri di Trento.

Contatto su LinkedIN e Twitter