Linee Guida per la realizzazione di Studi di Fattibilità

7. DETTAGLIO DELLE SEZIONI DELLO STUDIO DI FATTIBILITA'

7.1 La situazione attuale

Il contesto dello studio

Questa parte dello studio di fattibilità consiste in un documento testuale che colloca il progetto che viene analizzato attraverso lo studio di fattibilità nel contesto complessivo della strategia di sviluppo del sistema informativo dell'amministrazione.

Tutte le informazioni contenute in questo punto sono di regola già presenti al momento della produzione dello studio di fattibilità, in genere anche in maniera formalizzata, in particolare nei documenti di pianificazione. Il compito dello studio di fattibilità è quindi quello di puntualizzare gli elementi specifici relativi al progetto in esame e di formalizzare il raccordo tra l'iniziativa prevista e il quadro generale.

 

In questa parte si riprenderà per sommi capi, ma con una specifica attenzione alle tematiche trattate dal progetto, la visione strategica dell'amministrazione in termini di servizi e organizzazione e utilizzo della tecnologia, visione strategica normalmente già esplicitata all'interno della pianificazione triennale.

La visione di servizio tratteggia lo stato ottimale che ci si propone di raggiungere in termini di erogazione dei servizi e di scelte organizzative di base. La visione tecnologica illustra le scelte di fondo dell'amministrazione in termini di utilizzo delle tecnologie informatiche e telematiche e lo scenario architetturale che si intende perseguire a livello globale.

 

Un altro elemento importante, ai fini della decisione che dovrà essere presa sull'investimento, riguarda la necessità di ripercorrere sommariamente il percorso che ha portato alla individuazione del progetto e alla decisione di effettuare lo studio di fattibilità.

In particolare sarà necessario evidenziare gli eventi, sia esterni che interni che hanno avuto incidenza sulla definizione del progetto. Tra gli eventi esterni ci potranno essere le modifiche legislative ed i loro decreti attuativi, gli indirizzi governativi e comunitari, le modifiche alla missione istituzionale e gli accorpamenti/scorpori di responsabilità ecc. Tra gli eventi interni ci saranno gli atti ufficiali dell'amministrazione e le indicazioni e le scelte, inerenti alla tematica in oggetto, espresse dai massimi livelli di responsabilità dell'amministrazione.

Una particolare attenzione dovrà infine essere dedicata alle considerazioni e alle motivazioni che hanno portato alla decisione di effettuare uno studio di fattibilità, motivazioni che portano alla sottolineatura di eventuali aspetti del progetto da sottoporre, attraverso lo studio, ad un esame particolare.

Nello specifico contesto della pubblica amministrazione è poi importante anche ricapitolare lo stato dei rapporti avuti sul problema in esame con l'Autorità e, in particolare, evidenziare come il progetto esaminato si collochi all'interno dello scenario definito dalla pianificazione triennale dell'amministrazione.

 

Descrizione della problematica

Questa parte dello studio di fattibilità consiste in un documento testuale che identifica la problematica da cui scaturisce il progetto, ne indica la rilevanza ne delinea esattamente i confini.

Tutte le informazioni contenute in questo punto sono di regola già presenti al momento della produzione dello studio di fattibilità, anche se spesso in maniera non formalizzata. Il compito dello studio di fattibilità è quindi quello di verificare, completare, sistematizzare e formalizzare le informazioni.

 

L'esigenza fondamentale a cui bisogna rispondere è la necessità di arrivare ad una descrizione esauriente del problema/opportunità che il progetto intende contribuire a risolvere o conseguire. Per comprendere esattamente il problema nella sua generalità è importante effettuare una scomposizione del problema in sotto-problemi ed è sempre necessario tracciarne esattamente i confini, allo scopo di delimitare l'ambito delle iniziative da intraprendere.

Le coordinate da seguire nella descrizione della problematica sono naturalmente i tempi, i costi e quantità e qualità dei prodotti/servizi erogati.

 

Altri elementi da chiarire riguardano la criticità della problematica trattata e del progetto collegato, ovvero quanto la valutazione di quanto la realizzazione o meno del progetto possa influire sulle attività stesse dell'amministrazione, e la sua urgenza.

Una classificazione di riferimento può essere quella di:

  • progetto obbligato, ossia indispensabile per rispondere ad obblighi legislativi e normativi;
  • progetto di importanza strategica, ossia collegato alle scelte strategiche relative alla missione istituzionale, individuate dal più alto livello dell'amministrazione;
  • progetto di elevata importanza per l'amministrazione, ossia comunque legato ad importanti obiettivi di miglioramento dell'efficacia operativa e/o a necessità di conseguire risultati in termini di economicità.

L'urgenza è definita univocamente nel caso di progetto obbligato, che in genere impone anche precise scadenze temporali, mentre sarà da valutare qualitativamente negli altri casi.

Contestualmente andranno esplicitate le conseguenze della mancata o ritardata realizzazione, che possono essere sia di tipo legale-normativo, sia di tipo operativo (impossibilità di fare qualcosa, permanere di inefficienze..), sia legate a perdita di opportunità.

 

E' infine essenziale che nella descrizione della problematica vi sia una specificazione delle esigenze e delle attese dell'utenza. A questo livello di approfondimento le esigenze possono essere espresse in forma testuale, secondo il punto di vista ed il linguaggio dell'utente, in termini per lo più qualitativi e difficilmente misurabili.

La formalizzazione delle esigenze dell'utenza è comunque importante perché rappresenta un ancoraggio forte alla concretezza dei processi operativi e alla visione dell'utenza sulla problematica, ancoraggio che è fondamentale per la costruzione di sistemi che possano effettivamente venir proficuamente utilizzati.

L'utente più significativo è naturalmente l'utente finale, ossia il fruitore definitivo del prodotto/servizio, che, nella maggior parte dei casi, sarà esterno all'amministrazione. Essendo abbastanza rari i casi in cui una amministrazione abbia attivato degli strumenti e delle modalità specifiche per la consultazione dell'utenza esterna in ordine alle sua soddisfazione e alla raccolta delle esigenze, ne consegue che questa formulazione di esigenze potrà essere di fatto solo una interpretazione. Ferma restando l'utilità della consultazione reale dell'utenza esterna, di cui si auspica quindi l'avvio, perché l'interpretazione sia il più possibile fedele alla realtà diventa necessaria la consultazione delle strutture dell'amministrazione che gestiscono i rapporti con gli utenti.

E' significativa anche la raccolta delle esigenze degli utenti interni, ossia del personale chiamato a svolgere gli adempimenti operativi del processo in esame. Questa raccolta di esigenze consente di raccogliere il notevole patrimonio, in genere nascosto, di esperienza, di competenza e di riflessione che si è accumulato negli anni all'interno di ogni amministrazione.

Queste esigenze e aspettative, sia interne che esterne, dovrebbero essere già presenti al momento dello studio di fattibilità in quanto dovrebbero essere comunemente raccolte nel corso della normale attività operativa. Il compito dello studio di fattibilità è quindi un compito di completamento e di formalizzazione, che comunque non può prescindere da un certo numero di interviste mirate a responsabili e rappresentanti del personale operativo, principalmente allo scopo di rendere esplicito ciò che spesso è solo implicito.

Descrizione della situazione attuale

Questa parte dello studio di fattibilità consiste nella individuazione e rappresentazione dei processi coinvolti nell'area di intervento, con specifica attenzione alla individuazione e rappresentazione dei flussi informativi, nella individuazione e rappresentazione della struttura organizzativa e dell'utenza coinvolta e nella descrizione sommaria dell'attuale livello di automazione.

Si tratta quindi di semplici elementi descrittivi che non rappresentano ancora una specifica analisi e diagnosi dei processi di servizio ma che ne costituiscono la base di conoscenza indispensabile.

Per questa sezione è importante che, accanto alla parte testuale, si utilizzino tecniche di rappresentazione più rigorose e ci si serva quindi di modelli per la rappresentazione dei processi, di matrici di relazione e degli strumenti normalmente utilizzati per la rappresentazione dei sistemi informatici.

 

Qualora lo studio di fattibilità nasca da un intervento strutturato di reingegnerizzazione del processo, tutte queste informazioni sono già presenti in forma organizzata e coerente per cui è sufficiente un rimando alla documentazione. Anche in assenza di una attività di Business Process Reengineering, tutte queste informazioni dovrebbero comunque essere già presenti in quanto normalmente utilizzate nella quotidiana attività di organizzazione e gestione delle attività correnti ed anche in questo caso si pone allo studio di fattibilità solo un problema di verifica, completamento e formalizzazione.

Possono peraltro anche porsi casi in cui questa conoscenza manchi del tutto. Questa situazione significa che nell'amministrazione si hanno processi di servizio non rilevati (per assenza della nozione di processo, per la presenza di processi incoerenti o frammentati) e si utilizzano sistemi informatici non documentati. Lo studio di fattibilità si deve quindi in qualche maniera far carico di quest'attività di ricostruzione della conoscenza, attività pesante e di per sé impropria nel contesto dello studio. Si tratta peraltro di un recupero essenziale di una situazione pregressa carente che costruisce un patrimonio conoscitivo e documentativo riusabile. Come già accennato in precedenza, questa attività può essere svolta direttamente dal gruppo di lavoro o essere affidata ad una linea parallela e separata di attività.

 

E' da sottolineare che tutta questa sezione ha lo scopo di chiarire il quadro della situazione attuale allo scopo di descrivere sinteticamente gli elementi essenziali su cui si è sviluppata la successiva analisi e diagnosi che ha portato alla definizione degli obiettivi del progetto.

Non hanno quindi senso pletoriche ed ingombranti descrizioni testuali onnicomprensive, per esempio ottenute tramite l'inserimento completo ed indistinto di leggi, normative, atti interni ecc. che servono solo ad appesantire il documento senza offrire nessun valore aggiunto. E' al contrario utile centrare l'attenzione sugli elementi di criticità, graduando anche il livello di dettaglio in funzione degli effettivi problemi e finalità in esame, dando cioè più spazio alle parti critiche.

 

Per quanto riguarda la rappresentazione dei processi la letteratura e l'esperienza mettono a disposizione delle amministrazioni una pluralità di modelli di rappresentazione.

Tra questi modelli si annoverano:

  • le carte di processo (process chart) o i diagrammi di flusso (flow chart), derivanti dalle necessità di analisi organizzativa;
  • i DFD (diagrammi del flusso dei dati, data flow diagram) o gli schemi SADT, con tutte le successive evoluzioni del modello, derivanti direttamente dalle necessità del ciclo di sviluppo del software;
  • altri modelli, come gli Action Diagram Workflow, più direttamente mirati alla evidenza dei rapporti cliente-fornitore o di altri aspetti specifici dei processi.

 

Rimandando alla "Guida operativa" una descrizione dei vari modelli e delle loro caratteristiche, si evidenzia qui che l'Autorità non intende in questo contesto indicare un modello obbligatorio o preferenziale, anche alla luce del fatto che ognuno dei modelli può essere considerato preferibile al variare dei contesti e della problematica principale.

 

Per quanto riguarda l'individuazione dell'utenza impattata e di come si distribuisce sulle varie strutture organizzative, possono essere utili sia un funzionigramma dell'amministrazione, sia matrici di relazione tra processi e strutture organizzative, che evidenzino anche il livello di responsabilità nel processo delle varie strutture (ad. es. decisore, operativo, controllo) ed il livello di coinvolgimento (forte, debole).

 

Per quanto riguarda la descrizione dell'attuale sistema di automazione è opportuno ricorrere alle consuete notazioni per la rappresentazione dell'architettura applicativa (sottosistemi applicativi e loro relazioni) e dell'architettura tecnologica (sistemi elaborativi e collegamenti), corredando gli schemi con le necessarie informazioni di dettaglio.

 

E' nella maggior parte dei casi particolarmente utile corredare tutto questo insieme di informazioni di ulteriori matrici di relazione tra informazioni, basi di dati, processi, applicazioni, strutture organizzative.

Analisi e diagnosi della situazione attuale

Questa parte dello studio di fattibilità consiste nell'esplicitazione dei risultati dell'attività di analisi e diagnosi dei processi impattati dal progetto, risultati che porteranno alla individuazione e quantificazione degli obiettivi del progetto.

E' quindi necessario approfondire la precedente descrizione del problema, andando ad individuare le varie cause del problema, collocare correttamente le cause sulle varie componenti del processo, individuare delle metriche atte a misurare i fenomeni che costituiscono le cause del problema, raccogliere le misure in riferimento alle metriche individuate.

Andranno poi approfondite e dettagliate le esigenze dell'utenza e si dovranno pertanto individuare i fenomeni le cui insufficienze portano all'insoddisfazione dell'utenza, collocare i fenomeni sulle varie componenti del processo, individuare le metriche e raccogliere le misure.

 

Tutte queste informazioni dovrebbero essere già presenti al momento della produzione dello studio di fattibilità.

Esse costituiscono una parte essenziale delle risultanze di una attività di Business Process Reengineering e sono quindi ovviamente presenti in forma completa se si è svolta questa attività. Esse possono altrimenti rappresentare i risultati di una osservazione certamente prevista se si è attivato un sistema di qualità, volto al miglioramento continuo.

In questi casi questa sezione dello studio di fattibilità si risolve in un opportuno rimando.

In assenza di questi prerequisiti, queste informazioni sono comunque quasi sempre presenti, in forma magari implicita o parziale, perché derivano dall'attività spesso informale che ha portato all'individuazione del progetto.

In questo caso il compito dello studio di fattibilità è quello di completare e formalizzare, che in concreto significa:

  • individuare e descrivere i vari specifici fenomeni su cui si vuole intervenire, che costituiscono la causa del problema o del mancato raggiungimento di una opportunità;
  • collocare questi fenomeni sulle varie componenti del processo, individuando in particolare quelli che attengono alla risorsa informazione e quindi al sistema informativo, che andranno risolti dal progetto informatico, e quelli che attengono ad altri aspetti (flusso del processo, organizzazione, personale, risorse ecc.) e che quindi andranno risolti con altre iniziative diverse e complementari dal progetto informatico;
  • misurare questi fenomeni, allo scopo di poter successivamente esprimere obiettivi quantitativi per il progetto. Come ripetutamente affermato queste misure riguarderanno sempre costi, tempi e misure di qualità del prodotto/servizio finale o di prodotti/servizi intermedi.

 

Riprendendo quanto già esplicitato in precedenza, è opportuno sottolineare che qualora gran parte del problema e quindi dell'intervento necessario si collochi su aspetti non informativi, sarà necessario avviare un programma di cambiamento che contempli, oltre allo specifico progetto informatico, altri contestuali progetti di cambiamento, integrati e coerenti, che intervengono sulle altre componenti. E' questo il caso tipico che è opportuno far scaturire da un intervento strutturato di reingegnerizzazione dei processi.

Se invece il progetto informatico è il solo intervento progettuale previsto, questo deve significare che c'è una sostanziale invarianza delle altre componenti, su cui è necessario intervenire soltanto allo scopo di renderle coerenti con il nuovo scenario che verrà prodotto dall'intervento sul sistema informativo (il vero e proprio tradizionale "impatto organizzativo"). Questa sezione del documento serve anche a motivare adeguatamente questa scelta.

 

Non è compito di questo documento quello di descrivere approcci, metodi e tecniche per la reingegnerizzazione globale dei processi di servizio. Tra di essi figurano approcci e metodi basati sull'esame della catena del valore (Activity Based Costing), sia approcci e metodi orientati all'esame dei fattori critici di successo, sia approcci e metodi derivanti dall'approccio TQM (approccio totale alla qualità, Total Quality Management), sia approcci e metodi basati sull'utilizzo sistematico del confronto con altre situazioni (Benchmarking).

 

Per quanto riguarda invece le tecniche utilizzabili per l'individuazione e la quantificazione dei fenomeni che sono causa del problema e per il dettaglio delle esigenze utente, si rimanda alla "Guida operativa" l'illustrazione di due tra le tecniche più diffuse quali le tecniche di Problem Solving di Ichikawa (la lisca di pesce, fish-bone) e la tecnica del QFD (Quality Function Deployment). Anche rispetto a queste problematiche peraltro l'Autorità non intende in questo documento indicare un modello obbligatorio o preferenziale.

 

Quello che è comunque necessario è evidenziare i fenomeni su cui intervenire che attengono a:

  • la natura e le caratteristiche del prodotto/servizio erogato;
  • l'andamento del flusso operativo del processo;
  • la quantità e la qualità delle risorse (non informative) utilizzate;
  • le strutture organizzative coinvolte e la distribuzione delle responsabilità;
  • la distribuzione e le caratteristiche professionali del personale addetto;
  • la logistica;
  • eventuali altri aspetti del processo.

 

Accanto a questi andranno evidenziati gli specifici aspetti informativi in termini di efficacia, efficienza, completezza, correttezza, disponibilità e tempestività dell'informazione resa disponibile dal sistema.

Tutti questi aspetti vanno ovviamente visti in relazione alle varie componenti del sistema informatico e presentano caratteristiche differenti in caso di progetto teso alla realizzazione di un sistema applicativo, di una infrastruttura tecnologica o di altra tipologia di progetto. Si rimanda pertanto al capitolo di questo documento che tratta le specifiche tipologie di progetto per una trattazione ulteriore di questa tematica.

Identificazione dei vincoli

Questa parte dello studio di fattibilità consiste nell'esplicitazione dei vincoli al progetto.

I vincoli sono possono essere sia di tipo giuridico-normativo, sia di natura temporale, sia di altra natura, sostanzialmente di carattere economico e organizzativo.

Tutto ciò che viene acquisito come vincolo deve naturalmente essere coerente con quanto definito in precedenza in termini di problematiche, ossia i vincoli non possono essere tali da impedire alla radice la risoluzione di quanto evidenziato.

Questa sezione dello studio è un documento testuale.

 

I vincoli giuridico-normativi derivano dall'esame delle leggi e delle norme esistenti che regolano l'area oggetto di intervento principalmente in termini di definizione dei prodotti/servizi, delle responsabilità, dei procedimenti amministrativi connessi.

E' quindi utile una sintesi di tale quadro normativo, non sotto forma di esposizione dettagliata ed indistinta, ma tesa a fornire il quadro conoscitivo di supporto ad un esame critico della situazione.

Il problema reale infatti è quello di distinguere tutto ciò che va considerato invariante, e che quindi costituisce un vero e proprio vincolo, da ciò che può o deve essere sottoposto a modifica alla luce delle strategie generali del progetto di cambiamento.

Qualora infatti il progetto imponga, ai fini della propria riuscita, una modifica del quadro normativo, dovrà essere individuata una linea specifica di azione per tale modifica, che dovrà avviarsi e dispiegarsi contestualmente al processo informatico e che inevitabilmente costituirà un fattore critico di successo del progetto, che dovrà essere gestito all'adeguato livello di responsabilità.

 

Un altro elemento importante sono i vincoli temporali, che possono derivare sia dall'obbligo di rispondere a predefinite scadenze di legge, sia dalle eventuali relazioni del progetto con altri progetti e iniziative, sia dalla necessità di rispettare il quadro strategico complessivo.

 

Gli altri vincoli sono, come si è detto, essenzialmente di natura economica e organizzativa. Lo studio di fattibilità è chiamato ad esplicitare con completa chiarezza sia i limiti economici dell'intervento, limiti economici che riguardano sia il valore globale dell'investimento, sia i limiti riferiti ai vari anni di esercizio. Nello stesso tempo è necessario anche esplicitare le condizioni di necessaria invarianza in termini di distribuzione delle responsabilità sui prodotti/servizi erogati, di coinvolgimento delle strutture organizzative, di numero e caratteristiche delle risorse da impiegare a regime e quant'altro risulti necessario.

 

Lo studio di fattibilità è chiamato quindi in quest'area ad una delicata opera di integrazione ed omogeneizzazione delle spinte al cambiamento derivanti dall'evidenza dei problemi e dalle scelte strategiche con i limiti imposti dalla situazione che spingono, in completa divergenza, alla continuità.

Da questo deriva l'importanza di questa sezione, che, se non risolta efficacemente, è una delle cause più comuni del fallimento dei progetti e del loro mancato raggiungimento dei benefici attesi.

Definizione degli obiettivi del progetto

Questa parte dello studio di fattibilità consiste nell'esplicitazione degli obiettivi del progetto.

Gli obiettivi debbono essere quantitativi ossia debbono fare riferimento a costi, tempi e a individuate caratteristiche di qualità del prodotto/servizio erogato, sempre suffragate da metriche specifiche e debbono essere in correlazione diretta con i fenomeni già individuati in precedenza come causa delle problematiche evidenziate.

E' quindi necessario descrivere gli obiettivi e collegare ad ogni obiettivo la metrica da utilizzare per la verifica del suo raggiungimento, i valori attuali e i valori obiettivo, eventualmente scadenzati nel tempo. Scadenzare gli obiettivi è necessario, nel caso di progetti complessi, per evidenziare come il progetto sia in grado di rispondere ai vincoli temporali evidenziati e rappresenta un elemento essenziale per definire poi il piano di massima del progetto, specialmente in termini di piano dei rilasci.

 

Gli obiettivi evidenziati in questa sezione del documento fanno riferimento all'insieme del programma di cambiamento proposto e sono pertanto obiettivi che si riferiscono al processo di servizio (o all'insieme omogeneo di processi di servizio) coinvolti.

Ciò significa che nel caso in cui si abbia un progetto informatico contestuale ad altri interventi su altre componenti si dovranno esplicitare gli obiettivi derivanti dall'insieme degli interventi.