shelidonMay 11, 20203 Comments on Un BIM Execution Plan Agile

Sabato scorso ho concluso un ciclo di quattro lezioni, durante le quali ho cercato di presentare il mio punto di vista sullo spinoso tema del BIM Execution Plan, il piano d’esecuzione di un progetto BIM, e su come si ponga rispetto all’Offerta per la Gestione Informativa e al Piano per la Gestione Informativa così come siamo abituati a vederli realizzare.
Ad un argomento spinoso, ho deciso di accompagnarne un altro: la riconversione di un edificio scolastico, ipotetico o tipologico, secondo i parametri di sicurezza dell’emergenza sanitaria. Gli effetti della pandemia sull’architettura è un argomento su cui in molti si sono pronunciati, con posizioni differenti.

Normalmente, ci si concentra sul BIM Execution Plan nelle sue sezioni di risposta agli Information Requirements del cliente.

I numerosi sistemi di riferimento, gli svariati template più o meno vintage, i framework di università e società di consulenza, spesso perdono di vista alcuni principi fondamentali che mi preme richiamare:

1. Il BIM Execution Plan è un documento vivo e qualunque sistema contrattuale che impedisce l’esistenza di un piano d’esecuzione forse non ha ben compreso la differenza con un piano di gestione;
2. Il BIM Execution Plan appartiene al team (non al coordinator, né tantomeno al manager);
3. Il Piano per la Gestione informativa è un documento strategico che dovrebbe essere molto più della compilazione di un template che nasce per la redazione dei capitolati;
4. Il BIM Execution Plan è un piano d’esecuzione che contiene sezioni tecniche e operative.

Approcciando la sua strutturazione prendendo in prestito principi che lo Scrum utilizza nello sviluppo e nell’organizzazione del Product Backlog, abbiamo provato a fare qualcosa di differente.

Obiettivi

Il concetto di obiettivo non è chiaramente proprio del BIM, anche se si è tentato di codificarlo e circoscriverlo fino alla noia. La ISO 19650-1 introduce il concetto di Model Purpose e ne elenca alcuni “ragionevoli”. Ne ho scritto spesso.

Nella declinazione di un obiettivo, abbiamo provato a analizzarne uno, ovvero l’inserimento del modello in un database generale di tutti gli edifici scolastici. Ci siamo basati sui dati pubblicamente a disposizione sul sito del MIUR e ne è nato un progetto collaterale di mappatura, ma questa è un’altra storia e dovrà essere raccontata in un altro momento.

Usi del Modello

Dagli obiettivi che gli stakeholder formulano, più o meno chiaramente, ricaviamo la definizione del primo tassello fondamentale per operare in BIM, ovvero gli usi del modello.

Dalla definizione degli usi, è possibile individuare le discipline interessate, la strategie di integrazione tra i vari usi e il conseguente breakdown del modello. Ma prima di lanciarsi alla carica urlando Geronimo, rimane una domanda fondamentale e – ancora una volta – riguarda gli stakeholder: i collaboratori e gli specialisti delle varie discipline sono in grado di consegnare ciò che viene richiesto?

Alla domanda si risponde solitamente portando avanti un processo di assessment e ne abbiamo visti tre:

• il Maturity Assessment di BuildingSMART, originariamente sviluppato e proposto da Arup;
• la matrice di Bilal Succar;
• la piattaforma Bmat, illustrata meglio a questo indirizzo.

Consiglio di provare quest’ultima: è necesaria la registrazione, ma è gratuita.

Per raggiungere l’obiettivo, qualcuno deve aver messo qualcosa nel modello, in qualche modo.

Gli usi del modello identificati dalla classe, tra tutti quelli emersi nello studio delle user stories, sono stati tre:

• la riconversione degli spazi e la creazione di nuove aule, spogliatoi per i dipendenti, spazi calmi, sale per lo streaming;
• analisi sulla capienza degli spazi e adeguamento del layout;
• analisi dei flussi di accesso e adeguamenti degli spazi annessi.

Livelli di Sviluppo degli Oggetti

Ovviamente, non avrei potuto parlare di un BIM Execution Plan senza affrontare il concetto di Livelli di Sviluppo, che ci viene come naturale conseguenza da qualunque considerazione che abbia senso riguardo al modello e ai suoi usi.

Come sempre e come mi è capitato di scrivere ormai tante (troppe) volte, esistono due livelli: un lviello relativo alla progressione del lavoro rispetto alle fasi e un livello relativo al concetto di affidabilità e stabilità delle informazioni contenute negli oggetti del modello.

Sebbene il concetto di Livello di Sviluppo (LOD) sia tecnicamente superato dal concetto di Level of Information Need (che sarebbe LOIN senza problemi, se qualcuno si fosse preoccupato di controllare il significato dell’acronimo prima di crearlo). Trovo però impossibile rendere comprensibile il concetto senza passare dal suo antenato.

In relazione alle fasi di progettazione, segnalo lo specchietto comparativo incluso nel RIBA Plan of Work 2020. Interessante non tanto la suddivisione tra Gran Bretagna ed Europa (it’s Brexit, bitch) ma la distinzione tra Europa e Spagna. Forse sanno qualcosa che noi non sappiamo.

Per la nostra scuola ho ipotizzato tre fasi:

• le informazioni da raccogliere in fase di rilievo;
• le informazioni necessarie al progetto della riconfigurazione;
• le informazioni da restituire al cliente, inteso naturalmente come l’insieme degli stakeholder analizzati in precedenza.

Molti degli usi del modello coinvolgevano in qualche modo i locali, naturalmente, che naturalmente sono “oggetti” un po’ anomali. Trovo sempre interessante quindi provare ad analizzare l’approccio statunitense, che identifica il livello di sviluppo dei locali in relazione a quello degli elementi che li definiscono. Ha perfettamente senso e ci consente di non perdere di vista che tutti gli oggetti hanno relazioni tra loro e che quindi un livell di sviluppo per una categoria se ne porta dietro molti altri.

Con un occhio alla norma UNI 11337-4, il discorso è sempre da scindere tra geometrie e informazioni. Credo che ormai lo sappiano anche i muri. Ma forse mi illudo.

Con un occhio alla norma sui LOIN in lavorazione, la definizione passa a essere anche sulla documentazione. Ma riguardo agli output, come vedremo, preferisco adottare un approccio “di ritorno”.

Il livello di fabbisogno informativo si declinerebbe quindi su:

• geometria:
  • dettaglio;
  • dimensionalità;
  • posizione;
  • aspetto;
  • comportamento parametrico.
• informazioni alfanumeriche:
  • identificatore dell’oggetto;
  • nome;
  • attributi specifici.
• documentazione.

Breakdown del modello

Su questo argomento mi avete chiesto qualche riferimento, oltre a quelli presentati a lezione ovvero:

• il caso studio in due parti Stepping Up to Completing Extra Large Projects in Revit (parte 1 e parte 2) presentato da Brian Kish su ArchSmarter;
• il Capitolato Informativo per la redazione dell’offerta per la Gestione Informativa del Nuovo Ospedale di Cesena (pdf ancora scaricabile qui).

Ho menzionato quindi il caso studio relativo alla Battersea Power Station di Londra, presentato all’Autodesk University di due anni fa da James Savage e Anthony Campbell.

Ricordo che la PAS 1192-2, con il dettaglio dei suoi flussi di collaborazione basati su modello, non esiste più. Il concetto di modello federato (o aggregato) è tuttavia ancora validissimo, è vivo e combatte insieme a noi. La ISO 19650-1 ce lo presenta come l’elemento caratteristico dello Stage 2, il livello di maturità cui bisognerebbe ambire come industria.

La stessa norma internazionale ci fa anche la grazia di fornire alcune motivazioni ufficiali che portano alla suddivisione di un progetto in più modelli da aggregare, ovvero:

• consentire ai diversi team di produrre le necessarie informazioni senza generare problemi di coordinamento (viene finalmente riconosciuto, rispetto alla PAS 1192-2 e al suo Level 3, che il problema del lavoro contemporaneo non è tecnologico, ma di processo);
• garantire il mantenimento della sicurezza delle informazioni;
• alleggerire i modelli per favorirne la trasmissione.

Nomenclatura File, Documenti e Oggetti

Le regole di nomenclatura costituiscono normalmente una delle parti operativamente più importanti di un BIM Execution Plan e il nostro non ha fatto eccezione. Per quanto riguarda i documenti, è bene ricordare che:

1. Le regole di nomenclatura del BS 1192 non esistono più se non come (futura) appendice nazionale della ISO 19650, che si limita a indicare come sia opportuno avere delle regole di nomenclatura (ma dai?);
2. La maggior parte dei sistemi di gestione documentale per il lavoro in qualità prevede una nomenclatura analoga a quella proposta nel vecchio standard britannico, che quindi non ha inventato nulla;
3. Molti dei campi che compongono la nomenclatura di un file sono in realtà intesi come metadati: inserirli fisicamente nel nome file è tecnicamente riduttivo;
4. Esiste un limite caratteri per il nome del file e il percorso (vedere qui, per i più dubbiosi).

Spesso ci si ferma qui, ma la nomenclatura degli oggetti (al minimo) è necessaria per operare bene all’interno di un modello. D’altronde è modellazione orientata a oggetti, non modellazione orientata a documenti.
Per quanto riguarda la nomenclatura degli oggetti, esiste uno standard britannico cui consiglio di far riferimento, quantomeno per consolidare l’importanza dei sistemi di classificazione.

Output

L’ultima parte su cui ci siamo concentrat è stata l’analisi degli output e delle loro implicazioni su tutti i ragionamenti fatti fino ad ora, suddividendo in tre tipologie di output:

1. Output documentali, grafici e non grafici (es: le tradizionali “tavole”);
2. Output analitici;
3. un tipo di output differente, che richiede il lavoro di uno specialista, e che ho definito output “esperienziale”: nel nostro caso si trattava di una piattaforma web, ma lo stesso discorso vale ad esempio per le esperienze di realtà virtuale.

Per quanto riguarda gli output documentali grafici, abbiamo cercato di analizzare le informazioni aggiuntive che ci vengono dall’analisi di un output tradizonale e il supporto che ci possono offrire nella definizione di breakdown, categorie, attributi e livelli di fabbisogno informativo.

Riguardo all’analisi, sappiamo che esistono diversi livelli di integrazione tra gli strumenti specifici per queste attività e gli strumenti di authoring. I diversi livelli di venivano raccontati nella vecchia PAS 1192-2 quando provava a spiegarci i diversi scenari in cui è accettabile dire di stare lavorando in BIM e variano da un livello di non integrazione (non BIM) al livello di completa integrazione sincrona, passando per un’integrazione asincrona (export / import) che può prevedere lo scambio di soli modelli geometrici o di modelli informativi.

Naturalmente quest’ultimo scenario ci porta sull’accidentato terreno della mappatura delle nostre categorie e dei nostri attributi in classi e pSet di… indovinate cosa? Sì, lui.

Ma è l’ultimo tipo di output che ci porta a farci delle domande più profonde sull’impianto generale, perché il coinvolgimento di ogni specialista comporta la necessità di analizzare le sue esigenze e le ricadute su tutto ciò che abbiamo fatto fino ad ora. Serve una piattaforma su cui caricare i modelli per renderli interattivi? Tempo di ricominciare il ciclo.