Studio di fattibilità: a cosa serve, quando farlo

Lo studio di fattibilità è il primo passo di un progetto tecnologico

In questa fase si analizzano i dati, le opportunità, e i rischi connessi alla realizzazione o adozione di una nuova tecnologia

Lo studio di fattibilità consiste in una fase di analisi puntuale di contesto, desiderata, criticità, dipendenze, costi, associati a un progetto di adozione o implementazione tecnologica.

Lo studio di fattibilità è talvolta indicato anche con l’acronimo PFTE (Progetto di Fattibilità Tecnica e Economica).

Sebbene lo studio di fattibilità sia spesso associato a contesti formali, inerenti appalti e concorsi di natura pubblica (Art. 14 D.P.R. n. 207/2010), questa fase progettuale è di vitale importanza per la realizzazione di progetti tecnologici strutturati.

Tralasciando gli ambiti di applicazione trasversali nei quali lo studio di fattibilità ha dignità di esistere, ci focalizzeremo qui nel contesto specifico della realizzazione di sistemi informatici.

La definizione

Possiamo definire lo studio di fattibilità come un processo analitico e metodologico che consente di valutare la possibilità e la convenienza di realizzare un determinato progetto o iniziativa di natura tecnologica.

Tale processo consiste nell’effettuare una serie di analisi e valutazioni tecniche, economiche, finanziarie, e di mercato, con lo scopo di determinare se il progetto può essere effettivamente realizzato, a quale costo, in quali tempi e con quali risorse, rispettandone comunque l’impatto in termini di vantaggio competitivo per l’azienda.

Lo studio di fattibilità si articola in diverse fasi, quali la definizione dei requisiti del progetto, la valutazione dei vincoli e delle opportunità, la stima dei costi e dei ricavi, la valutazione dei rischi e delle implicazioni progettuali, e la definizione delle possibili alternative.

Inoltre, lo studio di fattibilità è finalizzato a fornire al proponente del progetto una base di conoscenze per decisioni strategiche e di pianificazione contestuale o successiva alla realizzazione del progetto stesso.

Lo scopo nel contesto aziendale

Lo studio di fattibilità non va inteso come un requisito formale o un adempimento burocratico da smarcare. Lo studio di fattibilità ha finalità operativa e strettamente propedeutica alla buona riuscita delle fasi progettuali seguenti e derivanti dallo studio di fattibilità stesso.

In contesti particolarmente complessi, come sono tipicamente i progetti di evoluzione o adozione tecnologica in azienda, reperire e strutture le informazioni a supporto del processo decisionale non è banale. Qualora anche queste informazioni siano generate o reperite, esse dovranno essere rese fruibili dai decisori aziendali in modo chiaro e lineare.

I decision maker avranno anche necessità di supportare o argomentare le decisioni prese nel contesto progettuale, e pertanto lo studio di fattibilità potrebbe diventare un elemento cruciale per permettere ai responsabili progettuali di effettuare scelte con un grado di confidenza accettabile e con la consapevolezza di basarsi su dati oggettivi e misurabili.

Non è infrequente poi che le necessità propulsive di un progetto di trasformazione tecnologica nascano in contesti non direttamente attinenti alla sfera tecnologica dell’azienda. Ad esempio, il reparto marketing chiede implementazione di un software CRM. Tuttavia il requisito business non entra (e non deve entrare) nella definizione attuativa del progetto, le scelte architetturali e tecnologiche, e i costi o i rischi associati a queste scelte. Lo studio di fattibilità pertanto può fungere anche da elemento d’unione tra le esigenze aziendali e le necessità (o scelte) tecnologiche sottostanti la realizzazione del progetto.

Motivazioni e obiettivi dello studio di fattibilità

Siamo in grado a questo punto di definire le necessità e gli obiettivi che sottendono alla redazione di uno studio di fattibilità.

Lo stimolo nasce a fronte della necessità di valutare, prima ancora che avviare, un progetto di adozione o realizzazione tecnologica che per sua complessità, rischi, costi stimati, risorse umane e tecnologiche necessarie, requisiti di business, impatto sui processi aziendali, richieda una dettagliata analisi a supporto dei decision maker.

L’obiettivo dello studio di fattibilità si concretizza quindi:

• Nel fornire elementi analitici e oggettivi (data driven) a supporto dei decisori aziendali nell’intero iter progettuale. Sia quindi nelle fasi propedeutiche che in itinere al progetto stesso (ad esempio “Il progetto sta rispondendo ai requisiti forniti?” “L’investimento effettivo è allineato a quello stimato?”).
• Nel ridurre l’incertezza complessiva (e quindi il rischio) gravante sul progetto stesso. Lo studio di fattibilità diventa a tutti gli effetti uno strumento di mitigazione del rischio (risk management).
• Nel fornire supporto alla governance del progetto (top management, steering committee, ma anche stakeholders, investitori, soci aziendali…e ogni altro referente che per ovvie ragioni non avrebbe altrimenti modo di addentrarsi nei dettagli operativi del progetto).

Fasi componenti lo studio di fattibilità

Sebbene i progetti tecnologici siano declinabili in diverse accezioni, quali ad esempio:

• Realizzazione di sistemi applicativi da zero (“custom”).
• Realizzazione di infrastrutture informatiche (reti, spazi di archiviazione, spazi di lavoro).
• Diffusione di servizi tecnologici (accesso a sistemi virtuali, remoti, fisici, connessione tra dispositivi, Internet of Things).
• Modifica, implementazione, reingegnerizzazione di applicativi o prodotti esistenti.
• Aggiornamento o messa in sicurezza di sistemi e ambienti.
• Valutazioni di merito aziendale che sottendono a necessità tecnologiche (ad esempio “entrare nel mercato della realtà aumentata o dell’intelligenza artificiale”).
• Dotazioni aziendali (es. postazioni di lavoro remoto).

É possibile comunque individuare fasi specifiche dello studio di fattibilità comuni a qualsivoglia applicazione dello stesso:

1. Analisi della situazione attuale.
2. Descrizione del progetto ad alto livello.
3. Valutazione delle alternative.
4. Requisiti funzionali specifici.
5. Requisiti non funzionali.
6. Analisi dei rischi.
7. Analisi costi e benefici.
8. Change management.
9. Indicazioni per la messa in opera.

Analisi della situazione attuale

La fase di analisi della situazione attuale è quella nella quale trova origine la necessità del progetto evolutivo, tipicamente dal punto di vista aziendale, operativo.

In questa sezione troviamo:

• Descrizione delle attività aziendali attinenti il progetto (ad esempio ciclo di vendita, gestione logistica, attività di customer care, etc.).
• Descrizione della situazione attuale (mappa architetturale, diagramma sistemi e flussi informativi, attuale livello tecnologico e di automazione, soggetti e referenti aziendali).
• Descrizione e enumerazione delle principali problematiche o insight che hanno reso necessaria una valutazione di cambiamento o modifica.
• Genesi o cause del problema.
• Rilevanza della problematica riscontrata e urgenza della stessa.
• Identificazione di massima degli obiettivi di progetto o esigenze da soddisfare.
• Identificazione di eventuali vincoli noti ostativi o che sospingono la realizzazione del progetto (es. GDPR, regolamenti comunitari, necessità di reportistica istituzionale, eventi di natura geopolitica o sanitaria da affrontare, etc.).

Questa fase di raccolta di elementi noti è necessaria per rispondere al requisito dell’ autoconsistenza dello studio di fattibilità. Esso infatti dovrà essere un documento avente una propria dignità libero da dipendenze.

Descrizione del progetto ad alto livello

In questa sezione viene presentato il progetto nelle sue macro componenti, ovvero componenti di alto livello.

Restando nel contesto di uno studio di fattibilità propedeutico a un progetto tecnologico, si può trattare di:

• Fornire una descrizione testuale del progetto nelle sue componenti di massima (ad esempio “realizzazione di portale clienti fruibile da mobile e accessibile tramite username e password…”).
• Fornire una panoramica delle componenti impattate.
• Fornire prime evidenze di quanto già a disposizione dell’azienda e di quanto invece la stessa sia manchevole (es. “servizi cloud” o “dominio portaleclienti.org”).
• Fornire rispondenza tra gli obiettivi aziendali e le funzionalità tecnologiche esposte dal progetto.
• Collocare nel progetto le risorse e competenze necessarie (es. “sviluppatori app mobile”, “esperto cybersecurity”).
• Individuare sponsor aziendali e decision maker del progetto.
• Individuare e condividere eventuali requisiti di accettazione.

Questa sezione introduce il dominio progettuale e ne contestualizza il riferimento all’attività aziendale. Già da questa sezione si possono trarre le prime indicazioni utili e gli esperti della materia (“Subject Matter Experts” o SME) sono in grado di declinare alcune assunzioni sul progetto nella sua interezza.

Valutazione delle alternative

Lo studio di fattibilità presuppone la valutazione di diverse alternative progettuali, che possono insistere su:

• Acquisto di prodotti o soluzioni a mercato già esistenti.
• Costruzione di un prodotto ex novo.
• Lavorazione in economia interna.
• Lavorazione in outsourcing.
• Stima di diversi perimetri progettuali e declinazioni.
• Tipologia di sviluppo progettuale ipotizzato (waterfall, incrementale).
• Riutilizzo di processi, componenti, materiali esistenti in azienda.

In questa sezione è possibile fornire anche una valutazione di carattere oggettivo e/o quantitativo (supportata da evidenze numeriche) a riguardo della preferenza o opportunità di una o dell’altra soluzione o percorso. Tuttavia lo studio di fattibilità potrebbe anche limitarsi ad enumerare una serie di possibilità, lasciando poi la decisione finale ai decision maker deputati.

Lo scopo dell’analisi di fattibilità è quello di supportare un processo decisionale, non di sostituirsi ad esso.

Requisiti funzionali specifici

La sezione raccoglie i requisiti specifici espressi dagli stakeholder progettuali e dagli eventuali referenti operativi dell’azienda.

La definizione formale di requisito ci viene fornita da IEEE (Institute of Electrical and Electronics Engineers), nel documento IEEE 729-1983 “IEEE Standard Glossary of Software Engineering Terminology“:

1. Un requisito è la condizione o capacità necessaria all’utente per risolvere un problema o raggiungere un obiettivo.
2. Un requisito è la condizione o capacità che deve essere soddisfatta o posseduta da un sistema o da un componente del sistema per soddisfare un contratto, uno standard, una specifica o un altro documento imposto formalmente.

Da questa definizione deduciamo che il requisito non deve fornire elementi o suggestioni riguardanti la struttura dell’applicativo, progettazione delle componenti del software, o suggerimenti atti a affrontare una specifica tematica business. Questo in quanto si andrebbe a inquinare la neutralità del requisito che deve esprimere una necessità di un utente. Starà poi al team tecnico analizzare, comprendere e trasformare il requisito in una specifica tecnica.

Qualora, per determinate ragioni, si voglia comunque integrare la parte di requisiti funzionali con indicazioni di natura tecnica, il suggerimento è quello di trattarli in appendice o sezione separata così da mantenere intatta la gerarchia del documento per le successive analisi.

Requisiti non funzionali

I requisiti non funzionali non riguardano direttamente le funzionalità del sistema o del progetto, ma piuttosto, le proprietà, prestazioni, gli elementi di scalabilità, di sicurezza, di usabilità del progetto stesso.

I requisiti non funzionali stabiliscono non il “cosa” ma il “come” nello scopo di progetto.

Alcune tipologie di requisiti non funzionali da dettagliare all’interno dell’analisi di fattibilità possono essere:

• La velocità di risposta del sistema.
• La sicurezza dei dati.
• L’affidabilità del sistema.
• La disponibilità del sistema.
• La scalabilità del sistema.
• La compatibilità con altri sistemi e tecnologie.
• La facilità d’uso del sistema.
• La documentazione.
• La manutenibilità del sistema.

Requisiti del progetto: che livello di dettaglio?

La risposta non può essere univoca.

In linea di principio, l’esperienza sul campo ci dice che un maggior livello di dettaglio richiede anche in fase di redazione un maggiore coinvolgimento e approfondimento da parte degli stakeholder. Questo obbliga gli interessati a scendere nelle profondità dei desiderata e ad affrontarli con piglio critico e analitico. Il beneficio che si riflette nello studio di fattibilità è notevole e consente di avere un quadro più preciso e con indicazioni più chiare per quanto riguarda le criticità da affrontare.

Tuttavia la ricerca della massima completezza non deve diventare un elemento ostativo alla realizzazione dello studio di fattibilità o peggio un elemento scusante per giustificare eventuali ritardi.

Il metodo MoSCoW

Il metodo MoSCoW è una tecnica nata nel contesto della metodologia RAD (Rapid Application Development) e successivamente adottata estensivamente nella gestione d’impresa, business analysis e sviluppo del software secondo la filosofia Agile.

Secondo MoSCoW i requisiti vanno suddivisi in:

• Must: requisito obbligatorio la cui soddisfazione determina il successo della soluzione progettuale. Talvolta i requisiti MUST vengono anche indicati con un acronimo inverso: Minimum Usable SubseT, ossia il minimo sottoinsieme di funzionalità utilizzabile.
• Should: requisiti ad alta priorità che dovrebbe essere compreso nella soluzione.
• Could: requisito auspicabile e desiderabile ma non necessario. Potrebbe essere incluso nella soluzione finale.
• Won’t: requisito che viene recepito e classificato ma non sarà incluso nella release progettuale specifica.

Analisi dei rischi

Il rischio connesso a un progetto è dato dall’insieme degli elementi ed eventi in grado di causare pregiudizio alla sua realizzazione. Ad esempio:

• Impossibilità a realizzare il progetto per vincoli o limiti tecnici.
• Sforamento del budget.
• Time to market o comunque sforamento delle tempistiche progettuali.
• Mancata rispondenza ai requisiti business.
• Mancata rispondenza ai requisiti funzionali.
• Esposizione dell’azienda a rischi strutturali connessi oggettivamente al progetto stesso (es. un progetto fintech dovrà prevedere la gestione del rischio connesso al trattare denaro e fondi degli utenti).

Tale sezione ha lo scopo non solo di enumerare i possibili rischi, ma anche di individuare la rilevanza per ciascuno di essi ovvero la magnitudo comparata all’intero progetto.

Inoltre dovrà fornire elementi di risk mitigation e risk management, così da poter affrontare con un congruo grado di confidenza il verificarsi delle situazioni delineate.

Analisi dei costi e benefici

Chiamata anche “Analisi di impatto”, questa sezione deve fornire evidenza dei:

• Costi attesi del progetto.
  • Costi fissi.
  • Costi variabili.
  • Costi del personale e risorse.
  • Costi per tecnologie e impianti.
  • Costi per servizi.

O ancora:

• • Capex vs Opex.
  • Diretti vs Indiretti.
  • Fissi vs Variabili.
  • Interni vs Esterni.
• Benefici attesi del progetto.
  • Benefici economico/finanziari (esprimibili in forma di valori monetari).
  • Benefici misurabili ma non direttamente collegabili a un valore monetario puntuale (ad esempio efficacia dei processi, stabilità dei sistemi).
  • Benefici intangibili (possono essere valutati solo olisticamente, ad esempio benefici reputazionali, ambientali, sociali).
• Indici per l’analisi aziendale:
  • Indici finanziari.
  • Indici di risultato (es. KPI).

Change management

Questa sezione raccoglie indicazioni per la gestione della transizione dall’attuale stato dell’azienda (e dei suoi sistemi, processi, applicativi) alla nuova fase, idealizzabile al termine del progetto di cui l’analisi di fattibilità è espressione.

In questa sezione è possibile trovare riferimenti per:

• Definizione della strategia di programma.
• Analisi della volontà, attitudine, approccio dei destinatari del progetto finale.
• Configurazione e predisposizione degli strumenti per il loro uso iniziale.
• Misurazione degli obiettivi nella fase di transizione progettuale.
• Definizione di policy di migrazione e transizione da diversi applicativi, stati, sistemi, processi, con eventuali indicazioni per fasi intermedie e/o parallele.
• Definizione delle strategie di incentivo all’uso delle nuove tecnologie.

Indicazioni per la messa in opera

