Articoli

Digital Transformation: Aspettative sulle soluzioni da acquisire

La software selection è un processo articolato e composito:

lo abbiamo ricordato in un precedente post sulla scelta del software migliore, in cui ci concentravamo sull’analisi preliminare del proprio business aziendale (senza la quale non è possibile fare una scelta oculata). Vedremo anche che, per una buona selezione, è necessario prendere in considerazione un numero limitato di vendor. Per poi analizzare non solo le soluzioni da un punto di vista “tecnico”, ma anche i servizi che essi offrono e l’organizzazione delle risorse umane che, all’interno della nostra azienda, saranno necessarie per ottenere il massimo dal nuovo software. In caso contrario, avremo speso male i nostri soldi non ottenendo i benefici auspicati.

Ora invece facciamo un passo indietro e ci chiediamo quali requisiti funzionali e quali modalità di acquisto dovrà presentare la soluzione ideale per le nostre esigenze: in breve, quali sono i principali benefici che ci aspettiamo di trovare nel software migliore. Anche in questo caso, come per l’analisi preliminare del nostro business, non prenderemo ancora in considerazione nessun prodotto particolare né le specifiche tecniche: questo sarà il passo successivo. Per ora, ci limiteremo a compilare una check list con gli elementi da “spuntare” che ci tornerà utile nei passaggi successivi.

“Ci chiediamo quali requisiti funzionali e quali modalità di acquisto dovrà presentare la soluzione ideale per le nostre esigenze: in breve, quali sono i principali benefici che ci aspettiamo di trovare nel software migliore”

E anche in questo caso, la nostra to-do list è articolata e coinvolge più decisori interni alla nostra azienda: certamente, non soltanto il reparto IT.

1. Lista dei requisiti funzionali: siamo tutti allineati?

La selezione di un software di classe enterprise può essere l’effetto di un bisogno, manifestato da un comparto interno della nostra azienda, oppure di un mandato diretto del top management (che ha una visione complessiva dei futuri interessi dell’azienda e della strategia da seguire). L’origine del mandato stesso dipende in gran parte dal fatto che il processo preso in esame sia core o secondario rispetto al business. Ricordando che spesso la scelta di un nuovo software è la chiave per cambiare i processi.

In ogni caso, quello che conta davvero è che tutti gli attori coinvolti (includendo chi manifesta il bisogno, chi prende le decisioni ai massimi livelli e chi ha le competenze tecnico-funzionali per svolgere la futura trattativa) devono essere allineati sullo scopo della selezione e sulle caratteristiche della soluzione da acquisire.

Solo con questi presupposti possiamo infatti stilare la lista dei requisiti funzionali. Idealmente, i nostri tre attori (fruitori, top manager e analisti tecnico-funzionali) si troveranno insieme per un’attività comune di brainstorming. Indubbiamente, questa possibilità dipende dalla variabile tempo (occorre tenere conto dei costi interni per la definizione e gestione di un progetto).

E quest’attività di allineamento è tanto più importante se si considera un ulteriore aspetto della selezione: come in ogni “buyer’s journey”, ossia il processo di acquisto che parte da una necessità e passa per il reperimento di informazioni sull’offerta di mercato, ci possono essere delle “zone grigie”. Non è infatti raro che il top management, o la funzione aziendale che fruirà la soluzione, si trovino ad avere una conoscenza generica sulla soluzione da adottare: sa cosa vuole, non come raccontarlo in modo chiaro ed espicito. Anche a questo è utile il supporto specialistico del comparto IT, se presidiato da buoni analisti funzionali che mettono in campo le giuste competenze.

Ecco allora alcune domande che si porrà il team: qual è l’elenco dettagliato dei requisiti richiesti? Ogni punto è chiaro a tutto il team che ha stilato la check list? Chi svolgerà la trattativa ha bene in mente il proprio mandato? E il mandato stesso è specifico e dettagliato o presenta lacune? Una buona strategia da adottare può essere il metodo Scrum: chi partecipa al progetto racconta una storia in modo che l’esposizione, di tipo discorsivo, favorisca la definizione dei concetti da utilizzare per il lavoro.

Lista dei requisiti funzionali: una scala di priorità

Spesso le soluzioni enterprise sul mercato non presentano tutte le funzioni richieste dall’acquirente. I responsabili d’azienda lo sanno fin dall’inizio. Ed è per questo che, una volta stilata la check list, si procede a stabilire un indice di priorità: ogni azienda, una volta fissati gli obiettivi, ha i propri.

“Spesso le soluzioni enterprise sul mercatonon presentano tutte le funzioni richieste dall’acquirente. I responsabili d’azienda lo sanno fin dall’inizio. Ed è per questo che, una volta stilata la check list, si procede a stabilire un indice di priorità

Alcuni suggeriscono di associare ad ogni requisito un diverso punteggio di importanza: il punteggio complessivo di ogni soluzione visionata risulterà dalla somma dei requisiti presenti e dalla loro importanza relativa. È un consiglio di buon senso, a patto di non essere troppo schematici nella valutazione finale: è naturale che nell’attribuzione di un rating pesino anche fattori esterni al software, legati più che altro al fornitore. Li vedremo in un post successivo.

3. La qualità del software: lista di indici

Per valutare l’intrinseca qualità del software occorre stabilire delle metriche oggettive (al di là quindi dei requisiti funzionali, puramente soggettivi, richiesti dall’azienda).

Non sapere con quali variabili misurare il prodotto significa non poter prendere consapevolezza del suo valore. Anche in questo caso, vogliamo compilare una lista prima di esaminare le singole soluzioni: la useremo come metro al momento della selezione vera e propria.

Esiste una letteratura ampia sull’argomento: in effetti, basta digitare su un motore di ricerca “qualità del software” per scoprire post e libri sull’argomento. Un punto di partenza utile è la voce Wikipedia, che elenca una serie di parametri esterni (ossia riguardanti la qualità percepita dall’utente), per valutare la qualità della soluzione da acquisire. Tra questi: correttezza, affidabilità, robustezza, efficienza. Ma anche interni, verificabili da un team di sviluppatori: manutenibilità, riusabilità, modularità sono alcuni degli esempi elencati.

Anche in questo caso il team decide un indice di priorità per i diversi parametri: ad esempio il management aziendale, che ha la visione strategica del progetto, può attribuire alla riusabilità del software un’importanza secondaria. E naturalmente, in questa fase della software selection, è bene conoscere il parere della funzione qualità dell’azienda (dove presente).

Newsletter sull’Innovazione
Non perderti le notizie più importanti sull'Innovazione. Iscriviti per riceverle via e-mail.

4. Budget a disposizione

È una variabile fondamentale: prima di cominciare una trattativa bisogna avere a mente il budget complessivo che si ha a disposizione per l’acquisizione del software (sia per il software in sé, sia per i costi in termini di ore-uomo necessarie all’attività di selezione). Per stabilire una somma realistica alcuni hanno già a disposizione un benchmark di soluzioni precedentemente acquisite dall’azienda, altri si affidano al passaparola tra colleghi dello stesso settore merceologico (o dello stesso gruppo industriale). Verificare quanto si è speso in precedenza per soluzioni simili agevola infatti il processo di software selection.

“Bisogna avere a mente il budget complessivo che si ha a disposizione per l’ acquisizione del software: verificare quanto si è speso in precedenza per soluzioni simili agevola infatti il processo di software selection”

Naturalmente, il prezzo di un software di livello enterprise è una diretta conseguenza non solo della sua qualità intrinseca, ma anche del lavoro svolto dal fornitore per progettarlo e svilupparlo: per ammortizzare i costi, esistono forme flessibili di acquisizione (li vedremo al punto 6).

5. La sicurezza dei dati

Non se ne parlerà mai abbastanza: ogni azienda si trova a trattare una mole sempre maggiore di dati relativa al proprio business e ai propri clienti. Allo stesso tempo, sappiamo che negli ultimi anni sono aumentati gli attacchi informatici sui database aziendali. Proteggere le proprie informazioni è quindi responsabilità diretta e ineliminabile di chi le gestisce.

