Committenti Analogici e Digitali. L'Equivoco dei Requisiti Informativi

I Requisiti Informativi, definiti nel mondo anglosassone, non solo dalla BSI, come Client's o Employer's Information Requirements, oltre che, dall'ISO, come Exchange Information Requirements, costituiscono una delle principali acquisizioni che si devono alla cultura digitale britannica. Essi sono divenuti progressivamente un riferimento imprescindibile, tanto che, come Auftraggeber- Informationsanforderungen (AIA), sono oggetto di regolazione, in Germania, da parte della VDI, e in Svizzera, a cura della SIA. Essi si stanno diffondendo anche in Francia, come Cahier de Charges BIM, mentre in Italia sono stati puntualmente trattati nel DM 560/2017 e nelle norme UNI della serie 11337.

Il debito contratto con il mondo anglosassone si spiega col fatto che, negli Stati Uniti, ove la pratica della modellazione informativa si è inizialmente diffusa, la assenza di criteri metodologici, in presenza dell'adozione non sistematica degli strumenti, aveva condotto alla definizione del BIM Execution Plan, ovverossia del Piano di Gestione Informativa, inteso principalmente come riferimento fondamentale pel versante dell'Offerta.

I Britannici avevano, poi, esteso alla Domanda l'approccio metodologico, rendendosi conto che il committente fosse l'autentico Key Driver.

Requisiti Informativi, o Capitolato Informativo

I Requisiti Informativi, conosciuti in Italia come Capitolato Informativo, rappresentano, infatti, il veicolo con cui il committente indica ai propri fornitori, nelle diverse catene, le proprie necessità in tema di modellazione informativa, attendendosi, come prevede anche il DM 560/2017, che essi agiscano, come detto, da driver dei flussi informativi entro le supply chain di propria competenza.

Ovviamente, le formule contrattuali, che tendano o meno a separare o a integrare le fasi e gli operatori, influiscono profondamente sulla maniera nella quale i Requisiti Informativi si distribuiscono tra i livelli di fornitura, ma, come il DM 560/2017 pretende, è fondamentale che nel Capitolato Informativo figuri il modello informativo relativo allo stato dei luoghi e all'anagrafica patrimoniale dei cespiti e delle particelle coinvolti, oltre che le strutture di dati in essi citati percolino lungo l'asse intero di fornitura.

Tali Requisiti nascono prima della fase progettuale, per concludersi in quella della gestione e dell'esercizio: ad esempio, delle stazioni e delle linee ferroviarie.

Per questa ragione, prima dell'avvio della progettazione, il Capitolato Informativo dovrebbe essere strettamente legato al Documento di Indirizzo Preliminare, a oggi da esso avulso, oltre che concepito in maniera analogica, perché quest'ultimo contiene la descrizione delle aspettative puntuali del committente.

In tal guisa, il Capitolato Informativo, senza un nesso computazionale diretto con il Documento di Indirizzo Preliminare, rischia di essere privato della sua sostanza principale, assumendo un ruolo minore, in parte persino sovrastrutturale.

Non dimentichiamo che il Brief, il Documento di Indirizzo Preliminare, già Documento Preliminare alla Progettazione, rappresenta il vero e proprio atto progettuale della committenza.

Altri contenuti tipici del Capitolato Informativo coincidono, o potrebbero sovrapporsi, peraltro, con il Project Execution Plan, redatto dal Client Project Manager, cosicché sarebbe preferibile che, ad esempio, le strutture di scomposizione (OBS, PBS, WBS, CBS) si trovassero nel Piano di Gestione del Progetto, da recepire e approfondire successivamente da parte dai fornitori assieme al Piano di Gestione Informativa.

BIM USE

I Requisiti Informativi contengono, inter alia, gli Obiettivi della Modellazione Informativa, noti come BIM Use.

La grave criticità che si riscontra a questo proposito è, tuttavia, il fatto che originariamente questi ultimi stavano giustamente a indicare che il «modello», proprio a causa del significato dello stesso termine, non poteva che costituire una versione parziale e finalizzata di un fine da perseguire, rendendo insensata l'interpretazione per cui il modello informativo aggregato o federato potesse darsi come il «gemello» previsionale di quello che sarebbe stato il cespite fisico.

Il punto, però, è che attualmente per definirsi a pieno titolo committente digitale non è certo più sufficiente enumerare sinteticamente gli obiettivi della modellazione informativa, per lasciare successivamente si soli fornitori l'onere di configurare appositamente i modelli informativi.

Se, ad esempio, si intende richiedere, da parte del committente, ai fornitori dei servizi di progettazione che il modello informativo aggregato o federato sia utilizzabile proficuamente e congiuntamente per la direzione dei lavori e per la direzione tecnica di cantiere ai fini della gestione e dell'esercizio dell'opera commissionata, occorrerà che la stazione appaltante, o l'amministrazione concedente, definisca, per ogni entità, spaziale o tecnologica, che figurerà nello Information Model, una precisa struttura di dati, che la controparte dovrà tradurre in «oggetti».

D'altra parte, se si ricorda quanto sostenuto a proposito dello stato dei luoghi e della conoscenza dei patrimonî, la digitalizzazione del territorio e dei cespiti pre-esistenti al committente stesso compete una certa qual «oggettualizzazione».

In altri termini, poiché il committente dell'opera tangibile agisce pure come acquirente di informazione immateriale, le caratteristiche, geometriche-dimensionali e alfa-numeriche, di ciascun oggetto dovranno, appunto, riflettere modelli di dati, aggregazioni di dati strutturati.

Così come per la detenzione dell'Ambiente di Condivisione dei Dati, la ipotesi iniziale di strutturazione dei dati non dovrebbe essere lasciata, infatti, alla controparte contrattuale, proprio perché il committente/proprietario ha, in linea di principio, il maggior interesse allo sfruttamento dei dati e delle informazioni generati.

Non dimentichiamo, infatti, come il DM 560/2017 prevede, come già affermato, a proposito dello stato dei luoghi, che il committente, per potere richiedere e ottenere contenuti informativi computazionali, deve, in precedenza, fornirne di corrispondenti.

Il committente digitalizzato deve, infatti, saper elaborare Modelli di Dati, anziché lasciare l'iniziativa ai fornitori, proponendo richieste generiche e convenzionali, come accade in quasi tutti i Capitolati Informativi reperibili in Italia.

Starà, poi, ai fornitori dei servizi di progettazione di inscenare un contraddittorio, un dialogo «collaborativo» teso a confermare o a derogare alle richieste della committenza, sulla base di ragioni approfondite e condivise.

È palese, infatti, che la Digitalizzazione della Domanda Pubblica, espressa nei suoi termini più corretti, imponga una radicale riduzione delle stazioni appaltanti e delle amministrazioni concedenti, in grado di sostenere la guida e il contraddittorio nel corso del procedimento.

Nella fattispecie, infatti, il committente dovrà disporre di un Autentico Ambiente di Condivisione dei Dati in cui, all'atto della conclusione del progetto esecutivo, nel caso in cui si ipotizzi che questo possa essere il livello ideativo posto a base di gara, ogni oggetto/struttura di dati (non importa se tutti contenuti nel modello informativo, conta che essi siano presenti relazionalmente in formato computazionale nel Common Data Environment) dovrà essere disponibile in modo affidabile alla conclusione dei lavori.

Se ci si pensa bene, i dati strutturati che computazionalmente dovrebbero naturalmente costituire il progetto esecutivo su cui produrre le offerte da parte delle imprese di costruzioni concorrenti e su cui basare il Piano di Gestione Informativa da parte della impresa affidataria, dovranno consentire una informazione dettagliata.

Essa, tuttavia, al fine della comunicazione/prescrizione di ciò che dovrà essere realizzato attraverso il modello informativo aggregato o federato, passa attraverso una descrizione esauriente sotto il profilo della rappresentazione (grafica) e della descrizione (capitolare), ma, ad esempio, nell'ottica della computistica, decisiva per la contabilità gestionale e per quella analitica, opportuni algoritmi potrebbero evitare la configurazione geometrico-dimensionale di ogni elemento.

A prescindere dal fatto che attualmente nel modello informativo aggregato o federato i calcoli strutturali o impiantistici, così come le relative relazioni di calcolo, non possano essere direttamente inclusi, dovremmo chiederci in che cosa possa consistere un contratto in cui le informazioni siano presenti interamente nell'Ambiente di Condivisione dei Dati, senza che venga generato alcun documento «stampabile».

