Introduzione del SaaS: piano di progetto, tappe fondamentali e responsabilità

Introdurre il SaaS non significa sviluppare software

SaaS sta per Software as a Service: l'applicazione gira nel cloud ed è fornita tramite Internet. L'accesso avviene tramite browser o app; non è necessaria alcuna installazione sul proprio computer o server. Il pagamento avviene solitamente in abbonamento, mensile o annuale; aggiornamenti, patch di sicurezza e backup sono a carico del fornitore. Esempi noti: Microsoft 365, Google Workspace, Slack, Salesforce e Zoom.

Per il progetto cambia il compito: non si tratta di un progetto di sviluppo con una propria roadmap di prodotto, bensì di un progetto di introduzione e integrazione. Ciò include configurazione, concetto di autorizzazioni, migrazione dei dati, interfacce, formazione e collaudo. Presso l'azienda utilizzatrice restano la responsabilità per i dati – integrità, conservazione e backup – nonché la gestione degli accessi, le autorizzazioni utente e il ripristino dopo un incidente.

La vasta diffusione non rende l'introduzione più semplice: secondo Statista, il 70 percento delle aziende con fino a 500 dipendenti e il 56 percento di tutte le aziende worldwide utilizzano applicazioni SaaS. Realistico è quindi un piano con decisioni, ruoli, finestre di test e criteri di accettazione. L'assunto che un prodotto standard copra ogni caso speciale non regge.

Un'ulteriore differenza rispetto all'installazione propria: il fornitore distribuisce automaticamente nuove versioni e funzionalità. Gli utenti lavorano così sempre con la versione attuale. Nel piano di progetto viene meno la pianificazione interna dei rilasci; restano necessari finestre temporali definite per i test dopo aggiornamenti maggiori del fornitore e una comunicazione chiara agli utenti.

Chiarire l'immagine obiettivo, i processi e i requisiti

Prima della decisione sul prodotto sta l'analisi della situazione di partenza: architettura di sistema esistente, processi aziendali e requisiti organizzativi vengono rilevati in modo olistico. Ne risulta una strategia cloud che considera aspetti tecnologici, economici e relativi alla sicurezza. Essa è ancorata strategicamente a livello aziendale e non guidata puramente dall'IT. Fornisce una roadmap per la modernizzazione IT, decisioni d'investimento trasparenti e un'architettura che cresce con l'azienda.

Da rilevare sono: mappa dei processi con le procedure interessate, dati associati e flussi di dati, interfacce esistenti, ruoli e livelli di autorizzazione, requisiti sulla sede di conservazione dei dati e lingue necessarie. Ne risulta un'immagine obiettivo con criteri verificabili: processi da coprire, numero di utenti, volume di dati, quadro di costi e scadenze.

L'immagine obiettivo è più di uno studio preliminare: serve in seguito come metro di valutazione per la scelta del fornitore e come criterio di accettazione dopo il rollout. La complessità ridotta e le dipendenze tecnologiche minimizzate si misurano dal numero di sistemi sostituiti e dalle interfacce rimanenti.

Scelta della soluzione: criteri con riferimento alla Svizzera

Un catalogo di criteri impedisce che le impressioni della demo decidano la scelta. Da verificare sono l'ampiezza funzionale rispetto ai requisiti di processo rilevati, la conservazione dei dati in Svizzera o nell'UE, il multilinguismo in DE/EN/FR nonché la fatturazione e le modalità di pagamento. La conservazione dei dati in Svizzera o nell'UE vale come requisito per la conformità alla LPD; DE/EN/FR è lo standard per il mercato svizzero. Conta altrettanto il supporto fornito dal fornitore durante l'introduzione.

Molti clienti B2B svizzeri preferiscono il pagamento tramite bonifico IBAN. Chiarite se il fornitore lo supporta e se le fatture vengono emesse in CHF con imposta sul valore aggiunto svizzera. In Svizzera sussiste l'obbligo IVA a partire da un fatturato annuo di CHF 100'000.

I criteri tecnici contano allo stesso modo. In un'architettura multi-tenant, diversi clienti utilizzano la stessa istanza software, ma i loro dati sono completamente separati. Funzioni tipiche di una soluzione SaaS sono la gestione utenti e diritti, la separazione sicura dei dati, gli accessi API, la gestione degli abbonamenti e le analisi. Conta anche la scalabilità: licenze aggiuntive si possono prenotare solitamente in pochi clic, mantenendo basso l'impegno in caso di crescita o cambi di personale.

Per il confronto strutturato si adatta una matrice di valutazione ponderata: le stesse domande a tutti i fornitori, valutazione per criterio, somma solo successivamente. Un accesso di prova con propri dati di esempio mostra se i processi centrali vengono effettivamente rappresentati. Da chiarire per iscritto sono i tempi di supporto e reazione, la comunicazione sui rilasci, l'esportazione dei dati in caso di uscita, i termini di disdetta e le regole di prezzo in caso di aumento del numero di utenti. Una classifica non sostituisce questa verifica – riassume solo quanto valutato precedentemente con criteri propri.

Criteri per fornitori SaaS con riferimento alla Svizzera

Il piano di progetto: fasi dalla concezione al rollout

Uno svolgimento collaudato passa attraverso cinque fasi: concetto e perimetro, decisioni su architettura e integrazione, pilota con gruppo di utenti limitato, rollout esteso e successiva scalatura. Un approccio simile conosce lo sviluppo SaaS: strategia di prodotto, design dell'architettura, validazione MVP con utenti reali, scalatura. Ogni fase termina con risultati definiti, che devono essere presenti prima che inizi la successiva.

Fase 1 – Concetto e perimetro: i risultati sono l'analisi dei processi, la lista dei requisiti, il concetto grezzo, il quadro quantitativo (utenti, dati, interfacce) e la stima dei costi. Da decidere è quali moduli e aree funzionali introdurre in quale ordine e quali gruppi di utenti sono i primi in fila. Senza questa decisione non sono possibili né bando di gara né confronto delle offerte.

Fase 2 – Architettura e integrazione: qui cadono le decisioni tecniche di principio – esercizio multi-tenant o single-tenant, concetto di isolamento dei dati, design API, sede di conservazione dei dati, modello di autorizzazioni e la lista delle interfacce verso i sistemi esistenti. Risultati: concetto tecnico, specifica delle interfacce, piano di migrazione e concetto di test.

Fase 3 – Pilota: un gruppo di utenti limitato lavora con le funzioni centrali e dati reali; errori, lacune e problemi di utilizzo vengono registrati e prioritizzati. Risultati: casi di test superati, lista errori pulita, materiali di formazione, dati di test migrati. Solo se i processi centrali funzionano nel pilota, il rollout ha senso.

Fase 4 – Rollout: migrazione dei dati, formazione, supporto e comunicazione seguono un calendario per gruppo di utenti. Risultati: avvio produttivo con numero di utenti definito, formazioni completate, canale di supporto funzionante.

Fase 5 – Scalatura: estensione ad altre aree, moduli aggiuntivi, automazione e ottimizzazione delle prestazioni. L'introduzione non termina con la prima versione live; lo sviluppo del prodotto continua presso il fornitore, l'azienda pianifica conseguentemente esercizio ed estensione.

Definire le tappe fondamentali e renderle misurabili

Una tappa fondamentale vale come strumento di controllo solo se contiene quattro elementi: un risultato verificabile, un criterio, entro quando deve essere presente e un ruolo responsabile. Esempi: analisi dei processi completata, scelta del fornitore approvata dal committente, fase di test superata con utenti reali, avvio produttivo, obiettivi di utilizzo raggiunti dopo un periodo di osservazione definito.

Affinché le tappe fondamentali valgano come criteri di interruzione, ogni criterio deve essere formulato in modo da poter fallire. Il pilota si considera superato se i processi centrali concordati vengono eseguiti con dati reali e se è dimostrato il ripristino dei dati – non se «l'umore è buono». Se un criterio non viene raggiunto, le conseguenze vanno stabilite preventivamente: rinegoziazione, formazione aggiuntiva, nuovo ciclo di test o interruzione del progetto.

La dimensione temporale dipende fortemente dal perimetro. Chi introduce solo un'area centrale necessita di meno passi di migrazione, interfacce e formazioni rispetto a un'ampiezza funzionale completa con più moduli. Le date fisse vanno quindi legate ad eventi – approvazione budget, scadenza di un vecchio contratto, fine di una fase pilota – e non a desideri di calendario che azzerano l'impegno di test.

Chi fa cosa: responsabilità condivisa invece di tutto al fornitore

Base è il modello della responsabilità condivisa: la sicurezza dell'infrastruttura spetta al fornitore SaaS, la sicurezza dei dati in gran parte all'azienda utilizzatrice. Molte aziende assumono erroneamente che il fornitore protegga anche i loro dati. In realtà restano integrità, conservazione e backup dei dati presso il cliente – insieme alla gestione degli accessi, alle autorizzazioni utente e al ripristino dei dati.

Dal lato del fornitore stanno la fornitura da data center sicuri, l'esercizio, gli aggiornamenti, la manutenzione, le patch di sicurezza e i backup dell'infrastruttura. Dal lato dell'azienda stanno la responsabilità dei dati, il concetto di autorizzazioni, il backup proprio dei dati SaaS, il piano di emergenza e la compliance.

Ne derivano ruoli di progetto concreti: il lato committente decide su budget e sblocco delle tappe fondamentali. Le divisioni specialistiche forniscono processi, casi di test, accettazioni e la comunicazione agli utenti. L'IT è responsabile dell'integrazione, delle interfacce, del concetto di autorizzazioni nonché dell'esportazione e backup dei dati. La direzione di progetto conduce piano, lista dei rischi, report di stato ed escalation; il lato fornitore fornisce onboarding, supporto e informazioni sui rilasci.

Il budget temporale di ogni ruolo va esplicitamente inserito nella pianificazione. I collaboratori delle divisioni specialistiche non sono disponibili per il business quotidiano durante test e formazione.

Vantaggi e rischi nell'introduzione del SaaS

Regolare dati, diritti di accesso e ripristino

Gli accessi sono controllati da controlli di accesso basati sui ruoli (RBAC) e impediscono che utenti non autorizzati accedano ai dati. A ciò si aggiunge la separazione tra clienti: in un'architettura multi-tenant ogni cliente vede solo i propri dati, tecnicamente assicurati ad esempio tramite Row-Level Security a livello di database. Criteri importanti per una soluzione di backup sono la gestione semplice e il controllo di accesso basato sui ruoli.

Rischi tipici, contro cui il piano di progetto deve prendere precauzioni: cancellazioni accidentali ed errore umano, insider malevoli, ransomware e attacchi informatici che prendono di mira sempre più le applicazioni SaaS, nonché errori di sincronizzazione con perdita o danneggiamento dei dati. Dalla responsabilità condivisa deriva una propria strategia di backup e recovery per i dati SaaS – invece di fidarsi dei backup del fornitore.

Da ancorare fermamente nel piano di progetto sono un concetto di autorizzazioni con ruoli definiti, un test di ripristino prima del go-live, regole chiare su chi può cancellare e ripristinare, la registrazione delle azioni critiche, termini di conservazione e cancellazione nonché un'esportazione ordinata in caso di uscita da un servizio. Senza questi punti resta aperto chi agisce in caso di emergenza.

Migrazione e integrazione nel panorama di sistemi esistente

Obiettivo della migrazione è trasferire applicazioni esistenti, dati e processi aziendali in modo sicuro, strutturato e senza disturbi operativi nel nuovo ambiente. Connessi a ciò sono la riduzione della complessità e la diminuzione delle dipendenze tecnologiche. Entrambi si misurano dal numero di sistemi sostituiti e dalle interfacce rimanenti.

In pratica la migrazione inizia con un inventario dei dati: quali set di dati servono, dove si trovano oggi, chi è il proprietario, quali campi devono essere assegnati come? Seguono poi la pulizia prima del trasferimento, l'esportazione dal vecchio sistema, l'importazione, la riconciliazione e un controllo documentato dei set di dati. Le interfacce vengono collegate tramite l'API della soluzione; da chiarire è se lo scambio avviene in continuo o a batch e cosa succede in caso di guasti.

Durante il cambio funziona un esercizio parallelo: vecchio sistema e nuova soluzione vengono gestiti contemporaneamente per un periodo definito. Da stabilire preventivamente sono durata, criteri per lo spegnimento, responsabilità per la riconciliazione dei dati e una via di ritorno in caso il cambio si blocchi. Dopo lo spegnimento del vecchio sistema appartengono alla lista di chiusura contratti, licenze, accessi e contratti di manutenzione – altrimenti restano costi e dipendenze.

Dopo il go-live: esercizio, costi e ulteriore sviluppo

Con l'avvio produttivo inizia l'esercizio. Il SaaS funziona secondo un modello in abbonamento con costi mensili o annuali; queste spese ricorrenti appartengono al budget per l'intera durata, non solo all'anno di introduzione. Utenti o licenze aggiuntivi si possono prenotare solitamente in pochi clic, facendo crescere i costi con il numero di utenti.

Per il controllo appartengono all'esercizio indicatori chiave: utenti attivi, utilizzo per processo e casi di supporto. Analisi e dashboard forniscono i dati a tal scopo. Nuove funzionalità vengono ampliate gradualmente e sulla base del feedback degli utenti. Lo sviluppo del prodotto non termina presso il fornitore con la prima versione live; di conseguenza anche presso il cliente si pianifica continuamente.

Costi e impegno temporale variano fortemente con il perimetro. logixc cita valori orientativi per lo sviluppo di un prodotto SaaS in Svizzera: CHF 20'000 fino a 40'000 e 6 fino a 10 settimane per un MVP. Per una v1.0 completa sono CHF 40'000 fino a 80'000 e 12 fino a 20 settimane. Varianti Enterprise con multi-tenancy, API e integrazioni costano CHF 80'000 e più nonché 6 mesi e oltre.

Queste cifre riguardano lo sviluppo del prodotto. Nell'introduzione di una soluzione acquistata cadono invece costi di abbonamento, integrazione, formazione ed esercizio. Decisivi per la loro entità sono perimetro, numero di interfacce e grandezza del gruppo di utenti.