BIM e Schemi Contrattuali: Riflessi Non Giuridici

Requisiti Informativi e Qualificazione della Domanda
 
La premesse alle Note che seguono implicano che la Qualità del Contratto abbia influenza specifica sugli esiti della Esecuzione dello stesso e che, di conseguenza, ciò sia decisivo per le sorti della Gestione delle Informazioni.
Detto in altri termini, il presupposto è che una incoerente (rispetto all'essenza del Building Information Modeling) impostazione dei quadri contrattuali possa seriamente compromettere l'efficacia dell'adozione congiunta del Project Management e dell'Information Management.
Ovviamente, si tratta di riflessioni che non hanno alcuna pretesa in senso giuridico, ma che hanno lo scopo di sollecitare l'approfondimento in tale verso, nel Nostro Paese, da parte di chi ne abbia le competenze, così come è già avvenuto in Francia (Blandin, Bellenger, Pican), in Germania (Eschenbruch, Leupertz), nel Regno Unito (Mosey, Winfield) e negli Stati Uniti (Ashcraft, Circo).
Solitamente, nella letteratura sulla Committenza che pratica il Building Information Modeling, il documento che ricorre con maggiore frequenza è il BIM Execution Plan, traducibile in italiano come Piano di Gestione Informativa, sorto storicamente negli Stati Uniti in forma autonoma al fine di regolamentare i passaggi del Processo Digitalizzato.
Gli (Client's, Employer's, Appointing Party's) Information Requirements rappresentano, però, nei processi transattivi tra Parti in Causa, forse il maggiore elemento inedito apportato, questa volta, dal Regno Unito, quale espressione dei Requisiti Informativi di una Committenza, che sia essa Pubblica o Privata.
La loro traduzione in tedesco è pressoché immutata (Auftraggeber Informations Anforderungen), mentre in italiano (Capitolato Informativo), in francese (Cahier des Charges BIM) e in spagnolo (Pliego de Licitación o Pliego de Condiciones) risulta essere un poco differente.
Si tratta, in effetti, di una forte innovazione per due ordini diversi di motivi: perché rafforza l'identità della Domanda come Driver del Processo Digitalizzato; poiché presuppone una replica della Funzione (Bi-direzionale) di Committenza a ogni Livello di Fornitura lungo la Catena.
Per quanto concerne il primo tema, la BS PAS 1192-2, dapprima, la Norma UNI 11337-6 e la Norma ISO 19650-1 e la ISO 19650-2, poi, mettono in chiaro come non possa essere considerato realmente digitalizzato un Processo (Project) che non veda la Committenza come protagonista attiva e consapevole, dal punto di vista computazionale.
Del resto, in alcuni casi il Committente prevede di concordare la redazione dei Requisiti Informativi solo dopo l'Aggiudicazione del Contratto: così facendo, tuttavia, essi non fanno parte della valutazione della Offerta Tecnica.
Sotto il profilo strumentale non si tratta di una novità assoluta, in quanto, prima ancora del NBS BIM Toolkit, esistevano applicativi informatici Europei e Statunitensi (a partire da Nosyko dRofus e Trelligence Affinity) in grado di generare Space Programme collegati bi-direzionalmente con i software di BIM Authoring, ma, metodologicamente, ciò significa che le richieste avanzate dalla Struttura di Committenza non possano essere generiche né non machine readable.
Per questa ragione, non ha senso alcuno, da parte di un Committente, richiedere ai propri Potenziali Fornitori di "fare il BIM" (di utilizzare Metodi e Strumenti dell'Information Management) senza che esso non sia praticato all'interno dello stesso, così come, per la Committenza, non si tratta assolutamente, in prima istanza, di utilizzare la dotazione strumentale che, invece, adopererebbero i Fornitori di Servizi (quanto meno di Progettazione, di Direzione dei Lavori, ecc.) o gli Esecutori dei Lavori.
Al contempo, la disponibilità, in sede di Gara di Appalto o di Concessione, sia dei Requisiti Informativi sia delle Regole di Verifica dei Modelli Informativi, consente ai Concorrenti di comprendere la natura della risposta che sarà data dagli stessi attraverso i documenti tipici dell'Offerta Tecnica, ivi inclusa l'Offerta di Gestione Informativa (Pre-Award BIM Execution Plan).
Di fatto, la razionalità che guida un BIM-Based Tendering and Awarding Process verte sulla opportunità di rendere il più possibile computazionalmente trasparenti le attese e le condizioni contrattuali della Domanda pretendendo in cambio analoga trasparenza dall'Offerta, concepirà come Catena di Fornitura.
E' evidente, dunque, che in questo modo la Progettualità Strategica della Committenza si esplica appieno, tanto più in quelle frequenti occasioni in cui Cespiti Esistenti debbano essere conservati, trasformati o demoliti, associando ai Requisiti Informativi un Asset Information Model.
Ciò vale anche per il Green Field, considerando le sottostrutture come esistenti, specie in ambito urbano, allocando così specifiche responsabilità alle due (Contro) Parti in Causa ed enfatizzando la correlazione tra Building e City Information Management.
Oltre a ciò, la presenza delle regole di Verifica permetterebbe ai Concorrenti di valutare più accuratamente sia l'oggetto della procedura competitiva sia la rispondenza della propria Offerta Tecnica alle richieste iniziali prima della sottomissione della stessa.
Si riassumono brevemente i contenuti essenziali degli Information Requirements:
 
Information management:
  • Levels of detail (requirements for information submissions at defined project stages).
  • Training requirements.
  • Planning of work and data segregation (model management, naming conventions, etc.)
  • Co-ordination and clash detection.
  • Requirements for bidders' proposals for the management of the co-ordination process.
  • Requirements for bidders' proposals for the management of the collaboration process.
  • Requirements for bidders' proposals for BIM / common data environment supported health and safety / CDM management.
  • A schedule of any security and integrity requirements for the project.
  • A schedule of any specific information to be excluded or included in information models.
  • A schedule of constraints set by the employer on the size of model files, the size of extranet uploads or emails, or the file formats that can define the size of a volume.
  • Other project specific items such as pre-construction surveys or a requirement for the employer to receive information models describing newly-generated products and assemblies.
  • A definition of any co-ordinate origin/system.
  • A schedule of any software formats, including version numbers, to be used by the supply chain to deliver the project (or the formats of any outputs). NB PAS 1192-2 suggests that, 'Public sector employers may not wish to or be able or specify software packages to be used by their suppliers, but may instead specify the formats of any outputs. Private sector employers may choose to specify software packages and/or output formats.'
  • Alignment of information exchanges, work stages, purpose and required formats.
  • Details of the expected purposes for information provided in models.
  • An initial responsibility matrixsetting out any discipline responsibilities for model or information production in line with the defined project stages.
  • A schedule of the standards and guidance documents used to define the BIM processes and protocols to be used on the project.
  • A schedule of any changes to the standard roles, responsibilities, authorities and competences set out in the contract.
Competence assessment:
 
Requisiti Informativi e Strutture di Scomposizione
 
I Requisiti Informativi servono, perciò, a mitigare i Rischi di Insuccesso degli Appaltatori e dei Concessionari, a danno della Committenza, nella misura in cui le Stazioni Appaltanti, le Amministrazioni Concedenti e gli Sviluppatori Immobiliari sono in grado di configurare le attese contrattuali in maniera dettagliata.
Gli Intendimenti della Modellazione (BIM Use), ad esempio, chiariscono la natura stessa del Modello Informativo (descrizione in forma semplificata e controllabile di una Entità) che non può essere ovviamente inteso come una Replica Digitale del suo Originale Analogico, cosicché esso può presentare differenti Configurazioni a seconda degli Scopi.
Tra l'altro, sotto il profilo contrattuale, mentre un Modello Informativo Federato può consentire da esso di trarre quasi tutti gli Elaborati nella loro forma corretta ed esaustiva, la sua Configurazione potrebbe, invece, ostacolarne l'impiego per Intendimenti non previsti nei Requisiti Informativi (Energy Modeling, 4D Planning, ecc.).
D'altra parte, il grado di orientamento che i Requisiti Informativi sottendono, abilitano digitalmente il Documento di Indirizzo Preliminare (quello che era un tempo il Documento Preliminare alla Progettazione o Brief), sottolineando una volta in più, quanto Information Management e Project Management siano indissolubilmente legati: come è testimoniato bene dalla Linea Guida di ANAC sul RUP.
Sotto questo profilo, i Requisiti Informativi andrebbero integrati nel Piano di Gestione del Processo (Project Execution Plan), o viceversa: più probabilmente, gli Information Requirements dovrebbero essere inclusi nell'Ecosistema Digitale di Commessa dato dal Common Data Environment, unitamente al (BIM-Based) Project Management Information System.
La logica con cui devono essere impostati i Requisiti Informativi, infatti, è quella delle Strutture di Scomposizione o Breakdown Structure (WBS, OBS, CBS, ecc.), accentuata dal fatto che la Modellazione Informativa opera al Livello Elementare degli Oggetti (Entità Costruttive o Spaziali).
E' palese come la Scomposizione per Spazi e per Elementi sia obbligata in termini analitici nel caso di Edifici o di Infrastrutture Esistenti, mentre nel caso di Nuove Costruzioni la scelta della Granulometria influenzerà profondamente la risposta dei Prestatori contenuta nel Piano di Gestione Informativa e nel Modello Informativo Federato medesimo.
L'aspetto più significativo è, inoltre, dato dalla Matrice di Responsabilità che alloca Obiettivi e Oggetti) agli Attori (Fornitori), esigendo di dettagliarne anche le transizioni di fase, allorché, ad esempio, un Livello di Progettazione è assunto da un soggetto diverso da quello che ne aveva il carico in precedenza.
Ma si tratta pur sempre di un principio basilare del Construction Project Management.
Si noti bene che l'Information Management, esaltando la Simulazione (che è cosa ben diversa da ciò che taluni definiscono come Virtualizzazione), mette in luce la Prestazionalità (Performativity): secondo una simile ottica, accettando il principio della Centralità del Progetto, esso dovrebbe comportare una piena responsabilizzazione dei suoi Autori relativamente alla Realizzazione e al Ciclo di Vita, attribuendo a essi un carattere di Imprenditività.
 
 
Requisiti Informativi e Progettazione
 
I Requisiti Informativi dovrebbero generalmente contenere, a livello analiticamente elementare (oggettuale), anche la richiesta ai Concorrenti di delineare la Progressione dei Livelli di Definizione (Geometrico Dimensionale e Alfa Numerica) che, tuttavia, appunto,non si riferiscono omogeneamente all'Opera, come nella Legislazione sui Contratti Pubblici, bensì ai singoli Componenti. 
Occorre, qui, però, sottolineare alcuni aspetti non secondari:
1) i riferimenti oggi disponibili, prevalentemente negli Stati Uniti e in Europa, tendono a essere evocativi: vale a dire, propongono delle esemplificazioni che possano essere adoperate per confronto, ma non esiste, nei fatti, alcuna metrica che, in continuo, possa misurare con precisione la densità informativa di un Livello di Informazione o di Dettaglio;
2) proprio la distinzione tra Componente Geometrico Dimensionale e Componente Alfa Numerica evidenzia come un Oggetto possa assumere Livelli di Progressione differenziati. Il disallineamento tra Aspetti Geometrico Dimensionali e Aspetti Alfa Numerici ha un limite intrinseco nel fatto di ostacolare, oltre una certa misura, la Identificazione dei Conflitti, dato che crea Entità troppo eterogenee, ma rappresenta la migliore manifestazione dell'Approccio Lean.
Naturalmente i Requisiti Informativi del Committente non riguardano solo la Progettazione, bensì anche la Realizzazione e la Manutenzione: per quanto inerisce alla prima, tuttavia, la capacità della Committenza di definire i Requisiti in termini computazionalmente puntuali ha una grande influenza sullo evoluzione del Progetto Definitivo ed Esecutivo, ma può creare una possibile discontinuità tra le richieste iniziali e parte del Progetto di Fattibilità Tecnico Economica, specie in presenza di Schizzi o di Modelli Analogici.
A ciò occorre aggiungere che la nuova tripartizione dei Livelli di Progettazione sposta anticipandoli, molti dei contenuti del Progetto Definitivo in quello precedente, con vantaggi che sarebbero accentuati dal ritorno eventuale dell'Appalto Integrato.
Un altro tratto saliente ha a che fare con lo Sviluppo della Progettazione intesa non esclusivamente nell'ambito della Modellazione Informativa, bensì nelle sue relazioni con gli Ambienti di Calcolo Specialistico (Strutturale, Impiantistico).
La dialettica continua tra Ambienti di Calcolo (Strutturale e Impiantistico, ecc.) e Ambienti di Modellazione (Informativa) acquisisce particolare importanza agli occhi di un Committente, in quanto non solo permette di ricomprendere, entro l'Ecosistema Digitale entro cui si muovono i Prestatori, la maggior parte dei Dati strutturati in Informazioni e aggregati in Documenti (per ora), bensì, soprattutto, perché assicura il Design Optioneering, la valorizzazione della Scelta Dinamica tra Alternative Progettuali.
Ciò implica che probabilmente la Condivisione delle Responsabilità, nel senso di individuazione delle criticità della progettualità altrui, si estenda rispetto alla condizione tradizionale (Duty To Warn), ma pure che la Validazione del Dato assume un rilievo centrale, proprio perché esso è facilmente tracciabile e utilizzabile da altri senza mediazioni.
Altro aspetto rilevante è quello del Coordinamento dei Modelli Informativi da federare che, naturalmente, rimanda all'organizzazione interna delle Compagini Progettuali e ai poteri delegati in caso di conflitti tra Oggetti e tra Modelli, ma si riflette anche sulla Verifica dei Modelli Informativi ai fini della Validazione del Progetto.
A questo proposito, la detenzione della proprietà del Common Data Environment è determinante, in quanto, sia pure con diritti di accesso privilegiati, per il Committente è possibile esercitare una azione di Business Intelligence, vale a dire di non verificare solo la correttezza dei Modelli Informativi, bensì pure le criticità rilevate attraverso l'analisi dei modi d'uso degli applicativi informatici che li hanno prodotti.
 
 
Procedure di Aggiudicazione e Information Modeling
 
Si rimarca ossessivamente che la Modellazione Informativa, o meglio la Gestione delle Informazioni, sia sinonimo di Collaborazione e di Integrazione, ma, anzitutto, occorre comprendere come questo possa davvero verificarsi in presenza di Micro Organizzazioni e del Principio di Rigida Distinzione tra Progettisti, Costruttori e Manutentori/Gestori, a meno che non si attribuisca al Common Data Environment e all'Information Management un potere taumaturgico o, più modestamente, di autonomizzazione (di automazione dei processi decisionali) che prescinda dagli esseri umani.
E' palese che gli Strumenti dell'Information Management possano essere impiegati all'interno di forme contrattuali che esaltino la Contrapposizione o la Divisione, anziché la Collaborazione e la Integrazione: negando, pertanto, il Metodo che ne è all'origine.
Epperò, ciò equivarrebbe al paradosso per cui, una soluzione progettuale che si possa autoreferenzialmente ritenere compiuta e coerente a livello di Progettazione Esecutiva, si concretizzerebbe (virtualmente) in un Modello Informativo non più direttamente gestibile da Esecutori e Manutentori/Gestori.
Se, dunque, soprattutto, qui è l'Integrazione a venire meno, la mancata Collaborazione sarebbe evidente nel Piano di Gestione Informativa, che costituisce non solo la risposta del Fornitore Principale di Servizi o di Lavori, ma anche la sua proiezione delle Modalità di Interazione con i propri Sub Fornitori.
Il Committente originario, perciò, al fine di avere maggiore confidenza nei Flussi Informativi che scambia con i Fornitori richiede a questi di riprodurre la stessa impostazione nella Catena della Fornitura.
Naturalmente, ai Modelli Informativi Specialistici che scaturiranno dall'approccio collaborativo, la Committenza avrà accesso limitato contrattualmente, anche in tema di Tutela della Proprietà Intellettuale e di Sicurezza dei Dati.
La scelta delle Forme di Aggiudicazione e di Contratto (dal Contratto di Disponibilità all'Appalto di Sola Esecuzione) mette in risalto il grave dilemma legato a una scelta che il Sistema delle Costruzioni sembra aver propugnato nel Nostro Paese: quella di rinunciare alla caratteristica precipua insita in tutti gli sforzi internazionalmente adottati e che prendono le denominazioni eterogenee di Design-Build, Integrated Project Delivery, Project Alliancing, Early Contractor's Involvement, ecc.
La pretesa di eliminare Gradi di Collaborazione e di Integrazione tra Progettisti, Costruttori e Manutentori/Gestori, in nome di una fantomatica Centralità del Progetto, purissima retorica, nega, infatti, alla radice l'avanzamento dei Contratti Transazionali verso i Contratti Relazionali, o almeno ostacola gravemente nella direzione di assicurare Unicità di Interlocuzione e di Decisione in vista del Ciclo di Vita, determinante in Contratti relativi al Partenariato Pubblico Privato (inclusi quelli di Sponsorship relativi ai Beni Culturali Immobiliari).
Più praticamente, ciò significa che il Committente dovrà sostenere, al di là di una sconveniente Allocazione dei Rischi caratteristica del Design-Bid-Build, gli oneri probabili di un rifacimento, almeno parziale, del Modello Informativo Federato che scaturisce dalla Progettazione, alla luce delle esigenze degli Attori delle Fasi successive.

Accanto alla configurazione di Bandi e di Contratti di Riferimento (BIM-Oriented), occorre, allora ripensare attentamente i Contratti Multilaterali e il ruolo della Piattaforma Contrattuale entro cui avvengano le Transazioni Informative...