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 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 degli utenti 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'assunzione che un prodotto standard copra ogni caso speciale non regge.

Un'altra 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 grandi aggiornamenti 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: l'architettura di sistema esistente, i processi aziendali e i 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 di investimento trasparenti e un'architettura che cresce con l'azienda.

Da rilevare sono: mappa dei processi con le procedure interessate, dati correlati e flussi di dati, interfacce esistenti, ruoli e livelli di autorizzazione, requisiti per il luogo di archiviazione dei dati e lingue necessarie. Ne risulta un'immagine obiettivo con criteri verificabili: processi da coprire, numero di utenti, volume dei 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 possono misurare 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'ambito funzionale rispetto ai requisiti di processo rilevati, l'archiviazione dei dati in Svizzera o nell'UE, il multilinguismo in DE/EN/FR nonché la fatturazione e le modalità di pagamento. L'archiviazione 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 in CHF vengono emesse con IVA 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 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 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 ciò che è stato valutato in precedenza con i propri criteri.

Criteri ponderati per la scelta del fornitore SaaS (Svizzera)

Il piano di progetto: fasi dalla concezione al rollout

Una procedura collaudata passa attraverso cinque fasi: concetto e ambito, decisioni su architettura e integrazione, pilota con gruppo di utenti limitato, rollout su larga scala e successiva scalabilità. Un approccio simile è noto nello sviluppo SaaS: strategia di prodotto, design dell'architettura, validazione MVP con utenti reali, scalabilità. Ogni fase termina con risultati definiti, che devono essere presenti prima che inizi la successiva.

Fase 1 – Concetto e ambito: i risultati sono l'analisi dei processi, la lista dei requisiti, il concetto generale, 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 hanno la priorità. Senza questa decisione non sono possibili né la gara d'appalto né il 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, luogo di archiviazione 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 ripulita, 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 avvengono secondo un calendario per gruppo di utenti. Risultati: avvio produttivo con numero di utenti definito, formazioni completate, canale 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, l'azienda pianifica conseguentemente l'esercizio e l'estensione.

Definire e rendere misurabili le tappe fondamentali

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 il ripristino dei dati è dimostrato – non se «l'umore è buono». 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 centrale necessita di meno passi di migrazione, interfacce e formazioni rispetto a un ambito funzionale completo con più moduli. Le date fisse vanno quindi legate ad eventi – approvazione del budget, scadenza di un vecchio contratto, fine di una fase pilota – e non a desideri di calendario che comprimono l'impegno di test.

Sequenza temporale delle tappe fondamentali nel progetto SaaS

Chi porta 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 degli utenti 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 approvazioni delle tappe fondamentali. Le aree 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 guida 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 aree specialistiche non sono disponibili per il lavoro quotidiano durante test e formazione.

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 errori umani, insider malintenzionati, 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.

Punti critici prima del go-live per l'introduzione SaaS

Migrazione e integrazione nel panorama di sistemi esistente

Obiettivo della migrazione è trasferire applicazioni, dati e processi aziendali esistenti 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 possono misurare 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 passaggio gira un esercizio parallelo: vecchio sistema e nuova soluzione vengono gestiti contemporaneamente per un periodo definito. Da stabilire in anticipo sono durata, criteri per la disattivazione, responsabilità per la riconciliazione dei dati e una via di ritorno in caso il passaggio si blocchi. Dopo la disattivazione 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 tutta la durata, non solo all'anno di introduzione. Utenti o licenze aggiuntive si possono solitamente prenotare in pochi clic, facendo crescere i costi con il numero di utenti.

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

Costi e impegno temporale variano fortemente con l'ambito. 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.

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