Premesse
C’è un momento, in quasi tutti i progetti di digitalizzazione del facility management a cui ho partecipato, in cui emerge una domanda scomoda: “se un domani vogliamo cambiare fornitore, cosa ci portiamo via, tecnicamente?”. Spesso la risposta non piace a nessuno. Archivi ed Allegati di anni di contratto che ti vengono fornite in un inutile CD/DVD. File di disegno esportati in formati “finali” senza l’intelligenza del visualizzatore interno del Software. In alcuni casi anche impoverito nelle sue componenti CAD classiche: geometria appiattita e i blocchi persi, documenti caricati mese dopo mese di attività operativa non riscaricabili in blocco con la struttura originale, e tanti altri disagi del divorzio con un fornitore.
Il lock-in tecnologico non è mai una scelta digerita da chi acquista il software: è una conseguenza di decisioni tecniche fatte da chi lo progetta, spesso per comodità di sviluppo e nei casi peggiori per una strategia deliberata di trattenere il cliente. Ma l’effetto, per chi lo subisce, è lo stesso: un potere contrattuale che si erode anno dopo anno, fino a diventare insostenibile proprio quando servirebbe di più.
In quali punti tecnici del sistema si annida il lock-in in un software FM?
Il primo è la struttura delle sue tabelle. Quando sono stato chiamato da un importante operatore del mercato a valutare una soluzione che avevano adottato ho visto fino a che punto si può perseguire l’illegibilità del dato. Proteggere il know how? Neanche per sogno: incompetenza e sforzo di rendere impossibile lavorare con i dati applicativi al di fuori del proprio software.
Il secondo è il formato di integrazione dei disegni tecnici. Un file DXF può essere generato in modo “onesto”, con i blocchi salvati come entità BLOCK e riferimenti INSERT realmente riapribili e modificabili in qualunque software CAD standard, con gli attributi ATTRIB collegati e i livelli preservati; oppure può essere generato appiattendo tutto in geometria semplice – linee e polilinee senza più alcuna struttura logica – tecnicamente ancora un file DXF valido, ma di fatto inutilizzabile per chiunque debba poi lavorarci sopra. La differenza non si vede aprendo il file una volta, si vede quando si prova a modificarlo seriamente in un altro strumento.
Il terzo è la gestione documentale: se i documenti vivono solo nello storage proprietario del software, con una struttura di cartelle e metadati che esistono solo all’interno di quel sistema, ogni cambio di soluzione può diventare una migrazione dolorosa, spesso affidata a export a blocchi che possono perdere la relazione tra documento e record collegato.
Il quarto è l’integrazione con l’esterno: se l’unico modo per far dialogare il sistema con un ERP o un portale fornitori è passare attraverso sviluppi custom commissionati allo stesso fornitore del software, senza un livello di API pubblicato e documentato secondo uno standard come OpenAPI, il costo di ogni connessione resta sempre nelle mani del fornitore originale.
Cosa cambia, tecnicamente, con un’architettura aperta fin dal progetto?
Cambia tutto e in meglio! In primis la posizione negoziale del cliente, e questo si misura in scelte tecniche concrete e verificabili. Un sistema che esporta tutto in formato plain: dati alfanumerici e tabellari, documenti, disegni CAD in DXF nativo – verificabile aprendo il file esportato in un software CAD di terze parti e controllando che i blocchi restino editabili come tali – restituisce al cliente un patrimonio di planimetrie realmente portabile. Un sistema che si appoggia in modo intercambiabile a più provider di storage documentale (locale, o i principali servizi cloud), con le credenziali di accesso gestite lato server e mai esposte al client, permette di cambiare infrastruttura di archiviazione senza dover riscrivere l’intera gestione documentale. Un motore di API configurabile, che pubblica sottoinsiemi di dati con documentazione OpenAPI generata automaticamente, permette di collegare sistemi terzi senza che ogni integrazione richieda un progetto di sviluppo dedicato commissionato al fornitore originale.
Non è un dettaglio tecnico per soli informatici: è la differenza tra poter cambiare fornitore di manutenzione, di storage o persino di software gestionale senza dover ridisegnare da zero anni di manutenzioni, censimenti e planimetrie, e restare vincolati per inerzia perché il costo di uscita è diventato insostenibile.
Perché il formato IFC rende questo discorso ancora più rilevante sul fronte BIM?
Siamo ormai entrati nel vivo della stagione dell’integrazione BIM e anche qui l’uso di un formato come IFC, a differenza di molti formati proprietari di modellazione, garantisce in qualità di standard ISO (ISO 16739) piena interoperabilità.
buildingSMART International, è l’organizzazione indipendente che lo promuove anche come integrazione con i diversi fornitori di software commerciali. Un sistema che tratta l’IFC come formato di scambio nativo, senza convertirlo in un formato secondario e poi riesportarlo impoverito, garantisce che il modello BIM resti utilizzabile da qualunque strumento conforme allo standard, non solo da quello che lo ha originariamente importato. È lo stesso principio del DXF, applicato alla modellazione tridimensionale: lo standard aperto come garanzia di libertà futura, non come dettaglio tecnico ininfluente.
Come si riconosce, in fase di valutazione, un fornitore che non punta al lock-in?
Ponendo domande tecniche precise:
- I disegni esportati sono realmente apribili e modificabili in un software CAD standard di terze parti – provando davvero l’export, non fidandosi della dichiarazione commerciale – o solo visualizzabili?
- I documenti caricati possono essere migrati verso un altro spazio di archiviazione senza perdere struttura e storico, con un percorso di migrazione documentato e non solo teorico?
- Esiste una documentazione API pubblica, generata automaticamente e sempre sincronizzata con quanto realmente esposto, o l’integrazione richiede di “chiamare il supporto” ogni volta?
Le risposte a queste domande, più di qualunque elenco di funzionalità, rivelano la filosofia con cui un sistema è stato progettato.
L’impatto della libertà sulle figure coinvolte
Per il proprietario, il lock-in è un rischio finanziario di lungo periodo: un patrimonio informativo costruito in anni di censimenti e aggiornamenti che perde valore se resta prigioniero di un fornitore. Per il building manager, è un rischio operativo: si trova a dover gestire una transizione complessa proprio quando servirebbe continuità. Per il manutentore interno, il lock-in si traduce spesso in strumenti che non riesce a far evolvere con le proprie esigenze, restando dipendente da tempi e priorità altrui. Per la ditta esterna o il global service, invece, un sistema aperto è spesso un vantaggio competitivo: può dimostrare di saper lavorare su dati portabili, senza legare il cliente al proprio strumento proprietario, il che rafforza la fiducia nel rapporto contrattuale invece di alimentare il sospetto di una dipendenza forzata.
Qual è il ruolo del responsabile IT nel valutare questi rischi prima della firma di un contratto?
Il responsabile IT è, nella mia esperienza, la figura che dovrebbe porre queste domande per prima, prima ancora che il contratto venga firmato, perché è quella che dovrà gestire tecnicamente le conseguenze di una scelta sbagliata anni dopo. Verificare concretamente i requisiti di sicurezza e quelli infrastrutturali, fare un adeguato testing e analizzare la documentazione API prima di sottoscrivere un accordo, sono attività che richiedono qualche ora di lavoro tecnico ma che possono evitare anni di dipendenza da un fornitore che, con il tempo, potrebbe non essere più il migliore sul mercato.
Conclusioni
Il lock-in tecnologico è un costo che si paga in ritardo, spesso anni dopo l’acquisto iniziale, quando ormai la leva negoziale si è consumata. Un software di facility management pensato bene nel 2026 dovrebbe essere valutato anche per quanto è facile lasciarlo, non solo per quanto è comodo adottarlo, e questa valutazione richiede di scendere nel dettaglio tecnico di formati, export e documentazione API, non fermarsi alla demo commerciale. Nel prossimo articolo approfondirò un principio strettamente collegato: perché la capacità di adattarsi a nuove esigenze senza sviluppo software dedicato non è un lusso, ma una condizione architetturale necessaria per restare liberi nel tempo.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui