shelidonMarch 15, 20172 Comments on ISO 19650-1: Organization of information about construction works

Come avevo già annunciato, le ISO 19650 sul BIM sono disponibili per pubblica revisione, fino all’11 aprile, nella sezione Standards Development del British Standard Institute.
Sto procedendo a commentarli, sia come socio UNI al tavolo della 11337 sia come socio BSI. Per non farci mai mancare nulla, ho pensato di rendere disponibili i miei commenti. Dato che la citazione delle ISO è una questione spinosa, cercherò di procedere con la massima cautela e divulgando il meno possibile del testo originale, che è un testo proprietario. Laddove l’organo competente dovesse riscontrare qualche violazione, sono naturalmente sempre disponibile a rivedere ed ementare il testo. Basta che stiamo tutti molto calmi.

ISO 19650-1
Organization of information about construction works
Information Management using Building Information Modelling

Tanto per cominciare, un po’ di contesto. È stato recentemente votato di acquisire le ISO 19650 come norme nazionali riguardo al BIM, con addenda territoriali tra cui figurerà la nostra UNI.

Il valore aggiunto della UNI si riscontra sicuramente in:
– gli approfonditi schemi del processo informativo contenuti nel capitolo 1 nei vari livelli di maturità, mentre nella ISO il processo viene presentato in modo generico e senza considerazione dei vari livelli possibili;
-la declinazione del processo per fasi, sempre nel capitolo 1, che nelle ISO invece viene trattata in modo generico con particolare attenzione solo alle fasi relative al cliente ma scarso approfondimento rispetto alle differenze che sussistono tra le varie fasi di consegna del progetto (viene trattato nel dettaglio dalla 19650-2 e in quella sede saranno evidenziate le principali discrepanze);
– l’approfondimento sui LOD, che nella ISO vengono genericamente presentati come livello di informazione necessaria senza accenni alla stabilità e all’affidabilità del dato;
– il concetto di uso del modello, mancante nelle ISO con conseguenze a cascata su molti punti della norma (si vedano i commenti nel dettaglio, sezione per sezione);
– l’attenzione alla procedura di appalto (capitolo 5) ridotta all’information delivery cycle;
– la declinazione dei flussi di coordinamento, ridotti nella ISO a un semplice atto di federazione del modello o dei container senza che vengano esplicitate le fasi, gli attori e le responsabilità;
– le possibili configurazioni di un Common Data Environment (nella ISO è presentato lo schema concettuale del BS 1192 senza approfondimenti ulteriori).

Nonostante la fase di consegna sia oggetto del capitolo 2, alcuni principi evidenziati nel capitolo 1 costituiscono un conflitto concettuale, evidenziato nel dettaglio ai punti successivi e riassunto nella conclusione.

1. Introduction
Nonostante siano chiari gli intenti della premessa, un particolare punto dell’assunto così com’è formulato al momento risulta scarsamente condivisibile:

«At present, each year considerable resources are spent on training new personnel in approved data creation techniques, coordinating the efforts of supply chain teams and solving problems related to data reproduction. This is considered waste and can be reduced if the concepts and principles within this International Standards are adopted».

Gli sprechi nel settore delle costruzioni, che possono essere ridotti tramite l’adozione di un BIM standardizzato, potrebbero essere riformulati come segue:

«At present, each year considerable resources are spent on making corrections to unstructured data, incorrect managing of data by untrained personnel, solving problems arising from an uncoordinated efforts of supply chain teams and solving problems related to data reuse and reproduction. This is considered waste and can be reduced if the concepts and principles within this International Standards are adopted».

Inoltre, come si vedrà nello Scope, anche l’approccio al costruire e al costruito risulta scarsamente condivisibile.

Part 1: Concepts and Principles

1. Scope
Lo standard è proposto come uno standard valido per tutte le fasi: progettazione, costruzione, gestione e manutenzione. Disgraziatamente questo non è possibile. Proprio per questo motivo, gli standard inglesi sviluppano capitoli diversi, ciascuno con una sua autonomia, per le varie fasi. Riguardo alle fasi, inoltre, l’elenco è il seguente:
– strategic planning;
– initial design and construction;
– day-to-day operation;
– maintenance;
– refurbishment;
– repair;
– end-of-life.
Tra “initial design” e “construction” esiste una fase di sviluppo e ingegnerizzazione, di documentazione, tutta quella fetta di processo che trae il più immediato beneficio dall’uso del BIM. Commenterò maggiormente nel dettaglio questa fase nel capitolo 2, ma la premessa non è incoraggiante.

2. Normative References
Completamente condivisibile la nota riguardo ad un approccio aziendale allineato alla ISO 9001. Per questo motivo la UNI promulga e propone la figura del BIM manager aziendale, spesso trascurata in favore di un “BIM manager di progetto” che altro non è se non un BIM coordinator. Senza un’adeguata infrastruttura aziendale, l’implementazione del BIM risulta disomogenea e non organica, non riesce a penetrare nella filiera di produzione in modo consistente e senza sprechi. Non potrà mai, quindi, essere produttivo.
Non posso tuttavia non pormi delle domande riguardo alla flessibilità di questa norma: presentarla in combinazione alle ISO 9001 di qualità aziendale e alla ISO 55000 sulla gestione del patrimonio non rischia di trasformare il BIM in qualcosa di adatto solo per grandi speculatori? Una posizione politicamente forte, che rinuncia alla diffusione capillare sul mercato e che in paesi del Nord Europa si è già dimostrata problematica sul lungo periodo (si veda ad esempio il contributo di Tomi Henttinen allo scorso BIM forum di Barcellona. Si tratta di un approccio che in nessun modo può favorire il superamento del cosiddetto innovation chasm, il punto in cui l’innovazione deve superare il test delle masse per venire effettivamente adottata.

3. Terms and Definitions
3.4 appointed party. Il termine viene esplicitamente indicato come utilizzabile in presenza o meno di un incarico formale, tuttavia l’appointment formale via contratto è fondamentale perché al contratto sono allegati documenti fondamentali per il buon funzionamento di un processo BIM. La cosa funziona invece per l’appointing party perché può descrivere l’entità nel processo di ricerca di un’appointed party (e quando, quindi, non c’è ancora stato formal appointment).
3.11 client. La differenza tra l’appointing party («person or organization making an appointment or issuing a work instruction») e il cliente («person or organization responsible for initiating a project and approving the brief») deve essere chiarita.
3.13 container. «named persistent set of data and information within a file, system or application stored hierarchy. Example: including directory, subdirectory, data file (including model, document, table, schedule), or distinct sub-set of a data». Il container è originariamente il modello federato. Laddove si intenda allargare il concetto a una directory di informazioni e file, è necessario specificare che tutte le informazioni devono essere indicizzate all’interno di un modello primario (che sia grafico o un database). Ad esempio, se il container è composto da un modello e dalle schede informative degli oggetti in formato PDF, ad esempio, all’interno del modello devono essere presenti i rimandi alle schede. Correlazione di cui la UNI si occupa invece nel dettaglio.
3.15 data. La definizione «observations that in context yield information» è completamente in disaccordo con la definizione data dalle PAS 1192-2 ovvero «information stored but not yet interpreted or analyzed». L’espressione observation inoltre sarebbe in sé da includere nel glossario, perché estremamente specifica all’interno dell’edilizia (si vedano ad esempio le OCS).
3.16 delivery phase. La fase di delivery è la parte finale di ogni fase, progettuale o costruttiva. La definizione data («the part […] during  which the asset is designed, constructed and commissioned») impedirebbe ad esempio di parlare di delivery phase per la fase di consegna di un Asset Information Model (un modello sviluppato per la manutenzione). Al contrario il circolo need – execution – delivery delineato nelle PAS è sufficientemente flessibile da adattarsi anche alle richieste successive alla prima realizzazione dell’edificio. In generale si nota, nell’intero draft delle ISO, una scarsissima attenzione al riuso dell’edificio, mentre al contrario viene quasi data per scontata la sua demolizione.
3.19 exchange information requirements (EIR).  Assolutamente no. Non si utilizza un acronimo già in uso nell’industria per indicare qualcosa di diverso: ne può nascere solo confusione. Si consiglia di modificare in Communication of Information Requirements (CIR).
3.20 handback e 3.21 handover i termini sono invertiti rispetto all’uso comune e vengono rispettivamente indicati l’uno come la risposta del fornitore ad un handover di informazioni effettuato dal cliente. L’handover tuttavia è attualmente la consegna da parte del delivery team, anche perché quello che viene definito handover si effettuerebbe secondo i vari documenti di Information Requirements. Si parla di handover solo quando si tratta di un modello, e non di specifiche. In questo senso, anche la consegna di un Asset Information Model al delivery team incaricato di una conversione per la destinazione d’uso sarebbe un handover. Non c’è nessuna necessità di avere due termini diversi.
3.26 information standard. Per definizione, non può trattarsi di uno standard per i data.
3.28 level of information need. Il concetto dovrebbe concentrarsi sul livello di affidabilità delle informazioni per ogni categoria e necessaria in ogni fase (affidabilità declinate come e sulla base di usi del modello definiti quando?), ma riguardo a questo avrò modo di dilungarmi in seguito.
3.40 revision e 3.45 version. Anche in questo caso, i termini sono completamente invertiti rispetto al loro utilizzo che è prassi, ad esempio, nel Product Lifecycle Management. Le revisioni sono sequenze di modifiche minori all’interno di un set che rimane sostanzialmente uguale a se stesso (ad esempio lo spostamento di un pilastro). La versione prevede una modifica che rende sostanzialmente differente la configurazione di progetto (ad esempio un ridisegno completo della maglia strutturale).

4. Asset and project information, perspectives and collaborative working
4.1 Principles e 4.2 Supporting container-based collaborative working
Il modello viene proposto come fonte centrale di tutte le informazioni relative all’edificio, il che è estremamente corretto.
In seconda battuta tuttavia si dice che un modello può contenere:
– modelli tridimensionali;
– l’elenco delle attrezzature (equipment schedules);
– le specifiche tecniche;
– i certificati delle prove;
– le garanzie.
Tuttavia non si fa riferimento ai vari modi in cui queste informazioni possono essere connesse, derivate o ricondotte all’information model. Questa parte, estremamente ricca nella definizione del livelli operata dalla UNI 11337, costituisce di fatto il livello di maturità del processo BIM. La Figura 1 delle ISO, una reinterpretazione cubista del triangolo di Bew, rimane nella norma un dato puramente decorativo. Le carenze nella definizione di container, indipendentemente dalla sua ambiguità rispetto al modello federato che è strumento proprio del Level 2, hanno pesantissime ripercussioni sull’organicità della norma: il container dello Stage 1, in cui l’informazione è strutturata ma non centralizzata nel modello, viene indicato come oggetto di questa norma ma non ne vengono declinate le modalità di information management che sono drasticamente diverse e tecnicamente su un altro livello di complessità rispetto a quelle dello Stage 2. Inoltre, il Level 1 britannico non è di per sé considerato Building Information Modelling proprio per la non centralità del modello nel processo: risulta bizzarra quindi la contraddizione in termini presentata nello schema della ISO, in cui uno Stage 1 (non BIM) viene considerato normato dalla ISO 19650 ma lo Stage 3 (Database based Information Model) è lasciato fuori dalla norma.
4.3 Information management perspectives
Il capitolo illustra le prospettive da tenere in considerazione durante lo sviluppo di una strategia per la gestione delle informazioni. Queste prospettive sono quelle di:
– proprietario dell’immobile, che ha il compito di prendere decisioni strategiche tramite strumenti come il Business Plan e la Life Cycle Cost Analysis;
– utente finale dell’immobile, per identificare le necessità degli utenti e stabilire i principi di qualità del progetto che sarà: utilizza strumenti come il project brief;
– management del progetto o gestore dell’immobile, che deve pianificare il lavoro, mobilizzare le risorse giuste, coordinare e tenere sotto controllo lo sviluppo dei lavori: utilizza strumenti gestionali (organigramma, definizioni dei ruoli);
– società al contorno, una prospettiva atta a verificare che l’interesse della comunità venga salvaguardato durante il ciclo progettuale: utilizza strumenti politici e di concessione.
Nonostante le prospettive siano condivisibili, ad esse non corrispondono altrettanti attori: un conto è definire la prospettiva e un altro conto è definire chi fisicamente si debba occupare di stilare i documenti, cosa che la norma non prende in considerazione o considera in maniera superficiale. Molte di queste prospettive ad esempio sono responsabilità del progettista e questo elenco apparentemente innocente si traduce in una serie specifica di model uses che incidono drasticamente nella strutturazione e nella gestione del modello alle varie fasi.
Il modello tuttavia sembra marginale in questo discorso e anche l’elenco dei documenti risulta confuso. Risulta un po’ strano ad esempio vedere citato il Business Case tra gli strumenti del proprietario, perché dovrebbe essere uno strumento preliminare alle decisioni circa l’avvio o meno del progetto: gli strumenti elencati dovrebbero essere declinati a seconda della fase, dato che strumenti da utilizzare in studio di fattibilità non sono decisamente gli stessi da utilizzare durante lo sviluppo del progetto e la fattibilità è un punto cruciale del processo BIM. Altrettanto bizzarro è vedere Area Plans tra gli esempi di consegna nel settore con prospettiva sociale, come a implicare che le pubbliche amministrazioni sono e sempre saranno analogiche. Una prospettiva miope per una norma che si inserisce all’interno dell’innovazione digitale di processo. La tabella 1 al momento comprende tre campi:
a) prospettiva;
b) obiettivo;
c) esempi di deliverables.
La nota attuale «the example deliverables are relevant to the point of view of each perspective and do not indicate ownership of the deliverables» di fatto invalida completamente la tabella.

Dovrebbe essere ricompilata comprendendo:
a) fasi, come prima suddivisione della tabella;
b) prospettiva, come accade in questo momento ma cui mancano completamente ad esempio la prospettiva tecnica (ulteriori informazioni possono essere reperite qui, dove si trova una conversione in italiano dei tre punti costituenti l’Employer Information Requirements nella prospettiva britannica);
c) scopo, come accade in questo momento;
d) fasi coinvolte, come filtro per la colonna successiva;
e) figure coinvolte, più d’una per ogni prospettiva e probabilmente declinate secondo le fasi del progetto: il BIM è collaborazione e anche il lavoro di definizione della strategia dovrebbe essere impostato in modo collaborativo;
f) documenti, declinati secondo il punto 3: figure diverse producono e si rifanno a documenti diversi a seconda della fase del progetto in cui si trovano.

5. Definition of Requirements
5.1 Principles
La sezione individua, seppur non esplicitamente, una selezione di model uses dal punto di vista del proprietario/operatore dell’immobile (a  mio parere erroneamente assimilati nella stessa figura). Questi usi, secondo la norma, possono essere:
– la creazione di un registro di asset, che poi viene indocata essere in conformità con la ISO 55000 e che come tale dovrebbe risultare in un documento di information requirements da strutturare prima a livello aziendale / di organizzazione;
– supporto al business case (che tuttavia dovrebbe essere fatto prima della partenza del progetto). All’interno di questa voce vengono poi declinati dei punti più specifici relativi a vari aspetti di un brief:
– gestione della capienza e dell’utilizzo degli spazi, in relazione ad una struttura di Project Portfolio Management che anche in questo caso presuppone un coordinamento BIM a livello aziendale da parte del cliente/operatore;
– gestione della sicurezza e della sorveglianza;
– supporto ad un futuro cambio di destinazione d’uso (nota: si usa il termine “repurposing” che tuttavia è abbastanza specifico per gli oggetti e poco o mai utilizzato per gli immobili): di questo uso si elencano requisiti relativi alla capienza degli spazi: aree, volumi, occupazioni, condizioni ambientali, portanza strutturale (alcuni di questi valori sono già tecnicamente presenti in ogni modello ben fatto, ma altri prevedono operazioni di implementazione a livello sia tecnico che di workflow);
– analisi dell’impatto ambientale (sull’esistente o in previsione), niente di meno che qualunque analisi, dai costi alla CO2, dall’analisi energetica all’analisi dei rifiuti, dal consumo d’acqua fino a non meglio precisati altri effetti ambientali: inutile dire che ciascuna di queste analisi, specie se non qualitativa ma quantitativa, è uno specifico uso del modello, spesso sviluppato con la consulenza di uno specialista, che non può essere data per scontata, che implica un particolare modo di strutturare i modelli, la cui richiesta deve essere accuratamente valutata e alla cui consegna deve corrispondere un’adeguata remunerazione del professionista cui viene affidata;
– simulazioni dell’attività, ovvero modellazione delle informazioni necessarie al normale funzionamento dell’asset in modo da poter fare proiezioni di costi (una richiesta poco ambiziosa che probabilmente dovrebbe includere consumi quali il consumo energetico ma anche l’impatto di manutenzione e sostituzione pezzi, fino allo stipendio del bidello);
– manutenzione e riparazioni, ovvero informazioni circa le attività di manutenzione consigliate, la pianificazione preliminare di attività di manutenzione consigliate sia come tempistica che come costo (anche questa è una richiesta poco ambiziosa e tecnicamente semplice…);
– informazione circa la sostituzione di pezzi e materiali con particolare accento sulle strategie di smaltimento e riciclaggio;
– simulazioni per smantellamento e smaltimento, l’apice del ridicolo: in un sistema che dovrebbe disincentivare le demolizioni e facilitare le riconversioni, si suggerisce anche questo come uso del modello.
– supporto per le verifiche di conformità normativa e responsabilità regolamentare: il proprietario/operatore dovrebbe specificare le informazioni necessarie per garantire la salute e la sicurezza degli utenti nell’asset (si suppone e si spera che negli “utenti” siano inclusi anche gli operatori).

Anche in questa sezione, c’è una pesante confusione tra i requirements di fine fase o, nel caso si voglia considerare “progetto” anche un progetto che si chiuda immediatamente dopo la fattibilità, tra i requirements e le varie fasi.
Inoltre, si fa un uso piuttosto spigliato delle forme verbali: all’interno di un intero elenco introdotto come “might include” troviamo espressioni piuttosto forti come “should require”. L’utilizzo delle forme verbali in una norma, nella lingua inglese, è piuttosto rigoroso.

The provisions of this PAS are presented in roman (i.e. upright) type.
Its requirements are expressed in sentences in which the principal auxiliary verb is “shall”.
Its recommendations are expressed in sentences in which the principal auxiliary verb is “should”.
The use of the auxiliary verb “can” indicates that something is technically possible
and the auxiliary verb “may” indicates permission.
(PAS 1192-2)

La clausola finale «information requirements associated with the delivery phase of an asset should be espressed in terms of the project stages that the project client or the supply chain intends to use» dovrebbe essere spostata all’inizio e utilizzata come lente per rivedere l’intero elenco: se si desidera declinare tutti quegli usi (cosa che comunque mi sentirei di sconsigliare) una norma dovrebbe prendersi la responsabilità di generare una matrice con fasi e responsabili. Inoltre, se davvero si desidera mantenere documenti differenti per l’Organizational Information Requirements e il Project Information Requirements, è necessario indicare quali dei vari usi appartengono a quale documento, cui corrisponde un diverso livello della gerarchia aziendale.

Da ricordare inoltre che ogni requirement deve essere contrattuale e tutti questi usi hanno un impatto sulla gestione BIM del progetto e sul Delivery Level: i dati non crescono sugli alberi, devono inseriti da qualcuno all’interno di un’architettura impostata in fase di impostazione del modello.

