Il tema della riorganizzazione dei processi di servizio e dell'intervento integrato sulle varie componenti di una organizzazione (strutture, processi, tecnologie, personale) viene trattato specificatamente in un altro capitolo: quello che è importante sottolineare qui è 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à potrà mutuare le conclusioni dell’attività precedente. E' il caso tipico di progetto informatico indirizzato dalle ipotesi di reingegnerizzazione e contestuale e parallelo ad altri interventi relativi alle altre componenti del processo di servizio.
• il progetto informatico nasca autonomamente, anche su specifica spinta dettata da nuove opportunità tecnologiche. In questo caso lo studio di fattibilità dovrà prevedere le attività tese alla formalizzazione degli obiettivi di miglioramento del processo e delle ipotesi di intervento sulle altre componenti del processo. Tipicamente questo approccio ha senso quando il progetto informatico è il principale o addirittura il solo piano di intervento, mentre per le altre componenti si hanno solo interventi secondari, direttamente derivanti dal progetto informatico, secondo la normale accezione 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.

Anche i progetti di infrastruttura informatica e telematica 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.

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

La valutazione delle possibili alternative rappresenta peraltro una attività complessa ed onerosa, in quanto impone di dettagliare le varie ipotesi fino al punto di approfondimento necessario per stimarne costi, valutarne il grado di raggiungimento degli obiettivi, definirne le differenze in termini di impatto sulla situazione attuale. Nello stesso tempo, in caso di successiva gara, si rischia di limitare eccessivamente lo spettro delle possibili proposte. Anche alla luce di queste considerazioni, il problema reale consiste pertanto nel definire concretamente le alternative da considerare e quindi nel limitarne il campo di applicabilità.

Le alternative in termini di programma complessivo di cambiamento non sono oggetto di esame in uno studio di fattibilità. Alternative, quali, ad esempio, la scelta tra risolvere un problema tramite un intervento sul sistema informativo o viceversa tramite interventi solo organizzativi e normativi, dovrebbero essere già state risolte prima della decisione di effettuare uno studio di fattibilità sul progetto informatico.

Anche per quanto riguarda i requisiti del sistema da realizzare, non è necessario esaminare alternative. I requisiti del sistema sono le fondamentali condizioni a cui il sistema deve rispondere per soddisfare le esigenze individuate dall’utenza e discendono quindi direttamente dagli obiettivi del progetto e delle esigenze dell’amministrazione e dell'utenza. E’ il caso, ad esempio, della tipologia di informazioni trattate o delle principali funzionalità previste dal sistema. Si tratta pertanto di elementi "costitutivi" 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 soprattutto alle alternative in termini di specifiche generali del sistema e 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. Inoltre le alternative debbono essere concrete e non astratte (non è necessario esaminare ad esempio tutte le combinazioni possibili tra i vari livelli di alternativa ma solo quelle effettivamente significative). E' poi importante concentrarsi solo su aspetti effettivamente essenziali e determinanti la natura della soluzione, mentre altri aspetti possono essere più convenientemente demandati alla valutazione delle offerte e alla progettazione esecutiva. Infine è naturale che la natura delle alternative da considerare dipenda dalla tipologia di progetto, ad es. è diversa la tipologia delle alternative per realizzazioni di sistemi applicativi da quella per realizzazioni di infrastrutture informatiche.

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.

In diversi casi l'esame di questa alternativa non si pone: è il caso di organizzazioni che hanno maturato una propria "visione" tecnologica definendo specifiche architetture obiettivo a cui attenersi nello sviluppo dei propri sistemi informativi. Nel caso in cui questa opzione non esista (almeno nell'area in esame) lo studio di fattibilità dovrà viceversa esaminare e valutare compiutamente le alternative in termini di architettura tecnologica, attraverso una comparazione basata sul rapporto costi-benefici.

Accanto alle alternative tecnologiche 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 più conveniente.

Esiste poi possibilità di alternative in termini di modalità e specifiche realizzative. 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, 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. Quelle che non incidono sostanzialmente sulla natura della soluzione stessa possono essere demandate sostanzialmente all’offerta dei possibili fornitori e al progetto esecutivo.

In caso di gare è infatti importante dare ai fornitori la possibilità di esprimere compiutamente la propria capacità progettuale, senza vincolarle in limiti angusti 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 è opportuno non rinunciare.

Può peraltro verificarsi la situazione, specie per progetti di dimensioni ed impatto medio-basso o collegati a realizzazioni precedenti, che risulti 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à.

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.

A parte alcuni casi, peraltro abbastanza rari, in cui è necessario accertare la fattibilità "tecnologica", l’accezione più importante di fattibilità è quella legata all'analisi del rischio. Valutando infatti il rischio del progetto è fondamentale evidenziare le situazioni di rischio troppo elevate che possono pregiudicare l’ottenimento stesso dei risultati attesi e/o creare un situazione in cui diventano imprevedibili sia la durata del progetto che la quantità di risorse umane e finanziarie necessarie.

Questi sono progetti "impossibili", e lo studio di fattibilità è chiamato ad affrontare questa situazione, individuando 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 in genere dall’assenza di una conoscenza accettabile della situazione attuale, dalla presenza di requisiti incerti o troppo soggetti ad evoluzione e dalla assenza di un sufficiente grado di definizione della soluzione.

Il monitoraggio dei contratti relativi a progetti di grande rilievo della Pubblica Amministrazione prevede, quali modelli di riscontro per la stessa attività di monitoraggio, la disponibilità della seguente documentazione:

1. Il Manuale della Qualità, che costituisce il modello di riscontro per il Monitoraggio sul processo del fornitore;
2. Il Piano di Progetto, che costituisce il modello di riscontro per il Monitoraggio sulla conduzione del Progetto;
3. Il Piano della Qualità, che costituisce il modello di riscontro per il Monitoraggio sulla qualità dei prodotti;
4. L'Analisi dei costi e dei benefici, che costituisce il modello di riscontro per il Monitoraggio sulla bontà dell'investimento.

Come già accennato in precedenza, lo studio di fattibilità, fornisce direttamente il documento di "analisi dei costi e dei benefici" e pone una serie di requisiti che rappresentano obiettivi e vincoli che dovranno essere tenuti rigorosamente in conto negli altri tre documenti di riscontro.

Per quanto riguarda il Manuale della Qualità, lo studio di fattibilità dovrà fornire indicazioni relative ai requisiti di qualità del processo di produzione che dovranno essere soddisfatti dal fornitore. Tali indicazioni, una volta recepite nel capitolato di gara e quindi diventate condizioni obbligatorie della fornitura, diventano requisiti di qualità per il processo di produzione. Queste indicazioni saranno contenute nel paragrafo "Indicazioni per la gestione del piano di qualità", collocato all’interno della sezione relativa alle "Raccomandazioni per le fasi realizzative".

Il Manuale della qualità, insieme con la metodologia, le procedure ed i tools ad esso connessi, effettivamente impiegati dal fornitore nell’esecuzione dello specifico contratto, dovranno ovviamente essere coerenti con i requisiti espressi.

Anche in relazione a questa necessità è utile che tali requisiti vengano espressi in relazione agli standard ISO 9000, ed in particolare con la "ISO/DIS 9000-3 -Quality management and quality assurance standards -- Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software".

Per quanto riguarda il Piano di Progetto lo studio di fattibilità, produce il primo piano di massima del progetto. Tale piano di massima risulta vincolante, ai fini del monitoraggio, solo per gli aspetti relativi al piano dei rilasci, ai punti di controllo, e alla tempificazione espressa con Pert o diagrammi di Gantt. Sarà invece il "piano di progetto" che il Fornitore produrrà in sede di offerta e di progetto esecutivo ad essere utilizzato quale documento di riscontro nel monitoraggio. Questo piano di progetto, che ovviamente dovrà essere allineato alle indicazioni del piano di massima, contiene anche altri aspetti (RBS, costi, ...) e dovrà risultare coerente con i vari piani presenti nel progetto (piani legati alle attività primarie, di supporto ed organizzative di cui al ciclo di vita dei sistemi informativi - estensione del ciclo di vita del software della "ISO/IEC 12207:1995 Information technology -- Software life cycle processes...").

Per quanto riguarda il Piano della Qualità, lo studio di fattibilità, indica in una parte del paragrafo "Requisiti del sistema informativo da realizzare" i requisiti minimi di qualità dei prodotti (piano di qualità dei prodotti sw ed hw ) e dei servizi (piano di qualità dei servizi) che dovranno essere assicurati dal fornitore e che pertanto dovranno essere contenuti nel Piano di qualità del Fornitore.

Anche ai fini del monitoraggio è pertanto importante che tali requisiti vengano espressi in relazione alle caratteristiche di qualità di cui agli standard "ISO/IEC 9126:1991-Information technology -- Software product evaluation -- Quality characteristics and guidelines for their use" per quanto riguarda i prodotti software mentre, per quanto riguarda i servizi, siano coerenti a quanto contenuto nei documenti di "specifiche del servizio", di "specifiche di realizzazione del servizio" e di "specifiche controllo qualità del servizio" di cui alla norma "ISO 9004-2:1991 - Quality management and quality system elements -- Part 2: Guidelines for services".

Naturalmente si potrà poi far riferimento a norme e standard specifici esistenti per quanto riguarda le caratteristiche delle apparecchiature in acquisizione.