Premesse
Nel Facility Management il Sistema Informativo è un componente chiave: è l’infrastruttura che tiene insieme anagrafiche, ticket, ordini di lavoro, contratti, consuntivi, documenti ed evidenze. Quando però la piattaforma diventa un vincolo, la Proprietà perde potere negoziale e capacità di cambiare modello operativo.
Allo stesso modo una grande Global Service rischia di dover “adattare” ogni contratto allo strumento disponibile, invece di far funzionare un metodo standard su clienti diversi. Evitare il vendor lock-in significa quindi proteggere continuità operativa, controllo del dato e libertà di evoluzione, senza sacrificare qualità del servizio o tempi di avvio.
Che cos’è il vendor lock-in nel FM e come si manifesta nella pratica contrattuale e operativa?
Il lock-in non è solo “non posso cambiare software”: è quando cambiare diventa troppo costoso o rischioso perché processi, dati e integrazioni sono stati modellati in modo non portabile e gli investimenti economici su una piattaforma sono costati talmente tanto che la sola idea di ripartire da 0 diventa un incubo inaccettabile.
Si manifesta anche quando l’anagrafica asset vive in un formato proprietario, quando i workflow chiave operativi sono costruiti solo dentro una piattaforma senza documentazione esterna, quando la reportistica dipende da logiche non replicabili o time consuming, o quando l’accesso ai dati storici richiede costi e tempi non compatibili con una gara o un passaggio di gestione.
Per la Proprietà, il sintomo tipico è che in fase di rinnovo o cambio fornitore non si riesce a “portare via” davvero il patrimonio informativo: si porta un export parziale e si ricomincia da capo. Per una Global Service, il lock-in si vede quando si comincia a usare più una piattaforma di altre, anche se ogni cliente preferirebbe uno strumento diverso e non si è liberi di muoversi nella naturale dinamica di concorrenza (e quindi di negoziazione economica) tra più produttori.
Se però si mettono in atto strategie contrattuali precise in occasione della stesura dell’accordo si può ancora mitigare il rischio di dipendere dai fornitori se nel tempo peggiorano il loro prodotto o i loro servizi.
Chi deve possedere i dati e come si scrive questa regola in modo verificabile?
Il primo antidoto è chiarire la proprietà e la disponibilità dei dati. La regola utile è: la Proprietà (o il committente del servizio) deve avere diritto a ottenere i propri dati in modo completo, leggibile e riutilizzabile, con una frequenza e un formato definiti. Per una Global Service, la regola speculare è: i dati operativi devono poter essere estratti e consolidati per gestire più contratti con un metodo unico, senza dipendere da un singolo produttore.
Questa regola va resa verificabile in capitolato o contratto: quali dataset sono inclusi (asset, ticket, work order, documenti/evidenze, contratti, SLA, consuntivi), quale livello di dettaglio è richiesto (campi, relazioni, storico), con quale periodicità, e con quale responsabilità di qualità. L’errore più comune è una clausola generica “export dati su richiesta”: quando serve davvero, ci si accorge che mancano legami, allegati, stati, o che l’export è un file non utilizzabile senza il sistema originale.
Qual è il “minimo modello dati” che va standardizzato per ridurre dipendenza dal fornitore?
Per ridurre lock-in non serve standardizzare tutto: serve standardizzare ciò che rende possibile migrare e confrontare. In FM il nucleo è composto da: anagrafica asset (codice, famiglia, localizzazione, criticità), mappa spazi (sito-edificio-piano-area-ambiente), ticket e ordini di lavoro (tipologia, priorità, tempi, esito, causa), contratti e SLA (coperture, finestre, livelli), consuntivi (ore, materiali, extra, costi), e documenti/evidenze collegati agli eventi.
La Proprietà dovrebbe pretendere che questo nucleo abbia definizioni stabili e che non venga “diluito” in campi liberi o tassonomie arbitrarie. La Global Service dovrebbe usarlo come base per un modello interno comune, capace di assorbire input diversi e produrre report comparabili tra clienti. Il punto non è imporre un unico software, ma imporre un linguaggio dati e un perimetro minimo che resti portabile.
Che cosa chiedere sulle integrazioni per evitare che diventino una gabbia?
Le integrazioni sono spesso il vero lock-in: badge/accessi, sensori, integrazione con BMS, energia, procurement, contabilità, documentale, sistemi HSE, app mobile, e talvolta sistemi di produzione. Se ogni integrazione è “su misura” e senza documentazione, cambiare piattaforma significa rifare tutto.
La richiesta corretta, per Proprietà e Global Service, è che le integrazioni siano progettate come interfacce stabili e documentate, con gestione chiara di: quali eventi scambiare, quali identificativi usare (asset ID, location ID), quali stati e codifiche condividere, e come gestire errori e riconciliazione. La criticità tipica è creare integrazioni puntuali solo per far “funzionare oggi” il processo, senza specifiche e senza test di portabilità; in fase di cambio, nessuno sa ricostruire il perché di certe logiche e tutto si blocca.
Come si progetta una strategia multi-soluzione (tipica delle Global Service) senza perdere governance?
Una Global Service raramente può imporre un’unica piattaforma ai propri clienti; deve quindi operare in un ecosistema di strumenti diversi. Evitare lock-in, per chi eroga il servizio, significa avere un “sistema di governo” indipendente dagli strumenti dei clienti: un livello di consolidamento che riceve i dati minimi, normalizza codifiche e produce KPI coerenti.
Questo richiede disciplina: procedure operative standard che non dipendano da una specifica schermata, formazione centrata su concetti (stati, priorità, definizione di chiusura, evidenze), e un set di KPI con definizioni univoche. Il rischio maggiore è accettare definizioni diverse cliente per cliente (“preso in carico” significa cose differenti, “chiuso” viene usato in modo diverso): così anche con i migliori sistemi, i dati non sono confrontabili e la governance diventa narrativa invece che misurabile.
Quali scelte di configurazione e personalizzazione aumentano il lock-in e quali lo riducono?
Il lock-in cresce quando si personalizza troppo dentro il prodotto: campi e workflow costruiti senza mappatura esterna, reportistica complessa non replicabile, automazioni non documentate, e soprattutto tassonomie uniche che nessuno fuori da quel sistema comprende. Cresce anche quando la documentazione operativa vive solo nel sistema (o solo nella testa di chi lo ha configurato) e non in procedure e specifiche di processo.
Lo riduce, invece, una personalizzazione “sobria” basata su: configurazioni documentate, tassonomie ridotte e stabili, utilizzo coerente degli stati, e separazione tra logiche di business e strumento. Per la Proprietà questo significa poter cambiare fornitore senza perdere il metodo; per la Global Service significa poter portare lo stesso metodo su più clienti con meno attrito.
Come si gestiscono migrazione ed exit plan senza scoprire i problemi quando è troppo tardi?
L’exit plan non è un documento da allegare alla gara: è un insieme di prove periodiche. La pratica migliore è prevedere esportazioni regolari e verificare che siano realmente riutilizzabili: che i legami tra ticket–asset–location ci siano, che gli allegati siano recuperabili, che le codifiche siano comprensibili, che lo storico non si perda. Per la Proprietà, questo riduce rischio in fase di cambio e rafforza il potere contrattuale; per la Global Service, riduce rischio di “collasso” quando un cliente cambia piattaforma o chiede un trasferimento rapido di dati.
L’errore tipico è scoprire a fine contratto che mancano pezzi fondamentali: evidenze, consuntivi dettagliati, motivazioni, tempi reali, o che i dati sono pieni di testi liberi e quindi non analizzabili. La soluzione è trattare la portabilità come un requisito operativo: piccoli test di uscita, ripetuti, costano poco e evitano crisi.
Conclusioni
Evitare il vendor lock-in nei sistemi informativi di FM significa proteggere soprattutto tre elementi: controllo sul dato, portabilità dei processi e indipendenza delle integrazioni. Per i proprietari è una questione di continuità e potere negoziale: poter cambiare fornitore o piattaforma senza perdere storico, evidenze e capacità di controllo. Per le grandi Global Service è una questione di efficienza e scalabilità: gestire più contratti con un metodo comune, anche quando gli strumenti applicativi cambiano.
La priorità operativa da attivare subito è definire un nucleo minimo di dati e indicatori con regole univoche e pretendere esportazioni verificabili, non solo promesse contrattuali. Il criterio per capire se stai riducendo davvero il lock-in è concreto: se, a parità di servizio, puoi sostituire una componente (fornitore, piattaforma, integrazione) senza dover riscrivere l’intero modello operativo e senza perdere tracciabilità su asset, interventi, costi ed evidenze. In altre parole: libertà di scelta senza perdita di controllo.