ISO 19650: che cosa è cambiato? (2)

L’uscita della nuova ISO 19650 sul BIM è stata accompagnata dal ritiro di due norme britanniche cui molti di noi erano abituati a far riferimento: il BS 1192 e la relativa PAS 1192-2. Ci troviamo quindi in un periodo di transizione in cui bisogna trasformare alcuni dei nostri metodi in riferimento alla nuova norma e, quindi, […]

L’uscita della nuova ISO 19650 sul BIM è stata accompagnata dal ritiro di due norme britanniche cui molti di noi erano abituati a far riferimento: il BS 1192 e la relativa PAS 1192-2.
Ci troviamo quindi in un periodo di transizione in cui bisogna trasformare alcuni dei nostri metodi in riferimento alla nuova norma e, quindi, il tutto parte dal domandarsi cosa ci sia di diverso tra ciò cui eravamo abituati e ciò che abbiamo adesso.
La risposta semplice a questa domanda è stata “parecchio”. Nel mio articolo scorso (lo trovate qui) mi sono concentrata sulle differenze che i due capitoli della nuova ISO 19650 introducono rispetto al BS 1192, che si possono riassumere in differenze che riguardano:

  • costo (a fronte di uno standard gratuito, ci troviamo a dover sostenere una spesa non indifferente per l’acquisto di tutto l’ecosistema di norme);
  • termini e definizioni (abbiamo una gerarchia ancora più chiara tra model e container);
  • common data environment (un ritorno al più semplice nucleo di comparti del BS rispetto alla PAS 1192-2 e nessuna esemplificazione di flussi di collaborazione);
  • naming convention (o, più precisamente, l’assenza di una convenzione di nomenclatura univoca e il riferimento alla standard IEC 82045-1:2001);
  • coordinamento spaziale (o, più precisamente, l’assenza di specifiche in tal senso nella nuova ISO);
  • quality management (ovvero il rinforzato riferimento alla ISO 9001).

Dato che ogni promessa è debito, ora proverò a delineare le differenze principali tra la PAS 1192-2 e le ISO, anche se probabilmente sarebbe più semplice (e certamente più breve) delineare le somiglianze.

La PAS 1192-2 è stata ritirata e, con le opportune modifiche, diverrà appendice nazionale della ISO 19650-2.
La PAS 1192-2 è stata ritirata e, con le opportune modifiche, diverrà appendice nazionale della ISO 19650-2.

1. Contratti, incarichi e altre faccende minori

Uno dei grandi compromessi di questa ISO, su pressione di alcune specifiche nazioni nostre vicine, è l’esplicita fumosità circa la presenza o meno di un accordo contrattuale che riguardi i flussi di information modelling. Da un lato, la PAS 1192-2 era estremamente specifica, arrivando ad esplicitare quali documenti dovessero essere allegati ad un accordo che fosse legalmente vincolante.

La relazione tra il contratto e i documenti associati nella PAS 1192-2.
La relazione tra il contratto e i documenti associati nella PAS 1192-2.

Per quanto ci sia sempre stata una zona di grigio temporale tra la produzione del pre-contract BIM Execution Plan, il conferimento dell’incarico e la produzione del post-contract BIM Execution Plan, questa zona è sempre stata gestita nelle fasi di contrattazione. Gli Employer’s Information Requirements, in quanto parte degli Employer’s Requirements, figuravano chiaramente nel grande schema delle cose. Il BIM Protocol prodotto dal Construction Industry Council e peraltro recentemente aggiornato è sempre stato inteso come un allegato contrattuale.

The Protocol was drafted for use with
all common construction contracts.

La posizione della ISO 19650 in merito a questa questione è francamente disdicevole e avevo già avuto modo di pronunciarmi in netto disaccordo in occasione della sua prima consultazione pubblica.
I termini “appointment” (incarico), “appointing party” (parte incaricante) e “appointed party” (parte incaricata) vengono tutti corredati da una simpatica nota che specifica che il termine viene utilizzato anche quando non esiste un conferimento d’incarico formale tra le parti.

This term is used whether or not there is a formal appointment between the parties.