Se, in teoria, in futuro, l'Ambiente di Condivisione dovrebbe essere il fattore principale, in cui i dati, tutti computazionali, di volta in volta andrebbero a generare modelli informativi mirati (eventualmente a partire da definizioni pre-strutturate o View Definition), allo stato attuale esso più mediocremente consente di originare o di correlare documenti che, di fatto, traducono discretamente ciò che si vorrebbe gestire in continuo.

A oggi, le imprese di costruzioni competono nella fase di offerta sulla scorta di documenti, verificati e validati, sia pure, in parte, scaturiti da modelli informativi, a seguito di un processo progettuale in cui i flussi informativi sono ancora debolmente regolati, soffrendo di evidenti discontinuità.

Utilizzare il modello informativo aggregato o federato quale esclusivo veicolo di mediazione tra le controparti nel corso dell'esecuzione del contratto rappresenta, in effetti, una sfida improba.

Il modello informativo aggregato o federato giunge, del resto, solo a corredo dei documenti tradizionali, spesso esclusivamente in formati neutri, non completamente «affidabili», nel senso che grazie a un loro uso insufficiente potrebbero nascere versioni discrepanti.

Gli oggetti contenuti nei modelli informativi rispecchiano, infatti, strutture di dati che dovrebbero essere confermate, con maggiore grado di approfondimento a seguito delle scelte merceologiche e operativa dell'impresa affidataria e della sua catena di fornitura, a condizione che i modelli informativi aggregati o federati procurati dal committente siano facilmente adattabili alle logiche imprenditoriali.

Il che sembra essere problematico, poiché i progettisti dovrebbero seguire impostazioni fortemente orientate dalla committenza nei confronti del punto di vista della esecuzione dei lavori e della gestione dell'opera.

In assenza di questa versatilità, l'impianto strutturale previsto dalla committenza e adottato dai progettisti sarà sconvolto dall'impresa affidataria, ostacolando una convergenza nel corso dell'esecuzione dei lavori tra le controparti.

Come si è analizzato in altri contributi, la via alla «salizzazione» e alla «silizzazione» passa, a questo proposito, attraverso due passaggi non banalmente coincidenti:

i) da un lato, l'elemento, spaziale o tecnologico, previsto subirà una configurazione ulteriore da parte della catena di fornitura, sino a divenire entità fisicamente compiuta e successivamente registrata digitalmente, come rilievo del così come costruito;

ii) dall'altro, la modellazione 4D che permetta di scandire le ipotesi relative ai SAL e ai SIL conterrà delle «riduzioni», tanto più che il Sistema di Monitoraggio delle Commesse e dei Cantieri dell'impresa affidataria non avrà convenienza a verificare ogni variazione di dettaglio, ma le liste di riscontro collegate ai modelli informativi aggregati o federati dovranno rispecchiare la consistenza reale degli oggetti fisici, per alimentare, appunto, la contabilità analitica inerente agli stati di avanzamento.

La modellazione 4D, di là delle sue applicazioni più innovative basate sulla realtà aumentata e sugli ambienti immersivi, per non dire di strumenti di programmazione temporale spaziale semi-autonoma, richiede oggi un profondo ripensamento.

Tra l'altro, la modellazione 4D figura, sempre genericamente, come uno degli Obiettivi più ricorrenti.

Essa nasce, infatti, come strumento di supporto alla decisione per ottimizzare la logistica di cantiere e la sequenza costruttiva, ma, almeno per il secondo fine, a meno di non ricorrere a simulazioni interattive relative a lavorazioni particolari, rimane relativamente schematica.

L'associazione visiva dei valori delle curve a S ai singoli oggetti può, in effetti, rappresentare un passaggio evolutivo in senso gestionale, ma, sul versante dell'aggiornamento di questi ultimi, il modello 4D rischia di risultare troppo oneroso, senza contare che, così come per la programmazione della produzione cantieristica a breve periodo, sarebbe necessario il coinvolgimento attivo della intera catena dei fornitori e dei subappaltatori.

D'altronde, assumendo che gli oggetti prodotti dalla modellazione informativa alla fine del progetto esecutivo siano dettagliati analiticamente nel contratto tra le controparti, gli stessi, come negoziati all'interno della catena di fornitura saranno successivamente maggiormente precisati merceologicamente, ma non necessariamente la modellazione dovrà essere egualmente oppure maggiormente dettagliata perché le pattuizioni interimprenditoriali possono consentire omissioni o sottintesi senza nocumento, derivanti da specifiche logiche di acquisto.

