Corso di Sistemi Informativi Anno Accademico 2000 - 2001 Trasparenze 8 Gli studi di Fattibilità C. Batini e G. Lazzi.

Presentazione sul tema: "Corso di Sistemi Informativi Anno Accademico 2000 - 2001 Trasparenze 8 Gli studi di Fattibilità C. Batini e G. Lazzi."— Transcript della presentazione:

1 Corso di Sistemi Informativi Anno Accademico Trasparenze 8 Gli studi di Fattibilità C. Batini e G. Lazzi

2 Alla fine della pianificazione …...
L’individuazione delle applicazioni o progetti che l’azienda intende realizzare non esaurisce il processo di pianificazione delle tecnologie di informazione. La realizzazione di un qualunque sistema informativo rappresenta per una azienda un investimento che mobilita risorse: finanziarie umane impiantistiche

3 Come conseguenza ….. La scarsità di tali risorse richiede che vengano effettuate valutazioni sui progetti proposti che portino a dimostrarne la fattibilità e la convenienza economica. Tra tutti i progetti che superano l’esame di fattibilità e convenienza economica è poi necessario effettuare un confronto che stabilisca una scala di priorità. Ogni progetto potrà poi avere diverse soluzioni architetturali tecnico organizzative, per ciascuna delle quali sarà necessario valutare la convenienza economica e la fattibilità.

4 Obiettivi dello studio di fattibilità
Lo scopo dello Studio di fattibilità è quello di analizzare le esigenze informative connesse allo sviluppo di un nuovo progetto definito in linea di massima nella fase di pianificazione, ed arrivare alla individua-zione di: 1. una o piu’ soluzioni architetturali relative alle applicazioni, alle tecnologie e alle soluzioni organizzative.

5 benefici ottenibili nel tempo rischi legati alla realizzazione e
per: 2. fornire alla direzione gli elementi di valutazione necessari per prendere una decisione riguardo alla realizzazione operativa del progetto 3. proporre la soluzione tecnico organizzativa con valutazione dei costi delle soluzioni benefici ottenibili nel tempo rischi legati alla realizzazione e conseguenze del mancato raggiungimento degli obiettivi progettuali.

6 Tipici input allo studio di fattibilita’
1. Piano: progetti e budget, e/o 2. BPR: processi da modificare, e/o 3. Assessment e/o Benchmarking: diagnosi e iniziative di miglioramento Tecnologie ICT Stato attuale del sistema

7 Prodotti dello studio di fattibilita’
Analisi di fattibilita’ tecnico organizzativa e rischi Progetto di massima dei prodotti, dei servizi e della loro qualita’ Costi Benefici Analisi degli investimenti Forma di acquisizione (make or buy e “quale” buy) In caso di buy: Capitolato tecnico e contratto

8 La fattibilità puo’ essere:
Tecnica - Verifica se gli aspetti tecnici della proposta sono effettivamente realizzabili Organizzativa - Verifica se la proposta è realizzabile nell’ambito della organizzazione esistente Economica - Verifica se le risorse necessarie per la realizzazione del sistema (costi) sono giustificate dai ritorni prevedibili,espressi in termini di benefici Temporale - Verifica se il sistema è realizzabile nei termini in cui continua ad essere utile alla organizzazione Motivazionale - Verifica l’effettivo grado di accettabilità che gli utenti potranno esprimere rispetto al nuovo sistema, una volta realizzato

9 Progetto di massima dei prodotti e servizi Contiene:
Specifiche funzionali dei prodotti e servizi e loro qualita’ Architettura dati Architettura del software Architettura della infrastruttura tecnologica Architettura della rete

10 A seconda delle diverse tecnologie disponibili, possono esistere diverse soluzioni alternative

11 Tipologie di studi di fattibilita’

12 A seconda del contesto della iniziativa, i casi piu’ frequenti riguardano:
Nuovi sistemi applicativi Reingegnerizzazione sistemi applicativi esistenti Nuove infrastrutture tecnologiche Reingegnerizzazioni infrastrutture tecnologiche Installazione e diffusione Automazione d’ ufficio Affidamento all’ esterno attivita’ di gestione Formazione

13 Esistono poi diverse tipologie di studi a seconda del tipo di input e del tipo di output

14 Primo tipo: studio a partire da soluzione data
Input: soluzione tecnico organizzativa gia’ data (ad esempio dal bpr) Output: fattibilita’ della soluzione rischi costi benefici make or buy tipo di progetto

15 Secondo tipo: scelta tra diverse soluzioni
Input: diagnosi dell’ esistente Output intermedio: un insieme di soluzioni tecnico organizzative Output finale: una soluzione scelta analisi comparata della fattibilita’, dei rischi, dei costi, dei benefici scelta del make or buy scelta del tipo di progetto

16 Terzo tipo: analisi di diverse soluzioni
Input: diagnosi dell’ esistente Output intermedio: un insieme di soluzioni tecnico organizzative Output finale: analisi comparata della fattibilita’ (senza scelta della soluzione), dei rischi, dei costi, dei benefici delle diverse soluzioni scelta del make or buy scelta del tipo di progetto

17 Quando esistono diverse alternative lo studio e’ segmentato in:
Individuazione delle alternative e definizione di progetti di larga massima Valutazione costi benefici rischi per tutte le alternative Scelta della alternativa Produzione progetto di massima, capitolato, contratto

18 Possibili conclusioni dello studio di fattibilita’
Il progetto non si puo’ realizzare il progetto si puo’ realizzare, ma basta un intervento organizzativo Il progetto si puo’ realizzare con questa soluzione, con questi costi, con questi rischi Il progetto si puo’ realizzare, con queste soluzioni comparate, scegli tu

19 Parti o fasi dello studio di fattibilita’: una metodologia per la sua costruzione
Parte prima - Progetto di massima della soluzione Parte seconda - Analisi del rischio Parte terza - Analisi costi-benefici Parte quarta: produzione capitolato e contratto e scelta del fornitore

20 Parte prima: Progetto di massima della soluzione

21 Si compone di tre parti Definizione delle soluzioni alternative
Analisi di impatto aziendale Definizione della qualita’ attesa dal progetto (vedi parte sulla qualita’)

22 2.1 - Definizione delle soluzioni alternative

23 Le alternative riguardano
Il livello di dettaglio a cui fermare lo studio Requisiti di servizio ovvero Specifiche, e a quale livello Le soluzioni tecnologiche ed applicative Le modalita’ di realizzazione

24 Requisiti vs specifiche
La fornitura puo’ essere vista come a. un insieme di beni che dovranno poi essere gestiti da personale, ovvero b. un servizio, di cui si specificano i livelli e le qualita’, senza entrare nel merito del modo in cui il fornitore si organizza Esempio1: personal computer Esempio 2: rete geografica

25 Requisiti vs specifiche
Anche nel caso o per la parte di fornitura che e’ vista come insieme di tecnologie, lo studio di fattiibilita’ si puo’ fermare ad un livello intermedio Il capitolato (documento che descrive ai fornitori le caratteristiche del sistema su cui basare la offerta) recepisce questo livello intermedio I fornitori nella offerta tecnica arricchiscono le specifiche fornendo specifiche e soluzioni complete (valore aggiunto)

26 Esempio: accesso a basi di dati via web
Lo studio specifica che il DBMS deve essere relazionale con interfaccia web Le offerte specificano il tipo di RDBMS con le suite di ambienti di sviluppo e le soluzioni per il collegamento tra server dati e server web

27 Soluzioni tecnologiche ed applicative
Aspetti tecnologici Architettura di rete Architettura elaborativa Ambienti di sviluppo Aspetti applicativi Architettura dati Architettura applicativa Architettura di sicurezza Interfaccia utente Interfaccia verso altri sistemi Aspetti di servizio specifica dei servizi richiesti e livelli di servizio

28 Modalita’ di realizzazione
Per ogni servizio e prodotto richiesto Fare in proprio Affidarsi a fornitori esterni Riusare Queste alternative possono essere esaminate e valutate nello SF e la scelta preferenziale può costituire: elemento vincolante (diventa requisito della richiesta di fornitura) elemento di preferenza nella scelta della fornitura

29 Alternative tipiche in un progetto di sviluppo software per cambio di architettura
Sviluppo ad hoc Personalizzazione di prodotti ERP Affidamento ad un application Service provider Porting del software nella nuova architettura Reingegnerizzazione del software, attraverso ridocumentazione (reverse engineering) Soluzione mista Riuso dei dati Riuso delle specifiche dati/funzioni Ricostruzione delle specifiche dati/funzioni

30 Esempio 1 Realizzazione di un sistema informativo di manutenzione per uno stabilimento della azienda A. La sede centrale della azienda dispone già di un elaboratore per le procedure della intera azienda.

31 Esempio 2 Il Ministero delle Finanze deve acquisire ogni anno circa 20 milioni di dichiarazioni dei redditi dei soggetti fiscali Attualmente i tempi di acquisizione sono elevati, il tasso di errore porta a lunghi ricicli Alternative: Tramite data entry (soluzione precedente potenziata) Tramite acquisizione telematica Tramite dischetti Tramite acquisizione ottica

32 Esempio 3: carta di identita’
I comuni dovranno acquisire ogni anno 2-3 milioni di immagini di persone per fornire la carta di identita’ Tali acquisizioni possono essere fatte con: scanner su fotografia portata dal soggetto fotocamera analogica fotocamera digitale videocamera con costi e qualita’ diversa

33 2.2 - Analisi di impatto aziendale

34 Attivita’ e decisioni 1. Identificare le aree di utenza coinvolte, gli obiettivi e gli effetti per le stesse derivanti dal progetto 2. Sviluppare un piano organizzativo della soluzione definendo l’eventuale nuova struttura organizzativa delle unità interessate le eventuali modifiche normative interne od esterne gli eventuali sistemi informativi o procedure interconnesse

35 Continua 3. Sviluppare un piano del personale della soluzione definendo le competenze necessarie per la gestione del nuovo sistema le alternative di reperimento delle risorse umane le implicazioni in termini di addestramento, crescita e sviluppo professionale

36 Parte terza analisi del rischio

37 Scopo della analisi del rischio
Individuare in maniera precisa i rischi connessi allo sviluppo di una nuova applicazione e' fondamentale, e l'esito di questa quantificazione puo' modificare scelte che sotto altri aspetti si rivelano piu' economiche o piu' efficaci. Di solito questo problema non viene affrontato seriamente nella fase di analisi

38 Dunque l’ analisi del rischio fornisce elementi per
la decisione finale riguardo al finanziamento del progetto il piano di qualità possibili iniziative di riduzione del rischio Esito finale: attribuzione della classe di rischio

39 Classificazione dei rischi
• rischi tecnologici, cioe' collegati alla tecnologia utilizzata nella applicazione, e • rischi organizzativi, cioe' legati all'impatto che il sistema puo' avere sulla organizzazione. rischi finanziari, generati dalla indisponibilita’ di risorse finanziarie rischi legislativi, generati dal mancato adempimento a norme di legge

40 I rischi tecnologici riguardano
• il tipo di progetto • il tipo di ambiente di sviluppo (es. realizzare una applicazione in un linguaggio tradizionale comporta meno rischi che usare un ambiente di sviluppo di sistemi esperti), • il tipo di impianto (es. si puo' decidere di usare una memoria di massa di nuova concezione solo quando vi sia un adeguato numero di esperienze gia' consolidate presso altre organizzazioni), • l' esperienza richiesta, • il tempo di sviluppo (in diversi casi non prevedibile in maniera precisa), •i costi di sviluppo.

41 I rischi organizzativi riguardano
• la possibile rigidita' dell' ambiente organizzativo nell’ accettare i cambiamenti connessi alla adozione di nuove procedure, • l' impatto sull' utente finale, • la tipologia del ciclo di vita della procedura e • la frequenza e l' importanza che ha la procedura per gli obiettivi aziendali (es. una applicazione in tempo reale di controllo di un impianto e' evidentemente piu' critica di una applicazione gestionale tradizionale).

42 Rischi finanziari, relativi a
Durata superiore al periodo di finanziamento Indeterminatezza nella copertura dei costi di gestione Incertezza sui costi complessivi

43 Le Classi di Rischio in ambiente gestionale
Classe A Il servizio software è caratterizzato da una elevatissima criticità dovuta alle possibili responsabilità connesse alla importanza dei dati elaborati ed al loro potenziale impatto sull'esterno. Un malfunzionamento del prodotto può provocare danni gravi e diffusi verso terzi oppure causare una consistente perdita di immagine dell'Amministrazione e di fiducia verso i servizi da essa offerti. Classe B Il servizio software implica limitate responsabilità in caso di malfunzionamenti, pur trattando dati rilevanti e/o informazioni riservate. Un malfunzionamento del prodotto può provocare danni gravi e/o una certa perdita di immagine dell'Amministrazione verso l'esterno. Classe C: Il prodotto offre in generale un servizio che gestisce informazioni non critiche, per il quale un eventuale malfunzionamento comporta la sola perdita del lavoro svolto, o danni limitati.

44 Una metodologia per la analisi dei rischi (Banca d’ Italia)
• Individua un insieme di fattori di rischio • Per ogni fattore individua un insieme di parametri quantificabili • Quantifica per ciascuno il livello di rischio (alto/ medio/basso)

45 Fattore di rischio: complessita’ gestionale
E’ la difficoltà di definire il disegno organizzativo, applicativo e tecnico di un progetto In generale è inversamente proporzionale a quanto siano definiti e stabili e privi di ambiguita’ gli input, gli output e le regole/modalità di elaborazione.

46 Parametri da esaminare:
I - Interfunzionalità: Il progetto avrà come utilizzatori uffici diversi della Amministrazione che determineranno i vincoli da rispettare. 2 - Interventi su organizzazione e ruoli: Il progetto richiede una ristrutturazione organizzativa/ normativa. 3 - Intervento su procedure di lavoro: Il progetto richiede la modifica delle attuali procedure operative ed i1 ridisegno dei flussi informativi.

47 Continua 4 - Livello di inesperienza dell'utente sulla problematica:
L'utilizzatore finale del sistema non conosce le problematiche applicative di cui verrà investito. 5 - Livello di inesperienza dell’ Amministrazione sulla problematica: All'interno dell'Amministrazione non c'è conoscenza della problematica applicativa: l'Amministrazione vuole attivare delle nuove funzioni progettandole ex-novo. 6 - Partecipazione e supporto direzionale:Per la definizione dei requisiti organizzativi e funzionali del nuovo sistema è necessario il supporto e la partecipazione della Direzione dell'Amministrazione.

48 Fattore di rischio: innovazione tecnologica
Rappresenta la difficoltà di adattamento dell'ambiente alla evoluzione delle tecnologie offerte dal mercato; è inversamente proporzionale alla esperienza specialistica disponibile sui problemi tecnici del progetto. Parametri da esaminare: 1- Utilizzo di nuovo hardware: Il progetto utilizzerà hardware di base nuovo rispetto all'esperienza disponibile 2 - Utilizzo di nuovo software di base: Es. il progetto utilizzerà un sistema operativo, un TP monitor, un compilatore non conosciuti. 3 - Utilizzo di nuovo software di ambiente: Il progetto utilizzerà un DBMS non conosciuto.

49 Continua 4 - Utilizzo di soluzioni in ambiente TLC: Il progetto attua soluzioni basate sull'interconnessione, sull'uso di protocolli di reti, ecc. non noti. 5 - Necessità di software ad hoc: Realizzazione ex-novo di software di base, di ambiente, di telecomunicazioni o di interfaccia per lo sviluppo di applicazioni speciali.

50 Fattore di rischio: dimensione
E' la valutazione della quantità di risorse coinvolte nel progetto Parametri da esaminare: 1 - Numero di persone: E' il numero di persone (tecnici ed utenti) coinvolte nel coordinamento del progetto 2 - Dimensione tecnologica: E' il numero di mesi-uomo totali (utente, interni, esterni 3. Dimensione economica: impegno economico espresso in miliardi, per lo sviluppo del progetto

51 Come ridurre il rischio
Segmentare il progetto Ripartire il rischio con i fornitori es prezzi/risparmi unitari garantiti costi “a corpo” o per unita’ di prodotto prefissati Assicurare la copertura finanziaria dell’ investimento accantonamenti o riserve prudenziali per imprevisti o per tipologia di rischio margini temporali di riserva a fronte di rischi di maggiori tempi

52 Segmentare il progetto

53 Studio di fattibilità e “progetti impossibili”
Sono “impossibili” quei progetti per i quali la distanza tra stato iniziale e stato finale è troppo elevata per garantire livelli di rischio accettabili. In genere tale distanza deriva: da insufficienti elementi di conoscenza della situazione da un elevato grado di incertezza da un elevato grado di complessità

54 Rischio connesso alla durata e complessita’ del progetto

55 Per superare tale situazione lo SF può:
modificare lo stato iniziale (recuperando e incrementando la conoscenza della situazione attuale, diminuendo incertezza o governando la complessità), attreverso specifiche attività “spezzare” il progetto prevedendo progetti parziali (evolutivi in caso di incertezza o incrementali in caso di complessità) al posto del progetto unico: vedi in seguito prevedere un piano di lavoro che comprenda specifici punti di decisione (in tal caso il progetto deve prevedere modalità contrattuali coerenti)

56 Alternative sulla modalita’ di realizzazione
Soluzione unica: quando e’ realizzato con una unica attivita’ continuativa Realizzazione incrementale: Realizzazione e collaudo avvengono per parti successive, ma i requisiti non cambiano nel corso della realizzazione Realizzazione evolutiva: Per parti successive, con i requisiti influenzati dal collaudo o dalla sperimentazione

57 Il ciclo a spirale di Boehm

58 Guida alla scelta della soluzione

59 Esempio: progetto protocollo prefetture
Scopo: realizzare il protocollo e workflow informatizzato su tutti i processi per tutte le unita’ organzzative (100 prefetture e 5 direzioni generali del ministero degli interni)

60 Segmentazione intervenuta
Prima fase: 1 prefettura (Pavia) sul solo protocollo Seconda fase: estensione a Pavia sul workflow su 5 processi Terza fase: estensione a tutte le prefetture e al ministero sui 5 processi (es: invalidi civili, porto d’ armi) Quarta fase: estensione del worflow a tutti i processi significativi

61 Parte quarta: Analisi costi-benefici

62 E’ composta da tre parti
Analisi dei costi Analisi dei benefici Analisi degli investimenti (confronto costi benefici): vedi corsi di economia

63 Analisi dei costi A questo punto dello studio di fattibilita’ siamo in grado di classificare le voci di fornitura in base alle seguenti voci Tra poco vedremo metodi per la quantificazione dei costi per le varie voci

64 Analisi dei benefici

65 Benefici: classificazione
Tangibili: possono essere espressi in termini monetari. Es. riduzione del personale Quantificabili: possono essere espressi in termini diversi da quelli monetari facendo riferimento agli indicatori di efficienza ed efficacia dei processi Es. Riduzione delle code agli sportelli Es. riduzione del tempo necessari oad ottenere un documento Intangibili: possono essere valutati solo in base a considerazioni qualitative, aziendali, sociali o politiche

66 Tipologie di benefici tangibili
Riduzione della risorsa umana Riduzione di immobilizzi, cioè del rapporto valore vendite/valore magazzino Miglioramento del servizio Riduzione dei costi del materiale acquistato Riduzione dei costi del personale impiegatizio Riduzione dei costi di lavoro straordinario Riduzione dei fabbisogni di personale aggiuntivo Riduzione dei costi di duplicazione ed immissione dei dati Riduzione dei costi dovuti a dati erronei

67 Benefici tangibili: continua
riduzione dei costi di attrezzature d’ufficio riduzione delle scorte in eccesso riduzione dei livelli di scorte di sicurezza necessarie miglioramento della produttività del personale semplificazione delle procedure miglioramento delle comunicazioni interufficio riduzione del tempo richiesto per la produzione di documenti miglioramento dei rendimento dei venditori

68 Benefici intangibili Miglioramento del servizio alla utenza esterna
Miglioramento della immagine della organizzazione Maggiore motivazione e autonomia del personale Migliore disponibilita’ della informazione Affidabilita’ della informazione Riduzione dei supporti cartacei Miglioramento della metodologia di lavoro Efficacia e rapidita’ del processo decisionale