Orientarsi nella selezione di una soluzione software di mercato per la propria azienda o ente

In un recente articolo su questo blog abbiamo messo a tema, in termini generali, la problematica relativa alla scelta della migliore soluzione software per l’informatizzazione di un processo operativo di una azienda o di un Ente. Abbiamo proposto una riflessione -dettata dalla nostra concreta esperienza professionale- a proposito dell’alternativa tra commissionare lo sviluppo di una soluzione software ad-hoc e acquistare una soluzione di mercato “pacchettizzata”. Siccome tra queste alternative non esiste -evidentemente- la scelta sempre giusta, abbiamo cercato di fare emergere i punti di attenzione ed i criteri generali per orientarsi nei casi concreti in riferimento ai quali si deve esercitare la difficile opzione.

In questo secondo articolo di una “mini-serie” sul tema, ci confrontiamo con lo scenario nel quale si è optato di dotarsi di un sistema software pacchettizzato, da selezionare tra le offerte che il mercato propone.

Premessa importante: l’attività di selezione di una soluzione software per la nostra organizzazione e per il nostro processo, deve essere pensata come un vero e proprio progetto aziendale. Se poi si tratta di informatizzare un processo importante o addirittura strategico per l’azienda, a capo di questo progetto è fondamentale ci sia il vertice aziendale.

Partiamo elencando i criteri principali che consigliamo di utilizzare per arrivare ad una scelta consapevole e ben ponderata:

1. costo del prodotto software all’acquisto;
2. costo per il supporto, la manutenzione ordinaria e gli aggiornamenti del prodotto software;
3. completezza funzionale e know-how contenuto nel sistema;
4. livello di configurabilità ed “evolvibilità” del software;
5. facilità d’uso e piacevolezza delle interfacce utente;
6. facilità di introduzione della soluzione nella propria organizzazione;
7. tecnologia impiegata;
8. barriere all’uscita: rischio lock-in;
9. diffusione del prodotto sul mercato;
10. competenza del fornitore sul tema specifico;
11. solidità ed affidabilità dell’azienda fornitrice;
12. servizi accessori e di supporto offerti dal fornitore.

Precisiamo anzitutto che i criteri proposti non sono da considerarsi ordinati per importanza. Non possono esserlo in generale: il primo lavoro da fare in un progetto di software selection consiste proprio nello stabilire un ordine di importanza (meglio ancora un peso) nei criteri in gioco per orientare la scelta.

Costo del prodotto (punti 1 e 2)

Partiamo con i criteri più semplici da mettere a tema, quelli relativi al prezzo. Sono criteri semplici perchè hanno come oggetto una dimensione misurabile ed oggettiva in riferimento alla quale è relativamente semplice confrontarsi.

Anzitutto facciamo notare l’importanza di analizzare la componente costo del software nelle due dimensioni normalmente presenti: il costo una tantum  in fase di acquisto e il costo per le manutenzione ordinarie: oggi tante offerte sul mercato propongono costi di ingresso molto competitivi (a volte anche nulli) puntando ad ottenere una remunerazione dai costi di manutenzione e supporto. In un numero crescente di situazioni, il software viene proposto anche (o solo) in affitto, sfruttando la possibilità di erogarlo come servizio cloud-based, ad un canone fisso e permanente comprensivo degli aggiornamenti.

Ovviamente nel riflettere a proposito del costo, occorre fare i conti con la propria capacità di spesa messa in relazione all’importanza strategica del processo da informatizzare. E’ dunque importante stabilire con queste valutazioni la cifra limite che si ritiene ragionevole investire nell’acquisto. Fissato un estremo superiore per la spesa, il criterio -costo del prodotto- dovrebbe tendenzialmente scomparire dal novero dei criteri in gioco.

Estremizzando, bisognerebbe riuscire ad affrontare la valutazione degli altri fattori della scelta, dimenticandosi del costo del prodotto: tante volte un costo elevato viene scambiato per un sinonimo di qualità (niente di meno scontato quando si tratta di software pacchettizzato!) o, viceversa si tende a sottostimare i fattori di qualità di un certo prodotto costoso,  esaltandoli in un altro meno costoso orientandosi -magari inconsciamente- a propendere ingiustificatamente per un prodotto solo perchè fa risparmiare (nell’immediato!).

