Il BIM spiegato ai «Bambini»
Il BIM spiegato ai «Bambini»
Spesso si afferma che i ragionamenti metodologici relativi al Building Information Modeling (BIM) siano troppi astratti ed astrusi e che servano, invece, atteggiamenti più operativi e, in ultima analisi, più fattivi di quanto non lo siano quelli riferiti giusto ai Metodi e agli Assetti.
Si tratta, però, di una interpretazione di comodo che, malauguratamente, causa più problemi di quanti non riesca a risolvere, dato che intende ridurre la vicenda all'impiego decontestualizzato di Strumenti senza avere compreso la natura e l'origine di questi.
Si ricorda, infatti, anzitutto che il Modeling evoca la nozione di Modello e di Modellazione che rimanda, a sua volta, a una «riproduzione», a una simulazione del Reale che comporta schematismi e riduzioni: si tratta, allora, di approssimazioni digitali, preferibilmente intenzionali, mirate a finalità ben precise, non repliche esatte della realtà, come è evidente con particolare intensità negli Interventi sul Costruito.
In essi, infatti, l'acquisizione di Nuvole di Punti, con qualsiasi mezzo, per quanto accurata, può instillare l'illusione che ciò che sia rilevabile (nello spettro del visibile) corrisponda a ciò che autenticamente esiste, ma è ormai chiaro che, al di là della necessità di integrare quei Dati con altri, ottenibili per altre vie e con maggiori mediazioni, la trasposizione in un Modello Informativo non possa essere che, appunto, parziale, in quanto legata alla Modellistica e alla Modellazione.
Da questo punto di vista, non vi ha dubbio che lo scopo principale di un Progetto (Esecutivo) sia quello di mettere a disposizione tutti i Documenti necessari per la Esecuzione (Conforme) dell'Intervento senza giungere a costituire anticipatamente l'esatta realtà che si andrà a realizzare: in analogia, il Modello Informativo Federato di quel Progetto ambisce a restituire, in prospettiva, la totalità dei Dati, senza poterne, però, virtualizzare ogni aspetto.
In ogni caso, anche se nella vulgata del settore la Modellazione è associata alla Rappresentazione, nella sostanza, il Modello è uno Schema Teorico Riduzionista, altro dalla intenzione di mostrare, dunque, di semplicemente disegnare.
Ecco, quindi, che Analogico e Digitale rimandano a grandezze che variano in maniera rispettivamente continua e discontinua, laddove il secondo attributo ha a che fare con numero o, più propriamente, con una cifra: machine-readable, leggibile dalla macchina, vale a dire, utilizzabile potenzialmente in ogni occasione di Interoperabilità e di Interconnessione nella Smart City e nell'Internet of Everything, dove, però, sono le Cose a dialogare attraverso i Dati.
La Modellazione, inoltre, evoca, in determinate circostanze, la Rappresentazione e, in particolare, la Tridimensionalità, motivo per cui il BIM è, in primo luogo, associato al 3D, anche se esso sembra appartenere a un altro mondo, il mondo della Simulazione.
D'altra parte, in termini di Rappresentazione, appare centrale il Segno Grafico, ma γρα?ικ?ς implica sia il disegnare sia lo scrivere: d'altra parte, in molte circostanze è difficile separare la Componente Geometrico Dimensionale da quella Alfa Numerica: dalla produzione del Computo Metrico Estimativo alla effettuazione di una Verifica Energetica.
In ogni caso, la Rappresentazione tradizionalmente, con il Computer Aided Design, riguardava linee e polilinee, mentre il Building Information Modeling concerne, tra gli altri, come detto, la Simulazione e la Parametricità.
La Simulazione, peraltro, inerisce alla Previsione di Dinamiche, di eventi in movimento, riportando alla nozione di Modello Verosimile, mentre la Parametricità indica la possibilità di gestire numerose Alternative e Variazioni rispetto all'ipotesi originale da attuarsi in maniera coerente.
Quale che sia il significato delle annotazioni precedenti, resta il fatto che il BIM nasce come Product Data Model e, di conseguenza, l'Entità assume, sin da subito, una Identità, tanto Geometrico Dimensionale quanto Alfa Numerica: il che equivale a dire che ciò avvenga in maniera rigorosa, ma rigida, legata, in qualche modo, a una attitudine «manifatturiera».
Non dimentichiamo, comunque, che la Componente Alfa Numerica è assolutamente centrale negli Ambienti di Calcolo Specialistico, Strutturale, Energetico, Impiantistico, supportata pur da aspetti geometrici bi- e tridimensionali, ma non è ancora del tutto pienamente sincronizzata con quella presente negli Ambienti di Modellazione Informativa, mentre, per la parte di Progettazione Architettonica ed Edilizia, esse ha sempre, nella sostanza, rivestito ruoli accessori, almeno in termini di accuratezza e di congruenza, come dimostra, ad esempio, il Capitolato Speciale di Appalto.
La mancata pienezza della relazione che intercorre tra Modellazione e Calcolo inficia, sostanzialmente la completa validità dell'Information Management, poiché i Dati fluiscono, talvolta, con fatica e con lentezza.
Ovviamente, tale peculiarità è sostanzialmente anche sinonimo di rigidità nelle fasi iniziali di un Processo, specie laddove si parli di Sketching e, perciò, di Schizzi, al di fuori del Computational Design, che accennano a Soluzioni Formali e Spaziali in termini volumetrici, ma non necessariamente oggettuali.
A questo proposito, benché la Progettazione appaia la prima occasione naturale per utilizzare gli Strumenti, di BIM Authoring, in realtà, affinché essi possano supportare correttamente il suo esito, è opportuno che la Committenza, intesa quale funzione del commettere, del commissionare, sia esplicitata attraverso Strumenti di BIM Briefing (di Space Programming e di Code & Model Checking).
In origine, ciò non era scontato all'interno di tecnologie rivolte, appunto, alla Concezione, specie nelle sue fasi avanzate, e, pertanto, costringe Committenze Analogiche, spesso abituate a formulare richieste vaghe, o quantomeno generiche, a esprimersi computazionalmente tramite i Requisiti Informativi, altrimenti detti Capitolati Informativi.
In effetti, in molte circostanze, specie negli Stati Uniti o, comunque, al di fuori dell'Europa, il cosiddetto BIM Execution Plan è l'unico documento programmatico impiegato, talvolta unilateralmente dalla Domanda nei confronti dell'Offerta.
D'altra parte, i tentativi britannici di ingegnerizzare i Requisiti Informativi (il riferimento è allo NBS BIM Toolkit) sono attualmente sottoposti a severa critica e soluzioni alternative si stanno affacciando, proprio perché una Committenza Computazionale stenta ad affermarsi e i primi tentativi rischiano di dimostrarsi sovrastrutturali nei confronti delle prassi vigenti.
Certo è che, a oggi, gli Strumenti del Building Information Modeling stanno prevalentemente nell'immaginario della Progettazione, non in quello della Committenza che, infatti, nei primi casi nazionali, stenta a muoversi con destrezza, limitandosi a formulare richieste alla Contro Parte, senza essere in grado, però, di farlo veramente in termini computazionali.
Strettamente connessa a questa faccenda è quella relativa ai cosiddetti Livelli di Sviluppo o di Definizione, vale a dire di Avanzamento della Modellazione e della Gestione delle Informazioni, che mirano a stabilire una Metrica alternativa a quella tradizionale, imperniata sul Documento, idonea a valutare Quantità e Qualità dei Dati e delle Informazioni contenute nei Modelli Informativi.
Tutti i tentativi sinora conosciuti, tesi a misurare, appunto, la Densità Informativa Elementare (per ciascuna Entità non più riducibile contenuta nel Modello) in maniera disarticolata per Aspetti Geometrico Dimensionali e Aspetti Alfa Numerici hanno incontrato alcune difficoltà relative a:
1) operare tendenzialmente attraverso comparazioni agli esempi di riferimento, per gli Aspetti Geometrico Dimensionali: il che può funzionare soggettivamente, ma non in un contesto di machine-readability;
2) dover ricongiungere la Valutazione dei Livelli di Avanzamento della Modellazione alle Verifiche proprie degli Ambienti di Calcolo Specialistici per quanto inerisce agli Aspetti Alfa Numerici: il che dimostra come la dimensione prospettica, come si dirà, non appartiene a un determinato software, bensì a un unico Common Data Environment;
3) la Valutazione dei Livelli nella Scala Discreta vale specialmente per un contesto in cui i Valori degli Attributi siano assegnati alle Entità nei Modelli Informativi nel corso della Progettazione, in termini di promessa nominale, senza doversi confrontare, in seguito, con i Valori pertinenti derivanti dai sensori posti in opera, richiedendo una Scala del Continuo anziché la Scala del Discreto.
Il passaggio, dunque, costituisce, per la base delle Strutture di Committenza esistenti, uno stimolo molto impegnativo per acquisire quella maggiore Professionalità che è traguardata dalla Aggregazione e dalla Qualificazione delle Stazioni Appaltanti e delle Amministrazioni Concedenti.
Compare qui il concetto di Selettività che, ovviamente, risulta essere poco gradito per un Mercato spesso poco competitivo e che comporta spostamenti di equilibri negoziali tra le diverse Amministrazioni Pubbliche, così come all'interno delle Compagini Professionali e Imprenditoriali.
In altre parole, la diffusione del Building Information Modeling è accompagnata dalla preoccupazione che esso generi maggiori oneri, sia nell'acquisizione degli Strumenti sia nell'erogazione della Formazione.
Il punto è che la Selezione è inevitabile, proprio perché la razionalità intrinseca negli Strumenti punta all'Economia di Conoscenza, che presuppone una Economia di Scala.
Si tratta obiettivamente di una grande difficoltà culturale anche per gli Organismi di Progettazione, poiché i Requisiti Informativi, impostati su Entità e Oggetti, entro una Struttura di Scomposizione, una Breakdown Structure, non riflettono per nulla in larga parte una «flessibilità», utile in termini creativi (in molti casi), ma generatrice di Dati e di Informazioni destrutturati e incoerenti.
In definitiva, ai Committenti non piace l'idea di esercitare una propria Progettualità, oltre a tutto caratterizzata dalla Cultura del Programme & Project Management, né i Progettisti sono entusiasti di condizionare il proprio operato a quella dei primi, ma occorre domandarsi come, solo a valle del Progetto di Fattibilità Tecnico Economica, in cui oggi si raccoglie una forte anticipazione dei contenuti precedentemente ascritti al Progetto Definitivo, sia possibile, in maniera autoreferenziale per gli Organismi di Progettazione, avviare una Modellazione Informativa priva di continuità e di coerenza con le richieste originali e mirate dei Committenti, senza che questo non sia causa di ulteriori inefficienze.
Il rischio è ovviamente quello di riprodurre le Discontinuità e le Incoerenze attuali entro Strumenti pensati per altri Metodi: detto in parole povere, è possibile che gli Strumenti mettano impietosamente in evidenza l'Incongruità del Modus Operandi degli Attori, oggi meglio celabile grazie a Modalità più flessibili.
E' difficile, tuttavia, in un contesto di Debolezza della Committenza e di Autoreferenzialità dei Progettisti (la cosiddetta Centralità di un Progetto frutto dell'operato disintegrato di Micro e di Piccole Organizzazioni) che una accezione corretta sia realmente accettata e implementata, anche perché molti Dati, di diversa natura, non sono pienamente integrabili all'interno del Modello Informativo, ma, al limite, sono semplicemente a esso riferibili, per cui è improbabile che dallo stesso Modello si possano trarre tutti i Documenti Tradizionali o che, addirittura, la loro restituzione documentale non avvenga se non con l'apporto di Strumenti estranei, perdendo la garanzia di coerenza informativa.
La Centralità del Progetto, nell'ambito della Digitalizzazione, può divenire per gli stessi Professionisti, una micidiale trappola che metta in risalto tutte le Criticità ora nascoste nella Conflittualità tra Ideatori ed Esecutori, per cui l'Appalto Integrato è stato terreno di confronto e di scontro, senza che sia stato possibile conseguire alcuna Collaborazione o, appunto, Integrazione.
E', infatti, la categoria della Soluzione di Continuità, cioè della Perdita Informativa, l'oggetto principale dell'Information Management: introdurre elementi discontinui in un Flusso Informativo Pienamente Digitalizzato comporta il comprometterne la validità senza poter ricorrere agli aggiustamenti a cui si è acconci attualmente.
La medesima Discontinuità si riscontra tra la Progettazione Esecutiva, che nella logica dell'Appalto di Sola Esecuzione, non può che essere circoscritta all'ambito dei Progettisti (dei Professionisti) e la Progettazione Costruttiva, sotto il duplice profilo, della Modellazione Quadri- e Pentadimensionale (4D/5D Modeling) e degli Shop Model, nel senso che la Logica di Scomposizione e il Grado di Analiticità dei Modelli Informativi Federati difficilmente possono essere condivisi tra Professionisti e Imprenditori in assenza di Forme e di Luoghi di Interazione.
La Progettazione Costruttiva, d'altronde, è essa stessa, nell'ambito della Modellazione Informativa una Attività Costruttiva Precoce, poiché è influenzata dai criteri di transazione nella Catena di Fornitura e restituisce la Collaborazione Progettuale che deve intercorrere sotto la regia dell'Impresa Principale da parte delle Imprese Sub Appaltatrici e dei Fornitori.
La Separazione tra le Fasi e la Distinzione dei Ruoli, infatti, nei presupposti dei loro assertori si fondano sulla convinzione che i Saperi siano rigidamente distinguibili e che i Flussi Informativi che scaturiscono dai Progettisti siano perfettamente esaustivi e recepibili dai Costruttori: il che la realtà si incarica puntualmente di smentire.
L'esistenza di Capitolati o di Requisiti Informativi (Employer's o Apponting Party's Information Requirements) e di Piani di Gestione Informativa (BIM Execution Plans) serve, dunque, proprio, sia sul piano organizzativo sia sul piano contrattuale, a irreggimentare la Produzione e la Gestione dei Flussi Informativi all'interno di Compagini Omogenee (come quelle dei Progettisti o degli Esecutori) o Eterogenee (e, pertanto, Integrate).
E' ovvio che la concezione legata alla formulazione delle Richieste Informative da parte dell'Impresa Principale (dell'Impresa Affidataria), comporti per le Imprese Costruttrici (delle Imprese Sub Appaltatrici) un maggior grado di Co-Decisione, rafforzando legami prossimi ai Processi Aggregativi (di Internalizzazione) e, comunque, mutando i rapporti di forza lungo la Catena di Fornitura.
Naturalmente, dalla Progettazione Costruttiva si traggono Modelli Informativi e, analogamente, dagli stessi si originano Modelli 4D: sotto questo aspetto, il Modello Informativo gioca un ruolo non trascurabile anche nel corso della Realizzazione, ma, in questa sede, i Dati non provengono più solo dal Modello Informativo, bensì anche dalle Implementazioni Manuali sul campo o dai Sensori.
In questa sede è chiaro come certamente i Dati siano ancora correlabili e introducibili nei Modelli Informativi, ma, di fatto, sono i Modelli Informativi stessi e i loro applicativi a stemperarsi in un Ecosistema Digitale, in un Ambiente Informativo, in una Piattaforma Digitale.
Al termine della Esecuzione si avrà, d'altra parte, un Modello Informativo Federato che recepisca la situazione scaturita dalla Esecuzione, al fine della Gestione, ma esso resterà sempre una schematizzazione del Cespite Costruito, non esattamente il suo Doppio.
Ancora una volta, il Paradigma della Separazione, però, penalizzerebbe alcuni siggetti, nell'Appalto di Sola Esecuzione, non solo a monte nei confronti dei Progettisti, ma pure a valle, verso i Gestori/Manutentori, non coinvolti nelle fasi precedenti.
Se, nella Progettazione, il Modello Informativo appare come centrale, non altrettanto si può dire per la Esecuzione, poiché, al di là del 4D Planning e della Progettazione Costruttiva, ciò che conta è gestire contemporaneamente i Dati strutturati in Informazioni che discendono dal Modello stesso, assieme a quelli, ben più ingenti, che provengono dai Sensori installati sia presso le Postazioni e i Macchinari (e gli stessi Attori) all'interno e all'esterno del Cantiere sia presso i Social Network che concernono gli Operatori.
La stessa considerazione, che vale anche per la Gestione dell'Opera, evidenzia bene come il Modello Informativo Federato possa rimanere la costante di riferimento lungo il Ciclo di Vita del Progetto e dell'Opera, ma, in sostanza, a partire dalla Esecuzione, esso, all'interno di un Ambiente Informativo più vasto, di un vero e proprio Ecosistema Digitale, diventa il ricettacolo di Flussi Informativi generati attraverso, ad esempio, Mobile Device in cui si implementano manualmente Dati, Sensori e Wearable Device, utilizzabili per gestire Augmented e Mixed Reality.
A questo punto, si comprende chiaramente come il Modello Informativo, che si produce con gli applicativi di BIM Authoring assume una importanza diminuita, poiché sono proprio i Dati in quanto tali ad avere il sopravvento all'interno dell'Ecosistema Digitale.