Spoiler: i codici non sono burocrazia, sono coordinate.
Con le classificazioni un modello non è più una bella nuvola 3D, ma un catalogo che si filtra, si computa e si scambia senza perdersi.
Contesto & problema (perché conta ora)
Ogni progetto parte da una promessa: «questa volta i dati saranno in ordine». Poi apri il modello e scopri che “porta” si chiama “door_01_finalissima_v3”. Succede perché manca una mappa. Nel Building Information Modeling (BIM – modellazione informativa) le classificazioni sono quella mappa: ti dicono che cos’è un oggetto, dove sta e a cosa serve. Senza codici il modello resta muto: niente abachi affidabili, niente scambi IFC – Industry Foundation Classes puliti, niente COBie – Construction‑Operations Building information exchange che il facility manager possa usare. La serie ISO 19650 e la UNI 11337 ci ricordano che il dato non è casuale: vive in un CDE – Common Data Environment (Ambiente di Condivisione Dati) e ha metadati chiari.
Se capisci cosa classificare (funzione, sistema, prodotto, spazio), smetti di chiedere “dove metto questo parametro?” e inizi a chiedere “come riuso questo codice nel computo, nel capitolato, nel collaudo, nella gestione?”. È il passaggio dalla modellazione per tavole alla modellazione per scopi. La differenza tra un modello bello e un modello utile.
Idea centrale / mappa concettuale (le mappe non sono il territorio)
Una classificazione non è un’etichetta appiccicata in fondo: è una prospettiva. Lo stesso edificio lo puoi leggere come funzioni (elementi d’opera), come sistemi e prodotti, come lavorazioni, come spazi o persino come asset dell’ente che lo gestirà. Ogni standard accende una torcia su una parte del territorio; il trucco è usare la torcia giusta al momento giusto e non accecare il team con mille luci. L’imbuto è questo: scopo → tabella → parametro in Revit → output. Se lo rispetti, i dati passano senza intoppi da modello a IFC/COBie e da lì al CDE.
Piccolo schizzo ASCII per non perderci:
| [Scopo] | [Tabella] | [Parametro Revit] | [Output] |
|---|---|---|---|
| Stima preliminare | Uniformat / Uniclass EF | AssemblyCode / EF_code | QTO e costi |
| Coordinamento MEP | Uniclass Ss | Ss_code (istanza) | Viste e filtri |
| Capitolati/forniture | MasterFormat / Pr / Omni23 | Keynote / Pr_code | Capitolati |
| Asset/Facility | Uniclass En / SL + COBie | En/SL (Rooms) | AIM e FM |
Formati e tassonomie (senza sbadigli)
Uniformat (UniFormat II) guarda al cosa fa: è la tassonomia per elementi d’opera (A Sottostruttura, B Involucro, C Interni, D Impianti…). È la lente che preferisci quando devi stimare e confrontare opzioni senza perdersi nel dettaglio.
Uniclass 2015 è la collezione di tabelle a faccette: Co (complessi), En (entità), SL (spazi/luoghi), EF (elementi/funzioni), Ss (sistemi), Pr (prodotti). Parla nativamente la lingua del BIM e dell’interoperabilità. Richiede disciplina, ma ripaga: con Ss filtri i sistemi impiantistici, con Pr differenzi i prodotti, con SL agganci gli ambienti.
MasterFormat e OmniClass mettono ordine sul come si descrivono le lavorazioni e i prodotti nei capitolati. Nel mondo anglosassone sono lo standard di fatto; in Italia convivono spesso con listini DEI/regionali.
Poi c’è la casa madre: UNI 11337 (gestione informativa, ruoli, processi, criteri di codifica) e la serie ISO 19650 (processi informativi, requisiti, LoIN – Level of Information Need). Non servono per “ingessarti”, ma come binari su cui far scorrere i dati.
Idea chiave: classificare ≠ “mettere un codice a caso”. È scegliere una vista utile a uno scopo e fissarla in parametri stabili. Se capisci questo, smetti di chiedere “LOD quanto?” e inizi a chiedere “LoIN per cosa?”.
Revit: i ganci giusti (e quelli da evitare)
Revit ha già alcune maniglie. Assembly Code è perfetto per Uniformat nelle prime fasi. OmniClass Number è utile quando lavori con OmniClass o ti serve un parcheggio “pulito” per altre tassonomie. Keynote è l’aggancio naturale ai capitolati. Mark/Type Mark non sono classificazioni, ma ti salvano la vita per abachi e controlli. Il resto lo fai con Shared Parameters: Uniclass_EF, Uniclass_Ss, Uniclass_Pr per elementi e famiglie, Uniclass_En e Uniclass_SL per entità e ambienti.
Una regola che non tradisce: istanza dove il contesto conta (stanze e spazi, sistemi installati), tipo dove la classe non cambia (porte, diffusori, apparecchi). Dai ai parametri nomi corti e coerenti, e usa abachi QA con la colonna “Vuoto?” per smascherare i buchi. Non innamorarti di un solo standard: in Italia la doppia codifica (Uniclass per interoperabilità, Codice_Listino per i computi) è spesso l’unica strada per evitare i copia‑incolla acrobatici tra Revit ed Excel.
Dal modello al CDE: la vita sociale dei dati
Il dato non vive solo in Revit. Quando esporti in IFC ricorda che esistono i Classification Reference: se hai mappato bene EF/Ss/Pr, i codici viaggiano. In COBie quei codici si appoggiano a Type e Component e diventano filtri veri per chi gestirà l’asset. Nel CDE – Common Data Environment (penso a Autodesk Construction Cloud con Docs e BIM Collaborate) i file non sono “depositati”: sono contenitori informativi con Status, Revisione e, sì, Classificazione. È qui che la coerenza paga davvero: se il contenitore è marcato S1 – For coordination e ha revisione P01, nessuno userà “per sbaglio” un PDF sbagliato o un RVT non condiviso.
E se vuoi contare senza Revit? La sorpresa è Model Coordination: non è un abaco online, ma fa una cosa che mancava. Apri il modello nel browser, filtri per proprietà (categoria, disciplina, parametri personalizzati), attivi Object Colors e scegli Color by → Property (tipo, Fire Rating, Uniclass…). La legenda ti restituisce quanti oggetti per ogni valore. Con due clic hai “tutte le porte EI60”, colorate e contate. Salvi la vista e la condividi in Docs per chi non apre Revit: QA visuale, rapida, democratica.
Caso d’uso A — “BEP per Scuola: Uniclass come lingua franca”
Immagina una nuova scuola secondaria. Il committente chiede abachi chiari, IFC puliti e coordinamento MEP senza drammi. Nel BEP – BIM Execution Plan / PGI – Piano di Gestione Informativa decidi che la lingua sarà Uniclass: En/SL per campus, edificio e aule; EF per gli elementi architettonici e strutturali; Ss per gli impianti; Pr per i prodotti ricorrenti (porte, corpi illuminanti, terminali). In Revit i parametri sono pronti nel template; negli abachi QA compaiono subito i vuoti.
Ogni settimana un pilot: esporti l’IFC, controlli i Classification Reference, generi un COBie minimale con i codici su Type. Intanto nel Model Coordination salvi tre viste: “Aule per SL”, “Sistemi per Ss”, “Prodotti critici per Pr”. Chi deve solo verificare non apre Revit: entra, filtra, conta, commenta. Risultato? Consegne ripetibili, tracciabilità nel CDE, zero fogli paralleli “appoggio” che prima o poi si contraddicono.
Caso d’uso B — “Uniformat + Keynote per Ospedale: decidere in fretta”
Estensione ospedaliera, decisione in quattro settimane. Qui serve velocità. Metti Uniformat su Assembly Code e ragioni per blocchi: involucro, interni, impianti. Crei abachi costo‑centrati che parlano in modo comprensibile anche a chi non mastica BIM. Le poche voci critiche le agganci a Keynote (MasterFormat o listino) per non perderle in avanti.
Quando il progetto entra nel dettaglio, non distruggi ciò che hai fatto: introduci Uniclass (Pr/Ss dove serve granularità) e continui a usare i codici Uniformat per confronto opzioni. È una transizione morbida: niente ricodifiche epiche, niente doppie verità. Ripetibilità senza rigidità.
Errori ricorrenti → antidoti
Primo errore: mescolare standard senza scopo. Uniformat oggi, domani codici “di fantasia”, dopodomani MasterFormat “perché sì”. Antidoto: lega ogni tabella a un obiettivo (stima, coordinamento, gara, gestione) e scrivilo nel BEP/PGI.
Secondo errore: parametri a testo libero. Nel giro di due mesi avrai tre varianti dello stesso codice. Antidoto: Shared Parameters con elenchi controllati, abachi QA con “Vuoto?” e colorazioni in vista per gli elementi non classificati.
Terzo errore: codici solo nel modello e non nel CDE. Poi nessuno trova la versione giusta. Antidoto: in Docs usa Status/Revision/Classification come metadati dei contenitori. Il CDE non è un Dropbox elegante: è il registro del progetto.
Quarto errore: confondere LOD con LoIN – Level of Information Need. Non esiste un LOD magico che salvi tutto. Antidoto: chiedi “quale scopo?” e definisci LoIN (geometria + alfanumerico + documenti) nel EIR – Exchange Information Requirements; poi verifica davvero in consegna.
Contro‑esempio utile: Uniclass ovunque, sempre. In un concept sprint può diventare un cappio. Antidoto: parti con Uniformat/EF per mettere in fila i costi, poi apri il ventaglio con Ss/Pr dove servono.
Dal CDE alla Business Intelligence (per far parlare i numeri)
La qualità non si monitora a occhio. Se esporti gli abachi e/o lanci una raccolta proprietà dai modelli pubblicati in ACC, in mezz’ora hai un dataset che racconta il progetto: quante porte hanno il Fire Rating compilato, quanti elementi riportano il codice Uniclass, quanti spazi non hanno SL. In Power BI o Tableau puoi costruire un cruscotto che il Project Manager capisce al volo: widget “% elementi con codice”, grafico porte EI per piano, trend di compilazione per milestone, matrice categoria × LoIN.
Nota: La società di formazione e consulenza Forma Mentis di Milano, con cui spesso collaboro, ha appena finito il corso “Power BI(M) – Fondamenti di Business Intelligence”. Probabilmente a breve faranno una seconda edizione, quindi tenete d’occhio il loro sito.
Due dritte immediate: modello a stella (Fatti = elementi; Dimensioni = categorie, codici, livelli, fasi) e una misura DAX semplice per contare “elementi senza codice”. Pubblica il report accanto ai modelli in Docs. Così la direzione lavori non chiede “mandami l’Excel”: apre il cruscotto e vede lo stato in tempo reale.
Come parti domattina (to‑do pratico)
Scegli la strategia e scrivila nel BEP/PGI: Uniformat/EF per concept e costi; Uniclass Ss/Pr per coordinamento e gare; En/SL + COBie per l’AIM – Asset Information Model. Prepara uno schema di Shared Parameters con nomi brevi (EF_code, Ss_code, Pr_code, En_code, SL_code, Codice_Listino) e popola le famiglie più usate. Allena il CDE: in Docs attiva Status/Revision/Classification e usa naming coerente. Fai un pilot: 10 famiglie classificate, un IFC di prova, una vista in Model Coordination che colori per Property e un mini‑cruscotto Power BI per vedere dove mancano i codici. Da lì, iterazioni corte e costanti.
Nota/Disclaimer (norme e limiti)
Questo testo segue la cornice ISO 19650 e UNI 11337: definisci i requisiti a monte (OIR – Organizational Information Requirements, AIR – Asset Information Requirements, PIR – Project Information Requirements, EIR – Exchange Information Requirements), concorda i LoIN, governa i dati nel CDE e pensa open (IFC, COBie) fin dall’inizio. Gli annessi nazionali possono specificare naming e ID dei contenitori: adeguali, ma non perdere di vista il principio madre — coerenza documentata.
In sintesi: scegli la tabella giusta per lo scopo, aggancia i parametri giusti in Revit, usa Model Coordination per verifiche e conteggi rapidi, e fai parlare i dati con un cruscotto BI. È la differenza tra modellare e gestire informazioni.