Posso comprendere il tentativo di generalizzare il workflow, indicando come ricevente dell’informazione anche chi non sia tecnicamente cliente, ed è un esercizio di sensibilizzazione condivisibile che io stessa faccio quando invito a considerare cliente (ovvero utente del nostro prodotto) anche una terza parte che concorre collaborativamente alla costruzione del progetto integrato.
Tuttavia qui non stiamo parlando solo di questo, ma di una vera e propria mancanza nella definizione precisa del BIM come requisito contrattuale e, di conseguenza, della posizione gerarchica di certi requisiti all’interno dei documenti di conferimento d’incarico. Cosa che naturalmente è curiosa, considerato che l’intera parte 2 è dedicata a dettagliare i flussi in presenza di un appalto e dedica l’intero capitolo 5.4 alle attività da svolgersi in fase di conferimento d’incarico. La clausola in capitolo 1 rischia di trasformare l’intero testo in una amichevole linea guida, perché com’è possibile rendere vincolante una specifica normativa in assenza di un vincolo contrattuale di qualunque tipo?

Firmiamo il dannato contratto e andiamo a bere, per la miseria.
Firmiamo il dannato contratto e andiamo a bere.

Nonostante questo, forse presagendo l’addensarsi di pesanti nubi all’orizzonte, sempre nella parte 2 della norma si “consiglia caldamente” che il Lead stabilisca i requisiti informativi dei suoi subappalti “come se si trattasse di un incarico formale” anche con i team interni. Mio consiglio è di farlo anche con quelli esterni. Così, per dire.

The lead appointed party shall establish their exchange information requirements for each appointed party. When engaging internal teams, it is recommended that the lead appointed party establishes a clear schedule of information requirements as though it was a formal appointment.

banana

 


2. Employer Information Requirements

Una cosa rimane formalizzata, tuttavia, e viene ulteriormente dettagliata: quella parte che in Italia chiamiamo Capitolato Informativo.
Forse per farsi perdonare della mancanza di cui al punto 1, la ISO abbonda e riprende uno schema già visto nel lavoro del Minister of Justice che ci proponeva AIR, EIR e OIR.

Ricordate?
Ricordate? Beh, non è più valido.

In particolare, la ISO distingue tra:

  • OIR: Organizational information requirements;
  • AIR: Asset information requirements;
  • PIR: Project information requirements;
  • EIR: Exchange information requirements, violando una delle regole base della vita ovvero MAI usare un acronimo UGUALE per indicare una cosa DIVERSA.

Brevemente e senza poter entrare nel merito di ciascuno, la differenza è principalmente in termini di relazione con il prodotto finito: se l’AIR fornisce le speciiche per il modello di un Asset (il fabbricato finito), il PIR fornisce le specifiche per il modello in fase di progettazione, per quanto ridicolo possa suonare l’acronimo.
L’EIR si posiziona in fase di conferimento d’incarico, in questo rimanendo analogo al vecchio Employer’s Information Requirements, e parte della modifica è dovuta alla non volontà di utilizzare la parola Employer nella norma (connessa al punto 1 di cui sopra).

Novità interessante è costituita invece dal’OIR, già menzionato nel framework del Minister of Justice e che fondamentalmente mantiene le stesse caratteristiche che aveva in quel contesto: si tratta di un documento che ci invita a ragionare in termini di organizzazione e, a livello molto alto, definisce i requisiti informativi a livello aziendale, specialmente in presenza di gestioni sistematizzate e unificate degli immobili. Gli obiettivi possibili da considerare in questo documento vengono evidenziati in:

  • la pianificazione e conduzione di operazioni commerciali strategiche;
  • la gestione strategica dell’immobile;
  • portfolio planning;
  • l’assolvimento ad obblighi di legge;
  • la creazione di politiche aziendali.

Personalmente aggiungo e ricordo la necessità che ogni progetto (inteso nel senso più rigoroso del termine) introduca un cambiamento a livello aziendale e contribuisca al consolidamento dei protocolli BIM, specialmente nelle prime fasi dell’implementazione.

Alla definizione di questi information requirements è dedicato il capitolo 5 nella parte 1 della norma ed è la parte in cui vengono esemplificati alcuni obiettivi, come vi accennavo qualche giorno fa (qui).

La gerarchia tra gli Information Requirements della ISO 19650. Tutto chiaro, no?
La gerarchia tra gli Information Requirements della ISO 19650. Tutto chiaro, no?

