Il Costo del BIM: Committenze e Malintesi

Uno dei temi che oggi paiono emergere dal crescente interesse per la digitalizzazione nel settore delle costruzioni riguarda gli oneri che le committenze dovrebbero sostenere.
Occorre, anzitutto, premettere che la sensazione sia che la Domanda Privata, specie nello Sviluppo Immobiliare, si stia maggiormente attrezzando rispetto alla Domanda Pubblica e che sia meglio in grado di valutarne i benefici e i ritorni, anche a causa di motivi comprensibili.
In ogni caso, è palese come sia un errore di metodo non trascurabile far coincidere i costi per acquisire, utilizzare e gestire la strumentazione (hardware e software) colla stima esclusiva degli oneri da sostenere, in quanto la maggiore onerosità che deriva dalla digitalizzazione delle committenze consiste, paradossalmente, nel metterne a nudo le lacune analogiche.
Si assiste, anzitutto, con preoccupazione, per interventi di una notevole complessità, a iniziative adottate da enti pubblici locali e amministrazioni pubbliche locali (altro discorso meritano le amministrazioni centrali e gli enti pubblici economici: ben più attrezzati) che mettono a base di gara la documentazione tradizionale, che la legislazione impone, affiancando a essa modelli informativi parziali, se non, addirittura, talvolta recanti dati incoerenti cogli elaborati ufficiali.

Ciò che, per prima cosa, deve essere compreso, possibilmente evitando di utilizzare acronimi e locuzioni in altre lingue (se non accuratamente definite e tradotte: come dimostra l'intenso lavoro in corso in sede ISO sui progetti di norma della serie 19650), che il modello informativo originario deve riflettere lo stato effettivo delle conoscenze patrimoniali di una committenza, includente, pertanto, anche lo stato dei luoghi.

Se ciò non fosse possibile, sarebbe necessario che la committenza indicasse chiaramente che, all'avvio della progettazione (o eventualmente della esecuzione o della gestione) i dati di ingresso non siano completi e in che misura l'onere di acquisizione dei relativi dati e delle corrispondenti informazioni competa a ciascuna delle controparti.

In secondo luogo, è cruciale che i Requisiti Informativi siano espressi sempre più in maniera computazionale, definendo non solo teoricamente le strutture di suddivisione e di scomposizione degli spazi e delle unità tecnologiche, specificando possibilmente le definizioni delle aggregazioni dei dati e delle informazioni, chiarendo con precisione le finalità che la modellazione e gestione informativa si deve prefiggere.

Occorre, in altre parole, che assolutamente si eviti di richiedere ai concorrenti ciò che in proprio si padroneggia con difficoltà, generando, nelle offerte tecniche, un profluvio di racconti, schemi, diagrammi, che riflettono più, nel migliore dei casi, le buone intenzioni (o le cattive promesse) che non autentiche e sperimentate prassi digitali.

E' del tutto evidente, infatti, che questo approccio abbia elevate probabilità di essere disatteso nel corso dell'esecuzione del contratto, oltre che di generare immediatamente contenziosi nel periodo immediatamente seguente alla aggiudicazione provvisoria.

In altri termini, è bene che le stazioni appaltanti non si affidino a valutazioni forzatamente soggettive di narrazioni letterarie, ma che impongano (ammesso che ne siano in grado) metodi, procedure e protocolli propri, oltre che definiscano anticipatamente sia l'ambiente di condivisione dei dati (gravissimo passaggio l'affidarsi all'offerente) sia l'applicativo di gestione dell'opera nel ciclo di vita.
Al di là della struttura convenzionale del capitolato informativo, che rischia di divenire un documento (appunto!) di Information Management di sostanza analogica, ancorché digitalizzato, slegato dal Project Management, e dal Project Execution Plan, la stazione appaltante o l'amministrazione concedente deve adottare un criterio analogico, facendo competere gli offerenti in termini numerici, in termini contenutistici, non in termini formali, come, di fatto, spesso accade.
Il punto è che la preoccupazione della committenza deve essere quella di specificare puntualmente ciò che desidera (come il modello informativo debba essere impostato, ben oltre il giochino, oggi ineffettuale, dei LOD e dei LOI) e come esso possa essere utilizzabile nelle diverse fasi e dai diversi attori, senza dover essere rifatto più volte, provocando asimmetrie informative.
Quanto agli strumenti e agli applicativi, al committente servono quelli di Space Programming, Code & Model Checking, i Game Engine, gli Immersive Virtual Environment: per fare ciò serve costituire comunità di pratica e agenzie di supporto inter-amministrative, non favorire emulazione acritica di documenti di gare discutibili, in grado di produrre effetti devastanti in ambito epidemiologico.