Quali requisiti funzionali devo mettere in gara per evitare guai dopo l’avvio?

Premessa

Come trattato nel post precedente (puoi rileggerlo qui), possedere il Sistema vuol dire possedere il centro di controllo delle attività e dare il ritmo e il livello informativo a tutte le attività che vengono svolte sul tuo patrimonio. Un momento cruciale a riguardo è quello della stesura dei documenti per un Appalto di Servizi. In tale occasione scrivere i requisiti IT “in gara” non serve a comprare tecnologia: serve a proteggere il servizio quando partirà l’appalto. Se i requisiti sono vaghi, succedono tre cose molto prevedibili: il fornitore porta strumenti suoi non governabili, i dati restano “suo patrimonio” e non tuo, e dopo l’avvio scopri che non puoi misurare bene SLA, contestare, cambiare fornitore o integrare con i sistemi che già usi. In sanità, PA e campus, dove il global service spesso lavora su più sedi e con impatti su continuità e sicurezza, questi problemi diventano guai veri.

Qual è lo scopo dei requisiti IT: cosa devo proteggere davvero?

Prima di scrivere una riga di capitolato, chiarisci cosa vuoi proteggere:

1. la continuità operativa (ticket, reperibilità, scadenze)?
2. la misurabilità contrattuale (SLA/KPI e penali)?
3. la proprietà e portabilità del dato (reversibilità a fine appalto)?
4. la tracciabilità delle azioni (audit)?
5. la governabilità degli accessi (anche per terze parti e subappaltatori)?

Se questi cinque punti non compaiono in modo concreto, il requisito IT diventa “il sistema deve essere moderno” e non ti tutela.

Qual è il perimetro minimo del “sistema” che il fornitore deve garantire?

Se non metti tu come Stazione Appaltante il Sistema di Governo allora devi dire chiaramente quali funzioni minime ti servono per governare un contratto di servizio: gestione richieste e guasti (ticket), pianificazione e consuntivazione attività programmate, anagrafiche (asset/spazi/impianti), gestione documenti tecnici collegati agli asset, report KPI/SLA, e gestione extra/fuori canone con approvazione. Non serve imporre una marca, ma serve imporre il perimetro: altrimenti ti ritrovi con un help desk “solo email” e fogli Excel come back-office.

Quali requisiti devo mettere ?

su proprietà del dato e “reversibilità” a fine appalto?

Questo è il requisito più importante e più trascurato. Devi scrivere che tutti i dati prodotti durante il servizio sono del Committente e devono essere consegnati in formati riusabili, con tempistiche e senza costi “a sorpresa”. Pretendi esplicitamente: export completo di ticket, anagrafiche, piani manutentivi, consuntivi, documenti indicizzati, e una mappa dei campi/codifiche. Pretendi anche che la consegna includa un indice documentale e una tabella di collegamento (documento ↔ asset ↔ intervento). Senza questi punti, la gara ti lega al fornitore e il cambio appalto diventa un trauma. Per i dettagli valgono tutti i suggerimenti che ho messo nel post precedente.

su formati e interoperabilità per non dipendere dal software del fornitore?

Metti requisiti su formati “aperti” e su export standard: CSV/XLSX per dati tabellari, PDF come copia leggibile ma non unica, e possibilità di esportare allegati e documenti con struttura e riferimenti (non zip senza senso). Se nel tuo contesto c’è BIM/CDE, chiedi almeno la possibilità di scambiare dataset e riferimenti oggetto-documento, senza imporre per forza un formato unico “religioso”. L’obiettivo non è fare teoria: è garantire che i dati possano vivere nel tuo sistema o in quello del successore.

sulla qualità minima dei dati (così i report non sono finti)?

Se non imponi regole minime sui campi obbligatori, avrai ticket chiusi senza tutti i tempi delle varie fasi (arrivo sul posto, messa in sicurezza, inizio intervento, chiusura, etc), senza cause (organizzate in categorie usabili per analisi statistiche), senza evidenze (foto o firme dei referenti di sito), e KPI inutilizzabili. Scrivi che per ticket e interventi devono essere obbligatori almeno: priorità, stato, timestamp principali (apertura, presa in carico, ripristino/chiusura), classificazione (tipo richiesta/guasto), asset o ubicazione, e motivazione delle sospensioni. Scrivi che le regole di calcolo SLA/KPI devono essere configurate e documentate (quando parte e quando si ferma l’orologio, quali stati sospendono). Queste sono richieste coerenti con un facility management misurato e con contratti a performance: non sono “capricci IT”.

sulla tracciabilità (audit trail) per reggere contestazioni e verifiche?

Pretendi che il sistema tracci chi ha fatto cosa e quando: cambi di priorità, cambi di stato, annullamenti, modifiche a consuntivi, allegati aggiunti o rimossi, approvazioni. Pretendi log consultabili dal Committente e conservazione per un periodo coerente con il contratto e con le esigenze di audit. In contesti pubblici e sanitari, la tracciabilità è anche un tema di responsabilità: se un dato cambia senza storia, non è governabile.

su ruoli e accessi, per gestire fornitore, subappalti e turnover?

Non serve entrare nei dettagli “da cyber specialist”, ma devi imporre regole organizzative: accessi nominativi (no account condivisi), profili/ruoli differenziati (chi può solo leggere, chi può chiudere ticket, chi può approvare extra, chi può modificare anagrafiche), e gestione del ciclo di vita utenze (attivazione/disattivazione rapida quando qualcuno entra/esce). Pretendi che gli accessi per terze parti siano governati e che tu possa avere visibilità sull’elenco utenti e sui permessi. Il turnover è normale nei global service: se non governi gli accessi, avrai sempre “porte aperte” che nessuno controlla.

sulla continuità operativa (cosa succede quando il sistema non va)?

Qui si evitano guai dopo l’avvio. Chiedi una modalità di lavoro degradata: se la piattaforma è down, come si aprono le chiamate, come si assegna, come si tracciano tempi e interventi, e come si riallineano i dati dopo. Chiedi anche requisiti minimi di disponibilità (SLA della piattaforma), supporto, tempi di ripristino, e un piano di comunicazione incidenti. In ospedale e campus, il fermo del ticketing non è “solo IT”: blocca la gestione del servizio e la misurazione contrattuale.

sulle integrazioni con i miei sistemi (senza chiedere “integra tutto”)?

Chiedi integrazioni realistiche e verificabili. Tipicamente: import/export anagrafiche asset/spazi, integrazione con directory utenti (se applicabile), esportazione dati per BI/reporting, e dove pertinente integrazioni con sistemi tecnici (es. BMS) ma con regole chiare su cosa genera un ticket e con quali dati minimi. Specifica che le integrazioni devono essere documentate, mantenibili e testate in collaudo. Evita richieste generiche tipo “integrazione con qualsiasi sistema”: non è controllabile in gara e diventa una fonte infinita di varianti.

sulla gestione documentale per non ritrovarmi archivi morti?

Pretendi che ogni documento tecnico sia collegabile ad asset/spazio e, quando serve, a intervento/ticket. Pretendi versioning minimo (data, revisione, autore/fornitore), e possibilità di esportare l’archivio con indice (CSV/XLSX) che mantenga i collegamenti. Questo è decisivo nel cambio appalto: senza indice e collegamenti, ti consegnano cartelle di PDF e il nuovo fornitore ricomincia da capo.

su collaudo e criteri di accettazione, per non litigare dopo?

Scrivi che la piattaforma e i flussi devono essere collaudati con casi reali prima dell’avvio (o entro una finestra breve), e definisci criteri di accettazione semplici: ticket con campi obbligatori, calcolo KPI replicabile, export funzionanti, ruoli corretti, audit trail consultabile, consegna documentale indicizzata. Se non metti criteri di accettazione, dopo l’avvio tutto diventa “interpretazione” e ogni correzione diventa extra.

per evitare il “lock-in” commerciale e tecnico?

Pretendi che come Committente tu possa ottenere dati senza costi proibitivi, che non ci siano formati proprietari non esportabili, e che la documentazione di configurazioni e codifiche sia consegnata. Chiedi esplicitamente che le codifiche principali (categorie ticket, priorità, cause/azioni, alberi impianto/asset) siano esportabili e consegnate. Il lock-in nel facility non è solo licenze: è dipendenza da configurazioni non documentate.

per rispettare il contesto normativo senza trasformare la gara in un trattato?

Nel facility management, l’idea chiave è che processi, ruoli, informazioni e misurazioni siano strutturati e ripetibili, non “a memoria”. Tradotto in capitolato funzionale per il Software: responsabilità chiare, tracciabilità, misure replicabili, gestione documentale collegata agli asset, e continuità del dato tra appalti. Nei contratti di servizio, soprattutto pubblici, questi punti sono anche tutela amministrativa: riducono discrezionalità e contenziosi. Scrivili in modo operativo, come requisiti verificabili, non come slogan.

Conclusioni

Se vuoi evitare guai dopo l’avvio, i requisiti IT in gara devono puntare su cinque cose: dati tuoi e portabili, processi misurabili, tracciabilità, accessi governati, e collaudo con criteri chiari. Non serve imporre una piattaforma: serve imporre regole che rendano il servizio controllabile oggi e trasferibile domani. È l’unico modo per fare facility “da ufficio tecnico”: concreto, verificabile, e difendibile quando arrivano verifiche, contestazioni o un cambio appalto.

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