Chi deve aggiornare i dati e con quali responsabilità, lato cliente?

Premesse

Impostare “chi aggiorna i dati” non è burocrazia: è il modo più sicuro e veloce per evitare anagrafiche inattendibili, report non rappresentativi e discussioni infinite con il gestore dei servizi sul patrimonio, sia esso una grande Global service o un piccolo fornitore. Nei contratti di servizio (specie in sanità e PA) i dati diventano parte dell’evidenza su corrispettivi ma anche su SLA, penali, remunerazione degli extra e conformità: se non decidi ruoli e responsabilità lato cliente, il sistema informativo diventa un contenitore dove nessuno si fida di nulla.

Quali dati stai parlando di aggiornare (e perché ti servono)?

Prima di assegnare responsabilità, separa i “blocchi” di dati, perché non tutti hanno lo stesso proprietario naturale. In pratica: anagrafiche di asset e impianti, anagrafiche di spazi/ubicazioni, piani di manutenzione e attività programmate, ticket e consuntivi, documenti (manuali, dichiarazioni, schede, verbali), dati contrattuali (SLA/KPI, canone/extra, perimetri), utenti e permessi. Se non fai questa distinzione, finisci con un’unica risposta generica (“ci pensa il fornitore”) che poi non regge quando cambia il tuo team interno o il perimetro del contratto per aggiunta o chiusura di un presidio, un reparto o interruzione del rapporto con un appaltatore.

Qual è la “fonte ufficiale” per ogni tipo di dato (e dove si corregge)?

Devi decidere dove nasce la verità e dove si corregge, altrimenti avrai duplicati e conflitti. Esempio tipico: l’elenco spazi sta in un file Excel del patrimonio, mentre il CAFM ha codifiche diverse e il fornitore lavora “come gli arriva”. La regola che funziona è: per ogni categoria di dato definisci un solo punto di aggiornamento “master”, e tutti gli altri sistemi ricevono/allineano. Questa è la base per contratti di servizio misurabili: se l’anagrafica è contendibile, anche i KPI lo diventano.

Chi è il “titolare” del dato lato cliente (non chi lo inserisce)?

Nel mondo reale, chi inserisce spesso non è chi decide. Lato cliente serve nominare un titolare del dato per ciascun blocco, cioè la persona/ruolo che decide regole, standard e approva modifiche. In un ospedale o in un ente con più sedi, tipicamente il titolare del dato su asset e impianti sta nell’area tecnica/patrimonio, mentre su spazi e destinazioni d’uso può coinvolgere chi governa l’uso (direzione sanitaria, logistica, ufficio spazi, a seconda dell’organizzazione). Il punto è uno: il titolare del dato deve poter dire “questo è lo standard” e “questa modifica è accettata”, altrimenti il fornitore compila ma nessuno garantisce.

Chi è il “custode operativo” del dato (chi lo mantiene vivo ogni settimana)?

Oltre al titolare, serve un ruolo operativo lato cliente che faccia succedere le cose: controlli a campione, gestione delle eccezioni, richieste di correzione al fornitore, verifica che le regole siano rispettate. Se non hai questa figura (anche part-time), il sistema degrada in 3–6 mesi. Nelle organizzazioni “terra terra” questo ruolo spesso coincide col building manager o con un referente tecnico di presidio: non deve fare il data scientist, deve solo avere autorità e metodo.

Quali modifiche può fare il fornitore e quali devono essere approvate dal cliente?

Qui si vince o si perde. La regola pratica è: il fornitore può aggiornare ciò che deriva dal suo lavoro (esiti intervento, misure, ricambi, foto, verbali, note), ma non dovrebbe poter cambiare “identità e perimetro” degli oggetti senza controllo cliente (codici asset, ubicazioni ufficiali, classificazioni principali, criteri KPI, perimetri contrattuali). Se gli lasci mano libera su campi strutturali, ti ritrovi con asset rinominati, spazi spostati “per comodità”, categorie manipolate per far rientrare SLA.

Quali campi devono essere obbligatori perché il dato sia difendibile a contratto?

Se vuoi evitare contenuti “di bandiera”, devi decidere pochi campi obbligatori ma seri, soprattutto su ticket e consuntivi. Per esempio: priorità/motivo priorità, ora di presa in carico, ora arrivo in sito (se applicabile), ora ripristino, causa, azione, allegato minimo (foto o rapporto), e soprattutto lo stato “in attesa” con motivo tracciato quando il tempo SLA si sospende. Sono regole coerenti con la logica dei contratti di servizio: senza questi campi, i report SLA diventano opinioni.

Come gestisci gli accessi e le responsabilità (anche per audit e contestazioni)?

Regola semplice: account nominativi, ruoli chiari, niente utenze condivise “ditta/ditta2”, e log consultabili su chi modifica cosa. Non è paranoia: è l’unico modo per ricostruire fatti in caso di contestazione, incidente o ispezione interna. Lato cliente devi anche definire chi può approvare extra, chi può chiudere ticket “per conferma cliente”, chi può cambiare priorità, e chi può intervenire sui parametri che impattano KPI.

Come metti per iscritto queste responsabilità nei documenti di servizio, senza romanzi?

Non serve un tomo: servono poche regole inserite dove contano davvero, cioè negli allegati operativi del contratto (processi, SLA/KPI, tracciabilità, gestione anagrafiche, flussi di approvazione) e nel manuale operativo della piattaforma. L’idea è che, se domani cambia il responsabile o cambia il fornitore, la “regia del dato” resta uguale. Questo è pienamente coerente con un approccio moderno di facility management basato su processi misurabili e su un sistema di gestione strutturato (famiglia ISO 41000), senza trasformare tutto in teoria.

Come fai i controlli minimi ogni mese per capire se il dato sta degradando?

La manutenzione del dato non si fa “a fine anno”. Serve un controllo mensile leggero: campione di ticket, campione di asset, campione di documenti, e verifica di 3 cose: completezza, coerenza, tracciabilità. Se trovi errori ripetuti, non correggi solo il record: correggi la regola o la formazione, e se serve le autorizzazioni. Questo è il punto più importante nei contratti di global service: il fornitore risponde anche del processo, non solo dell’intervento.

Cosa fai quando il fornitore dice “non si può” o “il sistema non lo permette”?

La risposta operativa è: “Ok, allora quale campo/registro/log mi garantisce la stessa evidenza?”. Se non esiste, non è un problema “del software”: è un buco di governance che va risolto prima di parlare di KPI o penali. In alternativa, definisci una misura di emergenza (un allegato obbligatorio, un verbale standard, una nota strutturata) ma con scadenza: l’eccezione non deve diventare la norma.

Come eviti di finire fuori strada con privacy e dati personali nei ticket?

Se nel ticketing transitano nomi, numeri di telefono, segnalazioni di personale o dati sensibili indiretti (molto comune in ospedale e università), devi minimizzare e controllare: campi liberi solo dove serve, regole su cosa non va scritto, e permessi per profili. Non serve fare il legale in ogni post, ma serve ricordare che la gestione del dato nel facility non è solo tecnica: è anche responsabilità organizzativa.

Conclusioni

Se vuoi che il sistema di Facility funzioni, la domanda “chi aggiorna i dati” va chiusa prima di cambiare piattaforma e prima di discutere KPI. La ricetta pratica è sempre la stessa: definisci tipi di dato, scegli una fonte ufficiale, nomina un titolare lato cliente, assegna un custode operativo, blocca le modifiche “pericolose” con approvazioni, rendi obbligatori pochi campi che danno evidenza contrattuale, e fai controlli mensili leggeri. Da lì in poi il software aiuta davvero; prima, qualunque software diventa solo un posto dove scaricare responsabilità.

Se vuoi affrontare seriamente questo tema evitando i rischi sopra descritti puoi contattarmi qui.