La sezione finale raccoglie una serie di indicazioni e suggerimenti atti a gestire e minimizzare le possibili problematiche emergenti nella realizzazione del progetto tecnologico.

In particolare questa sezione tratta:

• Indicazioni per la determinazione della tipologia di fornitore o servizio.
• Indicazioni per la gestione del progetto (project management).

In particolare la sezione riguardante la gestione del progetto può indirizzare i decision maker verso la scelta di diversi approcci metodologici, quali ad esempio:

• Sviluppo waterfall (il progetto viene sviluppato e rilasciato in una unica soluzione monolitica).
• Approccio Agile (il progetto è sviluppato in via incrementale, iterativo ed evolutivo, con frequenti interazioni con l’utente allo scopo di acquisire feedback utili per il miglioramento in corso d’opera).
• Approccio misto.

Il piano di progetto

Allegati allo studio di fattibilità troviamo anche il piano di progetto.

Il piano di progetto esplicita nel tempo lo sviluppo del progetto, le sue milestone, gli oggetti e obiettivi principali che vengono affrontanti sull’asse temporale.

Esso fornisce evidenza della pianificazione delle attività e quindi tempistiche e scadenze che dovranno essere rispettate e monitorate.

Il piano di progetto si può avvalere di diversi strumenti di rappresentazione:

• Diagramma WBS.
• Diagramma di Gantt.
• Diagramma PERT.

WBS

Acronimo di “Work Breakdown Structure” è la scomposizione grafica di un progetto nei suoi elementi fondanti. Consente di visualizzare i deliverable e il loro collegamento con il progetto generale.

La WBS è solitamente propedeutica alla realizzazione di altri strumenti di gestione quali il Gantt o il PERT.

Una rappresentazione della WBS è visibile a questo link.

GANTT

Così chiamato in onore del suo ideatore, Henry Laurence Gantt, che lo teorizzò nel 1917, è un diagramma che riporta un asse orizzontale suddiviso in unità temporali (giorni, settimane, mesi) e un asse verticale a rappresentazione delle mansioni o attività che costituiscono il progetto.

Tipicamente delle barre colorate, frecce, o altro tipo di indicatore grafico evidenzia il progredire delle attività.

Il diagramma di Gantt rimane uno degli strumenti più usati nella pianificazione progettuale ed è stato declinato in numerosi strumenti digitali che ne semplificano la creazione e gestione.

PERT

Il diagramma di PERT (Program Evaluation and Review Technique) è un metodo statistico per la determinazione dei tempi delle attività di un progetto, che viene rappresentato graficamente in forma di diagramma di un grafo.

I nodi del grafo rappresentano le singole attività progettuali. Gli archi che uniscono i singoli nodi rappresentano sia le relazioni esistenti tra gli stessi, e possono essere associati a attributi quali durata, risorsa, costo. Questo aiuta a identificare le attività critiche, ovvero quelle che hanno un impatto significativo sulla durata del progetto, e adottare strategie per gestirle in modo efficiente.

Il diagramma di PERT aiuta anche a mostrare la sequenza temporale delle attività del progetto e a identificare eventuali vincoli e dipendenze tra di loro.

Il diagramma di PERT può richiedere molteplici iterazioni per la realizzazione di un cammino ottimale che unisca inizio e fine progetto rispettandone i vincoli di tempo e costo.

Una rappresentazione del diagramma di PERT è visibile a questo link.

Studio di fattibilità: risorsa fondamentale

A questo punto siamo in grado di affermare con cognizione di causa che lo studio di fattibilità rappresenti davvero una solida superficie sulla quale poggiare le fondamenta di un progetto tecnologico di successo.

In Aziona utilizziamo lo studio di fattibilità come elemento fondante dei nostri progetti di adozione tecnologica.

Se sei interessato a saperne di più, contattaci!

Bibliografia

• “Sistemi Informativi, Lo studio di Fattibilità” Prof. M. Golfarelli.
• “Studio di fattibilità per sistemi informativi”, Prof. P. Atzeni.
• “Analisi di Fattibilità per l’Acquisizione delle Forniture ICT”, documento a beneficio della PA a cura di AgID.