Uno dei compiti di chi svolge la trattativa sarà quindi conoscere le tutele messe in campo dal provider. Intanto, una conoscenza basilare dei rischi e delle soluzioni non può far male: il responsabile del reparto ICT potrà informare i suoi interlocutori aziendali su entrambi gli aspetti.

6. Somministrazione del software: quali preferenze?

Decidere se si preferisce una soluzione in cloud (su infrastruttura remota) oppure on-premise (installata sui server aziendali) non è semplicemente un vezzo: budget e tipologia di gestione dei dati hanno la loro diretta ricaduta sulla modalità con cui è somministrato il software.

Per molti manager, una soluzione on-premise è ancora associata ad una percezione di stabilità e di controllo: tuttavia, sono da considerare gli investimenti più consistenti. D’altra parte, il cloud è più flessibile e meno oneroso in termini di prezzo, ma richiede che il fornitore dia maggiori garanzie in termini di sicurezza dei dati e performance dei canali (cioè di velocità di trasmissione e di esecuzione del programma).

Cambia anche la modalità di assunzione dei costi: il prezzo dell’on-premise è basato in genere su pagamento di licenze, costi di personalizzazione, setup iniziale, successivi costi di manutenzione e così via. Quello del cloud è invece un modello pay per use: maggiore la fruizione, maggiore il costo. Tipicamente, nella modalità cloud, tutti gli oneri che compongono il costo si trasformano in un canone che li riassume, solitamente inferiore (a fronte di un impegno contrattuale pluriennale, spesso dai tre ai cinque anni).

7. Se il software è da cambiare: punti di debolezza e di forza

Può sembrare un paradosso, ma lo è solo apparentemente: una buona check list delle aspettative che riponiamo sulla nuova soluzione… non prescinde da un’analisi del software che va cambiato. Naturalmente, non ci riferiamo alla situazione di una prima installazione.

“Una buona check list delle aspettative che riponiamo sulla nuova soluzione… non prescinde da un’analisi del software che va cambiato

In primo luogo, lo scopo è di indicare i punti di debolezza: sono le peculiarità che ci hanno spinto a cercare un prodotto differente. Anche il software invecchia e l’accanimento terapeutico sullo stesso può rivelarsi una mossa errata.

Tuttavia, potremmo dover annotare anche alcuni punti di forza: non è detto, infatti, che la gestione del processo con la vecchia soluzione fosse lacunosa in ogni suo aspetto.

Anche durante questa analisi, è utile svolgere un lavoro condiviso: conoscenza funzionale e conoscenza tecnica vanno di pari passo ed entrambe concorrono ad una valutazione più concreta della qualità del software. Anche di quello da cambiare!

Personalmente, penso che quando il software non è più adeguato non è certo colpa di chi ha fatto a sua tempo la scelta. Semplicemente il mercato è cambiato e quel software non risponde alle nuove esigenze del business. Per questo l’ultimo orientamento va sempre di più verso un refactoring continuo delle applicazioni.

Autore Paolo Ravalli

CEO Mainline srl

Newsletter sull’Innovazione
Non perderti le notizie più importanti sull'Innovazione. Iscriviti per riceverle via e-mail.

Articoli recenti

Smart Lock Market: pubblicato il report della ricerca di mercato

Con il termine Smart Lock Market, ci si riferisce all’industria e all’ecosistema che circonda la produzione, la distribuzione e l’uso…

27 Marzo 2024

Cosa sono i design patterns: perchè usarli, classificazione, pro e contro

Nell'ingegneria del software, i design pattern sono soluzioni ottimali a problemi che si verificano comunemente nella progettazione del software. Sono come…

26 Marzo 2024

L’evoluzione tecnologica della marcatura industriale

La marcatura industriale è un termine ampio che comprende diverse tecniche utilizzate per creare segni permanenti sulla superficie di un…

25 Marzo 2024

Esempi di Macro Excel scritte con VBA

I seguenti semplici esempi di macro di Excel sono state scritte utilizzando VBA  Tempo di lettura stimato: 3 minuti Esempio…

25 Marzo 2024