Premesse
Il collaudo dei dati non è un passaggio “informatico”: è un atto di governo del servizio. Se dici “ok, si parte” con dati incompleti o incoerenti, nei primi mesi succedono sempre le stesse cose: ticket aperti sul nulla, piani manutentivi che non scadono quando devono, report SLA contestati, extra che esplodono, e scaricabarile tra cliente e fornitore. In ambito sanitario, PA, scuole/università e industria, dove la continuità operativa conta e i contratti sono misurati, il collaudo dei dati deve essere pratico, corto, verificabile e collegato a criteri di accettazione.
Che cosa sto collaudando esattamente quando parlo di “dati”?
Prima di iniziare, definisci cosa rientra nel collaudo: anagrafiche asset/impianti e spazi, classifiche e codifiche (priorità, categorie, cause/azioni), piani manutentivi e scadenze, storico interventi e ticket (se viene migrato), documenti tecnici collegati, regole SLA/KPI e report, utenti/ruoli e tracciabilità. Se non delimiti, il collaudo diventa infinito oppure si riduce a “import riuscito”, che non significa nulla per l’esercizio.
Qual è la soglia “minima accettabile” per partire senza bloccare il servizio?
Non esiste perfezione, ma esiste una soglia sotto la quale non si deve partire. Decidila prima e scrivila in modo misurabile, ad esempio: percentuale minima di asset critici censiti con ubicazione corretta, percentuale di spazi attivi codificati, percentuale di ticket con campi obbligatori valorizzati, percentuale di documenti indicizzati e collegati agli asset principali. La regola pratica è: accetta di rimandare “il lungo elenco” se la base per lavorare e misurare è solida; rifiuta la consegna se mancano chiavi, codici, ubicazioni, tempi e regole di calcolo.
Dove sono la “fonte ufficiale” e le chiavi univoche che impediranno i doppioni?
Prima di controllare i contenuti, controlla le chiavi. Ogni asset deve avere un identificativo unico, ogni spazio un codice univoco, ogni ticket un ID non riciclabile. Verifica anche che esista una regola per evitare duplicati e che i collegamenti siano consistenti (ticket → asset/spazio, documento → asset/spazio, piano → asset). Senza chiavi e collegamenti, qualsiasi sistema diventa una collezione di record scollegati e ogni report è un’opinione.
Quali campi devono essere obbligatori per rendere i dati “difendibili” a contratto?
Se lavori con SLA, penali, verifiche e contestazioni, devi imporre campi minimi che rendono il dato difendibile. Per i ticket: priorità, categoria, asset/spazio, apertura, presa in carico, ripristino/chiusura, stato, motivazione delle sospensioni, e consuntivo (anche minimo). Per gli interventi programmati: esito, data/ora esecuzione, operatore/impresa, evidenza (checklist/rapporto). Per gli extra: richiesta, approvazione, consuntivo, allegato. Collauda che questi campi siano davvero obbligatori nel sistema e non “saltabili” con scorciatoie.
Come verifico che le regole SLA/KPI siano configurate come da contratto?
Qui devi evitare la trappola dei report “belli ma indifendibili”. Pretendi una descrizione chiara delle regole: quando parte l’orologio, quando si ferma, quali stati sospendono, come gestisci le eccezioni (mancato accesso, attesa materiali, attesa autorizzazioni). Poi fai un test pratico: prendi un campione di ticket e ricalcola a mano (o con un foglio) il rispetto SLA. Se non riesci a replicare il numero, non è collaudato. Questo è coerente con contratti di servizio misurati: KPI non replicabili = KPI contestabili.
Come scelgo il campione giusto per il collaudo senza perdere settimane?
Non serve controllare tutto: serve un campione che “copra i rischi”. Scegli ticket e asset su: impianti critici (centrali, elettrico, UTA, gruppi frigo), aree sensibili (ospedale: reparti/servizi; campus: aule e servizi principali; industria: linee e utilities), e casi complessi (ticket sospesi, reperibilità, interventi multi-step, extra). Aggiungi casi “sporchi” (dati mancanti, duplicati, cambi priorità) perché è lì che il sistema deve reggere. Se il campione è solo casi semplici, il collaudo non vale.
Come verifico che le anagrafiche siano utilizzabili “sul campo” e non solo complete sul Sistema Informativo?
Qui la prova è pratica: un building manager deve riuscire a trovare un impianto, capire dove sta, vedere documenti utili, aprire un ticket collegato, e far partire un intervento senza cercare informazioni fuori dal sistema. Verifica ubicazioni, gerarchie (edificio–piano–locale o equivalente), coerenza delle denominazioni, e soprattutto la presenza di “asset critici” che il fornitore userà davvero. Un’anagrafica può essere completa al 95% ma inutile se manca il 5% che conta.
Come collaudo piani manutentivi e scadenze per evitare sorprese nei primi mesi?
Controlla che ogni piano abbia: oggetto (asset o gruppo), periodicità, regola di scadenza, attività previste, e modalità di consuntivazione. Poi fai un test temporale: simula o verifica cosa scade nei prossimi 30–60–90 giorni e confrontalo con ciò che ti aspetti in base alla realtà operativa. Il classico guaio post go-live è scoprire che scadono “tutte le attività insieme” o che non scade niente. Il collaudo serve a prevenire questo.
Come verifico documenti e allegati per non ritrovarmi un archivio morto di PDF?
Non guardare solo se “ci sono”: verifica se sono collegati e indicizzati. Ogni documento importante deve essere rintracciabile dall’asset/spazio e, quando serve, dal ticket/intervento. Chiedi un indice documentale (tabella) con tipo documento, data, versione, asset collegato, percorso file. Apri un campione e verifica qualità minima: leggibilità, versione corretta, documento giusto sul bene giusto. Se i documenti non sono collegati, per l’operatività valgono quasi zero.
Come collaudo ruoli, accessi e tracciabilità per evitare scaricabarile e rischi?
Prima del go-live verifica che i ruoli siano sensati: chi può aprire, chi può chiudere, chi può cambiare priorità, chi può approvare extra, chi può modificare anagrafiche. Verifica anche che gli account siano nominativi e che le azioni siano tracciate (audit trail) almeno sui punti critici: cambi di priorità, cambi di stato, modifiche ai consuntivi, approvazioni e cancellazioni. Questo non è “cyber da tecnici”: è requisito organizzativo per responsabilità e contestazioni.
Come gestisco le non conformità trovate nel collaudo senza bloccare tutto?
Definisci una regola semplice di triage: difetti bloccanti e non bloccanti. Bloccanti sono quelli che impediscono operatività o misurazione contrattuale: chiavi mancanti, tempi SLA non tracciabili, report non replicabili, ruoli sbagliati, duplicati gravi, piani che scadono male. Non bloccanti sono miglioramenti o completamenti che puoi pianificare dopo l’avvio, ma con una scadenza e un responsabile. L’errore tipico è accettare difetti bloccanti “tanto poi li sistemiamo”: non li sistemi mai senza leva.
Come formalizzo l’accettazione così non diventa una discussione infinita?
L’accettazione deve essere scritta come esito di test, non come sensazione. Prepara una lista di prove con risultato pass/fail e allega evidenze: export, screenshot, esempi di ticket, calcoli KPI, campioni di anagrafiche. Collega l’accettazione a una milestone contrattuale (avvio, saldo, trattenuta) e indica cosa succede se l’esito è “fail” su un punto bloccante. Questo approccio è coerente con la logica dei contratti di servizio: ciò che non è verificabile genera contenzioso.
Come faccio a dire “ok, si parte” senza prendermi un rischio eccessivo?
La formula pratica è: parti solo se sono veri tre punti. Primo, il sistema supporta i processi minimi senza scorciatoie (ticket, piani, approvazioni). Secondo, i dati minimi sono sufficienti per lavorare e misurare (chiavi, campi obbligatori, regole KPI). Terzo, hai un piano per chiudere le non conformità non bloccanti con tempi e responsabilità. Se uno di questi tre manca, stai firmando un rischio che poi si trasforma in mesi di caos operativo.
Conclusioni
Il collaudo dei dati serve a proteggere l’avvio del servizio e la tua capacità di governarlo. Se lo fai bene, è un’attività breve ma rigorosa: delimiti cosa collaudi, fissi soglie minime, controlli chiavi e campi obbligatori, verifichi regole SLA/KPI con calcoli replicabili, fai prove “da campo” su anagrafiche, piani e documenti, e formalizzi esiti e non conformità. A quel punto puoi dire “ok, si parte” sapendo cosa stai accettando e cosa no.
Se vuoi affrontare seriamente questo tema evitando i rischi sopra descritti puoi contattarmi qui.

Lascia un commento
Devi essere connesso per inviare un commento.