Valutazione e gestione di sistemi
informatici
Dispense per l’Anno Accademico 2008-2009
Riccardo Colombo
Urbino, 22 dicembre 2008
1. INTRODUZIONE ............................................................................................... 5
2.
1.1.
Presupposti del Corso .................................................................................................... 5
1.2.
Obiettivi del Corso ........................................................................................................ 10
1.3.
Articolazione del Corso .................................................................................................. 12
NOZIONE DI ARCHITETTURA INFORMATICA ................................................ 14
2.1.
2.1.1.
Premessa ............................................................................................................................ 14
2.1.2.
Componenti dell’architettura informatica................................................................................. 18
2.2.
Le Definizioni di architettura informatica ........................................................................ 24
2.2.1.
L’Approccio Tecnologico ........................................................................................................ 24
2.2.2.
L’ Informatica Gestionale ...................................................................................................... 28
2.2.3.
Il Portafoglio applicativo........................................................................................................ 36
2.2.4.
L’approccio sistemico ............................................................................................................ 38
2.3.
3.
Definizione assunta come riferimento............................................................................. 14
Le teorie organizzative .................................................................................................. 41
2.3.1.
La scuola decisionale ............................................................................................................ 41
2.3.2.
La scuola transazionale ......................................................................................................... 42
2.3.3.
La scuola dell’azione organizzativa ......................................................................................... 43
2.3.4.
La scuola della prospettiva strategica ..................................................................................... 45
VALUTAZIONE DEI SISTEMI INFORMATICI ................................................... 47
3.1.
Evoluzione dell’ICT e suo impatto sui sistemi di valutazione............................................. 47
3.1.1.
L’era dell’automazione .......................................................................................................... 48
3.1.2.
L’era della produttività .......................................................................................................... 48
3.1.3.
L’era del modello di business interno ...................................................................................... 49
3.1.4.
L’era del modello di business interno-esterno .......................................................................... 50
3.2.
La valutazione di diverse alternative di architettura informatica ....................................... 52
3.2.1.
Il metodo di valutazione: principi generali ............................................................................... 52
3.2.2.
Analisi del contesto ed individuazione delle alternative ............................................................. 58
3.2.3.
Grado di adeguatezza delle componenti dell’architettura informatica ......................................... 59
3.2.4.
Individuazione dei criteri di valutazione .................................................................................. 60
3.2.5.
Analisi delle soluzioni offerte da ciascuna delle Architetture ...................................................... 71
3.2.6.
Attribuzione di un giudizio di sintesi delle alternative di Architettura .......................................... 72
3.3.
Determinazione dei costi e dei benefici .......................................................................... 73
2
3.3.1.
Definizione di costo del ciclo di vita ........................................................................................ 73
3.3.2.
Determinazione dei benefici .................................................................................................. 76
3.4.
4.
3.4.1.
Premessa ............................................................................................................................ 80
3.4.2.
Le tecniche finanziarie .......................................................................................................... 81
3.4.3.
L’Approccio Sistemico ........................................................................................................... 88
3.4.4.
L’Approccio Strategico .......................................................................................................... 90
3.4.5.
L'Approccio Organizzativo ..................................................................................................... 95
3.4.6.
Conclusioni in merito all’approccio strategico ed organizzativo .................................................. 97
SELEZIONE DEl SOFTWARE E DEI FORNITORI .............................................. 99
4.1.
Determinazione dei costi di un software ......................................................................... 99
4.1.1.
Determinazione dei costi di un pacchetto standard .................................................................. 99
4.1.2.
Determinazione dei costi di sviluppo del software .................................................................. 103
4.2.
Le modalità di selezione dei prodotti, dei servizi e dei fornitori....................................... 106
4.2.1.
Il metodo: principi generali ................................................................................................. 106
4.2.2.
Definizione delle esigenze informative .................................................................................. 108
4.2.3.
Richieste di Offerta ............................................................................................................. 113
4.2.4.
Attività di Selezione dei fornitori e dei software ..................................................................... 114
4.3.
L’ approccio basato sulla check-list .............................................................................. 115
4.3.1.
Il metodo: principi generali ................................................................................................. 115
4.3.2.
Check-list basata sull’analisi dei requisiti funzionali e tecnici .................................................... 115
4.3.3.
Check-list basata sui moduli applicativi. ................................................................................ 116
4.3.4.
Check list “ semplificata” ..................................................................................................... 117
4.4.
5.
Sintesi della letteratura sull’argomento .......................................................................... 80
I contratti di servizi informatici .................................................................................... 118
4.4.1.
Principi generali ................................................................................................................. 118
4.4.2.
Oggetto del Contratto ......................................................................................................... 122
4.4.3.
Livelli del servizio ............................................................................................................... 123
4.4.4.
Durata del contratto : recesso e risoluzione .......................................................................... 124
4.4.5.
I corrispettivi del servizio .................................................................................................... 125
4.4.6.
La tutela della proprietà intellettuale .................................................................................... 126
4.4.7.
Le clausole di riservatezza ................................................................................................... 127
4.4.8.
Consegna, collaudo e accettazione ....................................................................................... 128
GESTIONE DEI PROGETTI INFORMATICI .....................................................129
5.1.
5.1.1.
Le finalità del project management .............................................................................. 129
Definizione di progetto ........................................................................................................ 129
3
5.1.2.
5.2.
ll Preventivo di Progetto ............................................................................................. 136
5.3.
Articolazione in unità elementari di un progetto ............................................................ 138
5.3.1.
Definizione di WBS ............................................................................................................. 138
5.3.2.
Riaggregazione delle WBS: la matrice dei prodotti e delle responsabilità .................................. 143
5.3.3.
Collocazione temporale delle attività..................................................................................... 146
5.4.
La Struttura di Progetto .............................................................................................. 146
5.5.
La Gestione del Cambiamento ..................................................................................... 150
5.5.1.
Formazione come strumento del cambiamento ...................................................................... 150
5.5.2.
Diverse tipologie di intervento formativo ............................................................................... 153
5.6.
6.
Peculiarità di un progetto informatico ................................................................................... 131
Gestione del cambiamento: riferimenti teorici ............................................................... 156
5.6.1.
Sistemi informativi e cambiamento ....................................................................................... 156
5.6.2.
Definizione di Cambiamento ................................................................................................ 157
5.6.3.
Differenti tipologie di cambiamento ...................................................................................... 159
5.6.4.
La dimensione emotiva e quella del potere............................................................................ 162
5.6.5.
Realizzare lo sviluppo organizzativo ...................................................................................... 165
5.6.6.
Considerazioni di sintesi ...................................................................................................... 166
Allegati ......................................................................................................168
6.1.
Allegato 1 applicazione del metodo ad un caso ............................................................. 168
6.1.1.
Il Contesto ........................................................................................................................ 168
6.1.2.
Descrizione dell’architettura informatica................................................................................ 169
6.1.3.
Individuazione delle diverse alternative di architettura ICT ..................................................... 171
6.1.4.
Analisi del processo di valutazione ....................................................................................... 172
6.1.5.
Valutazione di sintesi delle diverse alternative di architettura IT .............................................. 179
6.2.
Allegato 1 Analisi preventivi di controllo di gestione ...................................................... 179
6.2.1.
Premessa .......................................................................................................................... 179
6.2.2.
Analisi delle offerte ............................................................................................................. 180
6.2.3.
Analisi dei preventivi ........................................................................................................... 183
6.3.
Allegato 2 Documenti di offerta e di contratto .............................................................. 186
6.3.1.
Documento di definizione delle specifiche funzionali .............................................................. 186
6.3.2.
Documento di Disciplinare tecnico ........................................................................................ 193
6.4.
Allegato 3 Esempi di check list..................................................................................... 201
6.4.1.
Check list basata sulle specifiche funzionali ........................................................................... 201
6.4.2.
Check list basata sui moduli ................................................................................................ 211
6.4.3.
Check list semplificata......................................................................................................... 213
4
1. INTRODUZIONE
1.1. Presupposti del Corso
Secondo una ricerca1 svolta negli Stati Uniti, “ meno del 20% delle organizzazioni
considera i costi e i benefici di un sistema informativo prima di prendere una decisione
in merito al suo sviluppo” . Uno studio relativo a 13.000 progetti di Information
Technology ha evidenziato come solo il 34% di questi progetti sia stato
completato nei tempi previsti: mediamente un progetto eccederebbe del
43% il budget dei costi e dell’82% gli obiettivi temporali assunti
inizialmente.2 Peraltro i progetti informatici risultano tra i più frequenti casi di
insuccesso nell’ambito di un panorama, generalmente poco felice, delle modeste
performance degli investimenti, caratterizzati spesso da scostamenti negativi tra
aspettative e risultati attesi3.
Il mancato rispetto dei costi e dei tempi è solo uno dei problemi. In realtà gli effetti
negativi più rilevanti del fallimento dei progetti in Information Comunication Technology
(di seguito denominata ICT) riguardano il sotto utilizzo dei nuovi sistemi informativi da
parte degli utenti, con il risultato di non conseguire i benefici attesi e di non assicurare,
quindi, un adeguato ritorno ad un investimento, spesso di importo anche elevato.
Si tratta del noto IT productivity paradox4. Numerosi studi e ricerche, portate a termine
in questi ultimi anni in vari paesi industrializzati sul tema della produttività, hanno
documentato come gli investimenti in nuove tecnologie (ICT) non diano luogo ai
1
Ajay Das “ E-provider evaluation: an esploratory study” in International Journal of Technology Management n. 1
2004 pag.47
2
Charalambos L. Iacovou e Albert S. Dewter “ Turning around runaway information technology projects” in California
Management Review n.4 2004 pag.69; l’entità e la frequenza di fallimenti nel settore IT sono citate anche da
Vincenzo Comito in “ Perché i progetti falliscono “ in Sviluppo e Organizzazione n. 211 Settembre/Ottobre 2005
3
Vincenzo Comito, Perché falliscono i progetti in Sviluppo ed Organizzazione 2005
4
Tony Murphy “ Achieving business value from technologies “ Gartner 2002 pag. XV ; M. Lynne Markus “
Technochange management:using IT to drive organizational change“ Journal of Information Technology n.19 2004
pag. 12
5
rendimenti attesi se non vengono attuati, simultaneamente, cambiamenti tanto nel
disegno organizzativo delle imprese quanto nelle pratiche lavorative5.
Non si sono, tuttavia, ancora fornito soluzioni conclusive sotto il profilo delle
metodologie e dei strumenti da adottare ai fini di migliorare le performance dei progetti
relativi ai sistemi informatici. L’ampia letteratura sull’argomento6 e la prassi aziendale
forniscono, tuttavia, un’indicazione univoca e ormai non più contestata: è indispensabile
rinforzare le strutture aziendali7 dedicate ai sistemi informativi,fornendole delle
necessarie metodologie e competenze per governare gli investimenti in ICT.
La diffusione di applicativi gestionali realizzati in una logica di pacchetti standard, l’idea
che i sistemi informativi costituiscano costi indiretti, e quindi non legati al
prodotto/servizio, l’intensità dell’innovazione tecnologica, che rende rapidamente
obsolete le competenze interne all’azienda, sono tutti fattori, che, insieme con altri,
hanno indotto ad esternalizzare quote crescente delle attività relative allo sviluppo e alla
gestione dei sistemi informativi con un progressivo indebolimento delle Direzioni e degli
Uffici preposti all’ICT.
Non esistono più capacità di programmazione all’interno dell’organizzazione, a meno che
il software non sia parte integrante del prodotto/servizio offerto dall’azienda. Il presidio
delle capacità sistemistiche, ossia di analisi e progettazione dei sistemi informativi, si è
ridotto a poche persone nelle grandi aziende ed è di fatto inesistente nelle piccole e
medie imprese, con la conseguenza di provocare una diffusa incapacità ad assicurare
un’efficace interfaccia rispetto ai fornitori esterni, così come a svolgere funzioni di “
osservatorio tecnologico”.
5
Nicola Acocella, Riccardo Leoni “ La tecnologia da sola non basta” 25 novembre 2008 in www.sbilanciamoci.info
6
Già nel 2000 erano state censite oltre 1.000 pubblicazioni sul tema della valutazione dei sistemi informatici, Frank
Bannister, Dam Remenyi, Journal of Information Technology, n. 3 2000, pag. 231
7
Ovviamente, l’angolo di visuale è quello dell’azienda utilizzatrice di prodotti e servizi informatici, che deve quindi
rapportarsi ai fornitori, alle software house e ai loro partner. Le problematiche sono poi similari, anche se non
identiche, nel mondo dell’impresa così come in quello delle organizzazioni no profit e pubbliche. Per questo motivo e
per semplicità terminologica, “organizzazione”, “azienda” ed “impresa” verranno utilizzati come sinonimi.
6
Il ruolo del personale ICT all’interno delle aziende si riduce spesso a quello di “
amministratore della rete”, che è impegnato per la maggior parte del proprio tempo in
interventi di assistenza agli utenti sui problemi relativi alla rete, all’office automation e
agli applicativi aziendali, potendo dedicare poche energie alla valutazione e allo sviluppo
dei sistemi informatici. Di conseguenza, investimenti strategici e di importo finanziario
anche rilevante vengono portati avanti in risposta a sollecitazioni episodiche (spesso su
pressioni delle stesse software house) e senza un approccio strutturato, delegando,
paradossalmente, allo stesso fornitore esterno la selezione del software e la gestione
della sua implementazione in azienda.
Il meccanismo di scelta di un nuovo software è spesso quello descritto da Tony
Murphy8: si analizzano le “ demo” di alcuni fornitori, che esaltano, ovviamente, le
funzionalità del sistema offerto sottolineandone la semplicità per quanto riguarda
l’installazione e l’operatività; si sceglie una delle soluzioni offerte sulla base di un
preventivo del fornitore, che è spesso poco confrontabile rispetto a quello dei
concorrenti e presenta numerosi aspetti scarsamente definiti (per esempio, gli impegni
del fornitore per quanto riguarda l’assistenza e la manutenzione post-vendita); si affida
l’implementazione del sistema al personale specialistico ICT, se non allo stesso
fornitore, mentre l’introduzione presso gli utenti finali viene ricondotta ad una generica,
e spesso limitata, attività di formazione.
Questo approccio è sbagliato sotto il profilo del metodo e dei ruoli coinvolti. Sotto il
profilo metodologico, non si risponde in modo strutturato ad alcune questioni
fondamentali.
Una prima domanda da porsi è la seguente: qual’ è l’architettura informatica più efficace
per sostenere il posizionamento dell’azienda e le sue strategie di sviluppo ?
E’ questo il tema della valutazione e gestione del portafoglio informatico, che viene
spesso totalmente trascurato dalle aziende, e non solo da quelle di piccole dimensioni.
Si pensi a come è stato affrontato il tema dell’integrazione dei processi amministrativi.
8
Tony Murphy “ Achieving business value from technologies “ Gartner 2002 pag. 119-126
7
Si è ricorso, di fatto, a piattaforme tecnologiche integrate (i famosi ERP), privilegiando
tra l’altro un fornitore (Sap), con il risultato di “ distruggere “ gli applicativi gestionali
esistenti, di affrontare investimenti molto costosi e impegnativi sotto il profilo delle
risorse umane coinvolte e di trovarsi poi a dover sostenere ulteriori interventi ( in
hardware e in software complementari, per esempio di Business Intelligence) per
ottenere “ le grandi cose “ promesse. “ Con il senno di poi “ e alla luce degli elevati costi
sostenuti e dei modesti benefici ottenuti occorre chiedersi se erano state valutate
alternative all’adozione dell’ERP ( per esempio, basate sull’integrazione mediante
interfaccia di applicativi esistenti e il potenziamento di quelli più obsoleti); alternative
che fossero più compatibili con il modello di business, con le risorse finanziarie
disponibili, con la cultura aziendale e con la stessa instabilità dell’assetto istituzionale e
societario (è capitato spesso che investimenti significativi in ERP siano annullati da
acquisizioni o trasformazioni aziendali).
Una seconda domanda da porsi è la seguente:
che cosa ci si aspetta dal nuovo
software e quanto si è in grado di ottenere dalla nuova soluzione informatica ?
E’ questo il tema della selezione del software e del fornitore, una volta che è stata
verificata la sua coerenza con l’architettura informatica dell’azienda. Poiché sono
presenti sul mercato numerosi applicativi che apparentemente forniscono le stesse
funzionalità, è forte la tentazione di acquistare un sistema per emulazione, sulla base
della considerazione che “ c’è una ragione perché un particolare software ha la
maggiore quota di mercato“9. Questo approccio conduce spesso ad una “ apparente
software selection”, che sembra rispondere più a procedure aziendali, che richiedono di
consultare più fornitori, che ad una reale esigenza di approfondimento e di verifica. Da
questo approccio derivano alcune conseguenze di rilievo: viene spesso scelto un
software, le cui caratteristiche non si sposano con le peculiarità, infrastrutturali,
operative e culturali dell’azienda; non vengono identificati in modo puntuale i requisiti
funzionali e prestazionali dando origine ad un capitolato tecnico farraginoso e lacunoso;
si redige un contratto con il fornitore, che non è in grado di definire con la necessaria
precisione le responsabilità di quest’ultimo.
9
Carol A. Ptak e Eli Schragenheim “ Erp, tool, techniques and applications for integrating the supply chain” St. Lucie
Press 2004, pag. 287
8
Occorre anche chiedersi, una volta scelto il software più opportuno: in che modo
assicurare il rispetto dei costi e dei tempi previsti a budget e soprattutto evitare di
pervenire ad un sistema informatico, che risulti sotto utilizzato e non allineato con le
esigenze dell’organizzazione ?
E’ questo il tema dell’applicazione delle tecniche di project management ai progetti
informatici, che è reso particolarmente complesso dal carattere pervasivo degli
investimenti in ICT, che modificano radicalmente il modello organizzativo aziendale10.
Esiste, infatti, una potenziale contraddizione tra gli investimenti in informatica,
generalmente tendenti verso l’integrazione e progettati sulla logica orizzontale dei
processi,e
le
caratteristiche
organizzative
prevalenti
(basate,ancora,sulla
specializzazione professionale, sulla dimensione verticale e sulla chiusura del sistema
azienda verso l’esterno). Questa contraddizione si manifesta, innanzitutto, in una
elevata personalizzazione degli applicativi gestionali per renderli più vicini al tradizionale
modo di operare dell’organizzazione, con il conseguente incremento dei costi e
slittamento dei tempi. In secondo luogo si incontrano numerose resistenze
all’introduzione dei nuovi sistemi informativi, che vengono ricondotti alle tradizionali
modalità di lavoro, riducendone di conseguenza i benefici e pervenendo spesso a
soluzioni ben differenti da quelle prospettate.
Dal punto di vista dei ruoli coinvolti, è interessante riportare le considerazioni di due
esperti di ERP11 in merito all’esigenza di una figura “ indipendente” nella valutazione e
gestione dei sistemi informativi. “ Molti fornitori offrono un servizio per sviluppare le
specifiche per l’azienda così che possono essere individuate le soluzioni più appropriate
e più aderenti alle caratteristiche aziendali. La conseguenza è che la soluzione
raccomandata è molto probabilmente quella che può portare avanti il fornitore. Se il
problema principale nella selezione di un sistema è di assicurare l’obiettività, occorre
evitare di usare lo stesso fornitore per redigere le specifiche del sistema e per poi
10
Esiste un’amplissima letteratura su questo tema, che ha condotto alla nozione, suggestiva ma di modesti risvolti
pratici, di “tecnochange management” elaborata da M. Lynne Markus “ Technochange management:using IT to drive
organizational change“ Journal of Information Technology n.19 2004 pag. 12
11
Carol A. Ptak e Eli Schragenheim “ Erp, tool, techniques and applications for integrating the supply chain” St. Lucie
Press 2004, pag. 298
9
installarlo. E’ necessaria una figura indipendente per determinare le specifiche e
raccomandare le soluzioni “.
L’esigenza di una figura aziendale che gestisca lo sviluppo del portafoglio informatico è
sottolineata anche da Tony Murphy nella descrizione dei compiti dell’ “ Office of
Architecture and Standards Role”. Questo ufficio dovrebbe “ assicurare che i principi
dell’azienda in merito all’architettura e alla creazione del valore siano complessivamente
rispettati nel corso dell’attività di valutazione”12. E deve trattarsi di una figura
professionale, che possieda una sufficiente cultura tecnica ed una adeguata
metodologia economica ed organizzativa così da poter svolgere quelle funzioni di
gestione del portafoglio informatico e di interfaccia con i fornitori, funzioni spesso
disattese e non adeguatamente assolte all’interno delle aziende utilizzatrici di prodotti e
servizi informatici.
1.2. Obiettivi del Corso
Nell’ambito di un contesto aziendale estremamente fragile sotto il profilo della
valutazione e gestione del portafoglio informatico, è necessario formare figure
professionali, che possiedano gli strumenti culturali e metodologici per rinforzare le
organizzazioni in un’area, quale quella dell’ICT, senza dubbio strategica per lo sviluppo e
il successo futuro dell’azienda.
L’obiettivo del corso è di fornire un percorso logico e una serie di strumenti che
permettano agli studenti, una volta laureati, di operare nel mondo del lavoro come
interfaccia tra le esigenze di sviluppo dell’organizzazione e le attività svolte dagli
specialisti di ICT, sia essi interni che fornitori esterni.
Si passerà in rassegna la vasta letteratura sull’argomento, così da dare allo studente il
necessario inquadramento teorico, ma soprattutto l’impegno sarà rivolto a trasmettere
12
Tony Murphy “ Achieving business value from technologies “ Gartner 2002 pag. 159-163
10
un metodo, che sia sufficientemente semplice ed operativo da poter essere un
riferimento utile nelle situazioni concrete, che, presumibilmente, i giovani laureati si
troveranno ad affrontare nel mondo del lavoro.
A questo riguardo occorre premettere alcune precisazioni, che permettono anche di
delimitare e caratterizzare l’oggetto del corso:
-
si affrontano i problemi relativi alla realizzazione di un progetto informatico, che
viene avviato in seguito alla decisione di effettuare un investimento in ICT, al fine di
introdurre una nuova architettura informatica o parti di essa, assumendo quindi
caratteristiche di innovazione rispetto al preesistente assetto aziendale. Non viene
quindi affrontata la gestione quotidiana delle problematiche informatiche, quali la
manutenzione e l’assistenza alla dotazione di hardware, agli applicativi gestionali e
alla rete;
-
si fa riferimento all’implementazione di pacchetti standard di software applicativo,
che evitano le attività di progettazione e programmazione, in quanto lo sviluppo di
soluzioni informatiche “ custom” non costituisce più la situazione più diffusa di
investimento ICT e , qualora se ne si faccia ricorso, viene comunque affrontata
ricorrendo a fornitori esterni;
-
si è orientati, in termini di contenuti e metodi proposti, agli investimenti ICT
effettuati in organizzazioni di piccole e medie dimensioni, che costituiscono il tratto
distintivo della struttura produttiva ed economica del nostro paese.
Il corso fa poi riferimento a discipline tra loro differenti, che , nell’ambito di un corso
semestrale ed orientato a fornire una metodologia di intervento, verranno affrontate
privilegiando specifici contributi piuttosto che una trattazione esauriente ed approfondita
di ciascuna delle materie.
La prima disciplina è costituita dalle tecniche di valutazione degli investimenti, che
devono fare riferimento a quelle tipiche di carattere finanziario, alla loro applicabilità ad
un investimento in sistemi informatici e quindi all’eventuale ricorso ad approcci più
sofisticati, quali l’analisi strategica.
11
La seconda disciplina è costituita dal project management and control ( di seguito PM),
ossia dalle tecniche e dalle modalità finalizzate alla gestione dei progetti. La
strumentazione di PM, pur all’interno di principi generali comuni, si differenzia in
funzione dei diversi ambienti ai quali viene applicata: le costruzioni civili, i grandi
impianti, lo sviluppo di nuovi prodotti, la ricerca e sviluppo e attività di miglioramento
aziendale. Si cercherà quindi di trattare le metodologie più aderenti a progetti ICT di
media dimensione.
La terza disciplina è rappresentata dalla gestione del cambiamento, ossia da tutte quelle
tecniche organizzative e gestionali che sono orientare a favorire l’innovazione dei
comportamenti organizzativi.
La quarta disciplina è rappresentata dalla contrattualistica, ossia dalle problematiche
giuridiche e operative legate alla definizione di contratti aventi per oggetto servizi
informatici.
La necessità di utilizzare in modo congiunto una pluralità di discipline, tra di loro anche
molto diverse sotto il profilo culturale e metodologico, è un ulteriore conferma della
complessità alla quale è chiamato ad operare chi in una piccola e media organizzazione
deve svolgere il ruolo di riferimento delle problematiche informatiche.
1.3. Articolazione del Corso
Il Corso è articolato in quattro parti così da rispondere alle questioni che sono state
poste nel primo capoverso della presente introduzione:
-
La prima parte, Nozione di architettura informatica, illustra il contesto all’interno del
quale occorre inquadrare un progetto di un nuovo sistema informatico e risponde
alla domanda: quali sono i confini dell’oggetto dell’investimento ICT ?
-
la seconda parte, Valutazione dei sistemi informatici, illustra le diverse metodologie
di analisi degli investimenti in ICT e risponde alla domanda: quale architettura
informatica ?
12
-
la terza parte, Selezione del software e dei fornitori, illustra le metodologie per
scegliere la soluzione informatica più adeguata sotto il profilo tecnico e gestionale e
risponde alla domanda: che cosa ci si aspetta dal nuovo software ?
-
la quarta parte, Gestione dei progetti informatici, illustra le tecniche di PM più
efficaci per governare un investimento ICT e risponde alla domanda: in che modo
assicurare il rispetto dei costi e dei tempi e ridurre i rischi di non pervenire alla
soluzione attesa ?
Ciascuna delle parti che compongono la dispensa è, a sua volta, articolata in due parti.
La prima parte illustra un metodo da utilizzare per valutare e gestire i progetti
informatici, sempre nell’ipotesi di rivolgersi a piccole e medie imprese, che possiedono,
generalmente, limitate risorse e competenze da impegnare nella fase di analisi degli
investimenti e nel loro monitoraggio e governo.
La seconda parte riporta una sintesi dei principali contributi teorici senza la presunzione
di offrire un quadro esaustivo di una letteratura vasta ed articolata. L’obiettivo è di
fornire agli studenti alcuni riferimenti e suggestioni che permettano di stimolare la
riflessione e la curiosità anche in una fase successiva a quella universitaria, una volta
entrati nel mondo del lavoro.
Non sempre la rassegna della dottrina prevalente può avere lo stesso spessore e la
stessa ampiezza. Mentre esistono numerosi libri ed articoli in merito alla valutazione
complessiva delle scelte informatiche e al tema della gestione del cambiamento, per
quanto riguarda la selezione del software e dei fornitori occorre fare riferimento alle
prassi aziendali e alle attività dei consulenti, di solito parchi di indicazioni precise in
merito alle metodologie utilizzate.
Infine, non esistono contributi specifici in merito all’utilizzo delle tecniche di PM ai
progetti informatici ed occorre quindi fare riferimento alle metodologie più generali
relative alla pianificazione e controllo dei progetti. In particolare non viene affrontato
nella dispensa il tema delle modalità di valutazione e di mitigazione del rischio, che
costituisce la “ nuova frontiera “ del PM.
13
2. NOZIONE DI ARCHITETTURA
INFORMATICA
2.1. Definizione assunta come riferimento
2.1.1.
Premessa
Il termine architettura informatica
non presenta definizioni univoche, assumendo
significati e contenuti differenti in relazione ai diversi punti di vista rispetto ai quali si
affronta il problema dei sistemi informativi.
Con il termine “ Sistemi Informativi Aziendali” (in sigla SIA) si intende generalmente
l’insieme delle informazioni aziendali, siano esse esplicite o implicite, in formato
elettronico o cartaceo. Si pone quindi l’enfasi sulla complessa relazione tra
organizzazione, competenze e capacità delle risorse umane da un lato e infrastrutture
informatiche dall’altro; si parla quindi di:
•
“architettura dei processi aziendali per promuovere l’integrazione e la rapidità di
risposta;
•
architettura delle risorse umane per promuovere lo sviluppo di professionalità
idonee ai nuovi modi di operare;
•
architettura dei sistemi informativi per promuovere e supportare la flessibilità, la
connettività e l’integrazione”.13
Questo approccio così esteso, che intreccia numerose dimensioni (tecnologiche,
organizzative, informative in senso lato), rende di fatto difficile, se non impossibile,
isolare e valutare i costi e i benefici di un SIA14.
13
Giampio Bracchi, Gianmario Motta “ Progetto di Sistemi Informativi “ ed. Etaslibri 2000 pag.6-10
14
Renata Paola Dameri: “ La valutazione dell’information technology in azienda “ Isedi 2005 pag. 28-31
14
Un’altra definizione di architettura informatica è invece di forte connotato tecnologico e
si identifica con la nozione di infrastruttura di base, composta dall’hardware (computer,
accessori dei computer, come stampanti, scanner e così via, e linee di comunicazione) e
dai software che permettono il funzionamento dell’hardware: sistemi operativi, software
infrastrutturale, applicazioni di office.15 Questo approccio appare troppo riduttivo in
quanto trascura le applicazioni aziendali, ossia quei software gestionali che
contribuiscono al funzionamento aziendale, differenziando un’organizzazione rispetto ad
un’altra. Come è stato giustamente osservato, l’infrastruttura è costituita da prodotti ,
mentre le applicazioni aziendali “ sono legate al contesto, ai processi aziendali e
concorrono allo svolgimento delle attività poste in essere dai processi produttivi e dalla
formula imprenditoriale specifica di ciascuna impresa”16.
Le relazioni tra sistemi informatici ed organizzazione vanno inquadrate all’interno dei
vincoli stringenti imposti dall’evoluzione tecnologica, che si presenta difficilmente
governabile da parte di ciascuna azienda. Dall’inizio degli anni ‘80 le tecnologie legate
all’informazione e alla comunicazione sono state caratterizzate da un elevato tasso di
innovazione, che ha contribuito a diffonderle e a trasformarle da strumenti orientati a
ridurre i costi ( automatizzando delle attività prima svolte dall’uomo) a componente di
integrazione dell’organizzazione e dei rapporti tra questa e il mondo esterno. Le
caratteristiche assunte dall’ICT costituiscono il risultato composto di numerose
discontinuità tecnologiche, alcune in qualche modo governate da alcuni leader di
mercato ( si pensi al mondo Microsoft), altre come effetto dell’azione di numerosi
protagonisti anche esterni al mondo tradizionale dell’informatica ( si pensi solo al ruolo
dei grandi gruppi della telefonia e domani alla funzione competitiva che potrebbero
svolgere le imprese di prodotti mediatici), altre infine casuali e difficilmente prevedibili (
si pensi al primo sviluppo di internet).
15
Questo approccio è anche quello della Gartner con la nozione di “ Technical Architecture Framework “, malgrado i
tentativi dell’autore di darne un connotato più ampio rispetto a quello strettamente tecnologico Tony Murphy “
Achieving Business Value From Technology “ ed. John Willey e Sons Inc 2002 pag. .54
16
Renata Paola Dameri: “ La valutazione dell’information technology in azienda “ Isedi 2005 pag. 21
15
Le tecnologie informatiche sono quindi un “ dato esterno “ all’azienda, un vincolo o
un’opportunità, che ridisegna il modello organizzativo, con un impatto altamente
pervasivo non solo sull’organizzazione del lavoro (modalità di lavoro, professionalità
richieste, qualifiche professionali e così via), ma anche sulle relazioni tra le diverse unità
organizzative dell’azienda, aprendo una potenziale contraddizione tra gli investimenti in
ICT ( generalmente tendenti verso l’integrazione) e le caratteristiche organizzative
prevalenti ( basate sulla specializzazione professionale, sulla dimensione verticale e sulla
chiusura del sistema azienda verso l’esterno). Questa contraddizione genera due effetti,
che hanno comunque un costo elevato per l’azienda ( in termini di investimenti e di
tempi)17:
-
elevata personalizzazione degli applicativi gestionali per renderli più vicini al
tradizionale modo di operare dell’organizzazione;
-
elevate resistenze all’introduzione dei sistemi informatici, che si riflettono in
comportamenti non coerenti con quanto richiesto, nell’esaltazione dei difetti, e più in
generale nella tendenza a ritornare sulle tradizionali modalità di lavoro, riducendo di
conseguenza i benefici dell’investimento stesso.
D’altra parte, gli investimenti in ICT rappresentano anche un’elevata spesa per
l’azienda, riconducibile non solo ai costi di acquisizione dell’ hardware e del software,
ma anche a costi indotti e nascosti, che trovano origine nella gestione nel tempo del
sistema informatico e nelle energie che occorre impegnare per l’ implementazione e
manutenzione di nuovi software. Secondo diverse indagini, un impresa media
statunitense spenderebbe in ICT più del 4,2 % del giro di affari e le spese in sistemi
informatici costituirebbero ben oltre il 50% del budget di investimenti.18
La nozione di SIA rischia di non cogliere appieno la funzione autonoma di innovazione
svolta dalle tecnologie ICT, in quanto colloca il tema della valutazione e della gestione
dell’informatica in una dimensione troppo ampia, costituita dalla generazione e
17
L’impatto sulla produttività del mancato adeguamento dell’organizzazione alle caratteristiche degli investimenti in
ICT è stato bene qualificato da Nicola Acocella e Riccardo Leoni in “ La tecnologia da sola non basta” 25 novembre
2008 in www.sbilanciamoci.info
18
F.C. “ Ted “ Weston, Jr. “ Erp II: the extended enterprise system “ in Business Horizons, Novembre-Dicembre 2003
16
circolazione delle informazioni in azienda, che riconduce necessariamente alla cultura, ai
codici di comunicazione prevalenti e al mondo delle informazioni informali. Al contrario
la nozione di infrastruttura di base, con la quale spesso si identifica il termine “
architettura”, è troppo limitativa in quanto non pone enfasi agli applicativi gestionali e al
delicato ruolo di interconnessione tra organizzazione e tecnologia.
Pertanto, è opportuno assumere una nozione intermedia di architettura informatica,
che sia sufficientemente ampia da includere tutte le componenti di un sistema
informatico, e soprattutto quelle che maggiormente interagiscono con l’organizzazione e
con le persone, ma non così omnicomprensiva da divenire generica e di difficile utilizzo
pratico. Solo in tal modo è possibile determinare, con una relativa semplicità e
agevolezza, i seguenti aspetti di un investimento in ICT:
-
il costo totale di possesso di un sistema informatico (in sigla, TCO total cost of
ownership), che include “il costo iniziale di acquisizione e installazione dei computer
e del software, i costi di amministrazione per gli aggiornamenti dell’hardware e del
software, i costi di manutenzione, i costi di supporto tecnico e l’addestramento
sull’hardware e sul software senza dimenticare quelli di servizio e quelli immobiliari
necessari per utilizzare ed ospitare queste componenti tecnologiche “19;
-
la complessità delle relazioni con l’organizzazione, la cultura e le competenze delle
persone, evitando i principali rischi connessi al cambiamento innescato dalla
tecnologia: “ gli utenti non usano (dipendenti, clienti, fornitori ecc.) la tecnologia, la
sotto utilizzano, o la usano senza catturarne i benefici con il risultato di pervenire ad
una cattiva soluzione, ossia a soluzioni incomplete e non allineate con
l’organizzazione”
19
20
.
Kenneth e Jane Laudon “ Management dei sistemi informativi “ ed. Pearson Prentice Hall 2003 pag. 25
20
M. Lynne Markus “ Technochange management:using IT to drive organizational change“ Journal of Information
Technology n.19 2004 pag. 7
17
2.1.2.
Componenti dell’architettura informatica
Al fine di fornire una metodologia sufficientemente agevole per affrontare i problemi
sopra evidenziati (determinazione del costo totale di possesso, avvio di un effettivo
processo di cambiamento) si è ritenuto opportuno definire l’architettura informatica
come un sistema bilanciato di soluzioni hardware e software, composto da tre
connotati fondamentali:
I.
Le componenti dell’architettura informatica, costituite da infrastrutture
di computer, infrastrutture di rete, office automation e applicativi
gestionali, così come sintetizzata nella tabella successiva.
Componenti
dell’architettura
Infrastrutture di computer
Contenuti
Esemplificazioni
Computer
Mainframe,
workstation,
computer
personale
Sistemi operativi
Windows, Unix, Linus,
OS/2, Mac OS, Dos
Altri
dispositivi
computer
del Tecnologie
di
memorizzazione
(es.cd
rom), programmi di utilità,
programmi
di
interfacciamento
(
middleware)
Accessori del computer
Infrastrutture di rete
Reti comunicazione
Reti di computer
server,
personal
ad
uso
Stampanti, scanner, fax,
fotocopiatrici
Cavo
telefonico,
cavo
coassiale, cavo a fibre
ottiche,
trasmissioni
wireless con ponti radio,
trasmissioni wireless con
satellite
Elaborazione centralizzata,
architetture client-server,
architetture peer to peer,
18
modelli di rete (a stella, a
bus, ad anello)
Office automation
Approcci di reti
Reti locali (LAN), intranet,
intranet/extranet, internet
Accesso a web
Browser,
provider,
wireless web, protocolli e
tecnologie di sicurezza
Elaborazione
testi
Elaborazione immagini e
web, gestori di flussi di
lavoro ecc. es. Excel,
Word
Gestione dei documenti
Gestione
Comunicazione
della Posta elettronica, casella
vocale,
segreterie
telefoniche digitali, video
conferenze ecc.
Gestione dei dati
Elaborazione
dati
,database
desktop,
interfacce amichevoli per
accesso ai database del
server,
Gestione
conoscenza
e
collaborazione
Applicativi gestionali
della Portali di informazione,
della strumenti di groupware e
di collaborazione via web
programmi di e-learning,
programmi di knowledge
Tecnologie di database
Database proprietari, IBM
DB2, Oracle, Microsoft
SQL Server
Sistemi di elaborazione
delle transazioni ( in sigla
TPS
Transaction
Processing Systems)
Software per la gestione
delle transazioni di routine
necessarie uotidianamente
per condurre le attività
aziendali (es. Erp)
Sistemi di gestione delle
informazioni ( in sigla
MIS
:
Management
Information Systems)
Software per l’estrazione e
gestione dei dati dai
sistemi TPS mediante la
produzione
di
report
periodici standard;
Sistemi di supporto delle Software per la gestione
decisioni ( in sigla DSS : di ambienti di calcolo e di
19
Decision
Support
Systems, in sigla ESS :
Executive
Support
Systems)
II.
comunicazione
incorporando dati legati ai
sistemi
informativi
aziendali ma anche da
eventi esterni;
Un approccio sistemico all’architettura informatica, che la concepisca
come un insieme di parti tra loro profondamente interrelate. Al fine di
chiarire questo concetto è sufficiente un esempio banale: se acquisto un nuovo
software per il controllo di gestione devo analizzare con attenzione se i requisiti
tecnici non siano tali (in termini di memoria necessaria per esempio) da
richiedere un potenziamento del server o dei computer che dovranno utilizzare il
nuovo applicativo, con la conseguenza di ulteriori investimenti in altre parti
dell’architettura informatica.
Solo con un approccio sistemico, è possibile progettare “ una architettura per la
migrazione” che rifletta le caratteristiche dell’organizzazione, dei processi e delle
funzionalità che si attueranno gradualmente nel futuro ma che nel contempo si
sovrappone ai sistemi informatici già esistenti, che devono poter continuare ad
operare e il cui rifacimento richiede uno sforzo di molti anni solari “21. In tal modo
è possibile adottare un approccio per prototipi, definito come “ tentare qualche
cosa e usare i risultati come base per decidere che cosa fare nella fase
successiva”22, che rappresenta l’unico accorgimento per permettere di:
- graduare nel tempo il costo dell’investimento che spesso può essere di rilievo
significativo;
- salvaguardare il patrimonio informatico esistente, evitando di distruggere il
valore di soluzioni hardware e software, che ancora possono operare con
efficacia. Come viene giustamente sottolineato da Tony Murphy , la capacità
delle nuove applicazioni di integrarsi con i sistemi esistenti, che non vengono
dismessi, rappresenta una considerazione di vitale importanza da tener
presente nella decisione di investimento. “ Non dovrebbe essere sottostimata
21
Giampio Bracchi, Gianmario Motta Progetto di Sistemi Informativi ed. Etaslibri 2000 pag.6-10
22
M. Lynne Markus “ Technochange management:using IT to drive organizational change“ Journal of Information
Technology n.19 2004 pag. 15
20
la sfida di integrazione tra vecchie e nuove tecnologie”…. anche perché le
applicazioni ereditate “ spesso hanno costruito
funzionalità specifiche
dell’azienda non facilmente rimpiazzabili dai nuovi prodotti pre-confezionati “23;
- trovare il più valido compromesso tra le funzionalità standard del nuovo
sistema informatico e le caratteristiche specifiche dei processi dell’azienda.
Molte nuove applicazioni (si pensi agli Erp) sono progettate intorno ai processi,
sulla base degli migliori pratiche aziendali, contribuendo ad apportare anche
un miglioramento nelle modalità di lavoro dell’azienda. Il problema non è solo
la distanza tra le “ best practices” imposte dal nuovo sistema informatico e
l’approccio tradizionale al lavoro dell’azienda. Un’altra criticità deriva dal fatto
che spesso i processi aziendali sono serviti da più applicazioni informatiche. Si
pensi,per esempio, al processo commerciale di un’azienda, nella quale il ciclo
attivo (ordine-fattura al cliente e incasso) può essere supportata da
un’applicazione Erp, mentre le relazioni con il cliente sono gestite da un
prodotto CRM, che opera su una diversa piattaforma informatica.
III.
Il bilanciamento tra le diverse parti dell’architettura informatica. Le
ragioni alla base di questa nozione sono bene espresse da Tony Murphy che
sottolinea come “ una delle principali ragioni per le quali le imprese non riescono
a realizzare il valore atteso del business, è che sottostimano la complessità di
gestire i processi aziendali attraverso piattaforme tecnologiche divergenti e che
mancano di un piano complessivo per l’integrazione e il consolidamento. Una
valutazione complessiva dell’impatto sull’architettura è raccomandata come parte
della decisione di investimento”24.
23
Tony Murphy “ Achieving business value from technologies “ Gartner 2002 pag. 59
24
Tony Murphy “ Achieving business value from technologies “ Gartner 2002 pag. 60-61
21
Lo stesso autore illustra i vantaggi di una architettura informatica correttamente
bilanciata, evidenziando come si tratta di ricercare un equilibrio difficile tra fattori
tra loro non sempre immediatamente compatibili:
- massimizzare
la portabilità e l’interrelazione operativa tra le diverse
applicazioni mediante la ricerca della massima coerenza nell’hardware e nel
software. Con il termine portabilità si intende la capacità dell’architettura
informatica
di
sostenere
ulteriori
sviluppi
del
patrimonio
informatico
dell’azienda, che possono riguardare l’acquisizione e l’installazione di applicativi
gestionali e di prodotti di office più evoluti, nonché la crescita delle relazioni
all’interno dell’organizzazione e con il contesto esterno;
- ridurre il numero dei prodotti e delle tecnologie in uso così che gli staff tecnici
non devono mantenere la conoscenza su troppi prodotti e tecnologie,
abbassando di conseguenza il costo di formazione degli addetti e la
consistenza delle stesse funzioni aziendali dedicate ai sistemi informativi;
- risparmiare energie nel processo di acquisto, in quanto, dopo una prima
selezione, gli acquisti successivi non richiederanno di investigare nuovamente
diverse alternative in concorrenza. Verranno infatti utilizzati gli stessi prodotti
che sono stati individuati in fase di valutazione dell’architettura informatica:
per esempio, se si decide di utilizzare un unico data base Oracle per l’intera
architettura
informatica,
diviene
poi
inutile
effettuare
un
ulteriore
investigazione delle tecnologie in uso ogni qualvolta si intende effettuare una
implementazione delle tecnologie di data base;
- massimizzare i benefici economici e l’indipendenza che deriva da utilizzare una
serie di fornitori, individuando il giusto equilibrio tra risparmi nei costi
(comprando grandi quantità da un unico fornitore), e rischi di instabilità che
potrebbero derivare dall’instabilità finanziaria dei fornitori;
- provvedere alla massima protezione possibile degli investimenti esistenti così
da essere in posizione di sfruttare le nuove tecnologie quando esse si rendono
disponibili. Questo concetto è legato a due considerazioni: non distruggere
inutilmente gli investimenti effettuati nel passato, che potrebbero ancora
generare benefici per l’azienda; posporre per quanto possibile le scelte di
investimento così da poterle effettuare in una situazione di minore incertezza
tecnologica.
22
Con particolare riferimento agli Erp, Ted Weston dell’Università del Colorado ha
sviluppato il concetto di “ The Erp II Umbrella “25, ossia di un sistema integrato
d’impresa , frutto della combinazione di aspetti tecnici e di caratteristiche legate alla
specificità dell’attività dell’azienda, che permetta di integrare gli Erp di prima
generazione, che gestiscono le transazioni amministrative, con quelli di seconda
generazione, legati alla gestione delle relazioni con il cliente ( software CRM, customer
relationship management) e con il fornitore ( software SCM, supply chain
management). Un approccio integrato ai sistemi informatici dovrebbe conciliare queste
diverse esigenze:
-
velocità di esecuzione, che consiste nell’abilità di gestire “ in tempo reale “ nuovi
ordini da parte dei clienti e nei confronti dei fornitori, di aggiornare gli inventari e di
introdurre i necessari cambiamenti nei piani di produzione; essa deve anche
permettere di “ innovare i processi di business che attraversano le diverse funzioni
aziendali con un minimo di intervento dell’uomo”;
-
adattabilità, che si riferisce all’abilità di cambiare i processi aziendali “ in corsa” e che
richiede di porre l’accento sugli utenti dei sistemi informatici piuttosto che sul
personale ICT dell’azienda al fine di rimodellare i processi aziendali via via che
emergono le esigenze;
-
flessibilità, che consiste nell’abilità di integrare nuove acquisizioni di aziende, con i
loro sistemi contabili e processi aziendali, nuovi impianti e sistemi distributivi,
virtualmente nel momento stesso in cui queste nuove entità vengono acquisite;
-
capacità di risposta, che si riferisce all’abilità di intervenire ogni qualvolta emergono
problemi e criticità nella gestione aziendale.
25
F.C. “ Ted “ Weston, Jr. “ Erp II: the extended enterprise system “ in Business Horizons, Novembre-Dicembre 2003
23
2.2. Le Definizioni di architettura informatica
2.2.1.
L’Approccio Tecnologico
Una prima definizione di ICT è quella assunta dagli operatori del settore e considerata
dalla European Information Technology Observatory ( in sigla EITO), che fa riferimento
ai contenuti merceologici e parla, di conseguenza, di “ Information and Comunication
Technology”, che comprende:
-
l’hardware del computer, ossia l’insieme di apparecchiature, dispositivi fisici, circuiti
elettronici e microprocessori che permettono il funzionamento di un computer: in
termini di prodotti comprende i server, i personal computer, le stazioni di lavoro e le
stampanti;
-
le apparecchiature di ufficio, oggi fondamentalmente costituite da fotocopiatrici;
-
i software , ossia quell’insieme di programmi che assicurano il funzionamento del
computer, le sue funzionalità ed applicazioni: essi si distinguono a loro volta in
software di base ( o sistemi operativi), in software di utilità e in software applicativi;
-
i servizi informatici , ossia le attività di consulenza, personalizzazione, assistenza e
manutenzione relative alla realizzazione e gestione di sistemi informativi;
-
le apparecchiature di comunicazione per l’utente finale ( end user comunications
equipment “) che comprendono i sistemi telefonici fissi e mobili;
-
le apparecchiature di rete ,locali che di infrastruttura;
-
i servizi di trasporto ( “ carrier services”): servizi di telefonia fissa e mobile, internet
services.
24
Nella Tabella successiva vengono riportati i valori in miliardi di euro relativi ai paesi dell’ Unione
Europea, escluso Cipro e Malta, relativi al 2007: fonte European Information Technology
Observatory.
Segmenti di ICT
Hardware del Computer
Apparecchiature di Ufficio
Software
Servizi Informatici
Totale Sistemi Informativi
Apparecchiature per l’utente finale
Apparecchiature di rete
Servizi di Telefonia
Totale Telecomunicazioni
TOTALE ICT
Miliardi
%
80
8
76
140
304
12,0%
1,2%
11,4%
21,0%
45,5%
28
4,2%
43
293
364
668
6,4%
43,9%
54,5%
100,0%
E’ interessante osservare come l’hardware del computer costituisca una quota
relativamente modesta degli investimenti in ICT ( pesando non più del 12% del totale).
Inoltre i servizi informatici, ossia la consulenza ed assistenza legata all’implementazione
e gestione dei sistemi informativi, rappresentano quasi la metà degli investimenti in
informatica ad indicare anche in termini monetari l’importanza assunta dalle attività di
supporto al software.
Se si analizza la struttura del settore del software e di quello dei servizi informatici ( che
valgono complessivamente 220 miliardi di euro nell’Unione Europa), emerge la
significativa debolezza del cliente finale rispetto al mondo dei fornitori.
All’inizio della filiera si collocano i fornitori di tecnologie di base (quali la DBMS) e di
piattaforme applicative. Essi sono caratterizzati da una struttura competitiva di carattere
oligopolistico e interessati negli ultimi anni da intensi processi di concentrazione.
I
principali protagonisti sono fondamentalmente tre: Oracle, che ha una posizione di
sostanziale predominio nel comparto dei DBMS e mediante una serie di acquisizioni è in
forte crescita in quello delle piattaforme applicative ( negli Erp è oggi presente con una
sua soluzione, con le soluzioni J.D.Edwards e PeopleSoft); Sap, leader incontrastato
25
nelle soluzioni Erp, e, ovviamente, Microsoft, che con la soluzione Vision è presente
pure nel settore degli Erp.
I fornitori di base non si fanno carico direttamente della vendita e dell’implementazione
delle loro tecnologie e piattaforme applicative, ma si affidano ad una rete di “ partner”,
che possono essere meri rivenditori, sviluppatori di software specialisti e settoriali
utilizzando le tecnologie e le piattaforme applicative messe a disposizione dai fornitori di
base, ed infine fornitori di consulenza informatica e di assistenza nella fase di
personalizzazione, introduzione e gestione delle soluzioni vendute al cliente finale. Nella
maggior parte dei casi i fornitori di servizi svolgono contemporaneamente nella filiera le
tre funzioni sopra indicate (rivenditori di hardware, sviluppatori di software ed attività di
consulenza informatica). Il ruolo di partner non è sempre di carattere esclusivo e quindi
il fornitore di servizi può utilizzare contemporaneamente differenti tecnologie e
piattaforme applicative, con riflessi negativi sul grado di conoscenza delle stesse. Il
cliente finale si interfaccia con soggetti, i fornitori di servizi, spesso particolarmente
deboli sotto il profilo tecnologico ed interessati in misura particolare a vendere giornate
di consulenza e hardware aggiuntivi rispetto al prodotto di base. Solo in Italia si
possono censire, in difetto, 20.000 fornitori di servizi informatici, da alcuni di grandi
dimensioni (spesso diverse volte il loro cliente finale), quali Accenture, Engineering,
IBM, sino a piccole società locali o specialisti in alcuni settori di nicchia.
L’ultimo punto della filiera è costituito dal cliente finale, che riflette la struttura del
panorama economico ed industriale del nostro paese: un numero estremamente ridotto
di soggetti di grandissime dimensioni ( le grandi banche, Telecom, Enel, Eni, Fiat,
Finmeccanica, Poste, Sogei del Ministero delle Finanze e pochi altri), numerosi soggetti
di medie-grandi dimensione (tutte le medie imprese, le Regioni, i Comuni sopra 150.000
abitanti, le Aziende Sanitarie) e poi la miriade delle piccole e medie aziende, che
caratterizzano il tessuto produttivo del nostro paese.
26
Nel grafico successivo viene riportata la struttura del settore del software e dei servizi
informatici
Fornitori di
base
Pochi e
molto
concentrati
Esempi :
• Oracle, leader
nei DBMS
• Sap, Oracle,
Baan negli Erp
• Microsoft e Apple
nei sistemi
operativi Pc
Fornitori di
servizi
Numerosi,
solo 20.000
aziende in
Italia
Esempi :
• Accenture,
Engineering,
leader
• Specialisti per
settore
• Specialisti per
territorio
Clienti finali
Poche
grandi
imprese e
centinaia di
migliaia di
aziende
Individuare l’ICT in termini merceologici ha il pregio di porre l’enfasi sulla complessa
interrelazione tra il mondo dell’informatica e quello delle telecomunicazioni e sulla
sinergia tra microelettronica, applicazioni e settori di riferimento che rende
imprevedibile le caratteristiche e la direzione dell’innovazione tecnologica.
Come è sintetizzato in un recente studio della Gartner Inc., l’evoluzione tecnologica “,
supportata da una diminuzione di costi nelle tecnologie di base ( microprocessori,
memorie, banda larga) hanno trasformato l’ ICT. Si è rapidamente ampliata da una
risorsa di supporto, che fornisce vantaggi competitivi ( per esempio, costi, tempo,
qualità) ad una risorsa di front-office ( marketing, vendite, ricerche sul contesto
esterno) divenendo una necessità competitiva. Le nuove tecnologie hanno contribuito a
supportare questi sviluppi. Ma le nuove tecnologie hanno esse stesse agito come
catalizzatori per nuove iniziative competitive che a loro volta generano nuovi fattori
critici di successo per gli investimenti in ICT. Ed è da questi fattori che occorre ricavare
l’incremento di valore dall’ICT”26.
26
Tony Murphy Achieving Business Value from Technology ed. John Wiley e Sons Inc. 2002 pag.XIII-XV
27
La definizione di ICT sotto il profilo merceologico evidenzia la complessità e la
dimensione del settore dell’informatica e delle comunicazioni, che è sottoposto a forti
spinte provenienti dall’innovazione tecnologica (soprattutto nell’area dei micro
processori e delle infrastrutture di telecomunicazione), ed è caratterizzato da gruppi
industriali (con dimensioni tra le maggiori nello scenario industriale mondiale), a loro
volta interessati da intensi processi di concentrazione. Si è , quindi, in presenza di un
forte divario dimensionale a favore dei fornitori e a svantaggio del cliente.
2.2.2.
L’ Informatica Gestionale
Un altro modo per individuare i contenuti dell’ICT è di fare riferimento alle funzioni che
essa ricopre in azienda. Strassman definisce il Management Information Systems come
l’insieme di tecnologie di informazione che sono a supporto del management27. Più
precisamente Charles Wiseman parla di Strategic Information Systems, “ nel quale le
funzioni del sistema sono sia di processare transazioni routinarie (esempio, registrazioni
di fatture) e di produrre predefiniti report che di effettuare interrogazioni ed analisi.
L’uso primario è di supportare o formare la strategia competitiva dell’impresa, i suoi
piani per acquisire e mantenere un vantaggio competitivo o ridurre i vantaggi dei suoi
rivali”28. A questa definizione fa riferimento il termine italiano di informatica gestionale
comunemente usato.
Questa definizione riconduce ancora l’informatica ad una funzione di supporto dei
processi aziendali, concependola come un costo indiretto e non come parte integrante
del core business. In realtà questa definizione appare sempre più limitativa, non solo
perché risulta incompleta rispetto alla diffusione dell’ICT anche nelle aree strettamente
tecniche ed operative dell’impresa, ma soprattutto in quanto sottovaluta la capacità
dell’informatica di determinare profondamente il modo di essere dell’organizzazione, ciò
che è stato definito con un termine molto efficace “ la postura” dell’azienda.29
27
Paul A. Strassmann The Politics of Information Management, ed. The Information Economics Press, 1995
28
Charles Wiseman, Strategic Information Systems, ed. Irwin 1988 pag.98
29
Carroll W. Frenzel “ Management of Information Technology” ed. Boyd e Fraser 1996 pag. 40
28
Kenneth e Jane Laudon parlano opportunamente di “ catena del valore delle
informazioni “ , intesa come “ un insieme di attività a valore aggiunto per l’acquisizione,
la trasformazione e la distribuzione delle informazioni che i manager possono utilizzare
per migliorare le attività decisionali, incrementare le prestazioni aziendali e infine
migliorare i profitti aziendali “30.
Come è noto, Michael Porter ha sviluppato sin dal 1985 la visione dell’impresa come un
insieme di attività che vengono svolte per progettare, produrre, vendere e supportare i
prodotti. Questo concetto è stato rappresentato con la catena del valore31, distinguendo
tra attività primarie, che riguardano i processi di trasformazione e l’interfaccia con il
cliente, e attività di supporto che sono di ausilio alle attività primarie. Applicando la
definizione di catena del valore alle problematiche informative di un’azienda, si possono
distinguere tre fondamentali classi di processi32 e quindi di tipologia di eventi33:
Eventi operativi
Gli eventi operativi riguardano attività fisiche associate con i processi di business, ossia
con la produzione di beni e di servizi. Per esempio, sono eventi operativi l’acquisizione
di un ordine dal cliente, la consegna del prodotto al cliente, il ricevimento delle materie
prime dal fornitore ed il pagamento delle merci ricevute. Gli eventi operativi fanno parte
di un insieme di processi aziendali, che vengono anche denominati con il termine “
conversion cycle” (ciclo di trasformazione), in quanto convertono le materie prime in
prodotti finiti, che vengono consegnati al cliente.
Nell’industria manifatturiera e nelle medie-grandi imprese questi processi sono spesso
oggetto di operazioni formali, ossia sono descritti in procedure e disposizioni scritte, e
quindi
30
facilmente
rintracciabili
sotto
il
profilo
delle
informazioni
trattate.
Al
Kenneth e Jane Laudon “ Management dei Sistemi Informativi “ ed. Pearson Prentice Hall 2003 pag. 13
31
Sulla definizione di catena del valore e sui legami tra le attività, si veda Robert M. Grant “ L’analisi strategica per le
decisioni aziendali “ ed. Il Mulino 1999 pag. 156, 262-263
32
Per processo si intende un insieme di attività tra loro collegate, intenzionalmente destinate a raggiungere un
risultato.
33
I concetti che vengono esposti di seguito fanno riferimento a James H. Hall “ Accounting Information Systems “ ed.
Tomson 2004. L’autore definisce gli eventi come “ i fenomeni che influenzano cambiamenti nelle risorse dell’azienda.
29
contrario,nelle aziende di servizio e in molte piccole imprese si tratta spesso di eventi
informali, ed è quindi più difficile individuare le informazioni che accompagnano le
attività fisiche. Da questo punto di vista è interessante osservare come esista una
stretta interrelazione, non sufficientemente investigata, tra le tecnologie informatiche
applicate ai processi aziendali da un lato, e quelle che interessano direttamente gli
eventi operativi. Quanto più è diffusa l’applicazione dell’informatica agli eventi operativi,
quanto più si riscontra una formalizzazione degli stessi e quindi una più facile
rintracciabilità delle informazioni.
Le tecnologie informatiche applicate agli eventi operativi possono essere sintetizzate
nelle seguenti tipologie34:
-
sistemi per l’ufficio : sono le applicazioni informatiche che gestiscono i dati e i
documenti con la finalità di aumentare la produttività dei lavoratori e di supportare il
coordinamento e le attività di comunicazione di un ufficio: programmi di
elaborazione dei testi e dei dati, desktop publishing e sistema di trattamento
elettronico dei documenti;
-
sistemi informativi per la gestione della conoscenza : sono le applicazioni
informatiche rivolte ad archiviare e gestire il know-how aziendale ( in sigla KWS:
Knowledge Work Systems): la gestione elettronica dei documenti, i sistemi CAD/CAM
sino ai portali informativi;
-
tecnologie informatiche di automazione: sono le applicazioni informatiche rivolte al
processo produttivo, quali robot, macchine a controllo numerico, macchine di calcolo
utilizzate per il controllo di processo, calcolatori impiegati per la diagnostica o per il
controllo di qualità bancomat, registratori di cassa ecc.
-
tecnologie informatiche “ embedded” : sono le applicazioni informatiche incorporate
nei prodotti e nei servizi:strumentazione di bordo di una autovettura, sistemi di
Internet Banking, telefoni cellulari che possono diventare piccoli calcolatori ecc.
34
Per una rassegna delle diverse applicazioni dell’informatica in azienda si può consultare Giampio Bracchi, Chiara
Francalanci, Gianmario Motta “Sistemi Informativi e Aziende in rete”, ed. McGraw-Hill 2001 pag. 9 e Kenneth e Jane
Laudon “ Management dei Sistemi Informativi” ed. Pearson Prentice Hall 2003 pag. 48-56
30
-
tecnologie informatiche infrastrutturali: tecnologie utilizzate per la gestione e
l’esecuzione degli scambi informativi fra organizzazioni diverse: processamento dei
dati, reti geografiche, reti distributive , sistemi di comunicazione via satellite
Eventi informativi
Gli eventi informativi riguardano le attività associate con la registrazione, archiviazione e
distribuzione delle informazioni. Per esempio, sono eventi informativi la preparazione di
una fattura per il cliente, la registrazione delle consegne e delle bolle di entrata della
merce, la predisposizione di mandati di pagamento per i fornitori. Gli eventi informativi
sono molteplici in un’azienda ma sono oggetto del sistema informativo gli eventi che
possono essere “ catturati” dal sistema informativo mediante una evidenza documentale
(una fattura, la registrazione in un data base, una comunicazione): per esempio, un
evento operativo, la vendita, attiva la preparazione, da parte di un impiegato addetto
alla gestione amministrativa delle vendite, di un ordine verso il cliente. Questo ordine è
la formale evidenza che è avvenuta una vendita e copie di questo documento verranno
trasmesse ai diversi uffici aziendali coinvolti, quali la fatturazione, le spedizioni e la
contabilità clienti. La traduzione di un evento operativo in un evento informativo tramite
una evidenza documentale dà origine ad una transazione, ossia ad un “ evento
informativo che influenza o interessa l’organizzazione”35, in quanto fa parte di una
sequenza di eventi informativi, che accompagnano i relativi eventi operativi:per
esempio, emettere un ordine al cliente è alla origine di una serie di attività operative,
quali la messa in produzione di quanto è oggetto dell’ordine, e di flussi informativi agli
uffici aziendali coinvolti; al contrario, inviare e-mail al cliente per fissare un
appuntamento potrebbe non dare luogo a nessuna informazione rilevante per
l’organizzazione e quindi non assumere i connotati di una transazione.
35
La definizione di transazione è quella assunta da James A. Hall in Accounting Information Systems ed. Thomson
2004 pag. 7. L’autore distingue opportunamente tra transazioni finanziarie e transazioni non finanziarie, ossia eventi
operativi che non possono essere misurati in termini monetari.
31
L’azienda è pervasa da un sistema di processi transattivi ( “ transaction processing
system” in sigla TPS), che, in generale, possono essere ricondotti alle seguenti principali
tipologie:
-
ciclo passivo, che comprende: definizione del fabbisogno di acquisto, emissione
dell’ordine di acquisto, ricevimento della merce e controllo con l’ordine, carico a
magazzino della bolla della merce, registrazione della fattura, predisposizione del
mandato di pagamento al fornitore;
-
ciclo del personale, che comprende: anagrafica del personale, rilevazione delle
presenze, valorizzazione monetaria delle presenze sulla base della struttura
contrattuale
delle
retribuzioni,
mandato
di
pagamento
al
dipendente,
determinazione delle ritenute fiscali e dei contributi previdenziali, mandato di
pagamento agli Uffici delle Imposte e agli Enti Previdenziali , determinazione dei
ratei, registrazione in contabilità;
-
ciclo dei cespiti, che comprende: l’acquisizione di un nuovo cespite (definizione
della richiesta di investimento, emissione dell’ordine al fornitore, ricevimento
della fattura e registrazione in contabilità, carico nel libro dei cespiti),
deprezzamento
del
valore
del
cespite
(definizione
delle
aliquote
di
ammortamento, loro inserimento nel libro dei cespiti, registrazione degli
ammortamenti in contabilità con le scritture di assestamento, dismissione del
cespite
(autorizzazione
alla
dismissione,
emissione
dell’eventuale
fattura
all’acquirente, eliminazione dal libro dei cespiti, registrazione in contabilità con la
determinazione della minusvalenza o plusvalenza);
-
ciclo attivo: definizione dei prezzi di vendita, preparazione del preventivo di
offerta o definizione dei listini, emissione dell’ordine di vendita, predisposizione
degli ordini interni di produzione, predisposizione dei documenti di spedizione,
emissione e registrazione delle fatture al cliente, determinazione e gestione dei
crediti, incassi dai clienti.
Le applicazioni informatiche che supportano le transazioni possono essere classificate in
tre fondamentali tipologie:
-
sistemi ereditari ( legacy systems), che utilizzano ancora i mainframes implementati
negli anni ’70 ed ’80, e sono basati su un approccio dipartimentale ( “ flat file
model”). Secondo questo approccio ogni dipartimento aziendale utilizza propri file,
32
che non è possibile interconnettere con quelli utilizzati dagli altri dipartimenti. I limiti
principali di questo approccio sono riconducibili alle difficoltà a realizzare una efficace
integrazione aziendale, a possibili e frequenti disallineamenti tra le diverse basi
informative ed infine alla dipendenza di ciascuna funzione aziendale dalle
informazioni in suo possesso senza poter accedere alle informazioni depositate
presso i file degli altri dipartimenti;
-
sistemi ereditari che si appoggiano su data base segmentati, che utilizzano DBMS
come un vantaggio tecnologico, ma ciascuno dei sistemi aziendali ( gestione dei
clienti piuttosto che la produzione) sono progettati come una soluzione a specifici
problemi operativi piuttosto che come parte di un sistema aziendale complessivo.
Inoltre, poiché gli specifici sistemi informativi sono progettati indipendentemente tra
di loro e in tempi diversi, essi sono spesso costruiti su differenti e incompatibili
piattaforme tecnologiche, richiedendo poi speciali interfaccia per comunicare tra di
loro;
-
sistemi ERP (enterprise resource planning), che sono disegnati sulla base di un
flusso unitario delle informazioni all’interno dell’interno sistema aziendale, creando
un ambiente standardizzato per i processi aziendali e un comune database operativo
che supporti le comunicazioni e crei una comune base informativa. I principali
fornitori di ERP sono Sap, leader di mercato, Oracle, J.D. Edwards e PeopleSoft (oggi
entrambi di proprietà di Oracle) e Baan.
Eventi di carattere decisionale
Gli eventi di carattere decisionale riguardano le attività associate con la
pianificazione, valutazione e controllo delle decisioni. Per esempio, decidere se
acquistare da un fornitore piuttosto che da un altro significa prendere una decisione
sulla base di informazioni che provengono dagli eventi informativi. Gli eventi di
carattere decisionale si esprimono generalmente in report, che possono essere predefiniti o richiesti sulla base delle specifiche esigenze. Il flusso delle informazioni che
dai sistemi transattivi “ sale” verso i report è definito con il termine di “ sistema di
reporting”.
33
I principali sistemi di reporting sono i seguenti:
Aree funzionali
Produzione
Distribuzione
Marketing
Bilancio
Pianificazione e Controllo
Risorse Umane
Finanza
Controllo Strategico
Principali sistemi di reporting
-
Pianificazione della produzione
sistemi di controllo operativo
-
Sistemi di pianificazione delle ore di
lavoro e delle ore macchina
-
Pianificazione e organizzazione del
magazzino
-
Pianificazione
consegne
-
Pianificazione dei trasporti e modelli
di ottimizzazione dei carichi
-
Analisi di mercato
-
Sviluppo di nuovi prodotti
-
Analisi di prodotto
-
Situazioni periodiche e controlli interni
-
Scritture di rettifica ed assestamento
-
Adempimenti
fiscali
e
civili,
impostazione e realizzazione del
Bilancio e Report verso terzi
-
Piani e Budget
-
Contabilità Analitica
-
Report Infrannuali
-
Analisi e gestione delle competenze
-
Politiche retributive
-
Definizione
dei
fabbisogni:
reclutamento, formazione e sviluppo
-
Pianificazione e controllo dei flussi
finanziari
-
Sistemi di valutazione e controllo
degli investimenti
-
Gestione dei rapporti con le istituzioni
finanziari: gestione dei debiti
-
Sistemi di gestione del portafoglio
-
Monitoraggio di indicatori chiave di
performance
e
controllo
e
delle
34
-
Monitoraggio del posizionamento
competitivo e della soddisfazione
della clientela
-
Simulazioni ed analisi what if
Le applicazioni informatiche che supportano i sistemi di reporting alla base degli eventi
informativi possono essere classificate nelle seguenti fondamentali tipologie:
-
sistemi di gestione delle informazioni (in sigla MIS: Management Information
Systems) che servono principalmente
le funzioni di pianificazione, controllo e
supportano le decisioni a livello manageriale, estraendo i dati dai sistemi TPS
mediante la produzione di report periodici standard. Il prodotto tecnologico base di
questi sistemi è il DataWarehouse;
-
sistemi di supporto delle decisioni (in sigla DSS: Decision Support Systems)), che
aiutano i manager a prendere decisioni che sono “ uniche” e in rapido cambiamento
affrontando problemi in cui la procedura per arrivare ad una soluzione può non
essere completamente nota in anticipo;
-
sistemi di supporto direzionale (in ESS: Executive Support Systems), che creano un
ambiente generalizzato di calcolo e di comunicazione incorporando dati legati ai
sistemi informativi aziendali ma anche da eventi esterni.
35
Nel grafico successivo vengono sintetizzate le diverse tipologie di eventi e le applicazioni
informatiche relative
Controllo
strategico
Eventi
decisionali
• Sistemi MIS
Bilancio
(datawarehouse)
• Sistemi di supporto
Pianificazione
e controllo
Risorse
umane
delle decisioni DSS
• Sistemi di supporto
direzionale ESS
Marketing
Finanza
Produzione Produzione
Distribuzione
Eventi
informativi
Eventi
operativi
Ciclo
passivo
Ciclo
personale
Ciclo
cespiti
Sistemi ereditari su
mainframe
• Sistemi su DBMS
segmentati
• Sistemi ERP
•
Ciclo
attivo
Ciclo di trasformazione (attività primarie)
• Sistemi di ufficio
• Sistemi di knowledge
• Tecnologie di
automazione
• Tecnologie embedded
• Tecnologie
infrastrutturali
2.2.3.
Il Portafoglio applicativo
Un’altra definizione di ICT è quella di portafoglio applicativo
36,
sviluppata per analogia
con il concetto finanziario di portafoglio d’investimento. L’analisi di portafoglio dovrebbe
permettere all’azienda di bilanciare gli investimenti in una logica di compatibilità tra
esigenze e risorse.
In questa accezione il portafoglio applicativo di una azienda può essere diviso in tre
principali segmenti:
-
portafoglio direzionale, che comprende le applicazioni informatiche a supporto dei
cicli di pianificazione strategica e di pianificazione e controllo delle risorse aziendali:
apparterrebbero a questo segmento tutti i prodotti di MIS, DSS e ESS;
-
portafoglio istituzionale, che comprende le applicazioni informatiche per i processi di
supporto, quali l’amministrazione, gestione delle risorse umane e contabilità:
36
Giampio Bracchi, Chiara Francalanci, Gianmario Motta Sistemi Informativi e Aziende in rete, ed. McGraw-Hill 2001
pag. 95
36
appartengono a questo segmento i sistemi di elaborazione delle transazioni, quali gli
Erp;
-
portafoglio operativo, che comprende le applicazioni informatiche per i processi
primari dell’azienda, quali i sistemi di ufficio, quelli per la gestione della conoscenza,
nonché le tecnologie incorporate nei prodotti e nei processi primari e le
infrastrutture tecnologiche.
Si tratta di una definizione particolarmente efficace ai nostri fini, in quanto permette di
collocare gli investimenti in ICT su una matrice di portafoglio, rendendo possibile una
scelta che tenga conto delle esigenze complessive dell’azienda in termini informatici.
Essa presenta tuttavia gli stessi difetti delle tradizionali matrici di portafoglio, che
portano a sottovalutare i legami tra i diversi business focalizzando l’attenzione su
possibilità di investimento e disinvestimento che spesso sono irrealizzabili senza
snaturare la missione stessa dell’azienda.
Questi difetti sono esaltati nel caso dell’ICT, in quanto l’informatica è caratterizzata
proprio da una funzione crescente di integrazione tra le differenti attività aziendali,
rispondendo, di fatto, a necessità operative e competitive che impongono determinati
investimenti nell’architettura informatica dell’azienda per una sorta di adeguatezza
rispetto alle condizioni del settore di appartenenza. Gli investimenti in ICT
rappresentano un fattore di base ( in qualche misura “ igienico”) e non appartengono
all’area discrezionale delle scelte aziendali. Come è stato giustamente sottolineato da
Renata Paola Dameri37, l’ICT è uno “ strumento tecnologico che opera sui dati e li
trasforma in informazioni, conoscenze ed applicazioni” diventando in tal modo una
risorsa dell’azienda (e non quindi un costo o un mero fattore produttivo), in quanto
permette di:
-
formalizzare dati ed operazioni, svolgendo quindi un processo di sedimentazione e
strutturazione di conoscenze e competenze che diventano non più un elemento
impalpabile dell’impresa, ma elementi concreti della sua natura organizzativa ed
operativa;
37
Renata Paola Dameri: La Valutazione dell’information technology in azienda, ed. Isedi 2005 pag. 32
37
-
mettere a disposizione e diffondere i contenuti informatici che, precedentemente
formalizzati ed incorporati nei supporti materiali, diventano oggetti fruibili e
condivisibili da una molteplicità di utenti.
Inoltre, una recente ricerca
38
presso 130 grandi imprese USA avrebbe evidenziato come
solo il 17% delle aziende intervistate utilizzerebbe la tecnica del portafoglio per valutare
gli investimenti informatici (in sigla ITPM, IT portfolio management), individuando come
questo approccio sia ancora poco diffuso presso le stesse organizzazioni di grandi
dimensioni.
2.2.4.
L’approccio sistemico
Un’ulteriore approccio al tema dell’ICT trova origine nella crescente preoccupazione di
impostare e realizzare investimenti in informatica, che non irrigidiscano l’impresa e
rendano possibile portare avanti strategie di lungo termine in un ambiente competitivo
e fortemente turbolento. Partendo dai controversi risultati economici e finanziari degli
investimenti in ICT, alcuni studiosi e consulenti hanno sviluppato numerosi studi al fine
di individuare le migliori metodologie per “ creare valore” dall’informatica (si parla in tal
senso di BVIT, business value from information technology).
Si è sviluppato, quindi, nel corso degli anni ’90 un’ampia letteratura che ha condotto a
suggerire un approccio sistemico agli investimenti ICT, così da tener conto di tutti gli
aspetti, da quelli fisici e tecnologici a quelli più propriamente organizzativi e culturali.
La nozione di architettura ICT illustrata nella presente dispensa fa riferimento a questa
scuola di pensiero, che individuerebbe una correlazione tra agilità strategica da un
lato, ossia capacità di rispondere ai cambiamenti del mercato e del modello di business,
ed equilibrato posizionamento su tutte le componenti dell’architettura informatica
dall’altro lato.
38
Mark Jeffery, Ingmar Leliveld “ Best practices in IT portfolio management” MIT Sloan Management Review
Primavera 2004
38
Un interessante evoluzione della nozione di architettura ICT è quella che la concepisce
come un insieme di servizi e quindi una combinazione di capacità tecnologiche e di
competenze manageriali e professionali. La sintesi di una serie di indagini presso un
numero elevato di imprese avrebbe condotto a 10 raggruppamenti di servizi
informatici39, di cui sei connessi agli aspetti “ fisici” e quattro a quelli “ manageriali “
dell’ ICT. Le aree di complementarietà e di sovrapposizione tra i diversi raggruppamenti
di servizi sarebbero i punti più delicati per realizzare un’architettura ICT in equilibrio e
capace di dare all’impresa la necessaria agilità strategica.
I sei “ raggruppamenti” di servizi legati agli aspetti fisici sarebbero i seguenti:
-
servizi per la gestione della rete (“ channel- management services”), che includono
tutta una serie di infrastrutture fisiche ( siti web, e-mail, reti tecnologiche e così via)
e le attività necessarie per la loro manutenzione ed integrazione;
-
servizi per la gestione del rischio e della sicurezza (“ security and risk-management
services”), che includono tutte le infrastrutture e le politiche rivolte a proteggere i
dati e le attività dell’azienda: sistemi anti virus, uso di password, piani di emergenza
e piani contro disastri e attacchi ecc.;
-
servizi per la gestione della comunicazione (“communication services“),che includono
la realizzazione delle tecnologie e dei protocolli di comunicazione all’interno
dell’azienda e tra questa e i suoi clienti e partner: video conferenze, prodotti di
comunità, data base comuni ecc.;
-
servizi per la gestione dei dati ( “data-management services”), che includono tutte le
infrastrutture e le politiche per archiviare e memorizzare le informazioni, dai data
warehouses alle modalità di accesso e di distribuzione sino agli strumenti e alle
procedure per identificare e codificare la conoscenza;
-
servizi di gestione delle applicazioni (“ application-infrastructure services”), che
comprendono tutti i software finalizzati a standardizzare i processi aziendali, come la
contabilità, le risorse umane ecc.;
39
Peter Well, Mani Subramani e Marianne Broadbent “ Building IT infrastructure for strategic agility “ in MIT Sloan
Management Review autunno 2002
39
-
servizi di gestione delle infrastrutture di base ( “IT-facilities-management services”),
necessarie per integrare e supportare le altre infrastrutture: ci si riferisce ai server,
alla rete dei computer ecc.
In aggiunta ai sei raggruppamenti , che costituiscono le capacità fisiche di carattere
infrastrutturale dell’impresa, vanno considerati i quattro raggruppamenti di servizi che
rappresentano le capacità manageriali orientate all’ICT:
-
servizi di coordinamento delle infrastrutture (“IT-management services“),che
includono la pianificazione dei sistemi informativi, la gestione dei progetti informatici,
le attività di valutazione, selezione dei software e dei fornitori;
-
servizi di definizione dell’architettura e degli standard ( “ IT-architecture-andstandards services”), che comprendono le politiche che governano l’uso dell’ICT, le
scelte dell’architettura più opportuna per lo sviluppo dell’azienda e il monitoraggio
costante sull’evoluzione delle tecnologie e degli standard;
-
servizi di formazione in ICT (“ IT-education services”), che includono non solo
l’addestramento del personale ma anche la formazione manageriale su come
investire ed usare ICT per creare valore;
-
servizi di ricerca e sviluppo in ICT (“IT R&D services”), che includono la ricerca per
individuare nuovi modi per usare ICT al fine di creare valore.
L’approccio sistemico ha il pregio fondamentale di analizzare le differenti soluzioni
informatiche in una visione complessiva e coordinata, ossia nell’ ambito di una più
generale strategia di sviluppo dell’architettura ICT dell’azienda. In questo senso
rappresenta un’ottima metodologia di analisi che richiede tuttavia due condizioni di
rilievo:
-
notevoli competenze per comprendere a fondo le problematiche e le tecnologie
coinvolte;
-
capacità manageriali da parte della Direzione Aziendale per apprezzare un approccio
sistemico ed ordinato ai problemi informativi, che comporta, almeno nella
progettazione delle prime alternative di architettura,
un’attenzione in termini di
tempo e di impegno e quindi una elevata consapevolezza del ruolo strategico
dell’ICT.
40
L’approccio sistemico rappresenta l’approccio corretto alla valutazione degli investimenti
nel settore informatico ma deve essere semplificato al fine di un suo utilizzo in aziende
di media e piccola dimensione.
2.3. Le teorie organizzative
In questo paragrafo si intende affrontare il tema delle relazioni tra tecnologie
informatiche ed organizzazione senza pretendere di fornire un quadro esaustivo ma
concentrandosi sugli aspetti che possono avere i riflessi più significativi sul tema della
valutazione e della gestione di sistemi informativi.
La teoria dell’organizzazione ha trattato le tecnologie informatiche secondo diversi punti
di vista e differenti scuole di pensiero.
2.3.1.
La scuola decisionale
La scuola decisionale ha concepito la prospettiva informativa come uno strumento
dell’organizzazione per adeguarsi al contesto specifico nel quale viene ad operare.
Secondo questo filone di pensiero “ maggiore è l’incertezza ambientale, maggiori sono i
requisiti di capacità elaborative di un’organizzazione e, di conseguenza, più intense le
attività di natura informativa “40 . Particolare enfasi viene posta alla possibilità dei vertici
aziendali di interagire direttamente e nel modo più efficiente con il maggior numero
possibile di membri dell’organizzazione, e del management in particolare, migliorando la
comunicazione e la capacità di controllo, nonché contribuendo alla riduzione dei livelli
gerarchici dell’organizzazione.41
In questa ambito le tecnologie informatiche non possiedono una propria evoluzione
autonoma ( che nasce dal progresso delle tecnologie e delle applicazioni di base che la
contraddistinguono ) e il loro campo d’intervento sembrerebbe limitarsi ai sistemi
40
Giampio Bracchi, Chiara Francalanci, Gianmario Motta: Sistemi Informativi e Aziende in rete ed. McGraw-Hill 2001
pag. 13
41
Carroll W. Fenzel “ Management of Information Technology ed. Boyd & Fraser 1996 pag. 13
41
informativi gestionali, trascurando di fatto le tecnologie incorporate nei prodotti e nei
processi aziendali. Il contributo di questa scuola è di sottolineare come a contesti
differenti corrispondano campi diversi di applicazione delle tecnologie informatiche ,non
esistendo di fatto un “ imperativo tecnologico “ verso una determinata evoluzione di
informatizzazione.
Per quanto riguarda il tema della valutazione e gestione dei sistemi informativi, la scuola
decisionale fornisce due indicazioni di rilievo:
-
le scelte relative ai sistemi informativi vanno sempre accompagnate da un’analisi del
contesto interno ed esterno, che ne identifichi il grado di incertezza in relazione alle
principali variabili del settore di riferimento dell’azienda e delle principali
determinanti organizzative che la caratterizzano. L’analisi degli scenari, che
presuppone differenti alternative di riferimento e lo studio del loro livello di
governabilità e prevedibilità, può costituire un efficace ausilio nell’identificazione
della scelta informatica più opportuna;
-
tanto più elevata è l’incertezza quanto più vanno privilegiati percorsi di
informatizzazione per approssimazioni successive e vanno analizzati con attenzione
gli elementi di scalabilità , ossia di capacità di far fronte ad implementazioni
successive, dei pacchetti informatici oggetto di analisi.
2.3.2.
La scuola transazionale
La scuola transazionale pone l’accento sull’impatto delle tecnologie informatiche sul
costo delle transazioni ( ossia degli scambi fisici, documentari e più in generale
informativi), che avvengono all’interno di un’organizzazione e tra questa e i soggetti
esterni ( clienti, fornitori, concorrenti e così via).
Si pensi, per esempio, al volume di transazioni sottostanti al ciclo passivo di un sistema
amministrativo: si tratta di un elevatissimo volume di transazioni che richiederebbero
numerose operazioni manuali (dalla manipolazione ed archiviazione dei documenti
contabili al controllo degli stessi sino alla loro registrazione in contabilità) e quindi un
numero elevato di persone e lunghi tempi per gestire i documenti. L’introduzione di un
prodotto Erp automatizza i processi aziendali, riducendo i costi e i tempi conseguenti
42
con un impatto significativo sul numero di persone impegnate e sui tempi necessari per
svolgere le attività.
La scuola transazionale fornisce una spiegazione esauriente dei riflessi di alcune recenti
evoluzioni dell’ICT ( prodotti CRM, supply chain, internet e così via) sulle relazioni tra
organizzazione e mercato. Si pensi all’elevato costo per contatto cliente che deriva dalla
tradizionale approccio basato sulla rete di vendita (agenti, negozi, relazioni personali
con il cliente): costo contatto che può ridursi in misura significativa con “ una gestione a
distanza “ mediante i moderni strumenti messi a disposizione dall’ICT.
2.3.3.
La scuola dell’azione organizzativa
La scuola dell’azione organizzativa enfatizza la correlazione tra l’introduzione
dell’informatica e i necessari interventi di razionalizzazione dei processi aziendali senza i
quali difficilmente la nuova tecnologia può avere successo : “ le nuove tecnologie sono
eccitanti ed è grande la tentazione di usarle per risolvere i problemi del business.
Tuttavia i reali benefici sono ottenuti non applicandole ai processi esistenti, ma
cambiando i processi sottostanti e possibilmente applicando le nuove tecnologie agli
stessi processi ridisegnati “42.
I sostenitori della riprogettazione dei processi sottolineano opportunamente la
complessità dei problemi di cambiamento introdotti dalle nuove tecnologie informatiche,
ma ribaltano sull’organizzazione un percorso di informatizzazione che è concepito come
imposto dall’evoluzione tecnologica ( ossia dalle politiche delle grandi società di
software) e non funzionale alle effettive esigenze dell’azienda.
Un altro approccio, riconducibile sempre alla scuola dell’azione organizzativa, pone
l’enfasi sulla compatibilità
43
tra le caratteristiche dell’organizzazione e fattori di
cambiamento innescati dall’ICT, in relazione ai seguenti aspetti: la cultura aziendale (e
42
Lynn C. Kubeck: Techniques for Business Process Redesign Ed.Jhon Willey and Sons, inc. 1995 Pag. 11
43
Deborah Bunker, Karl- Heinz Kautz, Anne Luu Thanh Nguyen Role of value compatibility in IT adoption Journal of
Information Technology n.22 2007
43
quindi l’insieme dei valori delle persone che compongono l’organizzazione), la struttura
organizzativa, con le linee gerarchiche di responsabilità, e le pratiche di lavoro.
Si può parlare di “ compatibilità dei valori” quando l’analisi è concentrata sull’impatto
dell’innovazione sul modo di pensare, sulle idee e le credenze delle persone: per
esempio, se l’innovazione in ICT rende possibile lavorare “ da soli” in quanto migliora il
flusso delle comunicazioni scritte, ma il valore dominante nell’organizzazione è
rappresentato dalla comunicazione interpersonale di tipi informale, è evidente che il
nuovo sistema informativo incontrerà profonde resistenze.
Si può parlare di “ compatibilità delle pratiche “ quando ci si riferisce alla coerenza
dell’innovazione con le prevalenti modalità di lavoro delle persone: per esempio, è
possibile analizzare le informazioni su richiesta e mediante analisi what if, ma i manager
sono abituati a leggere le informazioni sulla base di report pre-fissati e rigidi; ed è
quindi probabile che l’innovazione introdotta creerà malumori e diffidenze, sulle quali
sarà necessario lavorare.
Più complessa e più difficile da individuare è la “ compatibilità delle strutture
organizzative” , ossia dalla coerenza dell’innovazione con la definizione dei ruoli e delle
responsabilità, con la struttura gerarchica e più in generale con l’equilibrio del potere:
per esempio, l’innovazione permette al vertice aziendale di avere informazioni di
dettaglio, anche sulla singola transazione effettuata, ma ciò significa impattare
pesantemente sul potere e l’autonomia della linea organizzativa ed in particolare dei
capi intermedi.
Le indicazioni della scuola dell’azione organizzativa hanno un impatto significativo sul
tema della valutazione e della gestione di un investimento nei sistemi informativi:
-
non è possibile limitarsi a determinare il costo dell’ hardware e del software,
comprensivo della relativa consulenza, per valutare correttamente l’investimento nel
settore informativo. Occorre tenere conto dei “ costi organizzativi occulti “ , che
derivano dall’impegno e dai tempi dell’organizzazione ad adeguarsi alla nuova
tecnologia che viene introdotta;
44
-
la gestione di un progetto informatico deve coinvolgere pesantemente il mondo degli
utenti con modalità che non possono limitarsi ad un pur approfondita analisi delle
caratteristiche dei processi organizzativi. I temi relativi alla gestione del
cambiamento entrano quindi di prepotenza e determinano spesso i tempi e i risultati
di un progetto di informatizzazione.
2.3.4.
La scuola della prospettiva strategica
La scuola della prospettiva strategica concepisce le tecnologie informatiche come una
componente essenziale della strategia. L’informatica dovrà assumere connotati differenti
in funzione delle due tipologie di strategia identificate da Michael Porter ( leadership di
costo e differenziazione). I Sistemi Erp e di supply chain contribuiscono senza dubbio
alla ricerca di una maggiore efficienza, mentre, per esempio, i prodotti CRM fanno parte
di politiche rivolte al miglioramento del servizio e quindi ad azioni di fidelizzazione e
differenziazione.
Si possono distinguere due fondamentali modalità di interazione tra ICT e strategia:
-
la prima modalità è di supporto ad una strategia, che è stata elaborata a
prescindere dalle potenzialità e dai limiti dei sistemi informativi, nonché degli
investimenti necessari per modificarli. Il ruolo dell’ICT è di identificare e
rispondere ad una serie di richieste, anche se “ ci può essere un ampio campo di
variazione nell’abilità degli uffici preposti ai sistemi informativi di riconoscere le
implicazioni di una strategia, di identificarne le esigenze in termini di fabbisogni
informativi e darne una risposta”44;
-
la seconda modalità è di contributo alla strategia, identificando le opportunità che
i sistemi informativi possono fornire alla ricerca di opportunità di business e al
rafforzamento dei vantaggi competitivi. Ciò richiede una comprensione, anche da
parte del vertice aziendale, delle principali determinanti della tecnologia
informatica e una stretta e dinamica interazione tra persone preposte ai sistemi
informativi e direzione aziendale.
44
Frederick M. Thorne Exploiting the strategic value of information in John S. Chandler e H. Peter Holzer
Management Information Systems ed. Basil Blackwell 1988 pag. 9-10
45
Questa corrente di pensiero ha il pregio di riconoscere come l’informatica costituisca
ormai un’arma competitiva e quindi non possa essere valutata solo nell’ottica di risparmi
di costo ma debba essere inquadrata in un più generale riallineamento strategico
dell’azienda.45
Concepire le scelte informatiche in una prospettiva strategica comporta di superare le
tradizionali tecniche finanziarie ( concentrate fondamentalmente sulla loro applicazione
ad una previsione di risparmi di costo) e di identificare il contributo dell’investimento al
raggiungimento di obiettivi strategici. Diviene più difficile dare una valutazione
finanziaria, in quanto è necessario stimare l’impatto della nuova tecnologia informatica
sullo sviluppo del business ( valutato in termini di incremento del fatturato, delle quote
di mercato e così via). Per quanto riguarda la gestione dei sistemi informativi, accettare
sino in fondo le indicazioni della scuola della prospettiva strategica significa concepire le
competenze e le capacità in sistemi informativi come componente del “ core business” e
quindi non soggette a processi di esternalizzazione.
45
Richard L. Draft Organizzazione Aziendale Ed. Apogeo 2001 pag. 248-259
46
3. VALUTAZIONE DEI SISTEMI INFORMATICI
3.1. Evoluzione dell’ICT e suo impatto sui sistemi di
valutazione
Le relazioni tra evoluzione dell’ICT e i sistemi di valutazione sono stati illustrati in modo
esauriente da Tony Murphy nel capoverso “ Some Historical Perspective “ di uno suo
libro46, già citato più volte in questa dispensa. L’autore suddivide la storia dell’ICT in
quattro ere alle quali corrispondono differenti approcci al problema della valutazione dei
sistemi informatici.
Il grafico successivo riporta sinteticamente le quattro “ ere” nelle quali si può articolare la storia
dell’ICT
Era IV Integrazione Esterna
Alto
Impatto
sulla
struttura di
business
Era III Integrazione Interna
Era II Personal Computer
Era I Automazione ed Efficienza
Basso
1950
46
2010
Tony Murphy “ Achieving Business Value from Technology” Gartner 2002, pag. 13-23
47
3.1.1.
L’era dell’automazione
In una prima fase, che può essere definita come l’era dell’ automazione, controllo dei
costi ed efficienza, i computer furono acquistati per automatizzare specifici business o
funzioni aziendali, che generalmente coinvolgevano grandi volumi di transazioni
ripetitive. Tipiche applicazioni erano le paghe e la gestione degli ordini. I sistemi
sviluppati in questa fase erano rivolti ad eliminare i processi basati su un ampio uso di
documenti e a ridurre i calcoli manuali aumentando
velocità e accuratezza. Questi
fattori fornivano anche la giustificazione per valutare i progetti in sistemi informativi e le
motivazioni principali erano dirette, costituite da tangibili risparmi .
Era relativamente facile stabilire che cosa potesse essere automatizzato e valutare
l’impatto dell’automazione in termini di risparmio ( per esempio il personale). I costi di
sviluppo e di gestione del sistema informativo si potevano limitare alle spese dirette ed
indirette associate con lo sviluppo, la gestione e l’imputazione dei dati, nonché al costo
dell’ hardware.
In termini organizzativi le risorse e le competenze dedicate alla gestione dei Sistemi
Informativi erano concentrate in un Ufficio specifico, profondamente separato dagli altri
Uffici. Il Ced, Centro Elaborazione Dati, ( era il nome che veniva dato all’ufficio dedicato
ai Sistemi Informativi), aveva una scarsa conoscenza del business, così come gli utenti
non erano incoraggiati ad approfondire la conoscenza dell’informatica. Questa
separazione creava una serie di problemi ( incomprensioni e conflitti) che avevano
comunque una scarsa importanza perché l’informatica andava a sostituire forza lavoro.
3.1.2.
L’era della produttività
Con la crescita esplosiva del Personal Computer, dal 1981 in avanti si è entrati nell’era
della produttività e del miglioramento dell’uso dell’informatica da parte dell’utente . Con
l’avvento del Pc si riducono i costi dell’ hardware e del software, si diffondono pacchetti
informatici standard e soprattutto tende ad essere eliminata la separazione tra
specialisti informatici ed utenti. Viene inoltre sconvolto il lavoro d’ufficio con la
progressiva e crescente autonomia dell’utente nell’uso di molte applicazioni.
48
Ai fini della valutazione della fattibilità di un progetto informatico il principale
cambiamento che è derivato da questa fase è stata una crescente applicazione delle
tecniche finanziarie, che si basavano sul concetto del valore temporale del denaro. In
effetti questo significa che il denaro ha un costo e quindi devono essere analizzati i
progetti sulla base della distribuzione temporale dei benefici ( più rapidi per quanto
possibile) e dei costi differiti ( da sostenersi più lontani nel tempo).
I costi e i benefici derivanti dall’introduzione dei Pc non erano, tuttavia, facilmente
quantificabili a priori, in quanto si trattava di un investimento articolato nel tempo e il
cui impatto sulla produttività non era chiaro. Cominciavano ad essere richiamati aspetti
organizzativi e quelli legati alla rapidità e fluidità delle informazioni come giustificazione
degli investimenti. Come conseguenza venne introdotto il concetto di benefici intangibili.
3.1.3.
L’era del modello di business interno
In una fase successiva, che può essere definita come l’era del modello di business
interno, si è assistito alla transizione dell’ICT da un miglioramento nella gestione delle
transazioni e nelle modalità di lavoro dell’utente ad uno strumento al servizio di nuovi
modi di fare business.
C’e’ una crescente enfasi sulla visione del business come una serie di processi che
possono e devono essere fondamentalmente ridisegnati e semplificati dall’applicazione
dell’ICT. Questo approccio è conosciuto come riprogettazione dei processi
( BPR:
Business Process Reengineering).
Si diffonde la richiesta di una maggiore integrazione all’interno dell’azienda, che ponga
fine a sistemi frammentati e ad isole di automazione. Come l’informazione diviene un
fattore determinante di successo, la condivisione delle informazioni e la gestione della
conoscenza assumono un significato crescente. Ciò significa che le barriere tecniche ed
organizzative che hanno impedito l’integrazione devono essere sostanzialmente rimosse,
come un’abitudine obsoleta.
49
Le implicazioni per l’ICT sono immense. I sistemi ereditari cominciano ad essere
rimpiazzati da applicazioni ERP e cresce rapidamente lo sviluppo di applicazioni legate
alla condivisione e alla gestione della conoscenza, con la diffusione di data warehouses.
Si diffondono inoltre le architetture client-server. Si assiste ad una esplosione
dell’outsourcing della funzione ICT che è sempre più vista come un gestore di servizi
piuttosto che un fornitore diretto.
Questa fase portò ai primi tentativi di superare i criteri contabili per valutare gli
investimenti in ICT. Ciò derivò dalla crescente consapevolezza della loro inadeguatezza
e anche dal contributo teorico della catena del valore di Michael Porter, che contribuì a
diffondere la visione complessiva dell’azienda e quindi la necessità di passare da sistemi
di valutazioni di carattere settoriale, basati sull’analisi di una specifica applicazione
informatica, ad approcci che fossero in grado di cogliere la globalità dell’impatto dell’ICT
sull’organizzazione. Uno dei più influenti scrittori di questo periodo fu Paul Strassman,
che aprì nuovi terreni di ricerca spostando l’attenzione dalle analisi di ritorno degli
investimenti basato sulle logiche finanziarie alle questioni organizzative, culturali e a
quelle legate allo sviluppo delle competenze e delle capacità delle persone.
Esiste una scarsa evidenza dell’applicazione di queste nuove tecniche di valutazione (di
ordine strategico e di comparabilità con le caratteristiche organizzative) ai processi
decisionali dei manager. Innanzitutto non sono state sviluppate metodologie pratiche e
convincenti. In secondo luogo uno studio ha mostrato come il 90% dei dirigenti
incontrino grandi difficoltà a quantificare benefici intangibili, mentre circa il 60% ha
trovato che l’incertezza dei benefici abbia reso tali metodi difficili da applicare.
3.1.4.
L’era del modello di business interno-esterno
Attualmente le imprese si trovano nell’era del modello di business interno-esterno.
Globalizzazione , pressioni competitive, sviluppo dei computer portatili, internet sono
tutti fattori che stanno contribuendo a cambiare la struttura dell’impresa e a imporre
una crescente cooperazione tra partner. Imprese virtuali costruite su partnership
strategiche dinamiche, outsourcing, confini organizzativi fluidi richiedono enormi
investimenti in tecnologie per comunicare, collaborare e coordinarsi. Le imprese sono
50
state forzate a ripensare alla propria visione e a trasformare le loro strategie, strutture
organizzative e processi per venire incontro a più stretti legami con i partner coinvolti
nello sviluppo del business. Questi partner svolgono le attività strategiche in un modo
strettamente sincronizzato, spesso assumendo molti dei rischi per portare i prodotti e i
servizi sul mercato.
Queste nuove forze competitive richiedono alle imprese di divenire maggiormente
focalizzate verso l’esterno nella gestione dei processi di business e di conseguenza le
architetture informatiche devono essere orientate ad integrare anche il mondo esterno,
per esempio la rete dei clienti e quella dei fornitori. Tuttavia, l’integrazione interna deve
essere completata e mantenuta. E’ quindi prevedibile che tutte le imprese affronteranno
un drammatico aumento della domanda di dati esterni e di interfacce di processo. In
molte imprese, il numero di interfacce connesse esternamente sorpasserà la domanda
dell’integrazione interna di processi.
Crescerà l’ attenzione all’integrazione tra partner : per aumentare la loro agilità ed
abbassare il costo del capitale investito, molte imprese stanno abbracciando il modello
dell’integrazione verticale decentrata con un sistema costituito da una rete di imprese.
In questo modello, l’impresa si focalizza sulle competenze e si basa sui partner per le
altre attività. Ciò richiede che le applicazioni orientate all’integrazione debbano includere
tecnologie, che facciano leva su internet, per rendere possibile il coordinamento più
stretto possibile con i partner esterni.
Si svilupperà l’attenzione allo sviluppo del network: mentre il precedente modello era
caratterizzato da una stretta integrazione in un ambiente tendenzialmente statico, un
altro approccio è un’integrazione leggera tra partner che possono cambiare
continuamente in funzione delle mutevoli esigenze dei clienti e delle condizioni di
mercato. La tecnologia deve essere in grado di includere network che utilizzano
piattaforme tecnologiche differenti.
I principali problemi di questo modello sono legati al fatto che le tradizionali architetture
ICT sono rigide e difficili da integrare. Malgrado gli sforzi, non si è ancora pervenuti a
standard globali. Le imprese devono non solo essere in grado di connettere i propri
51
applicativi gestionali via extranet, ma devono pure provvedere una connettività flessibile
per creare relazioni strategiche di lungo periodo e relazioni opportunistiche di brevemedio termine.
Dal punto di vista della valutazione degli investimenti informatici, il processo decisionale
assume una complessità sempre maggiore con la conseguenza che oggi manca di fatto
un approccio sistematico per identificare e realizzare i benefici derivanti dagli
investimenti in ICT e quindi generare valore da questi investimenti. “ L’evoluzione
dell’IT verso l’ICT, ovvero verso l’incorporazione delle tecnologie di comunicazione webbased, determina una ancora più forte dematerializzazione di prodotti, processi
produttivi, risorse. L’ICT può generare nuove risorse intangibili”47 creando un patrimonio
immateriale che è di difficile valutazione, in quanto non riconducibile facilmente a fattori
tangibili, quali la riduzione dei costi o l’aumento del fatturato.
3.2. La
valutazione
di
diverse
alternative
di
architettura informatica
3.2.1.
Il metodo di valutazione: principi generali
L’evoluzione dell’ICT rende difficile una valutazione degli investimenti nei sistemi
informatici sulla base delle sole considerazioni finanziarie. E’ infatti difficile identificare e
soprattutto monetizzare i benefici attesi, che hanno spesso caratteristiche intangibili.
Frequentemente la valutazione dell’investimento viene ricondotta a mere comparazioni
di costo tra diverse alternative o, al contrario, a considerazioni vaghe e difficilmente
documentabili, quali “ la crescita dell’organizzazione “ , “ la fluidità dei processi
aziendali” , “ il miglioramento del servizio “ e così via.
E’ necessario individuare un metodo, che sia in grado di ricondurre aspetti qualitativi a
valutazioni quantitative, tali da poter confrontare diversi fattori di giudizio e diverse
47
Renata Paola Dameri: La Valutazione dell’information technology in azienda, ed. Isedi 2005 pag. 71
52
alternative di architettura ICT . L’ampia letteratura in merito alla “ software selection48”
e gli approcci prevalenti nella consulenza
49
conducono all’applicazione di metodologie
basate sull’attribuzione di punteggi ai diversi criteri di valutazione, mediante valutazioni
necessariamente soggettive e seguendo procedimenti, “ il cui risultato più importante
non è il punteggio stesso, ma la scelta dei criteri da utilizzare per valutare il sistema. ….
è opportuno ripetere l’applicazione del modello più volte, cambiando i criteri e i pesi per
vedere quanto il cambiamento del risultato risenta di adeguate modifiche dei parametri
50
“.
In questo paragrafo viene illustrato un metodo di valutazione, che rappresenta una
semplificazione delle metodologie prevalenti, sia dal punto di vista delle analisi che delle
modalità di calcolo, così da poter essere utilizzato anche in aziende di medie e piccole
dimensioni e con risorse relativamente limitate. Il riferimento metodologico è costituito
dalle tecniche multi criterio (o multi attributo), secondo le quali è possibile scomporre
l’oggetto delle analisi in fattori semplici, ossia i criteri, che lo descrivono in modo
esaustivo, ed è possibile analizzare separatamente i criteri stessi. Il primo passaggio
dell’analisi multi criterio è quindi l’individuazione dei criteri e la loro comparazione con
differenti alternative, mediante una matrice di valutazione. Non essendo possibile
addizionare le diverse valutazioni ( in quanto di carattere qualitativo), occorre procedere
ad una trasformazione di scala che esprime tali valutazioni in forma di punteggi. I
punteggi attribuiti ai singoli criteri non tengono conto delle priorità e quindi
dell’importanza attribuita ai criteri stessi: occorre, quindi, procedere alla normalizzazione
della matrice di valutazione (per rendere comparabili ed omogenee i dati) e
all’assegnazione di pesi relativi ai criteri (per stabilire un ordine di importanza ai criteri
stessi). L’ultimo passo di questo procedimento è definito con il termine di “ calcolo degli
ordinamenti”, con il quale si combinano pesi e punteggi in corrispondenza di ciascuna
delle alternative.51
48
Si veda il recente contributo di Ajay Das “ E-provider evaluation: an exploratory study Journal of Technology
Management n.1 2004 pag.46-61
49
Si veda la metodologia proposta dalla Gartner con l’IT Value Process in Tony Murphy “ Achieving Business Value
from Technology” Gartner 2002, pag. 77-149
50
Kenneth Laudon, Jane Laudon Management dei sistemi Informativi Ed. Peason-Prentice Hall 2003 pag. 519
51
W. G. Sullivan, E. M. Wicks, J.T. Luxhoj Economia Applicata all’ingegneria ed. Pearson Prentice Hall 2006
53
Il punto di partenza del percorso di valutazione è la nozione di Architettura Informatica,
già illustrata. L’approccio consiste nel selezionare l’architettura ICT tra diverse
alternative considerando di avere a disposizione un portafoglio di potenziali architetture.
Ciascuna di queste genera benefici, rischi e costi, che vengono valutati in relazione alle
quattro componenti dell’Architettura Informatica (infrastrutture computer, infrastrutture
di rete, office automation, applicativi gestionali), ed eventualmente per ciascuno delle
categorie nelle quali si articola ciascuna delle componenti, almeno per quelle
considerate più rilevanti.
In termini sintetici il procedimento logico è il seguente:
1. vengono individuati i criteri con i quali valutare le differenti alternative di
architettura informatica. Una volta identificati i criteri di valutazione, viene
attribuito a ciascuno di essi un peso percentuale, misurato sul totale dei criteri,
pari a 100; il peso percentuale dovrà rispecchiare l’importanza per l’azienda del
criterio di valutazione. Per esempio, attribuire alla riduzione delle ridondanze
tecnologiche e ai costi di acquisto rispettivamente pesi percentuali pari al 10% e
al 50% significa dare maggiore importanza al secondo criterio di valutazione
rispetto al primo;
2. viene attribuito un giudizio di importanza (su una scala di punteggi da 0 a 5) a
ciascuna delle componenti dell’architettura informatica;
3. viene quindi elaborata una matrice per ciascuno dei criteri di valutazione, che
incrocia le componenti dell’Architettura Informatica con ciascuna delle alternative
di architettura che sono state individuate: all’incrocio tra componente e soluzione
fornita dall’alternativa di architettura viene attribuito un giudizio di adeguatezza
(sempre su una scala di punteggi da 0 a 5), punteggio che deve rispecchiare
l’aderenza della soluzione fornita da ciascuna delle alternative alle esigenze
aziendali rispetto a ciascuno dei criteri di valutazione e per ogni componente
dell’Architettura. Il punteggio attribuito a ciascuna delle soluzioni viene
moltiplicato per il punteggio attribuito ad ogni componente così da ottenere un
54
giudizio
di
sintesi
dell’impatto
dell’alternativa
su
ciascuna
delle
parti
dell’Architettura;
4. viene infine elaborata una matrice di sintesi, nella quale vengono incrociati i
criteri di valutazione con le diverse alternative di architettura e i relativi punteggi.
La moltiplicazione dei due sistemi di punteggio da 0 a 5 (uno relativo
all’importanza della componente dell’architettura informatica e l’altra concernente
all’aderenza della soluzione fornita dall’alternativa di architettura) fornisce un
voto complessivo ( con un massimo di 25 punti) che viene pesato con l’ incidenza
percentuale del criterio di valutazione. Per esempio, l’infrastruttura di rete, che è
una delle componenti dell’architettura informatica, è considerata della massima
importanza (e quindi ha un punteggio di 5). In corrispondenza di questa
componente, una delle alternative di architettura informatica fornisce la migliore
soluzione in termini di riduzione delle ridondanze tecnologiche ( e le daremo
quindi il voto di 5) ad un costo elevato ( e quindi le verrà attribuito, per esempio,
un punteggio di 1). La moltiplicazione dei due punteggi (l’uno relativo alla
componente e l’altro alla soluzione) fornirebbe un voto complessivo di 25 per la
riduzione delle ridondanze tecnologiche e di 5 per quanto riguarda il costo, la cui
somma algebrica fornirebbe un punteggio complessivo di 30. Questa valutazione
potrebbe rivelarsi non corretta in quanto non tiene conto dell’importanza
attribuita ai diversi criteri di valutazione. Seguendo l’esempio, la riduzione delle
ridondanze tecnologiche non viene presa in grande considerazione (incidendo per
il 10% del totale), mentre si dà grande importanza al costo (che incide per il
50%). Si perviene in tal modo ad un giudizio di sintesi (in questo esempio pari a
5) sulla validità di ciascuna delle alternative di architettura informatica, che è
stata analizzata.
55
Esempio numerico di matrice complessiva di valutazione
Riduzione
delle Costo
ridondanze
di
Totale
costruzione
Punteggi
tecnologiche
Punteggio
attribuito
alla a)
5
a)
5
10
attribuito
alla b)
5
b)
1
6
componente
Punteggio
soluzione fornita dall’alternativa
esaminata
Punteggio
congiunto c)= a)*b) 25
componente
attribuita
+
al
c)= a)*b) 5
30
d)
n.d.
soluzione
criterio
di
valutazione
Peso percentuale dell’importanza d)
attribuita
al
criterio
10%
50%
di
valutazione
Punteggio pesato con il peso e)= c)*d)
percentuale
attribuita
di
al
2,5
e)=c)*d) 2,5
5
importanza
criterio
di
valutazione
Come si può constatare, il metodo permette di arrivare ad una valutazione, mediante un
approccio analitico, che evidenzia principalmente:
-
l’importanza attribuita a ciascuna delle componenti dell’Architettura Informatica in
relazione alle finalità perseguite;
-
l’individuazione di criteri di valutazione che corrispondono a “ driver” generatori dei
benefici, dei rischi e dei costi e del contributo che ciascuno di essi dà alle diverse
alternative di Architettura;
-
l’importanza attribuita a ciascuno delle soluzioni fornite dall’alternativa di architettura
informatica sul percorso criteri di valutazione – componenti dell’architettura –
aderenza della soluzione fornita dall’alternativa alle esigenze dell’azienda.
56
Il metodo di calcolo per punteggi permette poi di effettuare una serie di simulazioni,
così da aiutare la direzione aziendale a capire i presupposti alla base delle decisioni e
quindi i vincoli e i rischi all’interno dei quali vengono assunte le decisioni di
investimento.
Come sottolinea la Gartner Inc., si tratta di portare avanti un’attività di forte
coinvolgimento dell’azienda, che deve iniziare “ con un workshop fortemente interattivo
che è finalizzato ad introdurre una comprensione di alto livello dei driver e della
dinamica di investimenti IT. I manager si sentono spesso incerti o perfino intimoriti
quando si misurano con questo problema ed è quindi fondamentale farli sentire
confidenti e familiari con questa materia
52
“.
Di seguito viene presentato il percorso logico da utilizzare per una corretta valutazione
dell’Architettura Informatica.
Analisi del
Contesto
Individuazione
Alternative
Analizzare le diverse
alternative alla luce
del loro
allineamento
strategico,
organizzativo e della
coerenza interna
Diagnosi delle
dotazioni
informatiche
Definire il grado di
adeguatezza delle diverse
componenti
dell’architettura
informatica
Analisi delle
alternative per
singolo fattore
Effettuare una analisi dei dati
fondamentali dell’azienda con
attenzione ai processi primari
e alle relazioni interne con
l’esterno
Individuazione
fattori di
valutazione
Descrivere i fattori di
valutazione in relazione al
contesto e darne un peso
di importanza
Descrivere e valutare le soluzioni
fornite da ciascuna alternativa in
corrispondenza di ciascuno dei
fattori di valutazione
Giudizio
complessivo
52
Tony Murphy “ Achieving Business Value from Technology” Gartner 2002, pag. 81
57
3.2.2.
Analisi del contesto ed individuazione delle
alternative
La prima fase consiste in un’analisi del contesto aziendale, finalizzata ad identificare i
seguenti aspetti:
-
Dati segnaletici dell’azienda: ragione sociale e forma societaria, localizzazione della
sede e numero di unità produttive, fatturato, di cui estero, numero di dipendenti, di
cui personale di sede, tipologie di prodotti, organigramma e procedure aziendali, per
esempio manuale di qualità.
-
Contesto aziendale: incontri con il top management, finalizzati a capire i seguenti
aspetti: principali interlocutori esterni (clienti, fornitori, istituzioni, rete di vendita) e
le relazioni più importanti (per esempio, con i clienti piuttosto che con la rete di
vendita), i cambiamenti più rilevanti in atto nel contesto esterno, le strategie che si
intende adottare per reagire ai mutamenti esterni, una descrizione delle attività
svolte dalle diverse funzioni aziendali e le relazioni più frequenti tra queste. E’
sempre utile una breve visita allo stabilimento o reparto produttivo così da ricostruire
il lay out (distribuzione spaziale delle macchine, flusso delle merci dall’entrata
all’uscita) e avere una visione delle principali tecnologie utilizzate (processi
produttivi, materiali, tecnologie di fabbricazione e di progettazione, metodi di
lavoro).
-
Individuazione delle alternative di architettura ICT: viene preparato un documento
di sintesi, che riporta i dati segnaletici e le principali caratteristiche del contesto
aziendale, da discutere e validare con la direzione aziendale . Sulla base di questo
documento vengono individuate le diverse alternative di architettura ICT.
Per ciascuna delle alternative considerate, è opportuno elaborare lo schema seguente:
-
breve descrizione dell’architettura ICT, articolata secondo le sue componenti:
infrastrutture di computer, infrastrutture di rete, office automation, applicativi
gestionali;
-
livello di allineamento strategico: esprimere un giudizio (alto, medio, basso)
dell’aderenza di ciascuna delle soluzioni individuate ai cambiamenti in atto nel
contesto esterno e alle strategie espresse dal top management;
58
-
livello di allineamento organizzativo: esprimere un giudizio (alto, medio, basso)
dell’aderenza
di
ciascuna
delle
soluzioni
individuate
alle
caratteristiche
dell’organizzazione;
-
livello di coerenza interna: esprimere un giudizio (alto, medio, basso) dell’aderenza
delle soluzioni individuate al grado di bilanciamento dell’architettura ICT.
Questa prima fase, quindi, è prevalentemente qualitativa ed è finalizzata a “ far
ragionare” la direzione aziendale sulle principali alternative, eliminando quelle che
risultano chiaramente incompatibili con le caratteristiche strategiche ed organizzative
e/o non fattibili sulla base di aspetti tecnici. In tal modo è possibile pervenire ad un
numero limitato di opzioni (tendenzialmente non superiori a 3), delle quali una deve
essere sempre costituita dalla situazione attuale, in quanto solo in tal modo è possibile
valutare la validità di investimenti rispetto ad una politica di mantenimento
dell’architettura esistente.
Questa fase ha anche la finalità di individuare gli obiettivi generali di carattere
informativo alle quali dovranno orientarsi le diverse alternative di Architettura
Informatica, offrendo le più efficaci soluzioni.
3.2.3.
Grado
di
adeguatezza
delle
componenti
dell’architettura informatica
L’analisi dell’architettura informatica attuale conduce ad individuare l’oggettiva
debolezza delle dotazioni informatiche e delle sue componenti alla luce dello stato della
tecnologia, dell’innovazione del settore e dei fattori di base che devono caratterizzare
una architettura informatica. Questa valutazione sarà tanto più oggettiva, e quindi
autonoma rispetto alle alternative individuate, quanto più ci si riferisce alle componenti
tecnologiche ( infrastrutture di computer e infrastrutture di rete), mentre per le altre
due componenti ( office automation e applicativi gestionali) il giudizio sarà
necessariamente influenzato dalla strategia aziendale, dalle caratteristiche organizzative
dell’azienda e dalle alternative individuate.
59
E’ chiaro che questa valutazione sarà il risultato di un’analisi da parte degli esperti
informatici (dell’azienda o esterni) e costituisce l’apporto
più significativo di queste
figure professionali al processo di valutazione.
La misura del grado di adeguatezza dell’architettura informatica viene sintetizzata
mediante l’attribuzione di un punteggio, su una scala da 0 a 5, alle componenti
dell’architettura in funzione dell’importanza crescente nella rimozione delle situazioni di
debolezza individuate.
3.2.4.
Individuazione dei criteri di valutazione
La seconda fase consiste nell’individuazione e nella pesatura dei criteri con i quali
valutare le diverse Architetture ICT. In generale, questi criteri dovrebbero discendere
dai risultati delle fasi precedenti mediante sessioni comuni con la direzione aziendale.
Si tratta di collocare ciascuna delle alternative di Architettura ICT in una struttura ad
albero, che permetta di identificare tre famiglie di criteri: massimizzazione dei benefici,
mitigazione dei rischi, ottimizzazione dei costi.
Di seguito viene riportata una illustrazione dei diversi criteri di valutazione da
considerare. I criteri di valutazione così come la loro struttura gerarchica potranno
modificarsi in funzione dell’oggetto della valutazione ( maggiore peso delle componenti
tecnologiche dell’architettura rispetto a quelle più gestionali) e in relazione al punto di
vista del valutatore e del decisore.
Massimizzazione dei benefici
Con la nozione di benefici si fa riferimento ai vantaggi, tangibili e intangibili, che
l’architettura ICT apporterà all’azienda in relazione alle strategie e alle finalità affidate
ai sistemi informatici.
Generalmente, i principali driver generatori di benefici sono costituiti dalla rispondenza
ai fabbisogni informativi e di rete, dalla riduzione delle ridondanze tecnologiche, dal
60
mantenimento di un livello di indipendenza rispetto a fornitori e tecnologie, nonché dal
contributo che l’architettura ICT può dare all’integrazione. E’ ovvio che possono essere
individuati altri driver generatori di benefici, tenendo conto delle peculiarità aziendali e
dei specifici obiettivi affidati ai sistemi informatici.
Rispondenza ai fabbisogni informativi e di rete
Con la nozione di rispondenza ai fabbisogni informativi e di rete si intendono le
caratteristiche generali dell’architettura informatica sotto due punti di vista:
-
le funzioni di elaborazione, memorizzazione e di supporto che dovranno essere
svolte dall’architettura informatica. Per esempio: creazione di un unico archivio dati,
possibilità degli utenti di accedere ad una unica banca dati, funzioni evolute di
scritture nei personal computer;
-
le prestazioni tecniche, che dovranno essere assicurate. Per esempio: dimensione
delle memorie, velocizzazione nella trasmissione dei file, livello di iterazione degli
accessi al sistema.
Si fa, quindi, riferimento alle esigenze informative generali di tutta l’azienda, mentre la
definizione dei requisiti informativi di massima e di dettaglio, nonché delle successive
funzionalità del sistema informatico verrà rimandata al momento in cui è stata prescelta
l’architettura ICT da implementare.
Riduzione delle ridondanze
Si tratta di limitare la molteplicità di tecnologie e di prodotti utilizzati così da ottimizzare
le attività di assistenza e di manutenzione.
Gli elementi da considerare per valutare il livello di ridondanze sono i seguenti:
-
campo di variazione dei requisiti tecnici dell’hardware e delle infrastrutture
tecnologiche, a livello di server, personal computer e reti di interconnessione. I
fattori da considerare sono in particolare le memorie primarie, le memorie
secondarie (che archiviano a lungo termine all’esterno della memoria primaria), i
61
dispositivi di input che raccolgono i dati e per convertirli in formato elettronico
(tastiera, sistemi di puntamento, automazione nell’introduzione dei dati),i
dispositivi di output (monitor, stampanti) e le modalità di elaborazione dei dati. I
requisiti tecnici dell’hardware riguardano le capacità di memorizzazione, la
velocità di elaborazione e il grado di compatibilità delle diverse parti
dell’hardware;
-
numerosità degli standard e dei sistemi operativi. Per quanto riguarda gli
standard ci si riferisce in modo particolare a quelli relativi alla codifica e a quelli
relativi all’interfacciamento, così da permettere ai sottosistemi di interagire in
modo corretto. Il tema degli standard così come quello dei sistemi operativi
assume particolare rilievo e complessità se si intende valorizzare l’interazione con
soggetti esterni all’azienda;
-
varietà delle tecnologie di database (commerciali rispetto a quelli proprietari) e
linguaggi di programmazione utilizzati;
-
numero di fornitori di hardware e di software.
Questo criterio di valutazione è tendenzialmente in contrasto con quello illustrato di
seguito e quindi comporta di ricercare un equilibrio tra aspetti tra loro non
complementari.
Salvaguardia dell’indipendenza
Si tratta di assicurarsi che non si viene a dipendere da fornitori e/o da specifiche
competenze così da assicurarsi un ampio spettro di scelte nel futuro.
In questo caso, si tratta di incrociare il numero dei fornitori con le diverse componenti
dell’architettura ICT, tenendo conto sia del grado di concentrazione del volume di
acquisti rispetto alle aziende fornitrici che delle tecnologie utilizzate dal fornitore stesso.
Il giudizio dovrà tener conto dell’importanza della singola componente dell’architettura
ICT e della sostituibilità del fornitore con altri fornitori e con differenti soluzioni.
62
Contributo all’integrazione
Occorre valutare in che misura le diverse alternative di architettura informatica
favoriscono la creazione di una base comune di informazioni e una rete unitaria di
comunicazioni.
L’integrazione costituisce un obiettivo da perseguire di per sé, a prescindere dagli
specifici fabbisogni informativi, in quanto migliora gli elementi di collaborazione e di
condivisione
dell’organizzazione,
rendendone
quindi
agevole
ed
efficace
il
funzionamento.
I fattori che contribuiscono all’integrazione sono molteplici, ma in generale riguardano il
numero e la fluidità delle transazioni, il miglioramento delle comunicazioni tra persone
ed unità organizzative, la realizzazione di un'unica base dei dati, delle informazioni e
delle conoscenze, nonché l’agevolezza con cui le persone possono accedere ad una
banca dati condivisa ed effettuare interrogazioni ed elaborazioni, guidate o non.
In particolare gli aspetti da investigare sono i seguenti:
-
in presenza di sistemi ereditari, verificare se è stato adottato un unico DBMS e il
livello di affidabilità e di qualità prestazionale delle eventuali interfaccia
tecnologiche;
-
in presenza di sistemi Erp, verificare la compatibilità tra la soluzione adottata e le
caratteristiche dell’organizzazione;
-
in presenza di un data warehouse, verificare il grado di copertura di questa
applicazione tecnologica e le principali caratteristiche in termini di archivi e di
possibilità di estrazione verso il sistema di reporting;
-
verificare le caratteristiche delle soluzioni di rete e la loro capacità di supportare
l’integrazione informativa prevista dalle applicazioni informatiche adottate.
63
Mitigazione dei rischi
L’adozione di un’Architettura ICT ha un impatto su alcuni fattori che possono generare
dei rischi, ossia delle perdite di valore per l’azienda in un futuro, più o meno prossimo.
E’ necessario tener conto di questi fattori al fine di ridurne l’impatto negativo.
I driver generatori del rischio sono generalmente la consistenza con l’attuale
architettura, la scalabilità, la flessibilità e la coerenza con il settore industriale di
riferimento. Anche in questo caso si possono individuare altri fattori in funzione delle
specificità aziendali.
Consistenza con l’attuale architettura
Si tratta di valutare la capacità delle nuove soluzioni di integrarsi con le tecnologie e le
applicazioni oggi in uso; uno dei principali problemi è che gli attuali sistemi continuano a
funzionare e a dare valore all’organizzazione. Il problema di integrare nuove e vecchie
tecnologie non va sottostimato, in quanto rappresenta una delle principali sfide nella
transizione da una architettura ad un’altra.
Scalabilità
“ La scalabilità fa riferimento alla capacità di un computer, un prodotto o un sistema di
espandersi per rispondere alle richieste di un maggior numero di utenti e (individua)
quindi quando un sistema hardware viene saturato”53, ma in senso più lato occorre
intendere con la nozione di scalabilità la capacità di una Architettura ICT “ di rispondere
alle richieste future, offrendo elevati livelli di prestazioni e disponibilità per le
applicazioni critiche dell’azienda”.
Sotto il profilo dei problemi legati alla scalabilità, l’aumento delle richieste dell’utente si
traduce in una crescita del volume delle transazioni, del volume dei dati di entrata e di
quelli prodotti, nelle dimensioni degli archivi e nell’incremento del numero delle
53
Kenneth Laudon, Jane Laudon Management dei sistemi Informativi Ed. Peason-Prentice Hall 2003 pag. 251 e
pag.361
64
postazioni utenti54. La scalabilità è un concetto a più dimensioni e quindi occorre
valutare ciascuna delle alternative di architettura informatica alla luce delle diverse
dimensioni della scalabilità, che sono fondamentalmente le seguenti:
-
memoria: verificare se esiste un legame proporzionale tra l’incremento delle
dimensioni del database (per esempio, di un fattore x) e i tempi di risposta nelle
transazioni e nelle interrogazioni (che in una progressione lineare dovrebbero
aumentare dello stesso fattore x);
-
velocità: verificare se ad un aumento della capacità di elaborazione diminuiranno
in termini proporzionali i tempi di processamento delle transazioni;
-
carico di lavoro: verificare se ad un aumento del carico di lavoro, per esempio del
numero di transazioni, la precedente capacità di processamento può essere
mantenuta
aumentando
le
capacità
dell’hardware
proporzionalmente
all’incremento del stesso carico di lavoro;
-
costi di transazione: verificare l’andamento dei costi unitari di processamento
all’aumento del carico di lavoro.
Adottare una Architettura ICT “ poco scalabile” significa creare i presupposti per ulteriori
investimenti e/o pregiudicare le possibilità di sviluppo dell’azienda.
Flessibilità
Per flessibilità si intende la capacità di rispondere ai cambiamenti del modello di
business e delle stesse innovazioni in atto nel settore dell’ICT. La flessibilità di un
Architettura ICT va quindi verificata rispondendo alle seguenti questioni55:
-
è in grado di adattarsi o incorporare cambiamenti nelle relazioni con il mondo
esterno: in particolare, evoluzione della rete dei fornitori e dei clienti che porti a
dialogare con soggetti dotati di differenti tecnologie informatiche, evoluzione
della struttura societaria dell’azienda (joint venture, accordi societari, scorpori di
54
James A. Hall Accounting Information Systems ed. Tomson 2004 pag. 583
55
Manuel de Nicola Gestione Strategica dei Sistemi informativi aziendali in Antonio Teti Business and Information
Business Analyst ed. Hoepli 2007 pag. 31
65
rami d’azienda, fusioni ed acquisizioni) che costringa a verificare la compatibilità
dell’attuale architettura con sistemi informativi ed organizzazioni differenti;
-
è in grado di adattarsi alle frequenti innovazioni tecnologiche che si rendono
disponibili nell’ambito degli strumenti di ICT.
Il sistema economico è caratterizzato da una elevata turbolenza dal punto di vista del
quadro più complessivo di riferimento (come il ciclo economico, la normativa e così via),
dal punto di vista della struttura competitiva e dell’andamento, quantitativo e
qualitativo, della domanda, ed infine con riguardo alle stesse trasformazioni societarie
(fusioni, acquisizioni, joint venture, accordi internazionali ecc.).
E’ quindi opportuno che l’Architettura ICT sia sufficientemente flessibile da non
pregiudicare eventuali cambiamenti strategici, societari ed organizzativi, e da non
generare comunque perdite economiche e patrimoniali, che possono derivare dalla
realizzazione di un investimento il cui ritorno venga vanificato dai mutamenti nel
modello di business. E’ ovvio che queste considerazioni sono strettamente legate al
posizionamento attuale dell’azienda e alle prospettive strategiche, così come sono
dichiarate dalla direzione aziendale.
Coerenza con il settore di riferimento
L’obiettivo è di valutare l’ allineamento o meno all’architettura prevalente nel settore
industriale di riferimento.
Il concetto di coerenza rispetto al settore industriale di riferimento presenta due
connotati differenti, ma tra loro complementari. Innanzitutto significa essere in linea con
le caratteristiche competitive del settore, in quanto l’Architettura ICT impatta in misura
significativa sulla produttività aziendale e di conseguenza sulla creazione dei vantaggi
competitivi. In secondo luogo, l’allineamento con le tecnologie informatiche prevalenti
nel settore (concorrenti, clienti, fornitori, istituzioni) rende più agevole l’eventuale
integrazione con i soggetti esterni, con i quali più frequentemente si rapporta l’azienda.
66
Costi di investimento
I costi di investimento sono costituiti dal valore totale delle risorse spese per realizzare
un nuovo sistema informativo ( costo di costruzione) e per metterlo in esercizio ( costo
di avviamento). I costi di costruzione e quelli di avviamento sono solo una parte dei
costi totali, in quanto vanno anche considerati i costi di esercizio e di manutenzione (
costi indotti), che nel tempo si renderanno necessari per garantire l’operatività del
sistema, e quelli relativi alle attività svolte da parte degli utenti finali per adottare il
nuovo sistema ( costi nascosti).
Costi di costruzione
Si tratta dei costi di acquisto dell’hardware e del software, che possono essere
determinati sulla base di preventivi da parte del fornitore e di stime effettuate mediante
analisi di investimenti analoghi.
Classificazione
Contenuti
Costo di costruzione
Acquisizione hardware : computer, terminali,
dispositivi di memorizzazione, stampanti, canoni
linee trasmissione dati
Acquisizione software : licenze e/o acquisto
pacchetti applicativi, servizi di analisi e di
programmazione
I costi di avviamento
I costi di avviamento, o di implementazione, riguardano i costi necessari per mettere in
funzione l’hardware e il software. Anche in questo caso, per queste voci di spesa
occorre riferirsi a preventivi e , soprattutto, a stime di massima ricavate, per analogia,
dall’analisi di investimenti analoghi.
67
Classificazione
Contenuti
Costi di Avviamento
Personalizzazione: sviluppo di codici programma per
adattare il pacchetto applicativo alle richieste
dell’utente
Installazione dei computer e del software
Parametrizzazione: Definizione ed inserimento
parametri necessari ad attivare il software
dei
Addestramento: costi per l’addestramento degli
specialisti dei sistemi informativi e degli utenti
Testing e collaudo, se necessari
I costi indotti
I costi indotti riguardano i costi non direttamente imputabili all’investimento
sull’architettura informatica, ma che trovano origine in tutte quelle attività necessarie
alla gestione dell’investimento. Le voci di spesa più rilevanti sono quelle relative ai costi
di coordinamento dell’investimento e all’adeguamento degli spazi e delle impianti
dell’azienda. Vanno inoltre, anche considerate, anche le ricadute nel tempo
sull’impiantistica e su altre componenti dell’architettura informatica.
La determinazione di questi costi è resa difficile dal fatto che riguardano spesso costi
interni all’azienda (per esempio, ore impegnate dal personale nell’attività di
coordinamento, nella predisposizione degli spazi e nell’intervento di adeguamento
dell’hardware), che è difficile determinare a livello di preventivo. Qualora non sia
possibile una determinazione puntuale, anche se stimata, di queste voci di spesa, è
comunque opportuno considerare un parametro correttivo del totale dei costi di
costruzione e di quelli di avviamento, non inferiore al 20-25%.
68
Classificazione
Contenuti
Costi indotti
Supporto e Coordinamento : costi per fornire un
supporto tecnologico, un servizio di assistenza,
impegno di coordinamento da parte dei
responsabili: costo del personale addetto ai Servizi
Informativi dell’Azienda
Adeguamento: costo per l’aggiornamento dell’
hardware e del software relativi ad altre componenti
dell’Architettura: costo di acquisizione dell’hardware
e costo dei servizi offerti dalle Società fornitrici
Infrastrutture: costo di gestione e manutenzione
delle reti tecnologiche
Spazio ed energia: spazio fisico (costo figurativo
dello spazio) e costi di servizio per il consumo
elettrico delle apparecchiature
I costi nascosti
I costi nascosti riguardano i costi connessi all’impegno delle persone in fase di
implementazione delle nuove componenti dell’architettura informatica e che derivano
fondamentalmente dalla necessità di imparare a lavorare con nuove tecnologie. Fanno
parte dei costi nascosti tutte le spese relative ad attività di assistenza non previste e
all’aggiornamento dell’hardware e del software sulla base dell’operatività.
La stima di questi costi si presenta particolarmente complessa ma è di particolare
importanza in quanto queste tipologie di costi possono raggiungere incidenze rilevanti
sul valore dell’investimento56. Anche in questo caso, in mancanza di stime più puntuali,
si può prevedere un parametro correttivo sul totale dei costi di costruzione e di quelli di
avviamento, non inferiore al 20%.
56
Daniela Di Berardino Information Tecnhology e metodologie di valutazione finanziaria in Antonio Teti Business and
Information Business Analyst ed. Hoepli 2007 pag. 8
69
Classificazione
Contenuti
Costi nascosti
Perdita di produttività dell’utente finale per
addestramento, apprendimento di nuove modalità di
lavoro, guasti hardware e software: ore impiegate
dall’utente finale per il costo orario del lavoro
Revisione ed aggiornamento dei pacchetti applicativi
sulla base dell’operatività: ore impiegate dalle
società fornitrici e/o dal personale addetto ai Sistemi
Informativi per il costo orario del lavoro
Perdite annue di produttività (costi figurativi)
derivanti da interruzioni di servizio della rete, dei
server, delle stampanti, dei terminali, degli
applicativi: % incidenza sulla produttività delle ore
di fermo per il costo orario del lavoro
Attribuzione di un giudizio di importanza ai fattori di valutazione
Una volta individuati e valutati i diversi criteri di valutazione, il passaggio successivo
consiste nell’attribuzione a ciascuno dei criteri individuati di un “ giudizio di importanza”,
calcolato sulla base di una incidenza percentuale sul totale , considerato uguale a 100.
In termini pratici va elaborata una tabella analoga a quella presentata di seguito a fini
esemplificativi.
Criterio di valutazione
Massimizzazione dei benefici
• Rispondenza ai fabbisogni informativi e di
rete
• Riduzione delle ridondanze
• Salvaguardia dell’indipendenza
• Contributo all’integrazione
Minimizzazione dei rischi
• Consistenza con l’attuale architettura
• Scalabilità
• Flessibilità
• Coerenza con il settore di riferimento
Costi di investimento
• Costi di costruzione
• Costi di investimento
• Costi indotti
• Costi nascosti
Totale dei criteri di valutazione
Incidenza percentuale di ciascuno dei criteri di
valutazione sul totale
%
%
%
%
%
%
%
%
%
%
%
%
100 %
70
3.2.5.
Analisi delle soluzioni offerte da ciascuna delle
Architetture
La terza fase consiste nell’analisi e nella pesatura delle soluzioni offerte dalle diverse
alternative di Architettura.
A questo punto del percorso si sono individuati i criteri con i quali valutare le diverse
alternative e l’importanza attribuita alle diverse componenti dell’ Architettura. Si può
passare a descrivere e identificare le alternative di Architettura da prendere in
considerazione. Al fine di non limitarsi ad un giudizio qualitativo è opportuno, anche in
questo caso, ricorrere ad un sistema di punteggi, che “quantifichi” l’adeguatezza delle
soluzioni offerte dall’alternativa di Architettura rispetto a ciascuno dei criteri di
valutazione e in corrispondenza di ogni componente.
Per ciascuno dei criteri di valutazione, deve essere, quindi, elaborata una matrice che
confronti ogni componente dell’Architettura con ciascuna delle alternative e che riporti ,
per “ cella” di incrocio componente- alternativa, un giudizio di adeguatezza della
soluzione offerta dall’alternativa, su una scala di punteggi da 0 a 5. A questo punto è
possibile pervenire ad una valutazione di sintesi delle alternative. I giudizi di importanza
attribuiti ad ogni componente vengono “ moltiplicati” per il giudizio di adeguatezza
attribuito a ciascuna delle alternative in corrispondenza di ciascuno dei criteri di
valutazione.
In termini pratici va elaborata una tabella analoga a quella presentata di seguito a fini
esemplificativi. Nelle righe vengono riportate le componenti dell’Architettura Informatica
(sono state indicate per motivi di sintesi solo le famiglie) ed in corrispondenza di
ciascuna di esse la valutazione di importanza che viene data dall’analista e condivisa
dalla direzione aziendale. Nelle colonne vengono riportate le diverse alternative di
Architettura Informatica, con il giudizio di adeguatezza della soluzione rispetto a
ciascuna delle componenti dell’Architettura Informatica. Nella colonna definita “
Rispondenza” viene riportata, per ciascuna delle alternative di Architettura e in
71
corrispondenza
di
ciascuna
delle
componenti
dell’Architettura,
la
valutazione
complessiva, che deriva dalla moltiplicazione del “ voto di importanza” con il “ voto di
adeguatezza”.
Va elaborata la seguente tabella per fattore di valutazione
Componenti
Contenuti
a) importanza
Architettura attuale
Architettura A
Architettura B
b) contributo
c) contributo
d) contributo
Rispondenza
a)* b)
attuale a)* c) A a)* d) B
Imfrastrutture computer
4
5
5
3
20
20
12
Infrastrutture di rete
3
2
4
3
6
12
9
Office automation
1
5
5
5
5
5
5
Applicativi gestionali
Totale
5
0
5
2
0
31
25
62
10
36
3.2.6.
Attribuzione di un giudizio di sintesi delle
alternative di Architettura
La quarta fase riguarda l’elaborazione di un giudizio di sintesi sulle alternative. A questo
fine, non sarebbe tuttavia corretto non tener conto della diversa importanza attribuita ai
criteri di valutazione. E’ quindi necessario che il “ voto”, ottenuto dalla moltiplicazione
del giudizio di importanza con il giudizio di adeguatezza, venga “ pesato “ con
l’incidenza percentuale di ciascuno dei criteri di valutazione sul totale dei criteri di
valutazione.
In termini pratici va elaborata una tabella analoga a quella presentata di seguito a fini
esemplificativi. Nelle righe vengono riportati i diversi fattori di valutazione ed in
corrispondenza di ciascuno di essi la valutazione di importanza attribuita dalla direzione
aziendale. Nelle colonne vengono riportate le diverse alternative di Architettura
Informatica, con il giudizio di “ rispondenza” che deriva dalle elaborazioni di cui al
capoverso precedente. Nella colonna denominata “ Valutazione” e in corrispondenza di
ciascuno dei fattori di valutazione e di ciascuna delle alternative di Architettura
72
Informatica,
viene
riportata
una
valutazione
complessiva,
che
deriva
dalla
moltiplicazione del “ voto di importanza” dato al fattore di valutazione con il “ voto di
rispondenza”. La totalizzazione di questo risultato permette di pervenire ad un giudizio
complessivo delle diverse alternative di Architettura Informatica.
Tabella esemplificativa del calcolo per pervenire ai punteggi finali delle differenti alternative
Criteri di valutazione
Contenuti
Fabbisogni informativi
Ridondanze tecnologiche
Livello di indipendenza
Contributo all'integrazione
Totale Benefici
Attuale architettura
Scalabilità
Flessibilità
Coerenza
Totale Rischi
Costi di Costruzione
Costi di Avviamento
Costi indotti
Costi Nascosti
Totale Costi
Totale
Architettura attuale
a) importanza
30,00%
10,00%
0,00%
10,00%
50,00%
15,00%
10,00%
5,00%
0,00%
30,00%
10,00%
5,00%
5,00%
0,00%
20,00%
100,00%
b) punteggio
Architettura A
Architettura B
c) punteggio
31
27
31
6
95,00
55
13
62
6
136,00
65
65
34
28
192,00
62
58
20
57
197,00
9
59
31
64
163,00
21
21
34
49
125,00
d) punteggio
36
38
38
35
147,00
47
31
57
30
165,00
37
37
36
54
164,00
423,00
485,00
476,00
Valutazione
a)* b)
attuale a)* c) A a)* d) B
9,3
18,6
10,8
2,7
5,8
3,8
0,0
0,0
0,0
0,6
5,7
3,5
12,60 30,10
18,10
8,3
1,4
7,1
1,3
5,9
3,1
3,1
1,6
2,9
0,0
0,0
0,0
12,65
8,80
13,00
6,5
2,1
3,7
3,3
1,1
1,9
1,7
1,7
1,8
0,0
0,0
0,0
11,45
4,85
7,35
36,70 43,75
38,45
3.3. Determinazione dei costi e dei benefici
3.3.1.
Definizione di costo del ciclo di vita
E’ opportuno osservare come anche nel settore dell’informatica valga uno dei principi
fondamentali della pratica ingegneristica. I costi di un investimento devono essere
valutati alla luce del costo dell’intero ciclo di vita dell’architettura informatica adottata.
Con questo termine si intende la somma di tutti i costi della soluzione informatica, dal
momento dell’individuazione dei fabbisogni sino al suo ritiro o dismissione dall’uso
aziendale.57
Il concetto di ciclo di vita si riferisce, innanzitutto, ad una nozione di completezza di tutti
i costi coinvolti nella realizzazione, implementazione e gestione dell’architettura
informatica, sia quelli di ordine esterno, provenienti dai fornitori, che quelli che possono
57
W. G. Sullivan, E. M. Wicks, J.T. Luxhoj Economia Applicata all’ingegneria ed. Pearson Prentice Hall 2006 pag. 31-
32
73
avere origine all’interno della azienda. Alla nozione di completezza va poi aggiunta il
concetto relativo alla valutazione a vita intera dei costi, valutazione che presuppone un
giudizio in merito alla durata dell’architettura informatica prescelta (in funzione anche
dell’evoluzione tecnologica in atto e dei possibili cambiamenti aziendali) e per quanto
riguarda l’andamento delle diverse tipologie di costi durante l’intero ciclo di vita della
soluzione informatica.
La nozione di completezza dei costi è espressa nella letteratura informatica dal Total
Cost of Ownership (in sigla TCO). Si tratta di un approccio sviluppato dalla Gartner Inc.
nel 1987, utilizzato per calcolare tutti i costi del ciclo di vita di una apparecchiatura
informatica, per l’acquisto, l’installazione, la gestione, la manutenzione e la dismissione.
Questo metodo intende quindi tener sotto controllo tutti i costi, sia quelli espliciti ( costi
di costruzione e costi di avviamento) che quelli impliciti ( costi indotti e costi nascosti).
Inoltre
ha
la
finalità
di
prevederli
e
monitorarli
sull’intero
ciclo
di
vita
dell’apparecchiatura informatica. Si è fatto riferimento alla definizione di TCO per
qualificare i costi di investimento nel capitolo dedicato ai fattori di valutazione di una
architettura informatica.
Una evoluzione del TCO è il Total Cost of Management (in sigla TCM), che comprende
anche gli oneri finanziari figurativi e l’eventuale costo opportunità derivante dall’impiego
delle risorse finanziarie nell’investimento ICT piuttosto che in altre destinazioni58. Il TCM
intende anche misurare e monitorare la destinazione dei costi individuando le attività e
le unità aziendali che usufruiscono dei servizi ICT. Si tratta quindi un approccio
particolarmente efficace per attribuire i costi ai fini del controllo di gestione.
L’esperienza ha dimostrato come l’80% dei costi complessivi venga stabilito e “
vincolato” entro il termine della fase di costruzione e di avviamento a causa delle
decisioni prese in sede di analisi dei fabbisogni, di progettazione preliminare e di quella
dettagliata, nonché dei problemi che si incontrano in fase di avviamento. Al contrario,
58
Daniela Di Berardino Information Tecnhology e metodologie di valutazione finanziaria in Antonio Teti Business and
Information Business Analyst ed. Hoepli 2007
74
come mostra la curva del costo complessivamente sostenuto durante il ciclo di vita, solo
il 20% dei costi impegnati viene poi realmente sostenuto nella fase di costruzione e
avviamento, mentre l’80% viene sostenuto nella fase operativa.
Il concetto di ciclo di vita è quello di rendere esplicita l’andamento dei costi lungo
l’intero periodo di vita della soluzione informatica e, quindi, di portare l’attenzione
sull’impatto che le decisioni iniziali ( legate alla scelta dell’architettura informatica, alla
progettazione e all’avviamento) possono avere nel minimizzare o meno
i costi
complessivi del ciclo di vita, anche nella fase operativa.
E’ opportuno osservare come, nella fase di valutazione delle diverse alternative di
architettura informatica, occorre limitarsi a valutazioni di massima dei costi,
tendenzialmente cautelative in termini di valori, rimandando ad una fase ulteriore, una
volta scelta l’architettura ICT, per eventuali approfondimenti in termini di stime di costo.
Di seguito viene presentato un grafico che sintetizza il concetto di ciclo di vita.
Un concetto chiave:
il ciclo di vita
Costo
Possibilità di intervento
su ciclo di vita
Costo complessivo
sostenuto
Tempo
Stima dei
bisogni
Progettazione Progettazione Costruzione Gestione Dismissione
preliminare
di dettaglio
75
3.3.2.
Determinazione dei benefici
A fronte dei costi, un progetto informatico deve esprimere anche benefici, che
giustifichino l’investimento.
Un primo ordine di benefici è di carattere tangibile, in quanto legato alla riduzione dei
costi derivante dall’automazione di processi aziendali e dalla conseguente sostituzione
del lavoro umano con la macchina. Un secondo ordine di benefici è di carattere
intangibile in quanto legato alla capacità di migliorare le procedure di coordinamento e
di contribuire allo sviluppo del business.
Un elenco59, anche non esaustivo, dei benefici tangibili ed intangibili permette di
evidenziarne le differenze e il diverso impatto sulla valutazione in termini monetari
Benefici tangibili
Benefici intangibili
-
Riduzione degli immobilizzi
-
Miglioramento del servizio all’utenza e
maggiore soddisfazione
-
Riduzione dei costi del materiale acquistato
-
Riduzione del personale
-
Miglioramento
dell’organizzazione
-
Riduzione dei costi di duplicazione ed
immissione dei dati
-
Maggiore motivazione ed autonomia del
personale
-
Riduzione dei costi dovuti a dati erronei
-
Migliore disponibilità dell’informazione
-
Miglioramento
personale
-
Efficacia e rapidità del processo decisionale
-
Semplificazione delle procedure
-
Miglioramento della metodologia di lavoro
-
Tempestività
intraufficio
-
……
-
Riduzione del tempo richiesto per la
produzione dei documenti
-
Riduzione dei supporti cartacei
-
…….
della
delle
produttività
del
comunicazioni
dell’immagine
59
Daniela Di Berardino Information Technology e metodologie di valutazione economiche- finanziarie in Antonio Teti
Business Administration System Analyst ed. Hoepli pag. 12
76
Il crescente legame tra ICT e modello di business ha reso sempre più importante il
tema dell’individuazione e della valorizzazione dei benefici intangibili, che sono peraltro
quelli più difficili da identificare e da misurare.
All’inizio degli anni ’90 Strassman
60
ha classificato i benefici informatici su una scala
qualitativa in funzione della crescente difficoltà di qualificazione e successiva
quantificazione.
I benefici di primo livello ( e quindi di facile individuazione e quantificazione ) sono
costituiti da tutti gli interventi che hanno un impatto sui costi : incremento di
produttività a parità di volumi di produzione, eliminazione di attività esistenti, in quanto
vengono automatizzate , risparmi derivanti dal non dover sostenere costi ulteriori a
fronte di un aumento dei volumi.
I benefici di secondo livello sono costituiti da tutti gli interventi che permettono di
migliorare il livello del servizio: miglioramento delle prestazioni ; incremento dei ricavi;
nuova configurazione delle relazioni, che consiste generalmente nella ridefinizione dei
rapporti tra azienda e i soggetti con i quali interagisce ( in particolare clienti e fornitori).
I benefici di terzo livello sono costituiti da tutti gli interventi che migliorano il
posizionamento competitivo: aumento dei vantaggi competitivi, riduzione dei rischi e
sopravvivenza prevalenti nel settore per allinearsi al mercato e poter continuare ad
operare.
Un metodo per individuare le diverse tipologie di benefici è
la correlazione fra
funzionalità e benefici del sistema secondo il seguente flusso logico ed analitico,
proposto da Bracchi, Francalanci e Motta
61
. Prendiamo due differenti funzionalità del
sistema informativo: l’informatizzazione delle registrazioni contabili e l’integrazione con i
sistemi informativi dei fornitori. Al fine di determinare i benefici forniti da queste
funzionalità occorre, innanzitutto, chiedersi che cosa influenzano, ossia quali attività
vengono modificate e, di conseguenza, qual è l’impatto sulle risorse impiegate nelle
attività in oggetto. L’informatizzazione delle registrazioni contabili permette di realizzare
60
Paul StrassmanThe Business Value of Computers, Information Economic Press 1990
61
Giampio Bracchi, Chiara Francalanci, Gianmario Motta: Sistemi Informativi e Aziende in rete McGraw-Hill 2001 pag
.359
77
in automatico le scritture contabili e quindi influenza l’attività manuale, azzerandola in
tutto o in parte. Ne deriva che si assisterà ad una riduzione della manodopera
impegnata in questa attività. Al contrario, l’integrazione con i sistemi informativi dei
fornitori permetterà di avere un magazzino più basso in quanto sarà possibile
trasmettere in via telematica gli ordini ai fornitori riducendo i tempi di trasmissione e
rendendo più affidabili le comunicazioni. Ne deriva che si assisterà ad una riduzione del
livello di stock e quindi i benefici riguarderanno senza dubbio il livello del circolante.
Di seguito viene presentato un grafico che sintetizza il percorso da seguire per passare dalle
funzionalità all’individuazione dei benefici
Esempio
Funzionalità
Informatizzazione
delle registrazioni
Cosa influenza
Manualità cartacea
Benefici
Riduzione Manodopera
Esempio
Integrazione con SI
fornitori
Integrazione dei
flussi informativi
Riduzione scorte
Valorizzazione dei Benefici
Una volta individuati i benefici potenziali, il passo successivo è di quantificarli e
valorizzarli in quanto solo in tal modo è possibile riportare i benefici all’interno di calcoli
di convenienza economica sulla base delle tecniche finanziarie. A questo scopo è
indispensabile riportare tutte le tipologie di benefici a quattro grandi categorie di
fenomeni monetari:
-
riduzione dei costi, che deriva dalla sostituzione di uomini con macchine ( quindi
risparmi nel costo del lavoro), da risparmi delle quantità acquistate di merci e servizi
78
( per esempio riduzione degli scarti) a loro volta valorizzate sulla base dei prezzi di
acquisto, ed infine da economie nei prezzi di acquisto a parità di quantità comprate;
-
riduzione dei tempi di attraversamento, ossia del numero di giorni necessari
per svolgere determinate operazioni e più generale per trasformare le merci e i
servizi acquistati in prodotti e servizi erogati o venduti. La riduzione del tempo di
attraversamento deve avere un impatto in termini di risparmio sul capitale circolante
netto, ossia sulla differenza tra la somma delle giacenze di magazzino e dei crediti
clienti da un lato e i debiti verso i fornitori dall’altro lato;
-
crescita delle vendite, che viene misurata dall’incremento delle quantità vendute
a parità di prezzi di vendita e dalla crescita di quest’ultimi a parità di quantità
vendute;
-
mancato incremento dei costi e dei tempi di attraversamento e mancato declino
delle vendite, che derivano dalla salvaguardia della posizione competitiva.
Tutti i benefici intangibili, che non possono essere valorizzati
secondo le categorie
sopra indicate, non hanno di fatto impatto sul calcolo di convenienza economica sulla
base delle tecniche finanziarie e restano soltanto a livello di considerazioni qualitative.
Al fine di ricondurre i benefici intangibili a indicatori quantitativi, che possono essere
valorizzati in termini monetari, vengono spesso utilizzate tecniche basate su interviste
agli utenti, che, partendo dalle informazioni fornite dai sistemi di controllo dell’azienda,
cercano di orientare l’interlocutore a identificare e quantificare in modo sempre più
preciso i vantaggi potenziali, “ scremandoli “ da considerazioni meramente qualitative o
da affermazioni generiche.
Si tratta di tecniche costose in termini di tempo, che “ richiedono pratica ed esperienze
che
vanno
adattate
alle
caratteristiche
specifiche
dell’organizzazione.
Esse
rappresentano tuttavia un’occasione di apprendimento per gli utenti e gli operatori dei
sistemi informativi e contribuiscono a migliorare la trasparenza delle scelte aziendali
diventando patrimonio metodologico e culturale che dura nel tempo “62.
62
Tony Murphy: Achieving Business Value from Technology. Gartner 2002 pag. 206
79
3.4. Sintesi della letteratura sull’argomento
3.4.1.
Premessa
Questo capitolo ha l’obiettivo di illustrare le diverse metodologie di valutazione degli
investimenti nei sistemi informativi.
Esse possono essere sintetizzate in tre tipologie:
-
le tecniche finanziarie, che analizzano l’investimento dal punto di vista dei suoi
ritorni economici e finanziari;
-
l’approccio sistemico o basato sul portafoglio informatico , che colloca
l’intervento nei sistemi informativi nell’ambito dello sviluppo di una compatibile ed
efficace piattaforma tecnologica ICT;
-
l’approccio strategico, che parte dalla prospettiva strategica per verificare la
validità e la fattibilità dell’investimento.
Non si tratta di metodologie alternative, ma di approcci che possono convivere e che
assumono livelli di importanza differenti in relazione alla dimensione dell’azienda e alle
sue caratteristiche manageriali e imprenditoriali.
Se si disegna una matrice, che incrocia la dimensione aziendale con lo sviluppo dei
sistemi gestionali dell’azienda ( e quindi la prevalenza o meno di modalità formali di
gestione), l’approccio basato sull’analisi del portafoglio informatico prevale nelle aziende
di piccola-media dimensione , caratterizzate da modesti sistemi gestionali, mentre le
metodologie basate sulla prospettiva strategica vengono di solito perseguite in aziende
di grandi dimensioni e con un ciclo complesso e formalizzato di pianificazione e
controllo.
Le tecniche finanziarie trovano una larga applicazione nell’elaborazione di Business Plan
per aziende in start-up e rientrano nelle procedure di analisi degli investimenti delle
grandi imprese; trovano una modesta applicazione nelle piccole e medie imprese per
80
l’abitudine diffusa ad affrontare gli investimenti senza una analisi approfondita dei
possibili ritorni economici e finanziari.
Esiste, poi, un altro possibile approccio, largamente diffuso tra le aziende italiane:
affrontare l’investimento nei sistemi informativi secondo una pressoché totale mancanza
di visione complessiva dell’intervento ma operando secondo le spinte delle circostanze e
le proposte dei fornitori. Questa modalità di intervento, che può essere definita con il
termine approccio opportunistico, non viene illustrato in questo documento in
quanto non presuppone nessuna metodologia di valutazione.
Nel grafico successivo vengono collocate le diverse modalità di valutazione tra due assi:
dimensione aziendale e grado di formalizzazione dei sistemi gestionali
Grande
Approccio
Strategico
Portafoglio
Informatico
Dimensione
Tecniche
Finanziarie
Piccola
Approccio
Opportunistico
Formali
Informali
Sistemi di Gestione
3.4.2.
Le tecniche finanziarie
Il Valore Attuale Netto
Le tecniche finanziarie per la valutazione degli investimenti consistono in una proiezione
dei flussi di cassa attesi ( data dalla differenza tra i flussi di cassa in entrata e flussi di
81
cassa in uscita, questi ultimi comprensivi dell’ esborso per l’investimento), che vengono
riportati ad oggi applicando un tasso che incorpora il rendimento atteso da parte
dell’azienda (processo di attualizzazione).63
Al fine di determinare Il Valore Attuale Netto vengono attualizzati il saldo dei flussi di
cassa in entrata e di quelli in uscita relativo a ciascuno degli anni di durata
dell’investimento, considerando l’esborso relativo a questo ultimo come primo anno: se
la somma algebrica di questi valori è positiva, si ritiene valido l’investimento; in caso
contrario, l’intervento è da scartare in quanto non produce un valore superiore alle
spese sostenute per generarlo. Il Valore Attuale può essere calcolato utilizzando la
seguente funzionalità di Excel : Inserisci – Funzione – Van.
Si prenda per esempio la valutazione dell’acquisto di un nuovo applicativo gestionale per
la gestione della contabilità. Sarà necessario individuare il costo di acquisto e stimare i
costi
relativi
all’avviamento
(
installazione,
eventuale
personalizzazione,
parametrizzazione e formazione) e quelli connessi all’ assistenza e alla manutenzione.
Una volta determinati i costi, questi ultimi verranno distribuiti lungo la vita utile prevista
del nuovo programma per essere poi confrontati con i benefici attesi, che potrebbero
derivare da una riduzione dei costi, da un incremento di produttività e da un
miglioramento del servizio, che dovrà riflettersi in un incremento del fatturato.
Gli esborsi per investimento e la differenza tra flussi di cassa in entrata e flussi di cassa
in uscita relativi a ciascuno degli anni della vita utile dell’applicativo determinerà l’
andamento dei flussi di cassa netti attesi, i quali verranno attualizzati applicando un
tasso “ di sconto “.
La tabella successiva riporta una esemplificazione del calcolo di convenienza
dell’investimento sulla base delle tecniche finanziarie. Come si può constatare anche da
una rapida simulazione su un foglio Excel, il Valore Attuale Netto è fortemente sensibile
63
Per l’illustrazione delle tecniche finanziarie si fa riferimento a Kenneth Laudon e Jane Laudon Management dei
sistemi informativi, ed. Pearson-Prentice Hall 2004 pag. 513-518
82
ai valori dei flussi di cassa in entrata e di quelli in uscita e soprattutto alla loro
distribuzione nel tempo, nonché al tasso utilizzato per l’attualizzazione.
Esempio di proiezione di un flusso di cassa netto per l’acquisto e l’avvio di un applicativo
gestionale: valori in euro
1
10.000
7.000
3.000
5.000
Anni
3
0
25.000
0
14.000
5.000
0
5.000
15.000
5.000
0
5.000
15.000
5.000
1.000
6.000
15.000
5.000
8.000
13.000
15.000
5.000
10.000
15.000
15.000
Totale
10.000
7.000
3.000
5.000
5.000
5.000
4.000
25.000
19.000
83.000
75.000
0
-25.000
8%
L. 32.758,48
0
-14.000
15.000
10.000
10.000
25.000
20.000
20.000
35.000
29.000
20.000
35.000
22.000
20.000
35.000
20.000
70.000
145.000
62.000
Acquisti software contabilità
Personalizzazione
Installazione
Adeguamento Hardware
Parametrizzazione
Formazione
Modifiche al software
Assistenza
Manutenzione
Totale Costi
Riduzione costi ( mezza persona in meno)
Miglioramento del servizio ( maggiori
2
4
6
7
5.000
5.000
4.000
margini netti sulle vendite)
Totale Benefici
Flusso di Cassa Netto
Tasso di Attualizzazione
Valore Attuale Netto
5
Il metodo del tempo di ritorno
Il metodo del tempo di ritorno (o payback) consiste nell’individuazione del numero di
periodi (generalmente anni o mesi) necessari affinché la somma dei flussi di cassa netti
relativi ai periodi successivi all’investimento
superi il flusso di cassa in uscita
determinato dall’investimento . I valori possono essere non attualizzati (e quindi si parla
di payback semplice) o attualizzati.
Nell’esempio riportato nella tabella in Excel l’investimento verrebbe recuperato all’inizio
del quarto anno, in corrispondenza del quale diviene positiva la somma algebrica
dell’esborso per investimenti e dei flussi di cassa netti relativi ai periodi successivi
all’investimento.
Il punto di forza di questo metodo è costituito dalla sua semplicità di calcolo, che ne
costituisce anche la debolezza intrinseca: non considera il valore monetario del tempo e
non permette di calcolare la profittabilità dell’investimento.
83
Nella tabella successiva viene calcolato il tempo di ritorno sempre nel caso dell’acquisto di un
applicativo gestionale
1
25.000
0
-25.000
Esborso per investimenti
Flussi di cassa periodi successivi
Saldo progressivo
2
14.000
0
11.000
Anni
3
4
0
10.000
-1.000
5
0
20.000
21.000
0
30.000
9.000
Il tasso di redditività operativa
Il tasso di redditività operativa ( in sigla Roi- Return on investment o più comunemente
usato in ICT Roti- return on technology investment) rapporta il valore medio dei risultati
attesi netti al valore dell’investimento; il tasso così ottenuto permette di identificare a
quale costo è possibile prendere il denaro in prestito per finanziare l’investimento.
Il risultato atteso netto viene determinato rettificando con gli ammortamenti i flussi di
cassa netti successivi al periodo di investimento. Poiché il Roi è un concetto economico
e non finanziario è necessario calcolare anche gli ammortamenti, che essendo un costo
ma non un’ uscita finanziaria non vengono considerati nel calcolo del Valore Attuale
Netto.
Nell’esempio riportato nella tabella in Excel si può ipotizzare una vita media dell’investimento di
5 anni e quindi calcolare un Roi del 32% .
Anni investimento
1
2
a) Esborso per investimenti
b) Flussi di cassa netti
c) Flusso di cassa medio annuo, dato da b)
diviso cinque anni
d) Ammortamenti sulla base di una aliquota
del 20% pari a a) diviso 5 anni
e) Risultato atteso netto o reddito operativo
dato da c) - d)
f) Roi dato da e) diviso a)
25.000
0
14.000
0
3
0
10.000
4
Anni di vita utile
5
0
20.000
0
29.000
6
0
22.000
7
0
20.000
Totale
39.000
101.000
20.200
7.800
12.400
32%
La debolezza del Roi è data dal fatto che tralascia il costo del denaro nel tempo ed è
fortemente condizionato dalla previsione della vita utile dell’investimento e dalle
modalità di calcolo degli ammortamenti.
84
Indice di profittabilità
Uno dei limiti del valore attuale netto è il fatto che non fornisce alcun elemento per
valutare la profittabilità: una semplice soluzione è rappresentata dall’indice di
profittabilità che viene definito come il rapporto tra il valore attuale dei flussi cassa netti
prodotti dall’investimento e il valore attuale dei flussi cassa in uscita per l’investimento
iniziale.
Sempre nell’esempio riportato nella tabella in Excel, il valore attuale dei flussi di cassa
netti successivi al periodo di investimento è di circa 67.000 euro. Riportati valore attuale
degli esborsi per investimento, pari a circa 35.000 euro, si ottiene un indice di
profittabilità di 1,93.
Esempio di calcolo dell’indice di profittabilità
Anni investimento
1
2
a) Esborso per investimenti
b) Flussi di cassa netti
g) Indice di profittabilità dato da b)/a)
25.000
0
14.000
0
3
0
10.000
4
Anni di vita utile
5
0
20.000
0
29.000
Valore
Attuale
6
0
22.000
7
0 € 35.150,89
20.000 € 67.909,37
€ 1,93
Tasso interno di rendimento
Il tasso interno di rendimento ( in sigla IRR- Internal Rate of Return) consiste nel tasso
di interesse in corrispondenza del quale è uguale la somma algebrica dei flussi di cassa
in entrata e dei flussi di cassa in uscita. Nel nostro esempio il tasso interno di
rendimenti è il 29% e può essere ottenuto in Excel con il Comando – Funzione – TIR.
Cost .
Limiti delle tecniche finanziarie
Le tecniche finanziarie sono comunemente utilizzate nella valutazione degli investimenti.
Da tempo esse sono tuttavia oggetto di critiche, di particolare rilievo, quando si tratta di
investimenti prevalentemente “ intangibili “ quali quelli nei sistemi informativi:
85
è difficile identificare e soprattutto monetizzare i benefici attesi e quindi le tecniche
finanziarie sono di difficile utilizzazione.
Questa osservazione, che si può estendere alla valutazione di numerose tipologie di
investimento, rispecchia un problema reale, che si presenta tutte le volte in cui
l’intervento nei sistemi informativi non ha un impatto evidente sui costi e sulla
produttività.
Accettare una strutturale impossibilità di stimare i valori monetari dei possibili benefici
significa, tuttavia, relegare gli investimenti nei sistemi informativi tra tutti quelli
interventi che non vanno ad incidere sullo sviluppo e sulla redditività del prodotto e
vanno quindi affrontati
solo in una fase di espansione dell’azienda. Inoltre non è
possibile giustificare un investimento solo sulla base di considerazioni vaghe e
difficilmente documentabili, quali “ la crescita dell’organizzazione “ , “ la fluidità dei
processi aziendali” , “ il miglioramento del servizio “ e così via.
Individuare e quantificare i benefici rappresenta quindi uno sforzo di analisi e di stima,
che deve permettere di meglio valutare la fattibilità dell’iniziativa, i cui vantaggi
economici vengono troppo spesso dati per scontati, e di creare anche un sistema di
indicatori che permetta di monitorare l’andamento dell’investimento nel corso della sua
realizzazione e del suo complessivo ciclo di vita;
esiste il rischio di favorire gli investimenti a breve termine rispetto a quelli più a lungo
termine, che potrebbero essere essenziali per lo sviluppo dell’azienda.
Le tecniche finanziarie tendono a privilegiare tutti gli aspetti che possono essere
facilmente quantificati innescando un processo implicito di selezione verso alcuni
investimenti rispetto ad altri. Inoltre tanto più tempo è necessario per avere ritorni
positivi quanto più basso sarà il Valore Attuale Netto a causa delle peculiarità del
metodo dell’ attualizzazione.
86
Tutto ciò colloca gli investimenti di base, che interessano l’architettura complessiva e
non i singoli applicativi gestionali e specifici interventi sulla rete, in una luce
relativamente sfavorevole, rendendo difficile formulare strategie di lungo periodo.
Le tecniche finanziarie tendono senza dubbio a squilibrare il portafoglio informatico di
un’azienda, privilegiando di fatto le soluzioni con elevata intensità di risparmio di lavoro
e forte impatto sul mercato. D’altra parte tutte le soluzioni che generano ritorni in un
arco di tempo lontano presentano elevati livelli di incertezza. E’ quindi corretto che esse
vengano “ penalizzate “ così da fornire un segnale di avvertimento nei confronti del
management sulle difficoltà e i rischi relativi ad investimenti “ troppo innovativi” .
contribuisce a rendere incomprensibile la complessità degli interventi nei sistemi
informativi.
Le tecniche finanziarie sono necessariamente rozze e semplificanti, tendendo ad
articolare i problemi di un sistema informativo aziendale in tanti “ isole” ( i singoli
applicativi gestionali, i singoli interventi sulla rete ecc.), perché tanto maggiore è
l’articolazione quanto più è possibile identificare i costi e i benefici.
Questo approccio, definito da Paul Strassman con la parola “ micromyopia”, conduce di
fatto a non cogliere le complesse interrelazioni tra le diverse parti di una architettura
informatica di un’azienda, aprendo la strada ad un sistema frammentato e caratterizzato
da continui interventi per ricucire un assetto a macchie di leopardo.
Questa osservazione è senza dubbio corretta ma attribuisce alle tecniche finanziarie, e a
coloro che in azienda le padroneggiano, un ruolo e un peso aziendale che non
corrispondono alla realtà. La frammentazione dei sistemi informativi in isole tra di loro
insufficientemente
integrate
è
riconducibile
ai
rapporti
di
potere
all’interno
dell’organizzazione e ad una insufficiente visione complessiva del top management della
problematica informatica e del suo ruolo in azienda.
In sintesi, le tecniche finanziarie presentano numerosi limiti, in merito alla loro reale
applicabilità e in relazione ad uno sviluppo equilibrato del portafoglio informatico
87
dell’azienda. Esse, tuttavia, chiariscono i termini di fattibilità di un intervento nei sistemi
informativi, favoriscono la crescita manageriale dei responsabili preposti allo sviluppo
informatico e creano le basi per un linguaggio comune con il top management
dell’azienda.
Come hanno osservato Bracchi, Francalanci e Motta64 “ un approccio economico alla
valutazione dei costi e dei benefici rimane irrinunciabile, poiché permette di giustificare
le scelte tecnologiche in un linguaggio, quello economico, che è indipendente dalle
competenze tecniche possedute da chi è responsabile dell’approvazione dei progetti “.Le
caratteristiche semplificanti vengono poi incontro alle esigenze dei top management di
identificare dei punti di attacco alla soluzione dei problemi, riducendo l’incertezza
derivante dalla complessità aziendale.
La valutazione di un investimento in sistemi informativi non può prescindere dalle
tecniche finanziarie, che vanno tuttavia utilizzate al fine di meglio comprendere
le
condizioni per il successo economico dell’investimento ( e quindi avviare le necessarie
azioni correttive) piuttosto che come criteri rigidi di selezione.
3.4.3.
L’Approccio Sistemico
I limiti dei calcoli di convenienza finanziaria e la constatazione del fatto che gli
investimenti ICT costituiscano ormai una infrastruttura base dell’impresa, da realizzare
anche quando non genera ritorni economici significativi nel breve-medio periodo, sono
le due considerazioni alla base di una serie di ricerche e di contributi, che si sono
sviluppati negli ultimi anni, finalizzati a individuare e misurare il grado di coerenza e di
compatibilità della spesa in informatica rispetto alle diverse dimensioni dell’azienda, da
quella strategica agli aspetti organizzativi.
64
Giampio Bracchi, Chiara Francalanci, Gianmario Motta: Sistemi Informativi e Aziende in rete McGraw-Hill 2001 pag.
332
88
Si sono quindi prodotti numerosi “ framework”, che dovrebbero aiutare le imprese ad
effettuare decisioni corrette in tema di informatica e a fornire ai singoli manager
riferimenti per indirizzare i singoli investimenti ICT in un quadro di allineamento con le
strategie e le finalità perseguite tramite sistemi informativi.
Dell’ampia letteratura sull’argomento vengono riportati due contributi di rilievo.
Il primo contributo fa riferimento ai “ cinque pilastri “ descritti in un recente libro della
Gartner inc., più volta citato in questa dispensa. Secondo l’autore65, ogni qual volta si
effettua una valutazione di un investimento ICT sarebbe necessario tener conto dei
seguenti aspetti:
-
allineamento strategico, ossia in che misura gli investimenti ICT possono contribuire
a perseguire gli obiettivi aziendali. L’informatica è un fattore fondamentale per
consolidare il modello di business o per innovarlo ed è quindi indispensabile che gli
investimenti vengano incontro ad esigenze di breve periodo così come alla capacità
di creare valore nel medio- lungo periodo;
-
i processi di business, in quanto ICT e processi sono “ due lati della stessa moneta
“. Se l’investimento in informatica non è in grado di orientare l’organizzazione in una
logica di processo, essa non potrà fornire un contributo significativo all’acquisizione
di vantaggi competitivi e finirà per fallire a causa delle resistenze delle persone al
cambiamento e al mantenimento delle vecchie modalità di lavoro;
-
l’architettura ICT, ossia la capacità delle tecnologie di integrare e permettere lo
sviluppo delle strategie di business, dell’organizzazione e dei processi;
-
i ritorni finanziari, ossia sulla capacità dell’investimento di creare più reddito, di
acquisire risparmi di costo o di fornire una migliore gestione delle informazioni;
-
i rischi, ossia la valutazione degli effetti negativi che possono derivare
dall’investimento al fine di avviare un approccio strutturato per la loro mitigazione.
Un recente contributo66 pone, invece, enfasi sul governo del processo decisionale in
tema di investimenti ICT al fine di evitare che l’informatica evolva verso direzioni
65
Tony Murphy: Achieving Business Value from Technology. Gartner 2002 pag. 39-76
66
Peter Well, Jeanne Ross “ A matrixed approach to designing IT Governance “ MIT Sloan Management Review 2005
89
impreviste e comunque non dirette dal top management, in quanto non sono definite a
sufficienza le regole complessive al cui interno effettuare gli investimenti. Gli autori
disegnano una struttura gerarchica di cinque decisioni:
-
le linee guida in tema ICT ( “ IT principles “), che comprendono le decisioni di alto
livello in merito al ruolo strategico dell’IT per lo sviluppo del business e alle modalità
di finanziamento degli investimenti;
-
l’architettura ICT ( “ IT architecture “), che include un insieme integrato di scelte
tecniche per guidare l’organizzazione nel raggiungimento delle esigenze aziendali. Si
parte, quindi, dall’individuazione dei processi primari e dei loro legami reciproci e
della loro intensità informativa per passare poi ad analizzare i requisiti funzionali e
prestazionali che dovrebbero standardizzate per tutta l’azienda così da supportare
l’efficienza aziendale e integrare i processi. Da qui dovrebbero derivare le scelte
tecnologiche più opportune;
-
l’infrastruttura ICT ( “ IT infrastructure strategies “), che consiste nei servizi IT
centralmente coordinati per provvedere alle capacità informatiche dell’azienda nel
suo complesso. Occorre quindi assumere una serie di decisioni in merito a quale
tipologia di servizi infrastrutturali di base assicurare all’azienda, quali livelli di servizio
garantire, quale politica di outsourcing e come assicurare la manutenzione
complessiva delle infrastrutture;
-
le esigenze di applicativi gestionali ( “ Business application needs “), che devono
condurre a sviluppare internamente o acquistare i software gestionali. Ciò significa
trovare la corretta conciliazione tra le caratteristiche dell’infrastruttura e le esigenze
specifiche dell’utente, individuando in tal modo una dotazione di applicativi
sostenibile e compatibile;
-
l’individuazione delle priorità ( “ Prioritization and investment decisions “), che
riguardano quanto investire e dove investire.
3.4.4.
L’Approccio Strategico
La crescente consapevolezza del ruolo strategico dell’ICT ha spinto numerosi autori e
grandi gruppi industriali a inquadrare le scelte nel settore informatico nell’ambito delle
problematiche più generali di posizionamento e di elaborazione delle strategie aziendali.
90
In questo modo le metodologie di valutazione degli investimenti in ICT hanno risentito,
e risentono, dell’evoluzione degli strumenti di pianificazione strategica, che ha
sviluppato sempre nuove metodologie e strumenti efficaci per elaborare e gestire la
strategia.
Pianificazione a lungo termine
Molte aziende elaborano ogni anno, secondo una logica di scorrimento, un piano
poliennale ( normalmente triennale, ma in alcuni anni con un orizzonte più ampio), che
identifica gli obiettivi strategici, le principali azioni da portare avanti e ne analizza i
risultati in una proiezione del Conto Economico e dello Stato Patrimoniale.
L’informatica è una componente di questo Piano e segue quindi la seguente scansione,
proposta da Bowman sin dal 198167:
-
pianificazione strategica che inquadra lo sviluppo dell’informatica all’interno del piano
aziendale secondo le seguenti attività: a) valutare gli obiettivi organizzativi e le
strategie, b) pianificare la missione dei Sistemi Informativi, c) valutare l’ambiente, d)
pianificare le politiche, gli obiettivi e le strategie;
-
analisi dei bisogni informativi, che esamina i bisogni informativi e determina le
strategie
architetturali
dei
sistemi:
a)
valutate
le
strategie
informative
dell’organizzazione, b) redigere il piano principale dello sviluppo ;
-
allocazione delle risorse, che quantifica le risorse destinate allo sviluppo dei sistemi e
individua i progetti necessari : a) redigere il piano delle risorse, b) valutare i progetti
e redigere il piano dei progetti.
Questo approccio, che appartiene ad una scuola di pensiero dominante sino agli anni 80
( chiamata del Long Range Planning), è stata accusata di astrattismo formale, di
introdurre una cultura burocratica all’interno dell’azienda e soprattutto di imporre un
ciclo di pianificazione così lungo e complesso da essere dispendioso in termini di energie
e di non tenere il passo con i cambiamenti del contesto esterno.
67
Giampio Bracchi, Chiara Francalanci, Gianmario Motta Sistemi Informativi ed Aziende in rete ed. McGraw-Hill 2002
pag. 290-291. Si veda a questo proposito anche Carroll E. Frenzel Management of Information Technology ed. Boyd
& Fraser pag.67-89
91
Il pregio di questo approccio, che viene ancora seguito dai grandi gruppi industriali, è di
porre l’accento sulle compatibilità complessive, ossia sul costante equilibrio tra
investimenti e risorse, finanziarie ed umane: lettura delle compatibilità che viene
assicurata dalle proiezioni del Conto Economico e dello Stato Patrimoniale.
Una recente evoluzione di questo approccio è costituito dall’articolazione del Piano
Poliennale in Piani di Azioni ( il così detto Master Plan), che identifica alcuni indicatori
per Azione al fine di meglio qualificare gli obiettivi e di monitorare il raggiungimento dei
risultati previsti. Si tenta in tal modo di trovare un livello intermedio tra il Piano
Complessivo dell’Azienda e la definizione di azioni e di obiettivi, spesso troppo
qualitativi, a livello di ciascuno degli interventi.
I modelli di posizionamento
I modelli di posizionamento si concentrano sulla valutazione del contributo dell’ICT sul
modello di business.
Tra questi modelli si può richiamare quelli di Venkatraman ( 1994) e di Wind e Mahajan
( 1981), così come riportati da Bracchi, Francalanci e Motta68.
Il modello di Venkatraman
incrocia i benefici ottenibili con il tasso di cambiamento
innescato dall’intervento nei sistemi informativi. i benefici effettivi dell’informatica sono
proporzionali ai cambiamenti organizzativi: benefici elevati non sono ottenibili con
cambiamenti organizzativi marginali e viceversa forti cambiamenti organizzativi sono
inutili se portano solo a benefici incrementali. L’approccio di Venkatraman focalizza solo
un aspetto ( i cambiamenti organizzativi) e comunque non risolve il problema di come
valutare i benefici ottenibili.
68
Giampio Bracchi, Chiara Francalanci e Gianmario Motta Sistemi Informativi ed Aziende in Rete ed. McGraw-Hill
2002 pag. 296-302
92
Più interessante appare il modello di Wind e
Mahaian. Riprendendo la matrice
strategica della Boston Consulting Group, esso correla il posizionamento strategico
dell’azienda con la gamma dei benefici che si può ottenere dall’investimento nei sistemi
informativi:
-
stelle, che include le aziende che hanno un’elevata quota di mercato in un settore
in forte crescita: il suggerimento è investire. A fronte di questo posizionamento è
possibile portare avanti progetti di investimento in ICT che perseguono benefici
intangibili (per esempio, un nuovo sistema di controllo che permetta di migliorare le
capacità
decisionali
del
management),
in
quanto
esistono
le
condizioni
generali(risorse finanziarie, tassi di crescita e quote di mercato) per realizzare
interventi con risultati a lungo termine, anche ad alto rischio;
-
mucche da mungere, che include le aziende che hanno un’elevata quota di
mercato in un settore a bassa crescita: il consiglio è di non investire ma di utilizzare
le risorse finanziarie generate per altri investimenti. A fronte di questo
posizionamento occorre limitarsi a mantenersi in condizioni di parità con la
concorrenza, investendo in ICT il meno possibile;
-
punti di domanda, che riguardano settori ad alta crescita ma nei quali l’azienda ha
una bassa quota di mercato: il suggerimento è di valutare con attenzione
l’investimento. A fronte di questo posizionamento è necessario perseguire la ricerca
di vantaggi competitivi mediante investimenti in ICT con risultati a breve termine
anche su progetti ad alto rischio, in quanto occorre conquistare quote di mercato:
per esempio,interventi finalizzati ad aumentare le prestazioni del prodotto/servizio;
-
business marginali (definiti anche come dogs), che riguardano aziende con basse
quote di mercato e bassi tassi di crescita: occorre disinvestire. A fronte di questo
posizionamento è opportuno investire solo in progetti di ICT che conducono a
risparmi tangibili con impatto nel breve periodo.
Un’interessante evoluzione dei modelli di posizionamento è rappresentata dall’approccio
sviluppato da Jeffery e Leliveld69, che inquadrano l’investimento all’interno di una
matrice che correla la capacità di creare valore per il business con il livello del rischio:
69
Mark Jeffery, Ingmar Leliveld “ Best practices in IT portfolio management” MIT Sloan Management Review 2004
93
-
alto valore generato – basso rischio: gli autori consigliano di investire, definendo
l’investimento “ funding priority “;
-
alto valore generato – alto rischio: il suggerimento è di investire in modo selettivo
per la difficoltà di realizzare l’investimento, che è definito “ fund selectively “;
-
basso valore generato- basso rischio: si tratta di un investimento a bassa priorità,
definito anch’esso come “ fund selectively”;
-
basso valore generato – alto rischio: il consiglio è , ovviamente, di non investire, in
quanto l’investimento è classificato “ do not fund”.
La catena del valore
Riprendendo il concetto di Michael Porter della catena del valore , si analizzano le
attività specifiche del business individuando quelle dove i sistemi informativi hanno con
maggiore probabilità un impatto strategico.
In generale i sistemi informativi devono essere finalizzati a migliorare la gestione delle
attività che hanno un impatto sulla creazione del valore per il cliente in relazione
alle strategie competitive che si intende perseguire, che, come è noto, Porter classifica
in due grandi tipologie: leadership di costo e differenziazione. Oltre a fornire un quadro
teorico di riferimento, Porter e Millar indicano anche i passi che sarebbe opportuno
seguire nella definizione di una strategia nei sistemi informativi:
-
valutare l'intensità informativa dei prodotti e dei processi aziendali , che
generalmente dipendono dal numero dei fornitori e dei clienti e dalla quantità di
informazioni che devono essere trattate dall'azienda e/o dai fornitori e dai clienti;
-
valutare il ruolo dell’ICT nella struttura del settore industriale di appartenenza al fine
di prevedere gli investimenti futuri che potrebbero avere impatto sul livello di
competitività e sulle " cinque" forze che la governano ( identificate, come è noto,
da Porter nei concorrenti, nei fornitori, nei clienti, nei nuovi entranti e negli
eventuali prodotti sostitutivi);
-
identificare e ordinare secondo una scala di priorità le attività nelle quali l’ICT
potrebbe creare vantaggi competitivi sia riducendo i costi ( strategia di
leadership di costo) che ampliando gli spazi di
mercato ( strategie di
differenziazione). L'attenzione deve essere prestata sia alle singole attività
94
(partendo
ovviamente da
quelle che
hanno
i
costi
più
elevati) che ai
collegamenti tra le attività stesse al fine di migliorare la fluidità dei processi
aziendali e ridurne le ridondanze;
-
investigare come l’ICT potrebbe creare nuovi business, partendo ovviamente dal
patrimonio di dati, di informazioni e di conoscenze dell'azienda;
-
sviluppare un piano per prendere vantaggio dell’ICT, traducendo, quindi, in azioni
i risultati raggiunti dalle analisi precedenti. In questo senso i due autori si
preoccupano di sottolineare come l’ICT non può essere affidata solo agli
specialisti ma deve divenire patrimonio dell'intera organizzazione, che deve
essere
maggiormente
coinvolta
nelle
scelte
e
nel
governo
della
loro
implementazione.
Porter e Millar colgono il legame tra ICT e modello di business, sia in termini di
analisi che di contributo che l'informatica può svolgere per migliorare le strategie
competitive. I suoi limiti derivano proprio dal livello di astrattezza nella quale si
muovono necessariamente le analisi strategiche, che lasciano alle competenze e alle
capacità del consulente e dell'azienda la loro traduzione in termini di analisi e di piani
di intervento.
3.4.5.
L'Approccio Organizzativo
Stimolati dallo sviluppo dei prodotti ERP, che richiedono ingenti e complessi
investimenti per essere portati avanti in azienda, alcuni autori hanno sviluppo una
metodologia ( definita come Enterprise Resource Management, in sigla ERM) orientata
ad identificare il grado di " disponibilità " dell'organizzazione ad accettare le implicazioni
organizzative e culturali richieste da un nuovo pacchetto informatico.
Si tratta, in definitiva, di ricercare la coerenza tra organizzazione e caratteristiche
funzionali del pacchetto informatico e più in generale dell'architettura che si intende
adottare.
In termini di metodo si tratta di una check-list di domande, a ciascuna delle quali
viene fornito un punteggio ( generalmente da 1 a 4). Più il punteggio ottenuto è
95
elevato tanto più l'organizzazione è pronta ad adottare la nuova soluzione
informativa; al di sotto di un certo punteggio è necessario prevedere significativi
interventi in fase di implementazione.
Se si analizzano differenti soluzioni informative, per esempio un prodotto ERP a fronte
di modalità di integrazione mediante interfacce tra differenti applicativi gestionali, il
metodo permette di individuare la soluzione che implica i minori cambiamenti in termini
organizzativi.
In termini di contenuti le domande sono rivolte ad identificare le seguenti attitudini
aziendali:
-
in che misura l'organizzazione lavora effettivamente per processi e non per
strutture
verticali:
orientamento
organizzativi, abitudine a
al
cliente,
numero
limitato
lavorare in team e così via.
di
livelli
E' ovvio come
l'abitudine a lavorare secondo una logica unitaria e finalizzata al mercato
favorisca l'adozione di pacchetti informatici integrati, quali gli Erp, e più in
generale architetture unitarie;
-
in che misura sono diffuse le procedure e gli standard, e quindi modalità di
lavoro basate sul rispetto di regole di comportamento a fronte di una
prevalenza delle relazioni interpersonali e di approcci adattivi alle specifiche
situazioni.
Anche
in
questo
caso
la
presenza
di
metodi
di
lavoro
regolamentati favorisce l'adozione di pacchetti informatici rigidi, quali gli Erp,
e di un sistema di comunicazioni scritte a fronte a quelle verbali;
-
in che misura esiste una visione complessiva dell'azienda , che crea un
ambiente unitario, coeso e disponibile al cambiamento. Quanto più esiste
una forte leadership tanto più è possibile introdurre rilevanti trasformazioni
nel sistema informatico;
-
in che misura, infine, è diffuso un sistema di incentivazione del management,
che permetta di creare un efficace sistema premiante e quindi agganciare
una parte della retribuzione al successo del nuova soluzione informativa.
Questo approccio coglie il forte legame tra investimenti in sistemi informativi e
resistenze organizzative al cambiamento e focalizza l'attenzione sulla ricerca di una
compatibilità complessiva. Il metodo della check list è efficace e poco costoso in
termini di tempi e di risorse da impegnare nell'indagine.
96
3.4.6.
Conclusioni in merito all’approccio strategico ed
organizzativo
L’approccio strategico ha il pregio di ricercare il legame tra ICT e modello di business,
fornendo in questo senso un contributo rilevante sotto il profilo teorico.
Se si esclude la pianificazione a lungo termine, che costituisce uno strumento
largamente utilizzato nelle grandi aziende e all’interno delle quali si inquadra anche la
valutazione dei sistemi informativi, i modelli di posizionamento e il modello di business
hanno una scarsa applicazione al di fuori della stretta cerchia dei grandi gruppi
internazionali e dei grandi consulenti. E’ comunque difficile pensare che l’approccio
strategico possa avere una larga applicazione tra le piccole e medie imprese per la
scarsa diffusione presso queste realtà di strumenti di pianificazione strategica.
Rimane il fatto che la riflessione sul modello di business debba costituire il punto di
partenza per qualsiasi valutazione degli investimenti in ICT, anche se non può essere
condotta in modo esaustivo e formalmente corretto. Gli investimenti in ICT vanno
valutati dal punto di vista del loro contributo al modello di business ma vanno
individuate modalità semplici per applicare le analisi strategiche in realtà non
strutturate, come possono essere le piccole e medie imprese.
La dottrina e la prassi aziendale si stanno evolvendo verso un approccio sincretico, che
cerchi di utilizzare in modo pragmatico i diversi contributi e le differenti esperienze.
L’allineamento tra strategie di business e strategie ICT è risultato particolarmente
difficile, soprattutto se perseguito con un approccio rigidamente pianificatorio. Al
contrario, sulla base dell’analisi di alcuni casi di successo, alcuni autori sostengono che il
raggiungimento di vantaggi competitivi tramite lo sviluppo di politiche ICT sia stato
spesso più il risultato dell’improvvisazione che di una pianificazione formale: “ molti casi
di sistemi informativi di successo sotto il profilo strategico sembrano mostrare che il
caso piuttosto che un consapevole allineamento strategico sia all’origine ( ex-post) di
97
una efficace aderenza dei sistemi informativi alla strategia”.70 La ragione fondamentale
alla base dei frequenti insuccessi è il fatto che l’equilibrio tra strategia, organizzazione e
sistemi informativi viene spesso concepito e perseguito come un fatto statico, di rigida
relazione tra le diverse parti, senza considerare che si tratta di un fenomeno dinamico,
che si autoalimenta e nel quale i sistemi informativi svolgono una funzione autonoma e
fondamentale nell’indirizzare l’organizzazione e determinare la strategia.
Partendo da queste considerazioni, alcuni autori suggeriscono che “ l’allineamento
strategico debba essere un continuo processo che comporti continui aggiustamenti,
piuttosto che un fatto statico che riporti, dopo che si è verificato, l’organizzazione ad
uno situazione di equilibrio. Si tratta quindi di conciliare un approccio top down, basato
su una progettazione razionale, ad uno bottom up, che si alimenti con processi
emergenti dall’interrelazione di tutti i componenti del rapporto tra modello di business e
sistemi informativi”.71 Questi autori evidenziano tre livelli nei quali si esprime, quindi, il
rapporto tra modello di business e sistemi informativi:
-
livello strategico: è basato su un ciclo formale di pianificazione;
-
livello operativo: si focalizza sui rapporti tra sistemi informativi e i diversi
dipartimenti dell’azienda, che deve evolvere da una sostanziale separatezza
reciproca ad un forte coordinamento e ad una intensa comprensione reciproca. Si
tratta di migliorare la comunicazione ma soprattutto di definire un “ comune
piano di azioni” per condividere e conseguire obiettivi comuni;
-
livello individuale : gli uffici dedicati allo sviluppo e alla gestione dei sistemi
informativi sono spesso caratterizzati da una matrice professionale, che, insieme
con la complessità della tecnologia, rende difficile il colloquio con gli utenti.
Quest’ultimi subiscono le scelte effettuate in tema di sistemi informatici e quindi
spesso esprimono resistenze rispetto all’innovazione: occorre evolvere verso
forme di coinvolgimento degli utenti nella stessa fase di sviluppo dei nuovi
sistemi informativi secondo una logica di partnership.
70
Ciborra C.U. From Thinking to tinkering Strategic Information Systems: A European Perspective, ed. Wiley 1994
pag.70
71
Hind Benbya e Bill McKelvey Using coevolutionary and complexity theories to improve IS allignement: multi-level
approach in Journal of Information Technology n.21 2006
98
4. SELEZIONE DEl SOFTWARE E DEI
FORNITORI
4.1. Determinazione dei costi di un software
Prima di illustrare le metodologie di selezione dei software e dei fornitori, si ritiene
opportuno descrivere le modalità di determinazione dei costi di un software, sia nella
veste di pacchetto standard, e quindi già sviluppato, che di applicativo che viene
sviluppato sulle specifiche del cliente.
Le metodologie esposte in questo capitolo possono essere utilizzate anche per
l’acquisizione di sistemi hardware che di software operativi. Ci si riferisce,
prevalentemente, ai software gestionali, ossia a quelle applicazioni informatiche che
riguardano la gestione aziendale.
4.1.1.
Determinazione
dei
costi
di
un
pacchetto
standard
La determinazione dei costi di un pacchetto standard presenta diversi elementi di
complessità, riconducibili ai seguenti fattori:
-
la politica dei fornitori di trasferire la maggior parte dei costi dalle voci di spesa più
visibili e facilmente riconducibili a valori a forfait (costo dei diversi moduli del
software, costo delle licenze, costi di installazione, costi annui di manutenzione ) alle
voci di spesa, che sono meno determinabili in fase di acquisto e più facilmente
riconducibili a compensi sulla base delle giornate spese, quali assistenza,
formazione, consulenza in fase di implementazione. In generale, le società di
software tendono ad operare con una modalità, chiamata a tempo spesa, ossia, sulla
base delle risorse umane impegnate, valorizzate con una tariffa predefinita e del
rimborso dei costi delle eventuali altre risorse impiegate. Occorre quindi operare per
spostare il baricentro economico del servizio dalla modalità a tempo spesa a quelle:
99
- a forfait o a prezzo fisso: un importo complessivo predefinito stimato sulla base
delle risorse umane e tecnologiche che il fornitore ha valutato siano necessarie
per erogare il servizio richiesto;
- prezzo per output: sulla base di un prezzo unitario per “ unità di output”, per
esempio il software applicativo sviluppato, i dati registrati su supporto magnetico,
le chiamate di help desk;
-
la difficoltà di determinare i costi nascosti, che sono generalmente generati dalle ore
del personale dell’azienda cliente impegnate in fase di addestramento e in relazione
alle
attività
di
implementazione
del
software
(in
particolare
per
la
parametrizzazione), nonché le ore di produttività perse dal personale in seguito alla
necessità di acquisire nuovi metodi di lavoro;
-
gli impatti economici su altre voci di costo (i così detti costi indotti), in particolare
sull’hardware a causa dei requisiti tecnici richiesti dal nuovo software. A questo
riguardo è opportuno partire da una valutazione complessiva dell’hardware e dei
software di base a disposizione dell’azienda e soprattutto degli utenti, che potranno
essere coinvolti dal nuovo software gestionale. Un indicatore sintetico di congruità
tra nuovo software e l’adeguatezza dell’hardware e del software di base può essere
il rapporto tra i costi complessivi del nuovo software e il valore della piattaforma
disponibile: se il rapporto è molto alto è probabile che si debba intervenire anche su
una revisione della stessa piattaforma. Nello stesso modo è possibile stimare i costi
di manutenzione che sarà necessario sostenere lungo la vita complessiva del
software.
72
Al fine di rendere più agevole l’esposizione delle diverse voci che contribuiscono ai costi
di un pacchetto standard si fa riferimento al preventivo di un software di controllo di
gestione, tenendo conto che le diverse componenti del costo possono essere facilmente
estese ad altre tipologie di applicativi.
Costo del Data Base
72
A cura di C. Batini Sistemi informativi A Alessandrini, G. Lazzi, F. Minelle volume III Costi e Benefici, ed. Franco
Angeli 2001
100
Nel caso di un software che utilizzi un data base commerciale, i costi da considerare
riguardano i costi di licenza d’uso e il costo annuo di manutenzione, generalmente
rapportati alle postazioni servite. Queste due voci di costo vanno quindi considerate per
posto di lavoro e possono costituire un vincolo economico significativo all’utilizzo del
software da parte di numerosi utenti.
Nel caso di un software che si basi su un data base sviluppato ad hoc, generalmente
viene offerto un costo totale a forfait, che non lievita quindi in base al numero di utenti,
ma può presentare notevoli rischi di incremento in fase successiva all’installazione, in
quanto non sono spessi chiari i costi necessari per l’implementazione, l’adeguamento e
la manutenzione del software.
Costo del software applicativo
Il costo del software applicativo è normalmente articolato su due voci:
-
il costo di acquisto del modulo base, generalmente offerto a forfait , al quale è
tuttavia connesso un costo annuo di manutenzione;
-
i costi necessari per la personalizzazione e la parametrizzazione del software, che
sono generalmente a forfait sulla base di specifiche tecniche di dettaglio definite in
fase di preventivo. La difficoltà dell’azienda cliente di identificare con precisione
queste specifiche e di trasferirle in termini di clausole contrattuali genera un’area di
potenziale lievitazione dei costi in fase di implementazione del software.
Costo dell’assistenza in fase di implementazione del software
I costi relativi all’assistenza e alla formazione in fase di implementazione sono offerti a
forfait, con l’attenzione da parte del fornitore di limitare al massimo le giornate di
impegno; per un software di modeste dimensione è difficile che le attività di formazione
e quelle di assistenza superino le due giornate di presenza da parte del personale del
fornitore.
Costo di assistenza post-vendita
101
L’impegno del fornitore in fase post-vendita è offerto sulla base delle giornate richieste,
dichiarando un costo annuo a giornata. Si tratta di una delle principali aree di rischio per
l’azienda cliente in quanto i costi si possono incrementare in misura significativa rispetto
a quanto previsto e/o si rischia di non valorizzare a pieno le funzionalità del software
acquistato, nel caso in cui non si intenda sostenere i costi di assistenza post-vendita.
Costi del personale dell’azienda
In sede di valutazione di acquisto di un nuovo software è opportuno valutare con
attenzione le ore perse dal personale per la formazione e l’implementazione del nuovo
software. Va quindi formulato un preventivo, che dettagli il numero di addetti, le ore e il
costo orario (generalmente il costo del lavoro incrementato di una percentuale del 20%
per tener conto delle spese generali diviso per la presenza media del personale in
azienda, espressa in ore).
Costo dell’hardware e del software di base
Per determinare i costi indotti occorre chiarire in sede di incontri con il fornitore quali
sono i requisiti tecnici richiesti per l’hardware e i software di base necessari, a livello di
server e di singola postazione utente.
Nella tabella successiva viene riportata una sintesi
delle diverse voci di un pacchetto software standard.
Descrizione
Costi in fase di acquisto
Data base
Licenza
d’uso
per
(generalmente per lotti di 5)
Modulo base
applicativo
del
Costi successivi all’acquisto
postazione
Costo per postazione a forfait
(compenso fisso)
software
a forfait (compenso fisso)
Personalizzazione
parametrizzazione
e
a forfait con un massimo di giornate
Assistenza
in
implementazione
fase
di
a forfait con un massimo di giornate
(generalmente non più di due)
Formazione
in
implementazione
fase
di
a forfait con un massimo di giornate
(generalmente non più di due)
102
Assistenza post vendita
Personale dell’azienda
Requisiti hardware
Requisiti software base
4.1.2.
Ore giornate impegnate sulla
base di un costo giornata
ore del personale valorizzate sulla base
del costo orario
ore del personale valorizzate
sulla base del costo orario
Processori con ram dedicati e spazio
disco, sia del server che di ciascuna delle
postazioni client
Sistema operativo e dotazione di
programmi, sia del server che di ciascuna
delle postazioni client
Determinazione dei costi di sviluppo del software
Le linee di codice
Con la diffusione dei pacchetti applicativi standard il problema della determinazione
dei costi di sviluppo del software rappresenta fondamentalmente un tema tipico
delle Software House e riguarda marginalmente l'intero universo delle organizzazioni
utenti73.
E' opportuno , comunque, avere un metodo di stima dei costi di sviluppo ai fini di
determinare la convenienza o meno ad acquistare pacchetti standard piuttosto che
fabbricarne " in casa", nonché allo scopo di meglio monitorare e controllare il
fornitore.
La misura ancora più comunemente utilizzata in campo software è quella, sviluppata
all'inizio degli anni ’70, delle Linee di Codice ( in sigla LOC - Lines of Code ), definite
come l'insieme delle istruzioni codificate in un dato linguaggio di programmazione. Ci
si pone dal punto di vista dell'analista-programmatore, per il quale l'output principale
dell'attività di sviluppo è una lista di istruzioni rilasciate per ciascuno dei codici
73
La trattazione di questo argomento fa riferimento a Luigi Buglione Misurare il software ed. Franco Angeli 2003 e a
Tommaso Federici Il progetto di sistemi informative ed. Franco Angeli 2001
103
sorgente. Per determinare il costo di sviluppo di un software sarebbe quindi sufficiente
conteggiare fisicamente ogni linea scritta e moltiplicare il numero così ottenuto per il
tempo unitario per elaborare ciascuna linea di codice.
L'approccio basato sulle Linee di Codice è stato oggetto di numerose critiche. Tra le
altre si possono richiamare le seguenti : le Linee di Codice non misurano la dimensione
del software, ma solo la lunghezza in termini di istruzioni rilasciate e non sono
quindi significative per un'analisi dei tempi necessari allo sviluppo; diversi linguaggi
di programmazione possono ottenere la stessa funzionalità con un numero differente di
istruzioni.
Questi problemi sono stati affrontati da numerosi studi che sono stati finalizzati a
determinare lo sforzo generale per lo sviluppo di un software. Il COCOMO ( Cost
Costruction Model) di Barry Boehm Esso stima il numero di mesi-uomo necessario per
completare il progetto in funzione del numero di istruzioni di alto livello da rilasciare ed in
base a parametri di correzione, detti cost-driver, che tengono conto di alcune
caratteristiche intrinseche del progetto e dell’ambiente di riferimento.
La formula proposta da Boehm è la seguente:
PM = h ( KDSI) K
dove PM indica il numero di persone mese, KDSI le migliaia di istruzioni rilasciate, h e k
la complessità del progetto.
Al fine di aiutare il calcolo relativo alla complessità del progetto, alcuni autori hanno
proposto alcuni indicatori standard, individuati sulla base dell'esperienza.
Per esempio, la formula di Waltson e Felix è la seguente:
PM = 5,2 ( KDSI), elevando KDSI alla potenza di 0,91
La formula di Bailey e Basili si articola in modo differente:
PM = 3,4 +/- 7,2 ( KDSI) +/- 25%, elevando (KDSI) alla potenza di 1,17
Analisi dei Punti Funzionali
104
Per superare i problemi comportati dall'uso delle LOC nel calcolo della produttività e
stima dell'impegno di progetto è stata sviluppata una nuova tecnica, denominata
Fuction Point Analysis (in sigla FPA) e tesa a misurare il numero dei Punti
Funzionali, ossia le funzionalità espresse da un programma e rilevabili dal punto di
vista dell'utente finale.
A metà degli anni ’70 è stata introdotta una metodologia che soppesa la quantità di
software prodotto sulla base delle effettive funzionalità richieste e rilasciate al cliente,
superando quindi il punto di vista del tecnico, ossia dell'analista-programmatore. Viene
invece assunto il punto di vista dell’utente, in quanto si parte dalla funzione applicativa
visibile dall’utente e da un conteggio di tali funzioni, pesandole in relazione all’ampiezza
e alla complessità.
Il costo determinato tramite la valorizzazione delle Linee di Codice non viene letto in
assoluto ( come avveniva con il metodo LOC) ma viene ricondotto ai Punti Funzionali
Sviluppati, così da ottenere l'impegno in ore o giorni per funzionalità e pervenire
quindi ad una valutazione più corretta dal punto di vista delle esigenze dell'utente.
Il metodo è stato elaborato nel 1975 da un ricercatore dell’IBM, Allan J. Albrecht, che
lo ha poi rivisto nel 1985: esso è oggi costantemente aggiornato da un gruppo
internazionale di società che utilizzano questo metodo, denominato IFPUG (
International Fuction Point User Group). L'aggiornamento costante può essere
effettuato consultando i siti www.ifpug.org e per l'Italia www.gufpi.org.
Il procedimento si sviluppa nel seguente modo.
-
Vengono innanzitutto identificate le componenti funzionali relative all'applicazione
della quale determinare il costo, definite con
il termine UWFP (
Unajusted Unweighted Function Points).
-
Vengono quindi ponderate le singole componenti funzionali secondo il livello
di complessità (basso, medio, alto) così da ottenere gli UFP (Unadjusted
Function Points).
105
Nella pratica si fa riferimento al Fuction Point Counting Practices Manual (
arrivato alla release 4.1.1) redatto dall’IFPUG nel quale vengono indicate le
regole di conteggio.
-
Si passa quindi a determinare il VAF (Value Adjustment Factor) che consiste in un
fattore di aggiustamento, individuato in un range tra +/-35% e che è dato a sua
volta dalla somma di 14 fattori chiamati GSC (General Systems Characteristics).
Questi fattori, collocati in una scala da 0 a 5 secondo il loro grado di influenza
(DI, Degree of Influence). La formula di calcolo del VAF è quindi la seguente:
VAF= 0,65+0,01 * Somma (GSC*DI).
In conclusione viene quindi determinato il costo del software sulla base del numero dei
punti funzionali, opportunamente ponderati e corretti dal VAF.
FP = UFP* VAF
La metrica dei Punti Funzionali ha incontrato un notevole successo, soprattutto per la
valutazione di costi di software di grandi dimensioni. I principali problemi aperti
riguardano l’incompleta oggettività del conteggio, che prevede una fase finale di
correzione su una percentuale molto ampia ( anche il 35%) basata su giudizi espressi
dal misuratore. Inoltre in una fase iniziale di sviluppo del software risulta estremamente
difficile avere una visione complessiva delle funzioni da realizzare, del numero e della
struttura degli archivi, del rispettivo livello di complessità e delle caratteristiche
dell’ambiente, che influenzano in misura determinante il fattore di adattamento, e
quindi la percentuale del 35%).
4.2. Le modalità di selezione dei prodotti, dei servizi
e dei fornitori
4.2.1.
Il metodo: principi generali
La realizzazione di un progetto informatico fa leva sempre più spesso su pacchetti
software standard: è quindi fondamentale selezionare i prodotti esistenti sul mercato e
106
di conseguenza scegliere i fornitori che meglio possono supportare la crescita
dell'architettura informatica dell'azienda.
Alla scelta del prodotto, configurato in forma standard, occorre poi aggiungere una serie
di servizi, che riguardano sia l’integrazione di pezzi diversi della fornitura (dell’ hardware
del software) sino ai servizi di implementazione e di assistenza), che permettono di
rendere funzionante ed operativo il software, sia l’affiancamento in fase di avviamento,
dai servizi relativi all’implementazione che all’assistenza. In tal modo la focalizzazione
degli obblighi assunti dal fornitore si sposta dalla fornitura del singolo prodotto (il
software, l’hardware e così via) al raggiungimento di un risultato complessivo: il
software operante.
Si è quindi dinanzi ad un contratto di “ system integration” o più banalmente di servizi
informatici, che incorpora anche il software e talvolta l’hardware stesso. Questa
tipologia di contratto presenta alcune caratteristiche peculiari, rispetto, per esempio, alla
semplice fornitura di un software o di componenti dell’hardware:
• la natura delle forniture richiede un negoziato tra fornitore e cliente, superando
la logica del contratto standard, che predomina negli altri campi dell’informatica e
che riducono la trattativa ad una semplice scontistica;
• il concetto stesso di prestazione, e quindi di responsabilità. Il fornitore è
responsabile dell’intera fornitura e quindi deve garantirla in termini precisi e
specifici in relazione all’oggetto della fornitura stessa.
Il percorso logico-organizzativo dall’emergere dell’esigenza sino alla definizione degli
impegni reciproci tra cliente e fornitore assume, quindi, una notevole complessità e
richiede metodologie che supportino il cliente nei suoi rapporti, prima negoziali e poi
contrattuali, con il fornitore di servizi informatici. Il tema della " software selection " ha
assunto pertanto un'importanza crescente, che può essere confermata dal numero di
siti, generalmente statunitensi, che offrono metodologie di analisi e di valutazione dei
prodotti informatici, anche con un'ottica molto specialistica ( per esempio solo legata
alle applicazioni Erp ). Alcuni di questi metodi si focalizzano sul singolo prodotto,
considerato di per sé nelle sue peculiarità funzionali e prestazionali e nelle piattaforme
tecnologiche che le supportano, altri, più opportunamente, considerano anche fattori
107
associati all'impresa fornitrice nel suo complesso e alla natura dell'investimento
in ICT ( se , per esempio, si tratta di una tecnologia relativamente matura o se
esistono specifici rischi).
In generale l'approccio per la selezione del software deve articolarsi in tre
passaggi fondamentali:
-
definizione di un modello generale, che conduca all’individuazione delle esigenze
informative e porti a definire i requisiti funzionali e prestazionali: a conclusione di
questa fase vengono predisposte le specifiche per la redazione della richiesta di
offerta ed individuati i fattori di valutazione, sulla base dei quali selezionare i diversi
software e fornitori;
-
l'elaborazione delle richieste di offerta ( " request for proposal ", in sigla RFP), che
devono contenere le specifiche tecniche alle quali devono rispondere i fornitori che
intendono offrire il pacchetto informatico. A conclusione di questa fase verranno
predisposti criteri di comparazione per effettuare una valutazione omogenea tra le
differenti proposte dei fornitori;
-
la valutazione delle differenti soluzioni e dei diversi fornitori mediante un metodo di
valutazione.
Nel grafico successivo viene riportato in sintesi il percorso per effettuare la selezione del
software e dei fornitori
Direttive
della
Direzione
Esigenze
informative
Richiesta di
offerta
Specifiche di
selezione
4.2.2.
Selezione
Specifiche
per il
contratto
Criteri di
comparazione
Definizione delle esigenze informative
Il processo di scelta di un applicativo gestionale prende generalmente le mosse da un
progetto più ampio, che riguarda la riorganizzazione di un processo aziendale e/o il
miglioramento del flusso di informazioni necessarie alla gestione e alla direzione
dell’organizzazione. Si pensi all’acquisto di un software per la conduzione del magazzino,
108
esso è proceduto, spesso, da una scelta aziendale (rivolta, per esempio, ad ridurre il
capitale circolante, ad introdurre rapporti più efficienti ed efficaci con il fornitore), che
viene seguita da un’analisi e da una serie di proposte da parte di consulenti esterni o
figure dirigenziali interne. Alla base, quindi, della decisione di acquistare un applicativo
gestionale c’è sempre un progetto organizzativo, sia esso esplicito che implicito, che
conduce ai seguenti risultati.
Elaborazione di un modello generale di funzionamento
Questo documento descrive le finalità, i meccanismi, il modello dei dati, i risultati attesi, il
sistema di reporting, nonché i ruoli e le responsabilità coinvolte. Questo documento è
fondamentalmente organizzativo e quindi viene sviluppato in un linguaggio finalizzato alla
comprensione delle persone che operano nell’organizzazione, con competenze e ruoli
anche ben lontani da quelli informatici.
Questo documento è di utilità per l’esperto informatico solo ai fini di una comprensione
generale del contesto. Sapere, per esempio, che per conseguire una gestione just in time
dei flussi di merce dal fornitore al magazzino occorre migliorare la comunicazione tra il
fornitore e il cliente utilizzando modalità web, può essere un fatto interessante ma
identifica esigenze
informative
al
un
livello troppo generico per essere utili
all’individuazione di criteri di scelta di software.
Definizione dei requisiti funzionali e prestazionali
Occorre passare ad un livello di maggiore dettaglio e specificazione mediante la
predisposizione di un elenco dei requisiti funzionali e prestazionali che deve avere il
software.
Si tratta di uno passaggio difficile in quanto è necessario che l’esperto informatico lavori
con il massimo livello di coordinamento e di comunicazione con gli esperti che hanno
elaborato il modello generale di funzionamento. In questo relazione si scontrano
differenze culturali e lessicali che spesso creano fraintendimenti e portano ad una
definizione troppo vaga dei requisiti funzionali e prestazionali. Mentre l’esperto
109
organizzativo ragiona in “ linguaggio naturale” e con un livello di sintesi coerente con la
definizione di flussi organizzativi, l’esperto informatico deve lavorare in “ un linguaggio
macchina” ( di programmazione e di tecnologia) e con analisi estremamente profonde.
L’obiettivo dell’esperto informatico è di modellare le relazioni tra i dati e i processi
partendo da un’analisi dettagliata dei flussi di lavoro: individuare le attività elementari e
quindi le informazioni che le attività elaborano, pervenendo quindi ad identificare le
funzioni elaborative e i contenuti della base dati.
Il metodo più comunemente utilizzato è quello AD ( Analisi di Dettaglio), che specifica i
requisiti del Sistema Informativo mediante modellazioni grafiche delle attività, delle
strutture delle informazioni e delle funzioni di elaborazione. Schematicamente il metodo
AD è costituito da una serie di passi74:
• analisi del cambiamento, dove sono definiti gli obiettivi della revisione del processo,
che proviene dal documento che riporta il modello generale di funzionamento;
• analisi delle attività, dove, applicando una scomposizione delle attività secondo una
struttura ad albero ( tipo WBS, per la cui definizione si veda l’ultimo capitolo) e
rappresentandola graficamente : in un grafico chiamato A-Grafi sono rappresentate
per ciascuna attività sia gli oggetti fisici ( per esempio i materiali ordinati) che
l’insieme delle informazioni utilizzate nelle attività stesse ( per esempio ordine
verso il fornitore);
• analisi delle informazioni, dove l’insieme informativo viene scomposto secondo un
modello di tipo gerarchico, che per ciascun livello dell’albero individua i dati
identificativi dell’insieme informativo considerato e il gruppo di informazione nel
quale esso si divide ( chiamati “ nodi “).
Per esempio, l’ordine verso il fornitore avrà come dati identificativi il numero
dell’ordine e come gruppo di informazioni il materiale ordinato. Al livello successivo
il dato identificativo sarà dato dal codice materiale e il gruppo di informazioni dalla
quantità ordinata: secondo questa logica si procederà lungo la struttura dell’albero.
74
Giampio Bracchi, Gianmario Motta Progetto di Sistemi Informativi ed. Etaslibri 2000 pag. 155
110
Uno strumento grafico chiamato C-Grafi permette di modellare la scomposizione
degli insiemi informativi sino a pervenire ad identificare i dati elementari e quindi a
costruire il modello concettuale dei dati;
• analisi delle funzioni elaborative, dove sono individuate e specificate , mediante IGrafo, le funzioni di aggiornamento pervenendo quindi al modello concettuale dei
processi. Vengono specificati gli insiemi informativi in termini di input e di output e
gli attivatori di ogni funzione di elaborazione.
Riprendendo il nostro esempio, la funzione di aggiornamento è attivata
dall’ingresso del materiale e l’input temporaneo della funzione è costituito dalla
bolla di accompagnamento, la quale farà riferimento ad un ordine verso il fornitore,
che sarà già inserito nella banca dati degli ordini. A questo punto la funzione di
aggiornamento darà luogo a due output: andrà a caricare il magazzino in base al
codice materiale, dando luogo ad un report di situazione scorte, e andrà aggiornare
la banca dati degli ordini fornitore, dando luogo ad un report di stato delle
consegne;
•
verifica di integrazione di sistema, dove le informazioni ( C-Grafi) e le funzioni (
I-Grafi) sono incrociate al fine di individuare le anomalie e le incompletezze di
analisi.
Di seguito viene riportata una tipica struttura ad albero di un’analisi dei requisiti funzionali
Ordine Fornitori
Dati
Identificativi
Numero
Ordine
Materiale
Ordinato
Altri
Dati
Data
Emissione
Dati
Identificativi
Quantità
Ordinata
Codice
Materiale
111
Definizione dei fattori di valutazione
Si può passare a definire quali saranno i fattori di valutazione sulla base dei quali
analizzare i software in sede selezione. Questo passaggio è particolarmente importante
per due ordini di motivi:
•
definire le priorità che si intende conseguire con il software e i vincoli all’interno dei
quali devono essere effettuate le scelte. Per esempio, è necessario che la Direzione
Aziendale chiarisca se sia più importare acquistare un software al costo più basso
possibile rispetto alle funzionalità o ad altre problematiche legate al fornitore (
assistenza, qualificazione ecc.);
•
chiarire le regole di selezione che verranno applicate in fase di scelta degli
applicativi così da evitare di subire “ pressioni” da parte di interlocutori che tendono
a spingere per un software rispetto ad un altro. Individuare queste regole in fase di
selezione significa rischiare di entrare in un “ ricircolo negativo” tra fattori di
valutazione e applicativi da un lato e fornitori da selezionare dall’altro.
Dal punto di vista pratico, l’individuazione dei fattori di valutazione persegue il
procedimento tipico delle analisi multi criterio, già illustrato nel capitolo 3. Viene
predisposta una lista di fattori di valutazione e viene attribuito un peso percentuale a
ciascuno di essi su un totale pari a 100.
Documenti da rilasciare alla fine della fase
A conclusione di questa fase verrà predisposto un documento, definibile con il termine
Specifiche per Selezione, che dovrebbe contenere (è possibile analizzarne un esempio con
l’allegato 2 “ Documento di definizione delle specifiche funzionali”):
• le specifiche funzionali che saranno alla base della richiesta di offerta, comprensive
di un elenco dei requisiti funzionali e prestazionali che deve avere il software;
• i fattori di valutazione, con i relativi pesi percentuali, comprensivi di una breve nota
che ne motivi la scelta e l’importanza attribuita.
112
4.2.3.
Richieste di Offerta
La richiesta di offerta è costituito dalle specifiche, tecniche ed economiche, alle quali
devono rispondere le aziende fornitrici, se intendono partecipare alla selezione del
software. Il documento dovrebbe essere articolato in cinque parti (è possibile analizzarne
un esempio con l’allegato 2 “Documento di Disciplinare tecnico”):
a) i criteri di qualificazione dell'azienda fornitrice, finalizzati ad identificare l’abilità del
fornitore ad fornire il prodotto e ad assicurare le attività per la sua implementazione:
dati anagrafici, il fatturato, la struttura organizzativa e societaria, il bilancio
aziendale, le referenze e informazioni generali sulla storia e sulle attività
dell'azienda;
b) i criteri legati alle prestazioni, che si articolano a loro volta nelle seguenti voci:
funzioni che deve assolvere il prodotto, gestione degli utenti e dei relativi livelli di
sicurezza, gestione dei flussi di informazione, gestione in internet, caratteristiche ed
amministrazione del sistema;
c) i criteri legati alla tecnologia, che riguardano le caratteristiche del data base, le
tecnologie di memorizzazione, le possibilità di esportazione dei dati e la scalabilità
del sistema, ed infine, ma non di minore importanza, i requisiti hardware per
l’installazione del prodotto, sia come client che come server;
d) i criteri legati ai servizi offerti dal fornitore, quali l’assistenza annua sul posto, in fase
di implementazione che di collaudo, l’assistenza remota (on line), le modalità di
manutenzione, la formazione del personale utente;
e) i criteri economici, relativi al prezzo (costi di licenze per postazioni e/o costo forfait),
costo per giorno dell’assistenza e della formazione, canoni anni di manutenzione,
costo annuo di assistenza on line, tempi di consegna e tempi di installazione.
Insieme all’elaborazione delle richieste di offerta è opportuno spendere tempo e denaro
per ampliare la rosa dei potenziali fornitori mediante un’attività di osservatorio: occorre
evitare di ricadere in pochi fornitori, che possono anche portare avanti politiche di
113
accordi così da annullare nei fatti l’impegno profuso nella fase di analisi funzionale e di
redazione delle specifiche.
4.2.4.
Attività di Selezione dei fornitori e dei software
Una volta ricevute le risposte, ciascuna di esse va analizzata sulla base di una serie di
fattori di valutazione.
Il metodo da utilizzare può essere basato sui seguenti passi logici:
•
sviluppare una struttura gerarchica dei fattori di valutazione da attribuire
alle differenti soluzioni e ai diversi fornitori, articolata secondo una struttura ad
albero e raggruppate nelle cinque categorie sopra descritte;
•
identificare l’importanza relativa dei fattori di valutazione, attribuendo a ciascuno
di essi un peso percentuale sul totale (quest’ultimo uguale a 100);
•
dare un punteggio a ciascuno dei fattori considerati relativamente a ciascuno dei
fattori di valutazione (su una scala da 1 a 5).
La gerarchia dei fattori di valutazione si può rilevare talmente complessa ed articolata
da richiedere modelli matematici per pervenire ad un giudizio complessivo. In secondo
luogo esiste sempre il problema di dare un peso alle differenti caratteristiche ed un
punteggio ai diversi fornitori, anche se bisogna dire che l’approccio analitico aiuta ad
inquadrare le effettive peculiarità e capacità del fornitore.
Il procedimento illustrato presuppone professionalità elevate all’interno dell’azienda (o
da parte di consulenti) e disponibilità di tempo e di risorse che si giustificano solo per
progetti informatici di particolare rilevanza.
114
4.3. L’ approccio basato sulla check-list
4.3.1.
Il metodo: principi generali
Un approccio basato sulle check-list riprende alcune caratteristiche del metodo sopra
descritto ( in particolare la focalizzazione sulle questioni fondamentali) ma lo traduce in
una modalità di analisi più semplice e senza dubbio meno costosa.
Si tratta di crearsi una scaletta articolata di domande al quale il fornitore dovrebbe
tendenzialmente rispondere in modo negativo o affermativo, fornendo una spiegazione
il più possibile precisa e chiara.
Anche in questo caso è indispensabile una fase preliminare, nella quale si va a
scomporre il tema da affrontare in questioni elementari: si tratta di un processo logicoconcettuale, che dovrebbe evitare di porre domande troppo generiche.
4.3.2.
Check-list
basata
sull’analisi
dei
requisiti
funzionali e tecnici
Questo primo approccio traduce in forma di domanda per il fornitore i risultati
dell’analisi funzionale, così da pervenire a determinare i punteggi sulla base dei quali
valutare i diversi software e fornitori.
Si tratta, quindi, di un metodo particolarmente approfondito, che richiede una
conoscenza significativa delle tipologie di applicazione; deve essere quindi svolta da
esperti specialisti della specifica tipologia di software ( per esempio, controllo di
gestione piuttosto che prodotti per il marketing) e dei specifici settori di utilizzazione
degli applicativi informatici.
Nell’allegato 3, si riporta un esempio di check list, relativo ad un prodotto di business
intelligence, applicato al controllo di gestione. Si possono evidenziare le seguenti
caratteristiche:
115
a) le domande sono molto articolate e seguono fondamentalmente uno schema
logico preciso, articolato nei seguenti argomenti:
-
funzionalità, ossia verifica della corrispondenza delle funzioni del software
alle esigenze del business; rappresenta, ovviamente, la parte della checklist
maggiormente personalizzata alle peculiarità della tipologia di
applicativo e alle specificità dell’azienda cliente;
-
gestione profili ed esigenze di sicurezza, che approfondisce le modalità di
accesso degli utenti al sistema e i protocolli con i quali si protegge il
sistema da aggressioni e da interferenze esterne;
-
gestione del processo, che analizza i flussi informativi e autorizzativi nella
rilevazione ed elaborazione dei dati;
-
il portale, ossia le capacità del sistema di fornire soluzioni web;
-
caratteristiche ed amministrazione del sistema, che investiga sulle
modalità di gestione del sistema e sulle competenze necessarie per
governarlo;
-
la tecnologia, che analizza in particolare le caratteristiche del data base e
più in generale i requisiti tecnici dell’hardware e del software di base;
-
dettagli fornitore, che riguardano una serie di informazioni in merito
all’esperienza del fornitore e alla capacità del fornitore di far fronte alla
fornitura.
b) viene richiesto un giudizio sul livello di copertura (su una scala da 1 a 4) della
soluzione applicativa proposta rispetto alle domande poste nella check-list;
c) viene richiesto un giudizio sul livello di personalizzazione necessaria (sempre su
una scala da 1 a 4);
d) viene, infine, contemplata la possibilità di fornire un commento in modo
descrittivo.
4.3.3.
Check-list basata sui moduli applicativi.
Un altro approccio prevede l’articolazione per moduli applicativi al fine di identificare il
grado di copertura del software sull’intera gamma dell’applicativo oggetto di analisi.
116
Questo approccio si può rivelare particolarmente efficace quando si tratta di scegliere
tra diverse soluzioni, tra loro tendenzialmente “indifferenziate” (per esempio, come nel
caso di un programma di contabilità), ma dove la preoccupazione è soprattutto rivolta
ad individuare la capacità dell’applicativo di integrarsi e/o di coprire numerose aree
aziendali: la contabilità ma anche la produzione, per esempio.
Nell’allegato 3 viene riportato un esempio di check list, che riguarda la selezione di un
applicativo gestionale in una piccola azienda meccanica. Vengono messi a confronto i
diversi fornitori sui vari moduli richiesti dall’azienda: in corrispondenza di ciascuno dei
moduli viene dato un voto da 1 a 5 a ciascuno dei fornitori così da pervenire ad una
valutazione tecnica del software.
Mentre per la maggior parte dei moduli si fa riferimento alle funzionalità richieste, con la
voce “ impostazioni generali” vengono invece indagate le caratteristiche tecniche e
prestazionali del software.
Una volta determinata la valutazione tecnica, per ciascuno dei moduli ( o
raggruppamenti di moduli) verrà richiesto un preventivo di costo così da pervenire alla
confronto economico tra i diversi fornitori.
Infine, verrà analizzato il livello di servizio del fornitore:la professionalità, la conoscenza
del prodotto e la capacità di offrire assistenza post-vendita nelle sue diverse modalità:
con persona presso il cliente e in “ remoto” mediante via internet.
4.3.4.
Check list “ semplificata”
Un altro approccio è orientato invece a formulare una serie di domande essenziali, che
permettono comunque di fotografare il software e il fornitore con il minor dispendio di
energie e di impegno.
Nell’allegato 3 viene riportato un esempio tratto da un sito americano di “ software
evaluation “. La selezione riguarda un applicativo gestionale e come si può constatare:
117
-
le domande sono dirette, in alcuni casi banali ma non permettono al fornitore di
eluderle;
-
alcune questioni ( non collocate in ordine) riguardano le capacità complessive
dell’azienda ( domande 1, 3, 4, 9, 22) ;
-
il fornitore deve rispondere in modo affermativo o negativo e mediante una sintetica
spiegazione scritta.
-
4.4. I contratti di servizi informatici
4.4.1.
Principi generali
I contratti di servizi informatici
75
appartengono alla categoria più ampia dei contratti ad
oggetto informatico. A differenza di contratti che realizzano il trasferimento e la
creazione di opere protette dalla proprietà intellettuale ( cessione di un software,
sviluppo di un software su specifiche esigenze del committente), il contratto di servizi
informatici costituisce una forma “ mista”, con la quale si mette a disposizione del
cliente un software ( standard o realizzato ad hoc è comunque soggetto ai diritti di
proprietà intellettuale) ed una serie di componenti hardware e software, nonché di
servizi legati all’avviamento e la messa in operatività dell’applicativo. La giurisprudenza
ha chiarito la differenza tra fornitura di un software e fornitura di servizi informatici, in
quanto “ la fornitura da parte di una software house di un elaboratore e di programmi
applicativi sviluppati ad hoc deve essere qualificato come un contratto atipico unitario (
contratto misto) di fornitura di un sistema informatico che ha come oggetto un risultato.
Se il sistema informatico fornito risultasse inidoneo, il contratto si risolverebbe per
inadempimento della software house” .76
Questa precisazione è di particolare importanza, in quanto fa ricadere i contratti di
servizi informatici all’interno della forma contrattuale dell’appalto, distinguendolo
rispetto ad altre due tipologie di contratti:
75
Nello svolgimento di questo tema si fa riferimento principalmente a Raffaele Zallone “ Informatica e telematica:
nuovi contratti di servizi ed. Giuffré 2003
76
Tribunale di Torino 13 marzo 1993 in Massimo Farina “ I contratti di realizzazione” in AA.VV I contratti
dell’informatica ed. Experta Edizioni 2008
118
• il contratto di licenza d’uso, attraverso il quale un soggetto, chiamato licenziante,
realizza il trasferimento del godimento di un software a favore di un altro
soggetto, chiamato licenziatario, a fronte di un pagamento di un canone. Si tratta
di un contratto così detto atipico, in quanto non specificatamente regolamentato,
ma al quale vanno applicate le norme generali dei contratti e in modo particolare
quelle relative alla tutela del marchio (Decreto Legislativo n.480 del 1992) e gli
articoli 2569, 2970, 2971, 2072, 2973 e 2574 del codice civile, nonché l’articolo
1341 del codice civile relativamente alla clausole vessatorie. Il contratto di licenza
d’uso viene poi generalmente assimilato al contratto di locazione (e quindi si
applicano anche gli articoli 1578 e 1579 del codice civile), dal quale si differenzia
in quanto il licenziante trasferisce al licenziatario anche la proprietà del supporto
informatico, il disco, sul quale viene registrato il software concesso in licenza, ciò
non avviene nel caso del contratto di locazione;
• il contratto di somministrazione, regolamentato dall’articolo 1559 del codice
civile, attraverso il quale il soggetto, il somministrante, fornisce un servizio,
attraverso modalità stabilite dal contratto, in modo periodico e continuativo. La
conclusione del contratto non è dato dal raggiungimento di un risultato, ma dal
durata del contratto stesso.
Poiché nel concreto è difficile definire, nel caso dei servizi informatici, a quali
delle due tipologie contrattuali riferirsi, secondo la prevalente dottrina, “
ogniqualvolta la produzione di una determinata opera prevarrà sulla fornitura di
una cosa ben determinata nella realtà (già esistente), il rapporto giuridico che ne
scaturisce sarà quello del contratto di appalto”
77
, nell’ipotesi inversa si farà
riferimento al contratto di somministrazione. Rientrano nei contratti di
somministrazione eventuali contratti di outsourcing dei servizi informativi
dell’azienda.
Per gran parte della dottrina i contratti di servizi informatici sono riconducibili alla figura
dell’appalto, ed in particolare dell’appalto di servizi78. Si fa quindi riferimento all’articolo
1655 del Codice Civile, secondo cui esso è l’accordo “ col quale una parte assume, con
77
Simone Zerauscheck ed Elisabetta Magini Contratti di informatica pag. 145 ed. Ipsoa 2001
78 Giuseppe Bellazzi I Servizi informatici in AA.VV. I contratti dell’informatica ed. Experta Edizioni 2008
119
organizzazione dei mezzi necessari e con gestione a proprio rischio, il compimento di
un’opera o di un servizio verso un corrispettivo in denaro”. Dal punto di vista lessicale,
la società fornitrice, la Software House, assume il termine di appaltatore, mentre il
cliente quello di committente.
Nel caso dei servizi informatici, l’oggetto è costituito dal servizio di implementazione,
aggiornamento, manutenzione, assistenza e consulenza, e sono quindi applicabili i
seguenti articoli:
• variazioni in corso d’opera ( artt. 1659, 1660 e 1661 codice civile): che , in
assenza di regolamentazione contrattuale, hanno validità solo se il committente
ha acconsentito. Il secondo capoverso dell’articolo 1659 stabilisce che “
l’autorizzazione si deve provare per iscritto” : una prassi che andrebbe seguita
con particolare attenzione e che invece è spesso disattesa nei contratti di
fornitura informatica;
• revisione prezzi (art.1664 codice civile): relativo all’onerosità sopravvenuta del
prodotto ed anche alla revisione del prezzo precedentemente pattuito. In
particolare, il secondo capoverso stabilisce che “ se nel corso dell’opera si
manifestano difficoltà di esecuzione derivanti da cause non previste, che rendono
notevolmente più onerosa la prestazione dell’appaltatore, quest’ultimo ha diritto
ad un equo compenso”. Si conferma l’importanza di una attenta definizione delle
specifiche e della loro effettiva fattibilità da parte del committente per evitare che
una insufficiente identificazione degli obblighi dell’appaltatore conduca ad una
lievitazione dei prezzi;
• verifiche in corso d’opera (art.1662 codice civile): al committente è concesso il
potere di verifica per valutare in corso d’opera lo stato di avanzamento;
• collaudo (art. 1665 codice civile): al committente è concesso il diritto di
collaudare l’opera prima della sua consegna definitiva. Il terzo capoverso
stabilisce che “ se il committente riceve senza riserve la consegna dell’opera,
questa si considera accettata ancorché non si sia proceduto alla verifica”.
L’attività di collaudo non viene sempre svolta con la dovuta attenzione nel caso di
un
contratto
avente
come
oggetto l’informatica, in
quanto si
assiste
implicitamente ad un suo avviamento. D’altra parte è difficile da definire il
120
confine tra attività di avviamento e messa in esercizio, con il risultato che è poi
complesso contestare all’appaltatore eventuali disservizi;
• garanzie (artt. 1667 e 1668 codice civile): il fornitore (definito come appaltatore)
deve fornire garanzie sui vizi e assicurare gli eventuali rimedi. Si conferma
l’importanza del collaudo, in quanto “ la garanzia non è dovuta se il committente
ha accettato l’opera e le difformità e i vizi erano da lui riconosciuti o erano
riconoscibili” (articolo 1667);
• recesso (art.1671 codice civile). Secondo numerose sentenze, le cause di recesso
possono anche riguardare il venir meno del rapporto di fiducia tra committente
ed appaltatore, “ ove tale fiducia sia venuta meno per qualunque motivo”79. Si
tratta di una precisazione molto importante nel caso di un contratto avente per
oggetto l’informatica, in quanto il rapporto di partnership che si viene a creare tra
fornitore e cliente richiede in questo caso che quest’ultimo sia convinto delle
capacità del fornitore stesso e della sua correttezza nella gestione di rapporti che
si prolungheranno nel tempo.
La lettura degli articoli del codice civile e della giurisprudenza in merito suggeriscono
che “ nell’interazione tra appaltatore e committente, particolarmente frequente in un
servizio continuativo, occorrerà aver sempre presente l’autonomia contrattuale che
caratterizza l’attività dell’appaltatore stesso e ciò anche per evitare pericolose
commistioni di ruoli e confusioni di responsabilità.80
Un aspetto molto importante in questa interazione è costituito dal rispetto del Decreto
Legislativo n.626 del 1994 ( “ norme sulla sicurezza”), in quanto il personale della
Software House opera spesso “ all’interno dell’azienda e del ciclo produttivo “81 e quindi
rientra in quanto previsto dall’articolo 7 , che prescrive al committente:
• di cooperare all’attuazione di misure di protezione e di prevenzione dei rischi
sull’attività lavorativa oggetto di appalto;
• di coordinare gli interventi di protezione e di prevenzione dai rischi cui sono
sottoposti i lavoratori;
79
Giuseppe Bellazzi I Servizi informatici pag. 177 in AA.VV. I contratti dell’informatica ed. Experta Edizioni 2008
80
Giuseppe Bellazzi I Servizi informatici pag. 179 in AA.VV. I contratti dell’informatica ed. Experta Edizioni 2008
Questo riferimento è stato introdotto dalla legge 27 dicembre 2006, n.296 (legge finanziaria per il 2007).
81
121
• di promuovere la cooperazione e il coordinamento.
A questo riguardo una circolare del Ministero del Lavoro ha chiarito come questa
responsabilità faccia capo esclusivamente al committente,“82 cui soltanto incombe
l’obbligo di impulso” alla cooperazione e al coordinamento.
Un altro problema riguarda la riservatezza delle informazioni e la tutela dei dati. Per la
peculiarità del lavoro, il fornitore di servizi informatici si troverà frequentemente ad
avere accesso a dati del committente, così come l’appaltatore si troverà a sua volta a
rendere disponibili al committente informazioni riservate, come studi, progetti e know
how in genere. E’ quindi importante per ciascuna delle parti mantenere, anche con
espressi accordi contrattuali, la riservatezza delle informazioni, delle tecniche e delle
metodologie.
Qualora nel contratto non vi siano specifiche clausole contrattuali, che obbligano alla
riservatezza, la normativa e la giurisprudenza non sono tali da evitare controversie di
difficile risoluzione. La normativa fa chiaramente riferimento ad informazioni segrete,
nel senso che “ non siano nel loro insieme, o nella precisa configurazione e
combinazione dei loro elementi, generalmente note o facilmente accessibili agli esperti
ed agli operatori del settore” e soprattutto “ abbiano valore economico in quanto
segrete”. Inoltre è necessario che siano sottoposte a misure “ adeguate a mantenerle
segrete”.83
4.4.2.
Oggetto del Contratto
Il primo elemento da definire con grande cura è l’oggetto del contratto, che non può
essere lasciato in forma vaga e ambigua, in quanto esiste il rischio di ricevere una
contro prestazione diversa da quella che mi sarei aspettato.
82
Circolare 12 gennaio 2001 n.8 del Ministero del Lavoro
83
Articoli 98 e 99 del Decreto Legislativo 10 febbraio 2005 ( codice della proprietà industriale). Si veda
anche l’articolo 623 del codice penale che parla di rilevazione di “ segreti industriali”.
122
E’ quindi necessario:
• specificare con il massimo dettaglio i servizi oggetto del contratto, obiettivo che si
ottiene con una loro sommaria descrizione e con una illustrazione, la più
minuziosa possibile, delle singole attività e prestazioni;
• definire le obbligazioni delle parti, ossia enumerare ed elencare le prestazioni che
una parte deve fornire all’altra e che condizionamento il corretto svolgimento del
contratto. Poiché i fornitori tendono a dettagliare in modo minuzioso gli obblighi
del committente, è opportuno che quest’ultimo identifichi in modo altrettanto
minuzioso gli obblighi del fornitore. In questo processo è, tuttavia, opportuno che
si mantenga un equilibrio complessivo tra le rispettive obbligazioni, che devono
rispecchiare i rispettivi ruoli ( cliente e fornitore) senza snaturare le reciproche
obbligazioni.
4.4.3.
Livelli del servizio
Il secondo elemento del contratto riguarda la valorizzazione precisa della prestazione sia
in termini di risultato che in termini economici, ossia l’individuazione di livelli di servizio.
Spesso, infatti, risulta particolarmente difficile descrivere puntualmente l’oggetto e le
modalità di esecuzione di un contratto di servizi informatici. Per meglio misurare la
prestazione, questa viene scomposta in risultati misurabili da indicatori fisici. Per
esempio, un contratto di manutenzione di un software può essere misurato dal numero
di interventi, dai tempi di chiamata alle richieste, dal valore dei guasti e così via. Le
metriche di sviluppo dei software (come le linee di codice e i punti funzionali) possono
aiutare ad individuare livelli di servizio nell’area della programmazione e della
personalizzazione, così come l’individuazione precisa del numero di parametri da
attivare e i relativi tempi unitari possono supportare la determinazione di livelli di
servizio nell’area della parametrizzazione.
Le parti potranno attribuire conseguenze rilevanti al raggiungimento o meno dei livelli di
servizio, ad esempio potranno essere previsti incentivi economici o disincentivi o può
essere previsto lo scattare di clausole risolutive espresse.
123
La definizione di livelli di servizio può essere senza dubbio efficace, ma occorre tener
conto di alcuni aspetti:
• evitare di trasformare quello che dovrebbe essere un obiettivo unitario e
complessivo in una miriade di attività con il rischio che si conseguono tutti i livelli
di servizio ma non si raggiunge il risultato complessivo. E’ necessario aver ben
presente le priorità, gli obiettivi strategici e le criticità così da individuare
misuratori che rappresentino ciò che è veramente importante per il cliente;
• evitare di formulare livelli di servizio che siano riferiti esclusivamente ad eventi
tecnici, ma occorre includere eventi operativi, che spesso riflettono meglio i
fattori critici del cliente.
4.4.4.
Durata del contratto : recesso e risoluzione
Il terzo elemento del contratto riguarda la durata del contratto, che può essere anche
abbastanza lunga e quindi deve contemplare anche la possibilità del committente di
recedere dal contratto, in quanto possono cambiare i presupposti economici e
tecnologici che hanno portato all’originaria stipula del contratto.
Occorre tener presente i seguenti aspetti:
• prevedere l’articolazione del contratto in più fasi, almeno quella di avviamento del
servizio e quella a regime, che comporta problematiche differenti in termini di
gestione, manutenzione ed assistenza. Ciascuna delle fasi deve contemplare il
raggiungimento di livelli di servizio, che se non conseguiti possono condurre al
recesso dal contratto da parte del cliente;
• prevedere specifiche clausole contrattuale di recesso, in quanto fare riferimento
al solo articolo 1671 del codice civile può risultare oneroso per il committente,
perché questo articolo prevede di indennizzare l’appaltatore delle spese
sostenute e soprattutto del mancato guadagno.
Per quanto riguarda la risoluzione del contratto, prevista dagli articoli 1453-1462 del
codice civile, è indispensabile che sia prevista una clausola di risoluzione espressa per
inadempimento, in quanto, in mancanza, la risoluzione stessa non potrebbe essere data
se non in caso di inadempimento grave (articolo 1455 del codice civile), di difficile
individuazione e sostenibilità in caso di controversia. L’articolo 1456 del codice civile
124
prevede, invece, che “ i contraenti possono convenire espressamente che il contratto si
risolva nel caso che una determinata obbligazione non sia adempiuta con le modalità
stabilite”, lasciando quindi ampio margine per individuare e circoscrivere le
inadempienze.
E’ fondamentale, poi, che vi sia una clausola specifica che riguardi il passaggio di
consegne nel caso di recesso e di risoluzione. L’originario fornitore dovrà mettere a
disposizione tutta la documentazione in suo possesso, fornire supporto e formazione
professionale per consentire l’esercizio dell’applicativo, e garantire, anche dopo la presa
in carico da parte del nuovo fornitore, una certa disponibilità del personale
precedentemente impegnato.
4.4.5.
I corrispettivi del servizio
Il quarto elemento del contratto è il prezzo da corrispondere al fornitore. E’ evidente,
innanzitutto, come la struttura dei corrispettivi deve essere articolata in funzione dei
livelli di servizio, ma deve tener conto dell’esigenza di conseguire un risultato unitario.
Gli aspetti da tener presente sono i seguenti:
• definire il più possibile un “ corrispettivo chiuso” che significa:
•
privilegiare una valorizzazione “ a forfait” dei livelli di servizio a fronte di una
tendenza del fornitore a privilegiare la remunerazione “ a tempo spesa”;
•
considerare l’intero spettro dell’oggetto del contratto e delle diverse fasi
contrattuali, prevedendo la possibilità del cliente di esercitare eventuali
opzioni. Per esempio, si riconosce il corrispettivo per la sola fase di
avviamento, ma si chiede al fornitore un “ prezzo vincolante” per le fasi
ulteriori, lasciandosi la facoltà di estendere o meno il contratto allo stesso
fornitore;
• evitare di creare incentivi economici su obiettivi difficilmente individuabili in modo
oggettivo. Esiste, in tal modo, il rischio di non mettere “ un tetto” alla lievitazione
del corrispettivo, che può derivare dal conseguimento di obiettivi di fatto non
impegnativi per il fornitore, Quest’ultimo, infatti, essendo uno specialista, ha una
migliore conoscenza degli elementi della fornitura;
125
• prevedere un meccanismo di controllo e verifica del servizio reso, tanto più
necessario quanto si prevede una pluralità di prestazioni e non una tariffa unica e
omnicomprensiva;
• prevedere un meccanismo per bloccare eventuali fatture in contestazione, per
evitare che scadano, diventando forme di pagamento di interessi, nonché per
risolvere eventuali contestazioni.
4.4.6.
La tutela della proprietà intellettuale
Il quinto elemento del contratto riguarda la tutela della proprietà intellettuale. Si tratta
di un problema di notevole complessità giuridica e contrattuale, in quanto è difficile da
definire quali voci includere all’interno della proprietà intellettuale. Generalmente si
allude ad una categoria complessa di beni, materiali, ma per lo più immateriali, che
comprende brevetti, marchi, materiale soggetto a diritto d’autore e relativi diritti di
sfruttamento economico, materiale riservato e metodologie utilizzate. Inoltre, esiste il
problema che la legislazione prevalente fa riferimento ad informazioni “ segrete” e
quindi limita di fatto l’area di protezione dei risultati dell’attività intellettuale.
Proprio per la vaghezza della normativa, è indispensabile che vi siano clausole
contrattuali specifiche, che possono riguardare le seguenti tipologie:
• gli elementi e i componenti standard, disponibili sul mercato e che compongono il
cuore tecnologico di un applicativo, sono soggetti alla tutela della proprietà
intellettuale del fornitore. In questo caso il fornitore mantiene la proprietà e il
cliente potrà utilizzare il prodotto in un rapporto di licenza, a fronte di un
corrispettivo economico. Un possibile vantaggio di questa soluzione per il cliente
è di pagare un prezzo inferiore rispetto a quello che dovrebbe sostenere per
l’acquisto del prodotto, comprensivo della proprietà intellettuale;
• elementi, sempre di proprietà di un fornitore, che però richiedono una certa dose
di personalizzazione. Se le personalizzazioni hanno un valore economico e
possono riguardare più aziende dello stesso settore ( si adotta, in questo caso, il
termine verticalizzazione). In questo caso si può aprire uno scontro tra fornitore
e cliente. Quest’ultimo potrebbe richiedere la proprietà della verticalizzazione o,
almeno, di pretendere che il personale del fornitore che ha verticalizzato la
126
soluzione informatica non venga utilizzato presso altri clienti, per evitare di
avvantaggiare dei concorrenti. In questa fattispecie di scontro negoziale, di
solito, il punto di attrito tra fornitore e cliente si sposta sulla durata del periodo
inibitorio. Una situazione intermedia è quella che prevede la proprietà congiunta
dei risultati dello sviluppo: questa soluzione può risolvere momentaneamente lo
scontro negoziale ma lo sposta nel tempo, quando si affronteranno le situazioni
specifiche ed emergerà la differente prospettiva tra fornitore (interessato allo
sviluppo commerciale) e il cliente (attento a non favorire i concorrenti);
• un sistema destinato a gestire processi particolari e specialistici. In questo caso è
il cliente a restare proprietario della soluzione e a concedere una licenza d’uso al
fornitore. Resta non chiaro il confine tra il prodotto, anche verticalizzato, di
proprietà del fornitore e l’applicazione specifica di proprietà del cliente.
4.4.7.
Le clausole di riservatezza
Il sesto elemento del contratto riguarda la riservatezza dei dati. Ai sensi degli articoli 1 e
20 della legge 675 del 1996 ( “ legge sulla privacy”), la messa a disposizione dei dati ad
un terzo viene definita come comunicazione dei dati e richiede il consenso
dell’interessato, ossia del cliente. Dovrebbe essere, quindi, nominato un responsabile
del trattamento, ossia nella figura giuridica del fornitore o in un suo dipendente.
Le clausole di riservatezza sono ormai uno standard, ma sono comunque necessari
alcuni accorgimenti:
• i dati personali devono esplicitamente qualificati come dati riservati, ai sensi della
disciplina prevista dal contratto. In questo modo il cliente, in caso di
inadempimenti del fornitore, avrà una specifica azione contrattuale nei suoi
confronti;
• prevedere il divieto di fare copie e di trasmettere a terzi i dati, se non senza
approvazione o richiesta del cliente o se previsto nel normale flusso dei dati
stessi.
127
4.4.8.
Consegna, collaudo e accettazione
Il settimo elemento del contratto riguarda il problema di disciplinare la consegna del
risultato del contratto. I temi da affrontare con clausole contrattuali specifiche sono i
seguenti:
• definizione di rilascio, ossia quando riteniamo che sia avvenuta la messa a
disposizione da parte del fornitore della soluzione e/o delle modifiche della
soluzione, nonché dei livelli di servizio previsti;
• i criteri di test di accettazione, in quanto il superamento del collaudo dipenderà
da come sono stati definiti questi criteri. Il problema è che spesso il cliente
risente di un divario di conoscenza tecnologica e quindi tende a subire le
proposte del fornitore. Occorre evitare che si faccia ricorso a “ specifiche tecnicofunzionali ufficialmente pubblicate” , che spesso sono estremamente generiche
rispetto alla specifica soluzione informatica;
• definire che cosa succede se il test non viene superato, per esempio, va ripetuto
o scattano subito delle penali ?
128
5. GESTIONE DEI PROGETTI INFORMATICI
5.1. Le finalità del project management
5.1.1.
Definizione di progetto
Il progetto può essere definito come “ un’attività non ripetitiva, finalizzata al
raggiungimento di un obiettivo in un certo periodo di tempo, svolta utilizzando uno
sforzo congiunto di un pool di risorse, all’interno di un budget di risorse”84. La
realizzazione e l’introduzione di un nuovo software costituiscono a tutti gli effetti un
progetto, in quanto occorre operare in tempi determinati, utilizzando competenze
diverse (gli informatici, gli esperti del processo aziendale oggetto di informatizzazione,
gli utenti che dovranno utilizzarlo) e all’interno di un preventivo di costi che occorre
rispettare.
Lo scopo primario delle metodologie di Project Management and Control ( in sigla PM)
è di realizzare uno sistema integrato di pianificazione, analisi e controllo di uno o più
progetti, che ne garantisca il completamento entro la data prevista ed i costi
preventivati e ne assicuri nel medesimo tempo la qualità del prodotto in funzione delle
risorse necessarie e disponibili.
Da questa definizione si possono trarre le caratteristiche fondamentali del PM:
-
lo scopo : i sistemi di PM non sono rivolti alla gestione operativa del “ quotidiano”
ma sono orientati a conseguire un obiettivo entro un determinato periodo di tempo e
all’interno di risorse limitate: la finalizzazione specifica costituisce una delle
caratteristiche fondamentali del progetto;
-
i tempi: la temporaneità costituisce un’altra caratteristica fondamentale di un
progetto, sia nel senso che è definibile un momento di inizio ed uno di fine, sia
perché occorre utilizzare persone e mezzi tecnici per un periodo di tempo limitato.
84
Autori vari, Organizzare e Gestire per progetti ed. Etas 2004 pag. 6
129
Ciò significa che alcune persone dovranno essere distratte dal loro lavoro quotidiano,
al quale dovranno rientrare a conclusione del progetto, o dovranno dedicare al
progetto una quota parte del loro tempo, sovrapponendo le attività di progetto a
quelle di routine;
-
le risorse : la limitatezza delle risorse, finanziarie, tecniche ed umane, costringe a
ricercare costantemente il corretto equilibrio tra efficacia ( raggiungimento dei
risultati qualitativamente elevati in tempi ristretti) e efficienza ( ottimizzazione
nell’uso delle risorse) ; si tratta poi di attivare una rete temporanea di competenze e
di professionalità, caratterizzate spesso da una elevata interdisciplinarietà ma anche
da competenze funzionali e matrici professionali e culturali molto differenziate;
-
i costi : la valorizzazione monetaria delle risorse impiegate focalizza l’attenzione ad
utilizzare le risorse a minor costo ( anche se sarebbe più opportuno sotto il profilo
dei tempi e della qualità ricorrere a risorse più “ pregiate” );
-
i requisiti tecnici: pur all’interno dei vincoli imposti dai tempi, dall’efficiente uso
delle risorse e del contenimento dei costi, occorre comunque rispondere alle
aspettative tecniche così da conseguire le prestazioni e le funzionalità attese.
130
SCOPO DEL PROJECT MANAGEMENT
Tempi
Tempi (t)
(t)
Costi
Costi (c)
(c)
SCOPO
SCOPO
Risorse
Risorse
Requisiti
Requisiti tecnici
tecnici (r)
(r)
7
5.1.2.
Peculiarità di un progetto informatico
Dal punto di vista delle finalità, la caratteristica fondamentale di un progetto
informatico, rispetto ad altre tipologie di progetto ( per esempio la realizzazione di un
impianto industriale per conto di un committente), consiste nel fatto che nella maggior
parte dei casi si tratta di un progetto interno all’azienda ( nel quale l’utente aziendale
dovrebbe svolgere le funzioni di committente), che deve essere realizzato nell’ambito di
un ambiente di lavoro non abituato a lavorare per progetti ( ossia finalizzando le attività
ad uno specifico obiettivo in un arco di tempo determinato).
Si pensi, per esempio, all’implementazione di un applicativo gestionale per conto della
Direzione Amministrativa. Quest’ultima continuerà a lavorare nelle proprie attività
quotidiane (che assorbono energie ed attenzione), gli stessi Sistemi Informativi
Aziendali saranno sempre impegnati in altre attività (assistenza agli utenti, interventi di
emergenza, elaborazioni ecc.), la Direzione Aziendale sarà a sua volta impegnata su
molti fronti e sarà la stessa Direzione Aziendale a distrarre le risorse, che dovrebbero
lavorare alla realizzazione del progetto, su altre attività. Il risultato di questa situazione
si tradurrà in un costante slittamento dei tempi e di una dispersione delle risorse, che
sarà una delle cause della lievitazione dei costi.
131
Un'altra caratteristica peculiare di un progetto informatico è costituita dall’instabilità
dell’oggetto ( ciò che è stato definito come lo “ scopo”), non tanto per incertezze legate
alla tecnologia (che nella maggior parte dei casi si può considerare consolidata) quanto
per la difficoltà a definire, una volta per sempre, le funzionalità attese rispetto al
programma. Il progetto informatico è spesso caratterizzato da continue varianti rispetto
allo scopo originario, che hanno origine nel circolo “ vizioso” che si crea tra funzionalità
da un lato ed esigenze dell’utente dall’altro lato: esigenze dell’utente che risultano
fortemente dinamiche e turbolente per tre ordini di motivi:
-
insufficiente comprensione tra quanto è richiesto dall’utente e quanto può offrire
la tecnologia, e questo aspetto rimanda al tema della valutazione dell’architettura
informatica e a quello della selezione del software;
-
forte cambiamento organizzativo innescato dall’introduzione della tecnologia
informatica, che costituisce quindi un aspetto congenito ai progetti nei sistemi
informativi;
-
difficoltà di comunicazione e di partecipazione tra esperti informatici ed utenti,
che costituisce invece un aspetto sul quale si può operare in fase di gestione del
progetto.
L’insufficiente consapevolezza dei vincoli del progetto (risorse di progetto “ non a tempo
pieno”, instabilità dello scopo) conduce ad una costante richiesta di revisione dei
requisiti tecnici (nuove funzionalità, ulteriori personalizzazioni ecc.), che si traduce in
continue varianti di progetto (spesso non formalizzate in una specifica procedura
aziendale) e quindi in un ulteriore fattore di slittamento dei tempi e di lievitazione dei
costi.
Stretti tra la dispersione dell’impegno da un lato e le nuove richieste dall’altro, le
persone responsabili della realizzazione del progetto si trovano in crescente difficoltà
anche perché si diffonde in azienda una sorta di delusione e di frustrazione rispetto ai
contenuti del progetto. L’ unico soggetto che viene favorito da questa situazione sarà il
fornitore di software, che può richiedere continue varianti al contratto, giustificate dallo
slittamento dei tempi e dalle nuove richieste tecniche.
132
La gestione di un progetto informatico presenta, quindi, alcune peculiarità rilevanti
rispetto a strutture organizzative stabili, finalizzate a svolgere attività quotidiane e
ripetitive.
I.
occorre definire e gestire una struttura temporanea, che è creata all’inizio del
progetto e viene sciolta al suo termine: le persone sono spesso impegnate nelle
attività del progetto in modo parziale ( continuando a svolgere le proprie mansioni
quotidiane all’interno dell’azienda) e comunque sono consapevoli che i ruoli e le
responsabilità assunti all’interno di un progetto si esauriranno alla sua conclusione.
Emergono tutta una serie di problemi, da quelli meramente contabili ( evitare che
vengano attribuiti al progetto costi di attività che sono di fatto di routine e non fanno
quindi parte del progetto) all’esigenza di fidelizzare le persone alle finalità del
progetto, distogliendo tempi ed energie alle mansioni tradizionali;
II.
occorre gestire persone con professionalità, esperienze e ruoli aziendali spesso molto
differenziati e talvolta divergenti: questa problematica è poi accentuata dal fatto che
il successo del progetto dipende in misura crescente dal ruolo svolto dai fornitori,
non solo quelli di hardware e di applicazioni, ma anche dalle aziende che erogano
servizi di consulenza per l’implementazione e l’istallazione.
Ci si riferisce alle società di consulenza e di integrazione di sistemi, spesso
rappresentate da grandi multinazionali in grado di svolgere una funzione da
protagonista all’interno di progetti informatici e in possesso di esperienze,
conoscenze e, di conseguenza, potere contrattuale di gran lunga superiori a quelli
dell’azienda cliente;
III.
occorre interagire frequentemente con le strutture permanenti dell’Azienda, che non
sono coinvolte nelle attività del progetto e sono destinatari dei suoi risultati.
Una peculiarità di un progetto informatico, rispetto ad altre tipologie di progetto, è la
presenza di figure chiave per la sua buona riuscita, che sono coinvolte solo
marginalmente o limitatamente ad alcune fasi.
L’ Utente Operativo è una persona che opera sul sistema e lo utilizza per svolgere
grande parte del lavoro: per esempio, nel caso di un sistema di contabilità è il
responsabile di un reparto che elabora i report prodotti dal sistema. Questa figura
partecipa ai corsi di addestramento all’uso del sistema, ma durante il progetto
raramente ha un ruolo attivo.
133
L’Utente Gestore è una persona che definisce, mantiene e modifica le funzioni del
sistema in prima persona o tramite gli esperti informatici: per esempio, sempre nel
caso di un sistema contabile, sono gli specialisti che definiscono il piano dei conti, il
formato dei report, le procedure di controllo e di verifica dei dati. Sono la
professionalità chiave per l’impostazione del sistema.
Poiché gli utenti operativi e quelli gestori non partecipano in modo pesante alle
attività del progetto, uno dei problemi fondamentali è gestire efficacemente le
comunicazioni verso questa comunità di utenti che, nel caso di quelli operativi, può
essere numerosa e geograficamente distribuita, mentre per quelli gestori si possono
creare situazioni di conflittualità legate alla diversità di linguaggio ( quelli gestori
frequentemente utilizzano modalità di comunicazione “ naturali” e non informatiche);
IV.
occorre assicurarsi una forte determinazione da parte del Vertice Aziendale nei
riguardi delle finalità del progetto.
L’esperienza ha dimostrato come la buona riuscita di un progetto dipende dai diversi
attori coinvolti ma è influenzata in misura significativa dal coinvolgimento dello
stesso Vertice Aziendale, sia nella fase di comunicazione e di lancio del progetto ( al
fine di chiarirne l’importanza per tutta l’azienda e per lo sviluppo aziendale ed
individuale) che in tutti i momenti nei quali il progetto potrà incontrare difficoltà e
resistenze nel corso della sua realizzazione.
Rispetto ad altre tipologie di progetto, un progetto informatico, quindi, presenta alcuni
elementi specifici di complessità:
-
la definizione dell’oggetto ( “ lo scopo “) e dei vincoli all’interno dei quali occorre
operare, nonché delle modalità di aggiornamento dello scopo stesso. L’obiettivo di
un progetto informatico non è sempre chiaro, esplicito e condiviso. Per esempio, è
limitato all’implementazione del software o si intende innescare un cambiamento
organizzativo ? Qual è il momento nel quale riteniamo che il software sia stato
testato e consolidato ? quando verrà installato ? quando verrà realizzata la
formazione del personale o infine quando sono state risolte tutte le anomalie emerse
durante le prime fasi di utilizzazione del software ?
A questi problemi si tende a dare una risposta mediante una corretta analisi delle
attività nelle quali si articola il progetto e nella loro formalizzazione in un documento,
chiamato Preventivo o Piano di Progetto;
134
-
la definizione dei ruoli dei diversi attori ( “ le risorse”), che devono operare, con
competenze e funzioni diverse, nella realizzazione delle attività del progetto. Si tratta
di definire “ chi fa che cosa” e quali sono le forme più efficaci di coordinamento e
controllo del progetto.
A questi problemi si tende a dare una soluzione mediante una efficace
organizzazione del progetto, che viene formalizzata nell’organigramma, chiamato “
Struttura di Progetto”;
-
la gestione del cambiamento innescato dall’introduzione di un nuovo software, che
consiste generalmente in mutamenti rilevanti nelle modalità di lavoro e nelle
relazioni tra le persone che compongono l’organizzazione.
A questi problemi si tende a dare una soluzione mediante l’utilizzo di tecniche che
favoriscano l’apprendimento e la condivisione da parte degli utenti delle nuove
funzionalità introdotte dalla tecnologia,che si sintetizzano in modalità orientate
all’adeguamento delle professionalità, e si sintetizza con il termine “ Gestione del
Cambiamento “.
L’approccio di PM ha senza dubbio il pregio di strutturare la pianificazione e il controllo
dei progetti informatici secondo regole e modalità preordinate e consolidate. Si possono,
tuttavia, identificare due possibili criticità.
Innanzitutto, i sistemi di PM sono spesso caratterizzati da un astratto formalismo, che
sposta l’attenzione dalla gestione delle attività primarie, quelle nelle quali si
determinano gli effettivi risultati, a quelle legate alla pianificazione e controllo. Come
dire, con una battuta, che mi accorgo che il progetto sta andando male ma non riesco
ad intervenire sulle reali criticità, in quanto non possiedo di fatto le capacità e la
tempestività per risolvere i problemi.
In secondo luogo, esso può rilevarsi troppo burocratico e pesante per le aziende di
piccola e media dimensione, anche se occorre dire come un minimo di formalizzazione
sia spesso utile ed opportuno per gestire in modo corretto le attività del progetto.
135
Le tecniche di PM devono a contribuire a “ dare ordine “ ad un approccio, spesso troppo
approssimativo, alla gestione dei progetti informatici: esso non deve sostituire con
comportamenti formalistici l’attenzione alla realizzazione delle attività primarie e
l’adozione di interventi adattivi e rivolti alla soluzione dei problemi.
5.2. ll Preventivo di Progetto
Il fondamentale punto di partenza del PM è costituito dalla previsione iniziale a vita
intera del progetto. A differenza del Budget Aziendale, che generalmente ha una
proiezione annuale, che si identifica con l’esercizio di Bilancio, il Preventivo di
Progetto
ha come orizzonte temporale il periodo di durata del progetto, che può
andare ben oltre all’anno di budget.
Il Preventivo di Progetto ( o Piano di Progetto) deve definire in modo chiaro ed univoco
lo scopo del progetto, declinando di conseguenza le attività da svolgere e l’impegno
delle risorse coinvolte.
Il Preventivo di Progetto deve essere articolato nei seguenti capitoli:
•
il contesto , il quale illustra i legami tra le attività del progetto e gli obiettivi
strategici, individuando ed illustrando gli scostamenti tra l’architettura informatica
di riferimento e quella che si viene profilando in fase di impostazione e durante
l’avanzamento del progetto;
•
le finalità, che definiscono in modo sintetico e dettagliato l’oggetto del progetto
e il sistema di vincoli all’interno del quale si va ad operare. Esso deve contenere:
-
una illustrazione dei requisiti tecnici, per un dettaglio dei quali si può rimandare
ad un allegato ;
-
le risorse professionali che dovranno essere coinvolte , con una descrizione delle
competenze e dei ruoli e delle responsabilità che dovranno assumere nel corso
del progetto ( non è male presentare un organigramma);
-
il sistema delle relazioni con i soggetti di riferimento ( i così detti stakeholder) e
l’illustrazione delle politiche che si intende portare avanti nei loro confronti ( in
particolare verso i fornitori);
136
-
i prodotti che verranno rilasciati con una breve descrizione delle loro
caratteristiche fondamentali e della relativa documentazione;
•
Il piano delle attività ( anche denominato “ Master Plan”) che identifica le
attività, collocandone nel tempo ed abbinando ad esse risorse e responsabilità.
In corrispondenza di questo punto verrà sviluppata l’articolazione delle attività
secondo la tecnica della WBS e verranno applicate le tecniche di pianificazione
temporale per distribuire nel tempo le attività stesse.
•
il piano economico-finanziario, che dimensiona in modo analitico i costi di
investimento e di gestione, identifica i benefici, tangibili ed intangibili, e ne valuta
la convenienza sotto il profilo finanziario e sulla base dei criteri di selezione del
portafoglio informatico;
•
la struttura di progetto, che incrocia le attività con le responsabilità e le
competenze delle persone coinvolte nel progetto, definendo in modo particolare
le relazioni tra il progetto e gli utenti
•
il sistema di reporting del progetto, che definisce le modalità di misurazione
dei risultati intermedi e finali nonché definisce le scadenze di aggiornamento (
tendenzialmente trimestrali) del progetto e coerenti con quelle più generali del
sistema di pianificazione e controllo dell’azienda. E’ importante osservare che
l’aggiornamento
periodico
del
progetto
deve
contemplare
l’analisi
degli
scostamenti tra quanto previsto alla data e quanto effettivamente realizzato,
nonché una riprevisione a vita intera del progetto;
•
la gestione dell’incertezza, che identifica i rischi connessi alla mancato
raggiungimento delle finalità e al mantenimento dei costi e dei tempi previsti e
individua le azioni per mitigare i rischi stessi.
137
Nel grafico sottostante viene riportato uno schema85 che evidenzia il flusso che si dovrebbe
seguire nella pianificazione e controllo di un progetto.
Definire e comunicare
i vincoli del progetto
Contesto
Definire i prodotti che verranno
rilasciati : determinare il “ cosa” si
deve fare
Finalità
Piano delle
attività
Piano
economico/finanziario
Definire le risorse e
determinare i valori
monetari in gioco
5.3. Articolazione
Definire le attività: “ cosa” si deve fare
e “quando “
Struttura di
Progetto
Disegnare i ruoli
organizzativi sulla base
della matrice
responsabilità-attività
in
Sistema di
reporting
Definire i misuratori di
performance e le
modalità di
aggiornamento
unità
Gestione
dell’incertezza
Individuare i rischi
ed avviare politiche
di mitigazione
elementari
di
un
progetto
5.3.1.
Definizione di WBS
La Work Breakdown Structure consiste nella scomposizione del progetto in diversi livelli
di attività secondo una rappresentazione gerarchica. Nella struttura a WBS l’obiettivo
generale del progetto si scompone in sotto-obiettivi (rami) il cui livello di dettaglio
spinge fino all’individuazione dei pacchetti elementari di lavoro ( definiti con il termine
work-packages). Quando si sviluppa una WBS è importante domandarsi fino a che
punto sia opportuno spingersi con la disaggregazione, in quanto un livello elevato di
dettaglio costringe ad una analisi estremamente analitica del progetto che non sempre
risulta utile.
85
Mauro Marini e Federico Ballardini Tecniche di programmazione e controllo dei progetti in a cura di Federico Munari
e Maurizio Sobrero Innovazione tecnologica e gestione d’impresa ed. Il Mulino 2004 pag. 180
138
Al fine di descrivere le modalità di costruzione della WBS si può prendere in termini
esemplificativi la realizzazione di un progetto relativo ad un nuovo programma di
contabilità.
La struttura è articolata su tre livelli:
•
il primo livello identifica le macro-attività, nelle quali si può scomporre qualsiasi
progetto
informatico
relativo
ad
un
software:
analisi
dei
requisiti,
implementazione ed avviamento;
•
il secondo livello individua aggregazioni di attività e, nel contempo, gli output,
che si intende conseguire mediante la realizzazione delle attività di livello
sottostante:
-
l’analisi dei requisiti si distingue nella definizione dei requisiti funzionali e in
quella dei requisiti prestazionali ed entrambe le attività hanno come risultato la
scelta del software più adeguato tra quelli presenti sul mercato;
-
l’implementazione si articola, a sua volta, nell’eventuale personalizzazione del
software e nell’attività di parametrizzazione: la conclusione di queste attività è
costituita dalla sperimentazione e validazione del funzionamento del software (“
testing”);
-
l’avviamento si distingue nel collaudo delle funzionalità e delle prestazioni del
software da un lato, e dall’altro nell’attività di formazione e di addestramento del
personale che dovrà utilizzare il software;
•
il terzo livello delle attività è quello più specifico rispetto alle caratteristiche
peculiari del progetto: le attività relative a questo livello vengono di seguito
descritte in termini sintetici.
139
Attività di 2°livello
Descrizione
Attività di 3° livello
Descrizione
Analisi delle procedure aziendali
Analisi dei requisiti funzionali
Modello concettuale
Definizione delle specifiche
Software selection
Capacità di elaborazione
Analisi dei requisiti prestazionali
Automatismi e utilizzabilità
Accuratezza dei dati e reporting
Software selection
Contenuti
Ricostruzione del flusso di
lavoro, input ed output, di
ciascuna fase del processo
Definizione dei criteri di
progettazione del nuovo
sistema con analisi dati-processi
Preparazione dei requisiti
funzionali del software con il
livello di dettaglio e di
specificazione necessari
Attività di selezione del
software
Definizione dei dati tecnici
richesti dal software: capienza
archivio, numero e complessità
delle elaborazioni, frequenza
delle elaborazioni
livello di automazione tra le
diverse maschere di " input",
semplicità e completezza delle
maschere di lavoro
Modalità di controllo dei dati
immessi e archiviati,
elaborazione dei report di
controllo e di lettura
Attività di selezione del
software
140
Attività di 2°livello
Attività di 3° livello
Descrizione
Descrizione
Nuovi codici programma
Personalizzazione
Interfaccia e integrazione
Costruzione reporting
Testing
Definizione chiave contabile
Parametrizzazione
Inserimento formule
Gestione revisioni
Testing
Contenuti
Numero e complessità delle
linee di codice da sviluppare ed
attività di programmazione
Individuazione delle interfaccia
necessarie, loro caratteristiche
funzionali e tecniche, loro
realizzazione
Individuazione modalità
tecniche per costruire il
reporting, realizzazione
Sperimentazione del
funzionamento della
personalizzazione
definizione della codifica di
identificazione necessaria per
assicurare il dettaglio richiesto e
nel contempo l'accuratezza dei
dati richiesti: realizzazione
Piano complessivo delle
formule, loro descrizione, e
successivo caricamento
Eventuali revisioni dei codici
programma per problemi
incontrati
Sperimentazione
dell'accuratezza e dei risultati
ottenuti
141
Attività di 2°livello
Descrizione
Attività di 3° livello
Descrizione
Tempi di elaborazione
Accuratezza archivi
Collaudo
Accuratezza reporting
Addestramento
Affiancamento
Validazione definitiva del nuovo
programma ed abbandono
definitivo di quello attuale
Comunicazione sulle finalità del
e formazione in merito alle
caratteristiche innovative
Training sulle maschere di
input, sulle modalità di
funzionamento del software,
sull'elaborazione del report
Assistenza on the job
Validazione e rilascio
Validazione definitiva del nuovo
programma ed abbandono
definitivo di quello attuale
Validazione e rilascio
Comunicazione e formazione
Diffusione
Contenuti
Verifica dei tempi di
elaborazione in funzione delle
esigenze dell'utente
Verifica mediante quadrature e
controlli, a campione,
dell'accuratezza dei dati
Verifica dei risultati ottenuti
mediante quadratura con il
sistema attuale gestito in
parallelo
142
Nel grafico successivo viene rappresentata l’articolazione della WBS nel caso di un progetto
informatico legato ad un programma di contabilità
Nuovo
Programma
di Contabilità
Analisi
Dei Requisiti
Funzionali
Avviamento
Implementazione
Prestazionali
Analisi delle attuali
procedure
Capacità di
elaborazione
Modello concettuale
Automatismi e
utilizzabilità
Definizione delle
specifiche funzionali
Personaliz
zazione
Accuratezza dei dati e
reporting
Collaudo
Nuovi codici
programma
Definizione chiave
contabile
Interfaccia per
integrazione
Inserimento
formule
Costruzione
reporting
Testing
Software Selection
Parametri
Gestione
revisione
Testing
Software Selection
Tempi di
elaborazione
Diffusione
Comunicazione e
Formazione
Accuratezza
Archivi
Addestramento
Accuratezza
Reporting
Affiancamento
Validazione e
rilascio
Validazione e
rilascio
Come si può constatare la WBS può essere articolata su numerosi livelli di attività, in
quanto ciascuno dei livelli può essere a sua volta scomposto. Si pensi, per esempio, alla
definizione della chiave contabile, ossia della codifica di identificazione dei dati gestiti
dal sistema: essa può essere articolata in una fase di progettazione, in quanto la
chiave contabile è specifica di ciascuna azienda, in una di validazione ed infine nella
realizzazione della chiave contabile, che può comportare anche un'attività di
programmazione e quindi una ulteriore attività.
5.3.2.
Riaggregazione
delle
WBS:
la
matrice
dei
prodotti e delle responsabilità
La WBS è una struttura logica, che deve essere riportata alle effettive realtà progettuali,
incrociandola, quindi, con le risorse disponibili ( in particolare persone e competenze
delle stesse), con i tempi attesi per la realizzazione del progetto e con le modalità di
controllo del progetto stesso.
143
Può rivelarsi opportuno aggregare le attività elementari in "aggregati ", che
permettano di ottimizzare le risorse, che sono sempre limitate, e di migliorare la
gestione del progetto.
L’aggregato delle attività deve essere identificato in modo circoscritto ed è un
elemento di lavoro che dà origine ad un prodotto. E' definito da input, attività che lo
costituiscono, output, è connesso ad altri aggregati da interconnessioni logiche e ad
esso vengono associate risorse, tempi e responsabilità. E' quindi la base per pianificare e
controllare l'avanzamento del progetto. La riaggregazione delle attività elementari in
aggregati di attività da luogo a due “ viste” del progetto, di particolare importanza per la
pianificazione e gestione dei progetti.
Per pervenire all'aggregazione delle attività si possono utilizzare differenti approcci,
quali per esempio:
-
per fasi progettuali, che mantiene la struttura originaria della WBS (analisi dei
requisiti, implementazione e avviamento), con il rischio di una dispersione delle
responsabilità: chi deve svolgere l’analisi dei requisiti funzionali tenderà a
rinchiudere il proprio ruolo nella preparazione delle specifiche funzionali, perdendo di
attenzione la loro effettiva applicazione nella fase di avviamento; al contrario chi
deve seguire l’avviamento farà ricadere i problemi su una insoddisfacente o troppo
astratta progettazione del sistema (analisi dei requisiti);
-
per discipline, ossia amministrative, tecnico-informatiche e formative. Questo
approccio ha il pregio di coinvolgere le differenti competenze in tutte le fasi del
progetto, anche se con impegni differenti in relazione ai contenuti, ma richiedono un
elevato livello di coordinamento e la disponibilità di numerose risorse;
-
per output definiti, ossia per risultati intermedi. Se questo approccio è possibile,
esso ha il pregio di individuare degli “ elaborati” che permettano di misurare
l’attività svolta, determinare lo stato di avanzamento e di valicare la qualità degli
output così ottenuti. Questo approccio darà luogo alla PBS (product break down
structure), che definisce l’articolazione del progetto secondo la struttura degli
output, ossia di ciò che bisogna rilasciare.
144
Seguendo il nostro esempio ( introdurre un nuovo programma contabile) si possono
individuare tre fondamentali pacchetti di lavoro, che coniugano la comunanza delle
discipline con il raggiungimento di risultati tangibili:
-
l'impostazione
e
gestione
complessiva,
che
comprende
l'analisi
dei
requisiti funzionali, la definizione della chiave contabile, accuratezza dei dati e del
reporting, l'accuratezza archivi e reporting, formazione e comunicazione, la
validazione e il rilascio: si tratta di attività, che richiedono un forte
coinvolgimento del Settore Amministrativo, nelle figure dei loro responsabili, e
un legame importante con la Direzione Aziendale, che deve essere lo sponsor
fondamentale del progetto;
-
la progettazione e realizzazione della parte informatica, che comprende
l'analisi dei requisiti prestazionali, la software selection, la personalizzazione,
costruzione reporting, gestione revisioni, il collaudo dei tempi di elaborazione, il
testing;
-
l'attività operativa, che comprende l'inserimento formule, l'addestramento
e
l'affiancamento.
Nel grafico successivo viene riportata la possibile aggregazione della WBS nel caso di un
programma di contabilità.
In corsivo: impostazione e gestione
In grassetto: progettazione e
realizzazione informatica
Nuovo
Programma
di Contabilità
In sottolineato: attività operative
Analisi
Dei Requisiti
Funzionali
Avviamento
Implementazione
Prestazionali
Analisi delle attuali
procedure
Capacità di
elaborazione
Modello concettuale
Automatismi e
utilizzabilità
Definizione delle
specifiche funzionali
Accuratezza dei dati e
reporting
Personaliz
zazione
Software Selection
Collaudo
Nuovi codici
programma
Definizione chiave
contabile
Interfaccia per
integrazione
Inserimento
formule
Costruzione
reporting
Testing
Software Selection
Parametri
Gestione
revisione
Testing
Diffusione
Tempi di
elaborazione
Comunicazione e
Formazione
Accuratezza
Archivi
Addestramento
Accuratezza
Reporting
Affiancamento
Validazione e
rilascio
Validazione e
rilascio
145
5.3.3.
Collocazione temporale delle attività
Una volta definite le attività elementari, i pacchetti di lavoro e le responsabilità relative,
occorre collocare le attività nel tempo, individuando i legami temporali tra le diverse
attività.
Il legame tra le diverse attività può essere di vario tipo:
-
Finish to Start, l’attività successiva può cominciare solo quando è terminata
l’attività indicata come precedente: si tratta di un legame sequenziale tra le
attività;
-
Finish to Finish, se l’attività A non è terminata, l’attività B non può terminare: si
tratta di un legame condizionante, che permette comunque di andare in parallelo
sull’asse dei tempi ma evidenzia un vincolo nel proseguimento delle attività;
-
Start to Finish, se l’attività A non è iniziata, l’attività B non può terminare, anche
in questo caso l’ attività B può essere avviata anche se non è partita l’attività A,
che comunque costituisce un vincolo per la conclusione dell’attività B;
-
Start to Start, se l’attività A non è iniziata, l’attività B non può iniziare, le due
attività devono partire contemporaneamente, possono avanzare in parallelo e
possono concludersi in momenti differenti.
Si tratta di elaborare dei diagrammi temporali mediante strumenti più o meno
sofisticati, sia sotto il profilo metodologico che informatico.
5.4. La Struttura di Progetto
Organizzare un progetto significa individuare organismi e ruoli che assicurino
determinazione, unicità di comando, coordinamento ed integrazione tra i diversi soggetti
coinvolti nel progetto.
La struttura organizzativa deve assicurare la coerenza tra WBS e la schedulazione delle
attività da un lato e il sistema delle responsabilità
dall’altro ( OBS, organisation
breakdown structure). Essa deve inoltre garantire il controllo dei costi e degli stati di
avanzamento del progetto, nonché la riprevisione delle attività, dei tempi e dei costi
durante tutta la vita del progetto.
146
L’organizzazione di un progetto dipende, ovviamente, dalla sua dimensione e
complessità, in quanto costituisce un costo di coordinamento, che non può diventare
eccessivamente pesante rispetto al volume dell’investimento e deve trovare comunque
giustificazione rispetto ai problemi da affrontare e non sulla base di uno schema
standard.
In generale sono stati individuati i seguenti organismi e ruoli organizzativi:
-
Comitato Guida ( Steering Committee ) che ha funzioni generali di indirizzo e di
controllo ed assiste il Capo Progetto.
Il Comitato Guida è composto da un rappresentante del Vertice Aziendale, che lo
dovrebbe presiedere, da rappresentanti delle funzioni aziendali utenti, dalla Direzione
del Personale e dallo stesso Capo Progetto. Il Comitato Guida dovrebbe riunirsi con
scadenze periodiche ( tendenzialmente mensili) al fine di analizzare lo stato di
avanzamento del progetto e intervenire su tutti i problemi, in particolare quelli tra le
diverse funzioni aziendali, che potrebbero emergere nel corso del problema;
-
Capo Progetto ( Project Manager) è il responsabile generale del progetto.
La letteratura ha “ mitizzato” la funzione del Capo Progetto, affidandogli ruoli
demiurgici, quasi da piccolo capo azienda. La realtà, almeno nel nostro paese, è
molto distante da questa visione e nella maggior parte delle situazioni il Capo
Progetto rappresenta un facilitatore, che fluidifica, stimola e monitora le attività del
progetto, intervenendo anche, per quanto gli è possibile, a risolvere le situazioni di
emergenza.
L’esperienza ha dimostrato come il Capo Progetto debba soprattutto assicurare il
massimo di trasparenza e di comunicazione sulle attività del progetto così da
permettere al Vertice Aziendale di intervenire tempestivamente ogni qual volta sia
necessario.
147
IL PM: MODELLI DI RUOLO
1 FACILITATORE
Comunicazione
Tempo
Persuasione
Basso status
Nessuna autorità
Può essere part-time
Facilmente revocabile
2 COORDINATORE
Controllo
Comunicazione
Tempo e Costi
Richiede autorizzazione a spendere
Nessuna autorità sulle persone
Autorità tecnica sul progetto
Può essere part-time
Revocabile
3 PROJECT MANAGER
Direzione
Progetto e Risorse
Definisce il budget
Autorità sulle persone (parziale)
Negozia e autorizza i cambiamenti
Autorità nell'ambito del progetto
Tendenzialmente a tempo pieno
Difficilmente revocabile
4 PROJECT GENERAL
MANAGER
Comando
Profitto e Persone
Pieni poteri
Autorità sulle persone
Negozia e autorizza i cambiementi
Autorità nell'ambito del progetto
Tempo pieno
Difficilmente revocabile
3
-
Gruppi di lavoro ( o project team) sono costituiti da persone che , a tempo pieno
o a tempo parziale, eseguono le attività operative del progetto. L’articolazione dei
gruppi di lavoro riflette le filiere delle attività del progetto, in modo coerente con la
OBS del progetto.
Talvolta si può rendere necessario identificare dei Responsabili di Parti di Progetto o
di Task, che assumono la responsabilità di gruppi di attività e di conseguenza
coordinano le risorse dedicate.
Qualora l’organizzazione del progetto preveda più responsabili si può prevedere un
Comitato Tecnico, o Comitato di Progetto, composto dal Capo Progetto e dai
Responsabili dei gruppi di lavoro che funge da tavolo operativo di discussione del
progetto e da una prima istanza decisionale.
-
Segreteria Tecnica ( Project Office) per i progetti di maggiore dimensione il Capo
Progetto è assistito da una struttura tecnica, costituita da competenze di Controllo
Costi e di Planning, che gestisce tutta la documentazione di progetto e monitora la
pianificazione e il controllo del progetto.
148
Nel grafico successivo viene presentata una struttura di progetto, caratterizzata da una gestione
collegiale, nel quale il Capo Progetto ha fondamentalmente un ruolo di facilitatore e di
assicurare la comunicazione più efficace tra i Responsabili di Task e il Comitato Guida.
PROGRAMMA DI LAVORO/ORGANIZZAZIONE DEL PROGETTO
Per rispondere ai criteri sopra indicati la struttura di progetto fa perno su un Comitato
Guida e sui Responsabili di task
Direttore Generale
Direttori di Area
UN COMITATO GUIDA
Capo Progetto
CONTROLLO DEL
PROGETTO
ANALISI
PERSONALIZ
ZAZIONE
PARAMETRIZ
ZAZIONE
TEST ED AVVIO
TASK
TASK
TASK
TASK
Qualsiasi progetto deve essere minimamente strutturato non fosse altro per evitare una
scarsa chiarezza nella definizione delle responsabilità e dei ruoli coinvolti.
I risultati che può dare un sistema di governo del progetto dipendono, tuttavia, da una
serie di fattori che sono al di là della stessa organizzazione adottata.
Il primo fattore è costituito dallo stile direzionale prevalente nell’azienda. Perché
funzioni il sistema di governo del progetto è necessario che nell’organizzazione si dia
importanza agli impegni assunti e ai ruoli organizzativi descritti e non ci si affidi invece,
come spesso accade nelle aziende italiane, alle relazioni informali e alle responsabilità
assunte nei fatti, anche al di fuori di quanto descritto dall’organigramma.
Occorre chiedersi quanto può essere efficace disegnare una struttura organizzativa di
progetto in realtà anche di media dimensione, come sono molte aziende italiane, nelle
quali mancano manuali organizzativi, descrizione delle mansioni , procedure, e nelle
quali il modello organizzativo prevalente è quello adocratico ( strutture ad hoc che
lavorano sulle emergenze) e/o gerarchico, poco incline ad accettare attività di tipo
trasversale, come sono tipicamente i progetti informatici.
149
Un’altra criticità rilevante dell’approccio basato sul sistema di governo è costituito dalla
carenza di risorse umane dotate di professionalità di rilievo, che caratterizza orami la
realtà industriale del nostro paese. In una situazione di scarsità di risorse è veramente
difficile pensare di strutturare un progetto dotandolo di molte figure gestionali e occorre
orientarsi verso soluzioni organizzative semplici , che non comportino un elevato
dispendio di energie e di tempo per la Direzione Aziendale. E’ anche per questo motivo
che si tende ormai ad affidare i grandi progetti informatici a Società di Consulenza, che
tendono a fornire un prodotto “ chiavi in mano” con tutte le conseguenze in termini di
effettiva operatività e applicabilità delle soluzioni informatiche.
Un ultimo aspetto è rappresentato dalla necessità di ridurre i costi di coordinamento,
che potrebbero derivare da un’eccessiva strutturazione del progetto.
L’adozione di un efficace sistema di governo costituisce una condizione necessaria per
gestire il progetto ma non è sufficiente e si potrebbe rivelarsi irrealizzabile e quindi
restare un “ disegno sulla carta”.
5.5. La Gestione del Cambiamento
5.5.1.
Nella
Formazione come strumento del cambiamento
cultura
del
mondo
informatico
la
formazione
viene
spesso
ricondotta
all’addestramento dell’utente sulla “ macchina”, adottando un approccio semplicistico al
tema del cambiamento: è stato messo a punto un nuovo software che porta a
funzionalità più elevate ( e quindi “ migliore”) , non si vede perché una persona non
debba adeguare i propri comportamenti e le proprie capacità, se gli vengono fornite le
giuste istruzioni.
Il cambiamento è tuttavia un processo complesso, in gran parte irrazionale, che richiede
un miglioramento delle conoscenze e delle capacità delle persone sotto due punti di
vista.
150
In primo luogo le persone devono cambiare la natura delle loro attività ( e spesso delle
loro stesse responsabilità), rendendo necessario acquisire nuovi strumenti per
conseguire il proprio ruolo e fare il proprio lavoro. Si pensi soltanto all’applicazione di un
CRM in una rete dei concessionari, nella quale i venditori sono abituati a gestire la
negoziazione con il cliente e non a raccogliere ed analizzare le informazioni per
indirizzare campagne promozionali in una fase anche successiva alla vendita ( in tutto il
ciclo di vita dell’automobile venduta).
In secondo luogo le stesse persone sono e devono essere fattori del cambiamento nel
senso che devono contribuire a realizzare le finalità dell’innovazione. Essi dovranno
modificare il proprio comportamento per renderlo aperto all’innovazione. Ritornando
sempre all’esperienza di un CRM in una rete di concessionari, gli stessi venditori sono i
soggetti che dovranno portare avanti un differente approccio verso il cliente ( dalla
vendita al marketing) e quindi sarà dai loro comportamenti che dipenderà in misura
significativa il successo della stessa innovazione ( e conseguentemente della nuova
tecnologia).
Non tutti gli strumenti rivolti ad adeguare le professionalità sono efficaci ma vanno
considerati in funzione del fabbisogno formativo da affrontare in sede di realizzazione di
un progetto informatico.
Esistono generalmente due “ assi “ del fabbisogno formativo da tenere presente:
-
il livello delle capacità, ossia l’acquisizione di nuove conoscenze e professionalità,
che possono coinvolgere l’acquisizione di nuovi strumenti ( banalmente si impara ad
usare Excell, Word e Power Point e così via) e di nuovi approcci al lavoro ( si impara
a comunicare tramite la posta elettronica, si conservano le informazioni in archivi
elettronici). L’esperienza dimostra come il cambiamento negli approcci di lavoro sia
molto più faticoso rispetto all’acquisizione degli strumenti;
-
il comportamento, ossia la disponibilità all’innovazione e a diventare fattore di
cambiamento: si pensi, per esempio, alla differenza tra imparare ad utilizzare un
programma di contabilità da un lato ed indurre e motivare i colleghi ad utilizzarlo e
valorizzarlo dall’altro ( normalmente tutti i nuovi software sono sotto utilizzati)
151
convincendoli ad abbandonare i vecchi approcci di lavoro ( basati per esempio su
Excell).
-
Ebbene, se incrociamo in una matrice queste due variabili ( livello di capacità richiesto e
comportamenti da modificare) è possibile individuare l’approccio formativo più corretto
in quella situazione specifica.
Basso miglioramento nei livelli di capacità e basso cambiamento nei comportamenti: in
questo caso le persone mancano delle necessarie professionalità per acquisire le nuove
tecnologie, le quali tuttavia non richiedono un cambiamento radicale e di conseguenza
una elevata partecipazione delle persone nella realizzazione del cambiamento. Lo
strumento della formazione come addestramento può essere una risposta efficace, in
quanto è sufficiente trasmette nuove abilità a fare e in questo modo si fornisce anche
sicurezza alle persone coinvolte, superando quello stato di ansietà che si collega sempre
al cambiamento.
Elevato miglioramento nei livelli di capacità e basso cambiamento nei comportamenti: in
questo caso il vero scoglio è costituito dall’altezza dell’ “ asticella” in termini di
professionalità e conoscenze richieste. L’addestramento potrebbe non rilevarsi
sufficiente o essere troppo costoso richiedendo interventi ripetuti nel tempo. Una
possibile soluzione è rappresentata dall’ “ affiancamento”, ossia da interventi mirati al
problema e al momento nel quale la persona è in difficoltà ad individuare la soluzione.
Basso miglioramento del livello di capacità ed elevato cambiamento nei comportamenti:
in questo caso l’addestramento si può rilevare totalmente inutile, mentre può essere
molto più efficace un’attività di formazione basata sulla comunicazione, ossia orientata a
trasmettere i nuovi valori, a chiarire le finalità del cambiamento e a rispondere ad
eventuali criticità che potrebbero emergere ( di solito di tipo organizzativo).
Alto miglioramento del livello di capacità ed elevato cambiamento nei comportamenti:
tutte le altre tipologie di formazione ( addestramento, assistenza, comunicazione) si
potrebbero rilevare necessarie ma non sufficienti per garantire il cambiamento. Una
possibile soluzione è costituita dal “ coaching” , ossia da un supporto costante orientato
152
non tanto a fornire soluzioni o risposte a problemi di ordine tecnico ( come potrebbe
essere l’attività di assistenza) ma soprattutto a fornire gli strumenti per lavorare sulle
potenzialità della persona e quindi per accelerare lo sviluppo professionale e
manageriale.
Alto
Affiancamento
Coaching
Miglioramento
livelli
di capacità
Addestramento
Comunicazione
Basso
Basso
Alto
Cambiamento nei comportamenti
5.5.2.
Diverse tipologie di intervento formativo
Le attività formative rivolte all’ “ adeguamento professionale” vanno affrontate
nell’ambito delle discipline che studiano la gestione e lo sviluppo delle risorse umane.
In questo contesto, che ha come oggetto la gestione di progetti informatici, verranno
solo forniti alcune classificazioni che permettono di orientarsi all’interno di una materia
molto complessa ed articolata, quale quella della scienza della formazione.
Addestramento
Per addestramento occorre intendere tutte le attività di formazione rivolte a trasmettere
informazioni e nozioni finalizzate ad acquisire capacità nell’uso di strumenti, in questo
caso informatici.
153
L’oggetto è quindi fondamentalmente tecnico e può essere affrontato con tre
fondamentali modalità:
-
la documentazione: la predisposizione di manuali ed istruzioni costituisce una
modalità di trasmissione delle informazioni, spesso trascurata dalle società di
software e poco richiesta dagli utenti ( forse per la falsa opinione che sia poco
importante accedere a documentazione scritta). Essa è invece fondamentale anche
per verificare lo scostamento tra quanto promesso e quanto realizzato e per
patrimonializzare la conoscenza al di là dell’utente che è stato coinvolto nella fase di
avvio del nuovo sistema;
-
la formazione in fase di avvio , che non deve limitarsi a sperimentare le funzionalità
del nuovo software, ma che deve riguardare anche una attività di impostazione più
generale che affronti le caratteristiche operative del software e i presupposti
concettuali che ne sono alla base;
-
la formazione di “ richiamo” e in corso d’opera, che deve ritornare sulle principali
criticità incontrate non una logica di mera risposta ai problemi ma con la finalità di
realizzare eventuali approfondimenti. Lo sviluppo della formazione a distanza ( elearning) permette oggi di abbassare radicalmente i costi di questa fase di
formazione anche a fronte di una popolazione numerosa e distribuita in termini
geografici;
E’ in generale importante che si richieda all’utente una funzione attiva, che lo costringa
ad operare con il nuovo software così da creare un reale apprendimento.
Affiancamento
Per affiancamento occorre intendere l’attività di supporto nella fase di avvio del
software così da realizzare l’addestramento “ by doing” che viene realizzato mediante il
tutoraggio di un esperto.
Poco utilizzato, in quanto le società fornitrici lo riconducono all’assistenza ( che
normalmente viene pagata a parte al di fuori del costo di licenza e di implementazione
del software) l’affiancamento rappresenta uno strumento molto efficace in quanto
permette di trasmettere le informazioni e le capacità durante l’utilizzo del nuovo
software.
154
Comunicazione
La finalità della comunicazione è di “ mettere in movimento” l’organizzazione, non solo
fornendo informazioni ma modificando le relazioni tra chi attiva il cambiamento e gli altri
partecipanti, creando un flusso di idee che è alla base di un nuovo modo di vedere la
realtà.
Nella gestione di un progetto i passi fondamentali per realizzare la comunicazione sono i
seguenti:
-
trasmettere la visione ( il problema, la soluzione e i mezzi per conseguirla) che guida
il processo di cambiamento. E’ opportuno, a questo fine, che non ci si limiti ad una
riunione di avvio ma si dia luogo ad una prima attività nella quale vengono
identificate le criticità che si incontreranno nella realizzazione del progetto e ad esse
vengano date prime risposte in termini di soluzioni già adottate o da adottare;
-
informare i partecipanti su come si sta proseguendo nella realizzazione del progetto.
E’ opportuno non solo trasmettere i problemi che si sono incontrati e che cosa c’è
ancora da fare: bisogna porre anche enfasi su quanto è già stato fatto così da
ridurre l’ansietà e creare sicurezza.
Coaching
Questa attività è rivolta fondamentalmente ai manager. Essa si esplica in una serie di
sessioni congiunte ( l’allenatore e i manager ) , nelle quali vengono analizzate le
situazioni incontrate e vengono scambiate idee ed esperienze. L’ allenatore deve
svolgere un ruolo di catalizzatore nell’aiutare il manager a riconoscere i punti di
debolezza e di forza e a trovare quindi le soluzioni appropriate a ciascuna delle
circostanze incontrate.
Questo approccio si basa sul principio che le persone non imparano nuovi
comportamenti ed approcci se gli vengono fornite già le soluzioni: esse devono trarre
lezioni dai loro successi e fallimenti.
Le attività rivolte all’adeguamento professionale si muovono all’interno delle scienze del
comportamento e si basano sul presupposto che gli ostacoli al cambiamento siano
155
riconducibili ad un divario professionale o a resistenze dovute ad una scarsa
comprensione delle ragioni del cambiamento e di come debba essere affrontato.
Questo approccio trascura l’ovvia considerazione che le persone in un’azienda operano
in contesto strutturato, fondamentalmente influenzato dai rapporti di potere e
dall’assetto che è stato dato ai processi aziendali.
Gli interventi di formazione e di comunicazione possono essere ancillari rispetto ad
azioni più profonde che operino sull’organizzazione aziendale ( i processi aziendali e lo
sviluppo delle risorse): essi non possono sostituire interventi sull’assetto dei processi
aziendali.
5.6. Gestione del cambiamento: riferimenti teorici
5.6.1.
Sistemi informativi e cambiamento
I benefici derivanti dagli investimenti in ICT si ridurranno inevitabilmente se le aziende
non considereranno i costi del cambiamento organizzativo associati al nuovo sistema o
non renderanno effettivi tali cambiamenti/implementazioni di successo richiedono
un’attenta gestione del cambiamento “ .86 “Le tecnologie informatiche possono
permettere i cambiamenti, ma la mera esistenza di queste tecnologie non vuol dire che
questi cambiamenti debbano necessariamente verificarsi “87 .
Affermazioni di questo genere, che riconducono all’organizzazione e alle persone che la
compongono le ragioni dell’insuccesso di molti progetti in campo informativo,
rappresentano ormai un “ leit motiv” di tutti i testi che trattano di implementazione delle
tecnologie informatiche.
Si tratta della componente contestuale di un progetto di gestione dei sistemi
informativi, che riguarda la strumentazione da adottare per rendere le modalità di
lavoro coerenti con le caratteristiche e le potenzialità delle nuove tecnologie.
86
Kenneth e Jane Laudon, Management dei Sistemi Informativi ed. Prentice Hall 2003 pag. 523
87
Lynn C. Kubeck Techniques for Business Process Redesign “ John Wiley e Sons 1995 pag. 6
156
A differenza delle tecniche di project management and control ( la componente
strutturale), che potevano attingere ad una dottrina consolidata, il tema del
cambiamento organizzativo innescato dall’ICT deve fare riferimento ad una miscellanea
di contributi che provengono da discipline ed approcci differenti: dall’analisi delle
strutture organizzative ( rivolte alla definizione dei ruoli e delle responsabilità) alla
riprogettazione dei processi aziendali sino alle teorie di sviluppo delle risorse umane.
5.6.2.
Definizione di Cambiamento
Per un’organizzazione così come per un individuo, si verifica un cambiamento “ ogni
qualvolta si modifica il sistema di conoscenze e di valori che sono alla base della
capacità di agire “.
Nella definizione di cambiamento sono presenti tre componenti fondamentali:
-
la conoscenza , che non è un sinonimo di dati e di informazioni ma “ è qualcosa di
ulteriore: essa consiste nella conclusione che deriva dal collegamento di una
informazione con altre informazioni e dal confronto con le conoscenze già
acquisite…. Implica la ricerca del modo in cui agire in base all’informazione per
conseguire gli obiettivi organizzativi “88.
Si possono distinguere due tipologie di conoscenze: quella esplicita, che è stata
formalizzata in documenti ed istruzioni; quella implicita che fa riferimento alle
esperienze delle persone e a quelle soluzioni che sono state trovate e realizzate nel
tempo;
-
i valori, intesi come “ l’insieme di opinioni e modi di pensare che sono condivisi dai
membri di un’organizzazione e che vengono insegnati ai nuovi membri come
esemplari “89;
88
89
Richard L. Daft Organizzazione Aziendale Apogeo Editore 2001 pag. 272-273
Richard L. Daft Organizzazione Aziendale Apogeo Editore 2001 pag. 330
157
-
il legame tra il patrimonio delle conoscenze e dei valori da un lato e la capacità di
agire dall’altro; il primo dà luogo ad “ una visione collettiva della realtà “ che
costituisce spesso il principale ostacolo all’avvio e alla realizzazione di
azioni ed
interventi che non siano basati sulle “ vecchie filosofie”.
La capacità di agire di una organizzazione non è quindi solo il risultato di un fatto
razionale ma anche dell’insieme di credenze, miti, competenze che costituiscono “ la
cultura aziendale” e determinano la principale resistenza al cambiamento.
D’altra parte il cambiamento non è la condizione naturale di un’azienda. Le aziende sono
disegnate per operare e non per cambiare: esiste quindi una potenziale contraddizione
tra lo sforzo delle organizzazioni di “ mettere ordine” per focalizzarsi sulla missione
aziendale e il cambiamento che porta necessariamente alla destabilizzazione e quindi al
disordine.
L’effetto destabilizzante del cambiamento rappresenta un passaggio obbligato, in
quanto deve incrinare le “ vecchie filosofie” se si vuole introdurre una reale innovazione
all’interno dell’organizzazione.
Questa “ rottura “ rispetto al passato crea ansietà, in quanto costringe le persone a
riallocare le conoscenze e i valori sui quali si erano appoggiati per lavorare in un
contesto percepito come stabile e sicuro.
La sensazione di ansietà ha connotati ambivalenti: da un lato rappresenta già il
presupposto al cambiamento ma dall’altro può spingere ad atteggiamenti di chiusura
per difendere il modo tradizionale di operare ponendo le basi per l’insuccesso ( o
parziale fallimento) dell’introduzione della nuova tecnologia.
Dallo stato di ansietà si può quindi uscire in modo positivo, costruendo una nuova
cultura aziendale, o viceversa si può implodere verso una posizione di stallo: non si può
tornare alla situazione preesistente in quanto ormai operano gli effetti della nuova
tecnologia e si ci viene a collocare in uno stato “ intermedio”, nel quale si cercherà di
adeguare il meno possibile alla nuova tecnologia le modalità di lavoro e il sistema delle
conoscenze e dei valori.
158
Il passaggio dallo stato di ansietà a quello di confidenza sull’innovazione costituisce la
chiave di volta per il successo di un processo di cambiamento e quanto più
l’organizzazione è in grado di “ dimenticare” le “ vecchie filosofie” quanto più si
assicurerà i benefici derivanti dall’introduzione delle nuove tecnologie.
Confidenza
Situazione
Di partenza
Massimi
Benefici
Ansietà
Implosione
Destabilizzazione
Introduzione
della nuova
tecnologia
5.6.3.
Situazioni
Sotto
Utilizzo
Differenti tipologie di cambiamento
Il cambiamento può assumere, ovviamente, caratteristiche molto differenziate, tanto da
renderlo difficilmente classificabile in categorie concettuali definite e stabili nel tempo.
Ai fini di capire la relazione tra cambiamento e modalità per realizzarlo è utile fare
riferimento a due possibili variabili: la profondità e la rapidità.
Per “ profondità del cambiamento “ si deve intendere “ il grado con il quale il
cambiamento influenza la natura dell’azienda”90.
90
John Pendlebury, Bendit Grouard, Francis Meston: Successful Ch’ange Management ed. Wiley 1998 pag. 14
159
Si può parlare di “cambiamento superficiale o incrementale”, quando si fa riferimento
ad
un’attività
di
miglioramento
costante,
il
cambiamento
coinvolge
parti
dell’organizzazione e per essere realizzato si può far leva su strutture organizzative già
esistenti e su processi tradizionali
91
.
Si pensi, per esempio, al completamento di un pacchetto software di contabilità con un
modulo di controllo di gestione appartenente alla stessa ditta fornitrice e che verrà
utilizzato dalla sola Direzione Amministrativa; oppure al potenziamento di una rete
interna con tecnologie più moderne che si rivolge ad utenti già abituati alla
comunicazione elettronica.
Si parla invece di “ cambiamento radicale o profondo “ quando si tratta di modificare
radicalmente l’architettura informatica esistente, viene coinvolta l’intera organizzazione
e si rende necessario ridisegnare i processi aziendali ed introdurre nuove modalità di
lavoro, che comportano nuove professionalità e competenze.
L’esempio più tipico di un cambiamento radicale è dato dall’introduzione di un Erp , in
quanto costringe ad integrare processi aziendali , che prima lavoravano tramite
programmi dipartimentali, e coinvolge più funzioni aziendali.
Per “ rapidità del cambiamento “ si deve intendere il tempo entro il quale occorre
realizzare il cambiamento. “ E’ un fattore di crescente importanza…il cambiamento non
è sufficiente in quanto spesso occorre realizzarlo rapidamente per mantenere la
posizione competitiva”92 .
Le ragioni perché un cambiamento venga realizzato rapidamente non sono solo
riconducibili alla turbolenza del contesto esterno all’azienda: va anche considerata la
necessità di non disperdere troppe energie nella realizzazione di un progetto.
91
Richard L. Daft Organizzazione Aziendale Apogeo Editore 2001 pag. 368
92
John Pendlebury, Bendit Grouard, Francis Meston: Successful Ch’ange Management ed. Wiley 1998 pag. 14
160
Le due variabili “ profondità “ e “ rapidità” sono importanti in quanto influenzano due
ulteriori componenti di un processo di cambiamento:
-
il grado di partecipazione delle persone: ovviamente quanto più il cambiamento
è radicale e può avere tempi lunghi, tanto più è possibile, e necessario, coinvolgere
e ricercare il consenso delle persone;
-
lo spessore delle analisi: anche in questo caso la disponibilità di tempi e la
profondità del cambiamento potranno rendere necessario e permettere analisi
approfondite prima ancora di avviare lo stesso processo di cambiamento.
A questo punto è possibile chiedersi quale dei possibili approcci al cambiamento illustrati
nel primo capoverso ( sistema di governo, adeguamento delle professionalità,
razionalizzazione dei processi e sviluppo organizzativo) sia più congeniale in relazione
alle due variabili: profondità e rapidità.
L’approccio basato sul “ sistema di governo” è funzionale ad un cambiamento che deve
essere realizzato in tempi brevi, ma che può essere agevolmente imposto dall’alto, in
quanto non provoca mutamenti profondi nell’organizzazione.
Fare affidamento ad interventi formativi rivolti ad “ adeguare le professionalità “ è
congeniale ad un cambiamento che può essere realizzato in tempi lunghi, lasciando
all’organizzazione il tempo di metabolizzare l’innovazione, e che non coinvolge
mutamenti radicali tali da dover ridisegnare i processi aziendali.
Le tecniche di BPR sono generalmente pervasive per l’organizzazione richiedendo analisi
approfondite e complesse: dovrebbero essere applicate a fronte di cambiamenti radicali
che non devono essere realizzati in tempi brevi.
Gli strumenti dello sviluppo organizzativo ( percorsi di carriera, sistemi di incentivazione,
mobilità interna e così via) dispiegano la loro efficacia in tempi anche brevi ma
costituiscono un costo significativo per l’organizzazione ( in termini di tensioni emotive e
di mutamenti di valori culturali di riferimento ) e vale la pena utilizzarli se occorre
affrontare innovazioni profonde.
161
Nella matrice seguente viene sintetizzata graficamente la correlazione tra profondità e
rapidità del cambiamento dal un lato e i possibili approcci alla gestione del
cambiamento.
Alto
BPR
Sviluppo
organizzativo
Profondità
del
cambiamento
Adeguamento
professionale
Sistema di
governo
Basso
Basso
Alto
Rapidità del cambiamento
5.6.4.
La dimensione emotiva e quella del potere
Un processo di cambiamento ha sempre, in misura maggiore o minore, un impatto su
due fondamentali dimensioni dell’individuo, che “ vive all’interno dell’organizzazione.
-
Il cambiamento provoca reazioni emotive che sono legate al timore di essere
inadeguati, a dubbi sulle proprie capacità, a speranze di sviluppo personale e così
via. Il cambiamento crea nuove condizioni, che possono essere minaccianti o
attrattive ma che in tutti i casi non sono familiari, specialmente se si è abituati ad
operare in un ambiente stabile.
La rottura con lo “ status quo” è particolarmente destrutturante per le persone, che
condividano o meno il cambiamento. La novità e la natura destabilizzante
dell’innovazione creano sintomi di resistenza e lo sviluppo di chiusure da parte degli
individui che ne vengono influenzati.
Le resistenze sono particolarmente forti all’inizio del processo di cambiamento, ma non
scompaiono mai nel corso del progetto.
162
I principali sintomi di resistenza sono i seguenti:
Non riconoscimento
Marginalizzazione
Familiarità con la soluzione
Rifiuto della soluzione
Timore delle conseguenze
I mezzi
Mancanza di interesse
-
Se la situazione esistente è percepita come soddisfacente, le
persone non capiscono perché bisogna cambiare
Il problema è riconosciuto ma si considera secondario in
funzione di uno o più problemi considerati prioritari
Il problema è accettato,ma si resiste al cambiamento perché
non è capita la soluzione. Quando gli obiettivi non sono
conosciuti o sono vaghi, le persone rifiutano il progetto,
perché ne riconoscono i presupposti ma non le sue finalità
Il problema è riconosciuto e la soluzione conosciuta, ma
quest’ultima non è considerata appropriata
Le persone resistono perché temono di non essere capaci di
adattarsi alle nuove condizioni o di perdere vantaggi di
potere
Si richiama la mancanza di mezzi, ma si tratta spesso di una
falsa causa che nasconde i sintomi sopra illustrati
Le persone non vogliono il cambiamento perché qualsiasi
cambiamento richiede impegno ed energia. Questo
atteggiamento nasce spesso da uno scarso interesse nel
lavoro, da un diffuso scetticismo su qualsiasi cambiamento e
da un senso di frustrazione rispetto a quanto deciso dal
Vertice Aziendale
Il cambiamento modifica la struttura di potere, la quale influenza in misura
determinante le relazioni tra gli individui e l’atteggiamento di quest’ultimi verso le
regole aziendali.
Il cambiamento, operando una rottura dello status quo, destabilizza le relazioni di
potere: alcuni individui e funzioni aziendali ne usciranno rinforzati, altri saranno
indeboliti dagli effetti dell’innovazione. In generale le resistenze al cambiamento
163
tendono ad essere più forti di quelle che lo favoriscono, in quanto la struttura di potere
( che è fatta fondamentalmente di relazioni informali, non scritte) tende a modificarsi
secondo una direzione non prevedibile e che quindi crea minaccia per tutti.
In generale all’interno della struttura di potere di un’azienda esistono tre tipologie di
atteggiamenti nei confronti del progetto:
-
i supporter, che condividono gli obiettivi del progetto e sono disponibili a sostenerlo.
Se questi soggetti hanno un forte peso decisionale vanno valorizzati nella funzione
che potrebbero svolgere nell’ambito dei conflitti di potere attivati dalla realizzazione
del progetto;
-
gli opponenti, che ostacolano comunque, per motivazioni di potere e/o per fattori
emotivi, gli obiettivi del progetto e rappresentano un’area di rischio da gestire con
un atteggiamento fermo ma non minacciante;
-
gli indifferenti, che sono normalmente la parte più ampia della popolazione, che
assumono un atteggiamento di attesa rispetto ai conflitti di potere che si sono aperti
con l’avvio del progetto.
La presenza di due dimensioni ( quella emotiva e quella relativa alla struttura di potere)
rende opportuno realizzare, pur nell’ambito di un progetto apparentemente tecnico,
quale quello informatico, una serie di interviste ai manager e a coloro i quali hanno un
ruolo di “ opinion leader “ per identificare la struttura di potere, il ruolo dei principali
attori e le resistenze più probabili che potrebbero scaturire dalla dimensione emotiva.
L’ impatto del progetto sulle due dimensioni potrebbe essere sintetizzato su una
matrice, che colloca il progetto o parti di esso tra due assi : il grado di cambiamento
sulla struttura di potere e il livello possibile di reazione emotiva.
164
Forte
Reazione
emotiva
Progetto
Debole
Instabile
Stabile
Struttura di potere
5.6.5.
Realizzare lo sviluppo organizzativo
Gestire le due dimensioni ( quella emotiva e quella legata alla struttura di potere)
significa adottare una serie di accorgimenti, che appartengono alla “ sfera” della
gestione delle risorse umane.
In questo contesto ne vengono indicati alcuni senza pretesa di essere esaustivi:
-
adottare un approccio per approssimazioni successive, che sia in grado di
fornire risultati parziali, che confermano la validità delle finalità del progetto. La
sperimentazione riduce il senso di ansietà ( in quanto le persone percepiscono i
contenuti del progetto come qualche cosa di reversibile ), favorisce la partecipazione
anche nell’attività di verifica dei risultati, i quali a loro volta, se positivi, creano
crescente confidenza.
In termini informatici ciò significa privilegiare, se possibile, soluzioni anche non
ottimali ma che permettono alle persone di testare le funzionalità possibili delle
nuove tecnologie, ed operare in una logica prototipale rispetto ad una modalità che
faccia leva su analisi troppo dettagliate per pervenire ad una architettura
informativa già definitiva.
165
Successo
Approccio per
successive
sperimentazioni
Successo
Successo
Successo
Crescente
confidenza
Successo
-
Garantire il diritto di fare errori: si abbassa la soglia della resistenza se le
persone capiscono che possono sbagliare. Le persone saranno incoraggiate ad
esprimere idee e a cercare nuovi modi di lavorare quanto più saranno convinti di
essere protetti in caso di fallimento.
-
Introdurre gli obiettivi del progetto nel sistema premiante dei manager
così da motivare economicamente sul conseguimento dei risultati attesi.
-
Creare percorsi di carriera per i manager maggiormente aperti al progetto,
fornendo segnali evidenti del legame tra sviluppo individuale e raggiungimento degli
obiettivi del progetto.
5.6.6.
Considerazioni di sintesi
Lo sviluppo organizzativo è un fattore importante di successo per quei progetti che
richiedono un alto cambiamento.
L’obiettivo di un progetto informatico non è tuttavia quello di creare un clima di
partecipazione e di evitare di introdurre, per quanto possibile, elementi di turbolenza
nella struttura di potere. Esso deve raggiungere obiettivi tangibili rispettando i tempi e
all’interno dei costi preventivati.
166
Occorre quindi mettere nel conto un impatto significativo sulla dimensione emotiva e su
quella legata alla struttura di potere ed è necessario considerare il conflitto come un
elemento intrinseco nella realizzazione del progetto.
L’esperienza ha dimostrato come le vere variabili di successo siano
legate alla
determinazione e alla capacità di affrontare i problemi con ordine e con sufficiente
serenità così da ridurre o almeno gestire i momenti di tensione, che saranno sempre
presenti.
Il
conflitto è un fatto endemico ad un progetto informatico e va affrontato con un
atteggiamento di forte determinazione.
167
6. Allegati
6.1. Allegato 1 applicazione del metodo ad un caso
6.1.1.
Il Contesto
Al fine di chiarire meglio il procedimento da seguire è stato sviluppato un esempio.
Un Istituto Geriatrico gestisce un’attività di assistenza per gli anziani ( case protette,
centri diurni , residenze protette) e un ingente patrimonio immobiliare, dal quale trae i
redditi per supportare l’attività di assistenza.
L’Istituto sviluppa un volume di affari di circa 8 milioni di euro, di cui 3 milioni nel
settore dell’assistenza, con un capitale investito valutato nell’ordine di 100 milioni di
euro. Tra dipendenti e collaboratori l’Istituto occupa 100 persone, di cui 30 presso la
sede amministrativa e il restante personale impegnato nelle strutture dedicate
all’assistenza.
Le strutture dedicate all’assistenza sono quattro, collocate anche distanti dalla sede
amministrativa.
L’ Istituto ha operato in un contesto relativamente tranquillo per molti anni ma
recentemente sono in corso due profondi cambiamenti che avranno un impatto
rilevante sull’assetto complessivo dell’organizzazione:
-
una recente normativa regionale prevede la trasformazione dell’Istituto Geriatrico in
“Azienda Pubblica”; dotata di autonomia statutaria, gestionale, patrimoniale,
contabile e finanziaria ed operanti secondo criteri di efficienza, efficacia ed
economicità nonché nel rispetto del pareggio di bilancio;
-
l’apertura di due nuovi Centri di Servizio per gli anziani, che porteranno il numero
degli ospiti dagli attuali 70 a circa 400 con un incremento conseguente dei
dipendenti.
168
Aumenterà il numero dei Centri ( da 4 a 6) e crescerà il peso dell’attività dell’assistenza
sulle attività complessive dell’Istituto con riflessi sull’equilibrio finanziario complessivo.
La gestione immobiliare dovrà migliorare in termini di efficienza e di redditività per
supportare il prevedibile incremento delle perdite che deriverà dalla maggiore rilevanza
dell’attività di assistenza.
Si pone quindi il problema di avviare un processo di trasformazione dell’Istituto, che
deve riguardare anche i sistemi informativi. La situazione appare molto complessa in
quanto occorre tener conto di numerosi aspetti:
-
le istituzioni di riferimento dell’Ente ( Regione e Comune capoluogo) hanno
introdotto un prodotto ERP ( Sap) ed è possibile che richiedano in un prossimo
futuro che anche i principali fornitori adottino lo stesso programma;
-
si vorrebbe pervenire alla Certificazione di Qualità del Settore Assistenza, vista non
come un “fiore all’occhiello”, ma un’occasione per procedurizzare e documentare le
attività svolte, evidenziare gli scostamenti rispetto a quanto “promesso” con la Carta
dei Servizi e le Convenzioni con il Comune ed introdurre le necessarie azioni
correttive; è necessario passare da una gestione “ manuale” delle informazioni
dell’ospite ad una informatica così da collegarsi anche con le istituzioni di
riferimento;
-
è in atto l’introduzione del sistema di Contabilità Economica per pervenire alla
redazione di un Bilancio Economico ( con Stato Patrimoniale) abbandonando la
contabilità finanziaria, che gestisce solo le entrate e le uscite finanziarie.
In una situazione così complessa ed incerta , Il Direttore Generale decide di affidare una
consulenza ad un Esperto Informatico, che dovrà individuare le scelte più opportune da
portare avanti sulla base di una diagnosi dell’attuale stato delle infrastrutture
informatiche.
6.1.2.
Descrizione dell’architettura informatica
Nella sede dell’Istituto sono presenti 29 personal computer e 10 stampanti sotto una
moderna rete locale ethernet di tipologia a stella con 10/100 mbs di velocità. Il sistema
169
operativo di rete è Windows NT. In sede esiste un solo personal computer su cui è stata
abilitata una postazione internet.
I pc della sede sono interconnessi con due strutture aziendali, A e B, attraverso una
linea digitale dedicata ISDN. Tali strutture però possono scambiare files con la sede e
condividerne il servizio di posta elettronica ad una velocità relativamente bassa (max 64
kbs). La struttura A due pc in rete, altri 2 pc non connessi tra loro e su uno di essi si
effettuano delle connessioni remote con l’ Azienda Sanitaria Locale per velocizzare le
procedure di ottenimento dei risultati di analisi. La struttura B ha 2 pc che non sono in
rete tra loro. Una terza struttura, denominata C, ha 2 pc in rete locale ed una
stampante ma non ha ancora un collegamento con la sede.
Esistono due Server : un HP LH3 Netserver, che eroga ai suoi utenti un servizio di
condivisione directory, di posta elettronica interna, di condivisione stampanti di rete, di
sicurezza degli accessi; un server AS 400, che per scelta non dialoga con LH3, sul quale
gira un applicativo amministrativo ed è aperto a tutti i PC. Il back-up sui servers è
realizzato attraverso la rotazione quotidiana di supporti “ DAT”.
Il centralino è di nuova generazione, di tipo digitale e supporta 8 canali di
comunicazione ISDN.
L’architettura fisica è realizzata attraverso un moderno armadio di permutazione ed un
cablaggio strutturato che assieme permettono l’integrazione sia della trasmissione dei
dati, sia della fonia. Tutti i pc della sede, i relativi monitor ed i 2 servers sono stati
opportunamente alloggiati sotto gruppo di continuità.
L’antivirus è il Norton 2003 della Symantec ed è installato localmente su ogni pc ed
aggiornato tramite internet con una procedura di “ live update” dall’amministratore di
rete.
Le caratteristiche degli attuali applicativi gestionali sono riportati di seguito: essi non
sono collegati tra di loro in quanto mancano software di interfaccia:
-
Gestione del Personale ( rilevazione presenze e paghe) su sistema operativo WINNT
e fornitore A;
170
-
Contabilità ( ordini, finanziaria, contabilità economica e controllo di gestione) su
sistema operativo IBM e fornitore C;
-
Gestione Immobiliare ( sistema informatico dei dati catastali, territoriali ed
economici) su sistema operativo WIN 98 database nativo fornitore D;
-
Gestione documenti ( database per la protocollazione dei documenti ) su sistema
operativo WIN 98 fornitore E;
-
Gestione Lavori ( preventivazione a ricavi, contabilità lavori) su sistema operativo
WIN 98 fornitore F.
Attualmente è attivo un sistema di posta elettronica interna su supporto Microsoft
Outlook. Esiste un sistema di protocollazione informatica dei documenti in entrata e in
uscita dall’Ente. Non esiste un sito web internet e non sono state implementate
soluzioni intranet.
6.1.3.
Individuazione
delle
diverse
alternative
di
architettura ICT
L’analisi della situazione attuale delle dotazioni informatiche e di rete, nonché le
implicazioni delle trasformazioni in atto nel contesto esterno hanno condotto la direzione
aziendale a considerare come sia urgente intervenire sugli applicativi gestionali, le cui
caratteristiche dipartimentali non favoriscono l’integrazione aziendale. Inoltre occorre
aumentare la dotazione di pc delle strutture assistenziali così da permetterle di
migliorare le capacità di archiviazione ed elaborazione dei dati e di comunicazione verso
l’esterno. Anche la rete appare fortemente inadeguata e il suo potenziamento è una
condizione indispensabile per adeguare anche le infrastrutture di computer. Queste
considerazioni hanno condotto a dare i seguenti punteggi alle diverse componenti
dell’Architettura: 5 agli applicativi gestionali, 4 alle infrastrutture di computer e 3 a
quelle di rete. Gli elementi di office automation sono considerati di minore importanza e
hanno ricevuto quindi un punteggio pari ad 1.
Per quanto riguarda i criteri di valutazione, la direzione aziendale ha ritenuto che fosse
prioritario che la nuova Architettura rispondesse ai bisogni informativi dell’Ente in una
171
fase di complessa trasformazione e di crescita organizzativa. E’ stata attribuita, tuttavia,
una notevole importanza alla salvaguardia dell’attuale architettura, sia per non
disperdere investimenti realizzati nel passato che per non generare un salto eccessivo
nelle modalità di lavoro dell’Ente.
Si sono poi considerate tre possibili alternative di Architettura ICT:
-
la situazione attuale, che, ovviamente, non comporta particolari interventi, se non
per quanto riguarda la manutenzione dell’hardware e del software. L’azienda è
caratterizzata da applicativi dipartimentali, da una rete cablata limitata alla sede, che
non coinvolge gli stabilimenti, e da una reportistica in Excel;
-
l’Architettura A, che prevede l’introduzione di un Erp per integrare i processi
amministrativi, una rete wireless, un prodotto evoluto per la reportistica e la
realizzazione di un nuovo server con una rete stellare;
-
l’Architettura B, che prevede l’integrazione mediante interfacce degli applicativi
gestionali esistenti, una rete cablata e il passaggio di una reportistica in Access
rispetto a quella in Excel. Le infrastrutture di computer resterebbero come le attuali
in quanto non vengono introdotti nuovi applicativi che necessitano di un
potenziamento delle funzioni di elaborazione e di memorizzazione.
Di seguito viene descritto il procedimento per ciascuno dei fattori di valutazione da
considerare.
6.1.4.
Analisi del processo di valutazione
Rispondenza ai fabbisogni informativi e di rete
L’ Architettura A è quella che risponde maggiormente ai fabbisogni informativi, in
quanto prevede un applicativo Erp, un nuovo prodotto di reportistica e di conseguenza il
potenziamento del server. Tuttavia, le differenze rispetto all’Architettura B sono minime,
in quanto quest’ultima fornisce una soluzione più adeguata al tema della comunicazione
e permette comunque di conseguire risultati lusinghieri con l’utilizzo di interfaccia tra gli
attuali applicativi gestionali.
172
Componenti
Contenuti
Architettura attuale
a) importanza
Imfrastrutture computer
Infrastrutture di rete
Office automation
Applicativi gestionali
Totale
Soluzione
Architettura A
b) contributo
Architettura B
Carenze nel
server e nelle
4 memorie
Soluzione
Potenziati e
quindi adeguati
ai fabbisogni
2 informativi
Rete incompleta
3 perché limitata
Programmi di
1 base
Rete wireless
con un unico
2 punto di accesso
Potenziamento
2 per reportistica
Rete cablata
con unico
4 server
Programmi di
3 base
1 Erp
Integrati con
5 interfaccia
5 Dipartimentali
c) contributo
Soluzione
Rispondenza
a)* b)
attuale a)* c) A a)* d) B
d) contributo
Mantenimento
degli attuali
5 computer
3
8
20
12
5
6
12
15
2
2
3
2
3
5
21
25
60
15
44
Riduzione delle ridondanze
La tabella successiva riporta il confronto delle diverse alternative sotto il profilo delle
ridondanze tecnologiche. L’Architettura A conduce a ridurre la varietà delle tecnologie e
il numero delle dipendenze, in quanto è basata sulla scelta di un prodotto Erp.
Componenti
Contenuti
Architettura attuale
a) importanza
Soluzione
b) contributo
Architettura A
Soluzione
Infrastrutture di computer
Database Oracle
e database
4 proprietari
Infrastrutture di rete
Unico standard,
3 solo per la sede
Office automation
1 Più fornitori
4 Wi-fi e hiplan
Riduzione
numero dei
2 fornitori
Uno per ciascuno
5 degli applicativi
Unico fornitore
0 per gli applicativi
Applicativi gestionali
Totale
c) contributo
2 Unico data base
Architettura B
Soluzione
Database
Oracle e
database
5 proprietari
Rete cablata
con unico
2 server
3 Più fornitori
Molti fornitori
con un'unica
5 tecnologia
Rispondenza
a)* b)
attuale a)* c) A a)* d) B
d) contributo
2
8
20
8
5
12
6
15
1
2
3
1
3
0
22
25
54
15
39
Salvaguardia dell’indipendenza
l’Architettura attuale è la più rispondente a criteri di indipendenza, proprio perché le sue
caratteristiche comportano il maggiore numero di fornitori e di tecnologie. E’
interessante come le infrastrutture computer e l’office automation risultino le
componenti dell’Architettura maggiormente rispondenti al concetto di indipendenza, in
quanto, ovviamente, i fornitori sono facilmente sostituibili.
173
Componenti dell'Architettura
Contenuti
Architettura attuale
a) importanza
Soluzione
Architettura A
b) contributo
Soluzione
Architettura B
c) contributo
Soluzione
Elevato numero
4 di fornitori
Infrastrutture di rete
Elevato numero
4 di fornitori
Unico fornitore,
ma facilmente
3 sostituibile
due fornitori non
3 sostituibili
Elevato numero
4 di fornitori
Rete cablata
con unico
0 server
Office Automation
Elevato numero
1 di fornitori
Elevato numero
4 di fornitori
Elevato numero
4 di fornitori
Un unico
5 fornitore
Più fornitori ma
forte
dipendenza
dalle tecnologie
0 database
Infrastrutture Computer
Fornitore per ogni
5 applicativo
Applicativi gestionali
Totale
Rispondenza
a)* b)
attuale a)* c) A a)* d) B
d) contributo
4
16
16
16
1
9
0
3
4
4
4
4
3
25
54
0
20
15
38
Contributo all’integrazione
L’Architettura A è quella più rispondente ai criteri di integrazione, in quanto,
ovviamente, basata su un prodotto Erp. Se si fosse data meno importanza agli
applicativi gestionali, si poteva arrivare a conclusioni differenti, che privilegiavano, per
esempio, l’Architettura B, maggiormente concentrata sul problema della rete.
Componenti dell'Architettura
Contenuti
Infrastrutture computer
Infrastrurre di rete
Office automation
Applicativi gestionali
Totale
Architettura attuale
a) importanza
Soluzione
Computer con
caratteristiche
4 disomogenee
Architettura A
b) contributo
Soluzione
Architettura B
c) contributo
Potenziamento
0 server
5
3 Rete solo la sede
Dotazioni
1 disomogenee
2 Rete wireless
Revisione
0 programmi
3
Applicativi
5 dipartimentali
0 Erp
5
3
Soluzione
Come la
situazione
attuale
Rete cablata
con unico
server
Dotazioni
disomogenee
Integrazione
mediante
interfacce
Rispondenza
a)* b)
attuale a)* c) A a)* d) B
d) contributo
0
0
20
0
5
6
9
15
0
0
3
0
4
0
6
25
57
20
35
Consistenza con l’attuale architettura
L’applicazione del procedimento nell’esempio porta a concludere come l’Architettura B
fornisce comunque un punteggio elevato in termini di mantenimento dell’attuale
patrimonio informatico. E’ interessante osservare come l’attuale Architettura risulti
particolarmente rispondente, in quanto si dà per scontato che le infrastrutture di
computer e di office automation siano ancora adeguate, anche rispetto alle prospettive
di sviluppo aziendale.
174
Componenti dell'Architettura
Contenuti
Infrastrutture
Computer
Architettura attuale
a) importanza
4
Infrastrutture di
rete
3
Office Automation
1
Applicativi
gestionali
Totale
5
Soluzione
Architettura A
b) contributo Soluzione c) contributo
Revisione
del server
Computer con
per
caratteristiche
sostenere
disomogenee e
nuovi
obsoleti
4 applicativi
1
Adeguata per la
Abbandono
sede, ma non
della rete
estesa a tutta
cablata in
l'azienda
3 sede
1
Per la
reportistica
necessità di
Modesta ma
adeguata
2
5 intervento
Abbandono
attuali
Attuali
applicativi
5 applicativi
0
Architettura B
Soluzione
Rispondenza
a)* b)
d) contributo attuale a)* c) A a)* d) B
Allineamento
dei computer
3
16
4
12
Rete cablata
con unico
server
5
9
3
15
5
5
2
5
3
25
55
0
9
15
47
Access già
presente
Mantenimento
di alcuni
applicativi
175
Scalabilità
L’Architettura A richiede i cambiamenti più sostanziali nei requisiti tecnici del sistema,
ma è anche quella che appare la più adeguata in termini di scalabilità. Ovviamente
l’Architettura attuale risulta l’alternativa più inadeguata sotto questo punto di vista.
Componenti dell'Architettura
Contenuti
Infrastrutture
Computer
Architettura attuale
a) importanza
Soluzione
b) contributo
Soluzione
Adeguata
0 agli sviluppi
Perplessità
sulla
scalabilità
della rete
3 wireless
4 Poco scalabile
Adeguata per la
sede, ma non
estesa a tutta
3 l'azienda
Infrastrutture di
rete
Adeguata ma in
1 futuro critica
Office Automation
Applicativi
gestionali
Totale
Architettura A
Architettura B
c) contributo
Soluzione
Criticità sul
5 server
4 Scalabile
Adeguata
0 allo sviluppo
5 Poco scalabili
Rispondenza
a)* b)
d) contributo attuale a)* c) A a)* d) B
3
0
20
12
Rete cablata
con unico
3 server
5
9
9
15
Adeguata ma
5 in futuro critica
4
4
5
4
5 Poco scalabili
0
0
13
25
59
0
31
Flessibilità
L’Architettura attuale è la più rispondente rispetto alla flessibilità del modello di
business, in
quanto
si è tenuto conto dell’eventualità che l’azienda possa essere
oggetto di una trasformazione societaria e quindi mantenere l’attuale Architettura
significa ridurre l’eventuale perdita in termini di investimenti effettuati. Sarebbe stata
diversa la conclusione, se si fosse tenuto conto della flessibilità intesa come capacità di
dare risposte rispetto ai cambiamenti del mercato, in quanto , ovviamente,
un’architettura basata su applicativi dipartimentali non risulta la più efficace da questo
punto di vista. E’ pure interessante osservare come l’ alternativa attuale e quella B
risultino di fatto indifferenti, anche se caratterizzate da valutazioni totalmente differenti
sulle diverse componenti dell’architettura.
Componenti dell'Architettura
Contenuti
Architettura attuale
Infrastrutture Computer
Soluzione
Non si effettua
nessun
4 investimento
Infrastrutture di rete
Limitata solo alla
sede e flessibile
a cambiamenti
nell'assetto
3 produttivo
Office Automation
Applicativi gestionali
Totale
a) importanza
1 Indifferente
Possibile
abbandono
5 dell'investimento
b) contributo
Architettura A
Soluzione
Investimento sul
server e sui
5 computer
Massima
flessibilità con il
5 wireless
Investimento di
2 adeguamento
Elevato
5 investimento
c) contributo
Architettura B
Soluzione
Non si effettua
nessun
3 investimento
Rete cablata e
quindi
investimento
rigido ma
5 comunque utile
4 indifferente
Investimento
limitato
0 nell'interfaccia
Rispondenza
a)* b)
attuale a)* c) A a)* d) B
d) contributo
5
20
12
20
4
15
15
12
5
2
4
5
4
25
62
0
31
20
57
176
Coerenza
Si tratta di valutare l’allineamento o meno all’architettura prevalente nel settore
industriale di riferimento.
L’esempio evidenzia la validità dell’Architettura A,in quanto ha adottato le infrastrutture
e gli applicativi più in linea con quelli prevalenti nel settore.
Componenti dell'Architettura
Contenuti
Architettura attuale
a) importanza
Soluzione
Architettura A
b) contributo
Soluzione
Investimento sul
server e sui
0 computer
Infrastrutture di rete
Debolezza nelle
4 dotazioni
Adeguata per la
sede, ma non
estesa a tutta
3 l'azienda
Office Automation
1 Inadeguata
Massima
flessibilità con il
2 wireless
Adeguamento
0 rende adeguati
Applicativi gestionali
Totale
5 inadeguata
0 Allineati
Infrastrutture Computer
Architettura B
c) contributo
Soluzione
Rispondenza
a)* b)
attuale a)* c) A a)* d) B
d) contributo
Debolezza nelle
5 dotazioni
Massimo
investimento,
ma comunque
5 utile
4 Inaeaguata
Modesto
investimento di
5 integrazione
0
0
20
0
5
6
15
15
0
0
4
0
3
0
6
25
64
15
30
Costi di costruzione:
Nell’esempio, i costi di costruzione più elevati risultano quelli relativi all’Architettura A,
che richiede il maggiore investimento negli applicativi gestionali ( per l’acquisto di un
Erp) e nelle infrastrutture di computer per l’acquisto di un nuovo server.
Componenti dell'Architettura
Contenuti
Infrastrutture
Computer
Infrastrutture di
rete
Office Automation
Applicativi
gestionali
Totale
Architettura attuale
a) importanza
Soluzione
Non si effettua
nessun
4 investimento
Architettura A
b) contributo
Architettura B
Nessun
3 investimento
Nessun
1 investimento
Soluzione
c) contributo
Investimento sul
server e sui
5 computer
2
Investimenti nelle
dotazioni
5 wireless
3
Necessario un
5 adeguamento
4
Nessun
5 investimento
Massimo
5 investimento
Soluzione
Investimento
sui computer
Cablatura
Nessun
investimento
Modesto
investimento di
0 integrazione
Rispondenza
a)* b)
d) contributo attuale a)* c) A a)* d) B
3
20
8
12
0
15
9
0
5
5
4
5
4
25
65
0
21
20
37
I costi di avviamento:
Le valutazioni non si discostano sostanzialmente dai giudizi relativi ai costi di
costruzione, con l’unica avvertenza che i valori assoluti, in moneta, possono risultare
177
inferiori o superiori al costo di costruzione in relazione alle attività di personalizzazione e
di assistenza richieste e/o necessarie.
Componenti dell'Architettura
Contenuti
Infrastrutture
Computer
Infrastrutture di
rete
Architettura attuale
a) importanza
Soluzione
b) contributo
1 nessun costo
Soluzione
Costi di
5 installazione
Costi di
5 installazione
Costi di
5 installazione
5 Nessun costo
Costi di
personalizzazion
5 e/addestramento
4 Nessun costo
3 Nessun costo
Office Automation
Applicativi
gestionali
Totale
Architettura A
Architettura B
c) contributo
Soluzione
Costi di
2 installazione
Costi di
3 installazione
Costi di
4 installazione
Rispondenza
a)* b)
d) contributo attuale a)* c) A a)* d) B
Costi di
0 addestramento
4
20
8
16
2
15
9
6
5
5
4
5
2
25
65
0
21
10
37
I costi indotti
L’Architettura IT attuale risulta penalizzata dai costi di manutenzione/adeguamento, che
saranno crescenti in funzione della progressiva obsolescenza dell’hardware e del
software.
Componenti dell'Architettura
Contenuti
Infrastrutture
Computer
Infrastrutture di
rete
Architettura attuale
a) importanza
4
3
Office Automation
Applicativi
gestionali
Totale
1
5
Soluzione
Costi di
manutenzione
Costi di
manutenzione
Costi di
manutenzione
Costi di
manutenzione
Architettura A
b) contributo
3
3
3
2
Soluzione
Costi di
assistenza
Costi di
assistenza
Costi di
assistenza
Costi di
assistenza
Architettura B
c) contributo
3
3
3
2
Soluzione
Costi di
assistenza
Costi degli
spazi
Costi di
assistenza
Costi di
assistenza
Rispondenza
a)* b)
d) contributo attuale a)* c) A a)* d) B
3
12
12
12
2
9
9
6
3
3
3
3
3
10
34
10
34
15
36
I costi nascosti
L’Architettura IT attuale risulti particolarmente penalizzata dalla perdita di produttività, e
quindi dai costi nascosti, connessi all’utilizzo di tecnologie ormai inadeguate.
Componenti dell'Architettura
Contenuti
Infrastrutture
Computer
Infrastrutture di
rete
Office Automation
Applicativi
gestionali
Totale
Architettura attuale
a) importanza
4
3
1
5
Soluzione
Perdita di
produttività
Perdita di
produttività
Perdita di
produttività
Perdita di
produttività
Architettura A
b) contributo
3
1
3
2
Soluzione
Perdita di
produttività
Perdita di
produttività
Perdita di
produttività
Perdita di
produttività
Architettura B
c) contributo
4
5
3
3
Soluzione
Perdita di
produttività
Perdita di
produttività
Perdita di
produttività
Perdita di
produttività
Rispondenza
a)* b)
d) contributo attuale a)* c) A a)* d) B
4
12
16
16
5
3
15
15
3
3
3
3
4
10
28
15
49
20
54
178
6.1.5.
Valutazione di sintesi delle diverse alternative di
architettura IT
La soluzione più adeguata è costituita dall’Architettura A, benché il suo scarto rispetto
all’architettura B sia minimo. L’Architettura A risulta penalizzata dall’elevato costo di
investimento, ma apporta benefici significativi rispetto alle altre soluzioni.
Criteri di valutazione
Contenuti
Fabbisogni informativi
Ridondanze tecnologiche
Livello di indipendenza
Contributo all'integrazione
Totale Benefici
Attuale architettura
Scalabilità
Flessibilità
Coerenza
Totale Rischi
Costi di Costruzione
Costi di Avviamento
Costi indotti
Costi Nascosti
Totale Costi
Architettura attuale
a) importanza
30,00%
10,00%
0,00%
10,00%
50,00%
15,00%
10,00%
5,00%
0,00%
30,00%
10,00%
5,00%
5,00%
0,00%
20,00%
Totale
100,00%
Architettura A
b) punteggio
c) punteggio
31
27
31
6
95,00
55
13
62
6
136,00
65
65
34
28
192,00
62
58
20
57
197,00
9
59
31
64
163,00
21
21
34
49
125,00
423,00
485,00
Architettura B
Valutazione
a)* b)
attuale a)* c) A a)* d) B
d) punteggio
36
9,3
18,6
10,8
38
2,7
5,8
3,8
38
0,0
0,0
0,0
35
0,6
5,7
3,5
147,00
12,60 30,10
18,10
47
8,3
1,4
7,1
31
1,3
5,9
3,1
57
3,1
1,6
2,9
30
0,0
0,0
0,0
165,00
12,65
8,80
13,00
37
6,5
2,1
3,7
37
3,3
1,1
1,9
36
1,7
1,7
1,8
54
0,0
0,0
0,0
164,00
11,45
4,85
7,35
476,00
36,70 43,75
38,45
6.2. Allegato 1 Analisi preventivi di controllo di
gestione
6.2.1.
Premessa
Il caso viene sviluppato con riferimento all’azienda che è stato oggetto della valutazione
delle diverse architetture informatiche, di cui al paragrafo 6.1.
Il sistema di controllo di gestione ad oggi implementato è stato costruito in via
sperimentale sull’applicativo Excel, che se da un lato è di facile utilizzo ed estremamente
familiare, dall’altro presenta una serie di limiti che hanno spinto l’Ufficio Economia e
Finanza a cercare soluzioni più idonee alla crescente complessità gestionale dell’Ente e
alla fase di sviluppo che sta vivendo.
L’attuale modello di controllo di gestione in Excel consente di ottenere informazioni di
179
contabilità analitica (disgiuntamente dagli applicativi di contabilità economica e
finanziaria). Il modello è piuttosto complesso ed è basato su una prima suddivisione
dell’Ente in settori e su una successiva suddivisione in aree e centri di costo/risultato
che accolgono diverse tipologie di costi/ricavi (diretti, indiretti di struttura, indiretti di
area, indiretti di settore e generali). Il modello contiene anche le tavole per il
ribaltamento dei costi indiretti e generali sui centri di risultato sia a livello di preventivo
che a livello di consuntivo.
L’applicativo Excel costituisce un ottimo strumento per la gestione di una fase
sperimentale che tratta pochi e semplici dati ma altrettanto non può dirsi in presenza
del livello di complessità gestionale che caratterizza l’Ente.
I limiti del modello in Excel sono legati alla sua natura di foglio di calcolo, all’alta
probabilità di commettere errori di imputazione, alla facilità di manomissione dei
documenti, al tempo impiegato per la sua gestione e manutenzione e all’impossibilità di
lavorare in modalità multiutente.
Le caratteristiche di funzionamento di questo applicativo implicano inoltre:
-
la revisione di tutte le formule di calcolo ogni qualvolta venga inserito un nuovo
elemento (può essere per es. un nuovo centro di costo ma anche semplicemente
una nuova voce di costo o il cambiamento di un criterio di ribaltamento);
-
la necessità di inserire il dato elementare n volte;
-
la difficoltà estrema di utilizzare i dati elementari per effettuare semplici
estrapolazioni e simulazioni.
-
6.2.2.
Analisi delle offerte
L’Ufficio Economia e Finanza ha contattato cinque società informatiche (CBA
Informatica, Imola Informatica, Dieci Dieci Multimedia, Philosoft e Nsi), ha sottoposto
loro le proprie esigenze e richiesto una proposta commerciale dettagliata.
CBA Informatica non ha ritenuto di effettuare alcuna offerta; le altre società hanno
esperienza nella programmazione e produzione di sistemi informativi ma tra queste solo
Philosoft sembra avere una specifica referenza nell’ambito del controllo di gestione.
Philosoft è anche l’unica società ad avere la propria sede fuori dai confini della regione
180
mentre le altre hanno la propria sede nel territorio della provincia di Bologna.
Imola Informatica, Dieci Dieci Multimedia e Nsi sono società che propongono un
prodotto di programmazione mentre Philosoft propone un prodotto commerciale
distribuito dalla Cognos Italia.
Le ditte incontrate, tranne CBA, hanno fornito all’Ufficio Economia e Finanza i preventivi
nei tempi previsti rispondendo ai requisiti minimi richiesti e funzionali alle esigenze
dell’Ente:
-
garantire un applicativo più gestibile e sicuro dell’attuale mantenendo al
contempo i risultati raggiunti in termini di rendicontazione (e quindi in grado di
fornire almeno le medesime informazioni strutturate);
-
offrire un prodotto flessibile dal lato della programmazione e gestione per
consentire per es. di modificarne agevolmente i parametri (per es. criteri di
ribaltamento, centri di costo, ecc.) o di effettuare simulazioni/estrazione di dati.
Tali criteri minimi unitamente ad altri fattori (tecnologia, prezzo, assistenza post-vendita
e manutenzione, reportistica, accessibilità al sistema e referenze specifiche),
costituiscono la base per la valutazione delle offerte pervenute dalle ditte incontrate.
Si devono considerare i seguenti vantaggi che deriverebbero dall’acquisto di un
applicativo da qualunque delle ditte:
-
riduzione del carico di lavoro stimabile in 180 ore uomo / anno per l’inserimento
e il controllo dei dati;
-
azzeramento degli errori di calcolo e di riproduzione delle formule;
-
azzeramento errori per l’inserimento di nuove voci di costo e ricavo o per
l’inserimento di nuovi centri di costo;
-
risparmio di tempo correlato alla gestione degli errori e all’inserimento di nuovi
centri di costo;
-
creazione di modelli di report adattabili alle esigenze di diverse tipologie di
interlocutori;
-
autonomia dell’Ufficio Economia e Finanza nella gestione dello strumento
informatico che agirebbe in qualità di amministratore di sistema.
181
Nella tabella seguente vengono riportate sinteticamente le caratteristiche emerse
dall’analisi dei preventivi.
Tecnologia
Accessibilità
Reportistica
Prezzo
Imola informatica (1)
Tecnologia Java utilizzabile via browser a
partire da componenti open source;
database MySQL (prevista compatibilità
anche con i maggiori database
commerciali);
requisiti minimi: JDK almeno di livello
1.4;
proprietà del codice applicativo del
cliente;
Dieci Dieci Multimedia (2)
Interfaccia web; l'applicazione non
necessita di plug-in
ambiente di sviluppo open source: web
server APACHE in ambiente PHP su
database Mysql;
sistema installabile sia su piattaforma
Linux che Microsoft.
Interfaccia pura html o applet Java
(piuttosto simile alle tabelle Excel);
Immissione dati in multiutenza con
autenticazione e gestione diversificata dei
profili utenti
Interfaccia utente identico a quello in uso Sistema multiutente con accesso attraverso
attualmente (tabelle Excel) disponibilie in profilo utente caratterizzato da possibilità
operative differenti
rete; gli utenti possono lavorare
contemporaneamente.
Reportistica fornita da Cognos; il
controller può a piacimento creare nuove
interrogazioni, stampe ed estrapolazioni.
Reportistica da programmare (non c’è
libertà di creare in autonomia un report)
disponibile in formato html, pdf ed Excel;
compresa nel prezzo la reportistica
discussa in sede di analisi e corrispondente
in linea di massima all'attuale; nuove
estrazioni/stampe mediamente complesse
sono quotate intorno a € 300 -400, il costo
effettivo valutato in termini di ore/uomo di
un programmatore ovvero € 40,00 / ora.
Non sono previsti costi di acquisto
software e licenze (essendo sistema open
source);
€ 42.000,00 (+IVA 20%) = €
50.400.000,00; attività di formazione non
specificata
Costo del software "Cognos Planning
Administrator" comprensivo di Add-in
Excel: € 8.835,00
Canone manutenzione: € 2.110,00
Servizio di consulenza: € 9.000,00
Spese di trasferta forfetarie: € 1.200,00
Totale
€ 21.145,00
Totale (+IVA 20%) € 25.374,00
+ alcune giorante di formazione
all'amministratore del processo
Costo software: € 13.200,00
Costo licenza per il sistema di generazione
di reportistica "Winward Report" per ogni
sistema server: €
600,00
Totale
€ 13.800,00
Totale (+IVA 20%) € 16.560,00
Garanzia: Canone di manutenzione
obbligatorio il 1° anno comprensivo di
nuove versioni e sistemazione errori del
software, helpline telefonico: € 2.110,00;
Interventi on-site successive al riesame
del progetto € 700,00 a giornata e
rimborso spese trasferta a piè di lista.
Garanzia: 12 mesi data consegna per errori
e disfunzioni dell'applicazione; interventi
di manutenzione migliorativa o di
formazione sono quotati a € 40,00 /ora
uomo (è possibile valutare un contratto a
canone definendo con precisione interventi
e servizi ricompresi). La manutenzione
prevede l'aggiornamento della piattaforma
e del sistema operativo che compete ai
tecnici che si occupano della rete interna
(eventualmente formati in fase di
installazione) e il back-up periodico dei
dati.
Esperienze di progettazione specifiche in
prodotti di controllo di gestione
Non specifiche - specializzato in
applicazioni software di tipo Legacy basate
su database relazionali per la gestione dei
processi
Non sono previsti costi di acquisto
software e licenze (essendo sistema open
source); € 16.000,00 (+IVA 20%) = €
19.200,00; due giornate per il training
degli operatori che agiranno come
amministratori
Garanzia di 1 anno sul software dalla
consegna con supporto off-site; assistenza
dopo il primo anno € 3.500,00 (+IVA
20%) = € 4.200,00; interventi on-site e
interventi evolutivo del software € 300,00
a giornata (+IVA 20% = € 360,00). La
manutenzione del sistema spetta al
fornitore che si occupa della rete interna.
Referenze
specifiche
Non specifiche - specializzato in gestione Non specifiche - specializzato nella
di grossi progetti di ingegnerizzazione
progettazione di siti e portali internet
informatica (Unicredito, BPM,
Bancaintesa, Sogei, Vodafone, CGIL
Emilia romagan, etc.)
Sì
Si
Tempi
Nsi (4)
Sistema software modulare basato su
database relazionale (applicazione puro
web non necessita plug-in); interfaccia
web
sistema implementato in tecnologia Java 2
Enterprise Edition
piattaforma Linux e Windows 2000
prodotto di proprietà condivisa tra NSI e
Opera Pia; codice sorgente a disposizione
gratuita per 12 mesi (durata garanzia)
Interfaccia utente identico a quello in uso
attualmente (tabelle Excel); Sistema
centralizzato di accesso attraverso privilegi
in modalità multiutente (utilizzo
contemporaneo di più utenti anche con
diverse modalità operative
contemporanee).
Reportistica in formato Excel con gestione Reportistica da programmare (non c’è
autonoma delle opzioni di generazione
libertà di creare in autonomia un report)
foglio; la reportistica è altamente
disponibile in formato html, pdf ed Excel;
personalizzabile senza interventi.
compresa nel prezzo la reportistica
discussa in sede di analisi e corrispondente
in linea di massima all'attuale; ulteriori
estrazioni sono valutate in ore uomo a €
45,00 /ora.
Servizi di
assistenza post
vendita e
manutenzione del
sistema
Integrazione
Philosoft (3)
Prodotto commerciale di Business
Intelligence “Cognos Planning” che
consente il mantenimento di interfaccia
Excel. Il prodotto dispone già di alcune
funzionalità di base quali ad es.
l'intelligenza finanziaria; il pacchetto
software non necessita di scrittura di
codice informatico ed è quindi gestibile
nell'evoluzione dalla funzione interna di
controllo di gestione.
Garanzia 1 anno dalla consegna per il solo
software (bachi e disfunzioni del sistema);
interventi di modifica di funzionalità e/o di
manutenzione migliorativa sono quotati a
€ 45,00 /ora uomo (è possibile valutare un
contratto a canone definendo con
precisione interventi e servizi ricompresi).
Manutenzione semplice: richiede solo la
conoscenza di base dell'ambiente di
sviluppo (PHP e MySQL). La prevalente
attività di manutenzione è da intendersi
come backuppaggio periodico dei dati
contenuti nel Data base.
+ 1 giornata formativa per amministratore
software compresa
Codice sorgente a disposizione per il
periodo di garanzia
Sì - da valutarsi in sede di analisi ma
Si
normalmente quantificabili in 2/3 giorni.
Analisi, sviluppo e test nel periodo ottobre- 120 giorni totali (non sono specificati i
Un mese e mezzo - 1gg di analisi; alcune 100 giorni
dicembre 2005
tempi relativamente alle varie fasi in cui
giornate di impostazione/verifica; 4 giorni
interviene personale dell’Opera Pia –
di caricamento dati storici e rilascio in
progettazione di dettaglio con supporto del produzione; 1 giorno training e 2 giorni
personale, valutazione del prototipo,
affiancamento
collaudo prodotto)
182
6.2.3.
Analisi dei preventivi
1 Fase
L’analisi approfondita dei preventivi inoltrati dalle ditte contattate evidenzia che tutte le
società rispondono ai requisiti minimi richiesti fornendo soluzioni connaturate alla
tecnologia utilizzata. Nessuna ditta offre formazione agli utilizzatori finali, in quanto
l’interfaccia utente proposta da tutti i fornitori rimane pressoché identica a quella
attualmente in uso e se necessaria sarà comunque a carico dell’Ufficio Economia e
Finanza.
Per questo motivo si è ritenuto, sentito anche il parere dell’ing. De Sario, di assurgere la
tecnologia, il prezzo, la garanzia e servizi di assistenza post-vendita a parametri
fondamentali per effettuare la scelta.
Considerata l’estrema chiarezza in termini di risultati che si intendono raggiungere
attraverso l’utilizzo del prodotto informatico, il consulente interno ha fornito una serie
di elementi a supporto della tecnologia open source che presenterebbe i seguenti
vantaggi:
-
assenza di costi di licenze;
-
prodotto di proprietà dell’Ente;
-
prodotto non compilato ma completamente programmabile;
-
sistema di tipo client-server su web (che permette di non effettuare installazioni
su PC ma direttamente su server).
Le tecnologie che non sono open source operano in ambiente Microsoft con tutti i limiti
tra i quali uno dei più rilevanti è la necessità di installare la parte client su tutti i PC (con
le problematiche connesse in caso per es. di modifiche al programma) oltre alla
necessità di pagare le licenze d’uso.
Il consulente esterno ritiene invece che le soluzioni open source possono essere
interessanti sotto il profilo propriamente tecnologico, tuttavia aprono una serie di
problemi in funzione dell’evoluzione futura e di una scalabilità/integrabilità del prodotto.
Per questo motivo ritiene più intelligente anche se più costoso scegliere un data base
commerciale.
183
E’ naturale che optare per l’una o l’altra scelta tecnologica non è indifferente ai fini della
valutazione per la quale si sono individuati il punteggio (da 0 a 5 per ogni fattore di
valutazione) e la modalità di calcolo del risultato (somma del punteggio di ogni fattore
di valutazione ponderato dal peso percentuale attribuito ad ogni fattore di valutazione).
Nella tabella seguente sono riportati i fattori di valutazione con il relativo peso
percentuale ai fini della valutazione dei preventivi.
Fattori di valutazione
Peso % dei
fattori
Tecnologia
Prezzo
Accessibilità
20%
20%
10%
Assistenza post-vendita
e manutenzione
25%
Interrogazioni e
reportistica
Integrazione
Tempi
Referenze specifiche
Totale
10%
5%
5%
5%
100%
2 Fase
In breve, la tecnologia open source appariva particolarmente appetibile finché era
garantita la presenza di una figura tecnica di riferimento interna. Il venire meno di
questa figura ha spinto l’Ufficio Economia e Finanza ad entrare nel merito anche di
questioni squisitamente tecniche ed informatiche invitando le ditte a fornire nuovi
elementi di valutazione. Inoltre, l’Ufficio si è avvalso della consulenza del nuovo tecnico
informatico che alla luce degli ultimi problemi sorti relativamente al sistema informativo
dell’Ente ha rivisto il giudizio del precedente tecnico che non intravedeva ostacoli di
natura tecnica relativamente ai prodotti offerti dalle ditta contattate.
E’ opinione del nuovo esperto che l’attuale sistema informativo non supporti i prodotti
offerti da Imola Informatica, Dieci Dieci Multimedia e NSI (vedi lettera allegata). Ciò
184
rende di fatto inutile procedere con la valutazione dei singoli preventivi dato che l’unico
prodotto che è tecnicamente possibile installare è quello offerto da Philosoft che, a
parere dell’esperto, presenta tuttavia:
-
una tecnologia obsoleta;
-
l’obbligatorietà di installazione su ogni client di un programma per l’esecuzione;
-
elementi minimi di configurazione: Windows 98 e Office 2000
-
data base proprietario (e non su SQL)
Tali elementi che potrebbero rendere poco appetibile il prodotto perché caratterizzato
già oggi da elementi tecnologicamente obsoleti non devono tuttavia ostacolare una
lucida riflessione rispetto alle reali esigenze dell’Ufficio:
-
l’Ufficio abbisogna di uno strumento affidabile e semplice che non necessita ad
oggi di specifiche tecniche avanzate;
-
considerata la fase di incertezza che sta vivendo l’Ente e la forte probabilità che
si pervenga al nuovo sistema contabile non prima del 2007 si ritiene congruo
l’investimento di poco più di € 25.000,00 che risulterebbe pienamente
ammortizzato nell’arco di un triennio/quadriennio;
-
in questo arco temporale si può godere di vantaggi che derivano dalla sicurezza
dei dati prodotti e dalle risorse risparmiate ed impiegate per effettuare
sperimentazioni e altre attività produttive;
-
la possibilità di effettuare simulazioni di scenari diversi al cambiare di parametri
(conti economici prospettici basati su diverse ipotesi di costi e ricavi – oggi non
attuabile con gli strumenti a disposizione se non impiegando notevoli risorse in
termini ore uomo).
Ciò premesso si propone di acquistare il software realizzato dalla ditta Philosoft con
l’intento di dedicare il tempo e le risorse che si renderanno disponibili alla ricerca di
soluzioni tecnologicamente più avanzate ed in linea con le future disposizioni normative
e contabili fermo restando la necessità di procedere all’adeguamento dell’attrezzatura
informatica attualmente in uso.
185
6.3. Allegato 2 Documenti di offerta e di contratto
6.3.1.
Documento
di
definizione
delle
specifiche
funzionali
Obiettivo del documento
Il documento di definizione delle specifiche funzionali ha la finalità di identificare le
funzionalità richieste al software. L’esempio, che viene riportato, riguarda un prodotto di
reportistica di Controllo di Gestione.
Struttura del documento
Obiettivo del Progetto
L’obiettivo del progetto è quello di realizzare un sistema informativo in grado di
supportare i seguenti processi:
•
Acquisizione dati consuntivi di base (ricavi e costi per Centri di Costo) estratti dal
programma di contabilità
•
Acquisizione dati previsionali attraverso interfacce distribuibili ai Direttori
•
Elaborazione dei ribaltamenti tra Centri di Costo
•
Elaborazione indicatori di efficacia ed efficienza
•
Produzione di prospetti di sintesi
•
Sistemi gestionali
Gli ambienti gestionali di interesse sono:
Modulo di Contabilità Finanziaria
Le entrate e le uscite sono registrate su Capitoli di Spesa/Entrata (circa 800-1.000)
aggregati in Centri di Responsabilità (indicati nel seguito con CdRF). I CdRF sono circa
30.
186
Modulo di Contabilità Generale
Il passaggio tra Contabilità Finanziaria e Contabilità Generale è fatto con procedure
automatiche.
Modulo di Contabilità Analitica
Le registrazioni vengono completate manualmente attribuendo il Centro di Costo (CdC).
I Conti di Analitica hanno una corrispondenza 1:1 coi Conti di Generale. Nel passaggio
Finanziatia-Generale-Analitica vengono mantenute le informazioni del Capitolo di
Spesa/Entrata. I Capitoli di Spesa/Entrata fanno sempre riferimento ad un solo Conto
mentre possono essere imputati suddividendoli su più CdC.
Durante l’anno possono esserci nuovi stanziamenti o modifiche a quelli già approvati
con variazioni in aggiunta o diminuzione degli importi di un capitolo di spesa/entrata.
Queste variazioni possono essere numerose.
Programma di Gestione del Personale
Gestisce i dati del personale. Il responsabile del Personale estrae i dati a livello di
matricola in un foglio Excel con tutte le voci. Questo foglio è completato dal CdG con il
CdC di ogni risorsa, totalizzando poi le voci per CdC e producendo un file per alimentare
le relative voci sul programma di contabilità.
Per i Co.Co.Co arrivano al CdG le notule in formato cartaceo. Ogni risorsa è già
assegnata ad un capitolo di spesa/entrata. Il CdG inserisce i dati in un foglio di Excel già
accorpati per CdC e accoda i dati al file con il Personale da inviare al programma di
contabilità.
Informazioni gestite
Di seguito vengono descritte le tipologie di informazioni da gestire nel modello.
Centri di Costo
I Centri di Costo sono enti sui quali vengono attribuite in contabilità analitica entrate e
uscite. I CdC vengono raggruppati secondo tre diverse logiche:
Settore (18) Area (5) CdC (200)
E’ la logica di tipo organizzativo e rispecchia quindi le diverse attività e responsabilità.
Stakeholder CdC
187
Utilizzata per identificare i portatori d interessi nei confronti dell’ente (es.Adolescenza,
Ambiente, Disabili, Industria, ecc.)
Tipologia CdC
È una classificazione che serve in particolare per i ribaltamenti. Le tipologie sono:
10 = CdC Istituzionali – caratteristici dell’ente
20 = CdC Produttivi – erogatori di un servizio
30 = CdC di Supporto (28) – al servizio di tutti gli altri CdC
40 = CdC di Investimento
50 = CdC Comuni (o di Area o di Settore) – al servizio degli altri CdC di quell’Area
o di quel Settore
Capitoli di spesa/entrata
Rappresentano una disaggregazione dei conti e costituiscono il raccordo tra visione
Finanziaria e visione Gestionale. Ogni capitolo di spesa/entrata è associato ad un solo
conto.
Vengono raggruppati in:
FunzioneServizioCentri di ResponsabilitàCapitoli di Spesa/Entrata
Mentre ogni CdC di analitica è associato ad un unico Servizio, non c’è univocità di
corrispondenza tra CdC e CdRF.
Periodi
Attualmente i dati sono a livello di quadrimestre, mentre saranno gestiti i trimestri.
Versioni
È da prevedere la gestione di:
stima a finire
anno precedente
consuntivo
budget
188
2 riprevisioni trimestrali
Anni
Su dati riepilogativi avere la possibilità di confronto con 5 anni in linea. I dati di dettaglio
saranno archiviati separatamente per anno.
Piano dei conti
Vengono gestite circa 130 voci, raggruppate in voci sintetiche. Di seguito il dettaglio dei
conti e le voci di sintesi.
A livello di CdG non tutti i conti sono gestiti. Alcuni conti, ad esempio quelli del
personale, gestiti extra contabilmente non sono movimentati tutti. Verrà quindi gestita
una matrice in cui specificare le voci utilizzate.
Per ogni Conto / CdC verrà associato l’Ufficio Competente in modo che sia esplicitata la
responsabilità di quella voce di spesa/entrata.
Provenienza Costi
Per avere la completa rintracciabilità dei ribaltamenti, si terranno distinti i costi/ricavi
propri dei CdC da quelli ricevuti dalle fasi di ribaltamento; si gestirà una dimensione
specifica con i seguenti elementi:
Diretti
Comuni di Area
Comuni di Settore
di Supporto
Totale
La somma dei Diretti + Comuni di Area + Comuni di Settore viene denominata Costi
Governabili ed è utilizzata per il calcolo degli Indicatori unitamente ai Costi Totali.
Indicatori
Gli indicatori hanno attualmente una gestione completamente manuale in Excel. Sono
suddivisi in:
189
Indicatori di efficienza: misurano il costo delle prestazioni caratteristiche di un servizio
rapportato ad un indicatore significativo del volume di attività ed esprime quindi il
rapporto tra risorse impiegate e risultato ottenuto
Indicatori di efficacia: misurano la capacità dell’ente di soddisfare certi bisogni della
collettività in termini di rilevanza e misurano lo scostamento rispetto al risultato atteso
Gli indicatori di base sono circa 100 e sono specifici di settore con il livello di dettaglio di
CdC.
Flussi ed elaborazioni
Flussi
Fogli di Budget
Excel
Excel
3.Budget
e riprev.
5.Reporting
2. Personale per
Matricola
6.Ribaltamenti
7.Inserimento Indicatori
Analisi
Data Base
4.Bilancio previsionale
SAEP
Reporting e Analisi
Finanziaria
Completamento
manuale
Personale
1.Costi/ricavi per
CdC, Conto, CdRF, Capitolo
SQL Access Analitica
Generale
Automatico
Excel
Flussi interni al sistema
Flussi esterni al sistema
Acquisizione Consuntivi Costi e Ricavi
I consuntivi vengono acquisiti dal programma di contabilità col seguente dettaglio:
CdC
Conto (fattore produttivo)
Mese
CdRF
Capitolo
190
I dati saranno estratti in automatico dal Sistema di programma di contabilità con un
tracciato di file .txt. Non saranno caricati i conti relativi al Personale, che possibilmente
dovranno essere esclusi dal file.
Acquisizione Costi del Personale
I Costi del Personale sono estratti dalla Funzione Personale dal programma di gestione
del personale su un foglio Excel con il dettaglio Matricola, Voce, Mese. Tale foglio sarà
mappato in un formato acquisibile dal Data Base. In Data Base questi dati saranno
completati in automatico con l’informazione del CdC (con la gestione di una tabella che
associa ogni Matricola al CdC, eventualmente specificando % di attribuzione nel caso di
più CdC). Contrariamente ad oggi, i dati così completati NON verranno inviati al
programma di contabilità, in quanto l’elaborazione è semi-automatica e della durata di 1
gg.
Acquisizione Budget e Riprevisioni
Il Budget e le Riprevisioni saranno acquisite tramite fogli Excel direttamente collegabili
al Data base e distribuibili ai diversi responsabili che potranno inserire i dati in modalità
off-line.
I dati verranno inviati al programma di contabilità per il caricamento in contabilità
finanziaria per capitolo di spesa/entrata.
Acquisizione Bilancio previsionale
Dal programma di Finanziaria saranno estratti i dati di bilancio previsionale per Capitolo,
con le seguenti informazioni:
-
Capitolo
-
Entrata/Spesa
-
Importo Previsione
-
Esercizio
-
Mese
-
Importo Variazione
-
Esercizio (Variazione)
191
-
Mese (Variazione)
-
Importo Definitivo
-
Residui
Reporting
I report da distribuire agli utenti saranno preparati in Excel direttamente collegati al
Data base.
Ribaltamenti
Attualmente la logica dei ribaltamenti è la seguente:
Fase 1: Ribaltamento CdC Comuni di Area sui CdC della medesima Area
Fase 2: Ribaltamento CdC Comuni di Settore sui CdC del medesimo Settore
Fase 3: Ribaltamento CdC di Supporto su tutti i CdC (tipo 10,20,40)
Il driver è il Totale dei Costi, che per le Fasi 2 e 3 include anche i Costi derivanti dal
ribaltamento della fase precedente.
Per potere col tempo affinare le logiche di ribaltamento, sia in termini di CdC riceventi
che di driver, verrà gestita una matrice per associare dinamicamente CdC cedente-CdC
ricevente-driver. Potenzialmente qualsiasi voce di dettaglio o di sintesi, o anche degli
indicatori non economici, potranno essere utilizzati come driver.
Inserimento Consuntivi Indicatori
Gli indicatori saranno inseriti direttamente in Database, mentre i report verranno
prodotti in Excel.
Output del sistema
Gli output del sistema saranno:
-
conti economici per CdC
-
prospetti finanziari per capitolo/funzione
192
Gestendo il dettaglio di capitolo di spesa/entrata sarà infatti possibile riconciliare la
visione economica con quella finanziaria.
Simulazioni
Sarà predisposto un ambiente dove il CdG può imputare dei dati per effettuare
simulazioni. In particolare la simulazione potrà essere utile per vedere l’impatto di
variazioni sui capitoli di spesa/entrata.
6.3.2.
Documento di Disciplinare tecnico
Obiettivo del documento
Il documento di disciplinare tecnico ha la finalità di definire contrattualmente le
condizioni della fornitura ed in particolare l’oggetto, gli output, il prezzo e le condizioni
di assistenza. L’esempio, che viene riportato, riguarda un prodotto di reportistica di
Controllo di Gestione.
Struttura del documento
OGGETTO DELLA FORNITURA
Nell’ambito dell’implementazione di una contabilità economica basata su Centri di Costo
(Contabilità Analitica), è partito nel Febbraio 2004 un progetto che ha permesso ad
oggi:
-
la definizione di un modello di rappresentazione delle attività tipiche del Comune
-
la parametrizzazione dell’esistente sistema informatico amministrativo per la
raccolta dei dati di base (Ricavi e Costi per Centro di Costo) e il calcolo delle
successive allocazioni.
-
l’avvio delle relative procedure organizzative per l’acquisizione dei dati e la
gestione in esercizio di tutto il sistema.
-
l’avvio di una sperimentazione per circa 6 mesi (2004)
-
l’esercizio in produzione del sistema per tutto il 2005 e per metà del 2006
193
Per il completamento del progetto si intende dotarsi di un software di Business
Intelligence in grado supportare tutti i processi di:
-
acquisizione dati consuntivi di base (ricavi e costi per CdC) estratti dal sistema
contabile
-
acquisizione dati previsionali attraverso interfacce utenti da distribuire ai referenti
dei Settori
-
elaborazione delle allocazioni tra Centri di Costo (in un unico nuovo sistema sia i
dati consuntivi che previsionali utilizzando le regole inserite una sola volta)
-
elaborazione di indicatori di efficacia e di efficienza
-
produzione e distribuzione dei vari prospetti di sintesi ai diversi referenti dei
Settori
Il software deve inoltre prevedere, in un prossimo futuro, la possibilità di essere
integrato con un modulo di pianificazione strategica e di valutazione degli obiettivi. A
titolo puramente indicativo si indicano le numerosità degli elementi che dovranno essere
gestiti del sistema:
-
Centri di Costo: circa 200 elementi base + relative aggregazioni
-
Voci di Conto Economico: circa 100 voci base + circa 50 voci calcolate
-
Periodicità: mensile con 5 anni in linea
-
Versioni dati: Consuntivi, Budget, 2 Forecast
Il software deve permettere al Settore Attività Finanziarie di gestire le informazioni
derivanti dalla contabilità finanziaria ed economica di integrarle con le informazioni di
tipo previsionale e di distribuirle, una volta elaborate ed integrate con parametri di tipo
fisico, tramite l’opportuna reportistica ai vari Settori, come meglio specificato di seguito.
A tale scopo si intende procedere all’affidamento della fornitura mediante trattativa
privata, preceduta da gara ufficiosa.
Premesso che si intende procedere alla trasmissione della richiesta di offerta via telefax,
per ragioni di celerità, si comunica quanto segue:
ART. 1 – CARATTERISTICHE GENERALI DEL SISTEMA
1.1
Il sistema deve operare nell’ambiente tecnologico già definito presso l’Ente.
Il fornitore dovrà specificare in dettaglio tutte le caratteristiche Hardware e
194
Software necessarie al funzionamento del sistema proposto, nonché le
caratteristiche Hardware e Software necessarie per l’installazione e l’esercizio
dell’applicazione sui PC degli utenti
Dovranno essere definiti inoltre gli skill sistemistici necessari alla manutenzione in
esercizio del sistema e le principali attività
sistemistiche necessarie alla
manutenzione in esercizio del sistema.
1.2
Dovrà essere fornito il numero minimo di licenze d’uso, in ogni caso non inferiore
a due
1.3
Il fornitore dovrà esplicitare il costo di eventuali licenze aggiuntive sulle stazioni
di lavoro
Il sistema deve essere corredato di procedure automatiche di back up/restore dei
1.4
dati
1.5
Il fornitore dovrà farsi carico della configurazione completa di tutto l’ambiente
operativo e della parametrizzazione del ambiente di lavoro.
ART 2 – REQUISITI FUNZIONALI E APPLICATIVI DEL SISTEMA
2.1
2.2
Il software deve comprendere i seguenti moduli o funzionalità:
-
Budgeting e Forecasting
-
Controlling
-
Indicatori
-
Reporting
Il software deve poter essere integrato con il modulo o funzionalità di
Pianificazione Strategica e Valutazione degli Obiettivi
2.3
Il software deve garantire la capacità di acquisire dati da sistemi amministrativi
esterni in formato testo o Microsoft Excel
2.4
Il software deve garantire la capacità di acquisire dati da sistemi amministrativi
esterni sviluppati in RDBMS Oracle.
2.5
Il software deve possedere funzionalità di controllo disponibili durante
l’acquisizione di dati esterni
2.6
Il software deve possedere la capacità di creare procedure automatiche per il
caricamento di dati esterni
195
2.7
Il software deve poter essere gestito dall’utente per ciò che riguarda gli aspetti di
implementazione, utilizzo ed evoluzione del modello di controllo senza interventi
di programmazione
2.8
Il software deve essere corredato di tutta la documentazione necessaria
all’utilizzo dello stesso.
2.9
L’applicazione deve possedere meccanismi di controllo per le autorizzazioni di
scrittura in funzione della log-in dell’utente (livello accesso alla maschera e livello
accesso alla singola informazione)
2.10
Modulo Bugdgeting e Forecasting
2.10.1 L’applicazione deve possedere la capacità di acquisire dati previsionali attraverso
interfacce native distribuibili a diversi utenti.
2.10.2 L’applicazione deve possedere la capacità di acquisire dati previsionali attraverso
interfacce native distribuibili a diversi utenti che presentino contestualmente dati
di riferimento (consuntivi, storici, ecc.).
2.10.3 Il software deve possedere sistemi di gestione delle versioni delle interfacce di
caricamento ed eventuali sistemi per la distribuzione delle stesse agli utenti.
2.10.4 Il software deve possedere la capacità di generare valori forecast e valori
consuntivi sui forecast di base
2.11
Modulo Controlling
2.11.1 Il software deve avere la capacità di gestire i dati secondo diversi “punti di vista”:
- Versione del dato (consuntivo, budget, forecast 1..n, anno precedente, ecc.)
-
Periodo (mese, anno, eventualmente dato)
-
Centro di costo
-
Linea di Conto Economico
Dovranno essere dichiarati i limiti nella gestione dei dati secondo le diverse viste
(es. n. max di punti di vista definibili, n. di elementi max all’interno di ogni punto
di vista, n. max totale di elementi per limiti della base dati, ecc.).
2.11.2 Il software deve avere la capacità di definire una o più aggregazioni (gerarchie)
lungo i diversi punti di vista.
Dovranno essere dichiarati eventuali limiti nella gestione delle gerarchie (es. n.
max di gerarchie definibili per punto di vista, n. max di livelli definibili entro ogni
gerarchia, ecc.).
196
2.11.3 L’applicazione deve avere la capacità di definire regole tra gli elementi
appartenenti ad ogni “punto di vista” (in particolare definire formule anche
complesse tra le voci del Conto Economico).
2.11.4 Il software deve avere la capacità di elaborare risultati partendo dai dati di base
caricati (da sistemi esterni o tramite interfacce) utilizzando le formule e le
gerarchie inserite per ottenere:
-
prospetti di Conto Economico sintetici e dettagliati;
-
prospetti sintetici e dettagliati secondo le diverse gerarchie;
-
prospetti con calcolo di varianze fra i diversi tipi di dati (Budget
vs/Consuntivo, Forecast 1 versus Budget, etc.).
2.11.5 Il software deve avere la possibilità di calcolare allocazioni (ribaltamenti) lungo
le gerarchie di Centro di Costo anche a più fasi (cicli di ribaltamento).
2.11.6 Il software deve avere la possibilità di definire drivers diversi di ribaltamento in
funzione della Linea di Conto da ribaltare (es. quantitativi, percentuali, a valori
standard, consuntivi, di budget, forecast. ecc.).
2.11.7 Il software deve avere la possibilità di utilizzare drivers ottenuti dopo
aggregazioni di Linee di Conto (es. utilizzare come driver di una specifica Linea di
Conto/ Centro di Costo il Totale dei Costi Diretti dei Centri di Costo riceventi).
2.11.8 Il software deve avere la possibilità di ribaltare sia i Costi che i Ricavi.
Dovranno essere dichiarati eventuali limiti nella gestione dei ribaltamenti (es. n.
max cicli di ribaltamento, n. max di drivers definibili, ecc.). Dovranno essere
descritte eventuali caratteristiche disponibili per la rintracciabilità dei dati ribaltati
(es. possibilità di risalire ai Centri di Costo cedenti, ecc.) attraverso report
cartacei e/o interfacce di navigazione sui dati.
2.11.9 Il software deve avere la possibilità di definire una procedura automatica di
esecuzione dei cicli di ribaltamento.
2.11.10Il software deve avere la possibilità di effettuare analisi destrutturate (es. drilldown, rotate, ecc.)
2.12
Indicatori
2.12.1 Il software deve possedere la capacità di gestire dati extra-contabili per la
197
definizione di indicatori (es. n. bambini presenti, iscritti, ecc.)
2.12.2 Il software deve possedere la capacità di utilizzare i dati contabili articolati per
Centro di Costo e i dati extra-contabili per il calcolo di indici (es. costo medio per
bambino, ec..).
2.12.3
Il software deve possedere la capacità di produrre report “di qualità” con i
dati degli indicatori distribuibili ai diversi Direttori dei Settori (formattazione
report, grafici, ecc.).
2.13
Reporting
2.13.1 Il software deve avere la capacità di produrre report per analisi dei dati di tipo:
-
Conti Economici Sintetici e di Dettaglio per Centro di Costo e
Raggruppamenti di Centri di Costo
-
Conti Economici Sintetici e di Dettaglio per Periodo e Versione Dati
-
Conti Economici Sintetici e di Dettaglio con diverse colonne, di diverso
Periodo e Versione Dato
2.13.2 Il software deve avere la capacità di eseguire i diversi report in funzione di
parametri (es. prospetto di C/E selezionando il CdC, il Periodo, la Versione dato,
ecc).
2.13.3 Il software deve avere la capacità di produrre report “di qualità” distribuibili ai
diversi Direttori dei Settori (formattazione report, grafici, ecc.).
2.13.4 Il software deve avere la capacità
di stampare elettronicamente i report
(formato Adobe PDF) e di esportarli in formato tabellare (Microsoft Excel).
2.13.5 Il software deve avere la possibilità di definire una procedura automatica di
esecuzione dei report per la stampa elettronica (formato PDF) e cartacea.
2.13.6 Il software deve possedere sistemi di gestione delle versioni dei report ed
eventuali sistemi per la distribuzione degli stessi agli utenti.
ART 3 – REQUISITI DELLA FORNITURA
3.1
Tempi di messa in esercizio:
il sistema dovrà entrare in esercizio improrogabilmente alla data del 1° Gennaio
2007, con un periodo di parallelo di tre mesi.
Tutte le attività necessarie alla messa in esercizio dell’applicazione dovranno
essere svolte on – site e dovranno iniziare a partire dal 4 Settembre 2006.
198
Per messa in esercizio si devono intendere le seguenti fasi:
implementazione del software (personalizzazione e parametrizzazione) così da
corrispondere ai requisiti funzionali richiesti: entro il 1° gennaio 2007;
l’attività di testing, comprensiva dell’assistenza nella fase di gestione in parallelo
tra il software attuale e il nuovo software e delle modifiche che si renderanno
necessarie: entro il 30 marzo 2007;
collaudo e rilascio del software con la consegna del manuale operativo definitivo:
entro il 30 aprile 2007.
3.2
Garanzia della fornitura:
la fornitura dovrà essere interamente coperta da garanzia on – site non inferiore
a mesi 12 decorrenti dalla data di messa in esercizio, contro vizi, difetti di
funzionamento, errori latenti e altre anomalie. La garanzia comprenderà altresì la
fornitura gratuita di tutte le prestazioni previste dal successivo art. 3 . 4
3.3
Manutenzione ordinaria e assistenza post – garanzia:
il canone annuale di manutenzione non dovrà superare il 15% del prezzo del
software e comprende le seguenti prestazioni_
- assistenza sistemistica
- assistenza specialistica funzionale
Gli aggiornamenti apportati dovranno in ogni caso salvaguardare tutte le
personalizzazioni effettuate dall’utente in modo autonomo.
Il contratto di manutenzione avrà validità annuale e decorrerà dal 1° giorno
successivo a quello di scadenza della garanzia del sistema.
Il fornitore dovrà quotare un compenso a forfait relativo ad almeno 10 giorni di
assistenza post-garanzia on site, successiva al collaudo del software previsto per
il 30 aprile 2007 e relativa all’affiancamento al personale nell’utilizzo del software
e comprendente eventuali modifiche che si potranno rendere necessarie.
3.4
Addestramento e Formazione
L’offerta dovrà contenere un piano dettagliato, comprensivo di tempi e modalità
di svolgimento, dell’addestramento e della formazione da fornire al personale
199
addetto del settore Attività Finanziarie e Contabili (3 unità) e del settore Sistemi
Informativi (2 unità).
Personalizzazione del sistema
3.5
Per le eventuali personalizzazioni del sistema la ditta aggiudicataria si impegna a
mettere a disposizione personale specializzato. Il costo di ogni singolo intervento
dovrà essere quantificato e contrattato con un apposito progetto ad un costo non
superiore di € 500,00 giornata/uomo più IVA, spese di trasferta incluse
ART 4 – REQUISITI DEL FORNITORE
4.1
Il fornitore dovrà presentare
-
una illustrazione della struttura aziendale con il fatturato del 2005
-
un elenco di referenze in progetti di budgeting e pianificazione
-
un elenco di referenze in progetti di Business Intelligence
-
Il fatturato 2005 in consulenza sulla BI e BPM
-
I Curricula Partner e Project Manager con almeno 5 anni di esperienza in progetti
di Business Intelligence, nonché i Curricula del gruppo di lavoro
ART 5 - OFFERTA ECONOMICA
5.1
L’importo presunto posto a base della gara.
200
6.4. Allegato 3 Esempi di check list
6.4.1.
Check list basata sulle specifiche funzionali
Business Requirements
Livello
di Personalizzazione
copertura
necessaria
(1 - 4)
(1 - 4)
Funzionalità
Regole e Strutture
E' possibile definire / creare diverse
dimensioni di analisi?
E' possibile definire / creare gerarchie e
relazioni tra le diverse dimensioni di
analisi?
Il sistema permette di relazionare i dati
soltanto ad alcune dimensioni di analisi?
Es:
le
vendite
possono
essere
dimensionate per cliente e prodotto
mentre la cassa può essere espressa solo
per unità organizzativa?
I dati di consuntivo possono essere
aggregati ad un livello di dettaglio
maggiore rispetto a quello di budget nello
stesso modello? (es. il budget principale
aggrega i costi totali di marketing ma il
direttore marketing desidera il budget per
singola campagna o pubblicazione) Se si,
specificare come
E' possibile definire dei driver globali? Un
esempio è rappresentato da un prezzo
fissato dal marketing, utilizzato da altri
dipartimenti e da questi non modificabile
E' possibile definire / creare regole di
calcolo di indicatori e di misure di risultato
personalizzate?
E' possibile modificare i modelli logici di
business?
201
L'utente può creare modelli custom come
sottoinsiemi del modello aziendale? Il
modello può essere modificato (elementi,
dimensioni, regole)? E' possibile definire
scenari multipli? I dati generati possono
essere riutilizzati nel modello aziendale?
L'utente
può
creare
un
modello
indipendente da quello aziendale? E'
possibile
successivamente
mappare
questo modello in quello aziendale?
Periodi Temporali
E' possibile gestire dati espressi secondo
differenti unità temporali? Per esempio le
vendite per settimana, il budget dei costi
per mese, lo stato patrimoniale per
quadrimestre
E'
possibile
la
periodicizzazione
automatica dei dati totali? Ad esempio
valori mensili dedotti da un'ammontare
annuale sulla base
settimane in un anno
del
numero
di
Measures
Quali tipi di measures sono supportate?
Finanziarie
Non Finanziarie
Indici
Apertura/Chiusura bilanci. Quelle di
apertura bilancio sono automaticamente
dedotte da quelle di chiusura?
Allocazioni
Le measures finanziarie possono essere
espresse come:
Debiti o crediti? Se no, come è
altrimenti possibile calcolare
finanziari positivi e negativi?
i
flussi
Stato Patrimoniale/Conto Economico?
202
Tipologia del tasso di cambio? In
alternativa, come vengono applicati tassi
differenti quali per esempio media,
chiusura, alle singole measures?
Allocazioni
Sono supportate
strato?
le
allocazioni
multi
Come il sistema alloca le differenze tra
budget e consuntivo di periodo (es:
trimestre) ? Le differenze del trimestre
possono essere riallocate sui mesi
rimanenti tramite driver nel processo di
forecasting?
Conversioni di Valuta
Quale è il supporto per la conversione
automatica fra valute ?
Attraverso più valute di riferimento?
E' possibile metterle direttamente a
confronto su uno stesso report?
Attraverso versioni multiple, per
esempio con tassi di consuntivo e di
budget? E' possibile metterle direttamente
a confronto su uno stesso report per
mostrare l'impatto dei movimenti valutari?
Il sistema può consolidare in diverse
valute (USD, GBP, Euro, ecc.)?
Il sistema può consolidare a differenti
tassi per mostrare l'impatto dei movimenti
di cambio?
Reporting ed Analisi
E' Possibile utilizzare funzioni di tipo "drill
up" e "drill down"?
Il sistema visualizza anche grafici e
risultati sullo stesso schermo, come in un
foglio di calcolo (excel)?
Il sistema può generare report di analisi
contenenti grafici a torta, grafici, ecc.
nella stessa applicazione?
203
E' possibile inserire annotazioni di testo
all'interno dei report?
E' possibile inserire allegati all'interno dei
report?
Il sistema supporta report di eccezioni?
E' possibile ordinare le eccezioni per
mostrare tuttte quelle che più si
discostano dall'obiettivo?
L'utente può ripartire o ruotare sul display
le informazioni?
Il sistema permette all'utente finale di
registrare e richiamare i suoi report
privati?
La produzione e la distribuzione ad ogni
utente dei report può avvenire in maniera
automatica?
L'utente finale può creare una variante in
maniera estemporanea? Ad esempio,
calcolare
la
variante
percentuale
consuntivo/budget per tutte le aziende;
ordinare il risultato per evidenziare le
migliori 10 in termini di ricavi; fare le
stesse cose per i costi totali. Questa
variante può essere evidenziata o
rappresentata tramite un grafico?
Il sistema supporta gli utenti non in linea?
Per esempio, gli utenti possono scaricare i
dati dal database, lavorarci in remoto e
successivamente rimandare le modifiche
indietro?
Gestione Profili e Livelli di Sicurezza
E' possibile definire profili di utenti o
gruppi di utenti su più livelli gerarchici per
garantire la sicurezza e l'accesso alle
informazioni?
Esiste una gestione dei profili utente con
autorizzazioni alle transazioni ed alle
operazioni sui dati?
204
Esiste una gestione dei profili utente con
autorizzazioni a livello di record e campo
(lettura, scrittura, cancellazione, ecc.)?
Una volta consentito l'accesso, questo può
essere sia di lettura che di scrittura?
Il sistema gestisce la sicurezza degli
accessi ai fogli di lavoro direttamente nel
CPM data store?
Viene utilizzata la stessa gestione di
sicurezza degli accessi alle pagine web?
Esiste un sistema di sicurezza che
restringe l'accesso degli utenti al database
?
Gestione del Processo
Sono gestiti i flussi informativi con livelli di
autorizzazione e revisione?
Quali processi
software?
sono
supportati
dal
 Formulazione di Strategie
 Strategie tradotte in tattiche ed attività
 Assegnazione di tempi, responsabilità,
KPI e pesi sulla strategia/tattica/attività

Supporto all'analisi per scenari.
Generazione di report che mettano a
confronto fianco a fianco il risultato di
differenti scenari ("What If")
 Assegnazione di obiettivi Top-down
 Pianificazione dell'attivo dettagliato che
calcola il deprezzamento delle attività e
l'NBV per categoria di attività
 Piano strategico
 Budget annuale
 Budget mensile
 Budget per B.U., Legal Entity, Gruppo
 Rolling forecast
Il sistema produce l'estratto conto
finanziario: Reddito, Stato Patrimoniale e
Flusso di Cassa? Il Flusso di Cassa può
205
essere derivato dallo Stato Patrimoniale?
L'applicazione possiede una funzionalità
di sottomissione che mostra chi ha
sottomesso budget e forecast e chi no?
Il sistema fornisce feed-back in tempo
reale riguardo l'impatto delle sottomissioni
del budget? Come?
Quali sono le modalità con cui il sistema
protegge le sottomissioni approvate da
cambiamenti indesiderati? Quali sono i
passi necessari per proteggere i dati da
cambiamenti nel momento in cui sono
stati validati?
Quali sono le modalità con le quali il
sistema aggiorna il budget o il forecast?
Quale processo è richiesto per mantenere
una vecchia versione e generarne una
nuova?
L'utente può spostarsi tra i vari processi
CPM senza dover cambiare sistema? E'
necessario importare/trasferire dati nel
processo?
E' possibile utilizzare lo stesso sistema per
rappresentare i dati di consuntivo?
L'utente può visualizzare i dati relativi
all'ultimo
forecast,
quelli
dell'anno
precedente e quelli di consuntivo fianco a
fianco senza dover creare uno speciale
data model?
E' possibile per l'utente definire un
intervallo di valori ammissibili per i
risultati?
Il sistema evidenzia automaticamente i
dati che sono al di fuori dei criteri stabiliti?
Se la struttura del data model viene
modificata come viene trasferita tale
206
modifica sui report?
In che modo il sistema supporta l'utente
nel riesame del budget on-line se dopo la
sottomissione
questo
è
stato
immediatamente accettato?
Il
sistema
supporta
la
generazione
automatica e la distribuzione dei report
agli utenti finali? In quale formato, per
esempio pdf. xls., txt., html, xml, ecc.?
E' possibile effettuare delle previsioni
partendo da una serie storica di dati?
Il sistema può supportare forecast su basi
statistiche?
Il sistema può analizzare la stagionalità
dei dati di consuntivo e di forecast
dell'anno precedente e successivamente
utilizzare i risultati per popolare la prima
proposta di budget per l'anno di
riferimento?
Portale
Il sistema è "web-based"?
E' possibile imputare i dati nel sistema in
forma grafica piuttosto che con una
tabella di input? Excel? Il sistema
supporta drill-down e rotazioni sia su
excel che su interfaccia web?
Il sistema permette l'accesso via Pocket
Device (cellulare, palmare, UMTS)?
Il sistema permette l'invio di informazioni
tramite e-mail, sistemi di istant messaging
( chat ) e newsgroup?
Il
sistema utilizza la piattaforma
Microsoft.NET ed XML come sistema di
comunicazione? Come?
L'utente
può
essere
supportato
nell'inserimento dei dati nel web e in
excel tramite funzionalità di help online?
207
Come sono costruite e pubblicate per gli
utenti finali le viste web?
Caratteristiche ed Amministrazione
del Sistema
Manutenzione del Sistema
Quali tecnologie si devono conoscere per
manutenere il sistema?
Ogni informazione strutturata del modello
di CPM può essere automaticamente
aggiornata al mutare di dimensioni logiche
residenti su un sistema esterno?
Il sistema possiede un'interfaccia grafica
per la manutenzione del modello?
Monitoring e gestione
strumenti, metodologie)
degli
spazi
(
Se viene effettuata una modifica:

E' resa automaticamente disponibile
all'utente finale?
Aggiorna il sistema di imputazione dei
dati?
 Aggiorna le analisi?
Se viene aggiunto un nuovo centro di
responsabilità e viene effettuata una
riorganizzazione i cambiamenti sono
acquisiti automaticamente nel video di
imputazione dei dati, nei report e
nell'analisi? In caso contrario che impegno
richiede tale attività?
Come viene effettuata la manutenzione
delle videate web e dei menu? Il sistema
fornisce delle GUI per acquisire i
cambiamenti o è necessario modificare
direttamente il codice HTML?
Che impegno è richiesto per avviare un
nuovo utente all'applicazione?
Caratteristiche del Data base
Dimensione massima di un data store:
N°. di measures
208
N°. di dimensioni di business che
possono essere
measures
applicate
ad
ogni
N°. di elementi per dimensione di
business
 N°. di versioni di dato che è possibile
conservare
N°. di periodi temporali supportati in
un anno. E' possibile aggregare i periodi
secondo criteri stabiliti dall'utente?
N°. di anni che possono essere
conservati
 Esiste un datastore unificato per i dati
di consuntivo, budget e forecast?
I dati devono essere duplicati fra processi
diversi? Per esempio è necessario
trasferire dati presso un altro data store
per il reporting?
Tecnologia
I dati sono contenuti in un unico database
centrale?
Il
sistema
proprietario?
utilizza
un
database
Esiste la possibilità di gestire le codifiche e
le regole di trascodifica tra sistemi?
E' possibile l'importazione/esportazione
dati da Excel o da Access?
Apertura/intefgrazione con altri prodotti
I dati sono immediatamente accessibili o
sono memorizzati
proprietario?
in
un
formato
L'utilizzo del web fa parte del sistema o è
necessario un modulo aggiuntivo?
I consolidamenti
server?
sono
elaborati
sul
Tipicamente quanti file sono prodotti
dall'esecuzione completa dell'applicazione
su 50 utenti?
209
Il sistema fornisce supporto su tutti i
processi CPM in uno stesso database?
Sono state pianificate delle modifiche
all'architettura tenica che altera quanto
sopra?
Si documenti la distribuzione dei clienti
sulle varie tipologie di BI proposte.
Dettagli Fornitore
Referenze ( Nomi Società in cui è
implementato il prodotto)
Diffusione della piattaforma in Italia (
unità in produzione )
Diffusione della piattaforma del mondo (
unità in produzione )
Quale % di ricavi della Vostra Azienda è
generata dalla vendita di questo specifico
prodotto?
Si elenchino tutti i prodotti offerti col
dettaglio dei moduli di cui questi si
compongono
E' il prodotto di punta della Vostra
Azienda?
Da quanto tempo la soluzione proposta è
disponibile in Italia?
Struttura -Italia Roma e il supporto fornito
210
6.4.2.
Check list basata sui moduli
211
212
6.4.3.
Check list semplificata
#
Evaluation Checklist
1
Our ProEst Service Plan includes
What is the technical support unlimited telephone support and
and update policy?
all cost estimating software
updates and enhancements.
2
Is there a hardware security
No Hardware Security is used.
device preventing me from
ProEst Users are allowed to install installing the system on my
on numerous machines.
laptop or home office machine?
3
How Long has the company
Since 1976, 25+ Years Strong
been in business?
-
4
How many companies are using
6,000+
your cost estimating software?
-
available?
ProEst Estimating
Other
Yes
What Web-Based,
and
On-Site
Quarterly classes held at our San
Diego location.
5
Is training
formats?
6
Is
custom
available?
7
What Hardware is needed to
Pentium
run
your cost estimating
64
Megs
of
software program at optimal
Windows 98/2000/NT
speed?
8
Yes
Is online or web-based support
It is included in our ProEst available?
Service Plan.
9
Are there references available?
10
Does the cost estimating
Yes
software have a digitizer
Save and edit digitizer takeoffs.
interface for electronic takeoffs?
programming
Yes
We develop, maintain, and can customize all of our products.
Machine
RAM -
Yes
-
-
213
11
How many Costs per item does
5 Costs Per Item
the software accommodate?
12
Yes
Does the software have both ProEst comes complete with
Item and Assembly takeoffs?
prebuilt database of items and
assemblies.
13
Yes
Are there multiple levels of
Taxes, Burdens, Overhead, Profit markups?
as well as single line markups.
14
Yes
Can you customize your own ProEst has a built-in report
reports?
generator to create the exact
output your company requires.
15
Can an estimate be broken Yes
down
and
organized
by The locations are user-definable location?
and unlimited in number.
16
Can an estimate be broken Yes
down by Phase or Work User
definable
Breakdown Structure?
numeric.
17
Does the software have
centralized cost table?
18
Yes
Does the cost estimating
Input multiple sub-contractor or
software allow for Subcontract
material vendors and select the
& Vendor quote comparison?
best cost solution.
19
Can you
formulas?
20
Yes
Can the system maintain a The ProEst software interfaces
budget list for job cost tracking? with over 20 accounting and job
cost systems.
21
Will
the
software
databases?
edit
the
-
and
alpha -
Yes
a The cost table in ProEst allows
the user to update thousands of
items with 1 change.
Yes
system The formulas
user-definable
takeoffs.
are completely
for
custom
Yes
cost
estimating The ProEst system will import RS
import
trade Means, Trade Service, Allpriser as well as standard text files from
suppliers.
214
22
Yes
Does the company develop all CMS designs, develops and
of their own products?
maintains all of their software
products.
215
Bibliografia
Autori vari, Organizzare e Gestire per progetti ed. Etas 2004
AA.VV : Antonino Attanasio, Giuseppe Bellazzi, David D’Agostini, Massimo Farina: I
contratti dell’informatica ed. Experta Edizioni 2008
Ajay Das “ E-provider evaluation: an esploratory study” in International Journal of
Technology Management n. 1 2004
Frank Bannister, Dam Remenyi, Journal of Information Technology, n. 3 2000
C. Batini, B Pernici, G. Santucci Sistemi informativi A Alessandrini, G. Lazzi, F. Minelle
volume III Costi e Benefici, ed. Franco Angeli 2001
Hind Benbya e Bill McKelvey Using coevolutionary and complexity theories to improve IS
alignment multi-level approach in Journal of Information Technology n.21 2006
Giampio Bracchi, Gianmario Motta “ Progetto di Sistemi Informativi “ ed. Etaslibri 2000
Giampio Bracchi, Chiara Francalanci, Gianmario Motta “Sistemi Informativi e Aziende in
rete”, ed. McGraw-Hill 2001
Luigi Buglione Misurare il software ed. Franco Angeli 2003
Deborah Bunker, Karl- Heinz Kautz, Anne Luu Thanh Nguyen Role of value compatibility
in IT adoption Journal of Information Technology n.22 2007
John S. Chandler e H. Peter Holzer Management Information Systems ed. Basil
Blackwell 1988
Charalambos L. Iacovou e Albert S. Dewter “ Turning around runaway information
technology projects” in California Management Review n.4 2004
Ciborra C.U. From Thinking to tinkering Strategic Information Systems: A European
Perspective, ed. Wiley 1994
Vincenzo Comito, Perché falliscono i progetti in Sviluppo ed Organizzazione n.211
Settembre/Ottobre 2005
Renata Paola Dameri: “ La valutazione dell’information technology in azienda “ Isedi
2005
Richard L. Draft Organizzazione Aziendale Ed. Apogeo 2001 pag. 248-259
Carroll W. Frenzel “ Management of Information Technology” ed. Boyd e Fraser 1996
216
Tommaso Federici “ Il progetto di sistemi informativi” ed. Franco Angeli 2001
Robert M. Grant “ L’analisi strategica per le decisioni aziendali “ ed. Il Mulino 1999
James H. Hall “ Accounting Information Systems “ ed. Tomson 2004.
Kenneth e Jane Laudon “ Management dei Sistemi Informativi “ ed. Pearson Prentice
Hall 2003
Mark Jeffery, Ingmar Leliveld “ Best practices in IT portfolio management” MIT Sloan
Management Review Primavera 2004
Lynn C. Kubeck: Techniques for Business Process Redesign Ed. John Willey and Sons,
inc. 1995
M. Lynne Markus “ Technochange management: using IT to drive organizational
change“ Journal of Information Technology n.19 2004
Federico Munari e Maurizio Sobrero Innovazione tecnologica e gestione d’impresa ed. Il
Mulino 2004
Tony Murphy “ Achieving business value from technologies “ Gartner 2002
Peter Well, Mani Subramani e Marianne Broadbent “ Building IT infrastructure for
strategic agility “ in MIT Sloan Management Review 2002
Peter Well, Jeanne Ross “ A matrixed approach to designing IT Governance “ MIT Sloan
Management Review 2005
F.C. “ Ted “ Weston, Jr. “ Erp II: the extended enterprise system “ in Business Horizons,
Novembre-Dicembre 2003
Charles Wiseman, Strategic Information Systems, ed. Irwin 1988
Carol A. Ptak e Eli Schragenheim “ Erp, tool, techniques and applications for integrating
the supply chain” St. Lucie Press 2004
W. G. Sullivan, E. M. Wicks, J.T. Luxhoj Economia Applicata all’ingegneria ed. Pearson
Prentice Hall 2006
Paul A. Strassmann The Politics of Information Management, ed. The Information
Economics Press, 1995
Antonio Teti Business and Information Business Analyst ed. Hoepli 2007
Raffaele Zallone “ Informatica e telematica: nuovi contratti di servizi ed. Giuffré 2003
Simone Zerauscheck ed Elisabetta Magini Contratti di informatica ed. Ipsoa 2001
217