Sopratutto quando nel paniere dei prodotti valutati è presente anche un prodotto con licenza gratuita (open source o meno), risulta molto facile commettere gli errori suddetti, svalutandolo a priori il prodotto (se è gratis … non vale niente) o -viceversa- privilegiando questa scelta reputandola meno rischiosa e facile da revocare in caso di insuccesso. Approfittiamo di questo passaggio per fare notare che, avviare un sistema software all’interno ad una organizzazione può comportare costi anche molto rilevanti per la struttura che lo deve adottare. Dunque, sbagliare una scelta di questo tipo, produce in ogni caso sprechi e -forse fatto ancora più grave- perdita di credibilità nei confronti della propria organizzazione.

Completezza funzionale e configurabilità del software (punti 3 e 4)

Un fattore decisivo nella valutazione è senz’altro la completezza funzionale delle diverse soluzioni valutate. Per valutare adeguatamente questo fattore è importante fare lo sforzo di produrre una lista dei requisiti funzionali, classificandoli in:

• requisiti essenziali: l’eventuale mancanza di un requisito di questo tipo è un motivo sufficiente per escludere un prodotto;
• requisiti importanti: l’eventuale mancanza di un requisito di questo tipo fa perdere valore in modo sostanziale ad un prodotto;
• requisiti auspicabili: l’eventuale mancanza di un requisito di questo tipo fa perdere valore in modo contenuto ad un prodotto;
• requisiti accessori: l’eventuale presenza di un requisito di questo tipo fa guadagnare valore in modo contenuto ad un prodotto;

Nel giudicare l’importanza di un requisito (quindi nel classificarlo), è sempre bene fare contare prioritariamente il valore misurabile che l’automazione in questione produce concretamente all’interno dell’organizzazione. In altre parole, un requisito è tanto più importante quanto è elevato il guadagno indotto da questa funzione informatizzata, in termini di riduzione del tempo di lavoro di persone coinvolte nel processo, supporto alla riduzione del numero di errori, incremento di velocità nel dare risposte strategiche al management, soddisfazione dei clienti utilizzatori del servizio, ecc. .

Potrebbe sembrare una sottolineatura superflua, scontata, ma tante volte ci capita di constatare l’applicazione di criteri di importanza del tutto inadeguati, derivanti prevalentemente da “fissazioni” al riguardo di prassi operative consolidate che potrebbero essere messe facilmente in discussione, magari guadagnandoci anche in termini di efficienza.

Andando oltre la mera completezza funzionale, in alcuni casi, in un prodotto software è interessante poter trovare il valore di una “esperienza consolidata del processo” da informatizzare.  Il know-how contenuto nel sistema informatico acquistato, potrebbe veicolare alla nostra organizzazione un valore aggiunto importante in termini di correttezza ed efficienza della gestione.

Se ad esempio devo informatizzare il processo di acquisto di capi finiti (da rivendere) nel settore della moda, è auspicabile che il software che sceglierò sia intrinsecamente ricco di indicazioni circa il modo più corretto ed efficiente per redigere un ordinativo caratteristico per questo settore di attività, per stabilire un solido scambio di documenti contrattuali con il fornitore, per gestire le fasi successive all’ordine (eventuali rettifiche, tempi e modi di consegna della merce, modalità di pagamento,…)  in relazione con la controparte (il fornitore), ma anche con gli altri reparti della propria organizzazione.

In alcuni ambiti, soprattutto quando la mia organizzazione entra in un nuovo settore operativo, senza portarsi in dote una consolidata esperienza dei processi che lo caratterizzano, la ricchezza di know-how di cui è dotato un sistema informatico, potrebbe diventare il motivo determinante per preferirlo a tutti gli altri.

Vale infine la pena ricordare che, nel valutare la qualità funzionale di un sistema software, non è sufficiente prendere atto della disponibilità o meno di una funziona applicativa. E’ estremamente importante capire con quale costo (generalizzato) sarà possibile modificare tale funzione per farla evolvere a copertura di eventuali nuove esigenze o per mutarne il comportamento.

Se ad esempio mi trovo a dover selezionare un sistema per gestire prenotazioni di visite mediche, potrebbe darsi il caso che la soluzione che sto valutando,  prevedendo slot di visita configurabili di durata di 5 minuti o di multipli di 5 minuti, sia perfettamente conforme alle mie attuali esigenze. E’ plausibile però che in futuro l’organizzazione potrebbe avere bisogno di gestire anche slot di visita della durata di 7 minuti. E’ dunque fondamentale in fase di valutazione del software, accertarsi del fatto che la modifica dell’unità temporale minima per una prenotazione sia un parametro configurabile, ovvero modificabile senza richiedere la modifica del codice sorgente del sistema o, quantomeno, che l’eventuale necessaria modifica non costringa ad uno stravolgimento delle logiche di fondo o delle interfacce utente dell’applicazione.

