1.3.1.1 Il contesto dello studio

Questa parte consiste in un documento che colloca il progetto analizzato dallo studio di fattibilità nel contesto della strategia di sviluppo del sistema informativo. Le informazioni contenute in questo parte sono di regola già presenti, anche in maniera formalizzata, al momento della produzione dello studio di fattibilità. 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. Si tratterà pertanto:

• di riprendere, per sommi capi e con una specifica attenzione alle tematiche trattate dal progetto, la visione strategica in termini di servizi, organizzazione e utilizzo della tecnologia, visione strategica normalmente già esplicitata all’interno della pianificazione;
• di ripercorrere sommariamente il percorso che ha portato alla individuazione del progetto, evidenziando gli eventi (ad es. modifiche legislative, indirizzi governativi e comunitari, atti ufficiali dell’amministrazione, indicazioni espresse dai massimi livelli di responsabilità dell’amministrazione…) che hanno avuto incidenza sulla definizione del progetto;
• di fare riferimento alla pianificazione effettuata sulla materia;
• di sottolineare le motivazioni che hanno portato alla decisione di effettuare uno studio di fattibilità, evidenziando gli aspetti del progetto da sottoporre, attraverso lo studio, ad un esame particolare.

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

Anche le informazioni contenute in questo parte sono di regola già presenti al momento dello studio ma spesso in maniera non formalizzata. 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.

Un altro elemento da chiarire riguarda la criticità della problematica trattata e del progetto collegato, ossia la valutazione dell'influenza del progetto sulle attività 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, con il linguaggio dell’utente ed in termini qualitativi.

Per utente va inteso sia l’utente finale, il fruitore definitivo del prodotto/servizio, che in genere sarà esterno all’organizzazione (nel caso della P.A. si tratterà di cittadini, imprese ecc.), sia l'utenza interna ossia il personale chiamato a svolgere gli adempimenti operativi del processo in esame, da cui è importante raccogliere il patrimonio, spesso nascosto, di esperienza e competenza che si accumula all’interno di ogni organizzazione.

Anche le esigenze degli utenti dovrebbero essere già presenti al momento dello studio, in quanto dovrebbero essere comunemente raccolte nel corso della normale attività operativa. Il compito dello studio di fattibilità è quindi di completamento e di formalizzazione, ma 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.

Questa parte dello studio di fattibilità consiste nella individuazione e rappresentazione dei processi e dei sistemi informatici 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 della situazione attuale 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. Una parte di queste informazioni dovrebbe comunque derivare dalla 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à.

Considerando lo scopo di tutta la sezione (descrivere sinteticamente gli elementi essenziali che hanno determinato poi l'analisi, la diagnosi e la 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 una pluralità di modelli di rappresentazione, alcuni dei quali sono trattati in altri capitoli. I modelli comunemente più usati comprendono 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 e altri modelli, come gli Action Diagram Workflow, più direttamente mirati alla evidenza dei rapporti cliente-fornitore o di altri aspetti specifici dei processi.

Per quanto riguarda l’individuazione dell’utenza impattata e di come si distribuisce sulle varie strutture organizzative, possono essere utili sia un funzionigramma dell'organizzazione, 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.

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à, o derivanti da una attività di reingegnerizzazione o prodotti da 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.

Come già accennato, occorre 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. 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.

Per l'analisi e la diagnosi di processi e di strutture organizzative esistono una pluralità di approcci, metodi e tecniche. Tra di essi figurano approcci e metodi basati sull’esame della catena del valore (Activity Based Costing), approcci e metodi orientati all’esame dei fattori critici di successo, approcci e metodi derivanti dall’approccio totale alla qualità, 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 possono citare le tecniche di Problem Solving di Ichikawa (la lisca di pesce, fish-bone) e la tecnica del QFD (Quality Function Deployment). Parte di questi metodi e tecniche sono maggiormente descritti in altri capitoli.

Una attenzione specifica è naturalmente necessaria per gli specifici aspetti informativi in termini di efficacia, efficienza, completezza, correttezza, disponibilità e tempestività dell’informazione resa disponibile dal sistema. 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.

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.

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 all'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.

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.

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.