Un punto sicuramente controverso, che già non ha mancato di far discutere, è l’apertura alla possibilità che un cliente sviluppi Project Information Requirements tipici da utilizzare in tutte le sue gare.

Repeat clients may develop a generic set of PIR that can be adopted,
with or without amendment, on all of their projects.

Questa prospettiva naturalmente mi terrorizza, specialmente in assenza di una definizione di “repeat clients”.

Non mi sorride l'idea di un cliente che lancia PIR ciclostilati dall'elicottero.
Non mi sorride l’idea di un cliente che lancia PIR ciclostilati dall’elicottero.

Un altro punto decisamente problematico è la natura non più immutabile dell’EIR (oltre al fatto che non mi abituerò mai al significato del nuovo acronimo).
Nonostante le sue sezioni rimangano fondamentalmente quelle cui siamo abituati (gestionale, tecnica e commerciale), il documento diventa una specifica che viene passata di mano in mano, dall’affidatario al Lead e giù giù lungo la catena dei subappalti in una sorta di telefono senza fili che incentiva il relativo apponting party a integrare il documento con le proprie specifiche, in un passo che – tradotto sommariamente – suona più o meno:

L’EIR ricevuto dalle parti incaricate, inclusi i Lead, può essere aumentato con i loro rispettivi EIR.
Alcuni degli EIR possono essere quindi trasmessi alle rispettive parti (sub)-incaricate,
in particolare quando è necessario uno scambio di informazioni con un team della parte sub-incaricata
e questa informazione non deve essere poi scambiata con la parte incaricante principale.

Insomma, il cliente ha il suo EIR, lo trasmette al Lead, che lo modifica e lo trasmette ai suoi subappalti, in particolare quando le informazioni prodotte dai subappalti non devono poi essere condivise con il cliente (perché, si sa, noi produciamo informazioni per il gusto di farlo, ma non servono davvero al cliente finale).

"Hey, psst, pare che il cliente voglia anche il COBie"
“Hey, psst, pare che il cliente voglia anche il COBie”

Naturalmente la possibilità che ogni parte incaricata integri l’EIR a piacimento è raggelante e la ISO non manca di raccomandarsi che questo guazzabuglio infernale venga poi coordinato da qualcuno (non è chiaro da chi) in un unico sistema organico. La norma non si cura di darci un’idea circa il come dovrebbe fare una delle parti o una parte terza a collezionare e coordinare specifiche informative che vengono prodotte e diramate tra subappalti su cui non ha controllo formale. Certamente non vorrei essere la persona cui viene affidata questa magagna (e adesso che l’ho detto…).


 

3. One Lead to Rule them All

Come i più attenti tra voi avranno notato, al punto precedente parlo di Lead al plurale. Si tratta di un’altra modifica significativa introdotta dalla ISO rispetto allo schema della PAS 1192-2.
Se ricordate, la PAS si fondava esplicitamente su un cardine di funzionamento: era necessario che una delle figure incaricate (o una figura terza) assumesse il ruolo di Lead. Se avete mai preso tra le mani il mio libro, il gioco sviluppato con Gabriele Gallo nel percorso a bivi ruota molto intorno al rapporto con questa figura (o alla possibilità di conquistare il picco della montagna e diventare BIM Leading Consultant).

In particolare, la PAS 1192-2 ci diceva:

The above principles involve the delivery
of a co-ordinated project information model
to the employer containing graphical and non-
graphical information through a single point of
responsibility, likely to be the lead designer or the
contractor.

Questo era il senso della famigerata e incompresa figura 7 della PAS 1192-2.
Questo era il senso della famigerata e incompresa figura 7 della PAS 1192-2.

Il capitolo 2 della ISO 19650, viceversa, sistematizza la presenza di più Lead, nessuno dei quali in chiara posizione di coordinamento con gli altri. Indipendentemente dal paradosso etimologico congenito al ragionamento di avere più Lead, lo schema che lo illustra (figura 2 del capitolo 2, per chi ha la norma) è grottesco, con i vari Lead cui viene lasciato un non meglio precisato compito di coordinarsi con il vicino e l’intero sistema circoscritto in quella grande famiglia chiamata Project Team. Ora, non posso riportarvi la figura originale per questioni di copyright, ma ho cercato di riprodurla nel modo più efficace possibile.

