Premesse
Raramente un sistema di facility management smette di funzionare all’improvviso. Il fallimento, nella mia esperienza, è quasi sempre lento e silenzioso: si manifesta come uno scostamento progressivo tra ciò che il software dice e ciò che accade davvero negli edifici. L’anagrafica asset non aggiornata da mesi, la planimetria che non corrisponde più alla disposizione reale dei locali o che non traccia neppure l’ultima ristrutturazione, la manutenzione registrata e non analizzata e tanti piccoli segnali di abbandono che vanificano investimenti di decine o centinaia di migliaia di euro.
Il sintomo comune è sempre lo stesso, e ha una spiegazione tecnica precisa: costo di aggiornamento dei dati. Se l’evolvere quotidiano del patrimonio non consolida in forma facile le variazioni il valore del Sistema è destinato a crollare. Se sullo stesso oggetto fisico appartengono informazioni sparse in tabelle diverse, in allegati “morti”, spesso con chiavi identificative diverse o associazioni fragili e gestiti da persone diverse, senza che nessuno abbia la responsabilità tecnica di tenerli allineati. Non è un problema di disciplina del personale: è l’assenza di un modello relazionale unico.
Cosa significa davvero “affidabilità dei dati” ?
Significa che l’edificio, il piano, il locale e i componenti registrati sul Sistema Informativo corrispondono allo stato di fatto con uno scarto accettabile (differenze trascurabili nei parametri quantitativi e qualitativi). A tutti i livelli, la rappresentazione digitale deve riportare informazioni veritiere ed utili alla gestione. Nel disegno CAD il locale è un poligono di forma e misure allineate allo stato di fatto e con dati d’uso e tecnici corrispondenti all’effettivo; la caldaia disegnata ha marca e modello dell’effettiva macchina, non di quella sostituita o rimossa due anni prima . Stesso discorso per le manutenzioni.
Quando un tecnico deve intervenire, non deve ricordare mentalmente interventi che sono avvenuti mesi prima ma mai trasformati in aggiornamento dell’anagrafica. E neppure dover consultare tre basi documentali distinte che nessuno ha mai davvero collegato con un vincolo tecnico. È il motivo per cui, in molte organizzazioni, un semplice censimento di “quanti asset critici abbiamo in questo edificio” richiede purtroppo telefonate col personale sul campo e nel peggiore dei casi giorni di lavoro manuale invece di essere una singola query SQL con una join tra tabelle correttamente collegate.
Perché gli aggiornamenti una tantum non bastano, tecnicamente?
Perché non c’è alcun meccanismo che ne garantisca la durata nel tempo. Un riallineamento fatto dopo anni, magari con export ed import sporadici rende il sistema inattendibile. Senza meccanismi di aggiornamento puntuale strutturato ed obbligatorio a livello di database e di documentazione l’usabilità finisce per dipendere dalla buona sorte.
Un disegno tecnico, per essere davvero utile alla gestione, non dovrebbe essere un’immagine “del passato”: dovrebbe invece essere esso stesso una sorgente attendibile di informazioni aggiornate regolarmente nel database, ciascuna con un riferimento diretto agli eventi di ogni giorno (interventi a guasto e MP, ispezioni, ristrutturazioni, etc), Solo così, quando un locale cambia le sue informazioni insieme alla nuova destinazione d’uso sul campo o un asset viene spostato, l’aggiornamento avviene in un’unica sessione e si propaga automaticamente a ogni vista che la interroga.
Quale ruolo ha l’unificazione del modello dati?
È il punto di partenza di tutto il resto. Un edificio, un piano, un locale, un asset dovrebbero essere entità coerenti sia che l’utente stia guardando una planimetria, un modello 3D, una scheda di manutenzione o un semplice elenco tabellare. Quando questo principio non è rispettato fin dal progetto funzionale del Sistema Informativo, ogni funzionalità aggiunta successivamente (un cruscotto, un report, un’integrazione) eredita la stessa frammentazione di base, perché interroga dati che non sono mai stati veramente uniti, solo “avvicinati”.
Ho visto organizzazioni investire cifre importanti in data lake e strumenti di reportistica sofisticati, costruiti sopra query che aggregano dati da fonti non allineate, per poi scoprire che i numeri mostrati erano inaffidabili. Nessuna dashboard, per quanto ben disegnata graficamente, può correggere un modello dati frammentato alla radice: può solo renderlo più visibile, o più facile da ignorare finché qualcuno non se ne accorge in un momento critico.
Che ricadute ha questo problema per il proprietario, il building manager e il manutentore ?
Il proprietario percepisce la frammentazione come un rischio economico: non sa con certezza quanto vale, in termini di superfici e asset, il proprio patrimonio, perché i numeri cambiano a seconda di quale sistema li genera. Il building manager la vive come un logorio quotidiano: ogni richiesta della proprietà o di un ente di controllo richiede di incrociare a mano fonti diverse. Il manutentore interno o esterno, spesso, sviluppa una conoscenza tacita che compensa la frammentazione – “so io dove sono le cose” – ma è una compensazione fragile, che si perde ogni volta che quella persona o quel fornitore cambia o lascia, perché non è mai stata scritta in un database.
In particolare il fornitore esterno che subentra su un nuovo appalto non ha la conoscenza tacita accumulata da chi lavora in un edificio da anni: dipende interamente dalla qualità del dato che trova, e se quel dato è frammentato tra più sistemi mai davvero collegati, il periodo di affiancamento e apprendimento si allunga, con un costo che ricade sia sul fornitore sia, indirettamente, sul livello di servizio percepito dal cliente nei primi mesi di contratto. Un modello dati unificato riduce drasticamente questo tempo di adattamento, perché la conoscenza dell’edificio è scritta nel sistema e non nella testa di chi c’era prima.
Conclusioni
La prima domanda tecnica da porsi quando si valuta un software di facility management non è “che funzionalità ha”, ma “che strumenti ho per facilitare il mantenimento di coerenza nei dati dei miei edifici, dei miei spazi e i miei asset “? serve un processo che garantisca che ogni cambiamento vincoli ma soprattutto faciliti il ripristino dell’integrità dei dati. Nei prossimi articoli entrerò nel merito di come un sistema ben progettato affronta concretamente questo problema, a partire dal modo in cui tratta i disegni tecnici e i modelli tridimensionali come dati vivi, e non come semplici “istantanee” che invecchiano male.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui