Blog / Scelta del gestionale cloud

SLA del gestionale cloud: RTO, RPO ed exit strategy

Pubblicato l'8 settembre 2026 · Redazione Gestionale sul Web

Quando un gestionale diventa il punto di passaggio per ordini, fatture, scadenze, magazzino e assistenza, un'interruzione non è un semplice problema tecnico: può fermare attività che generano ricavi o rispettano impegni verso clienti e fornitori. Per questo la domanda “il servizio è affidabile?” va trasformata in requisiti che possano essere letti, testati e confrontati.

Che cosa deve dire davvero lo SLA di un gestionale cloud

SLA significa Service Level Agreement: è l'accordo che definisce livelli di servizio attesi, metodo di misura e responsabilità. Una brochure può dichiarare “alta disponibilità”; uno SLA utile precisa invece quale componente viene misurata, in quale periodo, con quale fonte e quali eventi sono esclusi. Deve inoltre chiarire cosa accade se il livello non viene rispettato.

È importante distinguere tre piani. Il requisito aziendale descrive ciò che il processo può tollerare; l'obiettivo operativo, spesso chiamato SLO, è il target usato per progettare e gestire il servizio; lo SLA contrattuale formalizza l'impegno verso il cliente. I tre valori non sono necessariamente identici. Un credito sul canone, per esempio, è un rimedio economico, ma non compensa ordini non evasi o una chiusura contabile rinviata.

Prima di confrontare fornitori, chiedi una versione completa delle condizioni del servizio e verifica perimetro, dipendenze e modalità di rendicontazione. Le funzioni applicative restano decisive, ma per un gestionale in cloud vanno esaminate insieme alla continuità che il processo richiede.

Partire dai processi, non dalle percentuali

Lo stesso fermo ha effetti diversi. Dieci minuti possono essere irrilevanti per un report mensile e critici per il banco vendita. La prima attività consiste quindi nel mappare i processi essenziali, il periodo in cui sono più sensibili e una procedura alternativa temporanea. Non serve assegnare a tutto la priorità massima: requisiti irrealistici aumentano costo e complessità senza migliorare le decisioni.

Questa mappa consente di classificare criticità e dipendenze. Se il gestionale scambia dati con e-commerce, banche, corrieri o sistemi di produzione, occorre capire se la misura copre soltanto l'interfaccia web o anche code, elaborazioni e API del gestionale.

Disponibilità, RTO e RPO: tre misure diverse

Disponibilità

La disponibilità indica la quota di tempo in cui il servizio risulta utilizzabile nel periodo osservato. Una percentuale non è confrontabile finché non sono noti almeno: orario coperto, calendario, manutenzioni pianificate, durata minima conteggiata, componenti incluse e fonte della misura. Anche il punto di osservazione conta: una piattaforma può rispondere tecnicamente ma non permettere di completare una funzione essenziale.

Per dare ordine di grandezza, in un mese convenzionale di 30 giorni il 99,9% corrisponde a circa 43 minuti e 12 secondi di indisponibilità, mentre il 99,5% corrisponde a circa 3 ore e 36 minuti. Non sono promesse universali: il calcolo reale dipende dalle regole contrattuali. Chiedi anche se i fermi brevi vengono sommati e come si trattano degrado delle prestazioni e manutenzioni.

RTO: entro quando deve ripartire il servizio

L'RTO non dice automaticamente che tutte le funzioni e integrazioni saranno operative nello stesso momento. Va chiarito da quale evento parte il conteggio, quando termina e quali verifiche sono incluse. Un accesso ristabilito senza giacenze aggiornate o senza invio dei documenti potrebbe non soddisfare il processo aziendale.

RPO: a quale istante devono tornare i dati

Se l'RPO è quattro ore, in uno scenario coerente il ripristino potrebbe non includere le modifiche più recenti fino a quella finestra. Per un catalogo aggiornato raramente può essere accettabile; per movimenti di magazzino o documenti emessi può creare un lavoro di ricostruzione importante. La guida NIST sulla pianificazione della continuità distingue chiaramente RTO e RPO: uno riguarda il tempo di ripresa, l'altro il punto di recupero dei dati.

Assistenza, incidenti, backup e prestazioni

“Risposta entro un'ora” non significa “problema risolto entro un'ora”. Lo SLA dovrebbe distinguere presa in carico, aggiornamenti, mitigazione e risoluzione, con priorità definite attraverso impatti osservabili. Un blocco generale, un errore su una funzione importante e una richiesta informativa non possono seguire lo stesso percorso.

Verifica canali e orari dell'assistenza, reperibilità per le urgenze, escalation, frequenza delle comunicazioni e report conclusivo. L'azienda deve sapere chi può aprire un incidente critico e quali informazioni fornire. Anche il fornitore ha bisogno di contatti aggiornati e di una classificazione condivisa.

Per backup e disaster recovery chiedi frequenza delle copie, separazione degli ambienti, conservazione, cifratura, responsabilità e soprattutto prove di ripristino. Il backup è una copia; il disaster recovery è l'insieme coordinato di persone, procedure e tecnologie che riporta il servizio entro obiettivi definiti. ENISA suggerisce di monitorare nei contratti cloud disponibilità, risposta agli incidenti, ciclo di vita dei dati, vulnerabilità, cambiamenti e log: segnali più concreti di una formula generica.

Infine, aggiungi misure di prestazione vicine all'uso reale: tempo di caricamento nelle ore di punta, durata delle elaborazioni, ritardo delle sincronizzazioni e comportamento al crescere di utenti e volumi. Un servizio formalmente “disponibile” ma troppo lento per chiudere un ordine può essere operativamente inutilizzabile.

Portabilità dei dati ed exit strategy

La continuità non riguarda solo i guasti. Può servire cambiare fornitore, riportare un processo all'interno, fondere due aziende o interrompere un modulo. L'exit strategy stabilisce come mantenere accessibili dati e documenti durante la transizione, quali attività spettano alle parti e quando le copie residue verranno eliminate.

Dal 12 settembre 2025 si applica il Data Act europeo, che contiene regole sul passaggio tra servizi di trattamento dati. Tra gli elementi previsti rientrano informazioni su procedure, metodi, formati, limitazioni tecniche e strutture dei dati esportabili. L'applicabilità concreta e le eventuali eccezioni dipendono dal servizio e dal contratto: questa guida non sostituisce una valutazione legale.

Per un software gestionale, “esportabile” deve essere verificato con precisione. Non basta ottenere un foglio con clienti e prodotti se mancano relazioni, stati, allegati, registrazioni, unità di misura, storico, tracciati e dizionario dei campi. Chiedi quali dati sono disponibili tramite export e quali tramite API, in quali formati documentati, con quali costi e tempi. Esegui un campione prima della firma e ripetilo periodicamente.

L'uscita dovrebbe includere un periodo di transizione, assistenza al trasferimento, accesso in sola lettura quando opportuno, criterio di accettazione dell'export e attestazione della cancellazione finale. Pianificare questa possibilità non significa aspettarsi un fallimento: significa ridurre il rischio di dipendenza e rendere più governabile qualunque cambiamento futuro.

Dodici domande da fare prima di firmare

1. Perimetro: quali applicazioni, API, elaborazioni e integrazioni sono incluse nello SLA?
2. Calcolo: come viene misurata la disponibilità e quali eventi sono esclusi?
3. Manutenzione: con quanto preavviso viene comunicata e quali finestre usa?
4. Criticità: come si classificano gli incidenti e chi assegna la priorità?
5. Tempi: quali sono presa in carico, aggiornamento, mitigazione e ripristino?
6. RTO: da quale evento parte il conteggio e quando il servizio è considerato recuperato?
7. RPO: quanta perdita temporale di dati è prevista nei diversi scenari?
8. Prove: con quale frequenza vengono testati backup e ripristino e quali evidenze sono disponibili?
9. Prestazioni: quali soglie valgono per pagine, elaborazioni, code e sincronizzazioni?
10. Comunicazioni: come riceveremo stato, avanzamenti e analisi della causa?
11. Portabilità: quali dati, allegati, metadati, log e configurazioni possono essere esportati?
12. Uscita: quali sono tempi, costi, supporto, accesso transitorio e cancellazione finale?