Una ulteriore nota si rende necessaria sulla terminologia utilizzata a livello di verbi d’azione.

Informazioni come queste dovrebbero essere inserite nel glossario iniziale perché influenzano l’intera scrittura della norma.
Alla luce di questo sistema, risulta difficile credere alla Figura 2, in cui un Project Information Model contribuisce a creare un Asset Information Model più o meno per magia, a seguito di un contatto indiretto con gli Asset Information Requirements. Le informazioni contenute nell’Asset Information Requirements sono usi del modello e devono essere specificati all’interno degli Employer Information Requirements visti nel suo complesso: non possono essere aggiunte in modo posticcio dall’entità astratta che, secondo le norme, dovrebbe trasformare il Project Information Model in un Asset Information Model. Molti usi elencati a titolo esemplificativo implicano impostazioni radicalmente diverse a livello di information & model management.

5.2 Organizational information requirements
5.3 Asset information requirements
5.4 Project information requirements
5.5 Exchange information requirements
Le sezioni elencano lo scopo dei documenti e, per alcune voci, da chi vengono generati. Una tabella riassuntiva sarebbe decisamente più efficace e dovrebbe essere integrata, ammesso di voler conservare questo circonvoluto sistema di input.

6. The Information Delivery Cycle
6.1 Principles
Il paragrafo elenca i quattro punti per la condivisione delle informazioni, ovvero:
a) le informazioni sono necessarie per la gestione dell’edificio in tutte le sue fasi, inclusa quella in cui si sta valutando se costruirlo o meno;
b) le informazioni vengono specificate in modo progressivo;
c) le informazioni devono essere trasmesse a tutti i livelli della catena produttiva;
d) la condivisione e il coordinamento delle informazioni viene trasferita tramite Information Exchange e gestita attraverso il Common Data Environment.
Nonostante siano tutti punti condivisibili, l’ultimo crea qualche problema tecnico. Se il Common Data Environment diventa uno strumento di gestione dei dati, e non di condivisione, lo schema è quello dello Stage 3 (database-based model), che tuttavia viene indicato come non oggetto di questa norma.
6.2 The Information Life Cycle
La sezione fornisce un quadro di integrazione tra la ISO 19650 e le altre norme che regolamentano le attività a livelli non di costruzione dell’asset. Queste norme sono:
– ISO 55000 per l’Asset Management;
– ISO 9001 per la gestione aziendale;
– ISO 8000 per la qualità dei dati;
– ISO 27000 per la gestione in sicurezza delle informazioni.
L’integrazione di queste norme all’interno di un sistema di Building Information Modelling, sia a livello di gestione che a livello di produzione, sono tuttavia un affare piuttosto serio. Seppur apprezzi di vedere consigliata la ISO 9001, anche in questo caso bisognerebbe specificare per quali parti della filiera sono maggiormente rilevanti quali norme. Dovrebbero poi essere fatti una serie di quaderni, di linee guida per mettere a sistema le varie norme: si tratta di un lavoro che al momento ben pochi possono fare.
Qualcuno poi mi dovrebbe spiegare qual è l’integrazione della norma con altre norme citate in bibliografia e in particolare:
– ISO 16793, Nuclear fuel technology — Guide for ceramographic preparation of UO2 sintered pellets for microstructure examination (non sto scherzando).
Ho inoltre forti dubbi circa l’integrazione con altre norme citate in bibliografia e la cui integrazione pure sarebbe opportuna, ovvero:
– ISO 22263, Organization of information about construction works — Framework for management of project information;
– ISO 27000, Information technology — Security techniques;
– ISO 29481, Building information models — Information delivery manual.

6.3 Setting information requirements and planning for information delivery
6.3.1 General Principles e 6.3.2 Supply chain provides information for asset / owner / operator or project client decisions
Il sistema generale tra appointing party e appointed party è simile a quello già delineato nella PAS 1192-2(r2): a ogni requirement corrisponde una reazione da parte dell’appointed party in cui vengono declinate le modalità di consegna di quella informazione.

Portando questo ragionamento alle sue estreme conseguenze, ci troviamo in una situazione del genere:

Tuttavia, addentrandosi nella lettura dei paragrafi successivi (Figura 6 per esempio), sembra chiaro che queste Information Exchange siano estrazioni di informazioni dal modello informativo, effettuate in specifici punti del processo ovvero i punti in cui gli stakeholder hanno necessità di prendere decisioni supportate da queste informazioni. Anziché promuovere la figura di un cliente coinvolto all’interno del flusso costante di dati, sembra essere presentata qui una strategia assistenzialista che, seppur nell’ottica di quella grande attenzione al cliente su cui si basa tutto il sistema di qualità ISO, seleziona specifici dati e li astrae dal processo coordinato. I rischi sono immediatamente chiari se si fa un semplice esempio inserito in un workflow reale.

Con un cliente esterno al processo, ogni Information Exchange per decisioni chiave è una consegna. Questo significa che il lavoro viene fermato, in attesa delle sue decisioni, e si tratta di un momento generalmente utilizzato dal BIM coordinator per ristrutturare i modelli e le architetture di gestione dati in vista della fase successiva. Il coinvolgimento del cliente direttamente sul modello è cruciale per ridurre le tempistiche e consentire la realizzazione di analisi dinamiche: perdere di vista cosa è uso del modello, cosa è oggetto di consegna e cosa invece è lavoro collaborativo sui dati del modello significa perdere di vista il vantaggio principale del BIM ed appesantire la filiera di produzione con una sovrastruttura decisi0nale statica che farebbe da zavorra ad una struttura per propria natura dinamica.

Inoltre, per ogni consegna delle informazioni di progetto viene richiesto di portare avanti un risk assessment in modo da verificare quanto sia probabile che l’appointed party non consegni le informazioni richieste.
Se le informazioni richieste sono quelle del punto 5.1, il risk assessment dovrebbe essere un’operazione piuttosto facile…

6.3.3 Information verification and validation at start and end of project stages e 6.3.4 Information is drawn from the whole supply chain
Lo stesso problema di fasi si riscontra in questo paragrafo che dovrebbe descrivere la relazione tra la consegna delle informazioni e la loro verifica/validazione (due termini che dovrebbero essere inseriti nel glossario all’inizio, per evitare fraintendimenti). La Figura 7 della norma risulta quantomeno confusa. Lo schema completo dovrebbe essere qualcosa del genere:

Se la chiusura di fase implica un passaggio di mano del modello, la situazione si complica. Un doppio controllo delle informazioni viene infatti previsto dalla norma, ma assegnato all’attore sbagliato: se il modello passa dal Consulente A al Consulente B ad esempio, gli Information Requirements a quel punto vengono stilati, sotto forma operativa di BIM Execution Plan, dal consulente successivo (Consulente B) ed è il cliente a dover effettuare la submission perché si trova nella strana posizione mista di cliente e fornitore. Se il modello non è adatto per l’utilizzo da parte del Consulente B, deve essere messo a budget un adattamento della sua struttura o un aggiornamento dei suoi dati.

7. Project and Asset information management roles
7.1 Principles
Per quanto riguarda i ruoli, i principi base evidenziati nella norma sono:
– sarebbe meglio che i ruoli di information management non coincidessero con ruoli che abbiano una responsabilità progettuale (ma non è chiaro se si parli a livello di organizzazione, quindi il BIM leading consultant non può essere l’architetto, o a livello di individuo, quindi il BIM coordinator non può essere il capoprogetto);
– ruoli e responsabilità elencati nella norma non coincidono con eventuali titoli lavorativi, quindi ad esempio si parla di Information Management e non di BIM Coordinator.
Ne aggiungo uno: nonostante la norma faccia un abbozzo di distinzione tra le informazioni da gestire a livello aziendale e quelle da gestire a livello di progetto, questa distinzione decade nel capitolo 7 limitandosi a distinguere tra la gestione delle informazioni a livello di progetto globale e la gestione delle informazioni a livello di task team specifico. Il terzo livello più alto (quello del BIM manager non di progetto) deve essere reintrodotto perché sia possibile raggiungere buona parte degli obiettivi posti dalla norma a quel livello.
7.2 Roles for information production and information process
I ruoli descritti in questa sezione ricoprono:
– la produzione di informazioni;
– il coordinamento delle informazioni prodotte con quelle provenienti da altre fonti (attività al momento indicata come inclusa nella produzione di informazioni ma che deve necessariamente essere scorporata in quanto non operativa ma gestionale);
– la gestione del processo informativo, compresa la definizione di procedure e i controlli di aderenza ai metodi concordati.

In situazioni complesse, viene inoltre indicata la possibilità di individuare una figura chiamata information facilitator o information process manager. La suddivisione tra produzione e coordinamento viene quindi proposta solo per progetti particolarmente complessi mentre deve necessariamente essere imposta come punto fondamentale per qualunque progetto degno di essere chiamato tale (in opposizione al business as usual). Tuttavia, dato che la sezione si pone esplicitamente l’obiettivo di indicare funzioni e non ruoli, dovrebbero essere riformulate come information facilitation o information process management. L’ultima cosa di cui abbiamo bisogno è inventare nuovi ruoli.

A questo proposito, particolarmente problematico risulta l’Annex A, in cui viene proposta una matrice di ruoli con relative autorità. Questi ruoli sarebbero:
a) Information Facilitator, una specie di assistente sociale al livello del BIM coordinator, che dovrebbe favorire la comunicazione tra i vari autori delle informazioni, facilitando lo svolgersi di riunioni e i processi collaborativi: comunica con il cliente, ma coordina gli utenti e dovrebbe avere autorità di project management. Il ruolo del facilitator, tuttavia, in project management è abbastanza specifico: si tratta di una figura con competenze di project management che agisce sulla breve durata di un singolo task o di una prospettiva circoscritta. Si potrebbe parlare di facilitator ad esempio per un BIM coordinator incaricato solo della clash detection, che è una parte parziale del processo di modellazione informativa, ma l’esempio è erroneamente portato per la figura al punto d;
b) Information coordinator, che dovrebbe essere il nostro BIM coordinator o, meglio, il BIM coordinator del singolo consulente: coordina le informazioni, le configura (in che senso?), rende possibile lo scambio interoperabile delle informazioni tra vari formati, può essere fusa con la figura al punto d se non fosse che a livello di responsabilità fa clash detection ma non ha l’autorità di proporre soluzioni a queste clash;
c) Information author, ovvero il progettista: deve essere spostato in posizione a, in fondo al resto della filiera di gestione;
d) Interface manager, ovvero un BIM coordinator che si occupa solo di clash detection, con l’autorità di proporre soluzioni in opposizione all’information coordinator: il suo ruolo è di supporto, eventualmente, a un coordinatore delle informazioni (un facilitator, in questo senso) e quindi deve essere spostato;
e) Task Information manager, dirige la produzione delle informazioni nel rispetto degli standard, dei metodi e delle procedure concordate: se è di progetto, si tratta di un BIM coordinator. Se è di azienda, invece, si tratta di un BIM manager e si posiziona a un ruolo superiore dell’architettura aziendale.
f) Project Information manager, un uomo il cui ruolo è estremamente confuso: definisce gli information requirements (quindi opera dal lato del cliente a livello gestionale), rende possibile lo scambio di informazioni tramite il Common Data Environment  (quindi opera a livello di progetto dal lato del cliente o per suo conto dal lato del BIM leading consultant), mantiene e riceve le informazioni del modello (quindi è un BIM coordinator a livello del BIM leading consultant), favorisce l’integrazione e il coordinamento delle informazioni tra i vari modelli (quindi è di nuovo il BIM coordinator responsabile del modello federato), popola di informazioni l’information exchange con dati estratti dal modello (quindi è un data entry specialist). Non serve essere un esperto di project management aziendale per rendersi conto che questa figura ha delle serie contraddizioni e deve essere spacchettata sulle altre.
In generale è drammatica e preoccupante la banalizzazione del BIM alla clash detection: un documento degno degli anni ’80. Se si desiderano fare degli esempi, è necessario avere un esempio puramente informativo dopo l’esempio puramente geometrico: un buon esempio potrebbe essere il Quantity Take Off.

7.3 Asset information management roles
Ancora una volta, la gestione dell’asset o del portfolio di asset viene posta sullo stesso piano, mentre una è un’attività a livello aziendale e l’altra è un’attività a livello locale. Particolare accento viene posto sulla necessità di strutturare le informazioni in modo da facilitare l’avvicendarsi di diverse figure nello stesso ruolo, ma nessu riferimento viene fornito circa lo standard per la gestione di queste informazioni (la relativa ISO dovrebbe fornire indicazioni in questo senso o, in caso contrario, una delle due è completamente da rivedere nelle sue citazioni incrociate).
Indipendentemente da questo, anche a livello di asset la persona in ruolo gestionale dovrebbe:
– validare le informazioni fornite dai fornitori o da altre parti in causa;
– autorizzare la loro inclusione all’interno del modello.
Nessuna indicazione viene data su chi ha il compito di:
– manutenere, gestire le revisioni e ordinare gli aggiornamenti di versione del modello (ruolo cruciale per una parte di processo che si spalma potenzialmente su decenni);
– valutare l’aggiornamento dell’architettura informativa (ruolo simile al precedente ma a livello aziendale);
– inserire fisicamente le informazioni all’interno del modello (ruolo operativo).
Sembra che a livello di asset esista solo il gestionale di progetto (nostro BIM coordinator) ma non il gestionale aziendale (nostro BIM manager) e non vengono presi in considerazione ruoli operativi. Chi dovrebbe inserire le informazioni nell’Asset Model? Una squadra dedicata, come credo, oppure si pensa che l’aggiornamento del modello possa essere demandato alle maestranze dedicate alle operazioni fisiche di manutenzione?
7.4 Project Information management roles
Responsabilità specifica di progetto, che ha il compito di:
– stabilire gli standard informativi;
– stabilire metodi e procedure di produzione;
– definire il Common Data Environment.
Il suo livello di coinvolgimento nella filiera di produzione tuttavia cambia drasticamente le responsabilità di questa figura. E’ necessario definire se si tratta di una figura in seno al cliente, nel qual caso non può dettare metodi e procedure di produzione ma solo gli standard informativi di output, se si tratta del BIM leading consultant, o se è semplicemente il gestore del Common Data Environment.
7.5 Task information management roles
Information management a livello di singola squadra, considerato solo per progetti particolarmente grossi. Si tratta probabilmente dei BIM coordinator locali, in opposizione al coordinator del leading consultant, e come tale si tratta di una figura necessaria. Ogni entità di produzione con autonomia deve avere il proprio coordinatore.

8. Container-based collaborative working
Il principio di base fornisce come assunto una situazione che invece è transitoria e non completamente condivisibile, ovvero l’identificazione di un sistema (il container) come sorgente unico delle informazioni in opposizione al singolo file (modello). I principi base elencati sono i seguenti:
a) si lavora al level 2 con un ulteriore grado di rallentamento: ogni originator produce le proprie informazioni, utilizzando informazioni prodotte da altri solo quando verificate. La modalità di utilizzo di queste informazioni tuttavia apre la strada ad ogni livello collaborativo possibile, perché tali informazioni possono essere utilizzate tramite:
– riferimento;
– modello federato;
– scambio diretto di informazioni.
Se lo scambio diretto di informazioni si traduce in un sistema di flusso diretto da un modello all’altro (vedi Flux), non si sta più parlando di un level 2, le responsabilità tra le parti sfumano. Bisogna essere rigorosi nell’indicare una metodologia o nel delineare vari scenari per l’utilizzo di queste informazioni prodotte da terze parti.
D’altro canto, la possibilità di utilizzare solo informazioni verificate deve essere spiegata ulteriormente: è necessario un certo livello di automatismo (garantito ad esempio dal sistema dei LOD) per velocizzare la produzione di un progetto integrato.
b) è necessario fornire information requirements che siano chiaramente definiti, sia a livello strategico (da parte degli investitori ad esempio) che ad un livello qui definito tattico (l’operator). I vari livelli devono essere chiamati sempre nello stesso modo: si veda ad esempio la terminologia utilizzata nella sezione 4.
c) è necessario valutare l’approccio proposto, la capacità e le possibilità di ogni contractor o consulente prima dell’assegnazione dell’incarico (una procedura consolidata, il Consultant Capabilities Assessment, che meriterebbe di essere esplicitamente citata). Il punto è maggiormente esplorato nel capitolo successivo.
d) deve essere fornito un Common Data Environment che in questo punto tuttavia viene presentato come un luogo in cui immagazzinare le informazioni, in opposizione al punto 6.1 in cui si descriveva come un sistema di gestione dei dati.
e) i modelli devono essere sviluppati con un numero di tecnologie che siano in grado di essere conformi a questi standard (ovvero, al momento, nessuna);
f) i modelli devono essere messi al sicuro da accessi non autorizzati, dalla perdita di dati, dalla corruzione della struttura, dal degrado e dall’invecchiamento. Aspetti cui altre norme dedicano interi capitoli vengono qui liquidati in un paragrafo. Nessun sistema e nessuna tecnologia garantisce di mettere completamente al riparo dalla corruzione il modello. Ciò che può essere messo parzialmente al riparo dalla perdita di dati è il container, ad esempio con sistemi di backup e ridondanza, ma se avessi un soldino per ogni volta che ho visto corrompersi un file di Revit probabilmente potrei smettere di lavorare.

9. Appointed party capability and capacity
9.1 Principles
I sistemi di valutazione proposti per un fornitore sono tre:
a) un assessment da parte del committente;
b) un’autocertificazione da parte del fornitore stesso;
c) un assessment commissionato a una terza parte.
Inutile dire che il punto b è completamente inaccettabile e legittima una giungla di autocertificazioni che non può trovare spazio in una norma.
Viene inoltre lasciata la possibilità di portare avanti l’assessment solo per fornitori nuovi, mentre i fornitori storici possono mantenere il loro status di fornitore già approvato. Il sistema è accettabile solo se realizzato in simbiosi con il sistema di qualità della ISO 9001, che prevede un feedback dopo ogni attività del fornitore e il controllo di indicatori con una media al di sotto della quale un fornitore perde il suo status.
9.2 Extent of capability and capacity assessment
Il paragrafo fornisce alcune voci che dovrebbero essere incluse in un assessment, ovvero:
a) il livello di dedizione con cui si intende essere conformi agli standard e agli information requirements;
b) l’esperienza dell’azienda e del team in particolare per quanto riguarda il lavoro collaborativo container-based;
c) le possibilità di accesso e l’esperienza nell’utilizzo delle tecnologie specificate o previste negli information requirements;
d) l’esperienza dell’azienda e del team in particolare su quello specifico tipo di progetto.
Il punto a) non dev’essere una risposta a un assessment (nessuno mai risponderebbe che intende profondere uno scarso impegno nel rispetto degli standard) ma un vero e proprio impegno che sia parte integrante del contratto di fornitura.
Il verbo “should” che introduce la sezione dovrebbe (no pun intended) essere verificato rispetto a un glossario simile a quello riportato dalle PAS 1192.

10. Information Delivery Planning
10.1 Principles
La sezione fornisce un indice per gli Information Delivery Plans che costituiscono, di fatto, il BIM Execution Plan. I punti che dovrebbero essere definiti nell’Information Delivery Plan secondo la norma sono:
a) come le informazioni rispetteranno le specifiche;
b) quando verranno consegnate le informazioni, rispetto alle fasi di progetto, con relative date;
c) come saranno consegnate le informazioni;
d) quali informazioni saranno consegnate;
e) chi consegnerà le informazioni.
Molte delle voci proposte non sono altro che le informazioni normalmente riassunte nella Model Production and Delivery Table, che comprende:
a) come verranno consegnate le informazioni, rispetto alle fasi di progetto, con relative date;
b) quali informazioni saranno consegnate, per quale uso del modello e a quale livello di sviluppo;
c) chi consegnerà le informazioni.
La tabella è un documento contrattuale e quindi non può essere rimandata alla fase di produzione dell’Information Delivery Plan. Ciò che può essere demandato a una fase successiva è esclusivamente il punto a), che dovrebbe essere espanso e maggiormente esplorato in questa sezione degli standard.
10.2 Timing of Information Delivery
Nessun commento: la sezione si raccomanda di stilare una time schedule che tenga in considerazione tutte le fasi, inclusa la costruzione e il procurement.
10.3 Responsibility Matrix
La matrice di responsabilità secondo la norma dovrebbe specificare:
a) i vari ruoli di information management;
b) le varie responsabilità e i vari oggetti di consegna.
La matrice dovrebbe essere espansa a ricalcare quanto commentato nella sezione 7 e, in generale, essere coerente con quella struttura.
10.4 Defining the scope of information to be delivered
Il punto illustrato nel titolo è il più critico, oggetto di molti dei commenti nelle sezioni precedenti. Tuttavia il contenuto della sezione si riduce a essere un’indicazione di strategia riguardo all’uso dei volumi (sezione 7.6 della PAS 1192-2, da cui provengono molti degli schemi riportati).
Per chiarezza, la PAS 1192-2 identifica nella strategia dei volumi quella che noi chiamiamo suddivisione del modello. La sezione, essendo presa dagli standard britannici, è ben fatta e prevede la possibilità di identificare uno o più set di volumi a seconda degli usi del modello.

Volume: manageable spatial subdivision of a project, defined by
the project team as a subdivision of the overall project
that allows more than one person to work on the
project models simultaneously and consistent with the
analysis and design process.
(PAS 1192-2)

Si tratta di un punto cruciale del model management e le PAS specificano che, per lavorare al Level 2, «each volume or subdivision is a reference file». Tuttavia questa suddivisione avviene anche in conseguenza degli usi.
Manca purtroppo una chiara strategia riguardo all’individuazione di questi model uses. Personalmente sull’argomento consiglio l’episodio 24 del BIM Think Space, in cui il problema viene esplorato da vari punti di vista. Dato che la norma si sbilancia a consigliare diversi usi, le strade sono due:
– individuare una strategia chiara per l’individuazione di questi usi;
– stralciare molte parti e limitarsi a una spiegazione chiara del concetto di uso.

11. Managing the collaborative production of information
11.1 Principles
La sezione pone tre principi:
– è necessario utilizzare un Common Data Environment, anche se non si entra nel merito circa la frequenza della condivisione: trattandosi di un Level 2 si suppone che le condivisioni siano periodiche, e non continuative, il che presuppone dei cicli di coordinamento che mi aspetto specificati in una ISO;
– l’obiettivo principale è il coordinamento, sia spaziale che informativo, ma viene portato il solo esempio della clash fisica tra due oggetti (peraltro declinato in due soltanto delle tre accezioni possibili ovvero hard e soft, dimenticando la workflow);

– è preferibile utilizzare oggetti generici prima che gli elementi vengano selezionati da catalogo o mandati in produzione, ma che indichino gli spazi richiesti per l’installazione, la connessione ad altri sistemi, la manutenzione, la sostituzione, e che questi oggetti vengano sostituiti da elementi specificati solo laddove richiesto: si punta quindi a un’obbligatorietà del LOD 350 americano (senza nessuna considerazione sul livello di affidabilità delle informazioni ma solo sulla presenza delle stesse, con conseguente diminuzione di tutela sul progettista).

11.2 Level of information need
Anche ammettendo che la geometria venga considerata in qualche modo un dato e quindi un’informazione (cosa che comunque andrebbe specificata da qualche parte), la sezione risulta incompleta.
Correttamente viene indicata la possibilità di indicare LOD diversi per diversi elementi dello stesso modello e altrettanto correttamente si raccomanda la necessità di richiedere il livello minimo di informazione necessario a soddisfare le richieste (o sarebbe meglio dire il livello minimo di informazione necessario a garantire l’uso del modello) ma non si fa menzione alcuna circa il livello di affidabilità dell’informazione in opposizione alla presenza della stessa.

Mi spiego meglio.
Per un’azienda che opera in varie fasi del processo edilizio, è normale avere librerie di componenti a livello di infrastruttura aziendale. Per ovvi motivi, tali componenti sono spesso oggetti specificati, che nelle prime fasi del processo svolgono la funzione di oggetti generici. Questo è particolarmente importante per la lettura del modello: se un cliente o un consulente riceve elementi in cui viene specificato il fornitore, ma nella tabella dei LOD è indicato che si tratta ancora di oggetti generici, il cliente o il consulente sanno che quella informazione non è attendibile. Un tipico parallelismo che può far comprendere questo concetto è quello di un rendering sviluppato in fase concettuale: per quanto l’arredo nell’immagine possa essere un arredo specifico di un fornitore specifico, è ben lungi dall’essere la decisione definitiva. Questo accade per ogni elemento: dai muri ai serramenti fino ai componenti impiantistici.

Se il concetto di LOD perde la sua accezione di Livello di Affidabilità e diviene un indicatore circa la presenza o meno delle informazioni, possono accadere due cose:
– l’azienda deve operare un enorme lavoro di semplificazione e sottrazione sui componenti, eliminando informazioni selettivamente per ogni LOD e mandando di fatto in ridondanza sei volte l’intera libreria, con uno spreco enorme di risorse e un’altissima possibilità di errore;
– anche laddove venga portata avanti con successo questa operazione, esistono dei valori che vengono inseriti di default e non possono essere cancellati: significa che l’informazione sarà presente ma non sarà affidabile.

Il LOD costituisce una tutela per tutti e deve esserne mantenuto lo spirito.

12. Common Data Environment
12.1 Principles
La sezione volontariamente ricalca solo quella parte delineata nel BS 1192 e non prende in considerazione il flusso complesso esplorato nelle PAS, che vengono relegate all’Annex B. Per la prima volta in questa circostanza viene nominato il BIM Execution Plan, lasciando intendere quindi che sia qualcosa di diverso dalla serie di Information Plan che giungevano in risposta ai vari Information Requirements. Non è chiaro se il BIM Execution Plan sia quindi un’anomalia nella nomenclatura ma costituisca risposta a quello che viene chiamato Exchange Information Requirements, se si tratti di un collettore dei vari Information Plan o quale sia il livello gerarchico tra i vari documenti.
Particolare risulta inoltre la clausola secondo la quale «container-based collaborative working allows for CDE to be distributed across different computer systems or technology platforms». Quello che mi preme sia chiaro che si tratta semmai di un CDE unico multipiattaforma, e non di più CDE che funzionano su diverse piattaforme e che in qualche modo vengono integrati. L’operazione di federazione del modello inoltre avviene su una specifica piattaforma, che è quella scelta dal BIM Leading Consultant. La federazione non può avvenire direttamente nel Common Data Environment: la maggior parte degli strumenti attualmente sul mercato non lo consente.
12.2 The work in progress state
Nessun commento, se non che la sezione originariamente non era accessibile al cliente e ora viene indicata come solo accessibile al team che ha originato i dati, il che funziona perfettamente in questa fase ma crea un problema nel punto successivo.
12.3 The check/review/approve transition
La sezione è presentata come una semplice validazione dei dati rispetto agli standard, ai metodi e alle procedure concordati. Non è mai stato chiaro chi abbia l’autorità per portare avanti questa fase: se la sezione work-in progress è accessibile solo dai singoli task team, si tratta di un’autocertificazione portata avanti dal BIM coordinator delle singole aziende? Oppure esiste una sezione di pre-submission in cui il materiale viene spostato per approvazione e viene validato dalla squadra del BIM leading consultant? Da chiarire.
12.4 The shared state
Nessun commento: è la sezione in sola lettura visibile anche a terze parti e al cliente. Si richiede di usare uno stato di condivisione specifico, il “client shared”, per le informazioni destinate a quest’ultimo. La declinazione di questi stati tuttavia non è per nulla chiara. Viene inoltre concessa licenza di distribuire il materiale per il cliente attraverso sistemi diversi dal Common Data Environment e la cosa è completamente inaccettabile.
12.5 The review/authorize transition
La fase viene indicata in modo molto simile alla 12.3, distinguendola semplicemente dalla validazione tramite l’utilizzo del termine “test”. La differenza sembra essere quindi che nella 12.3 le informazioni vengono valide per la loro conformità agli standard mentre in questa fase vengono testati per la loro usabilità nelle fasi successive. Al superamento del test, i container passano di stato e vengono pubblicati. Il processo di autorizzazione dovrebbe separare le informazioni autorizzate per la fase successiva da quelle presenti nei container ma non autorizzate. Se il discorso viene portato sul modello, si capisce immediatamente come questo non sia tecnicamente possibile ma debba essere affidato a un documento programmatico (la tabella dei LOD) rispetto ai quali viene verificata la conformità in fase di consegna.
12.6 The published state
Informazioni autorizzate per l’uso. Deve essere specificato, in questo settore, quali sono gli usi autorizzati: il risultato è probabilmente una matrice con i vari usi e i vari livelli di affidabilità delle informazioni nelle fasi, che si compila progressivamente man mano che ci si avvicina all’handover finale.
12.7 The archived state
Usato per le informazioni superate. Un sistema di versioning, tra quelli che regolano ad esempio la ISO 9001, dovrebbe essere chiaramente indicato e scelto perché la norma sia un documento organico e coordinato con l’intero sistema normativo in cui si inserisce.

13. Summary of information delivery cycle
I principi su cui si basa il ciclo di consegna delle informazioni sono presentati come i seguenti:
– l’information management è cosa distinta rispetto alla produzione e alla consegna delle informazioni: principio condiviso cui però non corrispondono, nella sezione relativa ai ruoli, mansioni distinte e dedicate;
– l’information management deve essere utilizzato durante l’intero ciclo di vita dell’edificio;
– la quantità di informazioni da gestire aumenta sia durante la produzione del progetto che durante la gestione dell’edificio, ma non tutte le informazioni generate durante il progetto sono rilevanti per la gestione dell’edificio… e quindi? Stiamo dicendo che l’Asset Information Model è una versione epurata del Project Information Model? Molto pericoloso nei casi in cui l’Asset Iinformation Model torna a essere Project Information Model, cosa che dovrebbe essere richiesta nei progetti di rinnovo o restauro;
– l’asset e il project information model contengono set diversi di dati;
– l’information delivery cycle si attiva ogni volta che si effettua una nuova consegna di progetto, ogni volta che viene assegnato un nuovo incarico oppure ogni volta che viene data una nuova istruzione a un fornitore/consulente, ma in realtà un information delivery cycle così strutturato, non Agile, deve per forza basarsi su consegne fissate e non può essere applicato anche al work-in-progress quotidiano, che necessita di processi di coordinamento più snelli per nulla tenuti in considerazione all’interno di questa norma;
– le richieste di informazioni riflettono la prospettiva di tutte le part in causa e ricadono a cascata sugli appropriati livelli incaricati dei deliverables, un punto che funzionerebbe molto meglio e risolverebbe molti mal di testa se fosse affrontati in termini di uso del modello;
– le varie informazioni vengono fascicolate dalle parti incaricate ai più alti livelli del progetto, un punto che funzionerebbe molto meglio esplicitando la presenza e il ruolo del BIM leading consultant;
– gli information exchanges sono utilizzati per trasferire informazioni tra le varie parti incaricate e il committente (per le implicazioni problematiche di questo meccanismo, vedere i punti 6.3;
le informazioni ricevute tramite information exchange devono essere verificate dal ricevente rispetto ai relativi requirements.

Conclusione
I punti da rivedere con la commissione sono i seguenti:
– effettiva integrazione della norma con le altre ISO citate;
– introduzione del concetto centrale di uso del modello, cruciale per la committenza e per un processo di modellazione informativa orientato alla qualità e all’ottimizzazione del processo;
– revisione dei ruoli e conseguente individuazione chiara delle responsabilità laddove non evidenziate (utile a questo scopo introdurre la figura dei BIM leading consultant e/o del gestore del Common Data Environment);
– riportare all’interno del flusso digitale la figura del committente eliminando la possibilità esplicita di gestire gli Information Exchange come esterne ai modelli e al Common Data Environment;
– una gestione compatta e ottimizzata del modello attraverso le varie fasi di progetto e costruzione, con accento finale sulla riconversione, più che sulla demolizione;
– una revisione del concetto di container con chiara indicazione circa l’indicizzazione delle informazioni al suo interno.