Che materia stai cercando?

Economia ed organizzazione Aziendale – Fattibilità Appunti scolastici Premium

Appunti di Economia ed organizzazione AziendaleFattibilità. Nello specifico gli argomenti trattati sono i seguenti: Studio di fattibilità, Concetti e definizioni, Dall'idea di progetto alla effettiva realizzazione, La necessità di uno "studio di fattibilità", ecc.

Esame di Economia ed organizzazione Aziendale docente Prof. L. Iandoli

Anteprima

ESTRATTO DOCUMENTO

E’ poi importante correlare al modello le informazioni relative alle necessità di utilizzo

dei vari sottosistemi, specie in termini di volumi di utilizzo dei sistemi interattivi, gli

eventi di attivazione, la specificazione delle eventuali necessità di interfaccia tra

sottosistemi e con altri sistemi applicativi, la matrice di relazione tra informazioni e

sotto-sistemi..

Modalità di lavoro

La descrizione delle modalità di utilizzo del nuovo sistema informativo è necessaria per

tutti i progetti, compresi quelli relativi a infrastrutture tecnologiche e all’automazione

d’ufficio.

Questo implica la necessità di individuare le principali classi di utenza, in termini di

numero e tipologia di utenti, di unità organizzative coinvolte e di localizzazione

geografica. Per questo è particolarmente utile la rappresentazione, attraverso matrici di

relazione:

• delle modalità di utilizzo degli elementi informativi da parte delle principali classi di

utenza (creazione, aggiornamento, cancellazione, consultazione);

• delle modalità di utilizzo dei sottosistemi da parte delle principali classi di utenza.

Un altro elemento importante relativo alle modalità di lavoro, per i sistemi applicativi, è

la definizione dei requisiti in termini di interfaccia utente, definendo gli elementi

essenziali delle modalità di presentazione previste, dell’accesso e dell’uscita dalle

applicazioni, della disponibilità di help in linea ecc.

Requisiti architetturali

Il sistema da realizzare si collocherà, nella generalità dei casi, all’interno di una più

complessiva struttura informatica, con inevitabili necessità di interfaccia con altri sotto-

sistemi e dovrà pertanto essere coerente con una architettura spesso già definita. Inoltre

si può porre un problema di interfaccia con altri sistemi esterni (per la P.A. certamente le

altre amministrazioni). Da ciò la necessità di definire specifici requisiti architetturali

finalizzati a garantire coerenza nell'utilizzo delle tecnologie e integrazione con

l’ambiente circostante.

I requisiti debbono essere espressi come tali, ossia come condizioni a cui il sistema che

si deve realizzare deve rispondere, e non come specificazioni, sia pure di alto livello,

ossia come indicazioni esplicite di modalità operative, ambienti software, strumenti.

Ulteriori considerazioni su queste tematiche sono state illustrate nel paragrafo relativo

alla “Valutazione delle alternative”.

Requisiti di qualità

I requisiti di qualità vanno evidenziati sia in termini di qualità del processo di

produzione, sia in termini di qualità del prodotto/servizio, ad esempio il sistema

applicativo da realizzare oppure i servizi che dovranno essere erogati da una

infrastruttura tecnologica.

Per quanto riguarda la qualità del processo di produzione, ossia le modalità di

assicurazione della qualità da attivare nella conduzione del progetto realizzativo, lo

28

studio di fattibilità dovrà fornire delle indicazioni, anche in considerazione della stretta

correlazione tra tali modalità operative e la qualità del prodotto/servizio finale.

A questo fine va prevista nello studio di fattibilità una parte specifica su questo

argomento, le “Indicazioni per la gestione del piano di qualità”, collocata all’interno

della sezione relativa alle “Raccomandazioni per le fasi realizzative”. Si tratta appunto di

indicazioni e non di veri e propri requisiti, che potranno essere recepite nel capitolato in

misura totale o parziale, secondo una valutazione della dirigenza dell’amministrazione

che dovrà tener conto della criticità del progetto e del livello di rischio evidenziato, ma

anche del livello di maturità espresso dall’offerta di mercato nello specifico settore di

fornitura richiesta. Si potrà ad esempio:

• porre come condizione obbligatoria che il fornitore abbia superato il meccanismo di

certificazione formale ISO 9000 (EN 29000);

• porre come condizione obbligatoria l’applicazione di solo una parte delle modalità

di assicurazione della qualità contenute nelle norme ISO 9000;

• richiedere al fornitore di specificare quali modalità di assicurazione della qualità

intende adottare e utilizzare le conseguenti indicazioni dei fornitori come criterio di

selezione.

Il punto centrale dei requisiti di qualità che lo studio di fattibilità deve esprimere

riguarda però i requisiti di qualità del prodotto/servizio. Per questi è necessario fare una

distinzione tra i progetti che riguardano la realizzazione di sistemi applicativi (e quindi

in primo luogo prodotti software) e progetti che riguardano l’acquisizione di servizi

informativi o la realizzazione di infrastrutture informatiche tese all’erogazione di tali

servizi.

Per i sistemi applicativi gli standard di riscontro sono costituiti dagli standard ISO/IEC

9126:1991 - Information technology - “Software product evaluation - Quality

characteristics and guidelines for their use”, punto di riferimento centrale per la

definizione dei requisiti di qualità del software. Sulla base di questi indirizzi lo studio di

fattibilità dovrà esplicitare le caratteristiche di qualità di particolare importanza nello

specifico contesto del progetto, individuando metriche e valori obiettivo o comunque

specifici requisiti per ognuna di esse.

Per i servizi informativi, e di conseguenza per le infrastrutture tecnologiche che debbono

erogare tali servizi, il punto di riferimento è costituito dalla norma “ISO 9004-2:1991 -

Quality management and quality system elements -- Part 2: Guidelines for services”,

con particolare riguardo a quanto contenuto nelle sezioni relative alle “specifiche del

servizio”, “specifiche di realizzazione del servizio” e “specifiche controllo qualità del

servizio”.

Per quanto riguarda infine le tecnologie (apparati e apparecchiature) si potrà fare

riferimento, ove disponibili, a specifiche norme e standard, sia in termini di

caratteristiche ergonomiche che di MTBF, MTTR ecc.

Per i servizi è indispensabile produrre una descrizione esauriente dei servizi stessi e delle

loro caratteristiche, principalmente in termini di disponibilità (ad es. orario di

attivazione), di tempi di risposta, di affidabilità ecc.

29

E’ poi importante definire anche alcune caratteristiche relative alle modalità di

produzione/erogazione del servizio (personale dedicato come numero e caratteristiche

professionali, risorse strumentali dedicate, modalità di controllo e di regolazione ecc.)

nonché le regole di comunicazione con l’utenza, in termini di informazione e assistenza

e di modalità di ricezione delle problematiche e delle esigenze di miglioramento. Lo

studio dovrà definire le esigenze di fondo su queste tematiche, modellandole sulle

specifiche caratteristiche del servizio informatico erogato ed individuando metriche e

valori obiettivo.

Per una trattazione più completa delle problematiche di qualità si rimanda comunque ad

un apposito capitolo.

SPECIFICHE GENERALI DEL SISTEMA

In questo paragrafo si evidenziano le specifiche generali del sistema informativo da

realizzare o modificare, ossia quelle caratteristiche o proprietà essenziali per rispondere

alle esigenze e ai requisiti individuati. In particolare dovranno essere recepite nello

studio le specifiche necessarie a ché il nuovo sistema si integri nel complesso del sistema

informativo esistente e risponda alle scelte architetturali e agli standard vigenti.

Lo studio di fattibilità non deve evidenziare specifiche di dettaglio, che potranno essere

definite solo in successive fasi di progettazione (sia applicativa che tecnica) e si

concentrerà soltanto sulle specifiche che incidono sulla natura stessa della soluzione.

L’esatta determinazione del confine tra l’opportunità di limitarsi, nello studio di

fattibilità, alla definizione dei requisiti e la necessità di esprimere delle specifiche

dipende inevitabilmente dai diversi contesti in cui si colloca il progetto e dalle

caratteristiche del progetto stesso, per cui è in notevole misura affidata alla

professionalità e alla sensibilità di chi conduce lo studio.

E’ ad esempio perfettamente legittimo che un’amministrazione, avendo già in esercizio

un notevole numero di reti locali governate da un determinato sistema operativo o

avendo impiegato largamente un determinato DBMS, ritenga opportuno indicare come

specifica l’utilizzo di quelle componenti tecnologiche, anche per preservare una

competenza già accumulata che consente di effettuare con proprie risorse l’attività di

gestione e di prima manutenzione (pensiamo anche agli uffici periferici).

Ma è altrettanto legittimo, in un contesto differente, che lo studio di fattibilità e di

conseguenza il capitolato di gara si limitino alla esposizione dei requisiti funzionali e

prestazionali, lasciando ai fornitori e alle offerte la possibilità di indicare prodotti diversi.

Specifiche applicative

Le specifiche applicative riguardano l’architettura dati e l’architettura applicativa, ossia

l’individuazione e la descrizione dei principali archivi e dei vari sotto-sistemi.

Dal punto di vista dei dati si porrà specifica attenzione anche alle problematiche di avvio

(popolazione iniziale delle basi di dati) e alle problematiche di gestione (modalità di

aggiornamento, assicurazione della coerenza e integrità ecc.). Dal punto di vista delle

funzioni è necessario individuare gli insiemi di funzioni che andranno a costituire

specifici sottosistemi distinti, per collocazione, modalità di accesso, modalità di gestione.

30

In quest’area un elemento essenziale è la definizione della distribuzione dei dati e delle

applicazioni, all’interno di un’ottica client-server, considerando sia la funzionalità,

l’affidabilità e la sicurezza del sistema, sia aspetti di costo quali la necessità di impiego

delle infrastrutture di comunicazione e l’esigenza di assistenza tecnica e manutenzione in

periferia.

Un valido punto di riferimento è costituito dalla classificazione dei modelli di

distribuzione proposta da alcuni osservatori internazionali che individua sei tipologie di

distribuzione: presentazione distribuita, presentazione remota, logica applicativa

distribuita, gestione dati remota, gestione dati distribuita, gestione dati distribuita e

logica distribuita.

Una compiuta disamina delle alternative in termini di distribuzione è opportuna nello

studio di fattibilità nel caso in cui porti a conseguenze significative in termini di ris volti

organizzativi, operativi e di responsabilità, ad esempio nella determinazione di chi sarà

chiamato a svolgere le attività di amministrazione dei dati e di conduzione e

manutenzione dei sistemi. Negli altri casi potrà essere lasciata alla valutazione delle

offerte.

Un altro elemento di specifica riguarda l’interfaccia utente, elemento essenziale per

assicurare apprendibilità e facilità d’uso e quindi in ultima analisi l’accettazione del

nuovo sistema da parte degli utenti.

Le specifiche dovranno riguardare le modalità di presentazione, le modalità di

navigazione all’interno delle applicazioni, la “robustezza” del sistema rispetto ad

operazioni improprie, particolari esigenze di sicurezza per le quali non è sufficiente

l’enunciazione di requisiti ma è utile definire specifici meccanismi da utilizzare (ad es. il

riconoscimento dell’utente con meccanismi più sofisticati del consueto sistema basato su

codice e password), la disponibilità e l’organizzazione di aiuto in linea ecc. In quest’area

la soluzione ottimale è naturalmente rappresentata dall’esistenza di standard aziendali,

nel qual caso lo studio di fattibilità si limiterà alla loro riaffermazione, concentrandosi su

eventuali elementi di specificità del progetto.

Se il progetto prevede l’erogazione di servizi si dovranno definire le loro caratteristiche

specifiche essenziali. Questo vale sia per servizi erogati da infrastrutture tecnologiche,

per i quali potrà essere importante definire ad esempio modalità di accesso e modalità di

erogazione, sia per servizi collaterali previsti dal progetto quali ad esempio la

formazione e l’assistenza utenti (help-desk), di cui dovranno essere individuate e

descritte contenuti, caratteristiche, modalità di accesso ed erogazione ecc.

Specifiche tecnologiche

In questo paragrafo si illustrano gli elementi essenziali della configurazione tecnologica

del sistema in termini di numero, distribuzione e caratteristiche dei posti di lavoro, di

dimensioni, caratteristiche e natura dei poli elaborativi, di struttura e caratteristiche della

rete di comunicazione, di software di base e di software di rete da utilizzare.

Ciò implica il dimensionamento dei sistemi e della rete, partendo dai requisiti espressi in

termini di volumi da trattare (quantità di dati e carico operativo del sistema) con

l’applicazione delle opportune tecniche di Capacity Planning e Capacity Management.

31

E' in questa parte che si colloca la già citata questione delle alternative architetturali. In

questo caso sorge la necessità di sviluppare la descrizione delle diverse ipotesi fino al

livello necessario per poter arrivare ad un confronto in termini funzionali ed economici e

quindi consentire una sia pur sommaria stima dei costi. Nello stesso tempo è necessario

che lo studio espliciti i criteri con cui verranno valutate le varie alternative, distinguendo

tra criteri di qualità e criteri economici.

I criteri di qualità debbono essere formulati in maniera rigorosa e non ambigua, al fine di

poter valutare le alternative in maniera chiara e trasparente, e dovrà esser loro attribuito

un peso in maniera da poter esprimere una scelta anche tra soluzioni che hanno

rispettivamente un maggior grado di qualità e un minor costo. I criteri di economicità

sono concettualmente ovvi, in quanto è naturalmente da preferire l’ipotesi a costo

minore.

Si dovranno poi evidenziare nel documento, anche con tabelle di riepilogo utili alla

immediata comprensione, i costi e le valutazioni di qualità relativi alle varie alternative.

Per ognuna di esse è quindi necessario:

• esplicitare e motivare le valutazioni funzionali e di qualità effettuate, che dovranno

essere espressa attraverso un semplice sistema di punteggi che consenta un

confronto agevole;

• descrivere i criteri di stima adottati per arrivare alle ipotesi di costo evidenziate. Si

dovranno esplicitare e confrontare i costi complessivi delle varie alternative,

considerando sia i costi di realizzazione che i costi di gestione, per i quali sarà

necessario fare riferimento allo stesso periodo (in genere tre anni) che sarà poi

utilizzato per la valutazione costi-benefici.

Infine è importante un riepilogo finale sintetico con l’esplicitazione della scelta proposta.

Modalità di realizzazione

In questo paragrafo si indicano le principali modalità realizzative da adottare, con

particolare riferimento alla valutazione delle alternative in termini di nuova realizzazione

o acquisizione (“make or buy”), e a quelle in ordine al riuso di componenti esistenti.

“Make or buy”

“Make or buy” - 1 - Nuovo sviluppo vs. pacchetti standard o applicazioni esistenti

Una prima accezione dell’alternativa “make or buy” riguarda la scelta tra l’acquisizione

di pacchetti standard (o di applicazioni già installate in altre situazioni) e lo sviluppo ex-

novo.

La disponibilità di pacchetti standard o la possibilità di acquis ire applicazioni che

coprono funzionalità identiche o simili rappresentano evidenti opportunità in termini di

risparmio e di accorciamento dei tempi di realizzazione che lo studio di fattibilità deve

esaminare con attenzione: in certi casi l'esame di questa alternativa è costituisce

l’adempimento essenziale. 32

Il gruppo di lavoro, una volta definiti i requisiti del sistema che si deve realizzare, deve

esaminare l'offerta di mercato (e, se possibile, i sistemi analoghi disponibili) e valutare

in maniera comparata queste possibilità con la realizzazione ex-novo. La valutazione

dovrà tener conto degli aspetti funzionali, degli aspetti tecnici e, naturalmente,

dell’aspetto economico.

Dal punto di vista funzionale si produce una mappatura delle funzioni offerte dalle varie

soluzioni con i requisiti espressi, mentre, dal punto di vista tecnico, si dovrà verificare la

coerenza dell’ambiente utilizzato con il contesto tecnologico del S.I.

dell’amministrazione.

Per poter considerare valida la possibile adozione del sis tema o del pacchetto non è

ovviamente necessaria una rispondenza completa ai requisiti (estremamente rara) né una

totale coerenza tecnica: sarà sufficiente una corrispondenza di fondo, il che significa la

necessaria attività di personalizzazione non sarà particolarmente pesante.

Dal punto di vista economico occorre considerare i costi di acquisizione e di

manutenzione dei pacchetti e stimare l’impegno di personalizzazione. Per la

comparazione di questi costi con quelli stimati per la realizzazione ex-novo saranno

sufficienti stime di larga massima, dato che in generale il risparmio economico di queste

soluzioni rispetto al nuovo sviluppo è considerevole.

Una volta evidenziata l’opportunità di ricorrere al mercato, la soluzione più conveniente

è in genere quella di selezionare un numero limitato di possibili fornitori (i più vicini ai

requisiti espressi). Ciò porta ad una gara per l’acquisizione del pacchetto e alla sua

personalizzazione, da condursi con l’opportuna procedura di approvvigionamento, con

un numero limitato ma significativo di offerte.

“Make or buy” - 2 - Utilizzo risorse interne o ricorso al mercato

Una seconda accezione dell’alternativa “make or buy” riguarda la scelta fra l’utilizzo di

risorse interne ed il ricorso al mercato per la realizzazione di uno specifico prodotto (ad

es. un sistema applicativo) o l’acquisizione di uno specifico servizio (ad es.

manutenzione software, assistenza utenti, data entry..).

Questa scelta fa in genere capo a strategie già definite in ogni amministrazione e pertanto

è raramente oggetto di esame in uno studio di fattibilità, in quanto risolta a monte.

Possono peraltro darsi dei casi di incertezza, specie nelle amministrazioni in cui

convivono entrambe le modalità realizzative. In questo caso è legittimo che lo studio di

fattibilità affronti la questione sulla base di un confronto in termini economici e di

qualità del prodotto/servizio.

“Make or buy” - 3 - Esternalizzazione o meno delle attività di conduzione, gestione e

manutenzione dei sistemi informativi delle amministrazioni

Un discorso specifico va fatto per i progetti tesi all’affidamento all’esterno delle attività

di conduzione, gestione e manutenzione dei sistemi informativi delle amministrazioni,

comunemente note come “outsourcing”. Per questi progetti tutto il problema ruota

intorno all’alternativa “make or buy” e quindi all’esame delle alternative.

33

In questo caso quindi i contenuti essenziali dello studio saranno:

• la definizione dei requisiti in termini di servizi informatici che dovranno essere

acquisiti;

• la descrizione delle specifiche generali di questi servizi;

• la determinazione dei costi della situazione attuale;

• la stima dei costi delle soluzioni ipotizzate;

• la individuazione e valutazione dei benefici, con particolare riguardo alla

determinazione dell’ammontare del risparmio in termini di personale;

• l’analisi dei rischi (in genere rilevanti) dell’operazione;

• la valutazione finale dell’alternativa tra le varie modalità possibili di affidamento

all’esterno ed il mantenimento della gestione in proprio

Quest’ultimo aspetto che rappresenta il punto focale dello studio e ad esso sono

finalizzate tutte le attività precedenti. Se si decide di procedere all’esternalizzazione, i

requisiti e le specifiche dei servizi forniranno la base su cui costruire il capitolato di gara.

Riuso di componenti esistenti

Un’altra alternativa essenziale da risolvere riguarda il riuso o meno delle componenti

esistenti, specie nei progetti di reingegnerizzazione di sistemi applicativi o infrastrutture

tecnologiche. La problematica del riuso riguarda raramente le apparecchiature, quasi

sempre i dati (per i quali è da prevedere la migrazione nel nuovo sistema) ed in certi casi

il software applicativo.

Per quanto riguarda le apparecchiature il problema si presenta raramente e si risolve

attraverso una analisi della rispondenza delle apparecchiature stesse ai requisiti e alle

specifiche dell’architettura tecnologica prevista.

Per quanto riguarda i dati occorre definire le modalità di migrazione delle informazioni

nel nuovo sistema. Questo aspetto va affrontato con il dovuto approfondimento,

individuando soluzioni tecniche, modalità operative, tempistica e stimando l’impegno ed

il costo necessario, dato che questa attività rappresenta una componente critica del

progetto, talvolta di costo e difficoltà non indifferenti.

Infatti la migrazione mette spesso in luce problemi già presenti ed irrisolti di qualità ed

integrità delle informazioni possedute, tanto che in certe situazione lo studio di fattibilità

dovrà valutare la possibilità di introdurre nel progetto specifiche attività di recupero della

qualità dei dati, che dovranno essere convenientemente definite e stimate.

Il punto più critico riguarda però il riuso delle componenti software. In questo caso lo

studio di fattibilità deve approfondire, con il dettaglio sufficiente per una scelta

ragionata, lo stato delle applicazioni che è possibile incorporare nel nuovo sistema. Si

dovrà pertanto esaminare e valutare il software esistente, in particolare le componenti

più specializzate ed onerose, allo scopo di arrivare ad una loro valutazione funzionale e

tecnica che consenta di definire la scelta più opportuna tra le possibilità di:

• utilizzo “as-is” attraverso operazioni di incapsulamento;

34

• standardizzazione e riformattazione (intervento solo sull’aspetto esterno del codice a

fini di ridocumentazione);

• ridocumentazione completa;

• ristrutturazione del codice (da non strutturato a strutturato con eliminazione codice

ridondante ecc.);

• modularizzazione;

• migrazione;

• reingegnerizzazione completa (riscrittura ricavando requisiti da esistente).

• completo abbandono con riprogettazione integrale;

In questa operazione sono necessari i passi di mappatura dei requisiti, valutazione

funzionale e tecnica dell’esistente, stima dell’impegno comparata con l’ipotesi di

riferimento, in questo caso costituita dalla riprogettazione completa. Occorre anche

verificare la possibilità del ricorso a strumenti automatici.

Avvio del nuovo sistema

In questo paragrafo si esaminano le problematiche relative alla messa in produzione e

all’avvio del nuovo sistema, con specifica attenzione all'installazione e alla diffusione,

spesso trascurate e causa di rilevanti problemi per il buon andamento dei progetti, specie

nel caso di molteplicità di siti. Un'altra questione riguarda il periodo di transizione dal

sistema attuale a quello futuro, con le correlate problematiche di periodo di utilizzo

parallelo dei sistemi e di allineamento dei dati.

Le attività di messa in produzione ed avvio debbono trovare una loro collocazione nel

piano di progetto e prevedere il coinvolgimento e l’assunzione di responsabilità di

molteplici figure (settore informatico dell’amministrazione, fornitore, responsabili

utenti).

In alcuni casi la rilevanza (ed il rischio) di queste attività di avvio è tale che lo studio di

fattibilità potrà definire l’opportunità di spezzare il progetto in due parti, una relativa alla

sola realizzazione ed una relativa all’installazione, diffusione e avvio, come già

evidenziato nel paragrafo relativo alla segmentazione dei progetti.

Esercizio e manutenzione del sistema

In questo paragrafo si evidenziano le necessità di manutenzione del sistema in tutte le

sue componenti, individuandone requisiti, modalità operative e impegni necessari,

elementi di grande rilevanza ai fini della esatta determinazione dei costi del progetto.

Allo scopo di minimizzare i pur necessari costi di manutenzione, si dovranno essere

esaminare le possibilità di ottenere garanzie sul sistema nel suo complesso e sulle sue

specifiche componenti e valutata per la manutenzione l’alternativa “make or buy”.

E’ poi necessario evidenziare le attività previste per la conduzione del sistema,

individuando attività, compiti e risorse necessarie, base indispensabile per la successiva

determinazione dei relativi costi. Anche in questo caso si deve esaminare l’alternativa in

termini di “

make or buy”, ossia la convenienza o meno di esternalizzare l’attività di

35

conduzione, alternativa che dovrà peraltro essere inquadrata nelle strategie complessive

dell’amministrazione in questo campo.

Formazione e assistenza utenti

In questo paragrafo si definiscono le necessità e le iniziative di formazione legate

all’attivazione del sistema, che si dovranno rivolgere in maniera differenziata ai

dirigenti, agli utenti e al personale informatico. Si dovrà pertanto delineare un piano di

formazione per queste tipologie di personale, indicandone i fruitori, i contenuti di

massima, la durata, le modalità di erogazione, gli impegni necessari. Contestualmente

vanno progettati contenuti e modalità dell’assistenza che si prevede di fornire agli utenti,

specialmente nelle prime fasi di esercizio del nuovo sistema.

Dal punto di vista dei contenuti occorre distinguere l’assistenza specificatamente

tecnologica da quella applicativa, individuando per ognuna ambiti e responsabilità. Dal

punto di vista delle modalità di erogazione va definito l’insieme di strumenti da

utilizzare (help-desk, creazione di figure che assumono un ruolo di “focal point”,

diffusione della documentazione, utilizzo di strumenti elettronici quali posta elettronica,

bacheca elettronica ecc.), vanno definite le modalità si ricorso all’assistenza di secondo

livello (assistenza specialistica e assistenza agli operatori) e vanno definiti ruoli,

responsabilità, procedure.

3.3. Analisi del rischio

Analisi del rischio

Fattori di rischio del progetto

Complessità

Complessità gestionale

Dimensioni del progetto

Altri fattori

Incertezza

Incertezza dei requisiti

Innovazione tecnologica

Analisi del rischio di progetto

Modalità di gestione del rischio

Tabella 3 - Indice di massima della Sezione terza - Analisi del rischio

I rischi sono i pericoli di eventi che possono pregiudicare il buon esito del progetto. Il

rischio più importante riguarda la mancata conclusione del progetto ma è sinonimo di

fallimento anche il fatto che i prodotti siano errati o non accettati e non usati, impedendo

comunque il raggiungimento dei benefici attesi. Sono significativi anche altri rischi quali

la lievitazione dei costi, l’allungamento dei tempi, i problemi di integrazione.

36

Uno dei compiti essenziali dello studio di fattibilità è quello di evidenziare i rischi più

importanti di un progetto e soprattutto le loro cause (i fattori di rischio), allo scopo di

indicare le contromisure che debbono essere adottate nella gestione del progetto.

L’analisi del rischio si esplica pertanto attraverso tre passi fondamentali:

• l’individuazione dei fattori di rischio;

• la valutazione dei vari fattori (con una analisi e una classificazione);

• la individuazione delle contromisure, ovvero la definizione di modalità operative per

la gestione del rischio.

Fattori di rischio

In questo paragrafo si individuano e descrivono i principali fattori di rischio del progetto.

Essi sono in genere ascrivibili alla complessità (gestionale e dimensioni) e all’incertezza

(dei requisiti o derivante da nuovi strumenti tecnologici), facendo riferimento al contesto

applicativo e organizzativo (rischi organizzativi) e al sistema informatico (rischi tecnici).

Sono presenti in letteratura diverse liste di riferimento per i fattori di rischio. Tali liste

vanno interpretate come check-list e non come regole definite da adottare supinamente:

possono quindi essere di aiuto nella individuazione degli effettivi fattori di rischio, tipici

di ogni contesto e di ogni progetto. Si riportano qui di seguito soltanto alcune indicazioni

di massima sul tema, oggetto di specifici approfondimenti.

La complessità gestionale riguarda principalmente gli aspetti di complessità funzionale e

di impatto del sistema sull’organizzazione e l’operatività. Tra di essi figurano la

rilevanza strategica del progetto, il livello di interfunzionalità, l'interconnessione con

altri progetti, l'eterogeneità degli attori, la pesantezza degli interventi su organizzazione,

ruoli e procedure di lavoro, la dimensione e la complessità del contesto applicativo

(processi e informazioni)

La complessità per le dimensioni riguarda il rilevante numero di persone coinvolte, la

dimensione tecnologica e la dimensione economica del progetto. Gli aspetti da

considerare sono quindi il costo del progetto, il numero di persone coinvolte e i

mesi/persona complessivamente previsti, la dimensione del sistema informatico, il

numero di attori e sub-contraenti, la quantità di installazioni previste, l'adeguatezza dei

tempi e delle risorse finanziarie

Esistono poi altri fattori, che attengono comunque alla complessità, legati a specifiche

problematiche di implicazioni legali e normative, rapporti con le organizzazioni

sindacali e altro.

L’incertezza dei requisiti, rappresenta per lo più, specie per l’amministrazione pubblica,

il più rilevante tra i fattori di rischio. Dipende da un insieme di fattori quali la stabilità

dell’ambiente e dei processi, la disponibilità, chiarezza e stabilità dei requisiti, il livello

di conoscenza del sistema esistente, il livello di formalizzazione dei processi e delle

informazioni trattate, l'esperienza degli utenti, dell’area S.I. e dell’amministrazione sulla

problematica, la partecipazione e supporto direzionale

37

L’innovazione tecnologica rappresenta certamente un rischio quando propone un

ambiente su cui non si è accumulata l’esperienza necessaria. Il rischio da innovazione

tecnologica emerge in caso di utilizzo di nuovo hardware, nuovo software di base, nuovo

software d’ambiente e nuovi strumenti di sviluppo, di necessità di integrazione di

tecnologie eterogenee, di necessità di software “ad hoc” o di utilizzo di strumenti

contrattuali innovativi

Analisi del rischio di progetto

L’analisi del rischio consiste nella valutazione sistematica di tutti i fattori di rischio

individuati. La modalità operativa più diffusa consiste nell’attribuire ad ogni fattore di

rischio un coefficiente qualitativo (alto, medio, basso), che classifica l’importanza di

ogni singolo fattore e di ogni classe di fattori.

Il risultato finale si compendia in una tabella, di cui si allega un esempio che riprende i

fattori di rischio proposti da Euromethod, in cui vengono evidenziati il livello di rischio

di ogni singolo fattore, di ogni classe di fattori e dell’intero progetto.

TABELLA RIEPILOGATIVA DELL’ANALISI

DEL RISCHIO Classificazione Alto Medio Basso

Complessità gestionale

rilevanza strategica del progetto X

interfunzionalità X

interconnessione con altri progetti X

eterogeneità degli at tori X

Valutazione generale X

Dimensioni del progetto

numero complessivo di mesi/persona previsti X

dimensione del sistema X

dimensione economica X

Valutazione generale X

Incertezza dei requisiti

stabilità dell’ambiente e dei processi X

disponibilità, chiarezza e stabilità dei requisiti X

comprensibilità del sistema esistente X

livello di formalizzazione dei processi e delle X

informazioni aziendali

partecipazione e supporto direzionale X

Valutazione generale X

Innovazione tecnologica

utilizzo di nuovo hardware X

utilizzo di nuovo software di base X

necessità di integrazione di tecnologie eterogenee X

Valutazione generale X

VALUTAZIONE GLOBALE DEL RISCHIO DEL X

PROGETTO Tabella 4 - Esempio di analisi del rischio

38

Modalità di gestione del rischio

Questo paragrafo rappresenta il contributo più significativo dello studio di fattibilità

sulla problematica del rischio e consiste nella definizione di una strategia e di un insieme

di azioni tese alla riduzione dei rischi e quindi al buon andamento del progetto. Tra le

azioni possibili assumono una particolare importanza le scelte di segmentazione del

progetto, la definizione dei punti di decisioni e le modalità di controllo del progetto, a

cui si possono aggiungere altri aspetti specifici.

Per quanto riguarda la segmentazione del progetto occorre definire se effettuare il

progetto in soluzione unica oppure adottare un approccio evolutivo o incrementale alla

realizzazione e/o all’installazione. Le scelte sull’approccio alla realizzazione derivano

dall’analisi dei rischi individuati, sia quelli connessi con l’incertezza dei requisiti, sia

quelli attribuibili alla complessità gestionale e alle dimensioni. Il risultato finale di

questa fase è la definizione del progetto realizzativo immediato, che non

necessariamente coprirà l’insieme della problematica trattata dall’ipotesi iniziale. Questa

tematica è ripresa in dettaglio in un prossimo paragrafo.

La definizione dei punti di decisione consiste nella determinazione dei momenti (e delle

modalità) in cui si dovranno prendere delle decisioni sulla prosecuzione del progetto,

analizzando il lavoro effettuato e ponendo così dei punti fermi su cui basare lo sviluppo

ulteriore.

La stessa decisione di effettuare uno studio di fattibilità rappresenta di fatto la prima

scelta relativa ai punti di decisione in quanto condiziona l’avvio delle attività realizzative

alle risultanze dello studio medesimo.

Questa attività è necessaria nei casi in cui lo studio non può risolvere completamente le

problematiche di incertezza e complessità, specie come incertezza o variabilità dei

requisiti: diventa pertanto indispensabile definire quando e attraverso quali prodotti

intermedi potranno essere risolti questi residui elementi di incertezza o di necessità di

governo della complessità. Si tratta in sostanza di formalizzare quei passaggi del

progetto, che è sempre un progetto in soluzione unica, atti a sostenere il suo sviluppo su

basi più solide.

Gli esempi più diffusi per tali prodotti intermedi e relativi punti di decisione sono:

• la produzione di documenti di definizione dei requisiti globali;

• la produzione di documenti di definizione di specifiche realizzative di fondo;

• la produzione di documenti di specifiche di dettaglio;

• la produzione di prototipi, generali o di dettaglio per specifiche parti del sistema;

• la realizzazione di un sistema sperimentale, collaudato, che possa essere preso

esaminato e verificato per la successiva installazione operativa;

• l’installazione e l’utilizzo sperimentale di un sistema che possa essere verificato

nella sua operatività per la successiva diffusione su una pluralità di siti.

Rispetto ad ogni prodotto intermedio vanno individuate le caratteristiche essenziali, in

maniera che possa fornire tutti gli elementi necessari alla decisione a al consolidamento

del progetto, nonché le responsabilità e le modalità di approvazione.

39

In definitiva quindi la definizione delle modalità di controllo del progetto, consiste

essenzialmente nell’individuare specifici livelli di formalità e frequenza da applicare al

“project management”. E’ evidente come una elevata formalità ed una elevata frequenza

rappresentano scelte di una certa onerosità che possono essere però necessarie in un

progetto in cui esis tono significativi rischi.

Tutti le considerazioni derivanti da questa elaborazione si collocano nel capitolo di

“Raccomandazioni per le fasi realizzative”.

3.4. Il progetto proposto

Il progetto proposto

Segmentazione del progetto

Riepilogo delle acquisizioni e realizzazioni previste

Piano di massima del progetto

Piano dei rilasci

Punti di controllo

WBS, Pert, Gantt

Tabella 5 - Indice di massima della Sezione quarta - Il progetto proposto

In questo capitolo si evidenziano le scelte sulla segmentazione del progetto, e le

considerazioni che hanno portato alle scelte medesime, arrivando quindi ad una

puntualizzazione concreta del progetto realizzativo, con un piano dei rilasci ed i previsti

punti di decisione.

Si dovranno dettagliare esattamente i prodotti/servizi che si intende realizzare, recependo

le scelte effettuate in termini di separazione o meno tra l’attività di progettazione,

realizzazione e installazione e in termini di individuazione o meno di attività

sperimentali o progetti pilota da attivare separatamente. Le indicazioni in termini di

piano dei rilasci e di definizione di eventuali punti di decisione saranno la base da cui

partire per pervenire alla definizione del piano di massima del progetto.

Segmentazione del progetto (soluzione unica, incrementale, evolutiva)

Per quanto riguarda i criteri per la segmentazione del progetto, si riportano qui riproposte

le considerazioni svolte in Euromethod, che riguardano i possibili approcci con cui

affrontare le problematiche di realizzazione e di installazione.

Per l’approccio alla realizzazione si prevedono tre scelte principali:

• realizzazione in soluzione unica: quando il nuovo sistema informativo viene

realizzato e collaudato in un’unica versione, generalmente con un’unica attività

continuativa;

• realizzazione incrementale: quando la realizzazione ed il collaudo avvengono per

parti successive, ciascuna delle quali contiene un sotto-insieme delle funzionalità e

40

dei servizi previsti. In questo caso i requisiti del sistema sono completamente

definiti prima della realizzazione iniziale e non variano nel corso delle successive

installazioni;

• realizzazione evolutiva: quando la realizzazione (ed il collaudo) avviene per

versioni successive, in cui ogni versione può contenere o tutte le funzionalità o un

loro sotto-insieme. In questo caso i requisiti del sistema possono essere variati tra

due successive versioni, dopo aver appreso nuove informazioni dall’attività

realizzativa e dal collaudo.

Per la scelta tra i vari approcci alla realizzazione si utilizzano dei procedimenti euristici

basati sulle considerazioni su incertezza e complessità derivanti dall'analisi del rischio,

nonché dalla situazione delle scadenze normative e contrattuali.

In genere ’approccio evolutivo è indicato quando la situazione è incerta, mentre

l’approccio incrementale è adeguato a situazioni complesse ma non incerte. Inoltre gli

approcci incrementale o evolutivo sono da preferirsi quando ci sono tempi stretti, ossia è

necessario realizzare qualcosa al più presto, tipicamente per rispondere in tempo a nuove

esigenze normative.

Anche per l'installazione si possono avere i medesimi tre approcci (soluzione unica,

incrementale, evolutivo) e valgono considerazioni analoghe. Naturalmente variano i

fenomeni da osservare nei due casi, ad esempio la capacità del gruppo di progetto o

l’innovazione tecnologica possono costituire un fattore di incertezza per la realizzazione

ma non per l’installazione mentre la necessità di installare numerose repliche del sistema

rappresenta comp lessità dell’installazione ma non della realizzazione.

I tre approcci all’installazione, definibili come “verticali”, non tengono ancora conto

della problematica relativa alla distribuzione geografica.

Nel caso in cui l’installazione debba coprire una pluralità di siti geograficamente

distribuiti è da considerare l’eventualità di prevedere più fasi di installazione ed in

particolare una prima fase concentrata su una copertura geografica limitata, ad esempio

un solo ufficio o una sola filiale. Questa installazione, la tipica “installazione pilota”, ha

il fine di calibrare il sistema informativo e migliorare il processo di installazione prima

che l’intero contesto applicativo venga influenzato dai cambiamenti. Successivamente si

estenderà la copertura geografica, raggiungendo con l’ultima fase la copertura totale del

contesto applicativo. Le varie modalità di copertura geografica possono combinarsi,

senza alcuna limitazione, ai vari approcci all’installazione precedentemente indicati.

E’ infine da sottolineare il rapporto tra i diversi approcci all’installazione e alla

realizzazione.

Da questo punto di vista tutte le combinazioni appaiono possibili, con la sola eccezione

dell’approccio evolutivo alla installazione, che implica necessariamente un pari

approccio evolutivo alla realizzazione.

Riepilogo delle acquisizioni e realizzazioni previste

In questo paragrafo si focalizza definitivamente il progetto realizzativo proposto, alla

luce dei criteri di segmentazione scelti. Facendo quindi riferimento alle attività

realizzative di cui si propone l’immediata attivazione ed il necessario finanziamento, si

41

riepilogano le acquisizioni previste (sistemi elaborativi, servizi ed apparecchiature di

rete, software di base e d’ambiente e pacchetti applicativi, software applicativo ad hoc,

servizi professionali e quant'altro). Questa sintesi rappresenta la base per la successiva

stima dei costi e costituisce un punto di riferimento essenziale per la stesura di un

eventuale successivo capitolato di gara.

Piano di massima del progetto

In questo paragrafo si illustra il piano di massima del progetto. Esso ha l’obiettivo di

evidenziare le necessità e gli obiettivi di fondo a cui la programmazione puntuale delle

attività si dovrà adeguare per poter rispettare sia le scadenze temporali fissate sia la

coerente disponibilità dei prodotti intermedi necessari al progressivo superamento

dell’incertezza e alla definizione di dettaglio dei prodotti finali attesi.

Il piano di massima contenuto nello dovrà avere una estensione totale, ma certamente

presenterà elevati livelli di aggregazione e generalizzazione. All’avvio del progetto

realizzativo il piano di massima costituirà la base di partenza per la stesura della prima

versione del piano di progetto, successivo punto di riferimento per la gestione del

progetto. Gli elementi fondamentali del piano di massima saranno quindi:

• il piano dei rilasci

• l’evidenza dei punti di controllo e di decisione

• un piano di massima delle attività, che necessariamente non sarà al livello di

dettaglio richiesto da un piano operativo ma che servirà ad evidenziare le scadenze

fondamentali e le principali relazioni di dipendenza tra le macroattività.

Il piano dei rilasci, come già accennato in precedenza, consiste:

• nella specificazione delle progressive realizzazioni in termini di prodotti finali del

progetto, ossia nelle previsioni di completamento di sotto-insiemi del sistema finale

(ad esempio la progressiva realizzazione di basi di dati o di sottosistemi applicativi)

o di versioni successive dell’intero sistema o di sue parti;

• nella specificazione delle previsioni di completamento dei necessari prodotti

intermedi.

L’evidenza dei punti di controllo o di decisione parte dal piano dei rilasci e consiste

nell’evidenza delle necessità di verifica e decisione conseguente. In genere

coincideranno con i “milestones” di un piano delle attività.

Il piano di massima delle attività consiste nella esplicitazione della sequenza e delle

dipendenze tra le principali attività del progetto e potrà essere compiutamente

rappresentato attraverso il “Pert”.

Appare infine utile una sintesi generale del piano che sintetizzi le principali scadenze

previste.

Per una trattazione specifica dell'argomento si rimanda comunque all'apposito capitolo.

42

3.5. Analisi costi benefici

Sezione quinta - Analisi costi-benefici

Valutazione dei benefici attesi

Individuazione e descrizione dei benefici attesi

Individuazione ed esplicitazione delle metriche e dei valori attesi

Correlazione obiettivi-benefici

Stima dei costi

Individuazione delle principali voci di costo

Esplicitazione delle metriche utilizzate

Stima dell’impegno di risorse umane

Stima dei costi di impianto e di esercizio

Analisi dell’investimento

Tabella 6 - Indice di massima della Sezione quinta - Analisi costi/benefici

Valutazione dei benefici attesi

In questo paragrafo si descrivono in maniera analitica i benefici attesi dal progetto,

esplicitando le metriche utilizzate, dichiarando i valori attesi ed infine correlando i

benefici individuati con gli obiettivi generali del progetto già in espressi in precedenza.

L’individuazione dei benefici si riferisce in primo luogo ai benefici monetizzabili, ossia

riconducibili ad una diminuzione di costi attualmente sostenuti o ad incrementi di

entrate. Questo per l’ovvio motivo che i benefici monetizzabili sono quelli

compiutamente utilizzabili nell’analisi costi-benefici.

Si dovrà pertanto fare uno sforzo di monetizzazione di tutti i benefici riscontrati in modo

da poter arrivare ad una analisi dell’investimento. Ci possono essere peraltro dei casi in

cui questa monetizzazione possa risultare particolarmente difficoltosa o per i quali la

previsione in termini monetari non possa risultare sufficientemente oggettiva. Questi

benefici non potranno quindi compiutamente rientrare nel computo dell’analisi

dell’investimento ed il beneficio identificato potrà essere valorizzato dagli opportuni

livelli di responsabilità.

Anche nei casi in cui non si arriva ad una monetizzazione dei benefici è comunque

necessario riferirsi a benefici comunque misurabili, ossia riconducibili ad una modifica

di un fenomeno osservabile e quantificabile, che riguarderà essenzialmente i tempi

oppure misure relative ad aspetti di qualità.

Ha poco senso parlare di benefici “intangibili”, ovvero non misurabili in alcun modo. E’

infatti necessario, allo scopo di effettuare una effettiva analisi dell’investimento e

soprattutto per poter poi andare ad una verifica dei risultati ottenuti, ricondurre ogni

beneficio alle sue effettive conseguenze, che, se non analizzate attraverso specifici

fenomeni, diventano completamente evanescenti.

43

Questo è possibile nella stragrande maggioranza dei casi che ancora oggi vengono

spesso trattati come “benefici intangibili”. Benefici quali il miglioramento del servizio

reso all’utenza, la maggiore autonomia e la crescita professionale del personale, il

miglioramento nella disponibilità di informazioni, la riduzione dei supporti cartacei, la

rapidità e l’efficacia dei processi operativi e gestionali possono essere riportati a valori

numerici di specifiche variabili correlate. Questa operazione è tanto più semplice quanto

più l’individuazione del progetto e dei suoi obiettivi sia scaturita da una misurazione e

valutazione dei fenomeni che generano criticità.

Questo principio vale anche per i cosiddetti benefici di “immagine”, che, come insegna

l’esperienza del settore privato, possono e debbono essere concretizzati attraverso

l’osservazione di specifici fenomeni (reclami, ricorsi, dimissioni, richiesta di servizi,

citazioni della stampa, azioni legali..).

Per quanto attiene alla individuazione e valorizzazione dei benefici di un progetto e

all'utilizzo di specifiche modalità per la loro stima si rimanda ad uno specifico capitolo.

Stima dei costi

In questo paragrafo si evidenziano i costi stimati del progetto. Occorre pertanto

individuare le principali voci di costo, esplicitare le modalità di stima utilizzate (in

particolare per quanto riguarda la stima dell’impegno di risorse umane che è all’origine

di svariate voci di costo) ed infine riepilogare la stima effettuata, sia come costi di

realizzazione e d’impianto che come costo di esercizio, sempre riferita allo stesso

periodo già utilizzato per la quantificazione dei benefici.

Nella individuazione delle voci di costo è bene riferirsi ad una lista di voci che possa poi

essere sempre seguita nel corso della realizzazione del progetto.

Lo studio di fattibilità deve esplicitare tutte le modalità di stima adottate, allo scopo di

consentire ai centri decisionali una valutazione dell’attendibilità della stima effettuata. E’

infatti naturale che a livello di studio di fattibilità i costi siano determinabili in modo

solo approssimato: quello che serve quindi è capire la qualità e conseguentemente il

margine di errore della stima.

Per la individuazione delle principali voci di costo di un progetto e per l'utilizzo di

specifiche modalità per la stima dei costi si fa riferimento ad uno specifico capitolo.

Analisi dell’investimento

L’analisi dell’investimento, o analisi costi-benefici, ha un duplice scopo:

• dare una giustificazione economica all’investimento necessario, sintetizzando gli

elementi per la decisione sull’avvio del progetto: l’analisi dell’investimento

rappresenta uno dei cardini necessari a raggiungere gli obiettivi per cui lo studio

viene effettuato.

• fornire gli elementi per la scelta nel caso in cui si comparino più alternative.

La necessità dell’analisi dell’investimento nasce dal fatto che costi e benefici di un

progetto si materializzano in istanti diversi, e tali serie temporali devono essere tenute in

44

conto nel momento della valutazione, osservando un arco temporale predefinito

(normalmente l’arco dei tre anni a partire dalla messa in esercizio del nuovo sistema).

Per l’analisi dell’investimento esistono diverse tecniche utilizzabili e l'argomento è

trattato in dettaglio in un apposito capitolo.

3.6. Raccomandazioni per fasi realizzative

Raccomandazioni per le fasi realizzative

Indicazioni per l’approvvigionamento

criteri per la determinazione della tipologia di fornitore

criteri di selezione delle offerte

indicazioni sulle modalità di approvvigionamento

Indicazioni per la gestione del progetto

indicazioni per la gestione del piano di qualità

indicazioni sul project management

esigenze di negoziazione delle varianti

Riepilogo degli elementi utili alla stesura del capitolato

Tabella 7 - Indice di massima della Sezione sesta - Raccomandazioni per le fasi realizzative

Indicazioni per l’approvvigionamento

In questo paragrafo si sviluppano una serie di raccomandazioni, derivanti dagli

approfondimenti effettuati su requisiti e specifiche, rischi e piano del progetto, da tener

presente nelle fasi successive del progetto e tese a risolvere o minimizzare le

problematiche emerse. La necessità di queste indicazioni riguarda principalmente

l’approvvigionamento (capitolato, gara, valutazione offerte) e la gestione del progetto

realizzativo.

Scopo del processo di approvvigionamento è l’acquisizione di ciò che è più utile e

conveniente per raggiungere i fini dell'organizzazione. E' importante pertanto utilizzare

modalità di approvvigionamento capaci di ottenere dal mercato il miglior

prodotto/servizio all’interno dei vincoli economici dati (“best value for money”).

Ovviamente l’approvvigionamento deve tener conto del quadro legislativo vigente e

pertanto utilizzare modalità situate all’interno delle norme che regolano l’acquisizione di

beni e servizi informatici, norme che costituiscono un sistema di riferimento ed un

vincolo indispensabile. Rispettare il quadro legislativo rappresenta quindi una

condizione essenziale a cui è necessario uniformarsi ma non è, di per sé, un obiettivo

dell’approvvigionamento.

Le indicazioni sull'approvvigionamento non consistono quindi solo nelle informazioni

necessarie alla stesura dell’allegato tecnico al capitolato, ma comprendono anche, in

particolare nel contesto della Pubblica Amministrazione, i criteri per la determinazione

45

della tipologia di fornitore, le modalità di approvvigionamento più adeguate, i criteri di

selezione delle offerte, alle esigenze di negoziazione delle varianti.

Dal punto di vista del capitolato tecnico, nello studio di fattibilità si troveranno le

indicazioni relative a requisiti funzionali, architetturali e di qualità del sistema

informativo da realizzare, alle specifiche globali del sistema informativo da realizzare,

alla segmentazione del progetto, alle acquisizioni e realizzazioni previste e al piano di

massima del progetto.

L'obiettivo è quello di porre le aziende candidate nelle migliori condizioni possibili per

esprimere la loro proposta e la loro offerta, al fine di ottenere il meglio dal mercato. Per

questo è necessario fornire un quadro di chiarezza che eviti incomprensioni e minimizzi

esclusioni non fondate su importanti motivazioni di merito.

In generale tuttavia non è utile che l’attività per lo studio di fattibilità arrivi ad una

compiuta ipotesi di testo del capitolato e/o di contratto. Questo perché la definizione del

capitolato di gara dovrà prendere in esame anche altri fattori non considerati nello studio

(ad es. i vincoli di bilancio o convenienza di operazioni di accorpamento e scorporo delle

forniture) e perché lo studio non può e non deve sostituirsi alla necessaria valutazione e

decisione finale, con conseguente assunzione di responsabilità, che spetta alla direzione.

Per quanto riguarda i criteri per la determinazione della tipologia del fornitore, esistono

in letteratura svariate griglie tese alla classificazioni delle aziende fornitrici di prodotti e

servizi informatici. In genere comunque tutte le classificazioni dei fornitori tendono ad

assumere come elementi di riferimento un insieme di parametri tra cui si annoverano

solidità finanziaria, dimensioni e localizzazione, tipologia di prodotti/servizi offerti,

propensione al rischio e capacità di innovazione tecnologica. Ma, mentre la solidità

finanziaria è un elemento valutabile a prescindere dalla specifica fornitura oggetto di

indagine, tutti gli altri elementi acquistano specifico significato solo in relazione alla

tipologia di fornitura richiesta. Da ciò scaturisce l'importanza di individuare specifici

percorsi che, partendo dalla natura della fornitura richiesta, portino alla definizione delle

caratteristiche preferibili dei fornitori, che poi potranno tradursi sia in requisiti

vincolanti sia in parametri di valutazione delle offerte.

Un altro elemento su cui lo studio di fattibilità potrà esprimere raccomandazioni riguarda

i criteri di selezione delle offerte. Anche su questo tema esiste una trattazione specifica

in un altro capitolo. Il cuore del problema consiste comunque nella definizione di un

“modello di valutazione”, ossia un albero pesato dei parametri di valutazione, che derivi

direttamente dalla definizione dei requisiti e delle caratteristiche del sistema e dal

modello di qualità atteso. Il modello di valutazione dovrà comprendere anche una parte

di riepilogo e verifica dei requisiti obbligatori, che dovranno essere necessariamente

presenti nell’offerta perché questa sia considerata valida.

La costruzione di un modello di valutazione, procedendo di pari passo con la definizione

di requisiti e specifiche e del modello di qualità permette una verifica immediata sulla

completezza e sulla coerenza dei contenuti dello studio, oltre a consentire risparmio di

tempo e risorse. La chiara individuazione di possibili parametri di valutazione fornisce

un aiuto fondamentale per la stesura corretta dei capitolati, aiutando ad evidenziare con

46

chiarezza nel capitolato stesso le informazioni che le offerte dovranno riportare ed i temi

che dovranno sviluppare.

L’insieme delle raccomandazioni sulla tipologia del fornitore e sui criteri di valutazione

delle offerte conduce naturalmente anche a raccomandazioni sulle modalità di

approvvigionamento, ossia della scelta tra le varie procedure possibili (varie tipologie di

gare e di trattative private). Anche questo argomento è sviluppato in un apposito

capitolo.

Indicazioni per la gestione del progetto

In questo paragrafo sono esplicitate, sempre come raccomandazioni, le indicazioni per la

gestione del progetto realizzativo derivanti principalmente dalla valutazione del rischio e

dalle considerazioni sul piano di massima del progetto.

Fermo restando che potranno essere sviluppate tutte le indicazioni che si riterranno

necessarie per minimizzare i rischi individuati, gli elementi in generale più critici

riguardano la gestione del piano di qualità, l’organizzazione di progetto ed il “project

management“, le esigenze e le modalità di negoziazione delle varianti.

Dal punto di vista della gestione del piano di qualità si dovranno esplicitare gli elementi

essenziali delle modalità di assicurazione della qualità del processo di produzione dei

prodotti/servizi che si intende acquisire. Essi dovranno essere coerenti con il livello di

qualità atteso e con le necessità di diminuzione dei rischi.

Dal punto di vista dell’organizzazione del progetto e della sua gestione si riprenderanno

e specificheranno le considerazioni svolte nel paragrafo relativo alle “Modalità di

gestione del rischio”, definendo modalità operative, ruoli e responsabilità, livelli di

formalizzazione dei documenti, frequenza e caratteristiche del controllo

dell’avanzamento. Una particolare attenzione dovrà essere prestata alla definizione delle

modalità di coinvolgimento dell’amministrazione e delle sue persone, sia come

partecipazione alla gestione e controllo del progetto, sia come partecipazione diretta alle

attività operative, sia come partecipazione dell’utente alle fasi di analisi, progettazione,

test e collaudo.

Dal punto di vista delle esigenze e modalità di negoziazione delle varianti sarà

necessario trovare una modalità organizzativa e operativa capace di rispondere agli

eventuali problemi di incertezza dei requisiti e delle specifiche, definendo una sequenza

di punti di decisione capaci di eliminare progressivamente l’incertezza e stabilendo per

ogni punto di decisione le responsabilità e le modalità a cui attenersi nonché i contenuti

dei prodotti intermedi (in genere, ma non solo, documenti di analisi e progettazione)

necessari alla decisione.

Riepilogo degli elementi utili alla stesura del capitolato.

L’ultima sezione di questo capitolo potrà utilmente contenere un riepilogo degli elementi

utili alla stesura del capitolato. 47

Si tratta semplicemente di un riepilogo dei prodotti/servizi che è necessario acquisire

(configurazione del progetto realizzativo), dei requisiti di qualità dei prodotti/servizi che

dovranno essere assicurati, degli elementi per il modello di valutazione da esplicitare nel

capitolato, delle indicazioni sulle modalità di assicurazione della qualità che dovranno

essere recepiti dal fornitore nel suo processo produttivo, dei vincoli su piano di lavoro e

risorse che derivano dal piano di massima.

4. Tipologie di studi di fattibilità

L’ipotesi di indice dello studio di fattibilità, e le conseguenti specificazioni di merito sul

contenuto delle varie sezioni dello studio, ha un valore generale che inevitabilmente

introduce degli elementi di genericità in quanto non può compiutamente rispondere a

tutte le esigenze di specificità tipiche delle singole tipologie di progetti e quindi di studi.

E’ cioè evidente che l’effettuazione concreta di studi di fattibilità relativi alle varie

tipologie di progetto imporrà una revisione dell’indice-tipo in quanto:

• alcuni paragrafi perdono importanza o addirittura si rivelano inutili e quindi

eliminabili;

• alcuni paragrafi assumono particolare rilievo e richiedono specifico

approfondimento;

• alcuni paragrafi assumeranno un taglio diverso nei differenti contesti, imponendo

l’utilizzo di metodi e tecniche differenti.

In sostanza è indispensabile una opera di personalizzazione dell’indice-tipo, che tenga

conto della tipologia di progetto ed, in certi casi, della specificità del progetto e dei

problemi da affrontare. Per una prima schematizzazione del problema si possono

individuare alcune tipologie di progetto più diffuse, che sono:

• Realizzazione di nuovi sistemi applicativi

• Reingegnerizzazione di sistemi applicativi esistenti

• Realizzazione di nuove infrastrutture tecnologiche

• Reingegnerizzazione di infrastrutture tecnologiche esistenti

• Installazione e diffusione di sistemi applicativi e/o infrastrutture tecnologiche

• Automazione d’ufficio (informatizzazione di base)

• Affidamento all’esterno della gestione operativa dei sistemi

• Formazione informatica

Realizzazione di nuovi sistemi applicativi

I progetti per la realizzazione di nuovi sistemi applicativi, sono i progetti per i quali

l’indice-tipo proposto è utilizzabile con il minor numero di modifiche. Questo perché la

loro realizzazione impatta la quasi totalità delle problematiche esaminate: la maggior

parte delle metodologie presenti in letteratura si è infatti sviluppata guardando a questa

tipologia di progetti. Occorre comunque sottolineare:

48

• l’importanza dell’esame del processo di servizio a cui il sistema è destinato e, di

conseguenza, delle parti di descrizione e diagnosi del processo (flussi,

organizzazione, utenza..), della descrizione del processo revisionato alla luce del

progetto, degli interventi non specificatamente informatici previsti e quindi della

coerenza del programma complessivo di cambiamento;

• l’importanza dell’alternativa “make or buy” in termini di verifica della possibilità di

utilizzo di prodotti standard o di applicazioni sviluppate in altre amministrazioni.

Reingegnerizzazione di sistemi applicativi esistenti

Questa tipologia di progetti prevede sempre la realizzazione di sistemi applicativi ma in

presenza di sistemi già esistenti sui quali è necessario operare in ottica di

reingegnerizzazione.

Poiché la reingegnerizzazione di un sistema applicativo difficilmente si limita ad una

mera operazione tecnologica ma coinvolge in qualche misura anche l’aspetto funzionale,

occorre valutare il peso di questa evoluzione funzionale ed il suo impatto sui processi

operativi.

Se il peso della componente funzionale è consistente, si ritorna al caso di realizzazione

di nuovi sistemi applicativi, con l’ovvia differenza della rilevante importanza della

problematica del riuso delle componenti esistenti.

Se invece il peso funzionale è minore, ci si potrà principalmente concentrare sulle

problematiche tecnologiche (descrizione e diagnosi dell’attuale livello di automazione,

nuova architettura e nuovo ambiente di sviluppo) e sulle problematiche di riuso.

Una parte che diventa di importanza fondamentale è quella relativa all’avvio del nuovo

sistema in cui dovranno essere affrontati e risolti i problemi relativi alla migrazione dei

dati, con l’eventuale obiettivo di operare per la riqualificazione delle informazioni

(verifiche correttezza, completezza ecc.), alla necessità di “parallelo” tra vecchio e

nuovo, con tutte le questioni connesse, e alla necessità di formazione e assistenza agli

utenti per aiutarli nel cambiamento.

Realizzazione di nuove infrastrutture tecnologiche

I progetti tesi alla realizzazione di infrastrutture tecnologiche “orizzontali”, quali reti,

CED ed altro, hanno un legame minore con i processi di servizio, ma tale legame

continua ad esistere: la necessità di nuove infrastrutture tecnologiche non può che

derivare dal fatto che tali infrastrutture sono necessarie per assicurare agli utenti un

miglior servizio informativo.

Occorre quindi individuare gli obiettivi relativi al servizio che si vuole erogare all’utente

finale e alle sue ricadute, attenzione che è alla base dell’individuazione dei benefici.

Nello studio di fattibilità diventa quindi essenziale, oltre alla parte specificatamente

tecnologica (architettura, dimensionamento e quindi capacity planning..), la definizione

dei servizi e dei livelli di servizio che la nuova infrastruttura dovrà garantire e sulla quale

si innesteranno le funzionalità applicative e informative.

Per questa tipologia di progetti si dovrà necessariamente considerare l’alternativa di

“make or buy”, che si sostanzierà nell’esame della possibilità di usufruire dei servizi di

strutture esterne già esistenti. 49

Reingegnerizzazione di infrastrutture tecnologiche esistenti

Questa tipologia di progetti ha lo stesso obiettivo della precedente ma parte da una

situazione in cui le infrastrutture tecnologiche già esistono. Rientrano in questa tipologia

i progetti di migrazione architetturale, ad esempio iniziative di downsizing o di

rightsizing, o i progetti di evoluzione delle reti di un’amministrazione per la migrazione

verso la rete unitaria.

Oltre alle considerazioni già viste per la realizzazione di nuove infrastrutture, occorre

anche sottolineare:

• la necessità di esaminare congiuntamente le problematiche di reingegnerizzazione

dei sistemi applicativi connessi, date le inevitabili conseguenze su di essi;

• l’importanza assunta dalla diagnosi dell’attuale livello di automazione con

l’individuazione di adeguate metriche per esprimere la situazione attuale e attesa dei

livelli di servizio;

• l’importanza delle scelte architetturali e quindi il necessario esame delle alternative

connesse;

• l’importanza della questione del riuso;

• le problematiche di avvio e di parallelo;

• la necessità di formazione del personale informatico e degli utenti, che dovranno

gestire una situazione di profondo cambiamento.

Installazione e diffusione di sistemi applicativi e/o infrastrutture tecnologiche

Questi progetti riguardano l’installazione e la diffusione su una molteplicità di siti di

sistemi già realizzati. L’attivazione di specifici progetti di diffusione hanno senso solo

nei casi in cui tali problematiche assumano particolare rilevanza e in cui quindi il rischio

si concentra proprio su questa fase. Questa condizione è peraltro abbastanza comune

nelle amministrazioni caratterizzate da un forte decentramento operativo.

La necessità di un progetto e di uno studio specifico discende dalla differenza sostanziale

tra i temi da esaminare nella fase di prima realizzazione e quelli da esaminare nella fase

di diffusione, che rischiano di essere sottovalutati se collocati all’interno del medesimo

progetto.

Si tratta pertanto di una tipologia di progetti fortemente atipici rispetto a quelle

precedenti e quindi anche lo studio di fattibilità assume caratteristiche particolari. In

sostanza:

• assumono particolare importanza i vincoli temporali ed economici;

• perdono di significato le parti relative ai requisiti e alle specifiche applicative, in

quanto già risolte nella prima realizzazione;

• le specifiche tecnologiche si orientano al diverso dimensionamento dei sistemi nei

vari siti, in rapporto al carico di lavoro;

• diventano essenziali le parti relative all’avvio dei sistemi, alla formazione e

all’assistenza degli utenti, alla manutenzione;

• sono fondamentali le parti dedicate al piano di lavoro e alla gestione del piano;

50

• l’analisi costi-benefici utilizzerà quanto già prodotto nello studio relativo alla prima

realizzazione, con gli opportuni aggiornamenti;

• le raccomandazioni sulla tipologia di fornitori dovranno valutare (e cercare di

minimizzare) i vincoli sull’utilizzo di prodotti e fornitori della prima realizzazione.

Automazione d’ufficio

Anche i progetti di automazione d’ufficio, tesi alla diffusione dell’informatizzazione di

base, degli strumenti di informatica individuale e dei principali servizi di interoperabilità

tra cui gli strumenti centralizzati di comunicazione (posta elettronica) e di gestione

documenti, hanno una connotazione specifica. In particolare:

• la descrizione e la diagnosi della situazione attuale non vedranno un esame puntuale

dell’insieme dei processi, ma si dovrà focalizzare l’attenzione sulle attività

“orizzontali” (comunicazione, produzione, archiviazione e ricerca documenti,

ricerca informazioni ed elaborazioni individuali o di piccoli gruppi..);

• i requisiti e le specifiche si concentreranno sulle funzionalità e sull’interfaccia

utente;

• la problematica degli standard diventa di importanza capitale;

• le modalità realizzative si dovranno concentrare sulle problematiche di acquisizione,

diffusione, distribuzione, manutenzione;

• diventano essenziali le parti relative alla formazione e all’assistenza degli utenti;

• l’analisi costi-benefici dovrà contenere ipotesi generali sull’aumento di produttività.

Affidamento all’esterno della gestione operativa dei sistemi

Per questi progetti tutto il problema ruota intorno all’alternativa “make or buy” e quindi

all’esame delle alternative. In questo caso quindi i contenuti essenziali dello studio

saranno:

• la definizione dei requisiti in termini di servizi informatici, informativi e gestionali

che dovranno essere acquisiti;

• la descrizione delle specifiche generali di questi servizi;

• la determinazione dei costi della situazione attuale;

• la stima dei costi della soluzione ipotizzata;

• la individuazione e valutazione dei benefici, con particolare riguardo alla

determinazione dell’ammontare del risparmio in termini di personale;

• l’analisi dei rischi (in genere rilevanti) dell’operazione;

• la valutazione dell’alternativa tra affidamento all’esterno e mantenimento della

gestione in proprio ed è proprio quest’ultimo punto che rappresenta il punto focale

dello studio, per la cui risoluzione si effettuano tutte le attività precedenti;

• le raccomandazioni sulla scelta dei fornitori e per la valutazione delle offerte.

51

Formazione informatica

I progetti generali di formazione informatica hanno sempre una forte connotazione di

specificità rispetto all’amb iente in cui si calano e pertanto più deboli sono le indicazioni

generali.

E’ evidente peraltro che la descrizione e diagnosi della situazione attuale dovrà ruotare

intorno alla analisi dei fabbisogni formativi, alla progettazione del piano di formazione e

alla individuazione di una modalità di valutazione dei risultati. In particolare quindi:

• la fase di descrizione della situazione attuale dovrà arrivare alla definizione degli

obiettivi, allo sviluppo di “profili di competenza”, alla determinazione delle

esigenze di formazione (skill gap);

• il progetto di massima dovrà prevedere i requisiti generali del piano di formazione,

le specifiche dei contenuti dei corsi e le tipologie di piano di formazione, gli utenti

interessati;

• un’attenzione particolare dovrà essere prestata alle modalità e agli strumenti di

formazione, considerando anche le possibili alternative (tradizionale, CBT, auto-

apprendimento..)...

• il piano dei corsi e la responsabilizzazione dei responsabili degli utenti dovranno

essere particolarmente curati in quanto costituiscono senz’altro un fattore critico di

successo;

• il piano complessivo di progetto dovrà prevedere modalità di verifica dei risultati;

• l’analisi dei costi dovrà tener conto dei costi nascosti dovuti al tempo dedicato alla

formazione;

• la valutazione dei benefici dovrà basarsi sulle ipotesi di ricaduta in termini di

produttività.

5. Modalità di realizzazione di uno studio di fattibilità

5.1. Le attività per lo studio di fattibilità

Si è già affermato che lo studio di fattibilità deve raccogliere, verificare, completare,

sistematizzare e formalizzare informazioni elaborate in fasi precedenti e da queste

mutuate. Questo significa che ciò che manca o non è adeguato dovrà essere prodotto o

fatto evolvere attraverso attività specifiche. L’organizzazione ed il peso di queste attività

dipendono dal livello di approfondimento già raggiunto in precedenza e nello stesso

tempo i metodi e le tecniche da utilizzare derivano dalla tipologia del progetto in esame.

Da queste considerazioni deriva l'impossibilità di definire un percorso operativo standard

per la produzione dello studio: quello che può essere utile è uno schema di riferimento,

illustrato nella tabella seguente, che può costituire essenzialmente da elemento di

verifica per i percorsi concreti che si definiranno nelle varie situazioni.

52 Verifica con

ATTIVITA' committente

Definizione degli obiettivi e dell'ambito dello studio

Individuazione delle criticità

Stesura dell'indice del documento finale (1)

Individuazione delle risorse necessarie e stesura del piano di lavoro X

Reperimento ed esame della documentazione, completamento

interviste

Stesura della sezione relativa alla situazione attuale X

Revisione dell'indice del documento finale (2)

Elaborazione e prima stesura della sezione relativa al progetto di

massima

Identificazione delle problematiche di alternativa presenti

Sviluppo delle parti legate alle criticità individuate

Revisione dell'indice del documento finale (3) X

Elaborazione delle alternative e delle parti critiche

Prima analisi del rischio e dell'investimento anche in relazione alle X

alternative

Completamento della sezione relativa al progetto di massima

Stesura delle sezioni relative all'analisi del rischio, al progetto

proposto, all'analisi costi-benefici X

Prime ipotesi sulle fasi realizzative

Stesura finale documento

Presentazione documento

Tabella 8 - Attività per lo studio di fattibilità

Come si vede, il lavoro per la produzione dello studio è scadenzato intorno a molteplici

momenti di confronto tra il gruppo di lavoro ed il committente. Attraverso le verifiche

con il committente è possibile infatti superare alcuni dei principali rischi per la buona

riuscita dello studio, rischi che spesso dipendono dalla mancata focalizzazione

dell'ambito del lavoro, da una insufficiente attenzione ai punti di reale criticità, da una

scarsa comprensione degli obiettivi del committente.

Per effettuare proficuamente questa attività di verifica sono necessari degli incontri

formali in cui dovranno essere coinvolti i livelli di responsabilità e competenza necessari

alla piena illustrazione delle finalità del lavoro ed alla assunzione delle decisioni.

53


PAGINE

59

PESO

174.52 KB

AUTORE

Sara F

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Sara F di informazioni apprese con la frequenza delle lezioni di Economia ed organizzazione Aziendale e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Iandoli Luca.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Economia ed organizzazione aziendale

Economia ed organizzazione Aziendale  - Swot Apple
Dispensa
Economia ed organizzazione Aziendale – Bilancio Fiat
Dispensa
Economia ed organizzazione Aziendale - Bilancio Ducati
Dispensa
Economia ed organizzazione Aziendale – Bilancio
Dispensa