Inserisci le risposte in una matrice comune a tutti i candidati. Aggiungi responsabile della verifica, evidenza richiesta e risultato della prova. In questo modo lo SLA diventa parte della selezione del software gestionale, non un allegato letto soltanto dopo un problema.

Come provare le promesse durante demo e progetto pilota

Una demo dovrebbe includere almeno un caso di indisponibilità simulata o degrado controllato. Non occorre spegnere un sistema reale: si può descrivere uno scenario e verificare ruoli, canali, dati necessari e procedura alternativa. Per esempio, cosa fa il magazzino se il gestionale non è raggiungibile per 45 minuti? Chi registra le spedizioni? Come vengono riallineati i movimenti senza duplicati?

Per la portabilità, seleziona un campione piccolo ma completo: un cliente con più sedi, un articolo con unità e listini, un ordine con righe, allegati e stato, un documento collegato e la relativa registrazione. Esporta, apri e riconcilia il campione. Conta record e relazioni, verifica codifica, date e importi e conserva il risultato come base per i controlli successivi.

Per il ripristino, chiedi evidenza dell'ultima prova e chiarisci se il test ha verificato solo l'infrastruttura o anche l'applicazione. Definisci poi un riesame periodico: processi, volumi e integrazioni cambiano. Anche il requisito va aggiornato quando una funzione prima secondaria diventa essenziale.

Che cosa cambia quando il gestionale usa funzioni AI

Le funzioni di intelligenza artificiale introducono dipendenze ulteriori: modello, indice documentale, fonte dei dati, limiti di utilizzo e servizi esterni. Il gestionale può essere disponibile mentre l'assistente non risponde, oppure può produrre una risposta senza una fonte aggiornata. Conviene quindi separare lo SLA della piattaforma da quello della funzione AI.

Definisci almeno disponibilità del servizio, aggiornamento delle fonti, tracciabilità, comportamento quando un componente manca e percorso manuale alternativo. Per attività ad alto impatto, una risposta senza riferimento o con dati oltre la soglia di aggiornamento dovrebbe essere segnalata o bloccata. La guida sui dati gestionali pronti per l'AI approfondisce fonti autorevoli, permessi, verifica umana e metriche di qualità.

Questa distinzione aiuta anche a comunicare in modo più preciso: “il sistema è online” non equivale a “la risposta è corretta”. Disponibilità, qualità del dato e affidabilità del risultato richiedono indicatori diversi.

Domande frequenti

Che cosa indica lo SLA di un gestionale cloud?

Definisce livelli di servizio misurabili, modalità di calcolo, responsabilità e rimedi. Per un gestionale dovrebbe coprire almeno disponibilità, assistenza, incidenti, recupero e gestione dei dati.

Qual è la differenza tra RTO e RPO?

L'RTO indica entro quanto tempo il servizio deve tornare operativo. L'RPO indica a quale punto nel tempo devono poter essere recuperati i dati e quindi quanta perdita temporale è tollerabile.

Un uptime del 99,9% è sufficiente?

Dipende dal processo e dal metodo di calcolo. Servono periodo, esclusioni, componenti coperte e impatto aziendale; una percentuale isolata non basta.

Backup e disaster recovery sono la stessa cosa?

No. Il backup crea copie; il disaster recovery organizza il ripristino del servizio. Solo una prova completa dimostra che dati e funzioni possono tornare disponibili entro gli obiettivi.

Che cosa deve prevedere l'exit strategy?

Dati e componenti esportabili, formati, relazioni, allegati, tempi, costi, supporto alla transizione, accesso dopo la cessazione e cancellazione delle copie residue.

Vuoi valutare un gestionale cloud sul tuo processo reale?

Porta in demo una funzione critica, i volumi, le integrazioni e la tolleranza al fermo: il confronto sarà più utile di una lista generica di caratteristiche.

Esamina le funzioniRichiedi una demo

Fonti: Regolamento (UE) 2023/2854, Data Act; NIST, Recovery Time Objective; NIST, Recovery Point Objective; ENISA, monitoraggio dei livelli di sicurezza nei contratti cloud; Cloud Italia, SLA per i servizi cloud. Consultate l'8 settembre 2026.