Come scegliere un software aziendale senza partire dal prodotto

Scegliere un software aziendale non significa partire dall’elenco delle piattaforme disponibili e cercare quella con più funzionalità. Prima del confronto tra prodotti occorre chiarire quale processo deve essere supportato, chi utilizzerà il sistema, quali requisiti sono realmente necessari, quali integrazioni servono e quali vincoli devono essere rispettati.

Solo dopo questa analisi è possibile confrontare soluzioni e fornitori utilizzando criteri omogenei. In questo modo la domanda cambia: non più semplicemente “qual è il software migliore?”, ma “quale soluzione risponde meglio ai requisiti della nostra organizzazione?”.

Perché scegliere il software partendo dal prodotto può essere un errore

Una demo efficace può mostrare decine di funzioni interessanti. Una piattaforma molto conosciuta può avere caratteristiche tecniche avanzate. Nessuno di questi elementi, da solo, dimostra però che la soluzione sia adatta al processo che l’azienda deve gestire.

Partire direttamente dal prodotto rischia di invertire il percorso decisionale: invece di definire prima ciò che serve e verificare successivamente quali soluzioni lo soddisfano, si osservano le caratteristiche disponibili e si cerca di adattare l’organizzazione allo strumento.

Il software dovrebbe invece essere valutato rispetto a esigenze esplicite. La definizione dei requisiti è quindi un passaggio centrale: permette di trasformare necessità operative, vincoli e aspettative degli utenti in criteri utilizzabili per confrontare le alternative.

Prima del software: chiarire processo, obiettivi e utenti

Prima di preparare una lista di prodotti è utile delimitare il problema. Non occorre riprogettare necessariamente l’intero processo aziendale: bisogna però comprenderne abbastanza bene il funzionamento da sapere cosa si sta chiedendo al futuro sistema.

Quale processo deve supportare il software

Il punto di partenza è identificare le attività interessate: quali informazioni entrano nel processo, quali operazioni vengono eseguite, quali persone intervengono e quale risultato deve essere prodotto.

Per esempio, “serve un nuovo CRM” è ancora una descrizione troppo generica. È più utile chiarire se l’esigenza consiste nel centralizzare i contatti commerciali, gestire le opportunità, assegnare attività alla rete vendita, integrare le richieste provenienti dal sito o ottenere dati affidabili sull’avanzamento delle trattative.

Quale problema deve risolvere

La stessa categoria di software può essere adottata per esigenze molto diverse. Occorre quindi separare il bisogno dalla soluzione immaginata.

Un problema può riguardare, ad esempio, dati duplicati, attività manuali, difficoltà nel reperire informazioni, passaggi tra uffici non tracciati o strumenti che non comunicano tra loro. Identificare il problema consente di capire successivamente se una determinata funzione del software produce un beneficio concreto oppure è semplicemente disponibile.

Chi utilizzerà realmente la soluzione

Gli utenti coinvolti possono avere esigenze differenti. Direzione, amministrazione, commerciale e personale operativo possono utilizzare lo stesso sistema con obiettivi, frequenze e livelli di accesso diversi.

Coinvolgere gli utenti rilevanti nella raccolta dei requisiti aiuta anche a individuare attività ed eccezioni che potrebbero non emergere osservando il processo soltanto a livello direzionale.

Trasformare le esigenze aziendali in requisiti

Una volta chiarito il contesto, le esigenze devono diventare requisiti sufficientemente precisi da poter essere verificati. La requirements engineering, disciplinata anche dallo standard ISO/IEC/IEEE 29148, considera la definizione e gestione dei requisiti parte del ciclo di vita di sistemi e software.

Requisiti funzionali

I requisiti funzionali descrivono ciò che il sistema deve permettere di fare.

Alcuni esempi possono essere:

• creare e assegnare una richiesta a un responsabile;
• approvare un documento secondo un determinato flusso;
• importare automaticamente ordini provenienti da un altro sistema;
• generare un report utilizzando determinati dati;
• gestire ruoli e autorizzazioni differenti.

Formulazioni concrete rendono più semplice verificare il requisito durante una demo o un test.

Requisiti non funzionali

Non basta stabilire cosa deve fare il software. Occorre considerare anche le condizioni nelle quali deve funzionare.

In funzione del progetto possono diventare rilevanti aspetti come prestazioni, disponibilità, usabilità, modalità di accesso, sicurezza, gestione delle autorizzazioni, scalabilità, assistenza e continuità del servizio.

Questi requisiti possono incidere sulla scelta quanto le singole funzionalità.

Integrazioni e dati

Un software aziendale raramente opera in isolamento. Può essere necessario scambiare informazioni con ERP, CRM, e-commerce, sistemi amministrativi, piattaforme logistiche o altri strumenti già presenti.

Prima della scelta è quindi utile individuare almeno:

• quali sistemi devono comunicare;
• quali dati devono essere scambiati;
• con quale frequenza;
• quale sistema rappresenta la fonte principale del dato;
• come dovrà essere gestita un’eventuale migrazione iniziale.

Un prodotto adeguato dal punto di vista funzionale può diventare poco conveniente se richiede integrazioni complesse non considerate nella valutazione iniziale.

Sicurezza, scalabilità e continuità operativa

La sicurezza non dovrebbe essere trattata come una verifica separata da effettuare soltanto dopo la scelta. La sua importanza dipende dal processo, dai dati trattati e dal rischio associato al sistema.

Per i software più rilevanti può essere opportuno verificare, con il livello di approfondimento adeguato al progetto, aspetti quali gestione degli accessi, aggiornamenti, vulnerabilità, continuità del servizio, responsabilità del fornitore e pratiche adottate lungo il ciclo di vita del prodotto.

Anche la capacità della soluzione di accompagnare variazioni nel numero di utenti, nei volumi gestiti o nell’organizzazione dovrebbe essere valutata rispetto a scenari realistici, evitando sia di sottodimensionare il sistema sia di acquistare capacità non necessarie.

Come confrontare software diversi con criteri omogenei

Dopo aver definito i requisiti è possibile costruire una matrice di confronto. Lo scopo non è produrre automaticamente un punteggio finale, ma evitare che ogni soluzione venga valutata con criteri diversi.

È utile attribuire una priorità ai requisiti. Un requisito indispensabile non dovrebbe avere lo stesso peso di una caratteristica utile ma non necessaria.

È altrettanto importante registrare come è stata verificata una caratteristica. “Il fornitore dichiara che la funzione è disponibile” e “la funzione è stata provata utilizzando uno scenario aziendale” rappresentano livelli di evidenza differenti.

Software standard o personalizzato: cosa valutare

La scelta tra una soluzione standard, una piattaforma configurabile e un maggiore livello di personalizzazione non ha una risposta valida per tutte le aziende.

Una soluzione standard può coprire una parte elevata dei requisiti e beneficiare di un prodotto già mantenuto ed evoluto dal fornitore. In altri contesti possono essere necessarie configurazioni, integrazioni o personalizzazioni per gestire caratteristiche specifiche del processo.

Prima di decidere è utile distinguere chiaramente:

• ciò che il prodotto gestisce in modo standard;
• ciò che può essere ottenuto tramite configurazione;
• ciò che richiede personalizzazioni o sviluppo;
• ciò che non può essere realizzato o avrebbe costi e complessità non proporzionati.

Maggiore personalizzazione non significa automaticamente soluzione migliore. Ogni modifica può introdurre costi di sviluppo, manutenzione, test e compatibilità con gli aggiornamenti futuri. Allo stesso modo, adattare forzatamente un processo importante ai limiti di un prodotto può generare inefficienze operative.

Il prezzo del software non è l’unico costo da confrontare

Confrontare soltanto il prezzo della licenza può fornire una rappresentazione incompleta dell’investimento.

A seconda della soluzione, il costo complessivo può comprendere:

• licenze o abbonamenti;
• configurazione iniziale;
• personalizzazioni;
• migrazione e pulizia dei dati;
• integrazioni con altri sistemi;
• formazione degli utenti;
• assistenza e manutenzione;
• attività necessarie per aggiornamenti ed evoluzioni future.

Non tutte queste voci sono presenti in ogni progetto. Il punto è renderle esplicite prima del confronto economico, chiedendo ai fornitori cosa sia incluso e cosa richieda attività o costi aggiuntivi.

Come valutare il fornitore oltre alla demo

La scelta non riguarda soltanto il prodotto. Soprattutto per sistemi rilevanti per l’operatività aziendale, occorre valutare anche il soggetto che dovrà fornire, configurare, integrare o supportare la soluzione.

La due diligence sul fornitore può assumere profondità differenti in funzione del rischio. Le indicazioni NIST sulla gestione del rischio nella supply chain ICT sottolineano l’importanza di raccogliere informazioni pertinenti su prodotto e fornitore prima di assumere decisioni di acquisizione.

Verificare come comprende requisiti e processi

Un confronto utile non dovrebbe iniziare soltanto con l’elenco delle funzioni del prodotto. È importante verificare se il fornitore comprende il processo, individua eventuali punti da chiarire e distingue tra requisito, configurazione e personalizzazione.

Chiedere cosa è standard, configurabile o personalizzato

Una funzione mostrata durante la presentazione potrebbe essere inclusa nel prodotto, disponibile soltanto in un determinato piano, richiedere un modulo aggiuntivo oppure dipendere da uno sviluppo specifico.

Questa distinzione deve essere esplicitata perché influenza costi, tempi, manutenzione e possibilità di aggiornamento.

Valutare implementazione, assistenza e responsabilità

Prima della decisione è opportuno chiarire chi si occuperà di configurazione, migrazione, integrazioni, formazione e supporto, quali attività rimarranno a carico dell’azienda e come saranno gestiti problemi ed evoluzioni successive.

Per sistemi con un profilo di rischio significativo, la valutazione può comprendere anche domande più approfondite sulle pratiche di sicurezza del produttore e sulla gestione delle vulnerabilità. La profondità di questi controlli deve essere proporzionata al contesto e non può essere sostituita da una checklist generica.

Usare demo e test per verificare scenari reali

Una demo diventa più utile quando parte dai requisiti dell’azienda.

Invece di chiedere genericamente di “mostrare il software”, è possibile sottoporre al fornitore alcuni scenari rappresentativi: creare una pratica, importare un ordine, autorizzare una richiesta, ricercare un’informazione o produrre il report necessario al responsabile.

In questo modo la demo diventa anche uno strumento di verifica.

Checklist prima di scegliere un software aziendale

Prima della decisione finale può essere utile verificare che siano stati affrontati almeno questi punti:

• Processo: è chiaro quale attività deve essere supportata?
• Problema: è definito ciò che deve migliorare o cambiare?
• Utenti: sono stati coinvolti i ruoli realmente interessati?
• Requisiti: sono documentati quelli funzionali e non funzionali?
• Priorità: è distinto ciò che è indispensabile da ciò che è semplicemente utile?
• Dati: sono chiare provenienza, migrazione e responsabilità?
• Integrazioni: sono stati identificati i sistemi che devono comunicare?
• Costi: sono considerate anche implementazione, integrazioni, formazione e assistenza?
• Demo e test: le funzioni principali sono state verificate su scenari significativi?
• Fornitore: sono chiari attività, responsabilità, supporto e condizioni?

La checklist non sostituisce un’analisi tecnica quando il sistema è complesso o critico, ma aiuta a evitare che la decisione sia guidata soltanto dalla presentazione commerciale o dal prezzo iniziale.

Quando può essere utile un supporto esterno nella selezione

La selezione diventa più complessa quando coinvolge più uffici, integrazioni con sistemi esistenti, migrazione di dati, numerosi requisiti o fornitori con proposte difficili da confrontare.

In questi casi un supporto esterno può aiutare l’azienda a formalizzare i requisiti, organizzare i criteri di confronto, coordinare gli interlocutori e mantenere distinta l’esigenza aziendale dalla soluzione proposta dal singolo vendor.

È un approccio coerente con la consulenza Tech & Digital di DieSSe: l’analisi di processi, requisiti e strumenti precede la selezione della tecnologia.

La qualità della scelta dipende anche dalla qualità delle domande

Non esiste un software aziendale migliore in assoluto. Esistono soluzioni più o meno coerenti con determinati processi, requisiti, vincoli e obiettivi.

Per questo la selezione dovrebbe produrre una decisione motivabile: l’azienda deve poter ricostruire quali criteri ha utilizzato, quali requisiti ha verificato, quali compromessi ha accettato e quali costi e responsabilità ha considerato.

Partire dai requisiti non elimina la complessità della scelta, ma rende il confronto tra software e fornitori più strutturato e verificabile.

Stai valutando un nuovo software aziendale o devi confrontare proposte difficili da mettere sullo stesso piano? Richiedi un primo confronto.

Domande frequenti sulla scelta del software aziendale

Quali requisiti bisogna definire prima di scegliere un software aziendale?

Occorre definire almeno le funzioni necessarie, gli utenti coinvolti, i dati da gestire, le integrazioni con altri sistemi e i requisiti non funzionali pertinenti, come sicurezza, prestazioni, scalabilità e assistenza. I requisiti dovrebbero inoltre essere classificati per priorità.

Come confrontare due software aziendali?

È utile applicare alle soluzioni la stessa matrice di requisiti e verificare ogni elemento attraverso documentazione, demo o test. Il confronto dovrebbe comprendere anche integrazioni, costi complessivi, implementazione, assistenza e caratteristiche del fornitore.

È meglio un software standard o una soluzione personalizzata?

Dipende dai requisiti e dal contesto. Una soluzione standard può coprire adeguatamente molti processi, mentre esigenze specifiche possono richiedere configurazioni, integrazioni o personalizzazioni. Occorre valutare anche gli effetti futuri su costi, manutenzione e aggiornamenti.

Quali costi bisogna considerare oltre alla licenza?

Quando applicabili, vanno considerati configurazione, personalizzazioni, migrazione dei dati, integrazioni, formazione, assistenza, manutenzione ed evoluzioni successive. Le voci effettive dipendono dal prodotto e dal progetto.

Come valutare un fornitore di software aziendale?

Oltre al prodotto, è utile valutare la capacità di comprendere i requisiti, la chiarezza su configurazioni e personalizzazioni, le modalità di implementazione e assistenza, le responsabilità e, quando il rischio lo richiede, le pratiche di sicurezza e gestione delle vulnerabilità.

Fonti consultate

• ISO — ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering, versione confermata nel 2024.
• National Institute of Standards and Technology (NIST) — SP 1326, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, luglio 2026.
• Cybersecurity and Infrastructure Security Agency (CISA) — Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem.
• CISA — Software Acquisition Guide for Government Enterprise Consumers. Utilizzato esclusivamente come riferimento metodologico per gli aspetti di sicurezza e valutazione del fornitore; il documento è rivolto principalmente al contesto governativo statunitense.