shelidonAugust 10, 20151 Comment on Il COBie, questo sconosciuto: verso un BIM per il Facility Management

Lo scorso luglio, è stata rilasciata la terza versione del National BIM Standard per gli Stati Uniti, un progetto che la National Institute of Building Sciences (parte della buildingSMART alliance) sta portando avanti a livello nazionale da diversi anni. Ciò che è importante capire, prima di addentrarsi in quello che a mio avviso è il capitolo più interessante di questa versione revisionata e corretta secondo le ultime direttive ISO/IEC, è che non si tratta di un documento governativo. Il pamphlet, un pacchetto di 50 documenti per un totale di 110 Mb in cartella compressa, costituisce una linea guida che mira a definire lo standard al di là e al di sopra dei formati proprietari, ma non costituisce normativa. La regolamentazione del BIM negli Stati Uniti è affidata ai singoli stati (si vedano per esempio le Design Guidelines and Standards messe a disposizione dallo stato del Wisconsin, o gli Ohio BIM Protocols), mentre a livello federale sono già disponibili protocolli di standard quali quello dell’U.S. Department of Veterans Affairs o il recentemente aggiornato National BIM Overview del GSA.

Ciononostante, il documento di buildingSMART offre alcuni strumenti interessanti, soprattutto in uno dei campi tutt’ora critici della “ruota” BIM: la manutenzione.

Il COBie, questo sconosciuto

Mi era già capitato di parlarne quando il National Bim Report britannico ci aveva informato che persino i nostri colleghi d’oltremanica continuano a fare un uso limitatissimo del formato COBie. Come giustamente dichiarava un saggio anonimo nel documento NBS:

…a lot of effort (and money) has been put
into COBie, but the whole Excel sheet concept
contradicts the fundamental principle of a
common data environment.

Vediamo qual è la risposta che la buildingSMART statunitense ci propone nel tentativo di sbrogliare l’ingarbugliato problema.

Un po’ di storia: il COBie e le sue origini militari

Tanto per cominciare, è sempre bene ricordare da dove nasce il formato.

I primi Business Process Models a supporto del COBie (Construction Operations Building Information Exchange) risalgono ad un U.S. Army Technical Report del lontano 2007, e l’esercito degli Stati Uniti ha continuato a lavorare ai processi pertinenti il ciclo di vita degli edifici fino a quest’ultima versione dell’NBIMS-US™ V3. Smettiamo quindi di sorprenderci se il formato ci appare un po’ rigido.

L’obiettivo della ricerca portata avanti da bSMART è utilizzare il business process modeling che ha portato alla nascita del COBie, ma combinandolo con i principi di management propri della produzione snella, in modo da portare a confronto lo stato dell’arte del BIM con i processi COBie-based. Il confronto, per quanto accademico, si rivela interessante ed è un primo passo verso la soluzione del problema alla base del collo di bottiglia creato dal COBie al termine del processo di progettazione BIM. Come, quindi, prepararsi al peculiare output di dati richiesto dal Facility Management? O, ancora meglio, come preparare il proprio modello in modo da mantenere intatta la “ruota” del BIM?

Premessa: i principi della produzione snella

Per meglio comprendere l’intelligente operazione di bSMART nel tentativo di avvicinarci al COBie, è necessario avere chiari i principi della produzione snella cui accennavo poco sopra.

Il termine, dall’inglese lean production, è stato coniato una quindicina di anni fa dagli studiosi James P. Womack e Daniel T. Jones all’interno del loro libro The Machine That Changed the World (Harper Perennial, Novembre 1991), in cui analizzavano i processi virtuosi del sistema di produzione Toyota rispetto a quelli dei concorrenti. Ancora una volta, per inciso, la filiera delle costruzioni attinge a piene mani dal mondo dell’industria automobilistica che, non dimentichiamo, è stata la prima a teorizzare i concetti da cui deriva il nostro BIM.

Ma su quali principi si basa, in sintesi, la teoria della produzione snella?

Intanto è necessario partire una progettazione mirata, chiamata DFX ovvero Design for X. Si tratta di un’espressione utilizzata in ambito industriale ma estremamente attuale se trasferita nell’ambito delle costruzioni e indica un metodo di progettazione che sia già pensato non solo in base al ciclo di vita del prodotto ma anche all’ottimizzazione della sua realizzazione. La cosiddetta progettazione seriale viene disincentivata a favore di una progettazione mirata del singolo prodotto per la specifica esigenza e nello specifico contesto. Alcune declinazioni del Design for X applicato alla produzione industriale sono:

• Design for Manufacturability (DFM) e Design for Economic Manufacturability;
• Design for Producibility;
• Design for Testability;
• Design for Reliability;
• Design for Installability (si veda l’annosa questione della Soft Clash Detection);
• Design for Serviceability;
• Design for Recycling;
• Design for Environment;
• Design for Assembly e Design for Disassembly.

Numerosi di questi approcci sono perfettamente applicabili alla progettazione architettonica. Ma questa, come si suol dire, è un’altra storia.

Secondo passaggio della produzione snella è la Gestione della Produzione secondo il principio Just in Time (JIT), che sposta il focus dalla logica push (produzione massimizzata di prodotti non ancora venduti) alla logica pull, ovvero alla produzione di quei soli prodotti già venduti o che si prevede di poter vendere nell’immediato futuro.

Terzo e ultimo passaggio è la valorizzazione del prodotto secondo il principio del Total Quality Management (TQM).

Di questi tre passaggi, per quanto siano estremamente attuali a tutti i livelli dell’industria delle costruzioni, bSMART si concentra sul primo, ovvero sul concetto di DFX, e prova a sviluppare un fusso di lavoro mirato al conseguimento di un outpout che sia “COBie-compliant”.

Life-Cycle Phase List

• Study and Define Needs
• Develop Design Criteria
• Study Technical Feasibility
• Communicate Results Decision
• Develop Program – Space Program
• Develop Program – Product Program
• Prepare Invitation to Bid and Receive Proposal (Pre-Design)
• Explore Concepts – Design Early
• Develop Design – Design Schematic
• Develop Design – Design Coordinated
• Finalize Design – Design Final
• Prepare Invitation to Bid and Receive Proposals (Post Design)
• Respond to Pre-Proposal Inquiries
• Develop Pre-Construction Plan
• Identify Discrepancies
• Prepare Submittal Information – Product Type Selection
• Prepare Submittal Information – System Layout
• Organize Submittal Information
• Perform Submittal Review – Submittal Issue
• Provide Resources
• Execute Construction Activities
• Perform Equipment Testing
• Inspect and Approve Work
• Define, Record and Certify Discrepancies
• Closeout.

L’approccio di buildSMART si basa sul principio che una grande parte di queste fasi, specialmente le fasi preliminari che coinvolgono la committenza, non possano essere svolte direttamente sul modello ma debbano interfacciarsi con successo con input di dati in formato diverso. Per ogni fase del processo, il documento analizza i presunti vantaggi di utilizzare il BIM. Per molte voci, il vantaggio si riduce a un discutibile «Reproduction savings from reliance on electronic documents and the elimination of paper» (sia chiaro che non discuto i vantaggi economici dell’eliminare la carta stampata, quanto il fatto che ricorrere al BIM sia davvero condizione necessaria e sufficiente a far sì che l’utenza e gli operatori smettano di voler stampare i documenti di lavoro). Tuttavia è piuttosto interessante riportare ciò che viene enunciato come vantaggio alla voce Space Program:

1. Design professionals typically re-enter the Owner’s space requirements into the system they use for space programming. COBie-formatted data permits data to be transferred directly from the Owner to the Architect or Planner’s system
2. Requirements associated with each space are typically gathered and then documented on Room Data Sheets. COBie format would either eliminate the need to produce room data sheets or support automation of their production
3. The Architect/Planner sends the Space Program to the Owner’s Representative for review. Currently, this is done by comparing 2 documents. Use of COBie format would permit automated checking.
4. If the Architect/Planner could automate checking of his work product against the Owner’s requirements, then a rework/re-review cycle could be eliminated.

Gli stessi punti, con formulazioni diverse della frase, vengono ripetuti alla voce immediatamente successiva, Develop program: Product Program.

Ora, io capisco benissimo la necessità di lavorare tutti sullo stesso formato, dal momento in cui il BIM prevede che si lavori tutti sullo stesso “oggetto” chiamato modello (tralasciando il fatto che credo sia possibile, anche senza tradire lo spirito del BIM, far confluire all’interno dello stesso modello diversi formati di file, sotto forma di link).

Il problema principale del COBie in questo senso è che introduce, e teorizza come virtuoso, un formato di dati esterno ed estraneo al modello, che con esso deve interfacciarsi. La necessità quindi è quella di comprendere le necessità del formato e sviluppare protocolli che consentano l’esportazione rapida dei dati dal modello BIM nel formato desiderato, possibilmente conservando la possibilità di reimportare il feedback del cliente all’interno del modello senza ricorrere a lunghi e laboriosi data-entry completamente manuali.

Ora, come qualunque buon informatico potrà dirci, l’operazione di per sé non è affatto complessa: tutto ciò che occorre conoscere è la mappatura dei campi, ovvero quali dati dal modello BIM devono essere fatti confluire in quali campi del formato COBie. Tuttavia, si tratta ancora di un processo che conserva la “variabile impazzita” del documento esterno. In circostanze che prevedono la redazione di un Room Data Sheet ancora prima che venga tirata la prima linea, questo è a mio parere inevitabile almeno fino al raggiungimento della fase “Explore Concepts – Design Early”. A partire da quella fase in poi, tuttavia, diventa una questione di priorità. È tecnicamente possibile infatti, secondo il principio del Design for X, impostare un intero modello perché contenga nelle giuste categorie e con la giusta denominazione tutti i parametri necessari a mantenere all’interno del modello i dati necessari al Facility Management. Anche utilizzando un software proprietario come Revit. Molti dei campi richiesti sono già utilizzati come parametri nella normale progettazione architettonica BIM.

Il Type Worksheet Schema (a titolo esemplificativo) richiede i seguenti parametri. Tra parentesi viene specificato il formato del campo così come richiesto:

• Name (Alfanumerico)
• CreatedBy (Contact.Email)
• CreatedOn (data ISO del tipo 1900-12-31T23:59:59)
• Category (PickList.CategoryProduct)
• Description (Alfanumerico)
• AssetType (PickList.AssetType)
• Manufacturer (Contact.Email)
• ModelNumber (Alfanumerico)
• WarrantyGuarantorParts (Contact.Email)
• WarrantyDurationParts (Numerico)
• WarrantyGuarantorLabor (Contact.Email a due cifre)
• WarrantyDurationLabor (Numerico)
• WarrantyDurationUnit (PickList.DurationUnit)
• ExternalSystem (di sistema)
• ExternalObject (di sistema)
• ExternalIdentifier (di sistema)
• ReplacementCost (Numerico)
• ExpectedLife (Numerico)
• DurationUnit (PickList.DurationUnit)
• WarrantyDescription (Alfanumerico)
• NominalLength (Numerico)
• NominalWidth (Numerico)
• NominalWidth (Numerico)
• ModelReference (Alfanumerico)
• Shape (Alfanumerico)
• Size (Alfanumerico)
• Color (Alfanumerico)
• Finish (Alfanumerico)
• Grade (Alfanumerico)
• Material (Alfanumerico)
• Constituents (Alfanumerico)
• Features (Alfanumerico)
• AccessibilityPerformance (Alfanumerico)
• CodePerformance (Alfanumerico)
• SustainabilityPerformance (Alfanumerico)

Molti di questi parametri “non nativi”, possono essere facilmente implementati. Ulteriori funzionalità possono essere fornite agganciando i parametri, anziché a valori alfanumerici, ad un sapiente uso delle fasi (Allowed Value: PickList.DurationUnit).

Design for COBie: perché non farlo?

La risposta a questa domanda è semplice e non risiede né in una particolare difficoltà tecnica o di implementazione, né nella mancanza di uno standard ben documentato. La risposta, come spesso accade, risiede in una mancanza di committenza. Solo di recente mi sono imbattuta in un bando di concorso che richiedeva un modello BIM utilizzabile anche dal Facility Management. Su 8 punti aggiuntivi riservati al BIM, 1 punto soltanto veniva assegnato per i partecipanti che volessero spingersi in questo terreno inesplorato. Ora, volendo ricordare ancora una volta ciò che ha avuto modo di dire recentemente Lorenzo Bellicini del Cresme, il Facility Management costituisce una ghiotta fetta di mercato. Tuttavia questo mercato deve avere la lungimiranza necessaria ed essere pronto a retribuire adeguatamente progettisti e costruttori, per i quali il Design for COBie costituisce un investimento e uno sforzo, almeno in prima battuta, che non conosce precedenti. I Case Studies del  National Institute of Building Sciences parlano di un risparmio considerevole. Non posso fare a meno di domandarmi quando un tale risparmio, visibile solo all’invecchiamento dell’edificio, sarà effettivamente misurabile. Tuttavia, spero che non si debba aspettare così a lungo, e che una larga parte di committenza illuminata inizi a richiedere passi in tal senso. Solo da una richiesta effettiva e concreta da parte del mercato, sarà possibile sviluppare in modo effettivo ed efficace gli strumenti necessari al conseguimento del risultato.

Tuttavia, dato che siamo pionieri, ecco alcuni tool disponibili per chi volesse sperimentare con il formato:

• Model transformation, checking, and reporting: http://www.aec3.com/en/6/6_04.htm
• EcoDomus PM Commercial: http://www.ecodomus.com/index.php/ecodomus-pm/
• Onuma System Commercial – free COBie file checker: http://www.onuma.com/products/OpsAndCOBieValidate.php

Infine, è disponibile uno spreadsheet Google di buildingSMART : http://www.projects.buildingsmartalliance.org/files/?artifact_id=5445