Facilità d’uso, piacevolezza delle interfacce utente e accettabilità della soluzione nell’organizzazione a cui è destinata (punti 5 e 6)

La facilità d’uso e la piacevolezza delle interfacce utente dell’applicativo sono fattori che, anche nell’ambito di software aziendale, diventano sempre più importanti. Una sempre più diffusa abitudine ad utilizzare applicazioni intuitive ed immediate per rispondere alle quotidiane esigenze personali, rende gli utenti (giustamente) esigenti anche per quanto riguarda l’esperienza d’uso del software aziendale.

D’altro canto, sopratutto se gli utenti potenziali del sistema software sono tanti e, anche solo in parte, occasionali, interfacce utente ben fatte, intuitive ed “usabili”, tendono a garantire minore bisogno di formazione, meno frustrazione nell’utilizzo, meno errori e maggiore semplicità nel fare accettare il nuovo software all’organizzazione a cui è destinato.

Abbiamo collegato il tema della facilità di accettazione del software ai requisiti di qualità delle interfacce utente in quanto questo aspetto rappresenta una parte della questione, di importanza crescente. Detto questo -evidentemente- non tutto si risolve a questo livello. Nel determinare l’eventuale difficoltà ad introdurre un nuovo sistema informatico in una organizzazione, occorre, in aggiunta, tenere conto di:

• competenze di partenza dei potenziali utenti;
• affinità dei modi di operare suggeriti dal nuovo sistema con le abitudini storiche degli utenti;
• coerenza logica con la quale le diverse funzioni ed i processi sono messi a disposizione degli utenti nell’applicativo: tanto più le funzioni sono organizzate in modo logico e coerente, tanta fatica in meno dovranno fare gli utenti per mutuare rapidamente le nuove logiche operative .

 Tecnologia e architettura del sistema (punto 7)

La valutazione della tecnologia e dell’architettura con la quale il software è costruito potrebbe apparire un fattore del tutto secondario quando si acquista un prodotto pacchettizzato. Pur non ritenendolo tra i fattori più importanti per la scelta, suggeriamo comunque di considerarlo, coinvolgendo nel team del progetto una figura tecnica con competenze adeguate per “guardarci dentro”.

Quello di cui bisogna sopratutto accertarsi, è che la tecnologia del prodotto in valutazione non sia evidentemente obsoleta.  Una tecnologia obsoleta potrebbe creare problemi quando i sistemi operativi del Server, dei PC o gli Internet browser verranno aggiornati. Peraltro l’impiego di tecnologie obsolete indica -normalmente- una bassa propensione all’investimento sul prodotto da parte del fornitore.

Se diamo poi per scontato (e non è bene farlo in assoluto) che a nuove e moderne tecnologie ed architetture software corrispondono vantaggi in termini di prestazioni, efficienza e qualità del software, acquistare un prodotto -magari ottimo sotto altri punti di vista- costruito con tecnologie o architetture obsolete è sempre una scelta da ponderare attentamente.

Barriere all’uscita: rischio lock-in (punto 8)

Confermando, come si è scritto in precedenza, che è molto importante fare di tutto per non trovarsi nelle condizioni di dover fare tardiva marcia indietro dopo aver selezionato e messo in esercizio una certa soluzione software, è parimenti vero che, già in fase di selezione, è importante considerare la possibilità di dover o voler -dopo un certo tempo- sostituire il prodotto scelto. Uno dei fattori da valutare nella selezione, sopratutto se ci si confronta con una soluzione con costi di manutenzione elevati, deve essere il costo (generalizzato) per la sostituzione della soluzione ipotizzata.

Non sempre è possibile immaginare un modo semplice per cambiare software e/o fornitore di servizi di supporto dopo una certo tempo di utilizzo; il fatto che il sistema scelto sia basato su approcci e formati dei dati standard, è -in linea generale- una discreta garanzia di ridotte barriere all’uscita nel momento in cui si dovesse presentare l’esigenza.

 Diffusione del prodotto sul mercato (punto 9)

Come è facile comprendere, il fatto che un prodotto software sia diffuso e utilizzato da tante altre organizzazioni, tende ad essere un fattore di garanzia sia per quello che riguarda la solidità e completezza della soluzione, sia per le prospettive di continuità nel tempo del prodotto stesso.

