Premesse
Negli ultimi anni ho seguito da vicino moltissime realtà alle prese con la gestione di edifici, impianti e patrimoni immobiliari: aziende produttrici con più stabilimenti, società di gestione, clienti finali come enti pubblici e aziende ospedaliere. In quasi tutte ho trovato lo stesso quadro tecnico, al di là delle differenze di settore: un gestionale di manutenzione vissuto come speranza di efficienza che si scontra con mancanza di tempo, di risorse e di soluzioni. In casi estremi alcuni clienti con contratti multipli si trovavano a interagire con molti sistemi diversi (uno per fornitore), quattro anagrafiche dello stesso edificio, spesso in disallineamento tra loro anche nelle codifiche di piani e locali.
Non è un problema di persone poco diligenti, né di scarsa maturità digitale: gli ultimi applicativi di settore spesso fanno tutti affidamento sugli stessi standard aperti e diffusi da decenni, e la stragrande maggioranza degli edifici moderni dispone già di documentazione tecnica digitale di ottima qualità. Il problema è che i sistemi che dovrebbero mettere a frutto quella documentazione sono stati progettati come archivi “chiusi” e autoreferenziali, non come piattaforme dati coordinate. Nel 2026 la battaglia tra i fornitori di software FM non si combatte più su “chi ha il CAD” o “chi ha il BIM” o chi ha “l’IA”: si combatte su chi trasforma quei formati e quegli strumenti in potenziatori di dati vivi, su chi non blocca il cliente in uno o più formati o vincoli tecnologici proprietari, e su chi risponde più in fretta a un’esigenza nuova.
All’inizio di questo nuovo anno mi sono sentito in obbligo di fare nuovamente un giro completo sulle fondamenta del mio settore. Con questo articolo apro una serie che affronterà, punto per punto e con un taglio più tecnico di quanto normalmente si trovi in un blog di settore, le caratteristiche che un software di facility management dovrebbe avere per essere davvero all’altezza del 2026. Lo farò tenendo sempre presenti quattro figure che vivono lo stesso strumento in modo molto diverso: il proprietario dell’immobile e i suoi building managers, il manutentore interno, la ditta esterna o il global service che opera in appalto, e il responsabile IT che deve far convivere tutto questo con la sicurezza e l’infrastruttura aziendale.
Quali sono i problemi tecnici che un buon software FM deve risolvere?
Il primo è l’unificazione del modello dati: un edificio, un piano, un locale, un asset dovrebbero avere un identificativo certo e costante nel tempo, condiviso tra il disegno CAD, il modello BIM e il gestionale, invece di esistere troppo spesso come tre entità separate collegate a mano. Tecnicamente, questo richiede che il disegno tecnico non resti un file allegato ma diventi un insieme di entità in un database – ogni linea, ogni polilinea, ogni blocco DXF come riga interrogabile, con la propria geometria salvata in formati adeguati [GeoJSON o WKT (Well-Known Text)] e collegata tramite chiave esterna alle tabelle gestionali.
Il secondo problema è architetturale: quanto costa, in tempo di sviluppo, aggiungere una nuova funzionalità di gestione? Se ogni nuova esigenza richiede una tabella progettata a mano, un’interfaccia scritta a mano e un’API scritta a mano, il costo di adattamento resta sempre alto. Un’architettura dati “config-driven”, in cui tabelle, campi e permessi vivono come metadati interrogati a runtime invece che come schema cablato nel codice, cambia radicalmente questa equazione.
Il terzo è la sicurezza applicativa: Row-Level Security risolta lato server, permessi granulari fino al singolo campo, tracciabilità di ogni operazione. Requisiti OWASP implementati davvero e non costretti a deroghe pericolose. Questi sono requisiti che, in un sistema che tratta dati di strutture, fornitori e servizi critici, non sono opzionali.
Perché parlarne ora, con questo taglio tecnico, nel 2026?
Pur avendo trattato questi contenuti nei post degli ultimi 13 anni, volevo tracciare anche un bilancio e fornire informazioni che azzerino le scuse. Perché le tecnologie per risolvere questi problemi sono mature e ben documentate: motori di rendering vettoriale nel browser basati su WebGL per i modelli 3D, librerie open source consolidate per la lettura e scrittura di file DXF e IFC, algoritmi geometrici standard – come il point-in-polygon per capire se un asset ricade dentro un locale – disponibili in qualunque libreria di calcolo geometrico. Non c’è più alcuna scusa tecnica per proporre soluzioni chiuse o superficiali: la barriera, oggi, non è la tecnologia disponibile, ma la volontà di investirci seriamente.
C’è anche una ragione contrattuale, non solo tecnica: molti capitolati di gestione immobiliare e di manutenzione iniziano a citare esplicitamente requisiti tecnici sempre più stringenti e di conformità GDPR sempre più invasiva. Un software inadeguato su questi fronti non è più solo un limite operativo: è un rischio contrattuale e, in alcuni casi, normativo.
Cosa distingue davvero un fornitore maturo da uno che si ferma alla superficie?
Nella mia esperienza, il modo più rapido per capirlo è guardare cosa succede “sotto” alla demo commerciale. Un fornitore maturo sa spiegare in che formato viene esportato un disegno, se i blocchi restano BLOCK e INSERT nativi o diventano geometria appiattita, se il modello dati è davvero relazionale con chiavi esterne coerenti o è una collezione di tabelle indipendenti collegate da un identificativo testuale ricopiato a mano. Un fornitore che si ferma alla superficie parla solo di funzionalità e schermate, mai di come i dati sono strutturati e cosa succede quando quella struttura deve evolvere.
Questa differenza si vede in modo ancora più netto quando arriva la prima richiesta fuori standard: un nuovo tipo di maschera o funzionalità, l’implementazione di un processo specifico del cliente, un’integrazione con un sistema terzo. Il fornitore maturo la assorbe con una configurazione. Quello superficiale apre un preventivo di sviluppo e scarica tempi e costi sul cliente.
Quale ruolo giocano gli standard aperti in questa distinzione?
Un ruolo centrale, e spesso sottovalutato da chi valuta un software guardando solo l’interfaccia. Il formato DXF, sviluppato da Autodesk ma diventato di fatto lo standard di interscambio per il disegno tecnico bidimensionale, e il formato IFC, standard ISO 16739 gestito dall’organizzazione indipendente buildingSMART per la modellazione BIM, non sono dettagli per soli informatici: sono la garanzia che i dati prodotti oggi restino utilizzabili domani, indipendentemente dal software che li ha generati.
Lo stesso valgono per i formati pdf, json, per le API Rest e tutti i formati liberi da licenze proprietarie. Un sistema che si appoggia in modo nativo a questi standard, invece di reinventare formati proprietari, offre al cliente una tranquillità che va oltre la funzionalità immediata: la certezza che l’investimento fatto in digitalizzazione non evapori a ogni cambio di fornitore.
Come sarà strutturato questo percorso?
Nei prossimi articoli affronterò, in ordine, i grandi capitoli che compongono un software di FM completo, sempre con un taglio che unisce la sostanza tecnica alla prospettiva di chi lo usa ogni giorno: la gestione dello spazio fisico attraverso CAD e BIM, con i relativi standard e le tecnologie di rendering; la piattaforma dati che deve adattarsi all’azienda e non viceversa; il ciclo di vita della manutenzione dalla pianificazione all’intervento sul campo; la gestione documentale; la sicurezza e la conformità normativa; fino ai temi più attuali come l’intelligenza artificiale applicata ai dati aziendali e l’osservabilità del sistema stesso.
Conclusioni
Un software di facility management nel 2026 non si giudica più dal numero di funzionalità elencate in una brochure, né dal fatto che “supporti il CAD” o “supporti il BIM” – ormai lo fanno quasi tutti, almeno sulla carta. Si giudica dalla profondità con cui trasforma quegli standard in dati realmente interrogabili e collegati, dalla velocità con cui risponde a un’esigenza nuova senza costringere il cliente a un nuovo sviluppo, e dalla capacità di restare aperto invece di trattenere il cliente attraverso formati chiusi. È un’evoluzione che ho visto maturare cliente dopo cliente, e che nei prossimi post proverò a raccontare in modo concreto e tecnicamente fondato, capitolo per capitolo.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui