Studio di Fattibilità ICT: guida completa (2 di 2)

In questo secondo articolo dedicato agli studi di fattibilità (qui la prima parte) proveremo a riassumere una serie di linee guida che possono essere utilizzate per la realizzazione dello SdF di un sistema informativo o di una infrastruttura informatica: in questo secondo approfondimento cercheremo di far luce sui contenuti principali delle sette sezioni in cui è solitamente suddiviso uno SdF che abbiamo introdotto nel corso della prima parte di questa guida.

Gli articoli sono stati realizzati prendendo come modello di riferimento le ultime due versioni del Manuale di Analisi di Fattibilita’ per l’Acquisizione delle Forniture ICT della Pubblica Amministrazione, rispettivamente redatte dal Centro Nazionale per l’Informatica nella Pubblica Amministrazione (CNIPA) il 4 febbraio 2009 e da Agenzia per l'Italia Digitale (AGID) il 14 maggio 2015.

1: Descrizione della situazione attuale

Questa fase è dedicata alla verifica, al completamento e alla formalizzazione di tutte le informazioni che dovrebbero essere già note e disponibili al momento dell'inizio della fase dello studio di fattibilità, in quanto raccolte nel corso della fase immediatamente precedente (analisi preliminare o pianificazione). Nello specifico, è opportuno disporre dei seguenti set di informazioni:

• Il contesto generale della situazione attuale, nota anche come as-is o status quo.
• La descrizione delle problematiche (o degli impulsi innovatori) che hanno determinato l'idea del progetto.
• La raccolta delle esigenze e delle aspettative del personale, se il progetto impatta l'operatività.
• La raccolta delle esigenze e delle aspettative degli utenti finali, se il progetto impatta il prodotto o servizio fornito e/o le sue modalità di fruizione.
• L'individuazione dei processi coinvolti dal progetto, con particolare attenzione agli aspetti non prettamente informatici (solitamente trascurati dagli stakeholder).
• L'identificazione dei vincoli (temporali, di budget, etc.) per lo sviluppo del progetto, con particolare riguardo alle decisioni già prese e non modificabili (elementi invarianti).

Sulla base di tutti i punti precedenti, che possiamo in gran parte attenderci come input da razionalizzare, l'output principale che è necessario produrre in questa fase è la definizione degli obiettivi del progetto.

Partendo da queste premesse è possibile ipotizzare un indice di questo tipo:

• Il contesto dello studio
  • Descrizione della situazione attuale in termini di servizi, organizzazione, tecnologie esistenti e già in uso.
  • Descrizione delle esigenze e necessità attuali che hanno portato all'ipotesi progettuale.
• Descrizione della problematica
  • Descrizione e rilevanza di ciascun problema e/o opportunità riscontrabile nella situazione attuale.
  • Esigenze da soddisfare rispetto agli utenti interni (operativi) ed esterni (clienti/fruitori).
• Descrizione del sistema informativo attuale (as-is)
  • Individuazione e mappatura dei processi attuali (as-is) relativi alle aree di pertinenza del progetto.
  • Individuazione e mappatura dei flussi informativi attuali (as-is) relativi alle aree di pertinenza del progetto.
  • Individuazione e mappatura della struttura organizzativa e dell'utenza coinvolta (as-is) nelle aree di pertinenza del progetto.
• Misurazione della situazione attuale (as-is)
  • Analisi del livello di automazione attuale.
  • Individuazione dei fenomeni che costituiscono le cause del problema e relative aree di impatto.
  • Individuazione delle metriche utilizzabili per poter rappresentare i fenomeni critici e la loro evoluzione nel corso del tempo.
  • Utilizzo delle metriche individuate per misurare la situazione attuale.
• Identificazione dei vincoli
  • Vincoli di natura legale/normativo/procedurale: quadro normativo e procedurale di riferimento
  • Vincoli di natura temporale e di budget: analisi dei tempi e dei costi.
  • Vincoli legati alle decisioni non modificabili: individuazione degli elementi invarianti.
  • Altri vincoli: individuazione di eventuali vincoli ulteriori (organizzativi, tecnologici, etc.)
• Definizione degli obiettivi del progetto

Si tratta ovviamente di un modello che non va preso alla lettera, ma adattato alle proprie esigenze funzionali e organizzative, nonché al tipo di studio di fattibilità richiesto: alcune sezioni possono essere più o meno importanti di altre o non essere necessarie a seconda dello scenario di riferimento e della tipologia di progetto da analizzare.

2: Progetto di massima della soluzione proposta

Questa fase è dedicata alla redazione del progetto di massima relativo alla soluzione proposta: il compito principale di questo elaborato è quello di raccontare il progetto al fine di verificarne l'effettiva fattibilità: si tratta ovviamente di una verifica di alto livello, quindi priva di dettagli tecnici o implementativi.

Il documento che è opportuno produrre dovrebbe contenere i seguenti punti:

• Definizione dei requisiti, ovvero delle condizioni essenziali da soddisfare;
• Specifiche generali, ovvero una descrizione delle caratteristiche o proprietà che il sistema dovrà avere per poter rispondere ai requisiti individuati in precedenza.
• Modalità di realizzazione, ovvero una sintesi delle varie possibilità alternative a disposizione che consentano di ottenere un risultato compatibile con le specifiche generali individuate in precedenza. Nello specifico, le possibilità alternative possono includere:
  • Sistemi eventualmente già disponibili localmente o presso altri sistemi informativi di proprietà della stessa organizzazione o comunque utilzzabili a costo zero (reuse).
  • Sistemi già disponibili sul mercato, possibilmente insieme a una valutazione di massima sui costi/benefici rispetto alla realizzazione ex-novo (make or buy).
  • Sistemi che è possibile realizzare internamente (insourcing), possibilmente insieme a una valutazione di massima sui costi/benefici rispetto all'affidamento esterno.
  • Sistemi che è possibile affidare all'esterno (outsourcing), possibilmente insieme a una valutazione di massima sui costi/benefici rispetto alla realizzazione interna.
• Rilascio e manutenzione, ovvero una sintesi delle attività che sarà necessario svolgere per la messa in produzione, avvio, esercizio e manutenzione del nuovo sistema.
• Formazione operatori, ovvero una sintesi delle attività che sarà necessario svolgere per la formazione degli operatori interni (procedure, corsi, training on the job, verifiche, etc.)
• Assistenza utenti, ovvero una sintesi delle attività che sarà necessario svolgere per garantire la necessaria assistenza agli utenti / fruitori esterni (CRM, manuali, etc.).

In questa fase è fondamentale il ricorso alle interviste, che saranno funzionali alla raccolta dei feedback necessari per poter dimensionare in modo corretto l'impatto del nuovo sistema sulla struttura organizzativa attuale. Particolare attenzione va posta negli ambiti non prettamente informatici, che solitamente vengono trascurati o non correttamente valutati dagli stakeholder al momento della definizione del progetto proprio perché si tende a concentrare l'attenzione sugli aspetti IT; l'esperienza insegna che i progetti informatici hanno spesso una serie di impatti ulteriori che esulano dall'infrastruttura di riferimento e che possono determinare un incremento notevole dei tempi e costi originariamente previsti, pregiudicando in molti casi l'effettiva sostenibilità del progetto.

Partendo dalle premesse di cui sopra è possibile ipotizzare un indice di questo tipo:

• Requisiti della soluzione
  • Interventi necessari sulle procedure e/o sulle normative esistenti
  • Requisiti dell'architettura hardware (sicurezza, protezione dei dati, bare-metal backup, disaster recovery, etc.)
  • Requisiti dell'architettura software (sicurezza, protezione dei dati, backup, etc.)
  • Requisiti relativi alle modalità di lavoro (compatibilità con i processi esistenti, accessibilità, etc.)
  • Altri requisiti (qualità, compliance, ISO, etc.)
• Specifiche generali del sistema
  • Specifiche hardware e infrastrutturali
    • Architettura dell'infrastruttura IT (con esame e valutazione delle eventuali alternative)
    • Ambiente di sviluppo (con esame e valutazione delle eventuali alternative)
    • Ambiente di produzione (con esame e valutazione delle eventuali alternative)
  • Specifiche software e applicative
    • Architettura dati (con esame e valutazione delle eventuali alternative)
    • Architettura applicativa (con esame e valutazione delle eventuali alternative)
    • Interfaccia utente
• Modalità di Realizzazione
  • Descrizione delle alternative individuate (reuse, make or buy, outsourcing, insourcing).
• Modalità di Rilascio e Manutenzione
• Formazione operatori
• Assistenza utenti

Anche in questo caso il modello può essere semplificato sulla base dello scenario di riferimento: l'indice riportato prevede un progetto avente prerequisiti che esulano dal contesto prettamente IT e un impatto rilevante a livello sia infrastrutturale che applicativo, eventualità che non sempre si verifica se il sistema informativo dell'organizzazione è basato su una architettura orientata all'utilizzo combinato e modulare di servizi autonomi, interoperabili tramite API e monofunzionali (Service-Oriented Architecture, microservices, etc.).

3: Analisi dei Rischi

Questa sezione riveste un ruolo fondamentale per la valutazione della sostenibilità del progetto, in quanto ha lo scopo di definire i principali rischi (di natura economica, temporale, tecnologica, normativa, di sicurezza, etc.) connessi sia allo sviluppo della soluzione proposta (to-be) che all'avvicendamento della stessa con il sistema esistente (as-is). Si tratta dunque di una analisi multidisciplinare, in quanto necessita di una raccolta di informazioni relativa non soltanto agli aspetti tecnologici e informatici ma anche di natura legale, normativa, amministrativa e gestionale: per questo motivo è nuovamente fondamentale il ricorso a interviste puntuali con il personale operativo di riferimento.

E' importante comprendere che l'output di questa fase non deve limitarsi alla semplice individuazione dei principali rischi, ma anche alla produzione di opportune strategie di gestione degli stessi, sotto forma di contromisure (remediation). Si tratta dunque di un'attività potenzialmente molto onerosa in termini di tempo, impegno e denaro, ma assolutamente fondamentale per il successo di un progetto: per questo motivo è opportuno che l'analisi sia condotta secondo un set di regole precise. In Italia, la gestione dei rischi a livello professionale è solitamente condotta mediante l'adozione delle linee guida proposte dalla norma ISO 31000:2018 (Risk management - Principles and guidelines) e applicando le tecniche descritte nello standard ISO/IEC 31010:2009 (Risk management – Risk assessment techniques).

Sulla base di queste premesse, è possibile ipotizzare un indice di questo tipo:

• Risk Analysis (individuazione dei rischi)
  • Individuazione delle tipologie di rischio (normativo, tecnologico, economico, esposizione, etc.)
  • Registro dei rischi
• Risk Assessment (valutazione e quantificazione dei rischi)
  • Probabilità di accadimento
  • Impatto
• Risk Management (strategie di gestione del rischio)
  • Graduatoria dei rischi (maggiore esposizione)
  • Matrice di gestione del rischio
  • Individuazione delle contromisure

A differenza delle sezioni precedenti, in cui il grado di approfondimento del modello dipende in massima parte dallo scenario di riferimento, una corretta analisi dei rischi richiede necessariamente un approccio rigoroso e altamente formalizzato: per questo motivo si consiglia lo sviluppo integrale del modello sopra illustrato a prescindere dalla tipologia di progetto, integrando i singoli punti con le eventuali specificità descritte dalle summenzionate ISO per i vari ambiti di intervento.

4: Modalità di implementazione

In questa sezione del documento dovranno essere descritte le scelte relative alla segmentazione del progetto (realizzazione in soluzione unica, incrementale, evolutiva) e le considerazioni che hanno portato alle scelte medesime (basate sui parametri di complessità e incertezza del progetto e del tempo di realizzazione a disposizione). Inoltre verranno riportate le acquisizioni e le realizzazioni previste che rappresentano la base per la successiva stima dei costi e costituiscono un punto di riferimento essenziale per la stesura di un eventuale successivo capitolato di gara.

Infine verrà riportato il piano di massima del progetto a cui la programmazione puntuale delle attività si dovrà adeguare ( piano dei rilasci, punti di controllo e di decisione, piano di massima delle attività che evidenzi le scadenze fondamentali e le principali relazioni di dipendenza tra le macroattività).

In conseguenza di quanto detto, i contenuti di questa sezione possono essere organizzati all'interno della seguente struttura tipo:

• Segmentazione del progetto
• Specifiche globali del sistema informativo (to-be)
• Riepilogo delle acquisizioni e realizzazioni previste
• Piano di massima del progetto
  • Piano dei rilasci (milestone o sprint)
  • Punti di controllo (sprint review)
  • Strumenti di project management (WBS, Pert, Gantt, etc.)
• Definizione del modello organizzativo

Il paragrafo relativo al piano di massima del progetto, così come le sue sottosezioni, è pesantemente influenzato dal framework di processo utilizzato: un modello agile prevederà una serie di sprint iterativi aventi durata predeterminata (time-boxed) e punti di controllo costanti e frequenti (sprint review), laddove un modello waterfall prevederà il rilascio di un certo numero di milestone definite all'interno di una timeline predeterminata; lo stesso discorso vale per gli strumenti di project management: la metodologia agile determina gli avanzamenti di progetto facendo uso di strumenti di supporto iterativi contraddistinti da un elevato livello di variabilità (product backlog, kanban board, user stories), laddove un approccio di tipo tradizionale prevederà un diagramma rappresentativo delle componenti temporali e funzionali (es. Gantt).

5. Analisi di impatto

L'analisi di impatto, anche nota come analisi costi/benefici o valutazione della bontà degli investimenti, è una componente fondamentale dello studio di fattibilità per due motivi principali:

• Fornisce agli stakeholder una giustificazione economica agli investimenti necessari per realizzare il progetto.
• Fornisce i dati necessari per effettuare una serie di scelte strategiche, tra cui la valutazione delle varie possibili alternative ipotizzate nel corso della stesura del progetto di massima (cfr. sezione 2).

La stima dei costi viene generalmente realizzata mediante un documento ad-hoc - solitamente in formato spreadsheet - che prevede le seguenti componenti fondamentali:

• un elenco delle principali voci di costo;
• l'adozione di un criterio per la valutazione delle stime (possibilmente da esplicitare, avendo cura di citare le fonti e/o i riferimenti di mercato presi a indice);
• il calcolo delle stime dei costi di investimento delle singole voci (una tantum);
• il calcolo delle stime dei costi di esercizio delle singole voci (con cadenza periodica, ad es. annuale);

Una volta determinati i costi è possibile integrare lo spreadsheet inserendo i benefici che ci si propone di ottenere a seguito della realizzazione del progetto, dichiarandone i valori attesi; i benefici economici, ovvero immediatamente monetizzabili, andranno calcolati utilizzando i medesimi criteri utilizzati per il calcolo dei costi; i benefici non monetizzabili potranno essere rappresentati isolando le varie componenti (riduzione dei tempi di erogazione, riduzione dei reclami e/o delle contestazioni, maggiore efficientamento dei processi produttivi, etc.) e dando un valore economico a queste ultime, avendo cura anche in questo caso di indicare i parametri di misura e/o gli indici utilizzati per effettuare tale misurazione.

Per riportare contenuti di questa sezione è possibile fare riferimento alla seguente struttura tipo:

• Analisi dei costi
  • Criteri utilizzati per il calcolo
  • Elenco delle voci di costo
  • Calcolo dei costi di investimento
  • Calcolo dei costi di esercizio
• Analisi dei benefici
  • Calcolo dei benefici monetizzabili
  • Calcolo dei benefici non monetizzabili
• Comparazione costi/benefici

A corredo della comparazione costi/benefici è possibile aggiungere una sere di documenti di valutazione ulteriore, come l'analisi di impatto e gli indici finanziari e/o di risultato, qualora si dispongano delle necessarie informazioni amministrativo/contabili che consentano di calcolarli.

6. Gestione del cambiamento

Gli aspetti legati al change management, ovvero alla gestione dei cambiamenti all'interno dell'organizzazione, è un altro aspetto spesso sottovalutato dagli stakeholder al momento della definizione iniziale di un progetto IT. In estrema sintesi, questa sezione dello SdF ha il compito di descrivere le azioni e gli interventi da realizzare affinché l’introduzione del nuovo sistema possa essere correttamente supportata dall'organizzazione, prevedendo i cambiamenti necessari allo status quo. Ancora una volta è fondamentale porre particolare importanza ai cambiamenti non informatici, poiché sono quelli ad essere maggiormente sottovalutati nell'ambito di un percorso di valutazione della fattibilità di un progetto IT, e - di conseguenza - al ruolo chiave svolto dalle interviste e dalla raccolta dei feedback da parte dei ruoli e delle funzioni aziendali che potrebbero essere state escluse dalle analisi preliminari.

I contenuti di questa sezione andrebbero riportati secondo la seguente struttura tipo:

• Definizione della strategia di programma
• Analisi dei destinatari e stakeholders
• Predisposizione degli strumenti
• Definizione delle azioni per realizzare gli obiettivi di progetto
• Definizione delle strategie di incentivazione all’uso

7. Indicazioni operative

La sezione conclusiva del documento è generalmente dedicata a una serie di raccomandazioni che è opportuno considerare nell'esecuzione delle fasi immediatamente successive allo studio di fattibilità: capitolato, bando di gara, valutazione delle offerte, ingaggio dei fornitori, aspetti contrattuali, etc.; si tratta di un'attività che è opportuno condurre con le funzioni amministrative (es. ufficio gare), gestionali (es. contabilità) e/o amministrative (compliance, ufficio contratti, ufficio privacy) che si occupano dei relativi aspetti che è opportuno tenere presenti.

I contenuti di questa sezione andrebbero riportati secondo la seguente struttura tipo:

• Indicazioni per la stesura del capitolato
• Istruzioni per la corretta valutazione dei fornitori
• Istruzioni per la corretta valutazione delle offerte
• Varie ed eventuali

Anche in questo caso, il livello di dettaglio di questa fase dipende soprattutto dal quadro di riferimento in cui si iscrive il progetto: ad esempio, è del tutto evidente che un progetto che preveda un forte coinvolgimento di terze parti (outsourcing) dovrà prestare particolare attenzione agli aspetti contrattualistici e normativi che legano l'organizzazione ai rapporti con i fornitori e alla corretta valutazione dei capitolati, laddove un progetto sviluppato internamente non avrà queste necessità.

Conclusioni

Per il momento è tutto:  ci auguriamo che questo approfondimento possa essere utile a quanti hanno necessità di realizzare uno studio di fattibilità per la propria azienda o organizzazione. Per qualsiasi domanda, richiesta di informazioni o approfondimenti ulteriori, è possibile lasciare un commento utilizzando l'apposita sezione in fondo alla pagina.

Print Friendly & PDF Download