ISO 19650-4: qualche indiscrezione

Ai tavoli di lavoro nazionali è stata recentemente diramata una bozza della ISO 19650-4, per informazioni su una votazione. Naturalmente non posso entrare nel dettaglio dei contenuti, dato che si tratta di una bozza ancora piuttosto acerba, ma posso fornire qualche “pillola”, con l’avvertimento che molto potrebbe ancora cambiare e molto cambierà.

Tanto per cominciare, l’oggetto della parte 4 sono i protocolli di scambio informazioni, e si pone in successione a quella che dovrebbe essere la controparte ISO dell PAS 1192-3. Il titolo completo della norma è:

ISO 19650-4
Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM)
Information management using building information modelling
Part 4: Information Exchange

Al momento, il testo riprende le fasi delle parti 1 e 2 e il ciclo base all’interno del CDE, ovvero:

1. il lavoro viene sviluppato nella parte Work in Progress;
2. si approva internamente il suo passaggio nella parte Shared;
3. il lavoro viene revisionato dalle parti riceventi nella sezione Shared;
4. il lavoro viene autorizzato per la pubblicazione o vengono individuate azioni correttive;
5. in caso di autorizzazione effettuata, il lavoro passa nella sezione Published;
6. in caso di azioni correttive, viene ripassato nella sezione work in progress.

Il CDE così come definito nella ISO 19650-1.

L’unica aggiunta, che costituisce motivo di turbamento almeno per me, è la chiosa:

Scambi di informazioni (Information Exchanges) che sono esclusi dai processi interni al CDE possono passare direttamente dall’approvazione alla pubblicazione e ogni organizzazione dovrebbe sviluppare processi adeguati per controllare questi scambi

Il cammino dell’uomo timorato è minacciato da ogni parte dagli scambi di informazioni al di fuori del CDE.

In ogni caso, all’interno della definizione delle varie fasi vengono esplicitati alcuni passaggi non ovvi. Piccole frasi che, se lasciate così come sono, potrebbero significare molto per i nostri processi progettuali. Di seguito, e in nessun particolare ordine di importanza…

1. Chi definisce gli strumenti di authoring?

Il fornitore delle informazioni (diciamo ad esempio il progettista) è deputato a selezionare lo strumento di authoring che ritiene più adatto e lo farà (questa parte della norma fa un uso piuttosto entusiasta del verbo “shall”) in un ventaglio di opzioni che consentano:

• l’importazione delle informazioni relative al contesto;
• l’esportazione delle informazioni nei formati richiesti;
• i rischi eventuali connessi alla scelta dello strumento.

Non è ben chiaro, in questa fase, quale sia il margine di manovra della committenza, dato che la valutazione del rischio rimane comunque un processo assolutamente soggettivo: è consentita l’ingerenza se viene proposto uno strumento di authoring che il cliente ritiene essere ad alto rischio?

La scelta degli strumenti giusti è importante.

2. Quanto spesso bisogna consegnare?

Secondo i principi dello Scrum, che non mi stancherò mai di indicare come un ottimo framework per il BIM, bisogna consegnare:

• il prima possibile;
• più spesso possibile.

È conveniente procedere per consegne iterative incrementali. Schema da enhancedscrumguide.com.

3. Quando il lavoro si considera “completo”?

Uno dei grandi dilemmi nella gestione di un progetto è sempre definire quando un progetto è finito. La ISO non ci viene incontro, in questo, ma sembra voler almeno definire dei criteri secondo i quali il cliente deve valutare se la consegna finale è davvero finale. Questi parametri dovrebbero essere, oltre a quelli esplicitamente definiti nell’EIR (o AIR, se si tratta di un progetto relativo alla fase di gestione):

• la presenza delle informazioni richieste per soddisfare gli usi relativi alla fase in corso;
• la presenza delle informazioni necessarie per la supervisione e il coordinamento, incluse informazioni relative al coordinamento spaziale, al coordinamento fisico e ai coordinamenti di processo;
• la presenza delle informazioni necessarie a supportare la gestione a lungo termine, in accordo con gli standard aziendali, tramite l’utilizzo di nomenclatura e codifica standard, oltre che di open standard.

Alcuni progetti sembrano non essere finiti mai.

4. Conflitti

Quando si parla di risoluzione dei conflitti, spesso si riduce la cosa alla cosiddetta hard clash detection, ovvero al rilevamento delle interferenze fisiche. Tralasciando i conflitti umani (come sappiamo, per quelli non c’è software che tenga), questa ISO sembra voler individuare almeno a grandi linee alcune categorie di conflitto la cui verifica è necessaria per la fase di pubblicazione delle informazioni:

• conflitti spaziali, fisici e di processo, inclusi eventuali duplicati;
• conflitti di attributi e proprietà;
• accuratezza inappropriata o insufficiente (troppo precisi, come i famosi grattacieli quotati in millimetri, o troppo poco precisi);
• container in sovrapposizione o non in continuità (e sul tema della continuità il capitolo 4 della ISO dedica una sezione a sé).

Ancora nessuna soluzione a questo tipo di conflitto.

5. Conformità

Decisamente la mia parte preferita della norma, dettaglia cosa si intende per conformità in relazione al formato di consegna e specifica che il cliente considererà le necessità di information exchange utilizzando:

• un formato di modello aperto tra cui IFC, GML, Cesar o COBie (l’unica circostanza in cui il formato viene citato all’interno della norma);
• un formato di documento aperto tra cui docx, xlsx, pdf, sql, jpg, xml-zip.

Ma soprattutto…

proprietary or native formats
where this does not disadvantage any receiving parties immediate or future needs

E questo potrebbe tranquillamente essere il mio prossimo tatuaggio. Pensavo a una posizione sobria.