Un primo suggerimento per evitare di banalizzare pericolosamente questa valutazione, è quello di non fermarsi a considerare QUANTI altri clienti hanno scelto un certo prodotto, ma di valutare attentamente QUALI clienti lo utilizzano: qual’è la dimensione media di chi lo ha scelto finora, qual’è l’attività principale di queste organizzazioni, quante analogie ci sono tra la mia organizzazione e la maggior parte degli altri clienti di questo prodotto, ecc. .

Non sempre poi una grande diffusione del prodotto è un motivo adeguato per preferirlo. A volte la grande diffusione di un prodotto è determinata solo dal fatto che questo è arrivato sul mercato per primo riuscendo a guadagnare quote di importanti che, ad un esame più attento delle tendenze, si scoprono calanti o crescenti meno rapidamente rispetto ad altri prodotti concorrenti.

Bisogna infine evitare facendo queste considerazioni, di scartare a priori e perdere di vista prodotti molto recenti, con quote di mercato magari molto basse, che  potrebbero rappresentare soluzioni molto innovative dal punto di vista dei paradigmi funzionali o della tecnologia utilizzata. Optare per una soluzione di questo tipo è mediamente  più rischioso ma nel contempo potrebbe offrire un’interessante opportunità di essere aiutati dal sistema informatico ad offrire un servizio, o a mettere in atto un processo, con un interessante valore distintivo rispetto alla concorrenza. Certo è che, per fare una scelta di questo tipo occorre che il team che si occupa della software selection sia un team decisamente consapevole e competente (forse è questo il motivo per cui, scelte di questo tipo sono molto rare in Italia mentre sono documentate scelte fatte da grandi multi-nazionali o aziende governative americane che “rischiano” di impiegare prodotti realizzati da startup di poche persone, senza una storia alle spalle, anche per informatizzare processi strategici della loro organizzazione).

 Qualità e affidabilità del fornitore (punti 10,11, 12)

Concludiamo le nostre considerazioni sui criteri per la software selection mettendo a tema la qualità del fornitore del prodotto, articolata attraverso la valutazione della solidità aziendale, della sua competenza di merito sul processo e della sua capacità di offrire i servizi di supporto necessari per l’esercizio e l’evoluzione nel tempo del prodotto venduto.

Un prodotto giudicato ottimo, secondo tutti i criteri finora esaminati, potrebbe essere un prodotto da evitare se l’azienda che lo fornisce dovesse risultare poco convincente in termini di solidità ed affidabilità.

Scegliere il prodotto offerto da un’azienda con una storia breve, poco capitalizzata, con investitori alle spalle poco solidi, significa doversi confrontare con un significativo rischio di adottare un prodotto che potrebbe rimanere orfano dopo poco tempo. Quanto questo rischio sia in effetti rilevante è da valutarsi di volta in volta mettendolo a confronto con i benefici aggiuntivi che l’opzione per quel prodotto potrebbe garantire.

Facendo queste considerazioni, aziende con una certa struttura e capitalizzazione, quando il prodotto software valutato lo merita davvero, mettono in conto anche la possibilità -qualora diventasse necessario o opportuno- di salvare l’operazione acquisendo l’azienda fornitrice (privando peraltro in tal modo i concorrenti di un’opportunità) o internalizzando nella propria organizzazione le persone chiave del fornitore.

In relazione alla competenza di merito sul processo del fornitore, quello che si può dire è che, sopratutto quando il processo da informatizzare è un processo complesso, che richiede una importante esperienza per dominarlo, diventa prezioso poter avere a che fare con un fornitore che dimostra di conoscerlo molto bene e di padroneggiarne tutte le possibili varianti.

Ultimo, ma assolutamente non ultimo come importanza, occorre garantirsi in riferimento alla capacità del fornitore di:

• offrire servizi continuativi di assistenza e supporto garantendo livelli di servizio corrispondenti alle proprie esigenze e contrattualmente sanciti;
• offrire una prospettiva certa di evoluzione del prodotto attraverso un miglioramento continuo dello stesso, sia in un’ottica di mantenerlo tempestivamente aggiornato rispetto ad eventuali normative inerenti il suo campo di applicazione, sia nell’ottica di farlo evolvere con continuità con nuove funzionalità e miglioramenti tecnologici.

Nel prossimo (terzo ed ultimo) articolo di questa mini-serie, proporremo una analogo escursus a proposito dei criteri per valutare la scelta di un fornitore da incaricare della realizzazione di un prodotto software su misura. Vedremo che, salvo poche sovrapposizioni con il processo appena descritto, in gran parte si tratterà di un processo di valutazione differente, nel quale fattori simili dovranno essere considerati e soppesati in modo completamente diverso.