Con calma, ve la spiego sotto.
Con calma, ve la spiego sotto.

Le frecce continue indicano uno scambio di Information Requirements, oltre che di informazioni, e ricordiamo che ogni Lead Appointed Party può “arricchire” l’EIR con le proprie aggiunte (quindi in questa situazione siamo in presenza, al meglio, di quattro versioni diverse dell’EIR).
Le frecce tratteggiate indicano la necessità di un coordinamento informativo tra le parti. Anche nella versione originale dell’immagine, che presenta cinque Lead, il signore in alto a sinistra non parla con quello in basso a destra, ma facciamo uno sforzo per considerarla figlia di una semplice esigenza grafica, anche se questo tipo di cose non dovrebbero succedere in una norma.
La presenza di frecce continue tra l’Appointing Party e i Lead non è equivocabile nell’immagine originale, così come la presenza di EIR tra i Lead e i loro subappalti. La presenza di frecce continue (e quindi uno scambio di informazioni) tra i vari subappalti è tuttavia una mia interpretazione nel contesto della norma, perché l’immagine originale ha ravvicinato troppo i subappalti tra loro e non è possibile vedere se si tratta di frecce continue o tratteggiate. Vi piacerebbe che io stia scherzando.

Se i flussi tra i vari subappalti possono essere comunque regolamentati in modo abbastanza “facile”, o per lo meno regolamentarli è un’impresa ancora alla portata delle umane possibilità, più complesso rimane un coordinamento tra figure in posizione paritaria e senza una chiara gerarchia (oltre che in potenziale assenza di contratto).


 

4. Workflow documentale

A completare il quadro delle modifiche relative ai documenti da produrre, devo spendere due parole circa il workflow documentale nella fase di pianificazione (ovvero di pre-appointment). Nella PAS 1192-2, la situazione era “abbastanza” lineare e ci si era ormai abituati a questo schema:

La relazione tra i documenti utilizzati per la gestione delle informazioni secondo la PAS 1192-2.
La relazione tra i documenti utilizzati per la gestione delle informazioni secondo la PAS 1192-2.

Nella ISO, specialmente nella parte 2, si dettagliano molto più chiaramente i requisiti di ogni fase del processo fino ad arrivare alla vera e propria produzione collaborativa delle informazioni con relativa consegna e chiusura di progetto, ovvero:

  • Assessment and Need;
  • Invitation to Tender;
  • Tender Response;
  • Appointment;
  • Mobilization.

In questo senso, la ISO dedica una grande parte alle fasi di pre-appointment e quindi di gara, costituendo un punto di riferimento abbastanza valido per le stazioni appaltanti. Ma questo richiederà un focus a parte.

5. Bye bye COBie

Un’altra modifica importante, rispetto alle PAS 1192-2 che indicavano esplicitamente pdf e COBie tra gli output di consegna, è l’assenza di ogni menzione riguardante il formato (no, non si parla nemmeno di IFC né di formato aperto).

Ci sarebbe molto altro ma, per il momento, accontentatevi di questo.

15 Comments

  1. Ancora una volta grazie per la preziosa analisi. C’è un passaggio che mi inquieta particolarmente….Se ho compreso bene l’intenzione sarebbe quella di coinvolgere sia l’appaltatore che i sub-appaltatori nel processo di definizione degli standard informativi…..Ora, ammesso e non concesso che tutti i soggetti coinvolti abbiano un livello di competenza tale da poter collaborare su questo piano (ah ah), per un committente o, ancora meglio, per un gestore di una grande infrastruttura, affrontare diversi progetti o diversi cantieri lasciando che in qualche modo i propri fornitori possano “condizionare” gli standard operativi e conseguentemente il prodotto finale, sotto forma di modello AIM per la fase di gestione e manutenzione, destinato alle risorse interne per il supporto delle attività di FM, mi sembra sostanzialmente assurdo. O lo standard è rigido e viene applicato a qualunque tipologia di commessa e per qualunque fornitore oppure la committenza si troverà in mano, inevitabilmente pezzi diversi dello stesso puzzle. Già così suona malissimo. O sbaglio?

    1. Grazie, Alvise, è un piacere.
      Hai interpretato correttamente: viene lasciata libertà di integrazione all’EIR da parte di tutti i subappalti. E, nonostante venga specificato che questo debba essere in qualche modo coordinato, la ISO non arriva a specificare come né quando né da chi. A mio parere il problema non è tanto questo: abbiamo sempre saputo che si trae un beneficio quando i subappalti, specialmente quando estremamente specializzati, possono contribuire ai documenti collaborativi. Il problema principale a mio parere è la mancanza di una figura di coordinamento centralizzata, che nelle PAS veniva esplicitamente posta come ‘conditio sine qua non’ mentre in questo caso, probabilmente su pressione delle parti rappresentanti il cliente, viene lasciata ad un’autoregolazione di dubbia efficacia. Chiaramente gli interessi in gioco sono tanti e se si norma la presenza di un coordinatore centrale delle informazioni questo coordinatore va poi pagato. Non approvo la piega della norma, in questo punto come in quello dei contratti: questi sono compromessi che pagheremo cari, temo.

  2. Ho visto in un altro articolo che i famosi LOD cambiano in “level of information need”, in sostanza cosa cambia rispetto alle PAS?

    1. Nella sostanza, almeno a livello europeo, si passa al LOIN da un LOD che veniva composto attraverso uno schema multiplo di LOG (Level of Geometry) e LOI (Level of Information), anche se viene manuenuta la possibilità di utilizzare due scale diverse per la geometria e per le informazioni.
      Rimane un collegamento diretto tra LOIN e uso del modello (“The level of information need of each information deliverable should be determined according to its purpose”, dice chiaramente il capitolo 1 della norma) e la specifica del LOIN deve includere quantità, qualità e granularità delle informazioni richiese.
      E’ in lavorazione un capitolo dedicato ad una specifica chiara e finalmente univoca dei LOIN. I presidenti del tavolo di lavoro sono Sina Tiedtke e la nostra Marzia Bolpagni: se vorrà, integrerà lei questo mio commento. L’ultimo draft di cui sono in possesso è circolato nell’agosto dell’anno scorso, quindi potrebbero esserci stati importanti sviluppi di cui non sono a conoscenza. Al momento di questo draft, si parlava di un LOIN composto da un livello geometrico, un livello informativo e un livello documentale.
      Al momento, per come viene formulato il paragrafo 11.2 della ISO 19650-1, sembra che il LOIN sia ancora inteso all’inglese, di modello anziché di categoria. Spero che questo cambi o venga meglio specificato, perché onestamente ho sempre visto funzionare molto molto poco il sistema inglese rispetto a quello americano che procede per categoria. La bozza di agosto mi faceva ben sperare in tal senso.

      1. Grazie Chiara.
        Nella ISO 19650-1 viene introdotto il concetto di “Level of Information Need” senza definirlo in dettaglio. A livello europeo, il comitato europeo di normazione (CEN) sta lavorando su uno standard più specifico su questo argomento (prEN 17412) che coordino. Lo standard nella sua prima parte (Concepts and Principles) verrà pubblicato alla fine del 2019.
        Le modifiche sono diverse. In primo luogo prima di specificare i livelli di fabbisogno informativo (level of Information need) è necessario specificare l’uso (perché si richiedono le informazioni). In questo modo si vuole evitare che vengano richiesti “LOG 3” “LOI 2” etc senza entrare nel dettaglio. Come sappiamo gli aspetti geometrici, alfanumerici e documentali cambiano in base agli usi (e.g. analisi strutturali o analisi energetiche) anche nella stessa fase del progetto. Inoltre, al giorno d’oggi è difficile controllare cosa sia “LOI3” e verificare in modo (semi)automatico che quanto si riceve sia conforme alle richieste.
        I livelli di fabbisogno informativo non sono solo per nuovi edifici e infrastrutture, ma anche per quelli esistenti. Inoltre essi non vengono definiti solo a livello di “elemento”, ma anche a livello si sistema, componente, parte etc.in base alle fasi e agli usi.
        Esistono altre modifiche più dettagliate per cui rimando al testo definitivo quando verrà pubblicato.
        Anche in sede UNI stiamo lavorando su questi temi per allineare la UNI11337 alla prEN 17412.

  3. L’unico punto su cui avrei da ridire è il fatto che per il titolo del capitolo 5 mi sarei aspettato un “see you space COBie”

Leave a Reply to shelidon Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.