È evidente allora che il percorso che dagli oggetti informativi contenuti nella progettazione di fattibilità tecnico-economica arriva alle entità proprie al modello informativo del come costruito possa non essere così lineare come i Livelli di Sviluppo o di Definizione possano far presagire.

Il che spiega le ragioni per cui il committente deve ragionare accuratamente sulle strutture dei singoli oggetti che commissiona.

Come si può intuire, dunque, il modello informativo aggregato o federato che subisce la transizione da «esecutivo» a «costruttivo», per essere ottimale, dovrebbe contenere in se stesso una serie di astrazioni» che preservino la presenza e la computabilità di tutti i dati necessari secondo strutture predefinite, senza che essi siano tradotti completamente in oggetti.

L'Ambiente di Condivisione dei Dati dovrebbe, di conseguenza, includere tutte le strutture dei dati senza che esse «figurino» interamente nei modelli informativi.

La tempistica di aggiornamento delle previsioni relative agli accadimenti cantieristici, attuabile attraverso strumenti di rilevazioni delle quantità e degli altri parametri (tempo, qualità, salute e sicurezza, ambiente, ecc.) si incentrerà sui singoli oggetti nei modelli informativi, ma, soprattutto, dovrà investire le strutture dei dati che nell'Ambiente di Condivisione possano essere «rappresentabili» da cruscotti e icone, cosicché si possa ragionare visivamente sulla Business Intelligence.

I valori inerenti tanto alla contabilità gestionale (Earned Value Management) quanto alla contabilità analitica saranno, peraltro, in futuro sempre più acquisiti semi-automaticamente, «oggettivamente», attraverso sovrapposizioni di nuvole di punti e di oggetti o di analisi delle immagini, per quanto attiene al visibile, oppure tramite sensori collocati all'interno degli elementi da assemblare o da realizzare.

Se, perciò, vi è la necessità di conseguire la maggiore tempestività, economicità e precisione contabile tanto per la redazione del SIL quanto del SAL, resta, ritornando ai Requisiti Informativi iniziali, la necessità di ottenere, grazie allo sforzo congiunto di direzione dei lavori e direzione tecnica di cantiere, un modello informativo aggregato o federato come costruito che sia affidabile.

A questo proposito, intervengono due quesiti:

i) l'esaustività di tale modello deve essere forzatamente anche geometrico-dimensionale, nel senso che in esso dovranno figurare tanti oggetti digitali quanti siamo gli elementi fisici, che, comunque, non dovranno più essere considerati sotto il profilo esecutivo, ma da quello gestionale?

ii) sarà stato in grado il committente di configurare inizialmente la struttura di dati gestita dall'applicativo finalizzato alle Operations & Management?

La strada verso la redazione di Requisiti Informativi che siano davvero computazionali è piuttosto impervia: l'importante è non fornire alla Domanda l'illusione che la pratica si risolva col documento che oggi passa col nome di Capitolato Informativo, ma che attualmente serve solo parzialmente alla bisogna.

In conclusione, occorre, prima di tutto, spostare l'attenzione del committente sugli applicativi di Space Programming (come, a titolo puramente esemplificativo, Nemetscheck dRofus), di Information Requirements' Specification (vedi, sempre al medesimo titolo, AEC3 BIMQ), di Code & Model Checking (in questo caso, esemplificativamente Nemetscheck Solibri), per poi guardare agli Ambienti di Condivisione dei Dati come Ambienti di Modellazione e di Gestione dei Dati.

È chiaro, allora, che potremmo usare modalità di visualizzazione inedite (attraverso icone?) per gestire le strutture di dati riferite a ciascuna entità spaziale o tecnologica, monitorandone in tempo reale l'evoluzione (attraverso flussi di dati di provenienza eterogenea) e dando loro «forma» in modo diversificato.

Si potrebbe immaginare una visualizzazione degli oggetti, a partire dai Requisiti Informativi, come icone di in un gioco solitario, spostabili con un tocco di dito, digitalmente, che possano illuminarsi a ogni variazione di stato dei valori delle proprietà (o persino della struttura informativa) e che possano aprire rappresentazioni di vario genere (dal 3D al dashboard).

Commissionare strutture di dati, fornire strutture di dati, produrre strutture di dati, verificare strutture di dati ed elaborare strutture di dati: ecco ciò che si denomina come Data-Driven Process.