5. APPROCCIO CONCETTUALE E METODOLOGICO

5.1 Progetti informatici e revisione dei processi di servizio

Obiettivo finale dell'adeguamento dei sistemi informativi automatizzati (sia come realizzazione ex-novo che come modifica dei sistemi esistenti) è quello di contribuire al miglioramento dei processi di servizio.

Per ottenere risultati effettivi in termini di efficacia ed efficienza nell'erogazione dei servizi, è quindi necessario che gli adeguamenti dei sistemi informativi automatizzati si collochino in un contesto di razionalizzazione complessiva dei processi di servizio. Questo è ancor più importante nella Pubblica Amministrazione dove sono presenti rischi concreti che l'automazione intervenga su processi comunque obsoleti e mal organizzati e dove perdurano visioni esclusivamente tecnologiche dei sistemi informativi.

E' quindi evidente l'importanza che i progetti informatici si accompagnino a contestuali altri interventi sul processo di servizio che possono riguardare:

• 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.

E' infine molto probabile che questo insieme di interventi implichi la necessità di modifiche legislative e/o normative, che diventano essenziali per l'effettiva applicabilità del programma complessivo di cambiamento e che quindi costituiscono un'altra specifica area di intervento.

Il tema della riorganizzazione dei processi di servizio è stato già trattato in precedenza nel presente documento. Quello che è importante sottolineare è che la revisione dei processi di servizio può avere due approcci sostanzialmente diversi (e complementari).

Può infatti configurarsi come un completo e radicale ridisegno del processo, approccio che in genere deriva da scelte con ampia valenza politica che prevedono modifiche sostanziali ai servizi erogati, cambiamenti legislativi e normativi di ampia portata, ridistribuzione delle responsabilità, profondi mutamenti organizzativi. In questo caso la gestione del ridisegno deve essere affidata ad un centro di responsabilità forte, dotato di significativi poteri di intervento.

Può viceversa configurarsi come miglioramento di processi esistenti, approccio noto come FPI (Functional Process Improvement). In questo caso si ha invarianza o minime modifiche al servizio erogato, al contesto normativo e alla attribuzione di responsabilità e si concentra sulla riorganizzazione del flusso operativo e della struttura interna delle unità organizzative interessate insieme ad interventi sul personale addetto. In questo caso è fondamentale il coinvolgimento dei livelli intermedi della dirigenza, dato che la valutazione e le proposte di miglioramento non possono che nascere da una diffusa partecipazione attiva dei responsabili degli uffici coinvolti.

Quello che comunque emerge è la necessità di uno stretto rapporto tra i progetti di adeguamento dei sistemi informativi e gli altri interventi. Questo rapporto si può esprimere in modo diverso a seconda del contesto e delle dimensioni ed importanza dei vari interventi, e la diversità si esprime sia riguardo alle modalità di definizione dei progetti, sia riguardo alla loro attuazione.

Dal punto di vista della definizione dei progetti può verificarsi che:

• il progetto informatico scaturisca da una vera e propria iniziativa strutturata di riorganizzazione complessiva del processo di servizio. In questo caso lo studio di fattibilità relativo potrà mutuare le conclusioni dell'attività di Business Process Reengineering, sia in termini di obiettivi di miglioramento del processo che di ipotesi di intervento sulle altre componenti del processo stesso. Tipicamente questo approccio comporta un intervento radicale sul processo di servizio ed origina un programma integrato di cambiamento.
• il progetto informatico nasca autonomamente da una specifica attività di revisione del processo o a seguito di modalità correntemente presenti per l'analisi dei risultati dei processi e per il miglioramento continuo degli stessi. In questo caso lo studio di fattibilità relativo dovrà prevedere di svolgere direttamente le attività tese alla formalizzazione degli obiettivi di miglioramento del processo e delle ipotesi di intervento sulle altre componenti del processo. Tipicamente questo approccio comporta una sostanziale invarianza delle altre componenti per cui il progetto informatico è il principale o addirittura il solo piano di intervento.

Dal punto di vista della attuazione dei progetti, può verificarsi che:

• il progetto informatico sia un progetto parallelo ad altri progetti relativi alle altre componenti del processo di servizio, ossia può essere una delle iniziative di un programma di cambiamento che prevede altri specifici interventi;
• il progetto informatico sia il solo o il principale progetto di intervento, in quanto si assume la sostanziale invarianza delle altre componenti, che al massimo sono oggetto di interventi secondari, direttamente derivanti dal progetto informatico. Solo in questa accezione ha senso parlare di "impatto organizzativo".

Entrambe queste situazioni sono ovviamente possibili e possono rappresentare l'approccio al cambiamento più corretto da assumere nei diversi contesti. Quello che è importante è che la scelta dell'approccio derivi da una analisi e diagnosi dei processi di servizio coinvolti, che arrivi a conclusioni ragionate e consapevoli.

In conclusione appare comunque necessario che nella definizione di un progetto informatico si assuma un punto di vista complessivo sul processo (o sull'insieme omogeneo di processi su cui ci si propone di intervenire), esplicitando gli obiettivi di miglioramento ed indicando le necessarie iniziative collaterali all'intervento informatico.

Questa necessità si sostanzia nell'indicare nello studio di fattibilità:

• le conclusioni della diagnosi sullo stato attuale del processo di servizio;
• gli obiettivi di miglioramento espressi attraverso gli indicatori individuati ed i relativi valori obiettivo;
• la descrizione delle modifiche ai prodotti/servizi erogati;
• la descrizione delle modifiche al flusso del processo di servizio;
• la descrizione degli interventi organizzativi previsti;
• la descrizione degli interventi sul personale;
• l'esplicitazione degli ostacoli legislativi e normativi e le modifiche necessarie al loro superamento.

Anche i progetti di infrastruttura informatica e telematica (i progetti "orizzontali") riguardano un processo di servizio. Il processo in questione è il processo di erogazione di risorse informative agli utenti. Anche questi progetti possono quindi prevedere la medesima logica. Per questi specifici processi, tipici della gestione dei sistemi informativi, si può fare riferimento ad indicatori in parte già predefiniti.

Come già accennato in precedenza lo studio di fattibilità contiene un elemento, il progetto di massima della soluzione che, per sua natura, è soggetto a continua evoluzione in termini di maggior dettaglio e di risoluzione dell'incertezza.

Lo stadio di definizione, descrizione e rappresentazione del sistema che si intende realizzare, appunto il progetto di massima, sarà, nello studio di fattibilità, necessariamente ad un livello non esaustivo, principalmente in termini di dettaglio e di completezza.

Il problema che si pone è quindi quello dell'individuazione del livello di dettaglio e di completezza adeguato allo studio di fattibilità.

Si tratta ovviamente di un problema di difficile soluzione, per il quale risulta complicato definire una risposta valida per tutte le situazioni possibili.

Il principio è comunque nitido: il livello di approfondimento deve essere tale da garantire il raggiungimento degli obiettivi che lo studio di fattibilità si pone. Questo significa che la progettazione della soluzione deve raggiungere già nello studio di fattibilità un livello di dettaglio che consenta:

• di verificare la fattibilità tecnica e organizzativa;
• di stimare i costi con attendibilità;
• di individuare i rischi con attendibilità;
• di chiarire come e perché sono previsti benefici ed in quale misura;
• di stilare un piano di massima.

Questo principio è comunque un principio forte per la verifica del lavoro, durante la produzione di uno studio di fattibilità, infatti appare evidente come eventuali difficoltà nell'effettuare le attività sopra elencate, derivanti da una incompletezza di elementi di valutazione, indichino chiaramente la necessità di definire meglio la soluzione proposta.

Alla luce di questo principio la questione del livello di dettaglio viene ripresa nel presente documento nel capitolo che descrive il contenuto informativo delle varie sezioni dello studio di fattibilità, affrontandolo in maniera più analitica, relativamente agli specifici argomenti trattati.

L'esperienza dimostra peraltro che i problemi più rilevanti, in particolare rispetto alla stima dei costi, riguardano principalmente la determinazione dell'impegno e dei costi per lo sviluppo del software applicativo e la sottovalutazione degli impegni e dei costi relativi alla messa in produzione del sistema, ivi comprese le problematiche di formazione e di assistenza agli utenti.

Sarà pertanto su questo che si concentrerà la riflessione.

L'esame delle alternative rappresenta uno dei punti essenziali dello studio di fattibilità.

E' evidente peraltro che esaminare e valutare le possibili alternative progettuali rappresenta una attività complessa ed onerosa, in quanto impone di dettagliare gli n progetti di massima possibili fino al punto di approfondimento necessario per stimarne i rispettivi costi, valutarne i diversi gradi di raggiungimento degli obiettivi, definirne le differenze in termini di impatto sulla situazione attuale per quanto riguarda gli aspetti normativi e organizzativi, evidenziarne eventualmente punti di forza e di debolezza in relazione a caratteristiche funzionali e/o di qualità che non rappresentano requisiti essenziali ma che sono comunque utili alla valutazione.

Alla luce di queste considerazioni, il problema reale consiste quindi nel definire concretamente le alternative da considerare e quindi nel limitarne il campo di applicabilità.

Queste alternative, quali, ad esempio, la scelta tra risolvere un certo problema tramite un intervento sul sistema informativo o viceversa tramite interventi solo organizzativi o normativi, dovrebbero essere già state risolte prima della decisione di effettuare uno studio di fattibilità sul progetto informatico. Sono infatti scelte tipiche delle fasi precedenti, tese alla definizione iniziale dei progetti, che nascono da considerazioni da prevedersi all'interno di attività strutturate di Business Process Reengineering o comunque finalizzate alla diagnosi dei processi di servizio, attività tipiche della fase di pianificazione e definizione delle linee di intervento e che quindi non hanno attinenza specifica con il progetto relativo all'adeguamento del sistema informativo.

I requisiti del sistema sono le fondamentali condizioni a cui il sistema deve rispondere per soddisfare le esigenze individuate dall'utenza e discendono direttamente dalla esplicitazioni degli obiettivi del progetto e delle necessità individuate dall'amministrazione e dalle varie aree di utenza.

E' questo il caso, ad esempio, dei requisiti relativi alla tipologia di informazioni trattate, dei requisiti relativi alle essenziali funzionalità previste dal sistema, dei requisiti relativi alle caratteristiche quantitative e qualitative dei servizi informativi che si vogliono erogare.

Si tratta pertanto di elementi "costitutivi" della definizione del progetto, per i quali non ha logicamente senso immaginare alternative, una volta in presenza di una concreta idea di progetto, e rispetto ai quali il compito dello studio di fattibilità è quello di definirli compiutamente ed univocamente.

Ne consegue che, per individuare correttamente le alternative da prendere in esame, è necessario fare riferimento:

• alle alternative in termini di specifiche generali del sistema
• alle alternative in termini di modalità e specifiche realizzative

E' intanto da sottolineare come le alternative da considerare debbono essere tutte situate all'interno dei requisiti definiti, ossia debbono essere alternative comunque "efficaci", altrimenti è del tutto inutile valutarle. Inoltre le alternative debbono essere concrete e non astratte e non è quindi necessario esaminare ad esempio tutte le combinazioni possibili tra i vari livelli di alternativa ma solo quelle effettivamente significative.

Una volta esaminate e valutate le alternative, la scelta operata diventa requisito vincolante del progetto. E' da considerarsi eccezionale una valutazione di alternative diverse che porti solo alla indicazione di una generica preferenza, magari da utilizzare come elemento di valutazione delle offerte, in quanto rappresenta uno sforzo di approfondimento che può essere più agilmente demandato al momento della valutazione delle offerte e che lo studio di fattibilità può indicare nella parte della sezione "Raccomandazioni per le fasi realizzative" dedicata ai criteri suggeriti per la selezione delle offerte. Questo significa che l'esame delle alternative si deve concentrare solo su aspetti effettivamente essenziali e determinanti la natura della soluzione individuata.

E' infine da sottolineare che la natura delle alternative da considerare dipende dalla tipologia di progetto. E' cioè diversa la tipologia delle alternative per realizzazioni di sistemi applicativi da quella per realizzazioni di infrastrutture informatiche, è parimenti diversa la natura delle alternative di una nuova realizzazione da quella di un intervento di reingegnerizzazione ecc.

Per questo motivo una disamina più puntuale delle alternative da considerare è ripresa nel presente documento nella sezione che illustra le caratteristiche di specificità degli studi di fattibilità relativi alle varie tipologie di progetto. E' quindi in quella sezione del documento che troveranno concretizzazione, nei rispettivi contesti, le ipotesi generali qui espresse.

Le specifiche generali del sistema, le "specifiche globali" che definiscono la natura della soluzione, hanno costituito nel recente passato il punto focale dell'esame delle alternative. E' in questo ambito infatti che si collocano le alternative architetturali in termini tecnologici, tra le quali la celeberrima questione sistema centralizzato/sistema distribuito, su cui tanto si è discusso negli anni scorsi.

Non ci sono peraltro dubbi che in quest'area si addensino molte delle principali problematiche riguardanti l'esame delle alternative.

Occorre premettere, anche per liberare la questione da alcune forzature, quasi "ideologiche" che l'hanno talvolta inquinata in passato, che è normale che ogni amministrazione abbia maturato una propria "visione" tecnologica definendo specifiche architetture obiettivo a cui attenersi nello sviluppo dei propri sistemi informativi.

Si ricorda a questo proposito come l'Autorità abbia ripetutamente espresso l'importanza dell'adozione di architetture aperte e decentrate, "privilegiando, ogni volta che sia possibile, soluzioni basate sul decentramento della P.A., dei processi e delle basi informative, favorendo l'attività di riallocazione delle applicazioni e delle informazioni al variare delle esigenze" e sottolineando che "architetture di questo tipo sono particolarmente coerenti con il processo di decentramento di funzioni verso la pubblica amministrazione locale" (Dalle "Linee strategiche per il piano triennale 1995-97").

E' evidente come, in presenza di una definita opzione architetturale dell'amministrazione, non si ponga nello studio di fattibilità la questione dell'alternativa in termini di architettura tecnologica.

Nel caso in cui non esista una specifica "visione" e soprattutto nei casi in cui il progetto si collochi in un contesto già caratterizzato dalla presenza di soluzioni architetturali date, lo studio di fattibilità dovrà esaminare e valutare compiutamente le alternative tecnologiche, attraverso una comparazione basata sul rapporto costi-benefici, ed arrivando ad una scelta univoca.

Accanto alle alternative in termini di architettura tecnologica, possono esistere alternative anche in termini di architettura dati e architettura funzionale. Anche se in genere queste alternative hanno un minor impatto dal punto di vista dei costi, è bene che lo studio di fattibilità esamini le possibili diverse soluzioni in termini di distribuzione dei dati e delle funzioni per arrivare alla proposizione delle più convenienti specifiche della soluzione.

In quest'area è necessario fare una distinzione tra scelte di tipo strategico, che modificano in maniera significativa la natura della soluzione che si sta definendo e scelte che, al contrario, non incidono in maniera sostanziale nella definizione della soluzione, ma rappresentano soltanto diversi modi di realizzare la medesima soluzione.

Rientrano tipicamente nel primo gruppo ad esempio sia le scelte relative al "MAKE OR BUY", ossia l'alternativa tra acquisire pacchetti disponibili sul mercato, più o meno da personalizzare, o procedere ad una realizzazione ad hoc, sia le scelte sull'opportunità di recuperare o meno componenti del sistema esistente, magari con operazioni di incapsulamento o reingegnerizzazione.

Fanno parte tendenzialmente del secondo gruppo le scelte relative a strumenti e ambienti di sviluppo, le scelte relative all'interfaccia utente, le scelte relative alle modalità di interconnessione ecc.

Lo studio di fattibilità si deve concentrare solo sulle alternative di tipo strategico, quelle che, modificando la natura della soluzione, incidono su costi, tempi, caratteristiche essenziali di qualità del sistema che si vuole realizzare nonché, indirettamente, anche sui benefici.

Le varie modalità e specifiche realizzative, quando non incidono sostanzialmente sulla natura della soluzione stessa, non debbono quindi essere trattate come alternative (con valutazione e scelta vincolante all'interno dello studio di fattibilità), ma demandate sostanzialmente all'offerta dei possibili fornitori.

E' infatti importante che si dia la possibilità ai fornitori di esprimere compiutamente nelle offerte la propria capacità progettuale, senza vincolarle in limiti angusti e non necessari. La proposizione dei fornitori, ovviamente principalmente in caso di progetti complessi e di forniture composite, rappresentano un patrimonio di conoscenza e di approfondimento a cui non si deve rinunciare in caso di gara, dato che possono portare alla proposta di soluzioni che aggiungono qualità al sistema che si vuole realizzare. Questo vale da vari punti di vista: le tecnologie da utilizzare, la loro integrazione, le modalità di realizzazione, gli strumenti e l'ambiente di sviluppo, le caratteristiche dell'interfaccia utente e tanti altri aspetti legati alle caratteristiche di qualità del sistema.

Può peraltro verificarsi la situazione, specie per progetti di dimensioni ed impatto medio-basso o per progetti che sono collegati a progetti precedentemente realizzati, l'amministrazione possa ritenere utile porre dei vincoli alle modalità e agli strumenti di realizzazione, in genere per motivi di uniformità. Anche in questo caso non si pone un problema di esame di soluzioni alternative nello studio di fattibilità.

Sta ovviamente alla professionalità e alla sensibilità di chi redige lo studio di fattibilità una esatta individuazione di ciò che è più proficuo porre come vincolo e di ciò che sarà opportuno demandare all'offerta dei fornitori, ovviamente all'interno di requisiti definiti e vincolanti.

Ovviamente può anche darsi il caso che su tutta una serie di aspetti l'amministrazione abbia già definito degli standard a livello generale, validi quindi per tutto il sistema informativo e per tutti i progetti. Anche in questo caso il problema dell'esame delle alternative non si pone in quanto si dovrà semplicemente registrare l'esistenza di tali indicazioni, che saranno poi recepite nel capitolato e costituiranno vincolo per i fornitori.

La figura seguente illustra schematicamente l'insieme delle indicazioni riportate.

Uno dei compiti essenziali dello studio di fattibilità è quello di assicurare la fattibilità del progetto. A parte alcuni casi, peraltro abbastanza rari, in cui è necessario accertare la fattibilità "tecnologica", l'accezione più importante di fattibilità è quella che, esaminando il rischio del progetto in termini di complessità ed incertezza, arriva ad evidenziare situazioni di rischio troppo elevate che possono o pregiudicare l'ottenimento stesso dei risultati attesi o creare un situazione in cui diventa pressoché completamente imprevedibile sia la durata del progetto, sia la quantità di risorse umane e finanziarie che saranno necessarie.

Questi sono progetti "impossibili", e lo studio di fattibilità è chiamato ad evidenziare questa situazione ed a individuare e proporre soluzioni, in termini di modalità di realizzazione, che diminuiscano il rischio e rendano quindi fattibile il progetto.

I rischi fondamentali, che mettono in discussione la fattibilità stessa del progetto, derivano:

• dall'assenza di una conoscenza accettabile della situazione attuale;
• dalla presenza di requisiti incerti o soggetti ad evoluzione;
• dalla assenza di un sufficiente grado di definizione della soluzione, che impedisce stime ragionevolmente attendibili.