Un gestionale aziendale può smettere di funzionare correttamente dopo l’aggiornamento di una libreria, una modifica al sistema operativo o un cambiamento nei servizi esterni con cui comunica. Quando il problema interrompe la fatturazione, blocca gli ordini o impedisce l’accesso ai dati, la prima questione riguarda l’assistenza: chi deve intervenire, entro quanto tempo e con quali responsabilità?
La risposta dovrebbe trovarsi nel contratto sottoscritto con il fornitore. Eppure, espressioni come «assistenza tecnica inclusa» o «aggiornamenti periodici» possono lasciare irrisolte questioni decisive. Non chiariscono necessariamente se il servizio comprende le correzioni di sicurezza, se è garantito il ripristino delle funzionalità o se un intervento urgente comporta costi aggiuntivi.
I contratti di manutenzione software servono a disciplinare proprio queste situazioni. La loro efficacia dipende dalla precisione con cui vengono definiti i servizi, dalla possibilità di verificarne l’esecuzione e dalla gestione delle responsabilità tra committente e fornitore. Anche la disponibilità del codice sorgente e le condizioni per cambiare società di assistenza possono incidere sulla continuità delle attività aziendali.
Manutenzione correttiva, aggiornamenti ed evoluzione del programma
Il primo elemento da chiarire riguarda l’oggetto del servizio. La manutenzione software comprende attività differenti, che richiedono competenze, tempi e impegni economici non necessariamente coincidenti.
La manutenzione correttiva interviene sui difetti riscontrati durante l’utilizzo del programma. Può riguardare un errore nei calcoli, una funzione che restituisce risultati sbagliati oppure un’anomalia che impedisce di completare un’operazione.
La manutenzione adattativa serve invece a mantenere il programma compatibile con l’ambiente tecnologico in cui opera. Rientrano in questa categoria, ad esempio, gli adeguamenti necessari dopo modifiche alle API di un servizio esterno, aggiornamenti del database o cambiamenti nelle caratteristiche dei sistemi supportati.
Esiste poi la manutenzione evolutiva, destinata a introdurre funzionalità, modificare procedure operative o ampliare quelle già disponibili. La realizzazione di un nuovo modulo per la gestione del magazzino, per esempio, rappresenta generalmente uno sviluppo aggiuntivo e non la semplice correzione di un malfunzionamento.
La distinzione ha conseguenze economiche immediate. Nei contratti di manutenzione software è opportuno stabilire quali interventi siano compresi nel canone e quali richiedano un preventivo separato. Il semplice riferimento agli aggiornamenti non permette di capire se siano incluse anche le modifiche necessarie per adeguarsi a nuove esigenze aziendali.
Un ulteriore elemento riguarda gli aggiornamenti normativi. Un software utilizzato per attività amministrative potrebbe richiedere modifiche in conseguenza di nuove disposizioni o specifiche tecniche. L’obbligo di effettuare tali adeguamenti non dovrebbe essere dato per scontato: occorre individuare le normative considerate, le versioni supportate e le modalità con cui vengono gestite le modifiche.
Anche il ciclo di vita del prodotto merita attenzione. Un’applicazione può continuare a funzionare pur utilizzando componenti che non ricevono più aggiornamenti dal produttore. In questi casi, mantenere il sistema operativo non equivale a garantirne la sicurezza nel tempo.
Gli SLA devono distinguere la presa in carico dalla soluzione del problema
Uno degli elementi centrali dei contratti di manutenzione software è lo SLA, acronimo di Service Level Agreement. Si tratta dell’accordo che definisce i livelli di servizio attesi e i criteri per misurarli.
Un’indicazione come «intervento entro quattro ore» può assumere significati molto diversi. Potrebbe riferirsi alla prima risposta del supporto, all’avvio dell’analisi tecnica, alla disponibilità di una soluzione temporanea oppure alla completa risoluzione del guasto.
Queste attività devono essere distinte.
Il tempo di risposta misura l’intervallo tra la segnalazione valida e la prima presa in carico secondo le modalità concordate. Il tempo di ripristino riguarda invece il ritorno del servizio a condizioni operative definite, anche attraverso una soluzione provvisoria. Il tempo di risoluzione si riferisce alla correzione del problema secondo i criteri stabiliti contrattualmente.
La differenza è rilevante. Un errore che impedisce l’accesso a un gestionale può essere aggirato temporaneamente attraverso una procedura alternativa, senza che il difetto originario sia stato eliminato.
Gli SLA dovrebbero inoltre collegare i tempi di intervento alla gravità dell’incidente.
Un malfunzionamento che blocca l’intera attività richiede normalmente una priorità differente rispetto a un errore grafico o a una funzione secondaria temporaneamente indisponibile. La classificazione può considerare il numero di utenti coinvolti, l’impatto sui processi aziendali, l’esistenza di soluzioni alternative e l’eventuale rischio per la sicurezza dei dati.
A titolo esemplificativo, un’organizzazione potrebbe concordare la presa in carico delle emergenze entro un’ora e tempi più ampi per le anomalie non bloccanti. Si tratta però di parametri negoziali, non di standard universalmente applicabili. La loro adeguatezza dipende dalla criticità del software, dall’orario di copertura e dalle risorse effettivamente disponibili.
Conta anche il momento da cui inizia il conteggio. Una segnalazione inviata alle 22 di venerdì potrebbe essere gestita immediatamente oppure alla riapertura del servizio, a seconda che sia prevista un’assistenza continuativa o limitata ai giorni lavorativi.
Un SLA misurabile deve indicare orari di copertura, canali autorizzati per le segnalazioni, criteri di priorità e modalità di registrazione degli interventi. Deve inoltre chiarire quali eventi sospendono legittimamente il conteggio dei tempi e come vengono gestite le controversie sulla classificazione di un guasto.
Nei sistemi particolarmente critici possono essere previsti indicatori di disponibilità, rapporti periodici sulle prestazioni e conseguenze contrattuali in caso di mancato rispetto dei livelli concordati. Eventuali penali o crediti di servizio richiedono una disciplina specifica e non sostituiscono automaticamente gli altri rimedi eventualmente applicabili.
La sicurezza informatica richiede obblighi verificabili
Il National Institute of Standards and Technology, nella pubblicazione SP 800-40 Rev. 4 dedicata alla gestione delle patch, considera gli aggiornamenti una componente della manutenzione preventiva. Il processo comprende identificazione, valutazione delle priorità, acquisizione, installazione e verifica delle correzioni.
È una distinzione operativa importante: distribuire una patch non significa necessariamente aver completato il lavoro.
Prima dell’installazione occorre valutare gli effetti sulle funzionalità esistenti. Dopo l’intervento bisogna verificare che la vulnerabilità sia stata corretta e che il sistema continui a funzionare correttamente. Nei programmi aziendali complessi può essere necessario utilizzare un ambiente di test separato dalla produzione.
I contratti di manutenzione software dovrebbero identificare il soggetto incaricato di monitorare le vulnerabilità, valutare gli aggiornamenti disponibili e decidere quando applicarli.
La priorità non dipende esclusivamente dal punteggio tecnico assegnato a una vulnerabilità. Occorre considerare anche la possibilità che venga sfruttata, l’esposizione del sistema, la disponibilità di misure compensative e le conseguenze di un eventuale attacco.
La presenza di una vulnerabilità critica in un componente esposto a Internet può richiedere una gestione urgente. Una correzione che riguarda un modulo non utilizzato, invece, potrebbe seguire una procedura differente, purché la valutazione sia documentata.
Le indicazioni di OWASP sulla sicurezza della catena di fornitura software richiamano l’attenzione sulle dipendenze esterne. Librerie, framework e altri componenti possono introdurre vulnerabilità anche quando il codice sviluppato direttamente dal fornitore non presenta errori conosciuti.
Diventa quindi utile conoscere le versioni utilizzate, le dipendenze presenti e le modalità con cui vengono monitorate. Nei progetti più strutturati può essere previsto anche un inventario dei componenti software, eventualmente organizzato attraverso una Software Bill of Materials.
Il contratto dovrebbe disciplinare inoltre gli accessi amministrativi, la gestione delle credenziali, la registrazione delle attività tecniche e le procedure da seguire in caso di incidente.
Se il fornitore può accedere a dati personali per conto dell’azienda, occorre valutare anche il suo ruolo ai sensi del Regolamento generale sulla protezione dei dati. Quando opera come responsabile del trattamento, l’articolo 28 del GDPR richiede un contratto o altro atto giuridico con contenuti specifici, comprese le misure di sicurezza, le condizioni per ricorrere ad altri responsabili e gli obblighi di assistenza al titolare.
Queste previsioni possono essere coordinate con il contratto di manutenzione, ma non coincidono necessariamente con lo SLA tecnico.
La gestione delle violazioni di dati personali richiede particolare attenzione. Il responsabile del trattamento deve informare il titolare senza ingiustificato ritardo dopo essere venuto a conoscenza di una violazione. Il termine di 72 ore previsto dal GDPR riguarda, nei casi applicabili, la notifica del titolare all’autorità di controllo e non rappresenta un tempo standard concesso al fornitore per comunicare l’incidente all’azienda.
Backup e continuità operativa: responsabilità da separare
Una delle ambiguità più frequenti riguarda la gestione dei backup.
Il fatto che un contratto preveda assistenza tecnica non implica automaticamente che il fornitore sia responsabile delle copie di sicurezza. Analogamente, un servizio di hosting può comprendere procedure di backup senza garantire che ogni applicazione venga ripristinata entro un determinato intervallo.
È opportuno identificare chi esegue le copie, dove vengono conservate, con quale frequenza e per quanto tempo restano disponibili.
La procedura dovrebbe comprendere anche verifiche periodiche di ripristino. Un archivio di backup esistente ma inutilizzabile non offre la protezione attesa.
Per i sistemi più importanti entrano in gioco due parametri: il Recovery Point Objective, che rappresenta la massima perdita temporale di dati tollerabile secondo gli obiettivi aziendali, e il Recovery Time Objective, che indica il tempo-obiettivo entro cui ripristinare il servizio dopo un’interruzione.
Questi parametri appartengono alla pianificazione della continuità operativa e del ripristino in caso di disastro. Possono influenzare gli SLA, ma non devono essere confusi con i normali tempi di risposta dell’assistenza.
Un contratto che garantisce la presa in carico di una richiesta entro due ore non assicura, per questo solo motivo, che un database danneggiato possa tornare operativo nello stesso intervallo.
Le responsabilità possono inoltre essere distribuite tra più soggetti: sviluppatore, amministratore dei sistemi, fornitore cloud e azienda committente. Senza una ripartizione documentata, ciascuno potrebbe ritenere che determinate attività spettino agli altri.
Proprietà del codice sorgente e diritti sulle modifiche
La disponibilità del codice sorgente assume un valore particolare quando un’impresa utilizza un programma sviluppato su misura.
L’accesso all’applicazione non comporta automaticamente la titolarità dei diritti di sfruttamento economico del software. Allo stesso modo, aver finanziato uno sviluppo non chiarisce da solo quali diritti siano stati trasferiti al committente.
La direttiva europea 2009/24/CE disciplina la protezione giuridica dei programmi per elaboratore, distinguendo i diritti esclusivi del titolare da determinate facoltà riconosciute a chi utilizza legittimamente il programma.
La disciplina applicabile e gli accordi sottoscritti devono essere considerati quando si stabilisce chi possa modificare, riprodurre, distribuire o affidare a terzi lo sviluppo del software, ferme restando le eccezioni previste dalla legge.
Nei contratti di manutenzione software è quindi necessario distinguere la proprietà del programma originario dai diritti sulle successive personalizzazioni.
Un fornitore può utilizzare componenti preesistenti di propria titolarità, librerie open source e moduli sviluppati appositamente per il cliente. Non tutte queste parti seguono necessariamente lo stesso regime giuridico.
La questione riguarda anche gli aggiornamenti realizzati durante il rapporto di manutenzione. Se viene sviluppata una nuova funzione a pagamento, occorre chiarire chi acquisisca i relativi diritti e a quali condizioni possa essere successivamente modificata.
Per i committenti privati, le soluzioni contrattuali possono essere differenti: cessione di determinati diritti, licenza d’uso, autorizzazione alle modifiche oppure accordi che mantengono la titolarità in capo allo sviluppatore.
Nel settore pubblico esiste una disciplina specifica. Le linee guida dell’Agenzia per l’Italia Digitale sull’acquisizione e il riuso del software, in attuazione del Codice dell’amministrazione digitale, trattano espressamente la titolarità del codice sviluppato su commissione delle amministrazioni e delle successive modifiche realizzate durante la manutenzione.
Queste disposizioni non possono essere trasferite indistintamente ai contratti tra imprese private.
Sul piano tecnico, la disponibilità del sorgente rappresenta comunque una condizione importante, ma non sempre sufficiente per consentire a un altro sviluppatore di intervenire.
Occorrono anche documentazione, struttura del database, informazioni sulle dipendenze, procedure di compilazione e distribuzione, configurazioni e indicazioni sulle integrazioni con servizi esterni.
Un archivio contenente esclusivamente i file del programma potrebbe non consentire la ricostruzione dell’ambiente necessario al suo funzionamento.
Responsabilità del fornitore e limiti degli interventi
La ripartizione delle responsabilità rappresenta uno degli aspetti più delicati della negoziazione.
Un malfunzionamento può dipendere da un difetto del programma, da un’infrastruttura non adeguata, da una configurazione modificata dal cliente oppure da un servizio esterno temporaneamente indisponibile.
Attribuire automaticamente ogni interruzione al manutentore, senza considerare le cause effettive, può produrre controversie. All’opposto, condizioni eccessivamente generiche che escludano qualsiasi responsabilità rischiano di rendere poco significativo l’impegno assunto.
Il contratto dovrebbe identificare gli ambienti e i componenti coperti dal servizio, le attività affidate al fornitore e gli obblighi di collaborazione del committente.
Può essere necessario stabilire chi autorizza gli aggiornamenti, chi esegue i test funzionali e chi approva il passaggio delle nuove versioni nell’ambiente di produzione.
Se un intervento richiede la sospensione temporanea del programma, è utile definire preventivamente le finestre di manutenzione e le modalità di comunicazione agli utenti interessati.
Anche la gestione delle modifiche richieste dal cliente deve essere regolata. Una funzione aggiuntiva può interferire con procedure esistenti e richiedere verifiche ulteriori rispetto al lavoro inizialmente preventivato.
Sul piano giuridico, le clausole relative a limitazioni di responsabilità, penali, risarcimenti e cause di esclusione richiedono una valutazione riferita al singolo rapporto.
Nel diritto italiano, ad esempio, l’articolo 1229 del Codice civile stabilisce limiti alla validità dei patti che escludono o limitano preventivamente la responsabilità per dolo o colpa grave. Non sarebbe quindi corretto considerare qualsiasi clausola di esonero automaticamente efficace per il solo fatto di essere stata accettata.
Il contenuto dell’accordo deve inoltre essere coordinato con le norme applicabili al rapporto contrattuale e con eventuali obblighi inderogabili.
Durata del contratto, rinnovo e revisione dei costi
Un canone di manutenzione può essere definito su base mensile o annuale, ma il suo valore economico dipende dalle prestazioni effettivamente comprese.
Due offerte apparentemente simili possono prevedere condizioni differenti in relazione alle ore di assistenza, agli interventi urgenti, al monitoraggio della sicurezza o al numero di versioni software supportate.
Per confrontarle è necessario distinguere il servizio continuativo dalle attività fatturate a consumo.
Anche le condizioni di rinnovo meritano attenzione. Un contratto pluriennale può prevedere adeguamenti del corrispettivo, revisioni del perimetro tecnico o modifiche delle condizioni di assistenza.
L’introduzione di nuove infrastrutture, l’aumento degli utenti e l’integrazione con altri sistemi possono cambiare sensibilmente il lavoro necessario per garantire il servizio.
Nei contratti di manutenzione software dovrebbe quindi essere prevista una procedura chiara per concordare le modifiche, evitando che prestazioni originariamente escluse vengano considerate automaticamente comprese oppure che attività già pattuite siano successivamente trattate come extra.
È utile disciplinare anche il preavviso per il mancato rinnovo e le eventuali conseguenze della cessazione anticipata.
La durata commerciale del rapporto deve infine essere distinta dalla vita utile del software. Il rinnovo del servizio di manutenzione non garantisce, da solo, che ogni tecnologia utilizzata continuerà a ricevere supporto dai rispettivi produttori.
L’exit plan evita che la fine del contratto blocchi l’azienda
La possibilità di cambiare fornitore dovrebbe essere considerata prima della sottoscrizione, quando le parti possono ancora definire condizioni tecniche ed economiche senza l’urgenza di un’interruzione del servizio.
L’exit plan, o piano di uscita, stabilisce come avverrà il passaggio a un nuovo soggetto incaricato della manutenzione o alla gestione interna.
Il primo elemento riguarda la restituzione dei materiali necessari alla prosecuzione delle attività.
A seconda del rapporto contrattuale e dei diritti disponibili, possono rientrare nella consegna il codice sorgente, la documentazione tecnica, gli schemi dei database, i file di configurazione, le procedure operative e gli strumenti utilizzati per distribuire gli aggiornamenti.
Occorre considerare anche le credenziali amministrative, gli account cloud, i certificati digitali e le licenze. Quando possibile, è opportuno che gli account strategici siano intestati direttamente al committente, mantenendo separati i permessi operativi concessi al manutentore.
La disponibilità dei dati è un altro elemento essenziale. Le modalità di esportazione dovrebbero essere definite in termini di formato, completezza, integrità e tempi di consegna.
Un’esportazione tecnicamente possibile ma realizzata in un formato difficilmente riutilizzabile può rendere il trasferimento complesso e costoso.
Quando il fornitore tratta dati personali come responsabile del trattamento, l’articolo 28 del GDPR prevede che, al termine del servizio, i dati siano cancellati o restituiti secondo la scelta del titolare, con cancellazione delle copie esistenti, salvo gli obblighi di conservazione previsti dalla legge.
Il piano di uscita deve essere coerente con queste prescrizioni e prevedere anche la revoca degli accessi non più necessari.
Resta poi la questione dell’affiancamento tecnico. Un nuovo manutentore può aver bisogno di chiarimenti sull’architettura del programma, sulle procedure di aggiornamento e sulle criticità conosciute.
Nei sistemi complessi, un periodo di transizione concordato può ridurre i rischi operativi. È preferibile definire in anticipo durata, attività comprese, modalità di collaborazione e relativo compenso.
L’exit plan è concretamente utilizzabile quando un soggetto autorizzato può prendere in carico il sistema senza dipendere da informazioni o strumenti rimasti esclusivamente nella disponibilità del precedente fornitore.
Questa condizione può essere verificata attraverso una consegna periodica della documentazione, un controllo degli accessi e, nei casi più critici, una prova tecnica di trasferibilità.
Il costo effettivo della manutenzione comprende anche questa possibilità: un canone apparentemente conveniente può perdere parte del proprio vantaggio se la sostituzione del fornitore richiede la ricostruzione del software, delle integrazioni o delle procedure operative.
La verifica periodica delle prestazioni rende il contratto controllabile
Una volta avviato il servizio, la qualità della manutenzione dovrebbe essere valutata attraverso dati documentati.
Il sistema di ticketing può registrare quando viene aperta una segnalazione, a quale livello di priorità viene assegnata, quando viene presa in carico e in quale momento il servizio torna operativo.
Queste informazioni permettono di verificare gli SLA e individuare problemi ricorrenti.
È utile distinguere le anomalie effettivamente risolte da quelle chiuse attraverso soluzioni temporanee. Un incidente ripetuto più volte può indicare la necessità di una correzione strutturale anziché di ulteriori interventi isolati.
La documentazione dovrebbe comprendere anche gli aggiornamenti installati, le eventuali patch rinviate, le motivazioni del rinvio e le verifiche effettuate dopo le modifiche.
Per i programmi utilizzati nei processi più delicati possono essere concordate revisioni periodiche del servizio, nelle quali committente e manutentore esaminano gli incidenti, gli interventi programmati e le condizioni tecnologiche che potrebbero richiedere investimenti aggiuntivi.
Un elemento particolarmente significativo riguarda i componenti prossimi alla fine del supporto ufficiale. Se una versione del database, del framework o del sistema operativo non riceverà più aggiornamenti di sicurezza, il cliente deve disporre delle informazioni necessarie per pianificarne la sostituzione.
Nei contratti di manutenzione software, la previsione di un inventario aggiornato delle componenti e delle rispettive scadenze di supporto consente di affrontare queste decisioni prima che diventino emergenze operative.
È proprio su queste informazioni che può essere costruito un piano di interventi verificabile: versioni effettivamente installate, criticità conosciute, aggiornamenti necessari, responsabilità assegnate e date concordate per le successive verifiche.
