Introdurre il 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 e viene fornita tramite Internet; l'accesso avviene tramite browser o app. Non è necessaria alcuna installazione sul proprio computer o server. Di solito si paga un abbonamento, mensile o annuale. Aggiornamenti, patch di sicurezza e backup sono a carico del fornitore. Esempi noti: Microsoft 365, Google Workspace, Slack, Salesforce o Zoom.

Questo cambia radicalmente il compito del progetto: non si tratta di un progetto di sviluppo con una propria roadmap di prodotto, bensì di un progetto di introduzione e integrazione con configurazione, concetto di autorizzazioni, migrazione dei dati, interfacce, formazione e collaudo. Presso l'azienda utilizzatrice rimangono la responsabilità dei dati – integrità, conservazione e backup – nonché la gestione degli accessi, le autorizzazioni degli utenti e il ripristino in caso di incidente.

L'ampia diffusione non rende l'introduzione più semplice: secondo Statista, il 70% delle aziende con fino a 500 dipendenti e il 56% di tutte le aziende a livello mondiale utilizza applicazioni SaaS. Realisticamente, è quindi necessario un piano con decisioni, ruoli, finestre di test e criteri di collaudo, e non l'assunto che un prodotto standard copra ogni caso particolare.

Un'ulteriore differenza rispetto a un'installazione propria: le nuove versioni e le funzionalità vengono distribuite automaticamente dal fornitore, e gli utenti lavorano così sempre con la versione più recente. Nel piano di progetto viene quindi meno la propria pianificazione dei rilasci; rimangono necessari finestre temporali definite per i test dopo i grandi aggiornamenti del fornitore e una comunicazione chiara agli utenti.

Definire l'obiettivo, i processi e i requisiti

Prima di decidere il prodotto, si analizza la situazione di partenza: l'architettura di sistema esistente, i processi aziendali e i requisiti organizzativi vengono rilevati in modo olistico. Da ciò scaturisce una strategia cloud che considera aspetti tecnologici, economici e legati alla sicurezza, che è ancorata strategicamente all'azienda e non è guidata puramente dall'IT. Fornisce una roadmap per la modernizzazione dell'IT, decisioni di investimento trasparenti e un'architettura che cresce con l'azienda.

Da rilevare: mappa dei processi con i flussi interessati, dati e flussi di dati associati, interfacce esistenti, ruoli e livelli di autorizzazione, requisiti relativi al luogo di archiviazione dei dati e lingue necessarie. Da ciò nasce un obiettivo con criteri verificabili: processi da coprire, numero di utenti, volume di dati, quadro dei costi e scadenze.

L'obiettivo è più di uno studio preliminare: in seguito funge da parametro di valutazione per la selezione del fornitore e da criterio di collaudo dopo il rollout. La complessità ridotta e le dipendenze tecnologiche minimizzate si possono misurare in base al numero di sistemi sostituiti e alle interfacce rimanenti.

Selezione della soluzione: criteri con riferimento alla Svizzera

Un catalogo di criteri impedisce che le impressioni delle demo determinino la selezione. Da verificare: ambito delle funzioni rispetto ai requisiti di processo rilevati, archiviazione dei dati in Svizzera o nell'UE (requisito per la conformità alla LPD), multilinguismo in DE/EN/FR come standard per il mercato svizzero, fatturazione e modalità di pagamento, nonché il supporto del fornitore durante l'introduzione. Molti clienti B2B svizzeri preferiscono il pagamento tramite bonifico IBAN; chiarire se il fornitore lo supporta e se le fatture vengono emesse in CHF con IVA svizzera – in Svizzera vige l'obbligo di imposta sul valore aggiunto a partire da un fatturato annuo di CHF 100'000.

Anche i criteri tecnici hanno lo stesso peso. In un'architettura multi-tenant, più clienti utilizzano la stessa istanza del software, ma i loro dati sono completamente separati. Le funzioni tipiche di una soluzione SaaS sono la gestione di 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 solitamente prenotare con pochi clic, il che mantiene basso lo sforzo in caso di crescita o cambi di personale.

Per il confronto strutturato è adatta una matrice di valutazione ponderata: stesse domande a tutti i fornitori, valutazione per criterio, somma solo in seguito. Un accesso di prova con propri dati di esempio mostra se i processi chiave sono effettivamente mappati. Da chiarire per iscritto: tempi di supporto e reazione, comunicazione dei rilasci, esportazione dei dati in caso di recesso, termini di disdetta e regole sui prezzi all'aumentare del numero di utenti. Una classifica non sostituisce questa verifica – riassume solo ciò che è stato valutato in precedenza con criteri propri.

Criteri per la selezione dei fornitori SaaS (riferimento alla Svizzera)

Il piano di progetto: fasi dalla concezione al rollout

Una procedura collaudata si articola in cinque fasi: concetto e ambito, decisioni su architettura e integrazione, pilota con un gruppo di utenti limitato, rollout su vasta scala e successiva scalabilità. Una procedura simile è nota nello sviluppo SaaS: strategia di prodotto, design dell'architettura, validazione dell'MVP con utenti reali, scalabilità. Ogni fase si conclude con risultati prestabiliti, che devono essere presenti prima che inizi la fase successiva.

Fase 1 – Concetto e ambito: i risultati sono l'analisi dei processi, l'elenco dei requisiti, il concetto preliminare, il dimensionamento (utenti, dati, interfacce) e la stima dei costi. Da decidere è quali moduli e aree funzionali introdurre e in quale ordine, e quali gruppi di utenti saranno i primi. Senza questa decisione non è possibile né la gara d'appalto né il confronto delle offerte.

Fase 2 – Architettura e integrazione: qui si prendono le decisioni tecniche di principio – funzionamento multi-tenant o single-tenant, concetto di isolamento dei dati, design dell'API, luogo di archiviazione dei dati, modello di autorizzazioni e l'elenco 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 chiave e dati reali; errori, lacune e problemi di utilizzo vengono rilevati e prioritizzati. Risultati: casi di test superati, elenco errori ripulito, documenti di formazione, dati di test migrati. Solo quando i processi chiave funzionano nel pilota, il rollout ha senso.

Fase 4 – Rollout: migrazione dei dati, formazione, supporto e comunicazione avvengono secondo un calendario per gruppo di utenti. Risultati: avvio in produzione con un numero di utenti definito, formazioni concluse, percorso di supporto funzionante. Fase 5 – Scalabilità: 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 e l'azienda pianifica di conseguenza il funzionamento e l'estensione.

Fasi del progetto per l'introduzione del SaaS

Definire e rendere misurabili le tappe fondamentali

Una tappa fondamentale funge da strumento di controllo solo se contiene quattro elementi: un risultato verificabile, un criterio su quando deve essere presente e un ruolo responsabile. Esempi: analisi dei processi conclusa, selezione del fornitore approvata dal committente, fase di test superata con utenti reali, avvio in produzione, obiettivi di utilizzo raggiunti dopo un periodo di osservazione definito.

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

La dimensione temporale dipende fortemente dall'ambito. Chi introduce solo un'area chiave ha bisogno di meno passi di migrazione, interfacce e formazioni rispetto a un ambito funzionale completo con più moduli. Le date fisse vanno quindi legate a eventi – approvazione del budget, scadenza di un vecchio contratto, fine di una fase pilota – e non a desideri di calendario che comprimono lo sforzo di test.

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

La base è il modello di responsabilità condivisa: la sicurezza dell'infrastruttura è a carico del fornitore SaaS, la sicurezza dei dati in gran parte a carico dell'azienda utilizzatrice. Molte aziende presumono erroneamente che il fornitore protegga anche i loro dati. In realtà, l'integrità, la conservazione e il backup dei dati rimangono in capo al cliente – insieme alla gestione degli accessi, alle autorizzazioni degli utenti e al ripristino dei dati.

Dal lato del fornitore ci sono la fornitura da centri di calcolo sicuri, il funzionamento, gli aggiornamenti, la manutenzione, le patch di sicurezza e i backup dell'infrastruttura. Dal lato dell'azienda ci sono la responsabilità dei dati, il concetto di autorizzazioni, il backup proprio dei dati SaaS, il piano di emergenza e la conformità.

Da ciò si possono derivare ruoli di progetto concreti: il lato committente decide su budget e approvazioni delle tappe fondamentali. I reparti specializzati forniscono processi, casi di test, collaudi e comunicazione agli utenti. L'IT è responsabile dell'integrazione, delle interfacce, del concetto di autorizzazioni e dell'esportazione e backup dei dati. La direzione del progetto gestisce 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 espressamente inserito nella pianificazione – i collaboratori dei reparti specializzati non sono disponibili per il lavoro quotidiano durante test e formazione.

Responsabilità condivisa nel SaaS: vantaggi e rischi

Regolare dati, diritti di accesso e ripristino

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

Rischi tipici contro cui il piano di progetto deve prendere provvedimenti: cancellazioni accidentali ed errori umani, insider malintenzionati, ransomware e attacchi informatici che prendono sempre di mira 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 affidarsi ai backup del fornitore.

Da ancorare saldamente 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, i termini di conservazione e cancellazione e un'esportazione ordinata in caso di recesso da un servizio. Senza questi punti resta aperto chi agisce in caso di emergenza.

Punti critici prima del go-live: dati e sicurezza

Migrazione e integrazione nel panorama di sistemi esistente

L'obiettivo della migrazione è trasferire applicazioni, dati e processi aziendali esistenti nel nuovo ambiente in modo sicuro, strutturato e senza interruzioni operative. A ciò sono associati la riduzione della complessità e la diminuzione delle dipendenze tecnologiche – entrambe misurabili in base al numero di sistemi sostituiti e alle interfacce rimanenti.

In pratica, la migrazione inizia con un inventario dei dati: quali set di dati sono necessari, dove si trovano oggi, chi è il proprietario, quali campi devono essere mappati e 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 in batch e cosa succede in caso di guasti.

Durante il passaggio, viene eseguito un funzionamento parallelo: il vecchio sistema e la nuova soluzione vengono gestiti contemporaneamente per un periodo definito. Da stabilire in anticipo sono la durata, i criteri per lo spegnimento, la responsabilità per la riconciliazione dei dati e una via di fallback in caso di intoppi nel passaggio. Dopo lo spegnimento del vecchio sistema, contratti, licenze, accessi e contratti di manutenzione vanno inseriti nella lista di chiusura – altrimenti costi e dipendenze permangono.

Passi di migrazione nel nuovo ambiente SaaS

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

Con l'avvio in produzione inizia il funzionamento. Il SaaS funziona secondo un modello di abbonamento con costi mensili o annuali; queste spese ricorrenti vanno inserite nel budget per l'intera durata, non solo per l'anno di introduzione. Utenti o licenze aggiuntive si possono solitamente aggiungere con pochi clic, facendo sì che i costi crescano con il numero di utenti.

Per il controllo, nel funzionamento rientrano gli indicatori chiave: utenti attivi, utilizzo per processo e casi di supporto. Analisi e dashboard forniscono i dati a tal fine. Le nuove funzioni vengono ampliate gradualmente e sulla base del feedback degli utenti – l'ulteriore sviluppo del prodotto non termina presso il fornitore con la prima versione live, di conseguenza anche presso il cliente si pianifica in modo continuo.

Costi e impegno temporale variano notevolmente a seconda dell'ambito. logixc indica valori di riferimento per lo sviluppo di un prodotto SaaS in Svizzera: da CHF 20'000 a 40'000 e da 6 a 10 settimane per un MVP, da CHF 40'000 a 80'000 e da 12 a 20 settimane per una v1.0 completa, CHF 80'000 e più nonché 6 mesi e oltre per varianti Enterprise con multi-tenancy, API e integrazioni. Queste cifre riguardano lo sviluppo del prodotto. Nell'introduzione di una soluzione acquistata, invece, si sostengono costi di abbonamento, integrazione, formazione e funzionamento; decisivi per il loro ammontare sono l'ambito, il numero di interfacce e la dimensione del gruppo di utenti.