Il lavoro è in progress: pubblico il risultato parziale in virtù della consultazione, ma consiglio di tenere d’occhio l’articolo perché sarà aggiornato man mano che procedo nel commento delle sezioni successive.
Introduction
0.1 – Purpose
La sezione esprime chiaramente il destinatario di questa norma, ovvero l’Appointing Party, il cliente.
«This International Standard also defines the information management process, commonly referred to as building information modelling (BIM) and the activities through which delivery teams can collaboratively produce information and minimize wasteful activities». Come vedremo, la norma in realtà si concentra molto più sull’information management che su quell’integrazione digitale tra informazioni nel modello, propria del BIM e che costituisce valore aggiunto rispetto al semplice Information Management. Tuttavia, la parte importante di questo punto è il verbo “can”.
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.
Secondo la tradizionale mappatura dei verbi nelle norme, riportata nella citazione superiore, il verbo “can” indica qualcosa che è tecnicamente possibile. Il verbo che la norma sta ricercando è “should” o “may”. In ogni caso, è necessario specificare che qualora il delivery team scelga di non fare uso della presente norma è comunque necessaria dimostrazione o riferimento ad altro protocollo collaborativo. La collaborazione deve coinvolgere a cascata anche il delivery team e il task team.
0.2 National Annex
Oggetto della discussione ai tavoli nazionali in questi giorni, suggerimenti circa i margini di manovra delle norme nazionali vengono esplicitati nell’Annex B.
0.3 Relationship with other standards
Rispetto al capitolo 1, è stato stralciato il riferimento alla ISO 9001 che molto più rilevante della ISO 55000 in questa sede, trattandosi della fase di Delivery e non della fase di gestione dell’asset esplicitamente non oggetto di questa norma.
Tra l’altro, non mi è chiaro se questa norma mandi o meno in pensione la ISO 10789:2011, perché non voglio precludermi la possibilità di fare in BIM la prossima stazione orbitante.
Non scherziamo.
0.4 Benefits of the standard
Nessuna nota.
0.5 Interfaces between parties and teams for the purpose of information management
Esiste una confusione tra l’appartenenza a un gruppo (party) e il ruolo gerarchico nella piramide a livello di project management. Lo schema proposto nella ISO attualmente funziona più o meno in questo modo per quanto riguarda le figure coinvolte:
Non c’è comunicazione tra i vari Appointed Party
Se si considera la mancanza di comunicazione tra le varie Appointed Party, si presuppone che il coordinamento generale sia affidato all’Appointing Party (che può essere il cliente o una parte terza da lui incaricata… il che lo rende un’Appointed Party e ci ributta dritti dritti nello stesso problema, ma si veda la sezione 4.2 per un approfondimento su questo punto).
Al livello di questo paragrafo, il problema si pone con la figura completa, che incrocia questi gruppi con il loro inquadramento all’interno del progetto.
Gli inquadramenti all’interno del Project Team sono superflui, non univoci e peraltro ambigui.
Anche considerando che lo schema abbia intenzionalmente escluso il livello alto, corporate, quello del Programme Management, manca chiaramente un livello tra la Project Board (che dal testo sembra coincidere con l’Appointing Party), il Team Manager (Appointed Party) e il suo team, ovvero i due strati del Delivery Level. Questa figura mancante è tragicamente il managing level, il Project Manager. Come già anticipavo nei commenti alla parte 1, la mancanza di una figura chiaramente definita a questo livello, incaricata dal cliente o meno, si riflette negativamente su tutta la stesura della norma, creando ambiguità di ruoli e responsabilità.
Manca il BIM leading consultant, oltre al livello superiore (Project Board) che immagino sia stata omessa per scelta anche se non ne capisco il motivo.
1. Scope
La sezione specifica (nuovamente) il target della norma, con alcune contraddizioni rispetto alla sezione Purpose. Purtroppo la contraddizione circa il target del documento si trascina in molte parti della norma: se da una parte si dovrebbe trattare di una norma a uso della committenza, alla committenza stessa viene garantita un’estraneità peculiare al processo (si veda ad esempio la possibilità di non essere inclusa nel Common Data Environment di cui parlavo nella parte 1).
In questa sezione, i destinatari della norma vengono elencati come:
— those involved in the management or production of information during the delivery phase of assets;
— those involved in the definition and procurement of construction projects;
— those involved in the specification of appointments and facilitation of collaborative working;
— those involved in the design, construction, operation and maintenance of assets; and
— those responsible for the realization of value for their organization from their asset base.
Indipendentemente dall’ambizione di creare una norma che vada bene per tutte queste figure, esiste una contraddizione tra la specifica fase cui fa riferimento la norma e alcune di queste figure, in particolare coloro responsabili per la manutenzione e la realization (of) value, che in questa fase dovrebbero essere presenti come voci al tavolo ma non hanno un ruolo operativo. Circa il coinvolgimento di tutte le parti ai tavoli del lavoro collaborativo, tuttavia, un’altra clausola generalista in questo paragrafo pone un grave interrogativo.
«This International Standard can be applied to all types of assets
and by all types and sizes of organizations,
regardless of the chosen procurement strategy.»
Ora, è mia informata opinione che il BIM per un sistema design-bid-build (peraltro disincentivato negli schemi collaborativi) sia estremamente diverso da un BIM per il design-build e che l’intero sistema spinga verso le strategie Lean. Il pitch commerciale della norma, che cerca di vendersi come un rimedio universale omoepatico buono per tutte le stagioni, ne svaluta il significato e di riflesso squalifica la portata rivoluzionaria del BIM come metodo di progettazione, costruzione e gestione in edilizia. L’effettivo vantaggio del BIM per un cliente incastrato nel sistema design-bid-build è questione spinosa, tutt’altro che ovvia, che non può essere liquidata in una nota a margine dei paragrafi introduttivi.
Questo schema non è mio, ma è un buon riassunto del ruolo che il lavoro collaborativo ricopre nel sistema Design-Build, in opposizione al Design-Bid-Build
2. Normative References
Tra i riferimenti normativi, viene indicata la ISO 12006-2:2015. Building construction — Organization of information about construction works — Part 2: Framework for classification. Mi sembra sconsigliabile e peraltro non necessario, considerato che la norma fa uso del concetto di spazio e pochissimo altro. Più consigliabile sarebbe lavorare ulteriormente sul glossario.
Per i più distratti, la ISO 12006-2 è questa: la mamma di tutti i vari UNIformat, OMNIclass e MasterFormat.
In compenso, non viene fatto alcun riferimento ad un’altra norma la cui integrazione sarebbe importantissima per la Delivery Phase in BIM, ovvero la ISO 16757-1:2015. Data structures for electronic product catalogues for building services. Concepts, architecture and model. Stiamo nuovamente cercando di fare BIM senza i produttori?
Grazie, NBS.
3. Terms and Definitions
3.1 Terms relating to information management
Vedere i commenti alla parte 1.
3.2 Legend for process diagrams
Non sono un’esperta di grafici ISO, ma posso solo riscontrare una discrepanza tra i simboli proposti e gli stessi simboli utilizzati in altre ISO che non presentano una legenda della simbologia.
Che io sappia, esiste una ISO specifica per i simboli da utilizzare nei diagrammi (a parte tutte quelle ISO per l’industria chimica, che fa un uso massiccio ed estremamente standardizzato dei diagrammi).
Non mi sembrano quelli di questa ISO. Qualcuno riesce a fare una verifica e a confermarmi/smentirmi su questo punto?
4. Information Management Context
4.1 Information Management Process
La sequenza di operazioni viene proposta come segue:
1 Assessment and need
2 Invitation to tender
3 Tender response
4 Appointment
5 Mobilization
6 Collaborative production of information
7 Information model delivery
8 Project close-out (End of delivery phase)
Come si vede, la norma si auto-esclude da ogni progetto che proceda per appointment diretto, ovvero saltando dalla 1 alla 4.
Il processo inoltre ricalca parzialmente la figura 1 e quindi ha un problema ovvero posiziona la fase 1 (assessment and need) a livello di progetto e non a livello corporate, dove dovrebbe essere.
4.2 Information Management Roles
La sezione, come anticipavo nei commenti alla parte 1, presenta grosse lacune e pericolose ridondanze. Il consiglio sarebbe quello di formulare la sezione indipendentemente dal ruolo e presentando le funzioni che devono essere individuate all’interno del processo. Funzioni diverse possono essere svolte nello stesso ruolo, specialmente per progetti piccoli, mentre in questo momento l’infrastruttura proposta impedisce di fatto l’applicazione dello standard a progetti di piccole dimensioni, indipendentemente da quello che si afferma nella dichiarazione d’intenti della norma. Se devono essere individuati dei comparti, si consiglia di individuarli a livello più alto (corporate vs. di progetto, gestionale vs. operativo) lasciando il resto alla declinazione dell’organigramma. Se si vuole guardare a ISO di particolare successo come la ISO 9001, meno la norma è invasiva dei singoli organigrammi più alte sono le possibilità di adozione. La nota 1 non è sufficiente: il termine “ruolo” è sbagliato per esprimere il concetto.
La suddivisione potrebbe quindi diventare come segue.
1. Corporate Management
– Project Sponsorship (immagino individui gli usi del modello, ad esempio);
– Information Management (il corporate BIM manager, che integra il singolo progetto all’interno dell’infrastruttura aziendale, soprattutto in ambito ISO 55000 e ISO 9001).
2. Directing Level
– Project Delivery Coordination (il coordinator del leading consultant, che ha il compito di federare le informazioni);
3. Managing Level
– Project Information Coordination (il nostro coordinator);
4. Delivering Level
– Task Coordination (una specie di coordinator per il singolo task, un responsabile della singola attività);
– Information Author (gli operativi, che si occupano di modellazione informativa).
Il resto, signori miei, tra Interface Manager, Delivery Team Lead e Task Team Manager, è fumo oppure un ruolo della norma piramide di progettazione e, come tale, non oggetto di questa norma.
Inoltre, i principi base rimandati alla nota 5 (ownership, responsibility and authority) sono punti fondamentali che dovrebbero essere integrati nel sistema di pensiero.
Dopo aver letto questa parte della norma, ho bisogno di un momento per me stessa…
5. Information Management Process – Delivery Phase
5.1 Assessment and need (start of Delivery Phase)
L’attività viene svolta a livello corporate lato cliente, è preliminare alla creazione del progetto e responsabilità della cosiddetta Programme Board, quindi è un grave errore inserirla all’interno delle Activities Undertaken per Project (vedi Figura 3). A livello di asset management – e non solo – è necessario evitare che ogni progetto abbia i propri requirements non coordinati con il resto dell’infrastruttura aziendale.
In questo senso, nella sezione sono presenti attività che non hanno alcun senso senza la figura del BIM manager.
Le attività chiave vengono così elencate:
1.1 Appoint project information management roles
1.2 Establish the project’s information requirements
1.3 Establish the project’s information delivery milestones
1.4 Establish the project information standard
1.5 Establish the project’s information production methods and procedures
1.6 Establish the project’s reference information and shared resources
1.7 Establish the project’s common data environment
1.8 Establish the project’s information protocol
Alcuni di queste attività scivolano naturalmente verso la parte successiva o vengono incorporate nella parte precedente una volta rimessa a posto la struttura di project management.
Information Management Process – Delivery Phase – Assessment and Need Activities
5.1.1 – Appoint project information management roles
In questa fase, per quanto riguarda l’information modelling, è semplicemente necessario che il BIM manager (laddove presente) individui il coordinator del progetto. Stiamo sempre ragionando in termini di committenza, quindi si ipotizza uno scenario in cui il cliente sia esso stesso BIM leading consultant e sia in grado di coordinarsi, amministrarsi e gestirsi il progetto in BIM. Naturalmente la norma stessa sa che questo è irrealistico per le attuali condizioni di mercato e quindi apre alla possibilità di individuare un BIM leading consultant, anche se la cosa non è esplicitamente espressa in questi termini. Per ogni ruolo, la norma consiglia uno schema in cui ci si ponga domande circa:
– i compiti che saranno assegnati alla figura;
– l’autorità che queste figure avranno;
– la competenza richiesta (sia in termini conoscitivi che di abilità).
Aggiungo che i ruoli devono essere messi in relazione con gli altri ruoli già presenti, soprattutto in termini di autorità. Non basta quindi individuare dei ruoli ma è necessario iniziare sin da questa fase a tracciare un organigramma di progetto, che sarà necessario per il successo dell’attività collaborativa.
Criteri di pre-selezione per una figura gestionale. Le varie figure devono essere inquadrate in un’organigramma per il buon funzionamento del processo collaborativo.
5.1.2 – Establish the project’s information requirements
Si tratta dell’Employer’s Information Requirements. La sezione è drammaticamente incompleta: in questa fase devono essere individuati anche gli usi del modello, con relativi livelli di sviluppo per le varie fasi di consegna.
5.1.3 – Establish the project’s information delivery milestones
Nessuna nota. I due punti tuttavia dovrebbero essere riuniti all’interno della stessa voce: il plan of work dialoga in modo molto stretto con la Model Production and Delivery Table, il sistema dei LOD e i modelli di Information Exchange.
5.1.4 – Establish the Project Information Standard
L’attività è formulata in modo scorretto, lasciando intendere che ogni progetto debba avere i propri standard informativi. Si tratta di declinare gli Information Standard sul singolo progetto ed è compito del BIM coordinator in fase di progetto. In questa fase, al massimo, il BIM manager può verificare l’allineamento tra gli standard e le caratteristiche del singolo progetto.
5.1.5 – Establish the project’s information production methods and procedures
L’attività dovrebbe essere spostata in fase di tendering: l’Appointed Party ha diritto di proporre i propri metodi di produzione e le proprie procedure, purché integrate con i protocolli collaborativi di cui al punto 1.2.
5.1.6 – Establish the project’s reference information and shared resources
Lato informativo, viene stabilita la relazione tra il progetto e le infrastrutture aziendali (es: eventuali librerie di oggetti, script di automazione, ecc.). Gli elementi elencati dalla norma a titolo esemplificativo sono:
a) existing asset information (immagino che si possa decidere di non utilizzare un modello di as build ma di commissionare un nuovo modello, ad esempio, perché quello in archivio non è attendibile);
b) shared resources ovvero:
– process output templates in cui erroneamente vengono elencati documenti di processo come il BIM execution plan: si consiglia di correggere in process templates;
– container templates in cui si parla di template per modelli 3d, ad esempio, creando ulteriore ambiguità circa il concetto di container (vedere note alla parte 1);
– style libraries;
– object libraries.
Aggiungerei almeno:
– interoperability routines and templates (utilizzo di plug-in ad esempio o script di automazione, ma anche di template standard per l’esportazione verso altri formati previsti nel workflow).
c) library objects defined within national standards, un punto che presuppone l’esistenza di una libreria oggetti nazionale che nessuno ha. Manca quindi un punto d, circa il coinvolgimento degli equinidi monocorno.
Tra le risorse condivise di progetto, insieme alle librerie di oggetti definite negli standard nazionali, mancano loro.
5.1.7 – Establish the project’s common data environment
Troppo presto.
Inoltre, viene posto un vincolo tecnologico estremamente stretto circa le possibili piattaforme.
I requisiti elencati sono:
a) fornire un ID unico a ogni container (di nuovo non è chiaro se il container sia il modello, come sembra in questa sezione, o l’organizzazione di cartelle come veniva detto a un certo punto della parte 1) composto da un numero di campi separari da un delimitatore;
b) fornire a ogni campo un valore scelto da un elenco predefinito;
c) assegnare a ogni container i seguenti attributi:
— Suitability (status);
— Revision and version, con i problemi di lessico che rilevavo nella parte 1;
— Classification in accordance with ISO 12006-2 (quindi di ogni modello si richiede di indicare se sia un modello del complesso, dell’entità o di uno spazio, il che sembra implicare la possibilità di caricare modelli federati (per loro costituzione modelli di entità o complessi, e più difficilmente di spazi) anziché federarli direttamente nel Common Data Environment, funzionalità che veniva richiesta nella parte 1 ma che al momento non è fornita da nessuna delle soluzioni tecnologiche presenti sul mercato;
d) possibilità di spostare un container da uno stato all’altro;
e) possibilità di registrare nome utente e data per lo spostamento di stato dei container;
f) fornire un accesso sicuro a livello di container.
Analizzando i requisiti a) e b) risulta immediatamente chiaro che viene richiesto l’utilizzo di document controller avanzati, mentre il sistema (mutuato dalle PAS) tradizionalmente utilizza l’assegnazione manuale degli attributi al nome del file. Si pone inoltre un problema di corrispondenza tra il nome fisico del file al di fuori del CDE e il loro ID. L’univocità nel nome è necessaria per i protocolli di federazione.
Mancano inoltre alcune caratteristiche fondamentali, ovvero:
x) la possibilità di creare diversi comparti (a meno che non si voglia utilizzare esclusivamente la suitability, ma di nuovo ci porta esclusivamente verso sistemi di document controller estremamente costosi e tutt’altro che alla portata di tutti);
x) la possibilità di impostare differenti privilegi di accesso in lettura e in scrittura nei vari comparti.
Vedere ulteriori commenti sull’Annex B.
5.1.8 – Establish the project’s information protocol
Vedi Establish the Project Information Standard.
No Comments