Da cosa devo partire nel 2026 prima di cambiare software di Facility?

Premessa

Cambiare il software di Facility nel 2026 non è (quasi mai) un problema di “funzioni mancanti”. Avevo già dato un vademecum su come procedere alla scelta (lo trovi qui), ma se dopo un periodo decidi comunque di abbandonare una piattaforma è importante imparare la lezione e scegliere il nuovo a partire dalla soluzione dei problemi più gravi lasciati dal precedente.

La spinta al cambiamento, tranne casi gravi, è sempre un problema di aspettative tradite, di dati difficili da gestire e usare, condizioni di servizio non chiare e contratti che non proteggono abbastanza la parte acquirente. Se parti con interlocutori o piattaforme inadatte, puoi comprare anche la piattaforma funzionalmente migliore e ritrovarti comunque dopo poco tempo nuovamente con gli stessi problemi, solo più costosi per via del tempo e della migrazione necessaria tra il precedente e quello nuovo.

Questo articolo serve a chiarirti le idee e a mettere in fila cosa sistemare prima, lato Owner/Building Manager, per evitare un cambio software che diventa l’ennesimo progetto fallito.

Perché vuoi cambiare davvero?

La prima domanda non è “quale prodotto scelgo”, ma “qual è il problema che oggi mi costa tempo o soldi”. Vuoi ridurre tempi di presa in carico? Vuoi avere report credibili per SLA/penali? Vuoi smettere di perdere storico e documenti? Scegli 2–3 risultati misurabili e scrivili in modo semplice, tipo: “entro 90 giorni voglio vedere il 95% dei ticket con priorità corretta e orari tracciati” oppure “voglio un’anagrafica impianti con copertura almeno dell’80% sulle centrali critiche”. Se non sai cosa vuoi misurare, il software diventa un catalogo di feature.

Quali processi devi preservare assolutamente?

Molti cambi software falliscono perché non si proteggono adeguatamente i processi fondamentali. Quelli su cui gira il funzionamento stesso dell’azienda o del suo sistema di controllo operativo. Passare da un software ad un altro senza avere la certezza di preservare le procedure più importanti è l’anticamera dell’inferno operativo. Prima di toccare la piattaforma, serve chiarire e dichiarare come deve funzionare “come prima”: apertura ticket, classificazione (guasto/richiesta), priorità, escalation, chiusura, consuntivazione, allegati obbligatori, gestione preventivi, gestione fuori-canone. Senza questo, il sistema nuovo fallirà come o più del precedente.

Chi è il “proprietario” dei dati e chi li mantiene vivi nel tempo?

La domanda più scomoda: chi oggi lavora sul sistema attuale e aggiorna i dati è interno o esterno all’azienda? Se è interno, ha le competenze e capacità di fare altrettanto sul nuovo? Se la risposta è “ci penserà il fornitore”, allora devi decidere come lo controlli e come lo obblighi (con regole e verifiche, non con buone intenzioni) a garantire di avere ciò che ti serve nei tempi e con livelli qualitativi pari o superiori al precedente. Serve indicare almeno: chi approva le modifiche agli asset e agli spazi, chi può creare/chiudere ticket, chi può cambiare priorità, chi valida consuntivi e ricambi, chi gestisce i documenti. Senza questa parte, qualsiasi piattaforma diventa un posto dove ognuno scrive quello che vuole.

Che qualità hanno i tuoi dati oggi?

Prima di migrare, guarda in faccia la realtà: quanti asset sono duplicati, quanti senza codice, quanti senza ubicazione, quante categorie diverse per la stessa cosa, quante anagrafiche “storiche” non più esistenti. Non serve la perfezione, serve una soglia minima per lavorare. Se non fai una mini “radiografia” iniziale, scoprirai i problemi nel momento peggiore: durante la migrazione, quando i tempi sono stretti e tutti vogliono “andare live”.

Qual è l’anagrafica minima che ti serve per ripartire senza bloccare l’operatività?

In generale la tentazione è “mettiamo dentro tutto e subito”. Nel 2026, invece, conviene partire dal minimo che garantisce la continuità del servizio. Per esempio: se devo ricostruire le tavole CAD per dialogare con la nuova applicazione mi focalizzo sugli asset critici (centrali, gruppi frigo, UTA, elettrico), mentre gli spazi/aree funzionali (reparti, laboratori, aule, edifici) vanno necessariamente recuperate immediatamente, fornitori e contratti collegati, piani di manutenzione dove esistono, e soprattutto una codifica semplice e coerente. Il resto può entrare dopo, ma se parti con il “tutto subito” rischi di non partire mai.

Che integrazioni ti servono davvero (e quali sono solo “nice to have”)?

Nel tuo contesto, le integrazioni che contano sono poche ma pesanti: anagrafiche (HR/utenze), eventualmente contabilità/ordini, e soprattutto collegamenti con BMS/OT dove ha senso (allarmi che aprono ticket, informazioni di stato, correlazioni). Il rischio è chiedere “integriamo tutto con tutto” e poi scoprire che nessuno gestisce eccezioni, disallineamenti, duplicazioni. Meglio definire 1–2 flussi prioritari, con regole chiare e con un responsabile del dato su entrambi i lati.

Hai un piano di migrazione che non ti faccia perdere storico e continuità?

Il cambio software non deve azzerare la memoria: storico ticket, anagrafiche, documenti chiave, piani manutentivi, contratti, anagrafiche fornitori. Devi decidere cosa migrare davvero (non tutto è utile), ma devi anche garantire che ciò che ti serve per contestazioni e audit resti accessibile. E serve decidere fin dall’inizio dove sarà la “fonte ufficiale” dopo il go-live, altrimenti per mesi avrai due verità diverse.

Come farai il collaudo prima di dire “si parte”?

Il collaudo non è “il sistema si apre”. È: apriamo ticket reali, con casi reali; misuriamo tempi e stati; proviamo l’escalation; verifichiamo report; controlliamo che i campi obbligatori servano davvero; testiamo che un building manager riesca a lavorare senza scorciatoie. Se in collaudo usi dati finti e casi semplici, in esercizio ti esplode tutto addosso. Il collaudo deve essere corto, pratico, e con criteri di accettazione scritti in due pagine, non in cento.

Conclusioni

Nel 2026 “cambiare software” è l’ultimo pezzo, non il primo. Se prima metti a posto obiettivi misurabili, regole minime di processo, responsabilità sui dati, criteri di tracciabilità e una base di continuità operativa (soprattutto quando tocchi BMS/OT), allora la scelta della piattaforma diventa finalmente una scelta tecnica e non una scommessa. E soprattutto ti porti a casa un risultato vero: meno discussioni, meno buchi informativi, più controllo sul servizio. Se vuoi, nel prossimo passo posso trasformare queste domande in una checklist di 1 pagina “da riunione” da usare con IT, Building Manager e global service prima di qualsiasi demo commerciale.

Se vuoi affrontare seriamente questo tema evitando i rischi di tempo e denaro, puoi contattarmi qui.