Le Criticità del Piano di Gestione Informativa (BIM Execution Plan)

A pre-contract BEP is prepared by prospective suppliers, setting out their proposed approach, capability, capacity and competence to meet the Employer's Information Requirements (EIR).

Once the contract has been awarded, the successful supplier then submits a further BIM Execution Plan confirming the supply chain's capabilities and providing a Master Information Delivery Plan (MIDP). The MIDP is the primary plan setting out when project information is to be prepared, by whom, using what protocols and procedures, it is based on a series of individual Task Information Delivery Plans setting out responsibility for specific information tasks

Designing Buildings Wiki

A prescindere dalla scadenza dello 01.01.2019, un numero sempre crescente di committenti pubblici e di sviluppatori immobiliari ricorrono, più nelle loro richieste alla contro-parte che non alle proprie prassi interne, alla modellazione e alla gestione informativa (Building Information Modeling).

La maniera con cui essi domandano e ottengono i modelli informativi non appare, in molti casi, tuttavia, convincente, col rischio di disseminare pratiche che abbisognerebbero di diverse rettifiche.

Il presente contributo intende, a questo proposito, mettere in luce le criticità insite nei documenti che l'Offerta elabora in risposta ai corrispondenti documenti predisposti dalla Domanda.

Le relazioni pre- e post- contrattuali, nelle procedure competitive che danno vita a contratti di servizi o di lavori impostati sul Building Information Modeling (BIM) si reggono su due documenti, il Capitolato Informativo e l'Offerta, poi Piano, di Gestione Informativa, definita con precisione dal DM 560/2017.

Il decreto ministeriale, infatti, precisa che il Piano di Gestione Informativa è il documento redatto dal candidato o dall'appaltatore ovvero dal concessionario al momento dell'offerta e dell'esecuzione del contratto che, in risposta ai requisiti informativi del capitolato, struttura temporalmente e sistemicamente i flussi informativi nella catena di fornitura dell'appaltatore o del concessionario, ne illustra le interazioni con i processi informativi e decisionali di quest'ultimo all'interno dell'ambiente di condivisione dei dati, descrive la configurazione organizzativa e strumentale degli operatori, precisa le responsabilità degli attori coinvolti.

La maggiore criticità, lo si anticipa, che si è rinvenuta sinora nella prassi corrente sta nel fatto che si tratta di documenti spesso redatti con una scarsa valenza digitale, nel senso «numerico», computazionale, oltre che con un legame assai tenue con la struttura gestionale della commessa.

Esito di questo stato delle cose è che i modelli informativi prodotti e utilizzati sono non di rado disequilibrati tra aspetti geometrico-dimensionali e alfa-numerici, nonché poco rigorosi nella strutturazione dei dati: pecche davvero capitali per il successo della commessa digitalizzata.

Naturalmente, il PdGI acquisisce differenti connotazioni, a seconda che esso nasca per la progettazione, per l'esecuzione, per la gestione o per la demolizione, poiché il grado di produzione o di modificazione dei modelli informativi può variare sostanzialmente.

In altri termini, la sensazione ricorrente è che la transazione avvenga digitalmente, in qualità di supporti, ma che si svolga analogicamente quanto ad approccio mentale e a contenuti.

Il punto non risiede tanto nella prevalenza dei tratti geometrico-dimensionali, giacché questo codice di comunicazione è ovviamente imprescindibile (oltretutto, da esso dipendono molti elementi delle simulazioni di ogni genere, da quelle acustiche a quelle comportamentali), quanto dalla assenza della Data Driveness, cioè della capacità degli operatori di gestire la commessa sulla base di dati computazionali. 

Nei Capitolati Informativi e nei Piani di Gestione Informativa, al netto di diagrammi di flusso piuttosto scontati e ripetitivi e di matrici complicate, ma abbastanza nominali, non appare quasi mai chiaro come si assicuri la fluidità e la coerenza dei dati, come questi ultimi possono influenzare le decisioni.

La cartina da tornasole è offerta dal fatto che, al di là dell'impossibilità dei modelli informativi a comprendere al proprio interno l'esaustività dei dati che compongono il quadro contrattuale, nonostante che una parte dei documenti siano tratti dalla modellazione stessa, i modelli appaiono, relativamente a ciascuna fase temporale, non raramente impostati in maniera disordinata, al netto delle conflittualità dovute a cattiva coordinazione.

Il cosiddetto BIM Execution Plan (BEP o PxP), ovvero, in italiano, Piano di Gestione Informativa (PdGI), è, alla luce di quanto sopra, un documento sempre richiesto nei bandi di gara di servizi e di lavori che fanno riferimento a contratti pubblici o privati, facendo seguito ai Requisiti Informativi (Capitolato Informativo) definiti preventivamente dal committente.

La sua versione più conosciuta internazionalmente è quello predisposto dalla Penn State University, ma del BEP esistono svariate interpretazioni continentali, come quelle offerte da Comisión BIM, Mediaconstruct, SIA, VDI.

Il PdGI, che è conosciuto in Francia come Convention BIM, in Germania come BIM-Abwicklungsplan (BAP) e in Spagna come Plan de Ejecución BIM, rappresentando la risposta che il candidato e l’aggiudicatario propongono al committente.

Purtroppo, non di rado esso è richiesto in assenza dei Requisiti Informativi del committente, appena ricordati, o in presenza di una loro versione largamente insoddisfacente: ciò rappresenta un grave vulnus, che toglie alla committenza una parte considerevole della capacità computazionale (digitale) di indirizzo e di governo della commessa, causando numerosi inconvenienti, a partire dal fatto che, spesso nella versione di Offerta, il PdGI diviene assolutamente autoreferenziale.

In pratica, si delinea un approccio a tre stadi:

- l'orientamento iniziale proposto dal committente;

- la prima replica all'indirizzo del committente da parte dell'offerente;

- la risposta definitiva, evolutiva, avanzata dall'aggiudicatario.

Per questa ragione, si suole distinguere tra Pre-Award e Post-Award BIM Execution Plan, espressioni tradotte in italiano rispettivamente come Offerta di Gestione Informativa e Piano di Gestione Informativa.

In buona sostanza, a causa di ciò che è appena stato detto, la struttura concettuale del Piano di Gestione Informativa dovrebbe riflettere quella del documento a cui deve replicare, il Capitolato Informativo, altrimenti detto Client's o Employer’s ovvero Exchange Information Requirements, redatto, appunto, dalla contro-parte.

Il principale elemento attuale di debolezza dei PdGI è che essi sono spesso malamente collegati ai Project Execution Plan, quasi che Informazione e Decisione, Information Management e Project Management possano viaggiare su binari non comunicanti.

Del PdGI, che nasce nell’ambiente statunitense, esistono differenti versioni, a seconda dei Paesi (dagli Stati Uniti al Regno Unito, dalla Svizzera all’Italia, dalla Germania alla Francia), che differiscono tra loro essenzialmente per la distribuzione nei contenuti nelle sezioni; nessuno di questi, in realtà, presenta una caratterizzazione fortemente numerica, privilegiando aspetti in buona parte testuali.

A questo proposito, dopo averne esaminato i tratti principali si affronteranno le principali criticità che essi presentano. In ogni caso, la razionalità di base consiste nella capacità dell’offerente o del contraente principale di dimostrare di avere compreso appieno i fabbisogni informativi del committente e di essere in grado di rispondervi unitamente alla propria catena di fornitura, a cui tali fabbisogni dovrebbero essere stati diramati in maniera selettiva.

Se tali richieste non fossero presenti, prevalentemente in maniera computazionale, tutto l’impianto concettuale risulterebbe inefficace, riducendo il documento a una serie di buone intenzioni fini a se stesse.

La fase preliminare dell'Offerta di Gestione Informativa è così articolata da parte di una fonte britannica, citata in premessa:

- A project implementation plan (PIP) setting out the capability, competence and experience of potential suppliers bidding for a project, along with quality documentation.

- Goals for collaboration and information modelling

- Project milestones in line with the project programme

- Deliverable strategy

Secondo un'altra fonte, esso dovrebbe così delinearsi:

a) the project implementation plan (PIP) - confirming the capability of the supply chain, software versions, exchange formats, resources from supply chain, PIP is one of the documents used by an employer to assess the capability, competence and experience of potential suppliers bidding for a project, along with quality documentation

b) project goals for collaboration and information modelling; agreed software and views, security, process

c) major project milestones consistent with the project programme; start dates, expectations and milestones, deliverables

d) project information model (PIM) deliverable strategy: listing the specific models/deliverables at each work stage of the project

e) How project team will work to achieve the delivery of Asset Data Requirements (set up on EIRs) at handover

Il Piano di Gestione Informativa, invece, è, secondo la fonte per prima ricordata, nel contesto anglosassone, quadripartito in Management, Planning and documentation, Standard method and procedure, IT solutions, così, a loro volta, suddivise :

Management:

Roles, responsibilities and authorities.

Project milestones in line with the project programme.

Deliverable strategy.

Survey strategy.

Existing legacy data use.

Approval of information.

Authorisation process

Planning and documentation:

Revised project implementation plan (PIP) confirming the capability of the supply chain

Agreed processes for collaboration and modelling.

Agreed matrix of responsibilities.

Task Information Delivery Plan (TIDP) setting out responsibility for delivery of each supplier's information.

Master Information Delivery Plan (MIDP) setting out when project information is to be prepared, by whom and using what protocols and procedures.

Standard method and procedure:

Volume strategy

Origin and orientation

File naming convention

Layer naming convention

Construction tolerances

Drawing sheet templates

Annotation, dimensions, abbreviations and symbols

Attribute data

IT solutions:

Software versions.

Exchange formats.

Process and data management systems

La struttura che propone un'altra fonte è:

a) Data Management - roles, responsibilities and authorities, major project milestones consistent with the project programme, project information model deliverable strategy, survey strategy including the use of point clouds, light detecting and ranging (LIDAR) or global navigation satellite systems (GNSS), existing legacy data use, approval of information, PIM authorization process

b) Planning and Documentation - revised PIP confirming the capability of the supply chain, agreed project processes for collaboration and information modelling, agreed matrix of responsibilities across the supply chain, a. TIDP - Each task team manager shall compile their own TIDP, with its milestones. These are used to convey the responsibility for delivery of each supplier’s information b. MIDP - list the information deliverables for the project, including but not limited to models, drawings or renditions, specifications, equipment schedules, room data sheets, and shall be managed via change control

c) Standard Method and Procedure - the volume strategy, PIM origin and orientation, file naming convention, layer naming convention, agreed construction tolerances for all disciplines, drawing sheet templates, annotation, dimensions, abbreviations, symbols, required attribute data, file types

d) Common Data Environment - establish protocol for sharing of information, permissions, security levels and data backup

e) IT Solutions - software versions, exchange formats, process and data management systems

f) Asset Data Requirements and COBie parameters

La struttura che, invece, propongono, indirettamente, attraverso il Capitolato Informativo, le norme della serie UNI 11337 è suddivisa in una sezione introduttiva, in una sezione tecnica e in una sezione gestionale.

La sezione introduttiva comprende essenzialmente le premesse, la descrizione della commessa e i riferimenti normativi.

La sezione tecnica include la caratterizzazione dell'hardware, del software, dei formati di fornitura dei dati, del sistema comune di coordinate e di specifiche di riferimento, dell'evoluzione informativa, delle competenze in materia di gestione informativa.

La sezione gestionale include gli obiettivi informativi, gli usi, i livelli di sviluppo, i ruoli, le responsabilità e i poteri decisionali, l'analisi dei modelli informativi contenuti nel Capitolato Informativo, l'organizzazione della struttura di gestione della modellazione informativa, le politiche per la tutela delle proprietà intellettuali e della sicurezza dei dati, la proprietà dei modelli informativi, le modalità di condivisione dei dati e delle informazioni, le procedure di verifica, la gestione delle interferenze e delle incoerenze, la modellazione informativa multi-dimensionale, le modalità di archiviazione e di consegna.

Si può osservare, quindi, per prima cosa, che nel documento coesistono istanze diversificate, la prima delle quali consiste nel dimostrare al potenziale committente la propria qualificazione, la propria consuetudine, con i metodi e gli strumenti.

Ciò che, anzitutto, dovrebbe essere assolutamente indispensabile è, come già anticipato, che il committente - cosa che si verifica raramente - possegga computazionalmente la capacità di concepire la struttura spaziale e tecnologica e di strutturarne i relativi dati.

Di conseguenza, l’Organization Breakdown Structure, l’organigramma, che l’offerente indicherà nella apposita sotto-sezione, correlata alla corrispondente matrice di responsabilità e di rischio, dipingerà, prima ipoteticamente, poi praticamente, la struttura della catena di fornitura e, al suo interno, dei singoli soggetti ivi coinvolti.

A proposito, l'Offerta di Gestione Informativa dovrebbe permettere al committente di valutare precocemente le potenziali capacità dell'offerente principale di governare la diffusione dei Requisiti Informativi all'interno della propria catena di fornitura e la competenza di questa a soddisfare tali richieste.

Il che vuol dire che occorre definire, in primo luogo, la compagine dei soggetti coinvolti, orizzontalmente e verticalmente, che avranno un ruolo attivo nella gestione informativa che occorre sia immediatamente correlata matricialmente alle entità elementari (Breakdown Element e relativi oggetti) che andranno a costituire i modelli informativi disciplinari e i modelli informativi aggregati o federati.

Naturalmente, il grado di analiticità degli oggetti (spaziali e tecnologici) che figureranno all'interno della matrice dipenderà dalla fase temporale della commessa, a partire dal Briefing sino a giungere alle Operations & Maintenance.

È, infatti, importante che, sin dall’inizio, la struttura di scomposizione dell’opera commissionata sia computazionalmente formalizzata, cosicché, sia che si tratti di ideazione sia di realizzazione/gestione/demolizione, nonché che venga associata a precisi centri di responsabilità.

Non si dimentichi che la impostazione statunitense menziona i Model Element Author, vale a dire che sottolinea il fatto che l'autorialità, la paternità, sulla creazione o sulla modificazione degli oggetti sia individualizzata e che conti il passaggio da una fase all'altra, intesa come transizione da un soggetto a un altro, da una organizzazione a un'altra.

Non è, infatti, tanto, il passaggio, ad esempio, da LOD 300 a 350, o dall'analogo, che influisce, quanto la sua eventuale attribuzione a identità diverse.

Al contempo, al contributo statunitense si addiziona quello britannico, che enfatizza il possibile sdoppiamento, all'interno dello stesso livello di definizione per ogni singolo oggetto, tra la parte geometrico-dimensionale e la parte alfa-numerica.

Sostanzialmente, allocare le entità da modellare (da configurare secondo una precisa struttura di dati) ai singoli soggetti presenti nell'organigramma vuol dire poter effettuare una valutazione dei rischi che concernono la gestione delle attività che si rispecchiano nei modelli informativi.

Di conseguenza, assume particolare significato la descrizione, qualitativa e quantitativa, dei dispositivi hardware e la loro congruità cogli applicativi software, che dovrà essere verificabile alla luce della correlazione tra entità da modellare o da ri-modellare (nel senso di implementare o di redigere i valori delle proprietà che costituiscono l’oggetto) e soggetti che ne sono incaricati o responsabili.

Questi ultimi dovranno, peraltro, certo vantare un congruo bagaglio curriculare-esperienziale e qualificativo-certificativo, anche se la valutazione non dovrebbe riguardare solo i BIM Specialist, i BIM Coordinator e i BIM Manager, bensì pure la maturità digitale di tutte le singole organizzazioni coinvolte e delle relative risorse umane.

Come si vede, già dalle prime battute, dalle prime parti, del PdGI, il fine del committente è quello di valutare l’idoneità del candidato, effettuando una vera e propria valutazione delle sue capacità.

Chiaramente, avrebbe poco senso nella sezione tecnica isolare alcuni aspetti di natura gestionale che con essa interagiscono e che ritorneranno prepotentemente nella sezione successiva, per definire anche natura e ammontare dei modelli informativi previsti.

Elementi marginali, ma non trascurabili, di questa sotto-sezione sono anche i formati, proprietari e neutri, di scambio dei dati e delle informazioni tra applicativi, così come la definizione del sistema delle coordinate e dei riferimenti, i criteri di denominazione dei contenitori, oltre alla dimensione massima degli stessi.

Sotto questo profilo, desta una certa perplessità la presenza di diagrammi di flusso, piuttosto convenzionali, che illustrano la mappatura della evoluzione delle fasi temporali inerenti alla produzione dei diversi modelli informativi.

Ovviamente, questi aspetti tecnici sono strettamente legati a quelli propri della sezione gestionale, specialmente per quanto riguarda l’articolazione dei livelli di sviluppo e/o di definizione.

Molto spesso, infatti, si scrutano tabelle e matrici in cui, a dispetto della densità, i livelli delle strutture di scomposizione sono largamente insufficienti, l’allocazione delle responsabilità ai Breakdown Element è troppo generica e, infine, qualunque sia la scala (100-500, 0-7, A-G, ecc.), rari sono i disallineamenti tra oggetti e livelli di informazione e di dettaglio.

Soprattutto, la tradizionale successione di valori della progressione poco rivela della transizione di fase e su come essa si pensa possa essere governata.

A proposito dei livelli di progressione, si rammenta che essi tendono, in qualità di metriche, a uniformare le diverse fasi temporali (dalla redazione del documento di indirizzo preliminare alla progettazione esecutiva), ma tali livelli, a loro volta, dovrebbero essere contestualizzati sui BIM Goal e sui BIM Use: dovrebbero essere relativizzati.

Obiettivi e Usi della modellazione informativa potrebbero, inoltre, essere distinti per priorità loro assegnate.

In altre parole, il PdGI dovrebbe risolvere, numericamente, digitalmente, una difficile dialettica tra la nozione di oggetti (che oggettivizzano, appunto, gli elementi dell'opera, passata, presente e futura) e la loro connotazione specifica (nei confronti delle finalità distinte dettate dai Goal e dagli Use).

D’altra parte, in assenza di una rigorosa struttura dei dati di carattere computazionale da parte della committenza, i modelli informativi saranno sempre destrutturati  sul piano geometrico-dimensionale e poveri di contenuti alfa-numerici.

Qui intervengono anche i MIDP che, successivamente sviluppati nei TIDP, non solo consentono di concertare lo sviluppo temporale della modellazione informativa, ma anche di esercitare una prima versione di Business Intelligence da parte del committente a proposito della Supply Chain.

Il MIDP è, infatti, così definito:

The Master Information Delivery Plan (MIDP), is a primary plan which is used to manage the delivery of information during the project lifecycle. It is typically developed by the project delivery manager in collaboration with the task team managers and then used by the project delivery manager to assist in the delivery of project information during the project.

I TIDP sono, invece, intesi come:

The Task Information Delivery Plan (TIDP) is defined by the British Standards Institute as federated lists of information deliverables by each task, including format, date and responsibilities.

It is the responsibility of each task team manager to compile their own TIDP which then assist in the development of the MIDP.  Each task shall have a corresponding milestone that aligns to the overall design and construction programme, taking into consideration any sequencing requirements for the production of information.

Di conseguenza, essentially, the MIDP is a collation of Individual Task Information Delivery Plans (TIDP), prepared by other team members, and includes details of when project information is to be prepared, who is responsible for producing the information as what protocols and procedures for each stage shall be followed.

Gli Information Delivery Plan, in definitiva, rappresentano una ulteriore specificazione, anzitutto temporale, dell'insieme dato da organigrammi, strutture di scomposizione (i Work Breakdown Element e i Deliverable), diagrammi di flusso, matrici di responsabilità e di rischio, in cui, al parametro temporale si aggiunge una descrizione puntuale delle modalità di concertazione.

Da questo punto di vista, ad esempio, la determinazione delle modalità di interazione (segnatamente, la gestione delle riunioni) - persino la presenza di una eventuale BIG Room - appare significativa e rimanda ai modi della collaborazione che solitamente si identifica coi protocolli di scambio delle informazioni.

Vi è, tuttavia, qui un fraintendimento, poiché la cooperazione, concepita come prassi di condivisione e di scambio dei dati e delle informazioni, non può ridursi all'efficacia di protocolli e di dispositivi, senza tenere in conto le strutture contrattuali che ne determinano le convenienze reciproche e i rapporti negoziali di forza.

Nei fatti, il dettaglio della struttura dei dati, a iniziare dall’organizzazione spaziale finalizzata alle Operations & Maintenance, dovrebbe essere correlato a formule contrattuali che permettano o meno una simmetria informativa.

E' palese, dunque, che coesistano l'evoluzione della modellazione informativa secondo una precisa struttura dei dati, la cui variabilità dipende dagli Obiettivi e dagli Usi, la determinazione delle informazioni accessibili a ciascuna delle contro-parti e le pattuizioni contrattuali.

Non a caso, la gestione dei protocolli informativi è, nei PdGI, molto focalizzata sullo stato dei documenti e dei contenitori (file), ma troppo sovente la procedura di approvazione degli stessi è trattata a prescindere dai vincoli contrattuali.

La parte più equivoca del PdGI riguarda, però, gli Obiettivi e gli Usi della modellazione informativa, nel senso che essi, essendo sovente slegati dal Project Execution Plan, sono espressi molto genericamente, sono privi delle Model View Definition (MVD), oltre che degli Information Delivery Manual (IDM) e, in ultima istanza, non consentono davvero alle contro-parti di comprendere quanti e quali modelli informativi si renderanno opportuni.

La MVD è an IFC View Definition, or Model View Definition, MVD, defines a subset of the IFC schema, that is needed to satisfy one or many Exchange Requirements of the AEC industry. The method used and propagated by buildingSMART to define such Exchange Requirements is the Information Delivery Manual.

Questo aspetto, che si presenta sotto una veste fortemente tecnica, proprio per la sua natura connessa agli Obiettivi e agli Usi della modellazione informativa, costituisce una notevole criticità, poiché decide della capacità della committenza di utilizzare, il più possibile, un unico modello informativo aggregato o federato per differenti finalità.

In assenza di questa capacità, è molto probabile che il committente e la sua contro-parte si trovino a dover negoziare oneri imprevisti dovuti alla produzione di un numero elevato di modelli informativi non inizialmente finalizzati.

Una volta che il PdGI abbia descritto modi e tempi della modellazione informativa, il tema successivo riguarderà le modalità di aggregazione dei modelli informativi disciplinari e il loro coordinamento, che si esplicita attraverso la verifica degli stessi, il cosiddetto Code & Model Checking.

Questa attività ha nella Clash Detection l'esemplificazione più immediata, anche se avanza ora la Clash Avoidance, che, tuttavia, più che stare a significare un intento generico di evitare i conflitti, inerisce alla possibilità di creare modalità semi-automatiche di prevenzione delle interferenze e delle incoerenze, attribuendo agli oggetti una maggiore intelligenza (artificiale).

In apparenza, pertanto, il PdGI illustrerà le modalità di gestione di tali conflitti che concernono, in prima istanza, la coerenza.