Standard e classificazioni: perché senza codifiche il BIM non decollerà

Premesse

In un certo senso ho visto il sogno dei sistemi CAFM come autentico acceleratore di competitività naufragare sugli scogli dei vincoli di tempo, di budget e di cultura dei team operativi. Ho sinceramente il timore che lo stesso possa avvenire con il BIM che sicuramente alza l’asticella della complessità tecnica ed informatica.

Per questo partire con  il piede giusto di una solida costruzione delle classificazioni di base sarà una condizione necessaria a non uccidere il neonato in culla. In questo può venire in aiuto il lavoro di strutturazione che sta facendo buildingSmart.

Un modello IFC ben popolato assegna a ogni oggetto un tipo dello schema – IfcWall, IfcDoor, IfcFlowSegment – ma il tipo IFC da solo non basta a rendere un oggetto confrontabile con un catalogo prodotti, con un prezzario o con un registro asset di gestione: serve un secondo livello di codifica, la classificazione, che colloca l’oggetto in una tassonomia riconosciuta al di fuori del singolo progetto. Ad oggi questo secondo livello è ancora assente o applicato in modo non sistematico, ed è uno dei motivi per cui il BIM, pur in crescita, non ha ancora il  potenziale atteso.

Che differenza c’è tra un tipo IFC e un codice di classificazione?

Il tipo IFC descrive la natura strutturale dell’oggetto nello schema – “questo è un muro”, “questo è un componente di distribuzione fluidi” – ma non distingue, ad esempio, tra un muro portante in calcestruzzo e una tramezzatura leggera, né colloca un componente impiantistico in una gerarchia di sistema più ampia.

Un sistema di classificazione, applicato come proprietà aggiuntiva sull’oggetto, aggiunge questo livello: codici riconosciuti per identificare con maggior chiarezza la categoria specifica del prodotto o dell’elemento costruttivo, utilizzabile per aggregare, filtrare e confrontare oggetti a prescindere dal software che li ha generati. Senza questo secondo livello, ogni estrazione che richieda una categorizzazione più fine del semplice tipo IFC – un computo richiede una riclassificazione manuale a valle.

Perché una nomenclatura interna non sostituisce una classificazione pubblica?

Molti team di progettazione adottano convenzioni di denominazione interne, coerenti all’interno del singolo studio ma non standardizzate verso l’esterno. È un miglioramento reale rispetto al caos, ma resta un sistema locale: leggibile da chi lo ha definito, ambiguo per chiunque altro debba interrogare il modello in modo automatico o confrontarlo con un modello prodotto da un altro studio. La differenza pratica emerge nel momento dello scambio tra attori diversi della filiera – progettista, impresa, committente, futuro gestore – ognuno dei quali, senza un riferimento condiviso, deve reinterpretare la nomenclatura altrui prima di poterla usare.

Cosa succederà quando i modelli di due edifici dello stesso patrimonio saranno consegnati da team differenti?

È una situazione prevedibile per chi gestisce più immobili: un edificio modellato da uno studio con convenzioni proprie, un altro affidato a un secondo studio con convenzioni diverse. Confrontare i due patrimoni – un inventario aggregato, un’analisi comparata di manutenzione – richiede una riconciliazione manuale delle categorie, spesso troppo onerosa. Se si arrivasse ad una classificazione pubblica condivisa, applicata fin dall’inizio, non dovremmo arrenderci a riconciliazioni/normalizzazioni ex post da studi diversi.

Che effetto ha, per il Facility Management, l’assenza di classificazioni condivise in questa fase?

Per chi riceverà l’edificio in gestione, l’assenza di una classificazione condivisa a monte si traduce in un costo differito e concreto: un registro asset alimentato da un modello con codifiche coerenti può essere importato e aggregato automaticamente per categoria; uno alimentato da nomenclature libere richiede una rielaborazione manuale che, nella pratica di questi anni, quasi mai viene completata fino in fondo. L’ambito del FM in questa fase evolutiva del BIM non è ancora nella posizione di richiedere questo requisito in capitolato: lo subisce, quando esiste, come conseguenza indiretta delle scelte fatte in progettazione.

Conclusioni

La classificazione è la condizione strutturale che decide se un modello resterà un artefatto isolato o potrà davvero alimentare processi a valle – computi comparabili, registri asset aggregabili, gestione multi-edificio. Al momento questa consapevolezza resta patrimonio di pochi team avanzati; diventerà requisito esplicito solo quando la normativa comincerà a imporre capitolati informativi verificabili. Prima di allora serve comunque porre l’argomento della stesura di classificazioni e affermazione di standard condivisi.

Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui