Scegliere il SaaS: criteri per requisiti, valutazione e decisione

Il SaaS è un modello operativo, non una semplice modalità di fornitura

Chi utilizza il SaaS non acquista software nel senso classico, ma un servizio continuativo. Il fornitore gestisce l’applicazione, fornisce gli aggiornamenti e si occupa del supporto e della formazione; la soluzione è altamente disponibile e accessibile da qualsiasi luogo e da qualsiasi dispositivo connesso a Internet. Il fulcro della decisione si sposta quindi: ciò che conta non è l’installazione, ma l’esercizio continuo.

Poiché il fornitore è responsabile dell’esercizio, cambiano le priorità: il modello operativo, la qualità del servizio e la dipendenza dal vendor pesano più che nel caso di software installato in loco, dove gestione, manutenzione e aggiornamenti sono a carico dell’azienda. La scelta non dipende dunque solo dalle funzionalità, ma anche dalla misura in cui il servizio viene erogato in modo affidabile, sicuro e prevedibile per tutta la durata del contratto.

Anche la logica dei costi cambia: le piattaforme SaaS basate sul cloud sostituiscono le spese in conto capitale con costi operativi caratterizzati da modelli di prezzo prevedibili e da un ridotto onere di manutenzione IT (Philips). Non è l’acquisto una tantum a essere al centro dell’attenzione, bensì i costi ricorrenti. Questo rende più difficile il confronto tra le offerte, ma abbassa la barriera all’ingresso.

Dal proprio processo ai requisiti

I requisiti nascono dall’operatività aziendale, non da un elenco di funzionalità. Per Forterro è decisivo stabilire se una soluzione sia adatta al settore, alle dimensioni dell’azienda, al Paese, alla complessità dei processi e al focus tematico – ovvero se al centro vi siano commercio, produzione, distribuzione, finanza, progetti o manifattura industriale. Un sistema cloud per aziende commerciali pone accenti diversi rispetto a uno destinato alla produzione orientata ai progetti.

La via pratica passa attraverso i propri flussi lavorativi: annotare i processi principali nel loro effettivo ordine sequenziale, registrare volumi e quantità di documenti, definire i ruoli coinvolti, individuare i punti di passaggio verso altri sistemi e descrivere quelle eccezioni che nella quotidianità generano lavoro aggiuntivo. Da qui si possono derivare criteri verificabili suddivisi in obbligatori, desiderabili e opzionali.

Un catalogo di criteri slegato dai processi aziendali non costituisce una base decisionale valida. Ogni fornitore lo soddisferebbe allo stesso modo e la discussione si sposterebbe su aspetti marginali per l’esercizio. È quindi utile collegare ogni criterio al processo che dovrebbe migliorare – ed eliminare i criteri privi di tale collegamento.

Solo cloud o opzione cloud successiva

Il modello operativo è un criterio di valutazione autonomo. Per Forterro è decisivo stabilire se una soluzione sia stata sviluppata fin dall’inizio come ERP cloud o se un sistema ERP consolidato sia disponibile anche in modalità cloud. La panoramica citata classifica Myfactory come ERP puramente cloud; Abas, Jeeves, Sylob, ProConcept e Orderwise offrono le loro soluzioni cloud in aggiunta alle proposte ERP consolidate. Questa distinzione è rilevante perché mostra quanto coerentemente un prodotto sia concepito per l’esercizio continuativo.

Al modello operativo si collegano le domande che determinano la quotidianità: costi prevedibili, concetti di sicurezza professionali, alta disponibilità e infrastruttura scalabile. Per l’esercizio cloud, Abas menziona tra l’altro la trasparenza dei costi, backup automatizzati, patch, monitoraggio, sicurezza, disponibilità e infrastruttura scalabile.

Ai fini della valutazione, ciò significa chiedere concretamente: dove risiedono i dati, come vengono colmate le lacune di sicurezza, con quale frequenza vengono effettuati gli aggiornamenti, come vengono creati e ripristinati i backup, quale disponibilità viene garantita, come si scala in caso di crescita e chi reagisce entro quali termini in caso di guasti? Le risposte mostrano quanto cambi effettivamente l’onere IT interno – e se si realizzi quel sollievo promesso dal modello.

L’apertura tecnica come metro di valutazione

Per la valutazione tecnica è possibile formulare criteri verificabili: il software dovrebbe essere utilizzabile tramite browser e idealmente anche tramite app mobile; l’azienda dovrebbe poter configurare autonomamente tutto il necessario e dovrebbero essere possibili adattamenti più approfonditi mediante funzioni NoCode o LowCode. Si aggiungono un’API web versatile e ben documentata per le integrazioni, trigger e azioni standard per le principali piattaforme di integrazione NoCode come Zapier e Make, nonché la possibilità di esportare in qualsiasi momento tutti i dati in formati significativi (topsoft).

Questi punti decidono sull’utilizzabilità a lungo termine. Un account che può essere attivato online senza l’intervento del produttore rappresenta una promessa diversa rispetto a una soluzione in cui ogni modifica passa attraverso il fornitore. Chi configura in autonomia e si integra tramite interfacce documentate mantiene la capacità di agire quando i processi cambiano o vengono aggiunti ulteriori sistemi.

Uno sguardo al mercato svizzero mostra perché qui sia necessaria un’analisi accurata. Nella panoramica di mercato di topsoft, restringendo il campo ai criteri «client nel browser» e «cloud», dei 2253 prodotti di 960 fornitori ne rimanevano 18 prodotti di 12 fornitori; un’API REST era offerta da 51 prodotti di 35 fornitori. L’esportazione dei dati non è quindi una condizione accessoria, ma una garanzia per l’uscita.

Panoramica di mercato: apertura tecnica delle soluzioni SaaS in Svizzera

Profondità nella propria nicchia invece di ampiezza funzionale

Una soluzione che copre tutto per tutti raramente diventa indispensabile. Un’analisi del mercato SaaS svizzero riassume il principio: chi vuole essere tutto per tutti non è indispensabile per nessuno.

Chi invece si rivolge a un settore regolamentato con know-how tecnico specifico costruisce una posizione che un generalista difficilmente può replicare (Scalemetrics). Come esempio, la fonte cita Exnaton, focalizzata sulla tariffazione dinamica e sulla fatturazione energetica supportata dall’IA per i fornitori di energia, avendo integrato nel prodotto requisiti di compliance come ElCom ed ENTSO-E – ambiti in cui, secondo la fonte, le soluzioni SaaS generiche falliscono.

Da ciò si possono derivare due criteri di verifica. Primo: la conoscenza del settore e i requisiti di conformità specifici sono radicati nel prodotto, invece di essere offerti come servizi di consulenza a parte? La compliance può essere per determinati gruppi di clienti un motivo d’acquisto, non solo un ostacolo. Secondo: il fornitore può dimostrare impieghi presso clienti comparabili? L’analisi citata riporta per Exnaton progetti pilota dimostrati presso fornitori di energia prima del round di finanziamento – un segnale di effettiva risoluzione dei problemi anziché di mere announcements.

Per la decisione di selezione ne consegue che un ampio elenco di funzionalità non ha valore di per sé. Chi risolve realmente un problema circoscritto nel proprio settore mantiene il know-how specialistico nel prodotto e non solo durante il colloquio di vendita.

Criteri per la selezione di un fornitore SaaS nel mercato svizzero

Rendere confrontabili costi, benefici e rischi

Nella valutazione rientrano i costi operativi prevedibili al posto delle spese in conto capitale, nonché il ridotto onere di manutenzione. Secondo Philips, le piattaforme SaaS basate sul cloud consentono una rapida scalabilità senza nuovo hardware, trasformano le spese in conto capitale in costi operativi e riducono l’onere di manutenzione IT. Questi effetti devono entrare nel calcolo – ma non come presupposto, bensì come voce con un importo preciso.

Il confronto va effettuato sull’intera durata contrattuale, non solo sul primo anno. Oltre ai costi di licenza o abbonamento, vanno considerati l’implementazione, la migrazione dei dati, le interfacce, la formazione, eventuali adattamenti e l’onere interno di assistenza. Solo questa visione d’insieme rende due offerte effettivamente confrontabili e mostra se si realizza il promesso sollievo per l’IT interna.

Lo stesso spazio va riservato alla componente rischio: protezione dei dati e cybersecurity, integrazione nei sistemi esistenti, dipendenza dal fornitore, scenari di uscita e portabilità dei dati. Philips sottolinea che i fornitori SaaS nel settore sanitario devono garantire i requisiti HIPAA e GDPR mediante crittografia e gestione dei dati; come contesto, Philips indica che solo il 47 percento dei dati sensibili viene archiviato nel cloud, contro il 61 percento in altri settori. Per le aziende svizzere è fondamentale chiarire prima della firma i propri obblighi in materia di protezione dei dati, il luogo di conservazione dei dati e la restituzione contrattualmente garantita degli stessi.

Vantaggi e rischi dell’impiego del SaaS nel settore sanitario svizzero

Preparare la decisione e mettere in sicurezza l’implementazione

Il percorso decisionale segue un ordine semplice: ponderare i criteri, valutare le offerte in base a questa ponderazione, effettuare una fase di test limitata con dati reali e casi d’uso concreti e coinvolgere le aree funzionali interessate. Chi non coinvolte gli utenti nelle fasi iniziali prende una decisione che non verrà sostenuta nella quotidianità.

La decisione stessa va documentata: quali criteri, con quale peso, hanno determinato la scelta, quali fornitori sono stati esclusi e per quali motivi, e quali condizioni devono ancora essere soddisfatte prima della stipula del contratto. Non si tratta di un fine in sé: la documentazione rende la decisione comprensibile in seguito, quando i requisiti cambiano o si discute un cambio di fornitore.

La selezione non termina con la firma del contratto. Dal punto di vista dei fornitori, gli aggiornamenti regolari del prodotto e il continuo sviluppo sono centrali per soddisfare gli utenti e legarli più a lungo all’azienda. Per l’utente è l’altra faccia della stessa medaglia: se la scelta regge nella quotidianità lo si vede dopo – nella gestione del prodotto, nel suo ulteriore sviluppo e nell’adozione del servizio da parte degli utenti.

Passi per una decisione fondata nella selezione del SaaS