Sei sulla pagina 1di 82

LA STIMA DEI COSTI DEI SISTEMI INFORMATIVI

AUTOMATIZZATI

Alessandro Alessandroni

1. Concetti generali

1.1. Premessa
In questo documento viene esaminata la problematica della stima ex-ante dei costi dei
Sistemi Informativi Automatizzati (SIA) prima che questi si manifestino. Non vengono
pertanto trattate le problematiche relative all’analisi ex-post dei costi dell'Information
Technology (IT) che vengono effettuate nell’ambito di attività di gestione progetti,
assessment di sistemi IT, consuntivi, monitoraggio di contratti, perizie, ecc.

L’obiettivo principale è quello di fornire alcuni criteri da utilizzare nella stima dei costi
delle diverse componenti di un sistema informativo automatizzato, piuttosto che fornire
riferimenti di mercato destinati a divenire obsoleti in poco tempo.

La presenza nel testo di prezzi o tariffe relative alla attuale situazione del mercato o alla
evoluzione storica negli anni più recenti ha soltanto finalità esemplificative delle
modalità di valutazione proposte nel testo o di fornire, nel caso di previsioni sugli
andamenti futuri, indicazioni di tendenza utilizzabili nel breve e medio termine.

1.2. La stima dei costi nel ciclo di vita dei SIA


La stima dei costi di un sistema informativo automatizzato è una attività che può essere
svolta in mo menti diversi del ciclo di vita dei sistemi informativi automatizzati e per fini
diversi quali:

• Valutazione dei costi annuali dell’informatica nella predisposizione di budget e


piani relativi all’IT di una organizzazione
• Valutazione dei costi delle soluzioni alternative di un progetto IT da confrontare con
i benefici nella stesura di uno studio di fattibilità
• valutazione economica di forniture di prodotti e servizi informatici nella fase di
acquisizione (gara o trattativa privata)

Nel primo caso si tratta di definire i costi relativi alle risorse spese od impegnate per
l’evoluzione e l’esercizio del sistema informatico di una organizzazione.

1
Nel secondo caso l’interesse è rivolto ai costi di un progetto IT, cioè al valore delle
risorse spese od impegnate per la costruzione di un nuovo sistema, l’avviamento e
l’esercizio.

Nel terzo caso si tratta di stimare i costi degli specifici beni e servizi IT che sono oggetto
di fornitura e devono essere acquisiti sul mercato.

Nelle varie fasi è diverso il grado di dettaglio con il quale si conosce il sistema da
acquisire o gestire o le singole componenti da valutare e di conseguenza è diverso il
grado di accuratezza con il quale può essere effettuata la stima dei costi. Anche i metodi
di stima possono differire a seconda delle informazioni disponibili e della accuratezza
richiesta.

1.3. Classificazione dei costi


I costi dei sistemi informativi automatizzati possono essere classificati secondo diversi
criteri: per tipo di risorsa, per missione, per tipo di spesa , ecc.

1.3.1. Costi per tipo di risorsa


Le tipologie principali di costi IT sono:
• costi delle tecnologie (hardware e software): i costi hardware riguardano le stazioni
di lavoro, gli elaboratori periferici, gli elaboratori centrali, le periferiche e gli
apparati di telecomunicazione; i costi del software riguardano sia i costi del software
di base, del middleware e dei pacchetti applicativi
• costi del personale: consistono nei costi del personale informatico dedicato ad
attività di gestione operativa, di sviluppo e manutenzione delle applicazioni, di
assistenza utenti, di pianificazione, amministrazione e di supporto
• costi dei servizi esterni per manutenzione hardware, software e delle reti, sviluppo e
manutenzione software applicativo, consulenze applicative e sistemis tiche, servizi di
elaborazione dati, data entry, help desk e assistenza utenti, outsourcing totale o
selettivo, ecc.
• altri costi: costi per immobili, materiali di consumo, telefoni e altre strumentazioni

2
1.3.2. Costi per missione
Il costo complessivo del sistema informativo automatizzato di una organizzazione o di
uno singolo progetto si può articolare in costi di sviluppo e costi di esercizio.
Per attività di sviluppo si
intendono le attività
relative a progetti che
costi per missione vanno ad ampliare e
rinnovare il portafoglio
applicativo della
Costi di costruzione amministrazione o ne
modifichino in modo
Costi di sviluppo
significativo alcune parti
Costi di un Costi di avviamento
progetto/sistema
Costi di esercizio
I costi di sviluppo si
distinguono tra costi di
costruzione (o
progettazione/realizzazio
ne) e costi di avviamento.

Il costo di costruzione rappresenta il costo necessario per ottenere un sistema da avviare.


I costi di avviamento rappresentano il valore delle attività e delle risorse necessarie per
mettere in esercizio i sistemi, i costi per passare dal precedente modo di operare ad uno
nuovo.

I costi di sviluppo comprendono anche costi per l’acquisizione di apparecchiature


hardware e prodotti software aggiuntivi acquisiti per installare e/o mettere in esercizio i
nuovi sistemi o per far fronte alle cresciute esigenze dei sistemi in esercizio.
I costi di esercizio comprendono tutti i costi necessari per il corretto funzionamento dei
sistemi e l’utilizzo delle applicazioni da parte degli utenti.
I costi di esercizio e manutenzione rappresentano una quota rilevante, mediamente dal
70 all’80%, di tutti i costi IT di una organizzazione.

1.3.3. Costi interni e costi esterni


I costi interni sono principalmente i costi del personale informatico della
amministrazione impegnato nelle attività di sviluppo e di esercizio del sistema. Accanto
a questi costi interni diretti ci sono anche i costi interni indotti legati alle attività svolte
dagli utenti finali per attività connesse alla costruzione, avviamento e utilizzo del sistema
(ad es.: il valore del tempo speso dagli utenti per caricare i dati negli archivi o istruirsi
all’uso dei nuovi sistemi).
I costi indotti valorizzano l’impatto organizzativo dei progetti informatici nelle loro
diverse fasi.

Con lo sviluppo dei modelli client/server e dell’informatica distribuita il costo indotto


relativo al tempo speso dagli utenti finali per imparare a utilizzare i pc e per operare con
essi è diventato molto rilevante.

3
I costi degli utenti finali pc possono essere suddivisi nelle categorie:
• addestramento e formazione formale : il tempo speso dagli utenti nelle classi;
• addestramento informale: ore spese a leggere, ricercare e esplorare nuove
funzionalità del sistema ;
• mantenimento del pc: installazione delle applicazioni, gestione dei dati, backup,
aggiornamento dell’hardware e del software, risoluzione dei problemi e così via
• supporto a colleghi: tempo speso dal lavoratore che aiuta un collega e tempo nel
quale questi viene aiutato;
• attività non produttive: giochi, elaborazioni e comunicazioni personali, ecc.
E’ stato stimato da Gartner Group che in sistemi distribuiti con pc connessi in LAN il
costo delle attività svolte dagli utenti finali è pari al 35% del costo totale di possesso del
sistema.
Per ridurre questi costi (di oltre il 50%), nonchè quelli di supporto tecnico e gestione dei
pc, sono state introdotte nuove piattaforme caratterizzate da:
• gestione centralizzata server-centric;
• standardizzazione forzata dei posti di lavoro;
• ridotte funzionalità e bassa complessità dei posti di lavoro.

Nel capitolo successivo verranno approfonditi questi aspetti.

I costi esterni sono quelli relativi all’acquisizione di prodotti hardware e software e di


servizi affidati a società esterne anziché svolti internamente.

Come evidenziato nella tabella seguente in fase di pianificazione e di budget si prendono


in considerazione i costi esterni e i costi interni diretti trascurando i costi indotti che non
incidono sulle previsioni di spesa.

Nel caso di studio di fattibilità è bene valutare l’opportunità di considerare anche i costi
indotti sia al fine di stimare l’intero ammontare dei costi da raffrontare ai benefici sia
per poter comparare soluzioni tecniche e architetturali alternative che potrebbero essere
caratterizzate da diversi costi indotti.

In fase di acquisizione la stima dei costi, o più propriamente dei prezzi, si limita ai costi
esterni relativi agli oggetti di fornitura, siano essi prodotti o servizi.

Interni
Fasi Esterni
Diretti Indiretti
Piano e budget X - X
Studio fattibilità (analisi costi benefici) X X X
Acquisizione - - X

1.4. Le fasi della stima dei costi


La stima dei costi avviene attraverso due fasi distinte:

4
• la quantificazione delle risorse necessarie
• la valorizzazione delle risorse individuate nella fase precedente
I procedimenti di stima variano a seconda del tipo di costo come è esemplificato nella
tabella seguente:

Principali voci di costo Quantificazione risorse Valorizzazione


Costi hardware Dimensionamento degli • Valore di listino per
impianti richiesti fascia o per specifica
(elaboratori, linee di configurazione + sconti
trasmissione, posti di volume
lavoro, periferiche) a • Prezzo di mercato per
partire dalle caratteristiche unità prestazionale (ad
funzionali, dai volumi es. MIPS, GB)
elaborativi e dalle
prestazioni richieste dal
sistema (capacity
planning)
Costi sviluppo software Dimensionamento dello Valorizzazione del tempo
impegno in tempo uomo a uomo impegnato a costi
partire dalle caratteristiche standard o a tariffe di
quali-quantitative del mercato
sistema da realizzare
(dimensione applicazione
in FP/ produttività)
Costi avviamento Dimensionamento Valorizzazione del tempo
dell’impegno in tempo uomo impegnato a costi
uomo a partire dalla analisi standard o a tariffe di
delle singole attività mercato
pianificate
Costi gestione sistemi Dimensionamento dello Valorizzazione del tempo
impegno in tempo uomo a uomo impegnato a costi
partire dalle attività standard o a tariffe di
pianificate sulla base delle mercato + valorizzazione
caratteristiche quali- altre risorse utilizzate
quantitative dei sistemi da
gestire e dei livelli di
servizio richiesti + altre
risorse usate
nell’erogazione del
servizio (tecnologie, locali
, materiali di consumo,
ecc.)
Costi manutenzione % del prezzo dell’hardware
hardware e software e del software in
manutenzione

5
1.4.1. La stima dei costi nella pianificazione dei sistemi informativi automatizzati
Il processo di pianificazione dei sistemi informativi automatizzati comprende una fase di
dimensionamento delle risorse e della spesa che definisce i fabbisogni di risorse (addetti,
tecnologie, infrastrutture) e ne quantifica i costi a partire da un piano consolidato dei
progetti in portafoglio e delle attività di esercizio (gestione e manutenzione).

Piano dei Piano delle attività


progetti di esercizio

Piano delle risorse (quantificazione)


(personale, infrastrutture tecnologiche,
altre)
(valorizzazione)

Piano della spesa


Costi per risorsa, per missione, ecc.

I tre momenti, mostrati nella figura, possono essere percorsi nei due sensi: in senso top-
down o in senso bottom-up. Nel primo caso il piano della spesa e quelli degli organici e
delle tecnologie sono determinati da quelli delle attività di esercizio e di sviluppo. Le
politiche di spesa anticipano o ritardano i tempi, ma non determinano i contenuti del
piano. Nel secondo caso, viene determinato in primo luogo il budget di spesa, per
esempio decidendo le variazioni percentuali dei costi rispetto a quelli sostenuti nell’anno
precedente definendo una scala di priorità delle funzioni organizzative clienti; la fase di
selezione dei progetti deciderà la assegnazione delle risorse disponibili. Nel primo caso è
il programma di sviluppo a guidare la pianificazione dei costi, nel secondo caso è invece
privilegiato il controllo dei costi.

Entrambi gli approcci possono essere contemporaneamente presenti, per esempio il


primo per aree o tecnologie innovative, ed il secondo per aree consolidate, in cui
prevalgono i costi di esercizio.

6
Si riportano di seguito le voci di costo previste dalla metodologia della Autorità per
l’Informatica nella Pubblica Amministrazione (AIPA) per il piano triennale delle
pubbliche amministrazioni centrali:
a)sviluppo b) esercizio
• prestazioni professionali studio • hardware
fattibilità − locazione/leasing mainframe
• prestazioni professionali analisi e − locazione/leasing dipartimentali
progettazione − locazione/leasing stazioni di
• hardware lavoro
− mainframe − locazione/leasing altre
− dipartimentali apparecchiature
− pc/ws − manutenzione mainframe
− altre apparecchiature − manutenzione dipartimentali
− altro hardware − manutenzione stazioni di lavoro
• software − manutenzione altre
− di base e d’ambiente apparecchiature
− pacchetti applicativi • software
− prestazioni professionali realizzazione − locazione/leasing software di base
software e d’ambiente
− altro software − locazione/leasing pacchetti
• rete applicativi
− apparecchiature rete e cablaggio − manutenzione software di base e
− software rete d’ambiente
− prestazioni professionali per rete − manutenzione pacchetti
− altro rete applicativi
• formazione utenti − prestazioni professionali
• prestazioni collaudo manutenzione software
• messa in produzione • rete
− acquisto locali − locazione/leasing apparecchiature
− acquisto impianti tecnologici di rete
− prestazioni messa in produzione − locazione/leasing software di rete
− manutenzione apparecchiature di
− altro per messa in produzione
rete
• prestazioni monitoraggio
− manutenzione software di rete
• altri costi
--------------------------------------------- • esercizio sistemi
− prestazioni professionali gestione
sistemi
− prestazioni professionali
assistenza sistemistica
− prestazioni per elaborazione dati
− prestazioni per data entry
• formazione informatica
• assistenza utenti
• affitto/manutenzione locali
• manutenzione impianti tecnologici
• materiali di consumo
• altri costi
---------------------------------------------

7
Si osservi che in questo modello le voci di costo appartenenti alle diverse tipologie
(hardware, software, prestazioni e servizi) sono articolate in due sezioni sulla base della
missione (sviluppo ed esercizio) e sono ordinate in base alla collocazione temporale
nell’ambito del ciclo di vita dei sistemi informativi automatizzati.

Come evidenziato in precedenza, in questa fase si prendono in considerazione i costi


esterni e i costi interni diretti ma non i costi indotti in quanto questi non incidono sulle
previsioni di spesa.

1.4.2. La stima dei costi dei progetti negli studi di fattibilità (analisi costi benefici)
La studio di fattibilità fornisce tutti gli elementi dimensionali, quantitativi e qualitativi,
relativi alle risorse necessarie sia per la realizzazione del progetto che per l’avviamento e
l’esercizio. Fornisce inoltre indicazioni sulla attività che conviene affidare all’esterno.
Per la stima dei costi occorre individuare le principali voci di costo (con dettaglio
analogo a quello utilizzato in fase di piano) ed esplicitare le modalità di stima utilizzate
per ciascuna voce.

Contenuti del progetto di massima:


• specifiche applicative
• specifiche tecnologiche
• avvio del nuovo sistema
• formazione e assistenza utenti
• impegni di esercizio e manutenzione quantificazione
• make or buy (piano acqusizioni)

Costi del progetto:


costi per risorsa, per missione, ecc. valorizzazione

1.4.3. La stima dei costi esterni nella acquisizione di beni e servizi informatici
In fase di acquisizione di beni e servizi IT nei capitolati tecnici sono indicate le quantità
da acquisire, i requisiti funzionali e di prestazione dei beni e i livelli di servizio dei
servizi. Sulla base degli elementi quantitativi e qualitativi contenuti nei capitolati tecnici
si procede alla valorizzazione delle singoli componenti sulla base di informazioni di
mercato, secondo i criteri esposti nel seguito, e quindi alla determinazione dell’importo
complessivo della fornitura.

8
1.5. Organizzazione del documento
Dopo una sintetica descrizione dell’approccio del Costo totale di possesso o Total Cost
of Ownership (TCO) contenuta nel paragrafo 21 , verranno descritti nei paragrafi
successivi i criteri di stima delle singole componenti di costo.

Il modello adottato è quello proposto per il piano dalla Autorità per l’Informatica nella
Pubblica Amministrazione esposto in precedenza. Le voci di costo all’interno delle aree
sono stare riordinate in modo da raggrupparle per tipologia (hardware, software e
servizi) e sono state aggiunte alcune voci relative a prodotti hardware e software che nel
modello del piano risultano aggregate.

I costi relativi al noleggio e leasing di prodotti hardware e software, presenti nel modello
dei costi del piano AIPA nella sezione “costi di esercizio”, non vengono trattati
esplicitamente in quanto possono essere ricavati, attraverso semplici calcoli finanziari,
dai costi di acquisizione dei prodotti stessi. Non sono stati inoltre presi in considerazione
i costi non strettamente informatici quali impianti tecnologici, locali, materiali di
consumo, ecc.

Nella tabella seguente sono riportate nella prima colonna le voci di costo del modello di
piano AIPA e nella seconda colonna le componenti di costo esaminate nel presente
documento, con la indicazione, nella terza colonna, del relativo paragrafo.
voci di costo del modello di piano componenti di costo esaminate paragrafo
costi di sviluppo costi di sviluppo
hardware hardware
− mainframe − sistemi mainframe 3.2
− dipartimentali − sistemi intermedi (dipartimentali e server) 3.3
− pc/ws − personal computer 3.4
− altre apparecchiature e altro − stampanti laser 3.5
hardware − stampanti di linea 3.6
− scanner 3.7
− sottosistemi a disco per mainframe 3.8
− sottosistemi a disco per sistemi intermedi 3.9
− librerie robotizzate 3.10
− apparecchiature rete e cablaggio − sistemi di cablaggio e componenti di reti 3.11
(hub, switch, router, ecc.)
software software
− di base e d’ambiente − Software di base e d’ambiente per 4.1
mainframe
− software di base e d’ambiente per sistemi 4.2
UNIX
− dbms 4.4
− network & system management, ecc.) 4.5
− strumenti di sviluppo applicativo 4.6
− pacchetti applicativi e altro software − pacchetti applicativi per desktop 4.3
− pacchetti applicativi di tipo ERP 4.7

1
Il riferimento ai paragrafi si deve intendere all'interno del Contributo, quindi dal
secondo livello della numerazione.

9
− software rete incluso nel costo delle apparecchiature (3.11)
prestazioni e servizi servizi
− prestazioni professionali studio − studi di fattibilità 5.2
fattibilità
− prestazioni professionali analisi e − sviluppo software applicativo (compreso 5.3
progettazione avviamento) e manutenzione evolutiva
− prestazioni professionali
realizzazione software
− prestazioni professionali per rete questi costi sono compresi nel costo del cablaggio (3.11)
− formazione utenti − formazione (personale informatico e utenti) 5.4
− prestazioni collaudo − servizi per il collaudo e la messa in 5.5
− prestazioni messa in produzione produzione
− prestazioni monitoraggio − monitoraggio 5.6
costi di esercizio costi di esercizio
hardware hardware
− locazione/leasing hardware − la stima di questi costi si può ricavare dalla
stima dei costi di acquisizione
software software
− locazione/leasing software − la stima di questi costi si può ricavare dalla
stima dei costi di acquisizione
prestazioni e servizi servizi
− manutenzione mainframe, − manutenzione prodotti hardware 5.7
dipartimentali, stazioni di lavoro,
apparecchiature di rete, altre
apparecchiature
− manutenzione software di base e − manutenzione prodotti software 5.8
d’ambiente, pacchetti applicativi e
software di rete
− prestazioni professionali − manutenzione ordinaria del software 5.9
manutenzione software applicativo (MAC)
− manutenzione straordinaria anno 2000 5.10
− prestazioni professionali gestione − gestione sistemi e reti (CED, pc/LAN, 5.11
sistemi e assistenza utenti WAN, server)
− prestazioni per elaborazione dati
− prestazioni professionali assistenza − assistenza sistemistica 5.12
sistemistica
− prestazioni per data entry − data entry 5.13
− formazione informatica trattata insieme alla formazione utenti (5.4)

Nell’utilizzare un approccio di stima analitico, basato sulla valutazione delle singole


componenti di costo, si rischia di trascurare il costo della integrazione di più
attività/prodotti, di diverse tecnologie (hardware, software e servizi, reti) e di diversi
fornitori. Tali costi si annullano, o comunque si riducono, se l’amministrazione dispone
di risorse qualificate per gestire e realizzare progetti di questo tipo; altrimenti vanno a
sommarsi ai costi delle singole componenti.

Il costo aggiuntivo, nel caso di servizi che prevedono lo sviluppo e la integrazione di


sistemi, dalla progettazione fino al collaudo, può essere stimato pari al 10-15% degli
importi relativi all’hardware, al software e agli eventuali altri servizi.

10
2. L’approccio del Total Cost of Ownership (TCO)

2.1. Introduzione
In una fase iniziale nella quale non si disponga di informazioni di dettaglio sul sistema
da realizzare si può seguire un approccio di stima basato su modelli di costo totale di
possesso o total cost of ownership (TCO). La metodologia del total cost of ownership è
stata sviluppata principalmente per confrontare e valutare tecnologie e architetture
alternative prendendo in considerazione tutti i costi connessi con l’acquisizione, gestione
e manutenzione di un sistema o sottosistema informatico durante la sua vita utile (3-5
anni).

Tale approccio è anche utile per valutare i costi di servizi di outsourcing di sottosistemi
(ad es. outsourcing di pc, CED, reti, ecc.) nei quali il fornitore mette a disposizione sia
l’hardware ed il software sia il personale per la gestione.

Sono disponibili in letteratura analisi del TCO relativi sia a interi sistemi informatici che
a singole componenti quali pc, LAN, sottosistemi a disco, mainframe, server Unix o NT,
ecc. Nella tabella seguente (fonte: Gartner Group) sono riportate le principali voci di
costo che compongono il costo totale di possesso relativo a un sistema informatico.

11
2.2. Esempi di analisi del TCO
Si riportano nel seguito, come primo
esempio, i risultati di uno studio TCO client/server vs. mainframe/terminali
svolto nel 1995 dal Gartner Group
per comparare i costi dei sistemi mainframe/terminali
client/server

client/server con quelli dei sistemi 26%


41%
21%

33%
basati su mainframe. I risultati, HW, SW e TLC

sviluppo e

espressi in lire spese per posto di gestione


supporto utenti

lavoro informatizzato all’anno, hanno 7% utenti finali


23%

evidenziato un costo per i sistemi C/S,


pari a circa 9 milioni di lire all’anno 34% 15%

per utente, superiore del 70% al costo


dei sistemi tradizionali basati su
mainframe e terminali, pari a 15,5 milioni di lire all’anno per utente. Anche eliminando
dal conteggio i costi relativi alle attività degli utenti finali, la soluzione C/S rimane più
costosa del 37%. Nella figura a lato è confrontata la struttura dei costi delle due diverse
architetture.

Nel seguito viene descritto, sempre a scopo esemplificativo, il modello del TCO per
l’informatica distribuita elaborato recentemente dal Gartner Group per confrontare i costi
di diverse soluzioni client.

I risultati della analisi, riportati nella tabella sottostante, evidenziano che è possibile
ridurre i costi totali anche del 35% ricorrendo a piattaforme più semplici da gestire.

Il modello del TCO, adottato per questa analisi, comprende quattro categorie di costi
distinte per le postazioni di lavoro e per la rete:
• capitale
• supporto tecnico
• amministrazione
• attività dell’utente finale

Il costo del capitale rappresenta tutti i costi non riferiti al lavoro quali le spese per
l’hardware e per il software , la manutenzione, le spese di energia, ecc.

Il supporto tecnico comprende i costi del lavoro relativi allo staff di supporto tecnico
addetto all’help desk, alla definizione di standard per la organizzazione, alla gestione
dell’hardware e del software sia dei pc che dei server.

12
I costi di amministrazione per il desktop sono quelli relativi ai costi di acquisizione e
manageriali mentre i costi relativi alla rete riguardano i tradizionali compiti di
amministrazione della rete quali backup e amministrazione degli utenti.
La categoria delle operazioni degli utenti finali consiste dei costi del lavoro sostenuti

dagli utenti finali che interagiscono con le tecnologie in attività non produttive quali la
gestione dei file e la individuazione dei problemi.
Nel modello non sono compresi i costi delle applicazioni delle applicazioni specifiche
delle diverse linee di business, sia il costo di sviluppo delle applicazioni che i relativi
server in quanto i costi e i fabbisogni di applicazioni specifiche variano molto da azienda
ad azienda e da settore a settore.

Il modello esamina i costi IT di una ipotetica organizzazione con una LAN per 2500
utenti in cui la gestione sia centralizzata variazione dei costi in funzione della
piattaforma utilizzata 2 .

2
NC-C : (network computer) un thin client che esegue dei task (applets) acquisite dalla rete; NC-S :
piattaforma Windows terminal totalmente basata sul server con il desktop che si limita alla presentazione;
NetPC -ZAK-E e ZAK-A: net -pc con software ZAK (Zero Administration Kit)- ZAK-E (ZAK-Explorer
Interface, TaskStation Mode) per utenti che necessitano di accesso ad una sola applicazione o ZAK-A (ZAK-
Applications Support, AppStation Mode) per utenti che devono accedere a più applicazioni.

13
2.3. Sviluppi della metodologia del TCO
Negli ultimi anni la metodologia del TCO è stata arricchita con alcune integrazioni volte
a renderla uno strumento decisionale a supporto di iniziative di riduzione del TCO:
• aggiunta della complessità dell’ambiente e dei livelli di servizio (all’aumentare
della complessità aumenta il TCO);
• aggiunta della tipologia di utenti (con utilizzo di una parte di client diversi dal pc
per utenti con minori esigenze in termini di funzionalità);
• aggiunta delle “best practices” che riducono il TCO;
• aggiunta del rischio (la riduzione del rischio può comportare un aumento del
TCO).

2.3.1. Complessità
La complessità associata alle infrastrutture IT ed alla loro gestione sono uno dei fattori
più importanti che determinano il TCO. Più è complessa una organizzazione e le
installazione IT e maggiori sono i costi di pianificazione, realizzazione, rilascio e
dismissione associati a una grande varietà di tecnologie (PC, server, applicazioni, ecc.).

Le infrastrutture IT e le persone responsabili per la gestione dell’IT sono parte di un


sistema complesso di relazioni e interdipendenze. Più differenziate sono le componenti
associate con il sistema (per esempio numero di piattaforme) e più indefiniti i processi di
gestione (ad esempio processi di gestione dei problemi non documentati), maggiori sono
le risorse ed i costi necessari per supportare il sistema. La complessità può essere
articolata in due categorie principali: gestione IT, cioè come tutte le operazioni vengono
gestite, e infrastrutture IT, ovvero l’ambiente da gestire e le tecnologie a supporto della
gestione.

La complessità della gestione è influenzata da una serie di fattori quali il grado di


centralizzazione della gestione, il processo di controllo del budget, i processi di gestione
dei problemi e dei cambiamenti, i processi di pianificazione, i livelli di servizio, il
numero e tipo di utenti finali e la loro dispersione.

La complessità delle infrastrutture è distinta tra hardware e software.


La prima deriva dalla percentuale di applicazioni di tipo C/S, il numero totale di distinti
sistemi operativi, la maturità media delle applicazioni C/S installate, la percentuale di
applicazioni critiche.
La complessità dell’hardware è influenzata da un numero di fattori quali il numero di
differenti architetture hardware, il tasso di cambiamento dei PC, il tasso di adozione di
portatili, la percentuale di apparecchiature ridondanti (server, hub, router, ecc.).

E’ importante verificare che la complessità dei sistemi informatici presenti nella


organizzazione, e quindi i costi ad essa associati, sia giustificata dalle caratteristiche dei
servizi IT da erogare. Altrimenti occorre intervenire sui fattori di complessità con
conseguenti benefici in termini di TCO.

14
2.3.2. Tipologie di utenti
Una organizzazione tipo è composta da diverse tipologie di utenti con esigenze
differenziate. Non è opportuno fornire a un utente troppe funzionalità rispetto a quelle
necessarie ma non si può nemmeno fornirne un numero insufficiente. Le funzionalità
aggiungono complessità e la complessità aggiunge costi. Se, ad esempio, solo il 10%
degli utenti ha bisogno di tutte le funzionalità offerte da un pc standard si possono
introdurre altri client di minore complessità e costo che sono comunque adatti per gli
utenti con minori requisiti di funzionalità.
Nella tabella seguente, riferita ad una organizzazione con 2500 utenti, l’adozione di un
opportuno mix di apparecchiature client consente riduzioni consistenti del TCO senza
effetti negativi in termini di efficacia.

L’adozione di adeguate tecnologie integrate con i processi di gestione consentono di


fornire agli utenti il massimo in termini di funzionalità disponibili al minimo costo.

2.3.3. Best Practices


Il TCO può essere ridotto
attraverso pratiche di
gestione adeguate e
opportuni strumenti di
supporto.

Le best practices si basano


su tecnologie di supporto
(sia hardware che software)
che se correttamente usate
aiutano a ridurre il TCO di
oltre il 40% con aumento
dell’utilizzo delle

15
funzionalità e della soddisfazione degli utenti.
Nella figura è riportato l’impatto delle best practices sul TCO per sistemi pc/LAN.

2.3.4. Rischio
Infine l’analisi del TCO deve includere la valutazione del rischio associato alla
realizzazione e alla operatività dei sistemi informatici.
In particolare occorre valutare la relazione tra ris chio di fermata ed i costi. Una riduzione
del rischio richiede investimenti in IT ed è compito di chi gestisce l’IT valutare il giusto
compromesso.

3. Stima dei costi dell’hardware

3.1. Introduzione
Per alcuni prodotti hardware è possibile stimare il prezzo sulla base di un prezzo unitario
di mercato riferito ad un fattore di prestazione o di dimensione quali ad esempio la
potenza elaborativa o di memorizzazione; è questo il caso ad esempio del prezzo per
MIPS per un sistema di elaborazione di tipo mainframe o del prezzo per Gb per
sottosistemi di memorizzazione a disco.

Per altri prodotti la stima economica viene effettuata sulla base del prezzo di listino
medio riferito a una particolare tipologia di utilizzo o ad una specifica configurazione
(configurazione base + componenti aggiuntivi). Nel caso di acquisizione di un numero
elevato di unità si possono correggere i prezzi di listino con sconti medi riferiti ai volumi
in gioco. E’ questo il caso, ad esempio, di: personal computer (desktop e portatili),
workstation, stampanti.

In altri casi (ad esempio: server, librerie robotizzate, ecc.) sono possibili entrambi gli
approcci in quanto è possibile effettuare sia stime di massima basandosi su prezzi unitari
riferiti a dati di prestazione sia, una volta che si disponga di informazioni di dettaglio,
fare riferimento a specifiche configurazioni per valutazioni più accurate.

Per alcune apparecchiature di rete è possibile effettuare valutazioni di massima basate su


prezzi unitari per porta (hub, switch, router, escon director, ecc.). Anche in questo caso
valutazioni più accurate, in fase di acquisizione, devono fare riferimento a specifiche
configurazioni.

16
3.2. Mainframe
Il mercato dei mainframe è costituito principalmente dai sistemi IBM S/390 e
compatibili (Hitachi e Amdahl).

Dal 1993 la IBM, seguita dagli altri produttori, non pubblica più prezzi di listino dei
sistemi S/390 e, pertanto, gli unici riferimenti disponibili sono i prezzi medi di vendita
per MIPS rilevati dagli information provider (Gartner Group, Metagroup, Sievers
Consulting,
Observed Selling Prices (+/- 10%, 1 year warranty) ecc.). Tali
2Q97 3Q97 4Q97 1Q98 2Q98 3Q98 4Q98 prezzi
KDM/
MIPS
vengono
rilevati sul
mercato e
15 fanno
12
riferimento a
11,5
11
10,5
11
10,2
configurazioni
9
8,6 medie 3 . Nella
7,7
7,2
6,6 6,6 figura a lato è
7
Amdahl
6,6 6,6
5,8
riportato, a
Skyline 2

IBM CMOS
titolo di
98_004st.ds4
esempio,
© 1998 Ralf-Jürgen Sievers Consulting
l’andamento
trimestrale dei prezzi dei sistemi sul mercato europeo osservato dalla Società Sievers
Consulting.

Le potenze elaborative dei diversi sistemi, espresse in MIPS (milioni di istruzioni per
secondo), vengono fornite dai fornitori e verificate dagli information provider sulla base
delle effettive prestazioni rilevate dagli utenti. I MIPS vengono determinati sulla base di
un insieme di diversi carichi di lavoro (TSO, CICS, DB2, IMS e batch).

3
10-15 Mb di memoria centrale per MIPS e 0,5-0,75 canali per MIPS (Gartner Group);
10 Mb di memoria centrale e 0,2 canali per MIPS (Sievers Consulting). Per
configurazioni diverse da quelle medie occorre correggere opportunamente il prezzo
base per MIPS. Con riferimento alla sola memoria centrale i prezzi attuali sono pari a
circa 160.000 lire per Mb.

17
I prezzi medi di vendita dei mainframe sono diminuiti negli ultimi anni in misura
rilevante scendendo da circa
100 milioni di lire/MIPS nel
Cost per Configured OS/390 MIPS 1990 a meno di 10 milioni di
Fonte: Gartner Group lire/MIPS a fine 1997.
Tale riduzione, favorita dai
nuovi processori a tecnologia
C-MOS, non è più guidata
dalla competizione tra
produttori di mainframe ma
piuttosto da quella tra
mainframe e piattaforme
alternative (sistemi Unix di
fascia alta).
Gli analisti prevedono che il
trend discendente del prezzo
per MIPS dei grandi sistemi continui nei prossimi anni annui ad una tasso medio del
30% all’anno (vedi figura a lato).

I prezzi dei mainframe forniti dagli information provider sono riferiti all’acquisto di
nuovi sistemi IBM o compatibili (PCM). Nel caso di upgrade i prezzi per MIPS possono
essere superiori del 15-20%.

Per sistemi diversi da quelli IBM e IBM compatibili che offrono altre soluzioni
proprietarie i prezzi per MIPS, per l’assenza di competizione diretta, sono superiori di
3-4 volte a quelli indicati.

Il miglioramento sempre più rapido del rapporto prezzo/prestazioni e la riduzione


dell’intervallo di tempo tra l’immissione sul mercato di sistemi con processori più
potenti ha portato ad un accorciamento della vita economica dei sistemi, passata da 6
anni nel ’90 a 3-4 anni nel 1998, con conseguente discesa sempre più rapida dei prezzi
sul mercato secondario
(vedi figura a lato)

Mid-Market Values of IBM's Large Systems La continua riduzione dei


Fonte: Gartner Group prezzi dell’hardware non
è stata accompagnata da
una discesa altrettanto
significativa dei canoni
delle licenze software.
Nella figura seguente è
riportato il costo di
possesso di sistemi S/390,
con esclusione dei costi
del personale addetto alla

18
gestione, calcolato sommando agli ammortamenti dell’hardware, i canoni delle licenze
del software di base e della manutenzione ed i costi dell’energia.
Nei primi anni ’90 i costi si sono ridotti a un tasso medio annuo del 15%. Dal 1993 al
1996 il tasso di riduzione è passato al 25-30% all’anno. Durante questo periodo molte

organizzazioni hanno iniziato la migrazione da sistemi a tecnologia ECL a sistemi a


tecnologia CMOS, con elevata riduzione dei canoni di manutenzione e dei costi della
energia consumata.

La quota relativa al costo del software è andata crescendo ed è attualmente la voce di


costo più rilevante. Tale componente sarà esaminata in un prossimo paragrafo.

3.3. Sistemi intermedi (midrange)

3.3.1. Introduzione
Nel caso dei sistemi midrange non può essere utilizzato come indice di prestazione il
MIPS che è un valido indice di confronto all’interno di una stessa architettura
(mainframe) ma che può portare a grossi errori se utilizzato per confronti tra architetture
diverse quali quelle dei sistemi “midrange”.
Le prestazioni di un sistema multiuser e multitasking sono infatti determinate oltre che
dalla potenza del processore anche dalle caratteristiche architetturali (velocità del bus,
caching, sottosistema I/O, ecc.); si ricorda che in una configurazione bilanciata di

19
mainframe (1-1,5 canali per MIPS) circa il 25% del prezzo della unità centrale è dovuta
al sottosistema di I/O.

L’indice di prestazione più utilizzato per sistemi UNIX e NT è il numero di transazioni


al minuto tpm-TPC-C. Questo benchmark è nato per testare le caratteristiche dei sistemi
in ambiente OLTP (on line transaction processing) dove è richiesto un rapido accesso in
lettura e scrittura ai database che contengono le informazioni aziendali di riferimento ed
anche se tale indice è influenzato dal tipo di DBMS utilizzato nei test e dalla
configurazione adottata (tipo host o client-server4 ) è al momento il più utilizzato.
Nei risultati dei benchmark, pubblicati dal Transaction Processing Council, vengono
indicati per ciascun sistema: configurazione, tpm, e prezzo in $ per tpm calcolato sulla
base dei prezzi dell’hardware, del software e della manutenzione per 5 anni.

Nella figura seguente sono riportati, a titolo di esempio, i risultati relativi ai 10 sistemi
che avevano fornito, alla data di marzo 1999, le più elevate prestazioni e ai 10 sistemi
con migliore rapporto prezzo/prestazioni. Nel primo caso di tratta di sistemi Risc/UNIX
e nel secondo caso di PC server con processori INTEL e sistema operativo NT.

tpm(c)
Compan
Rank Config tpmC $/tpmC Database
y
115,395.
1 Sun Enterprise 10000 (64-way) $105.63 Oracle8i v8.1.5.1
73
AlphaServer 8400 (8 node x 12- 102,541.
2 Digital $139.49 Oracle8 v8.0.5
way) 85
93,900.8 Oracle8 Enterprise Edit'n
3 Sequent NUMA-Q 2000 E300 (64-way) $131.67
5 8.0.4
92,832.9 Oracle8i Enterprise Edit'n
4 HP HP 9000 V2500 (32-way) $86.94
6 8.1.5
RS/6000 SP Model 309 (12 node x 57,053.8 Oracle8 Enterprise Edit'n
5 IBM $147.40
8-way) 0 8.0.4
53,049.9
6 Sun Enterprise 6500 (24-way) $76.00 Sybase ASE 11.9.3
7
52,117.8 Sybase ASE11.5 EBF
7 HP HP 9000 V2250 (16-way) $81.17
0 7817
Ultra Enterprise 6000 c/s (2 node x 51,871.6 Oracle8 Enterprise Edit'n
8 Sun $134.46
22-way) 2 8.0.3
48,793.4 Oracle8 Enterprise Edit'n
9 Sequent NUMACenter 2000 (32-way) $127.53
0 8.0.4
43,169.8 DB2 for AS/400 V4
10 IBM AS/400e 9406-S40 (12-way) $128.91
5 Release 1
$/tpm(c)

4
Il test in configurazione client/server è mediamente superiore del 20%

20
Compan
Rank y Config $/tpmC tpmC Database
22,478.9 M'soft SQL Server 7.0
1 Compaq ProLiant 7000 c/s (4-way) $18.84
0 Ent Ed'tn
17,715.9 M'soft SQL Server 7.0
2 Compaq ProLiant 5500 6/400 $21.71
0 Ent Ed'tn
19,118.3 M'soft SQL Server 7.0
3 Unisys Aquanta QS/2V (4-way) $22.11
7 Ent Ed'tn
19,118.3 M'soft SQL Server 7.0
4 Unisys Aquanta QR/2V (4-way) $22.19
7 Ent Ed'tn
19,725.1 M'soft SQL Server 7.0
5 Compaq ProLiant 7000 c/s (4-way) $22.50
0 Ent Ed'tn
12,033.6 M'soft SQL Server 7.0
6 Compaq ProLiant 3000-6/500-1S (2-way) $22.64
0 Ent Ed'tn
24,328.6 M'soft SQL Server 7.0
7 Unisys Aquanta ES5045 (4-way) $22.99
7 Ent Ed'tn
19,050.1 M'soft SQL Server 7.0
8 HP NetServer LH 4 (4-way) $23.10
7 Ent Ed'tn
23,570.3 M'soft SQL Server 7.0
9 Siemens Primergy 870-40 (4-way) $23.41
3 Ent Ed'tn
21,354.5 M'soft SQL Server 7.0
10 Unisys Aquanta QR/2 (4-way) $23.73
5 Ent Ed'tn

I risultati dei benchmark TPC-C, pubblicati a partire dal 1993 evidenziano un continuo
incremento delle prestazioni e del rapporto prezzo prestazione. Ogni anno c’è stato quasi
un raddoppio delle
Unix Server: TPC-C prestazioni dei sistemi,
Performance History sia per effetto della
crescita della potenza
unitaria dei processori
che per l’aumento del
numero di processori
presenti in un sistema.

Nella figura a lato


(fonte Gartner Group) è
riportato l’andamento
delle prestazioni dei
sistemi UNIX negli
ultimi 5 anni sia con
riferimento alle
prestazioni dei singoli processori sia alle prestazioni complessive dei sistemi
multiprocessore.

Nella figura seguente sono riportati gli andamenti negli anni più recenti delle prestazioni
e del rapporto prezzo/prestazioni dei sistemi UNIX ed NT.

I prezzi per transazione sono diminuiti a tassi annui del 45-50% per sistemi NT e UNIX.
In termini assoluti i server NT hanno prezzi inferiori del 50-60% rispetto ai server

21
UNIX. Soltanto nell’area in cui le prestazioni dei server NT di fascia alta si
sovrappongono con quelli dei server UNIX i prezzi si avvicinano.

Quando nelle gare si mettono in competizione fornitori di server NT con fornitori di

server Unix sono stati osservati forti sconti praticati da quest’ultimi (anche dell’ordine
del 60-70% nel caso di 100-1000 unità o più) rispetto al 40% praticato generalmente per
acquisti consistenti.

Gli analisti prevedono che le riduzioni di prezzo proseguiranno per entrambe le tipologie
di sistemi ma con un miglioramento del rapporto prezzo/prestazione, per i sistemi UNIX
di fascia alta, inferiore a quello dei sistemi NT.
I sistemi AS/400 hanno prezzi per transazione superiori a quelli dei sistemi UNIX ed
NT; il rapporto prezzo/prestazione è comunque diminuito di circa il 30% negli ultimi
anni e gli analisti prevedono che diminuirà nei prossimi anni a tassi annui compresi tra il
30 e il 40% .

La riduzione dei prezzi dei server è favorita dai seguenti fenomeni:

1. crescente standardizzazione su architetture comuni di CPU sia per sistemi proprietari


che per sistemi Unix;
2. crescente uso della stessa CPU dal sistema più piccolo al più potente di una famiglia
attraverso architetture multiprocessore;
3. crescente uso di sottosistemi standard per I/O, memorie di massa, memorie RAM
anche per i sistemi di fascia alta.

22
Nel caso di server dedicati a utilizzazioni specifiche è più opportuno effettuare le
comparazioni tra diversi sistemi sulla base di benchmark mirati a particolari applicazioni
. Esistono risultati di benchmarking per i prodotti più diffusi.

Recentemente sono stati istituiti dei benchmark specifici per misurare le prestazioni di
server Internet (transazioni di tipo HTM ed FTP). Due di questi sono InterMark del
National Software Testing Laboratory (NSTL) e Specweb96 sviluppato dallo Standard
Evaluation and Performance Council (SPEC).

La stima del prezzo di un server può essere effettuata come:


• stima di massima: prezzo per utente o per fascia di utenti (funzione del tipo di
impiego del server)
• stima dettaglio: prezzo di listino della specifica configurazione + sconti volume

In fase di pianificazione non si conosce ancora la specifica configurazione da acquisire


ma soltanto il tipo di utilizzo e il numero di utenti. Con queste informazioni si può
effettuare soltanto una valutazione di massima del prezzo.

Nella fase di acquisizione si procederà al dimensionamento più accurato dei server, a


partire dalle caratteristiche funzionali, dai volumi elaborativi e dalle prestazioni richieste
dal sistema (capacity planning). In fase di acquisizione nel capitolato vengono indicati
indici di prestazione (ad esempio numero di tpm di tipo TPC-C), caratteristiche delle
configurazioni, quantità richieste, anni di garanzia che possono essere utilizzati per
stimare più accuratamente il prezzo di mercato.

3.3.2. Prezzo per fascia di utenti


Sulla base del numero di utenti previsti si può stimare il prezzo del server facendo
riferimento a sistemi acquisiti in passato (recente) o stimando il numero di tpm TCP-C
necessario sulla base di tabelle orientative quali quella riportata nella tabella seguente
nella quale vengono riportati il numero massimo di utenti e il corrispondente numero di
transazioni tpmC fornite per le tre tipologie di server più diffuse (NT, UNIX e AS/400).
Sulla base delle prestazioni espresse in tpmC si ricercano nei listini i prezzi di modelli
con tali prestazioni.

23
Limiti di capacità e prestazioni per server SMP
(fonte Gartner Group )

L’osservatorio dei prezzi della Società SIRMI fornisce i prezzi di listino in Italia (per
configurazioni costituite da 1Mb di Ram e 50 Mb di disco per utente attivo) relativi a
sistemi midrange ripartiti in 6 fasce sulla base del numero di utenti supportato.

Nel grafico seguente sono riportati i prezzi medi di listino per utente relativi a ciascuna
fascia. Il prezzo per utente dei sistemi configurati dalla SIRMI decresce all’aumentare
del numero di utenti supportati passando da oltre 2 milioni di lire per utente per i sistemi
più piccoli a un valore di circa un milione e mezzo di lire per utente per i sistemi di
fascia superiore.

24
2500

2000

1500
presso per utente

y = 3147.9x-0.1954
R 2 = 0.6516

1000

500

0
0 20 40 60 80 100 120

numero di utenti

I prezzi sopraindicati sono relativi a configurazioni orientate ad un utilizzo gestionale


basato su applicazioni OLTP. Tali prezzi possono variare anche significativamente per
configurazioni relative ad altre modalità di utilizzo quali: sistemi alta affidabilità (fault
tolerant), sistemi dedicati a sistemi direzionali con database estratti da applicazioni
gestionali (data warehouse), server di reti.

A titolo indicativo si riporta una tabella, elaborata a partire da dati Gartner Group del
1995, che illustra le differenze di prezzo di listino delle diverse configurazioni hardware
al variare del numero di utenti e del tipo di utilizzazione del server.

L/ML
tipo configurazione n. utenti
per utente
• data warehouse 100 3,5
• OLTP alta affidabilità 100 3,5
250 2,5
• OLTP 50 1,5
100 1,1
• Workgroup server 25 1,1
150 0,6
300 0,6

Gli information provider forniscono informazioni sugli sconti praticati sul mercato per
alcune tipologie di apparecchiature.

25
Ad esempio il Gartner Group fornisce le seguenti indicazioni relative a sconti massimi
rilevati presso clienti su server HP, IBM e SUN, per impegni in acquisti pluriennali di
valore superiore a 8 miliardi di lire.

MARCA Maximum Discount


Levels
HP 9000 35 - 40 %
IBM RS/6000 32 - 38 %
Sun Microsystems 40 - 45 %

Il principale fattore che influenza il livello dello sconto praticato dai fornitori è il numero
di unità acquisite o l’importo complessivo della fornitura (vedi seguente tabella basata su
varie fonti).

quantità acquistate 1 10 100


sconto 10-20% 20-30% 30-40%

Altri fattori che influenzano gli sconti sono:


• la modalità di acquisizione
• l’interesse del fornitore ad acquisire il cliente
• la prossimità del fornitore alla chiusura dell’anno fiscale
• il grado di obsolescenza del prodotto e la prossimità alla sostituzione con nuovi
modelli
• la disponibilità sul mercato secondario di sistemi paragonabili

3.3.3. Prezzo per specifica configurazione


Nel caso si conosca la specifica configurazione che si vuole acquisire, con
individuazione anche del tipo e del numero dei processori, è possibile stimare il prezzo
unitario facendo riferimento ai prezzi di listino di modelli con le caratteristiche richieste
offerti dai principali fornitori e agli sconti medi praticati dai fornitori in funzione delle
quantità acquistate.

3.4. Personal computer

3.4.1. Valutazione per fascia

I fornitori di processori e di PC, le riviste tecniche specializzate e gli information


provider hanno introdotto classificazioni dei personal computer per tipologia di utilizzo.
La Società Gartner Group, ad esempio, ha individuato le seguenti tre fasce per Pc
desktop:

26
• entry-level: per normali applicazioni di automazione di ufficio (videoscrittura,
piccoli fogli elettronici, rari accessi a database, emulazione di terminale)
• media: per utenti evoluti che utilizzano frequentemente fogli elettronici e database,
preparano presentazioni grafiche
• alta: utilizzazioni speciali per attività di editoria elettronica, sviluppo applicazioni,
gestione grandi database o grandi modelli su foglio elettronico, grafica ad alta
risoluzione, produzione di applicazioni multimediali, ecc.

Nel settembre 1997 a queste fasce corrispondevano le seguenti 6 configurazioni con i


relativi prezzi, 3 per le aziende più attente alla innovazione tecnologica e 3 per le aziende
più attente al prezzo:

Recentemente, con il crescere della potenza elaborativa dei processori per PC al di sopra
delle esigenze degli utenti entry level, secondo il Gartner Group, sistemi considerati
entry level sono ormai adeguati anche alle esigenze degli utenti di fascia media. La
fascia entry-level è
stata pertanto fusa
con quella
intermedia. Le
configurazioni
consigliate a
gennaio 1999 sono
indicate a lato.

La Società Intel ha
individuato un
numero superiore
di fasce di utilizzo,
le più basse destinate al mercato SOHO, alle quali corrispondono diversi livelli di

27
prezzo. Periodicamente la Società Intel aggiorna le configurazioni (per l’aspetto relativo
al processore utilizzato) delle diverse fasce ed i relativi prezzi.

Nella figura seguente è riportato un esempio. I prezzi indicati non comprendono i


monitor e sono prezzi di mercato per acquisti di 1 unità.

fasce di pc
(fonte: Intel)

Sys Price
(w/o monitor ) Q3’98 Q4’98 Q1’99 Q2’99
Pentium® II Pentium II Katmai
Professional processor 100MHz FSB Katmai
processor
100MHz FSB 500 MHz 100MHz FSB
>$2.5K 100MHz FSB
500 MHz
450 MHz 450 MHz
Mainstream PentiumII Pentium II
Katmai Katmai
Performance 3 processor processor
100MHz FSB 100MHz FSB 100MHz FSB
100MHz FSB
$2.0-2.5K 400 MHz 450 MHz 450 MHz 500 MHz

Mainstream PentiumII Pentium II Pentium II Katmai


processor processor processor 450 MHz
Performance 2 100MHz FSB 100MHz FSB 100MHz FSB PentiumII proc.
$1.5-2.0K 350 MHz 450/400 MHz 450/400 MHz 450 MHz
Pentium II PentiumII Pentium II
Pentium II processor processor processor
Mainstream processor 100MHz FSB 100MHz FSB 100MHz FSB
Performance 1 333 MHz 400/350 MHz 400 MHz 400 MHz
$1.2-1.5K
Celeron™ Celeron Celeron
Celeron processor
Basic Business processor 66MHz FSB processor processor
PC 2 66MHz FSB 333/300A MHz 66MHz FSB 66MHz FSB
300 MHz 366/333 MHz 366 MHz
$900-1,200
Celeron Celeron Celeron
Basic Business processor processor processor
PC 1 66MHz FSB 66MHz FSB 66MHz FSB
<$900 300A MHz 333 MHz 333 MHz

La medesima ripartizione per fascia è applicabile ai personal computer portatili tipo


notebook.

Per quanto riguarda l’andamento dei prezzi si può ipotizzare che nei prossimi anni il
miglioramento del rapporto prezzo/prestazione continui a tassi annui del 30% con una
continua discesa dei prezzi dei diversi modelli durante il loro ciclo di vita della durata di
3 anni.

La riduzione del rapporto prezzo/prestazione si traduce, per ciascuna fascia, in prezzi


invariati (o in leggera flessione) con miglioramento delle prestazioni conseguente a
introduzione di nuovi modelli più potenti in fascia alta e slittamento nelle fasce inferiori
dei modelli presenti in precedenza nelle fasce più alte. Le maggiori prestazioni sono
richieste dalle crescenti esigenze di potenza operativa da parte del software applicativo e
delle applicazioni multimediali.

28
In funzione delle quantità acquistate, i prezzi di mercato si discostano anche
sensibilmente dai prezzi di listino.

Nella tabella sono riportati gli sconti medi praticati in funzione delle quantità acquistate.

quantità acquistate 1 10 100 1000 >1000


sconto 0-10% 10-20% 20-30% 30-40% >40%

Anche nella determinazione degli sconti dei pc intervengono gli altri fattori indicati in
precedenza nel caso dei server.

3.4.2. Valutazione della configurazione


In fase di acquisizione si dispone dei capitolati tecnici che descrivono in dettaglio le
configurazioni e si possono quindi ricercare i corrispondenti prezzi medi sui listini dei
fornitori o su osservatori pubblicati da analisti di mercato, come quello della SIRMI.
Sulla base dei volumi da acquisire e degli sconti medi di mercato si possono stimare i
prezzi unitari e l’importo complessivo previsto per la acquisizione.

3.5. Stampanti laser

3.5.1. Valutazione per fascia


Le stampanti laser sono i principali strumenti per la produzione di stampe da parte degli
utenti finali ma vengono sempre di più usate anche come stampanti di produzione. Si
possono individuare diverse fasce in funzione dell’utilizzo (individuale, dipartimentale e
di produzione) legato principalmente alla velocità di stampa.

In fasce a parte possono collocarsi le stampanti laser a colori.


Nella figura seguente viene riportata una classificazione proposta dal Gartner Group per
le stampanti laser in b/n.

Fino a 20 ppm le stampanti laser vengono utilizzate per uso individuale e per piccoli
uffici. Da 21 a 80 ppm vengono utilizzate come stampanti di rete e oltre le 80 ppm come
stampanti di produzione.

29
Si possono individuare due fasce di stampanti per uso individuale e due per quelle di
workgroup. Per ciascuna fascia è stato indicato il prezzo medio di listino a settembre
1998 relativo a stampanti in bianco e nero, formato A4, risoluzione 600x600 (fonte
Sirmi):
• fascia bassa con velocità di circa 8 pagine al minuto (prezzo medio di listino
1.200.000 lire)
• fascia alta: stampanti da 12/16 pagine al minuto (prezzo medio di listino:
2.800.000 lire)
• fascia bassa: stampanti per produrre documenti consistenti da 24 pagine al minuto
(8.000.000 A4/A3 e f/r).
• fascia medi/alta: stampanti da 40 ppm, 32 Mb RAM, A4/A3 e F/R (prezzo
30.000.00 lire)

Le principali caratteristiche che incrementano il prezzo sono:


• colore
• formati superiori all’A4
• stampa fronte/retro

Dai listini dei fornitori o dai riepiloghi predisposti dagli information provider (SIRMI,
Datapro,ecc.) è possibile individuare il prezzo medio per fascia.

30
prezzi di listino delle stampanti laser (50-900 ppm)
ppm) (fonte SIRMI)

1400000

1200000

1000000

mi
gli 800000
aia
di
lire
600000

400000

200000

0
0 100 200 300 400 500 600 700 800 900 1000
pagine al minuto

Per quanto riguarda le stampanti di produzione da 50 a 900 pagine al minuto, nella figura
seguente è riportato l’andamento del prezzo di listino in funzione della velocità di
stampa.

Gli sconti volume da applicare per le stampanti di importo limitato, acquistate in grandi
volumi, sono analoghi a quelli relativi ai personal computer.

unità sconto medio


• 1-10 15-20%
• 11-100 18-25%
• 100-1000 26-45%
• >1000 45-60%

3.5.2. Valutazione per specifica configurazione


In fase di acquisizione si dispone di un capitolato tecnico con le prestazioni e
caratteristiche tecniche richieste e si possono, pertanto, ricercare i corrispondenti prezzi
medi sui listini dei fornitori o su osservatori pubblicati da analisti di mercato, come

31
quello della SIRMI. Sulla base dei volumi da acquisire e degli sconti medi di mercato si
possono stimare i prezzi unitari e l’importo complessivo previsto per la acquisizione.

3.6. Stampanti di linea


Le stampanti di linea hanno velocità comprese tra 400 e 2000 linee per minuto. In
questo caso si possono considerare tre fasce sulla base della velocità di stampa:
stampanti da 400, da 800 e da 1200 linee per minuto.

pagine al minuto prezzo medio di listino


400 10 ML di lire
800 15 ML di lire
1200-1400 22ML di lire

Nella figura seguente è riportato l’andamento del prezzo di listino in funzione delle
pagine al minuto (elaborazione su dati SIRMI)

prezzi di listino delle stampanti di linea


(fonte SIRMI)

50000

45000

40000

35000

30000
migliaia di lire

25000

20000

15000

10000

5000

0
0 500 1000 1500 2000 2500
linee al minuto

3.7. Scanner

Si possono individuare tre fasce di scanner, oltre a quelli per uso individuale:
• scanner di fascia bassa (da 25 a 2000 pagine al giorno): simplex o duplex; gli
scanner di questa fascia sono il singolo scanner di un piccolo sistema di gestione

32
price/capacity IBM RAMAC
(Source: GartnerGroup)

DM/MB
RAMAC3+9390

2
RSA

RVA (Without Snapshot)


1
RAMAC3+9390, RVA:
first second
system system

Gbytes 500 1,000 1,500


85 percent discount assumed, systems with
average configuration
documenti, gli scanner dipartimentali in un sito con alti volumi o, infine, gli
scanner di rete; velocità 20-30 ppm in simplex e 10-15 ppm in duplex con prezzo
inferiore a 10.000$
• scanner di fascia media (da 2000 a 10000 pagine al giorno): simplex o duplex;
velocità da 30 ppm (60 immagini per minuto) a 100 ppm (200 immagini per
minuto) con prezzi da 10 a 50.000 $
• scanner di fascia alta (da 3000 a oltre 100.000 pagine al giorno): velocità da 100 a
oltre 200 ppm con prezzi da 50.000 $ a diverse centinaia di migliaia di dollari.

3.8. Sottosistemi a disco per mainframe

Per la valutazione dei prezzi dei sottosistemi di memorizzazione a disco si utilizza il


prezzo unitario di vendita per Gb utile (al netto della capacità utilizzata per protezione
RAID). Tale prezzo varia principalmente in funzione:
• del numero di Gb acquistati;
• del tipo di protezione (RAID1 più costoso ma con prestazioni superiori rispetto al
RAID5);
• della configurazione, orientata alla capacità o alle prestazioni (dipende dalla
quantità di memoria cache per Gb, capacità dei singoli dischi, numero di
controller, ecc.);

Nella figura seguente è illustrato l’effetto della capacità di un sistema sul prezzo unitario
per Gb. Al crescere della capacità il prezzo del controller, che rappresenta di fatto un
costo fisso si ripartisce su un numero sempre maggiore di dischi e pertanto diminuisce il
prezzo unitario per Gb.

33
Nel primo trimestre 1999 i prezzi unitari dei sottosistemi a disco (comprensivi di dischi,
controller, cache e canali) variano da 0,7 a 2 milioni di lire per Gb. Il valore più basso si
riferisce a sistemi di grande capacità (oltre 360 Gb) ed a configurazioni orientate alla
capacità anziché alle prestazioni; i valori più alti si riferiscono a configurazioni minime o
finalizzate a prestazioni molto elevate.
La maggior parte dei fornitori offre 3 anni di garanzia.
Oltre 1,4 Tbytes si possono ottenere prezzi più bassi di quelli indicati.

I prezzi riportati fanno riferimento a configurazioni che non comprendono funzionalità


software particolari.

Con il rapido declino dei prezzi dei dischi alcuni fornitori stanno adottando nuovi
modelli di prezzo. Una tendenza crescente è quella di far pagare separatamente moduli
software che forniscono funzionalità avanzate. Un produttore ha già adottato questo
modello di prezzi. Quando si acquista un sottosistema i prezzi aggiuntivi per le
funzionalità avanzate (ad esempio software per effettuare mirroring remoto tra due o più
sottosistemi) possono rappresentare oltre il 50% del costo del sottosistema.

La riduzione dei prezzi


medi di vendita dei
sottosistemi a disco
dovrebbe proseguire a
tassi annui del 30% con
miglioramento anche in
termini di prestazioni e di
fault-tolerance (vedi
figura a lato).

34
3.9. Sottosistemi a di sco per sistemi midrange

Nel caso dei sottosistemi a disco per server midrange i prezzi vengono generalmente
riferiti alla capacità fisica e non a quella effettivamente utilizzabile come nel caso dei
sottosistemi per mainframe.

La fascia più bassa di prezzo è costituita da dischi non protetti. Aggiungendo protezione,
disponibilità e prestazioni il prezzo può aumentare di due o più volte.

La fascia media di prezzo comprende attualmente prodotti quali Amdahl LVS,


CLARION 3000, HP Model 12H, MTI 3200 and Sun A3000.

La fascia alta di prezzo è caratterizzata da sottosistemi con funzionalità avanzate del


controller e grandi capacità di cache; comprende ad oggi i sistemi EMC Symmetrix,
HDS 7700E, Sun A7000 e IBM VSS. Alcuni di questi sottosistemi possono essere
connessi a mainframe S/390.
I sottosistemi per server hanno in genere capacità inferiore a quella di sottosistemi per
mainframe e pertanto l’incidenza del controller sul prezzo unitario per Gb è maggiore.

A fine 1998 il prezzo per Gbyte fisico varia da 350 a 700 DM, i prezzi per Gbyte utile
variano da 800 DM per grandi sottosistemi a 1.300 DM per piccole configurazioni.

La figura riportata di seguito mostra la graduale convergenza del rapporto


prezzo/prestazioni per sottosistemi S/390 e UNIX di fascia medio-alta.
Per questi ultimi gli analisti prevedono che i prezzi diminuiranno nei prossimi 3 anni

fonte:
Gartner
Group

almeno del 25% all’anno.

3.10. Librerie robotizzate


I due principali produttori sono IBM e Storagetek.

E’ difficile definire una misura comune per misurare il rapporto prezzo/prestazione del
mercato dei sottosistemi a nastro. Ci sono tre possibili criteri:

35
• prezzo per unità di trasporto (unità di lettura/scrittura)
• prezzo per cartuccia
• prezzo per capacità lorda

Ciascuno di questi indici ha una importanza specifica nelle decisioni di acquisizione.


La capacità delle cartucce è aumentata del 35-40% in media all’anno negli ultimi 10 anni
(vedi figura di seguito).

Cartridge Capacity
fonte: Gartner Group

In alcuni casi l’aumento di capacità delle cartucce richiede un aggiornamento


dell’hardware, in altri soltanto modifiche del microcodice.

In termini di prezzo per cartuccia (vedi figura seguente) i prezzi delle librerie variano da
meno di 200.000 lire (200 DM) per cartuccia a circa 70.000 lire (70 DM) per cartuccia
passando da sistemi da 1000 cartucce a sistemi da 6000 cartucce.

Aggiungendo i sistemi di trasporto (2-3 unità di trasporto ogni 1000 cartucce) si arriva a
prezzi di 300.000 lire a cartuccia (per 1000 cartucce) e di 170.000 lire a cartuccia per
6000 cartucce.

L’efficienza dei sistemi in termini di prezzo/prestazioni può variare a seconda del


criterio utilizzato. Ad esempio sistemi Storagetek Powderhorn/Timberline hanno un
prezzo inferiore per cartuccia rispetto a sistemi IBM 3494/3590 ma un prezzo per Gb
superiore (200-300.000 lire per Gb) in rapporto alla capacità complessiva in quanto le
cassette IBM Magstar (10 Gb senza compressione) hanno una capacità superiore rispetto
alle 3490E (800 Mb). Occorre comunque tener conto che il fattore di riempimento è
inferiore nel caso di cartucce di capacità elevata quali le Magstar. Anche se si assume un

36
fattore di utilizzo pari al 50% il prezzo per Gb è comunque inferiore e pari a circa 60.000
lire per Gb.

Anche i sistemi Storagetek consentono una maggiore efficienza in termini di prezzo per
Gb sostituendo ai sistemi di trasporto Timberline i sistemi Redwood, da due a tre volte
più costosi, ma in grado di utilizzare cartucce da 10 a 50 Gb.

Gli sconti per questi prodotti raggiungono il 40-50%.


Gli analisti prevedono che i prezzi migliorino del 10-20 % nei prossimi 2 anni.

3.11. Infrastruttura LAN


I costi di realizzazione di una LAN si dividono in:
• costi per il cablaggio cosiddetto “passivo” che comprende il costo dei cavi con
relativi accessori e del personale che effettua l’installazione;
• costi per il cablaggio “attivo” ovvero i costi delle apparecchiature di rete quali hub,
switch, ecc.

E’ possibile effettuare per entrambe le componenti sia una stima di massima dei costi
basata su indicatori sia una stima di dettaglio basata su una valutazione analitica delle
singole componenti di costo.

Per la stima di massima del costo per punto del cablaggio passivo si forniscono, come
esempio, alcuni riferimenti: per una piccola e semplice installazione con L5 doppino o
UTP il costo è di 150-250.000 lire per pdl; in molte installazioni i costi variano da
300.000 a 500.000 lire per posto di lavoro e possono arrivare fino a 2.000.000 di lire in
casi complessi con uso di fibra ottica.

37
Per la stima di massima dei componenti attivi quali hub, switch si possono assumere dei
costi medi per porta. Si riportano come esempio alcune tabelle (fonte Sievers Consulting
e Gartner Group) nei quali i prezzi sono riportati in marchi tedeschi e dollari USA.

Scenario dei Prezzi relativi 1H98


Tecnologia Apparecchia- Velocità Prezzo per
tura Porta
Shared Fast Ethernet Hub 100 Mbps $ 100
Switched Fast Ethernet Switch 100 Mbps $ 150
Switched TokenRing Switch 16 Mbps $ 350
Shared FDDI Concentrator 100 Mbps $ 680
Switched FDDI Switch 100 Mbps $ 3200
ATM Switch 622 Mbps $ 4200
Shared Gigabit Ethernet Hub 1 Gbps $ 1400
Switched Gigabit Ethernet Switch 1 Gbps $ 2000

Per le apparecchiature di rete la stima di dettaglio è basata sulla specifica configurazione


(prezzo di listino + sconti volume).

38
4. Stima dei costi dei prodotti software

4.1. Generalità
La stima dei costi dei prodotti software si presenta complessa per la elevata modularità
con la quale di solito vengono offerti i prodotti, le differenti formule di pricing legate
alla potenza della piattaforma hardware, al numero di utenti nominali o concorrenti, ecc.

Le stime di massima possono essere effettuate secondo due criteri principali:


• mettendo in rapporto il prezzo delle licenze software al prezzo della piattaforma
hardware alla quale sono destinate: questo criterio di stimare il costo del software
come percentuale del costo dell’hardware è adeguato soprattutto per il software di
base e d’ambiente;
• sulla base di un prezzo unitario per utente: tale criterio è il più adeguato per il
software applicativo e per alcuni prodotti middleware.

Una stima di dettaglio non può che fare riferimento ai prezzi di listino degli specifici
moduli da acquisire e agli sconti praticati sul mercato.

4.2. Software di base e d’ambiente per mainframe


Tale tipologia di software comprende sistema operativo, DBMS, TP monitor, strumenti
di sviluppo, supporto alle reti geografiche, ecc.

Nel caso dei mainframe, per tali prodotti software è possibile acquisire la licenza d’uso a
fronte di un corrispettivo una tantum (OTC: one time charge) o disporre del software in
locazione pagando canoni mensili (MLC: monthly licence charge).

La stima di massima può essere effettuata:


• in termini del costo annuo per MIPS, basato su rilevazioni o su listini prezzi;
• come percentuale del valore dell’hardware.

La stima di dettaglio si può effettuare sulla base di canoni mensili del listino del
fornitore per i singoli prodotti, con riferimento al gruppo software del sistema e al tipo di
licenza.
Su questi prodotti gli sconti, se praticati, sono molto ridotti a seconda delle politiche
commerciali del fornitore.

Per le politiche di prezzo adottate dai fornitori il costo annuo del software per unità di
potenza (MIPS) decresce al crescere della capacità del sistema (o dei sistemi se sono
connessi in modalità Parallel Sysplex).

39
Nella tabella sottostante sono riportati i costi rilevati dalle analisi di benchmarking del
Gartner Group relativi ai canoni delle licenze sofwtare IBM e della manutenzione dei
prodotti di altri vendor.

canone software di base per mainframe: licenze IBM e manutenzione ISV


(milioni di lire all’anno per MIPS installati)

fascia di capacità minimo massimo mediana


(MIPS)
<100 10,4 31,2 21,9
100-160 9,6 27,2 18,4
160-230 8,0 29,6 16,6
230-550 8,0 24,0 14,9
550-1000 5,6 22,4 14,4
>1000 5,6 17,6 11,8
Fonte: Gartner Group

Nella figura seguente è riportato l’andamento del prezzo normalizzato (1= 60 MIPS) di

una tipica suite software per MVS in funzione della potenza installata (linea chiara). Il
prezzo unitario normalizzato scende molto rapidamente fino a circa 500 MIPS, dove il
prezzo unitario è circa il 30% del valore a 60 MIPS, per poi decrescere molto
lentamente. Per mantenere competitiva la piattaforma S/390 nei confronti dei sistemi
UNIX è previsto che IBM migliori nei prossimi anni le economie di scala delle licenze
software per i grandi utenti (linea scura).

40
Nella figura seguente è riportato il rapporto del costo del software, riferito ad una suite
tipo di prodotti, rispetto al costo dell’hardware in funzione della potenza di elaborazione

del sistema (fonte Metagroup). Per un mainframe di 100 MIPS la spesa per le licenze
software, su un ciclo di vita di tre anni, è pari a circa 5 volte quella per l’hardware.
Nell’intervallo 1000-2000 MIPS questo rapporto scende a 2.
Questo grafico fornisce un esempio di come effettuare stime di massima del costo del
software in relazione a quello dell’hardware, applicando il rapporto corrispondente alla
capacità del sistema in esame.

4.3. Software di base e d’ambiente per sistema midrange

Un set standard di software per un Server Unix comprende:


• sistema operativo Unix
• compilatore C
• file system
• software di gestione del sistema

Una stima massima del costo può essere effettuata in rapporto alla spesa dell’hardware; è
possibile assumere una percentuale compresa tra il 15 e il 25% della spesa hardware
(fonte IDC).

In questo caso i costi del DBMS e di strumenti di sviluppo software sono da valutare
separatamente.

41
4.4. Software applicativo per desktop
Il sistema operativo è normalmente compreso nel prezzo di acquisto del personal
computer.
Un pacchetto di office automation (word processing, fogli elettronico, programma di
presentazione) ha un prezzo di listino di circa 1.000.000 lire con sconti fino al 50% per
oltre 1000 licenze

Nella figura è riportato l’andamento degli sconti volume praticati negli USA dalla
Microsoft per Office 97.

sconto volume MS Office 97


(fonte: Software Economics)

50
40
30
20
10
0
1 10 100 1000 10000 100000
unità

Per il pacchetto di groupware si può assumere un prezzo analogo al pacchetto di office.

Per l’eventuale software per comunicazione con host il prezzo è di circa 150-200.000 lire
per client.

4.5. DBMS
I prodotti software per la gestione di basi di dati sono i software più diffusi per
applicazioni su sistemi UNIX, principalmente per quelle distribuite di tipo mission-
critical. Vi sono fornitori specializzati e alcuni fornitori di hardware.

Negli anni più recenti la piattaforma Windows NT è diventata sempre più competitiva
come piattaforma alternativa per database sia con Microsoft SQL Server che con i
prodotti dei fornitori di DBMS per UNIX che sono stati rilasciati anche nella versione
per NT.

Dataquest stima il mercato dei DBMS UNIX pari a 3.500 miliardi di lire nel 1997, con
piccola variazione rispetto al 1996, e il mercato dei DBMS per NT, sempre nello stesso
anno, pari a 1.500 miliardi di lire, circa il doppio dell’anno precedente.

42
Fino a poco tempo fa il mercato era distinto in due fasce di prodotti: DBMS per UNIX e
DBMS per NT, i primi molto più costosi dei secondi. Per NT venivano offerte un
sottoinsieme di funzionalità rispetto a quelle per UNIX. Queste versioni a basso costo
definite “workgroup” si ponevano in competizione con i prodotti della Microsoft.

Con la crescita delle funzionalità, prestazioni e scalabilità del DBMS Microsoft e di NT


Enterprise Edition la differenziazione di prezzo è diminuita e tutti i concorrenti
dichiarano di offrire prodotti con funzionalità piena sia su Unix che su NT. Alcuni
fornitori hanno eliminato dal listino la versione “workgroup” o la offrono allo stesso
prezzo su entrambe le piattaforme.

Il prezzo di listino di SQL server Enterprise edition è in USA di $4.219 (5 volte


superiore rispetto al prezzo di 849$ della precedente versione di SQL Server) mentre la
licenza client per 5 utenti concorrenti ha un prezzo unitario di 739$ ($170 per 25 utenti).

I prezzi dei DBMS continuano di fatto ad essere diversi per i due ambienti in quanto i
fornitori tendono a offrire molte delle funzionalità più avanzate come opzioni vendute a
parte che vengono di solito usate solo su sistemi UNIX.

Il mercato dei DBMS è attualmente caratterizzato da una elevata pressione competitiva


su prezzi.

Il prezzo di listino della licenze base è pari a 2.500.000-3.000.000 lire per utente
concorrente ma gli sconti sono molto elevati e possono arrivare fino al 70-80 % (oltre
1000 copie).

I canoni di manutenzione e assistenza variano a seconda del livello di servizio;


percentuali tipiche ad applicare sono:
− 8 ore x 5 giorni: 18-20% del prezzo di listino
− 24 ore per 7 giorni: 23-25% del prezzo di listino

4.6. Prodotti di network e system management in ambienti distribuiti

Numerosi fattori influenzano il prezzo delle licenze del software per la gestione dei
sistemi distribuiti :
• la dimensione (numero di server, applicazioni e desktop gestiti) e la complessità
(piattaforme ed eterogeneità delle tecnologie) della installazione;
• le funzionalità di gestione richieste;
• il livello di integrazione desiderato;
• l’interesse commerciale del venditore.

43
Gli sconti, secondo il Metagroup, variano dal 10-15% per le piccole organizzazioni, 25-
35% per le medie organizzazioni e fino al 50% per le grandi organizzazioni
multinazionali.

I costi della implementazione e della personalizzazione variano da uno a due volte


l’investimento iniziale in software. Generalmente i fornitori indicano costi di
implementazione del 20% ma questo vale solo per i compensi pagati al fornitore per
installazioni di base. I costi addizionali delle risorse umane interne variano dal 20 al
120% del costo iniziale del software a seconda delle funzionalità installate e delle
strategie di implementazione. Il costo di manutenzione annuo medio è pari al 18% del
prezzo di listino.

A titolo indicativo vengono forniti alcuni riferimenti per il prezzo del software scontato
relativo alle funzionalità di gestione degli eventi e della disponibilità, gestione delle
prestazioni e della capacità, inventario, gestione degli asset, gestione della
configurazione e dei cambiamenti, gestione dell’help desk, distribuzione elettronica del
software, amministrazione, sicurezza, memorizzazione, schedulazione, gestione
dell’output, sulla base di uno studio effettuato dal Metagroup :
• per 1500 utenti con 5 server: 1.800.000 lire per utente
• per 15000 utenti con 800 server: 800.000 lire per utente
• per 30000 utenti con 1.700 server: 600.000 lire per utente

Aggiungendo i
costi esterni e
interni di
implementazione, i
canoni di
manutenzione, il
costo
dell’hardware
aggiuntivo e della
formazione si
arriva a costi per
client gestito da 2 a
3 volte
l’investimento in
software come illustrato nella tabella di riepilogo, posta a lato.

44
4.7. Strumenti di sviluppo applicativo

I prezzi delle licenze software possono variare sensibilmente passando da un semplice


linguaggio 4GL a uno strumento CASE e di test, a un sistema integrato di strumenti
CASE con generatori di codice che coprono l’intero ciclo di vita di una applicazione.

Alcuni valori indicativi:


• nel primo caso: 500.000 lire a sviluppatore concorrente
• nel secondo caso: 20.000.000 lire a sviluppatore concorrente
• nel terzo caso: 40.000.000 di lire a sviluppatore concorrente

4.8. Pacchetti applicativi ERP


Con la sigla ERP (Enterprise resource planning) vengono denominati i pacchetti integrati
ad ampia copertura funzionale, acquistati presso un unico fornitore in alternativa allo
sviluppo di applicazioni ad hoc. La acquisizione di prodotti ERP è diffusa non solo
presso le grandi aziende industriali ma anche presso l’utenza medio-piccola, i settori
delle utilities, delle assicurazioni e della Pubblica Amministrazione. Il grado di
diffusione presso tali settori è correlato alla “verticalizzazione” dei prodotti ERP, ovvero
alla presenza, oltre che dei moduli tradizionali di tipo orizzontale (Personale, Contabilità,
ecc.) anche di quelli specifici per tipologia di attività settoriale. Tra le ragioni che
spingono le aziende a dotarsi di soluzioni ERP ci sono: la riduzione dei costi di sviluppo
e di manutenzione, la sostituzione dei sistemi legacy esistenti con un unico prodotto,
l’allineamento alle più aggiornate tecnologie object oriented e web enabling, la
necessità di migliorare l’integrazione tra sistemi e processi.

I prodotti ERP non coprono tutte le funzionalità richieste e necessitano pertanto di un


grado più o meno elevato di personalizzazione. Secondo alcuni analisti il prezzo (di
listino) per punto funzione di un prodotto ERP è circa un decimo di quello relativo allo
sviluppo su commessa. Se al costo delle licenze software si aggiungono i costi della
personalizzazione il risparmio di costi si può ridurre fino a scendere al 50%.

I prezzi delle licenze dipendono dai moduli acquisiti e dal numero di utenti che li
utilizzano. Per contratti con almeno 500 utenti i prezzi per utente variano da 3.500.000 –
4.000.000 lire. Gli sconti rispetto ai listini variano dal 15 al 50%, ma per i contratti
superiori a 40-50 miliardi di lire si raggiungono sconti superiori scendendo al di sotto di
600.000 lire per utente (per tutte le categorie)
I canoni di manutenzione sono pari al 15% del valore delle licenze.

I servizi di implementazione comprendono: parametrizzazione e personalizzazione del


pacchetto, integrazione con il sistema informativo, messa a punto e avviamento del
sistema, formazione dei tecnici e degli utenti. Secondo Gartner Group questi costi
variano da 2 a 4 volte il costo delle licenze software.

45
5. Stima dei costi dei servizi

5.1. Generalità
La erogazione di un servizio IT richiede un processo che utilizza principalmente risorse
umane, opportunamente organizzate, e risorse tecnologiche hardware e software, e si
svolge in un ambiente tecnologico - organizzativo più o meno complesso.

Il servizio fornito può essere misurato in termini quantitativi e in termini qualitativi


definendo opportuni parametri di misura e relativi livelli di servizio.

I costi associati al servizio, o i prezzi in caso di acquisizione dall’esterno, sono legati alle
risorse umane impegnate e alle tecnologie utilizzate. La complessità dell’ambiente ed i
livelli di servizio richiesti influenzano la quantità e qualità delle risorse necessarie per
l’erogazione del servizio.

Le modalità di stima dei costi per le diverse tipologie di servizio trovano un riscontro
nelle modalità di fatturazione dei servizi acquisiti sul mercato.
Le modalità principali sono le seguenti:
• time and materials: sulla base delle risorse umane impegnate, valorizzate con una
tariffa predefinita e del rimborso degli altri costi i costi delle eventuali altre
risorse impiegate;
• fixed price: un importo complessivo predefinito stimato sulla base delle risorse
umane e tecnologiche che il fornitore ha valutato siano necessarie per erogare il
servizio richiesto;
• price per output: sulla base di un prezzo unitario per unità di output; l’output del
servizio può ad esempio essere il software applicativo sviluppato o mantenuto, i
dati registrati su supporto magnetico, le chiamate di help desk alle quali è data
risposta, i secondi di CPU per MIPS utilizzati.

Per i servizi la stima dei costi o dei prezzi di mercato si presenta generalmente più
complessa rispetto al caso dei prodotti hardware e software, specialmente in tutti i casi
nei quali non sia possibile definire una metrica per misurare in termini quantitativi
l’output del servizio e definire quindi un prezzo unitario per unità di output. Anche
quando questo è possibile, comunque, gli aspetti qualitativi che caratterizzano un
servizio possono portare a variazioni anche di un ordine di grandezza dei costi o prezzi
unitari. E’ questo ad esempio il caso del servizio di sviluppo software dove il prezzo
unitario di un punto funzione può variare da meno di 300.000 lire a più di 3 milioni di
lire (fonte: Gartner Group) in funzione di numerosi fattori che verranno illustrati nel
seguito.

La situazione è più favorevole per alcuni servizi per i quali è possibile valutare l’onere in
termini di percentuale di un importo noto: è questo il caso dei servizi di manutenzione
hardware e software, per i quali si fa riferimento al valore dei prodotti da mantenere, o
dei servizi di monitoraggio dei contratti, per i quali il riferimento è costituito dal valore
del contratto.

46
Nei casi più complessi, in particolare quelli relativi ad attività di gestione dei sistemi e
delle reti e di supporto agli utenti, la valorizzazione del costo o del prezzo del servizio
avviene sulla base del dimensionamento preventivo dell’impegno in tempo uomo.
Quest’ultimo viene stimato a partire dalle attività pianificate, dalle caratteristiche dei
sistemi da gestire e dai livelli di servizio richiesti. Ai costi delle risorse umane vanno
aggiunti i costi delle risorse necessarie alla erogazione del servizio (tecnologie, locali,
materiali di consumo, ecc.).

Una stima di costo è una opinione fondata sulla analisi e sulla valutazione soggettiva del
costo di un prodotto, di un sistema o di un servizio. Tale opinione può essere formulata
sia in modo formale che informale, con diversi metodi, ognuno dei quali parte dal
presupposto che l’esperienza sia una buona base per prevedere il futuro. In molti casi, la
relazione tra l’esperienza passata e il risultato futuro è diretta ed evidente; in altri casi è
incerta, poiché il prodotto da sviluppare o il servizio da erogare si differenzia in modo
significativo da quelli che lo hanno preceduto. La sfida consiste nel passare dal noto
all’ignoto, impiegando l’esperienza ed avvalendosi degli elementi a disposizione. Le
tecniche impiegate per la stima dei costi vanno dalla intuizione, ad un estremo, fino alla
analisi statistica più complessa, all’altro.

La scelta di una tecnica rispetto ad un’altra dipende in primo luogo dalla tipologia del
servizio da valutare ma anche dalle informazioni disponibili, più o meno dettagliate,
sulle caratteristiche dei servizi, dalla esperienza di chi effettua la stima, dal grado di
novità tecnica, dalla accuratezza della stima richiesta, dal tempo e risorse disponibili,
ecc.

Le principali tecniche utilizzate per la stima dei costi sono:


• l’esperienza personale di uno o più esperti;
• la stima per analogia;
• la stima per mezzo di procedure ingegneristiche (standard);
• la stima con tecniche statistiche .

I primi due metodi sono certamente quelli caratterizzati da più immediata applicabilità e
comprensibilità. Basati essenzialmente sulle esperienze personali di esperti operano
comparazioni tra la situazione presente e casi simili affrontati in passato. Un grosso
svantaggio della stima per analogia è il grado di giudizio che essa richiede: sono
necessarie una notevole esperienza e professionalità per identificare e utilizzare le
analogie appropriate e per fare gli aggiustamenti per le differenze evidenziate. Tuttavia,
poiché il costo della stima per analogia è basso, essa può essere impiegata per controllare
gli altri metodi e, d’altra parte, è l’unico metodo che si può impiegare in uno stadio
preliminare di sviluppo.

Alla stima per analogia si possono ricondurre le valutazioni basate sui risultati di studi di
benchmarking che consentono di stimare, in modo piuttosto accurato, i costi medi, o i
costi delle best practices, e le risorse utilizzate per la erogazione di servizi IT facendo

47
riferimento a organizzazioni analoghe, caratterizzate cioè da caratteristiche simili sia
quantitative che qualitative dei sistemi da sviluppare o da gestire e dei livelli di servizio.
La accuratezza della stima è legata alla dimensione ed aggiornamento della base dati di
riferimento e alla scelta dei parametri in base ai quali vengono selezionati i gruppi di
confronto.

Le procedure di tipo tecnico/ingegneristico, simili a quelle con cui si preventivano i costi


in una produzione industriale, si basano sulla scomposizione delle attività da svolgere e
dei materiali richiesti in singoli elementi ai quali vengono assegnati i costi sulla base di
tempi e costi standard. Molti elementi di costo, come la manutenzione e il controllo
vengono calcolati come percentuali del lavoro di produzione richiesto.

Il metodo statistico di stima del costo può utilizzare delle tecniche statistiche che vanno
dal semplice tracciato grafico di curve alla analisi complessa di correlazione multipla. In
entrambi i casi, l’obiettivo consiste nel trovare una relazione funzionale tra i mutamenti
nei costi e il fattore, o i fattori, dai quali il costo stesso dipende.

I metodi che prevedono l’utilizzo di equazioni parametriche richiedono un lavoro


complesso in sede di studio dei dati storici e di scelta delle variabili significative. Segue
quindi la fase di calcolo dei coefficienti, al termine della quale, l’applicazione è piuttosto
semplice.

Sebbene le tecniche statistiche di stima del costo siano in molte circostanze preferite ad
altre, vi si può ricorrere solo quando sono disponibili i dati necessari per una base storica
sistematica. I dati raccolti in attività di benchmarking vengono spesso utilizzati per
ricavare equazioni parametriche.

La stima dell’impegno per i sistemi già in esercizio si basa sull’esperienza passata. Per i
nuovi sistemi si possono utilizzare stime per analogia (le più accurate e costose
richiedono analisi di benchmarking,), stime basate su parametri standard e tecniche
statistiche se disponibili.

La valorizzazione del tempo uomo impegnato viene effettuata a costi standard o a tariffe
di mercato a seconda che il servizio venga erogato internamente o da fornitori esterni; le
altre risorse vengono valorizzate a prezzi di mercato.

5.2. Servizi per la realizzazione di studi di fattibilità

5.2.1. Impegni, tempi e costi di uno studio di fattibilità


La realizzazione di uno studio di fattibilità deve essere necessariamente un'attività di
breve durata, data in generale l’urgenza di arrivare alla produzione del documento e alla
disponibilità delle informazioni da produrre. Una breve durata è inoltre connaturata al
carattere sintetico e “direzionale” del documento da produrre, per il quale sono inutili e
spesso negative eccessive lungaggini. L’esperienza porta ad indicare un periodo

48
variabile da uno a quattro mesi per la durata delle attività relative ad uno studio, periodo
che ovviamente varia in relazione alla complessità e alle dimensioni del progetto da
analizzare.

Questa durata è da intendersi come durata netta, ossia non comprensiva di eventuali fasi
iniziali di conferimento dell’incarico e di avvio dei lavori e di eventuali fasi finali di
esame, valutazione e accettazione del lavoro da parte del committente.

L’impegno complessivo necessario alla produzione dello studio di fattibilità può variare
dal doppio a quattro volte la durata temporale dello stesso. Questo significa che è da
prevedersi l’impegno medio per l’intera durata del lavoro di due - quattro persone.

Anche questa stima di impegno, sempre derivante dall’esperienza, varia in conseguenza


della tipologia di progetto da analizzare e della complessità e dimensione del progetto. I
fattori che maggiormente incidono sull’impegno necessario sono:
• il numero delle persone da intervistare (responsabili e addetti di unità
organizzative utenti coinvolte nel progetto, personale delle unità periferiche,
responsabili di funzioni di staff interessate...);
• l’eventuale necessità di procedere ad una ricognizione dell’offerta di mercato (in
particolare quando si deve esaminare la possibilità di acquisizione di pacchetti);
• la complessità di nuovo software applicativo ad hoc da progettare e stimare;
• la complessità delle operazioni di dimensionamento dei sistemi.

Ma l’aspetto principale che può incidere è certamente la qualità e la completezza delle


informazioni iniziali. E’ ovvio infatti che se l’effettuazione dello studio di fattibilità
impone di ricostruire situazioni poco note e mal documentate, questa attività può
incidere pesantemente sull’impegno. Le indicazioni di impegno e durata fornite si
riferiscono pertanto a situazioni medie e quindi l’impegno necessario può aumentare
anche considerevolmente se si attribuiscono impropriamente allo studio di fattibilità
attività di ridocumentazione di sistemi informatici esistenti o di prima rappresentazione e
analisi di processi di servizio mai esaminati.

Il costo dello studio di fattibilità discende direttamente dalle considerazioni relative


all’impegno, in quanto le prestazioni professionali costituiscono la parte assolutamente
preponderante dell’insieme delle risorse necessarie all’effettuazione dello studio.

5.2.2. Le figure professionali necessarie


Il responsabile del gruppo di lavoro per lo studio di fattibilità deve essere una persona di
elevata cultura ed esperienza. Tra le sue capacità professionali ci deve essere:

• capacità di interlocuzione a livello di top management e di direzione operativa;


• conoscenza generale delle opportunità di cambiamento offerte dalla tecnologia
informatica e telematica avanzata;

49
• conoscenza approfondita di metodi e tecniche per la pianificazione dei sistemi
informativi e l’elaborazione di studi di fattibilità;
• conoscenza delle problematiche organizzative connesse all’utilizzo dei sistemi
informatici;
• conoscenza approfondita di metodi, tecniche e strumenti per pianificazione, la
realizzazione e la conduzione di progetti informatici;
• conoscenza approfondita di metodi e tecniche per la gestione di sistemi informativi
complessi.

In presenza di specifiche problematiche di riorganizzazione e ridisegno dei processi


diventa importante la conoscenza di metodi, tecniche e strumenti per la pianificazione e
la gestione di progetti integrati e multidisciplinari (Change Management)

L’ampiezza e la profondità delle altre professionalità necessarie variano ovviamente


secondo la dimensione e la complessità del progetto e sono diverse per le varie tipologie
di progetto, in particolare tra progetti tesi alla costruzione di sistemi applicativi e progetti
di natura essenzialmente tecnologica.
Tutti i partecipanti al gruppo di lavoro, con l’esclusione, negli studi più complessi, di
una persona che può essere dedicata all’attività di editing e confezionamento della
documentazione, debbono comunque essere persone di buona esperienza e
qualificazione. Tra le professionalità necessarie potranno annoverarsi:
• competenza in organizzazione e analisi dei processi;
• competenza in analisi e progettazione di sistemi applicativi;
• competenze per la definizione di architetture tecnologiche;
• competenza sistemistica per la progettazione e dimensionamento di basi di dati, reti,
sistemi elaborativi;
• conoscenza di specifiche aree applicative;
• conoscenza dell’offerta di mercato in particolari settori;
• competenza sulle problematiche dell’esercizio dei sistemi e della conduzione dei
CED;
• competenza di procedure di acquisizione;

5.3. Servizi di sviluppo software

5.3.1. Le fasi di un progetto di sviluppo del software e i metodi di stima dei costi
La costruzione del software si articola in diverse fasi. Nel modello di costi del piano
esposto in precedenza i costi di sviluppo sono articolati in quattro voci corrispondenti a
fasi del ciclo di vita del software, avviate dopo lo studio di fattibilità:
• costi di analisi e progettazione;
• costi di realizzazione;
• costi di collaudo;
• costi di messa in produzione.

50
In questo paragrafo si tratterà della stima del costo complessivo di sviluppo di
applicazioni software riferito a tutte le fasi elencate compresi i costi per la messa in
produzione su un sito pilota. I costi per la eventuale estensione su altri siti devono essere
stimati a parte (vedi paragrafo apposito).

Nel caso si voglia stimare il costo relativo ad una singola fase si può ricorrere al metodo
delle proporzioni tra le varie attività del ciclo di vita che consiste nel calcolare il costo
totale, con uno dei vari metodi disponibili, e quindi ripartirlo sulle singole fasi secondo
percentuali predefinite. Questo approccio si fonda sull’ipotesi che, nell’ambito di una
data organizzazione, la distribuzione delle quantità di lavoro, necessarie nelle differenti
fasi dello sviluppo di un sistema è mediamente la stessa, ossia presenta poche variazioni
da un progetto all’altro. In assenza di un archivio storico dei progetti si possono
utilizzare i numerosi dati disponibili in letteratura.

Le principali tecniche utilizzate per la stima dei costi di sviluppo del software sono:
• l’esperienza personale di uno o più esperti;
• la stima per analogia;
• la stima per mezzo di parametri standard di produttività;
• la stima con tecniche statistiche (ad es. modello COCOMO).

Negli ultimi due casi occorre preventivamente disporre di stime delle dimensioni dei
programmi, valutate secondo opportune metriche, e quindi si possono applicare solo
dopo che il nuovo sistema è stato definito nelle sue componenti. In fase di
pianificazione, per i progetti per i quali non sono stati effettuati gli studi di fattibilità, si
può ricorrere soltanto ai primi due metodi.

Nel seguito viene illustrato come effettuare la stima dei costi di un progetto di sviluppo
software, svolto da un gruppo interno o affidato a un fornitore di servizi, a partire dalla
valutazione anticipata della dimensione del prodotto finale da realizzare e di stime di
produttività del team di sviluppo.

5.3.2. La dimensione: LOC


La determinazione della dimensione del software sviluppato è un problema complesso.
In passato l'unità di misura utilizzata era il numero di linee di codice sorgente (LOC).

In effetti i primi linguaggi macchina richiedevano molto tempo per la codifica dei
programmi, rispetto alle funzioni svolte, che sembrò appropriato misurarne lo sviluppo
sulla base delle linee di codice realizzate. Anche nei linguaggi di terza generazione
(Cobol, Fortran, ecc.) lo sforzo inerente la codifica, specialmente in assenza di generatori
automatici o efficienti strumenti Case, rimane significativo. La riduzione della parte del
tempo dedicata alla codifica e la potenzialità dei più recenti linguaggi (come C++ o
Visual Basic) nella riduzione della scrittura di codice fanno prestare maggiore attenzione

51
a quantificazioni non centrate sulla codifica e sull’ambiente tecnologico, ma sulle
funzionalità del software.

Negli anni più recenti si è così ravvivato l’interesse verso un metodo di quantificazione
nato alla fine degli anni Settanta, ideato da Allan J. Albrecht in ambito IBM.

5.3.3. La dimensione: i punti funzione o Function Point


Tale tecnica di misurazione di tipo funzionale, definita “Function Point” da Albrecht,
quantifica le funzionalità fornite dal software in termini di dati e processi significativi
per gli utenti finali dei sistemi.

La misura dei punti funzione di un progetto o di una applicazione software presenta i


seguenti vantaggi:
• sufficientemente oggettiva;
• valutabile precocemente rispetto alla realizzazione del codice;
• legata più al “cosa fare” che al “come farlo”;
• abbastanza indipendente dalle tecnologie implementative.

La metrica dei Function Point (FP) è utilizzata per valutare la dimensione dei programmi
applicativi da realizzare e mantenere e per misure di produttività del personale impiegato
nello sviluppo.

Dei diversi metodi di conteggio disponibili per il conteggio dei punti funzione di un
progetto di sviluppo e manutenzione (evolutiva) software, il più utilizzato è quello
proposto dall’IFPUG (International Function Point User Group).

Inizialmente si calcolano gli unadjusted function points (UFP), una metrica di “pura
funzionalità”, che dà una indicazione dell’ampiezza del sistema in termini di funzioni.
Questa metrica si applica una volta che è stata elaborata l’analisi funzionale del sistema e
quindi gli elementi fondamentali che ne costituiscono la visione “esterna” (pannelli,
tabulati, archivi) sono noti.

E’ basata su tabelle che assegnano un peso a ciascuno dei cinque elementi fondamentali
costituenti il sistema:
• internal logical file (ILF)
• external interface file (EIF)
• external input (EI)
• external output (EO)
• external inquiry (EQ)

Ciascun elemento viene pesato in modo diverso a seconda che sia valutato semplice,
medio o complesso (sulla base di apposite tabelle). Nella tabella seguente è riportato lo
schema di calcolo degli UFP.

52
Tipo Bassa Media Alta Totale
EI …….. x 3 + …….. x 4 + ……… x 6 =
EO …….. x 4 + …….. x 5 + ……… x 7 =
EQ …….. x 3 + …….. x 4 + ……… x 6 =
ILF …….. x 7 + …….. x 10 + ……… x 15 =
EIF …….. x 5 + …….. x 7 + ……… x 10 =
Totale UFP

Si calcolano quindi gli Adjusted Function Points (FP) del sistema moltiplicando gli UFP
per il fattore di aggiustamento, compreso tra 0,65 e 1,35. Il fattore di aggiustamento
viene calcolato sulla base di 14 caratteristiche generali del sistema alle quali viene
assegnato un punteggio su una scala da 0 a 5 a seconda della influenza del fattore sulla
complessità del sistema (0 = nessuna influenza e 5 = elevata influenza):

− comunicazione dati − aggiornamento interattivo


− distribuzione della elaborazione − complessità elaborativa
− prestazioni − riusabilità
− utilizzo intensivo della − facilità di installazione
configurazione − facilità di gestione operativa
− frequenza delle transazioni − molteplicità di siti
− inserimento dati interattivo − facilità di modifica
− efficienza per l’utente finale

5.3.4. Il rapporto tra FP e LOC


I FP forniscono una misura delle dimensioni del software da sviluppare. Esistono indici
di produttività basati sul numero dei FP. Altre volte, si usa "tradurre" il numero di FP in
LOC, utilizzando parametri di conversione differenti a seconda del linguaggio utilizzato,
e procedere successivamente alla valutazione dell'impegno, sulla base di indici di
produttività per LOC.

53
Nella tabella seguente è riportato per alcuni linguaggi di sviluppo il numero di istruzioni
che corrispondono in media ad un punto funzione (fonte: Capers Jones).

corrispondenza tra punti funzione e linee di codice

Linguaggio istruzioni per FP istruzioni per FP


Assembler 320 5.3.4.1. Ling
C 128 uag
Cobol e Cobol II 107 gio
Pascal 91 C++ 53
PL/1 80 Java 53
Fortran 95 71 Visual Basic 5 29
Smalltalk 21
SQL 13
Lotus 123/MS Excel 6

5.3.5. La stima dell’impegno


Una volta stimata la dimensione prevista del software da sviluppare si passa alla stima
dell’impegno richiesto. Questo può avvenire applicando opportuni parametri di
produttività o mediante equazioni parametriche.

Come molti autori hanno evidenziato, anche attraverso studi empirici, tra impegno di
sviluppo e dimensione di una applicazione software esiste una relazione di dipendenza
funzionale. E’ comunemente accettato che la dimensione sia il cosiddetto “driver
primario” della relazione funzionale. Questo significa che le variazioni della dimensione
sono quelle che determinano in misura maggiore le variazioni dell’impegno collegato.

Ma la relazione tra dimensione e impegno, e quindi costo di produzione, non è un


rapporto costante espresso da un valore di produttività media. Il legame tra dimensione e
impegno è mediato da una serie di fattori che possono mutare in modo estremamente
significativo il rapporto di produttività.
I principali fattori sono:
• linguaggio di programmazione
• piattaforma tecnologica
• classe di rischio dell’applicazione
• qualità attesa
• complessità e innovazione del problema da risolvere
• dimensione delle applicazioni
• esperienza del team di sviluppo
• metodologia di lavoro
• utilizzo di strumenti CASE
• grado di riuso di funzionalità già esistenti.

54
Nel caso di acquisizione del servizi di sviluppo all’esterno occorre inoltre considerare
che nella relazione tra prezzo praticato e costo di produzione intervengono
considerazioni di mercato e commerciali che a parità di produttività ( e quindi del costo
di produzione) possono di volta in volta portare a variazioni del prezzo per punto
funzione effettivamente praticato.

Tra i fattori elencati in precedenza una influenza rilevante sulla produttività è esercitata
dal linguaggio di sviluppo.
LANGUAGE LEVEL PRODUCTIVITY AVERAGE
PER STAFF MONTH La correlazione esistente tra
il livello di un linguaggio e
-------------- -------------------------
la produttività di sviluppo
• 1-3 5 to 10 Function Points non è lineare. I benefici si
• 4-8 10 to 20 Function Points ottengono principalmente
• 9 - 15 16 to 23 Function Points nella fase di codifica e, in
• 16 - 23 15 to 30 Function Points misura minore, in fase di
• 24 - 55 30 to 50 Function Points integrazione e test. Per
• Above 55 40 to 100 Function Points progetti molto grandi,
queste attività ammontano a
circa il 30% dell’impegno.

Nella tabella a lato (fonte: Capers Jones) vengono riportati i valori medi di produttività
in corrispondenza dei diversi livelli del linguaggio di programmazione.

Dall’analisi di casi reali risulta che l’utilizzo di strumenti CASE, in presenza di una
adeguata metodologia e di linguaggi ad alto livello, può portare a raddoppiare al
produttività nello sviluppo del software rispetto al caso in cui non si utilizzino strumenti
CASE.

Valori indicativi di produttività espressa in function point per mese/uomo, per lo


sviluppo di sistemi informativi automatizzati, sono riportati in tabella (fonte: Capers
Jones):

senza impiego di metodi con impiego di metodi strutturati 5


linguaggio strutturati
senza CASE con CASE senza CASE con CASE
basso livello6 5-8 6-12 7-14 10-20
alto livello7 10-15 12-30 13-50 25-100

5
La frase “metodi strutturati” indica la aderenza rigorosa a una delle tecniche strutturate note quali i metodi di
Yourdon, Warnier-Orr, Gane e Sarson, Martin ecc.
6
Qualunque linguaggio con più di 100 istruzioni per punto funzione (Cobol, Fortran, C, ecc.)
7
qualunque linguaggio con meno di 50 istruzioni per punto funzione

55
Per ciascuna combinazione di fattori sono riportati i valori minimi e massimi che può
assumere la produttività in funzione della esperienza del gruppo di progetto
relativamente a linguaggi, metodologie e tools di sviluppo utilizzati e allo specifico
dominino applicativo.

Sarebbe opportuno che i valori di produttività più adeguati per lo specifico caso
venissero determinati a partire dai dati relativi ai progetti passati memorizzati in un
archivio storico sufficientemente grande da poter fornire una base statistica di riscontro e
un modello credibile di riferimento per l’ambiente a cui si riferisce. In assenza di un
archivio storico significativo o nei casi di progetti innovativi per i quali non ci siano
precedenti interni ai quali fare riferimento si può fare riferimento ai risultati di attività di
benchmarking svolte da società specializzate (Gartner Group, Compass, Nolan Norton,
ecc.) o da organismi non profit quali l’International Software Benchmarking Standard
Group (ISBSG).

L’ISBSG è una associazione degli organismi nazionali di metrica del software (Italia
/GUFPI, USA/IFPUG, UK/UFPUG, Olanda/NESMA, Australia/ASMA, New
Zealand/SMANZ, ecc.) che definisce standard di benchmarking, tiene aggiornato un
repository di dati conformi allo standard alimentato gratuitamente da gruppi di progetto
di tutto il mondo e pubblica periodicamente i risultati della attività di benchmarking.

La versione 5.0 del repository contiene informazioni relative a 440 progetti.

Nelle tabelle seguenti sono riportati i valori minimi, massimi e medi dell’imp egno
necessario per la realizzazione di un punto funzione, espresso in ore uomo, in funzione
del linguaggio utilizzato e della piattaforma tecnologica. I dati sono tratti dal più recente
rapporto dell’ISBSG.

min. mediana max.


Mainframe totale 0,9 8,7 68,9
3GL (terza generazione) 0,9 11,0 48,1
4GL (quarta generazione) 0,9 7,4 39,8
ApG (generatore) 0,9 7,4 39,8
Midrange totale 0,7 5,5 23,0
3GL 0,8 6,9 21,9
4GL 0,7 4,6 23,0
ApG 1,3 2,4 5,8
PC totale 0,2 2,9 59,4
3GL 0,9 7,5 59,4
4GL 0,2 2,3 3,2

La tabella mette in luce l’effetto del linguaggio e della piattaforma sulla produttività.
Emerge una differenza significativa tra 3GL e 4GL con i 3GL che presentano
produttività inferiore ai 4GL. L’effetto della piattaforma è altrettanto evidente: la

56
mediana relativa ai linguaggi 4GL passa da 7,4 ore per FP in ambiente mainframe a 4,6
in ambiente midrange ed 2,3 in ambiente PC.

Per quanto riguarda la relazione tra dimensione del progetto e produttività, di solito
viene scartata l’ipotesi di una
relazione lineare e la risposta che
Produttività in funzione della si dà convenzionalmente è che il
dimensione (NESMA) costo cresce esponenzialmente con
25 la complessità, cioè:
20
produttività 15 costo = F(dimensione)n con n>1
(FP/MU) 10
5
0
In realtà una attenta analisi dei dati
750-1000

>1500
<100

1000-1500
100-250

250-500

500-750

dimostra che, benché sia vero che


le dimensioni del progetto
dimensione del sistema (FP) introducano un fattore di
complessità più che proporzionale
alle dimensioni del progetto, è
anche vero però che le attività di processo sono ammortizzate meglio sui progetti medio-
grandi che su quelli piccoli. Alcune analisi di benchmarking (Nesma – Olanda) hanno
evidenziato che la curva di produttività ha in realtà una forma ad U con un massimo
corrispondente ad una dimensione intermedia. Esiste cioè una dimensione ottimale dei
progetti, tale che i progetti più piccoli sono meno produttivi per l’incidenza delle spese
fisse di processo, mentre i progetti più grandi sono meno produttivi per il fattore
esponenziale dovuto alla complessità.
La dimensione ottimale varia da ambiente ad ambiente in funzione della tipologia di
progetto.

In alternativa all’utilizzo di un parametro di produttività da definire sulla base delle


considerazioni illustrate è possibile stimare l’impegno necessario per un progetto
software utilizzando in successione alla stima dei punti funzione il modello COCOMO
(Constructive Cost Model) che è il più referenziato e quasi unico studio pubblico basato
sulla analisi multifattoriale di un database di benchmarking.

Il modello COCOMO richiede in input una stima della dimensione della applicazione da
sviluppare misurata in linee di codice. Se si è in possesso di una stima dei punti funzione
è possibile convertire questi in linee di codice del linguaggio che si intende utilizzare
nello sviluppo, mediante gli opportuni rapporti di conversione (ad es. quelli forniti da
Capers Jones). Si applica quindi il modello COCOMO che sulla base dei valori fattori di
costo riferiti al caso in esame determina l’effort necessario per lo sviluppo. Applicando
delle opportune tariffe di mercato o costi standard interni si determina il costo del
progetto.

57
5.3.6. La stima del costo
La stima del costo di sviluppo può essere effettuata:
1. nel caso di sviluppo interno, sulla base dell'impegno previsto per il team di sviluppo
e del costo del mix di figure professionali impiegate; a questo costo vanno aggiunti i
costi delle risorse hardware e software utilizzate per lo sviluppo;
2. nel caso di sviluppo affidato all’esterno l’importo può essere stimato direttamente
sulla base del prezzo per punto funzione (adeguato per il caso specifico)
comprensivo dei costi dell’ambiente di sviluppo.

Se non si dispone di riferimenti di mercato dei prezzi praticati per punto funzione,
anche nel caso di sviluppo affidato all’esterno si può passare attraverso stime
dell'impegno e tariffe professionali di mercato.

I valori di produttività rilevati dall’ISBGS, riportati in precedenza, sono coerenti con i


prezzi offerti in recenti gare (circa 500.000 lire per FP con linguaggio 4GL su
piattaforma midrange e circa 1.000.000 di lire per FP per lo sviluppo con linguaggi 3GL
su piattaforma mainframe).

Per quanto riguarda le tariffe del team di sviluppo si rimanda al paragrafo apposito.

5.3.7. La stima dei costi di sviluppo nelle diverse fasi del ciclo di vita dei SIA
Nelle fasi alte del ciclo di vita (piano) è difficile che si disponga di informazioni
dettagliate che permettano l’applicazione di tecniche per la stima dell’impegno di
sviluppo che richiedono preventivamente una stima della dimensione della applicazione
basate sui punti funzione o sulla determinazione delle linee di codice da sviluppare; la
valutazione dei costi si basa in questo caso sull’analogia con precedenti realizzazioni.

Per poter stimare la dimensione con un grado accettabile di precisione occorre avere una
descrizione sufficientemente dettagliata delle caratteristiche del sistema da realizzare.

Sono state sviluppate delle metodologie, anche implementate in strumenti software, per
effettuare un conteggio anticipato dei punti funzione in uno stadio iniziale del ciclo di
vita del software sulla base di un numero limitato di informazioni relative ai dati e alle
funzioni.

Nello studio di fattibilità si dovrebbe arrivare a stimare la dimensione della applicazione


da realizzare preferibilmente secondo la tecnica dei punti funzione. I risultati della stima
servono poi in fase di gara per fornire indicazioni ai fornitori sulle dimensioni delle
applicazioni da realizzare e per definire l’importo massimo della fornitura, calcolato
moltiplicando il numero di punti funzione per un prezzo unitario che tenga conto delle
specificità del progetto e dell’andamento del mercato.

58
5.4. Servizi di formazione e addestramento
Le attività di formazione ed addestramento degli utenti finali o del personale informatico
danno luogo sia a costi diretti che a costi indotti in quanto richiedono docenti e materiali
(costi diretti) ma occupano anche il tempo dei partecipanti (costi indotti).

Le attività formative rivolte agli utenti finali sono legate all’avvio di progetti di
informatizzazione di vario tipo:
• revisione o sostituzione di un sistema preesistente;
• estensione a nuovi utenti di un sistema preesistente;
• automazione di ufficio;
• informatizzazione di attività precedentemente non supportate da sistemi
informatici (sia attraverso lo sviluppo di nuove applicazioni che la acquisizione di
pacchetti applicativi).

I costi di formazione dipendono in questo caso dall’entità del mutamento introdotto dal
sistema nelle prassi operative e dal numero degli utenti interessati da questo mutamento.
Quanto più variano le prassi operative, tanto maggiori sono le azioni richieste di
addestramento e formazione; quanto maggiore poi è il numero e quanto più vasto è
l’assortimento delle utenze interessate, tanto maggiore è il costo indotto dall’avviamento
del sistema.

Una attività continua di formazione del personale informatico è necessaria ai fini


dell’aggiornamento del personale stesso. Tale attività viene intensificata nelle fasi di
avvio di progetti particolarmente innovativi dal punto di vista delle piattaforme
tecnologiche, degli ambienti di sviluppo e di produzione utilizzati o degli strumenti per
la gestione dei sistemi.

In accordo con le considerazioni esposte, nel modello dei costi esposto in precedenza, la
formazione degli utenti è inserita tra i costi di sviluppo, mentre la formazione del
personale informatico tra i costi di esercizio.

La stima dei costi diretti di formazione, oggetto di questo paragrafo, può essere
effettuata in fase di pianificazione, come stima di massima basata sulle informazioni in
possesso, o in momenti successivi (studi di fattibilità e gare), in modo più accurato, sulla
base di piani dettagliati.

5.4.1. Stima di massima


I costi della formazione utenti possono essere dedotti in via approssimativa in base al
numero del personale della amministrazione che verrà interessato dai progetti il cui
avvio è previsto nel periodo di pianificazione.

Una prima stima di massima può essere effettuata considerando un costo fisso di
formazione per persona da moltiplicare per il numero di persone da addestrare e formare.
Tale costo può essere ricavato sulla base di esperienze precedenti.

59
Una stima più accurata può essere effettuata stimando i giorni di formazione necessari
per le diverse tipologie di utenti, per i diversi progetti nei quali sono coinvolti. La
valorizzazione può quindi avvenire in base a un costo standard di formazione per
giorno/allievo (200-300.000 lire) eventualmente differenziato sulla base della maggiore
o minore complessità dei corsi previsti.

Per quanto riguarda i costi per la formazione del personale informatico si può assumere,
in assenza di altre informazioni, un numero di giornate annue variabili da 10 a 15.
Questo valore è considerato ottimale da alcuni analisti anche se risulta che il numero
medio di giornate di formazione del personale informatico effettivamente realizzate dalle
aziende è di circa 6 giorni all’anno.

5.4.2. Stima di dettaglio


Le valutazioni di dettaglio si basano sui piani di formazione predisposti dalla
amministrazione, opportunamente valorizzati secondo i criteri esposti nel seguito.

La formazione in aula può avvenire mediante la partecipazione del personale a corsi


organizzati a calendario da fornitori di prodotti informatici o da società specializzate
presso le proprie sedi ed aperti anche a personale di altre organizzazioni o tramite corsi
su commessa, dedicati al personale di una specifica società o ente, che sono i tipici corsi
relativi all’utilizzo di applicazioni sviluppate su commessa.

Questi corsi sono economicamente e didatticamente preferibili, anche per contenuti


trattati in corsi standard, ogni qual volta il corso interessi un numero elevato di utenti che
possono partecipare contemporaneamente. Consentono inoltre la personalizzazione in
termini sia di contenuti che di durata ed orari in funzione delle esigenze degli utenti.

I costi dei corsi su commessa sono funzione:


• della natura del corso (complessità e specificità);
• durata del corso e numero di edizioni;
• la sede (presso il fornitore o presso il cliente);
• il numero e caratteristiche dei kit didattici da distribuire;
• l’eventuale esigenza di trasferte dei docenti.

Il costo di progettazione di un corso può essere valutato in riferimento alla durata del
corso stesso e alle tariffe delle figure professionali coinvolte secondo la formula:

rapporto gg progettazione/gg corso x giorni di corso x tariffa media lire/GU

dove per il rapporto tra giorni di progettazione e giorni di corso si possono assumere i
seguenti valori:
• 0-2 per l’addestramento su prodotti standard o formazione su temi generali

60
• 3-10 nel caso di addestramento su applicazioni custom o formazione tematica su
temi specifici del cliente

Il costo di erogazione del corso comprende il costo dei docenti, del materiale didattico,
dell’aula e l’eventuale trasferta dei docenti secondo la formula:

giorni aula x tariffa docente lire/GU + giorni aula x costo aula + costo materiale didattico
x n. partecipanti + eventuali trasferte

dove per la tariffa giornaliera del docente si può assumere un importo da 700.000 a
1.200.000 lire per l’addestramento su prodotti e da 1.000.000 a 1.500.000 lire per la
formazione tematica e per il costo dell’aula un costo da 200.000 lire/g a 700.000 lire/g.

Negli ultimi anni è cresciuto l’utilizzo di corsi su supporto multimediale ed interattivi, in


alternativa, o più spesso a complemento, delle attività di formazione in aula.

Per i costi dei prodotti per il computer based training (CBT) si possono fornire i seguenti
riferimenti:
• per i CBT offerti sul mercato i prezzi variano da 200 a 300 mila lire per i CBT
relativi all’utilizzo di prodotti di produttività individuale a circa 2.000.000 di lire
per CBT relativi ad ambienti di sviluppo o problematiche complesse; questi
prodotti sono soggetti a elevati sconti volume;
• per i CBT realizzati su commessa il costo di realizzazione è valutato in media pari
a 30 gg/persona per ogni ora di fruizione del corso multimediale con tariffa
giornaliera di 1.000.000 di lire; sulla produttività media indicata incidono le
caratteristiche dell’applicazione quali numero di colori , percentuale e qualità
della grafica, risoluzione, suono, tipo di percorso didattico, grado di interattività,
presenza di test, simulazione, animazione.

5.5. Servizi per il collaudo e la messa in produzione


L’avviamento di una applicazione software, sia sviluppata ad hoc, che acquisita come
pacchetto applicativo opportunamente personalizzato, comporta non solo la formazione
del personale, ma anche un insieme di attività per completare e formalizzare la
documentazione di sistema, allestire la piattaforma per il collaudo, effettuare il
caricamento dei dati, progettare i job batch, definire le procedure di ripristino, ecc.

Nella costi di sviluppo del software, la cui stima è stata trattata in un paragrafo
precedente, sono generalmente comprese le fasi che vanno dalla analisi dei requisiti alla
messa in esercizio su un sito pilota.

Le attività connesse alla diffusione delle applicazioni su più siti devono essere valutate a
parte. Il costo di avviamento è pari al valore del tempo-uomo impegnato, sia interno che
esterno, e di eventuali altre risorse necessarie. La stima preventiva dei costi richiede
pertanto una pianificazione delle attività sulla base di informazioni ambientali (numero

61
di siti e di utenti) e tecniche (complessità delle applicazioni e dell’hardware, esigenza di
paralleli, dati da caricare, ecc.).

Nel caso di amministrazioni distribuite geograficamente e funzionalmente i costi di


diffusione possono superare e di molto i costi di sviluppo.

5.6. Servizi di monitoraggio

5.6.1. Stima del costo del monitoraggio


Il monitoraggio consiste nella attività di verifica in corso d’opera dell’andamento dei
contratti.

Nella Pubblica Amministrazione Centrale italiana il monitoraggio dei contratti di grande


rilievo relativi a fornitura di beni e servizi basati su Information Technology è stato
istituito dal D.Lgs. 39/93 (art. 13, comma 2). I contratti di “grande rilievo” che devono
essere obbligatoriamente sottoposti a monitoraggio sono stati individuati in prima istanza
dalla circolare Aipa/Cr/3 del 28.10.1993 e successivamente sono individuati di volta in
volta dalla Autorità in sede di parere di congruità tecnico-economica emesso da AIPA ai
sensi dell’art.8 del D.Lgs. 39/93. Il monitoraggio può essere comunque anche attivato
autonomamente dalle Amministrazioni Pubbliche committenti di contratti di particolare
criticità, per costi, soluzioni tecnologiche innovative, connessioni con altri progetti
rilevanti, importanza strategica per l’azione della Amministrazione.

Il monitoraggio può essere appaltato dalle Amministrazioni, tramite gara, oppure può
essere svolto autonomamente da personale interno dell’Amministrazione, purché sia
salvaguardata l’indipendenza di giudizio del monitore e la sua preparazione tecnica.

La normativa caratterizza l’attività di monitoraggio come una verifica in corso d’opera


sull’andamento dei contratti, finalizzata alla prevenzione dei problemi, che viene attuata
rilevando con continuità e tecniche appropriate gli scostamenti da quanto preventivato e
da quanto necessario al buon esito di un contratto in termini di conduzione dei progetti,
qualità dei processi messi in atto dal Fornitore, qualità dei prodotti e dei servizi,
efficienza ed efficacia di quanto fornito in funzione anche degli investimenti sostenuti.

Il monitoraggio si configura come una attività di supporto al governo dei contratti, che
l’Amministrazione committente attiva per avere sempre la massima informazione
sull’effettivo svolgimento delle attività, al fine di prevenire risultati non in linea con le
aspettative e di contenere le spese ed i ritardi dovuti alla correzione di eventuali non
conformità di quanto fornito rispetto ai requisiti espressi. Il monitoraggio è perciò una
attività che può essere valutata anch’essa in base alla efficienza ed efficacia dimostrate,
attraverso il confronto dei costi che richiede rispetto ai benefici tangibili che produce.

62
L’impegno di risorse e il conseguente costo del servizio di monitoraggio di un contratto
è funzione dei due principali aspetti caratterizzanti i contratti che devono essere
monitorati:
• importo globale del contratto da monitorare;
• la complessità dei servizi da monitorare.

L’importo del contratto da monitorare è sicuramente uno dei parametri da considerare, in


quanto determina in ogni caso un certo volume di impegno e sottende una criticità e
rilevanza per il committente direttamente proporzionale. Correlare l’importo del
monitoraggio al solo importo del contratto da monitorare potrebbe però essere
fuorviante, in quanto, senza bisogno di ulteriori approfondimenti, è intuitivo che un
servizio, pur di valore economico elevato, basato su pochi processi ripetitivi, come la
gestione operativa, è più facile da controllare di un servizio, di minore importo, ma
costituito da molti processi, in parte magari anche estemporanei o non programmabili
come lo sviluppo del software.

Relativamente ai contenuti da dare al parametro di complessità, sembra ragionevole


considerarla rappresentata da questi attributi:
• tipologia di servizi
• numero dei servizi
• loro durata temporale
• criticità (n° di utenti coinvolti, importanza del servizio nel contesto etc…).

La dimensione dell’impegno richiesto dal servizio di monitoraggio prevede una quota


fissa base per alcuni adempimenti che il monitore deve comunque svolgere
indipendentemente dalle caratteristiche (costo, durata, servizi appaltati, loro complessità
etc..) del contratto monitorato. Questi adempimenti base sono, almeno, la messa in opera
del sistema di valutazione, studio degli atti e della documentazione, definizione ed
attivazione della base informativa del monitoraggio, riunioni di accordo e revisione con
le parti contrattuali sui modelli di riscontro e sul piano delle verifiche.

La durata minima di un monitoraggio, perché possa produrre risultati compatibili con le


aspettative, è di 6 mesi e deve, comunque essere almeno pari alla durata del contratto
oggetto del monitoraggio.
La incidenza del servizio di monitoraggio decresce all’aumentare del valore e della
durata del contratto monitorato, mostrando un comportamento asintotico: infatti, la
complessità e l’onerosità dello svolgimento delle attività di monitoraggio decresce, in
parte, con la pratica, una volta messa in piedi la struttura di verifica, ovvero con
l’acquisita conoscenza dello specifico ambiente da parte del monitore e il monitoraggio,
adotta, per la scelta degli obiettivi di verifica, tecniche di campionamento che hanno
anch’esse una possibile rappresentazione grafica di tipo asintotico.

La incidenza del servizio di monitoraggio cresce invece all’aumentare della complessità


dei servizi monitorati, che influenzano la difficoltà delle relative attività di verifica e la
complessità e frequenza delle verifiche ispettive da svolgere.

63
Per una stima di massima si può assumere che l’intervallo dell’incidenza, nel caso di
monitoraggio di complessità media, sia compreso tra circa lo 0,7 e il 5% del valore del
contratto da monitorare. Il valore massimo corrisponde a importi contrattuali di alcuni
miliardi di lire ed il valore minimo si può considerare come il valore dell’asintoto per
importi superiori a 500 miliardi di lire.

Il rapporto tra costo del monitoraggio nel caso di complessità massima e costo nel caso
di complessità minima, a parità di importo e durata contrattuale, si può assumere pari a
2.

5.6.2. Le figure professionali necessarie

Le figure professionali previste in fase di stima sono quelle della circolare Aipa/Cr/5,
Partner, Consulente senior e Consulente, più un Sistemista per la predisposizione
dell’ambiente tecnologico ed il relativo supporto durante il monitoraggio. La
distribuzione dell’impegno (in %) e le tariffe (basate su valori medi di listino) per un
monitoraggio tipo sono riportati nella tabella che segue:

Figura professionale Tariffa oraria Impegno in %


Partner 240.000 5
Consulente Senior 190.000 47
Consulente 140.000 39
Sistemista 140.000 9

Sulle tariffe di listino vengono praticati sconti come indicato nel paragrafo dedicato alle
tariffe professionali.

5.7. Servizi di manutenzione prodotti hardware


I servizi di manutenzione delle apparecchiature hardware possono assumere forme
diverse (di tipo continuativo, a gettone, a chiamata, ecc.). Nel seguito faremo riferimento
alla forma più diffusa di manutenzione di tipo continuativo effettuata dal fornitore del
servizio a fronte di un canone predefinito corrisposto mensilmente.

Data la maggiore concorrenza e lo spostamento del mercato verso prodotti basati su


componenti standard, i costi di manutenzione dell’hardware si sono ridotti drasticamente
dal 1995 ad oggi, ed è probabile che questa tendenza continui. Gli analisti prevedono che
in Europa, i costi di manutenzione dell’hardware continueranno a diminuire,
mediamente, del 15% all’anno nei prossimi anni.

64
Per le nuove acquisizioni i canoni di manutenzione possono essere stimati applicando al
valore di acquisto delle percentuali medie differenziate per tipologia di bene.

Questi valori possono essere desunti da contratti precedenti o da indagini di mercato o


forniti da analisti di mercato.

Nel caso dei mainframe e dei sottosistemi a disco è possibile utilizzare un prezzo
unitario della manutenzione rispettivamente per GB e per MIPS.

A titolo indicativo si riportano le percentuali medie per le principali tipologie di


hardware:
• mainframe: i canoni sono diminuiti nel tempo e per i modelli più recenti (CMOS)
sono intorno a 60.00 lire per MIPS per mese pari a una incidenza percentuale sul
prezzo di acquisto del 5-6% all’anno;

canone di manutenzione mensile per


MIPS

300
250
200
US $

150
100
50
0
3084 3090-E 3090-J 9021 9672

• sistemi midrange: mediamente 6% (con variazione dal 7% al 5% passando dalla


fascia bassa a quella alta)
• personal computer: mediamente 6% (anche in questo caso maggiore su modello
entry level e inferiore su fascia alta)
• stampanti: dal 12 al 14%, mediamente 15%

Si noti che per pc e stampanti in grandi volumi (>2000 pezzi) i canoni annui variano da
120.000 lire fino a minimo 80.000 lire a pezzo. La tendenza del mercato è di vendita con
3 anni di garanzia
• sottosistemi a disco: il canone mensile di listino è pari a 8$ per Gb pari a circa
170.000 lire per Gb all’anno

65
canone di manutenzione mensile per
GB

140
120
US $ 100
80
60
40
20
0
E

AC
-k

-2

-3

-2
TD

80

80

90

90

AC
M
33
-S

33

33

33

RA

M
80

RA
33

• router: manutenzione hardware: 12% del prezzo di listino che può essere ridotto del
2-4% sulla base del volume, manutenzione software: 5% del prezzo di listino
dell’apparecchiatura

5.8. Servizi di manutenzione prodotti software


Per quanto riguarda il software di base dei mainframe l’onere del servizio di
manutenzione è compreso nel canone di licenza mensile.

Nel caso degli altri prodotti software è possibile stimare il canone di manutenzione e
assistenza come percentuale del prezzo di acquisto della licenza d’uso.

I canoni sono differenziati sulla base dei livelli di servizio previsti dal contratto e variano
dal 12% al 21% del prezzo della licenza d’uso.

Nel seguito vengono riportate le percentuali medie in corrispondenza di livelli di servizio


crescenti:
• livello base (aggiornamenti e correzioni di errori): 12%
• come il precedente con in più il servizio telefonico di supporto (5gg/set, 8 h/gg): 14-
15%
• con supporto telefonico esteso (24 h/gg per 7gg /set), accesso a documenti su
problemi e soluzioni, formazione e addestramento: 17-18%
• come il precedente più rapporti personalizzati, gruppo di supporto a richiesta: 21%

5.9. Servizi di manutenzione applicazioni software


La manutenzione del patrimonio applicativo di una organizzazione riguarda i
programmi, i dati e loro strutture, le specifiche, i documenti per il cliente e l’utente e i
documenti per il fornitore.

66
La manutenzione può essere di vario tipo:
• correttiva: risoluzione di problemi;
• migliorativa: miglioramento delle prestazioni e dell’usabilità;
• adeguativa: adeguamento all’evoluzione dell’ambiente tecnologico;
• evolutiva: per adattare la procedura alle nuove esigenze dei processi di lavoro da
supportare; comporta l’aggiunta, il cambiamento ed eventualmente la rimozione
di funzionalità.

Si stima che l’incidenza della manutenzione vari dal 65% all’80% dell’impegno
complessivo di sviluppo e manutenzione, riferito alla intera vita della applicazione
considerata.

Con riferimento alle categorie citate, l’impegno maggiore riguarda gli ni terventi di
manutenzione evolutiva (55%) mentre la manutenzione adeguativa e correttiva incidono
rispettivamente per il 25% e il 20%.

La manutenzione evolutiva può essere valutata calcolando l’impegno in punti funzione


secondo la formula:

EFP = [(ADD+CHGA+CFP) * VAFA] + (DEL * VAFB)8

Per i valori di produttività, tariffe professionali e prezzo per punto funzione si può fare
riferimento alle attività di sviluppo.

Dopo l’intervento può essere aggiornato il conteggio dei punti funzione in base alle
modifiche apportate.

In fase di pianificazione, se non si conoscono in dettaglio i punti funzione da sviluppare


nell’ambito di interventi di manutenzione evolutiva si può effettuare una stima di
massima dell’impegno sulla base della percentuale media di cambiamenti apportati al
patrimonio applicativo nel passato, ipotizzando che questa rimanga costante.

8
dove:
EFP: conteggio dei punti funzione del progetto di manutenzione evolutiva
ADD: conteggio dei punti funzioni (non aggiustati) aggiunti dall’intervento
(segue nella pagina successiva)
CHGA: conteggio dei punti funzioni (non aggiustati) modificati dall’intervento; sono i
punti funzione conteggiati dopo le modifiche.
CFP: conteggio dei punti funzione aggiunti da eventuali conversioni dei dati.
VAFA: fattore di aggiustamento calcolato dopo l’intervento
DEL: conteggio dei punti funzioni non aggiustati eliminati dall’intervento
VAFB: fattore di aggiustamento calcolato prima dell’intervento

67
Le prime tre tipologie di manutenzione costituiscono quella che viene definita
correntemente manutenzione MAC (Migliorativa, Adeguativa e Correttiva). Sono esclusi
dalla manutenzione MAC interventi complessi di migrazione o reingegnerizzazione o
interventi di manutenzione di massa di tipo straordinario (anno 2000, EURO).

Non esistono metodi standard, o di impiego generalizzato, in grado di determinare con


precis ione i costi riferiti alla manutenzione applicativa. Finora è stata privilegiata
l’elaborazione di strumenti per la valutazione degli oneri relativi alle fasi che precedono
l’entrata in esercizio del sistema informativo automatizzato. Per quanto riguarda le fasi
più a valle, invece, la produzione di studi e ricerche si trova ad uno stadio evolutivo
meno avanzato.

Alcuni autori suggeriscono di stimare l’impegno in attività di manutenzione


rapportandolo a quello di sviluppo. Secondo Boehm (1981) l’impegno in manutenzione è
proporzionale sia alla dimensione del progetto che alla entità dei cambiamenti apportati
ai programmi.

La formula proposta, che rientra nel modello di stima COCOMO, è la seguente:

PMM = ACT x PM

dove PMM è il numero di persone/mese dedicate alla manutenzione nel corso di un


anno; ACT rappresenta il cosiddetto Annual change traffic, ovvero una misura dell’entità
delle modifiche, determinata come rapporto tra istruzioni nuove o riscritte rispetto al
numero totale di istruzioni; infine PM rappresenta l’impegno (espresso in termini di
persone/mese) necessario per sviluppare il progetto.

Lo stesso autore suggerisce una serie di fattori correttivi che hanno lo scopo di adattare
la formula alle caratteristiche dell’ambiente di riferimento quali: tipo e dimensione del
progetto, livello di esperienza degli addetti, strumenti tecnici impiegati ecc.

Secondo alcuni autori le attività di manutenzione MAC richiedono un impegno variabile


da 1/7 a 1/10 dell’impegno in sviluppo applicativo.

Il costo della manutenzione MAC può essere valutata sulla base della dimensione del
parco applicativo da mantenere, della produttività e del costo del personale o delle tariffe
professionali nel caso di servizi esterni.

La dimensione può essere valutata in linee di codice o in punti funzione.

La produttività della manutenzione MAC dipende principalmente da:


• manutenibilità delle applicazioni (modularità, linguaggi di programmazione, stile di
programmazione, accuratezza della validazione e test, qualità della documentazione,
età);
• livelli di servizio richiesti;

68
• conoscenza delle applicazioni e dell’ambiente da parte del personale incaricato della
manutenzione.

Per applicazioni legacy scritte in COBOL i valori della produttività relativi alla
manutenzione MAC si attestano intorno alle 200.000 LOC mantenute per anno uomo.

Un altro fattore di aleatorietà che rende difficile la stima dei costi di manutenzione si
riferisce alla distribuzione degli impegni lungo l’intera vita del prodotto software. Il
valore di produttività indicato in precedenza riguarda l’insieme degli interventi di
manutenzione MAC e deve essere considerato come un valore medio lungo l’arco di
vita di una applicazione. L’andamento temporale dell’impegno totale di manutenzione in
realtà non è costante ma ha un andamento del tipo di quello riportato in figura ricavato
interpolando dati reali (fonte: “Software sizing and estimating” – Charles, R. Symons):

impegno per manutenzione in funzione dell'età della


applicazione
2
1.5 (costo della non qualità) enhancement
ore-uomo
1 total
per FP
0.5
0
0 1 2 3 4 5 6 7 8 9 10
età della applicazione

L’area non tratteggiata compresa tra la linea orizzontale e l’asse delle ascisse
rappresenta l’impegno della manutenzione evolutiva che dipende da fattori caratteristici
di ciascuna organizzazione legati alla variabilità dei processi di lavoro supportati ed è
tendenzialmente costante negli anni.

L’area tratteggiata rappresenta l’impegno di manutenzione correttiva e migliorativa che è


elevato al momento del rilascio dell’applicazione e presenta negli anni successivi una
riduzione continua, derivante dal consolidamento dell’applicazione, fino a raggiungere
un minimo (dopo circa 3 anni) per poi crescere lentamente in seguito al deterioramento
tecnico conseguente agli interventi subiti e alla sua obsolescenza.

L’impegno della manutenzione adeguativa non è rappresentato nella figura in quanto


dipende da fattori esterni discontinui e non prevedibili.

L’area tratteggiata può essere interpretata come il costo della “non qualità”
corrispondente agli interventi necessari per eliminare i difetti presenti in fase di rilascio
(triangolo di sinistra) e la riduzione di produttività nel tempo conseguente al
peggioramento qualitativo.

69
La produttività in termini di punti funzione supportati per anno uomo presenterà pertanto
un andamento opposto (ad U rovesciata).

E’ opportuno che le organizzazioni tengano traccia in maniera distinta della attività di


manutenzione ordinaria (correttiva e migliorativa) da quella evolutiva e da quella
adeguativa.

Questo consente col tempo di:


• assestare le necessità di impegno di manutenzione evolutiva al valore medio tipico
della specifica organizzazione correlato alla variabilità dei processi di lavoro e delle
eventuali norme che li regolano;
• tenere sotto controllo la necessità di manutenzione ordinaria (che equivale al costo
della non qualità), puntando alla sua diminuzione assoluta attraverso il
miglioramento della qualità del nuovo sviluppo e interventi di reingegnerizzazione
delle vecchie applicazioni divenute troppo costose da mantenere;
• calibrare i contratti di manutenzione ordinaria sulla base del presumibile andamento
delle necessità di manutenzione correttiva e migliorativa delle principali applicazioni.

5.10. Servizi di manutenzione straordinaria: l’adeguamento all’anno 2000


Si propone come esempio particolarmente significativo di intervento di manutenzione
straordinaria quello dell’adeguamento all’anno 2000 dei sistemi informativi
automatizzati.

La stima di tale impegno richiede preventivamente l’individuazione degli oggetti su cui


l'evento ha effetto (oggetti impattati) e la definizione delle strategie e delle soluzioni
tecniche da adottare per l’adeguamento. Una volta identificati gli interventi da eseguire
su ciascun oggetto è possibile pervenire ad una stima di massima dei costi da sostenere.

In conseguenza della interazione tra le diverse componenti di un sistema informativo è


possibile che la non adeguatezza di un oggetto comporti di conseguenza la necessità di
adeguamento o sostituzione di altri oggetti correlati.

70
Nella tabella seguente si è cercato proprio di evidenziare i legami esistenti fra i diversi
oggetti in relazione alle fornitura e alle attività necessarie per l’adeguamento anno 2000.

Tipo di fornitura o di attività


hard software servizi
ware
Oggetti supporto
impattati acquis
sistemisti-co di
da to/ adegua- acquisto/
acquisto/ di supporto per conversi noleggio
adeguare noleg mento noleggio
noleggio all’utilizzo aggiorna- one ambient
gio licenze pacchetti
di tool di tool mento anno e di test
hardw software soft ware
licenze e 2000
are
migrazioni
hardware X X X
software X X X
base
pacchetti sw X X X
applicazion X X X X X X X X
i
archivi X X X X X X

Una volta raccolte informazioni sui macchinari, sul software di base e d’ambiente, sui
pacchetti, è necessario valutare attentamente la possibilità di adeguamento o
sostituzione, anche con riferimento, come già detto, alle relazioni fra questi e fra questi e
le applicazioni e gli archivi.

Per l’hardware non conforme è necessario valutare il costo per aggiornare il firmware
dei sistemi per cui questa possibilità è prevista ed il costo della sostituzione dei sistemi
per i quali non è possibile l’aggiornamento.

Per i prodotti non conformi anno 2000 è necessario, sulla base di indicazione dei
fornitori, valutare gli esborsi connessi all’acquisto delle nuove versioni conformi anno
2000 nel caso particolare in cui i contratti di manutenzione non prevedano questa
possibilità.

Le società fornitrici garantiscono software 2000 conforme solo su versioni recenti. Può
quindi essere necessario un upgrade delle versioni installate, o come già accennato, la
completa sostituzione del prodotto con uno analogo.

Si consideri che il cambiamento di un pacchetto applicativo può richiedere non solo la


sostituzione di tutti gli "strati software" (d'ambiente, di base, di sistema, di rete....)
sottostanti, ma anche la modifica di altri applicativi (personalizzazioni scritte ad hoc o
applicativi collegati) o di archivi, nonché delle piattaforme hardware su cui è installato.
Infatti si può verificare l'evenienza che la "compatibilità 2000" venga garantita su
versioni software che necessitano di hardware più aggiornato o potente dell'attuale.

Deve poi essere considerato che ogni nuova installazione di software di base può
necessita generalmente di un adeguato supporto di servizi di consulenza sistemistica.

71
Una volta raccolte informazioni sulle applicazioni ed i relativi archivi, è necessario
distinguerle in:
• applicazioni per le quali non è necessario alcun adeguamento in quanto già 2000
conformi;
• applicazioni per cui non è previsto l’esercizio dopo il 1999, a causa di rifacimenti in
corso o altro;
• applicazione per cui, a causa dei motivi esposti nel paragrafo “strategie di massima”,
non è conveniente l’adeguamento anno 2000 e si procede ad una completa riscrittura
o alla sostituzione con pacchetti;
• applicazioni che richiedono modifiche e che devono essere adeguate.

L’intervento di adeguamento verrà eseguito solo su questa parte di tutto il patrimonio


applicativo censito.

La fase di validazione del software modificato prevede una stretta collaborazione fra le
aree informatiche, interne o esterne, che hanno seguito tutto il processo di adeguamento
e le aree operative. Ad esse compete, seppure con un impegno minimizzato attraverso
l’eventuale impiego di tool, la validazione del sistema con le modifiche eseguite.

Per la stima di massima dei costi associati agli interventi di adeguamento delle
applicazioni ci si può basare sul numero di linee di codice eseguibile (ELOC)9 da
convertire. Valori orientativi del prezzo per ELOC offerti sul mercato variano da 300 a
800 lire per ELOC.

E’ evidente che occorre prendere in considerazione solo ELOC delle


applicazioni/sottosistemi operative dopo il 1999, e quindi non soggette a
reingegnerizzazione, rifacimenti o sostituzioni.

Le fasi/attività del progetto anno 2000 considerate nella stima sono inventario,
conversione, test, messa in produzione, sono esclusi i costi relativi alla creazione
dell’ambiente di test, all’utilizzo di macchinari (CPU, DASD), all’espansione dei
database.

I valori indicati si riferiscono ad interventi effettuati con l’ausilio di strumenti automatici


di supporto, in un ambiente piuttosto omogeneo e di media complessità, dove il
linguaggio utilizzato è il COBOL.

Lo scostamento dai valori medi può essere dovuto a numerosi fattori. Nel seguito
vengono descritti alcuni fra i più significativi:

9
Per codice eseguibile si intendono le linee epurate dalle definizioni dei dati e dai
commenti e simili; se invece si fa riferimento alle linee totali (LOC) il loro valore sarà
più alto di circa un 20-40%.

72
• grado di automazione: l’utilizzo di tool comporta notevoli miglioramenti nella
qualità dell’intervento oltre che economie nei costi e nei tempi, pur considerando il
costo aggiuntivo dello strumento. Il risparmio che si può ottenere viene stimato fino
al 50% dei costi, nella specifica fase di utilizzo dello strumento: esistono infatti
diversi tool per ogni specifica fase in cui si compone il progetto;
• linguaggio: il tipo di linguaggio influenza il costo di conversione principalmente
perché la disponibilità dei tool automatici e la loro efficacia varia da linguaggio a
linguaggio e, in misura minore, per la diversa disponibilità di adeguate
professionalità;
• età dell’applicazione: programmi meno recenti potrebbero avere un minore grado di
strutturazione e, a seguito di interventi di manutenzione succedutisi negli anni,
presentare caratteristiche di minore manutenibilità;
• presenza e qualità della documentazione: la presenza di una adeguata
documentazione agevola in particolare il lavoro di analisi e di test;
• disponibi lità del codice sorgente: è possibile che nella fase d’inventario vengano
messi in luce problemi circa l’esistenza in produzione di moduli eseguibili di cui non
sono più disponibili i sorgenti (o, anche se disponibili, con disallineamenti): questo
può comp ortare la riscrittura di intere parti del parco applicativo (con le
problematiche connesse al reperimento almeno dei documenti di analisi) o
l’affidamento a fornitori specializzati l’attività di creazione di codice sorgente a
partire da oggetti o da eseguibili;
• percentuale di linee di codice da modificare: la percentuale, il cui valore medio è
dell’8-10%, può variare da pochi punti ad alcune decine nei casi peggiori, con
conseguente variazione del lavoro di conversione da effettuare a parità di linee di
codice complessive delle applicazioni impattate;
• soluzione tecnica adottata: come già detto in precedenza, l’espansione dei campi
data richiede l'aggiornamento di tutte le applicazioni, anche di quelle che, in teoria,
potrebbero continuare a gestire la data con il vecchio metodo; in particolare,
dovranno essere aggiornate tutte le componenti delle applicazioni relative a
schermate e tabulati; c’è inoltre la necessità di sincronizzare l'adeguamento
(attraverso modifiche di uguale contenuto o la predisposizione di appositi "bridge")
di tutte le applicazioni che interagiscono con informazioni di tipo data, facenti parte
di archivi condivisi. Non va sottovalutato il problema legato alla rielaborazione di
dati storici già archiviati con rappresentazione dell'anno a due cifre né quello legato
alle maggiori esigenze di memorie di massa (dischi).

Nella definizione degli interventi e nella stima dei costi per l’adeguamento delle
applicazioni occorre considerare le risorse interne od esterne dedicate alla conversione,
nonché gli eventuali costi associati agli altri oggetti coinvolti, quali tool e relativi servizi
di supporto, eventuali risorse elaborative e di memorizzazione aggiuntive necessarie per
la attività di conversione e di test, ecc. Anche la modifica del software applicativo, come
già detto per i pacchetti, può richiedere non solo la sostituzione di tutti gli "strati
software" (d'ambiente, di base, di sistema, di rete) sottostanti, ma anche la modifica di
altri applicativi (personalizzazioni scritte ad hoc o applicativi collegati) o di archivi,
nonché delle piattaforme hardware su cui è installato.

73
Interventi di adeguamento degli archivi devono essere previsti solo nel caso di
sottosistemi per i quali sia stato deciso di adottare la soluzione della espansione dei
campi data portando l’anno a quattro cifre. Le modifiche ai data base, dovute
all’espansione dei campi data, possono portare ad un aumento dei costi del 50%,
secondo le stime della Gartner Group. Tale incremento dei costi deriva dalla necessità di
modificare il contenuto e la struttura degli archivi con conseguente necessità di scrittura
di programmi di conversione e la possibilità che si richieda l’ampliamento delle memorie
di massa (dischi). Poiché la fase di conversione rappresenta il 20-30 % del costo
complessivo del progetto, si può assumere che la scelta di espandere tutti i campi-data
relative al costo di conversione possa incrementare del 20-40%.

Nel caso la soluzione scelta sia il mantenimento di campo a due cifre con codifica dei
dati secondo un particolare algoritmo è richiesta la modifica del contenuto degli archivi
ma non quello della struttura. Le risorse umane necessarie per l’adeguamento degli
archivi dovrebbero pertanto essere inferiori rispetto al caso precedente ed inoltre non ci
sono costi associati per l’eventuale ampliamento delle memorie di massa.

Nel caso si adottino tecniche di windowing non sono previsti costi per l’adeguamento
degli archivi.

Nella tabella seguente viene riassunto l’impatto delle tre soluzioni sui programmi e sui
dati:

Programmi Dati Esigenze di


Soluzione tecnica sincronizzazione
I/O logica contenuto struttura
ampliamento del X X X X Alta
campo anno
codifica X X X Alta
time windowing X Media

5.11. Gestione di sistemi e reti

5.11.1. Gestione del CED


I costi dei servizi di gestione dei CED possono essere stimati sulla base dello staff
necessario e delle tariffe professionali o dei costi standard del personale interno
utilizzato.

74
Le attività da svolgere sono indicate nella tabella seguente:

operative System Operations supporto tecnico Operating System Support


Operations Support Subsystem Support
Tape Operations Internal Systems Support
Help Desk Performance Analysis
Print Operations Capacity Planning
Microfiche Operations Storage Management
Production Control System Security
Management Management

Una valutazione accurata delle risorse necessarie richiede attività di benchmarking,


effettuando comparazioni con centri analoghi per complessità e livelli di servizio. Una
stima di massima può essere effettuata tramite alcuni indicatori derivati da survey o da
attività di benchmarking.

Un indicatore di massima dell’efficienza è il rapporto tra staff e numero di MIPS


installati. Questo indicatore può essere riferito al personale complessivo o a quello
presente in specifiche aree di attività. Nel seguito viene riportata una tabella con i valori
minimi, massimi e medi del personale per MIPS, distinto tra operativi e servizi tecnici

Figura professionale minimo medio massimo


operatori 0,060 0,215 0,472
sistemisti (servizi tecnici) 0,038 0,100 0,216
totale 0,098 0,315 0,630
Fonte: Gartner Group

Emerge una elevata differenza tra valori minimi e valori massimi con un rapporto pari a
circa 6:1.

Un fattore importante per spiegare queste differenze è la dimensione del centro in


termini di MIPS complessivi.

75
Nella figura sottostante è riportato il valore medio del personale operativo in funzione
della dimensione del CED. Si passa da 45 persone operative ogni 100 MIPS nei CED al
di sotto di 80 MIPS a 5,4 nei CED tra 600 e 800 MIPS, per scendere fino a 2,7 (per 100
MIPS) per i centri oltre 2500 MIPS.
Per quanto riguarda il
personale dedicato ai
personale 0.45
operativo 0.4 servizi tecnici si può
0.35 assumere un rapporto di
0.3 1:2 rispetto al personale
per 0.25
MIPS 0.2 operativo.
0.15
0.1 Altri fattori che
0.05
0 influenzano il numero di
<80 80- 135- 215- >400 2500- risorse impiegate per
135 215 400 3000 MIPS sono:
MIPS installati • livelli di servizio e
qualità dei processi
• numero di sistemi operativi e di sottosistemi supportati
• utilizzo della capacità produttiva
• tipologia del carico di lavoro (batch, interattivo, online)
• volumi di stampe, montaggio nastri, ecc.
• grado di automazione

Nella tabella a fianco (fonte


MetaGroup), relativa a centri con 600-
800 MIPS, sono riportati alcuni indici
di efficienza relativi ad attività
specifiche quali supporto alle unità di
memorizzazione, help desk, montaggio
nastri, ecc.

Per quanto riguarda le tariffe


delle figure professionali
coinvolte si rimanda al capitolo
apposito.

5.11.2. Gestione dei server centralizzati


Anche nel caso della gestione dei server centralizzati (o gestiti centralmente) con sistema
operativo UNIX, OS/400, VSM, NT, la valutazione dei costi può essere effettuata sulla
base dello staff necessario e delle tariffe professionali o dei costi standard del personale
interno utilizzato.

76
Le attività da svolgere sono sia quelle di tipo operativo che quelle di tipo tecnico-
sistemistico. Una stima di massima può essere basata su alcuni indici (staffing ratios) che
definiscono il rapporto tra numero di server gestiti e numero di persone dedicate alla
gestione.

Dalle analisi di benchmarking effettuate dal Gartner Group questo indice varia nella
maggior parte dei casi analizzati da 0,1 a 2 in funzione di fattori di complessità
tecnologici e organizzativi quali:
• maturità delle piattaforme;
• fascia di prestazioni dei server;
• numero di piattaforme o sistemi operativi diversi;
• tasso di cambiamento dei server.

5.11.3. Gestione dei sistemi distribuiti


I costi dei servizi di gestione dei sistemi distribuiti possono essere valutati sulla base
dello staff necessario e delle tariffe professionali o dei costi standard del personale
interno utilizzato.

Le attività svolte riguardano le seguenti aree:


• servizi tecnici
• supporto utente / help desk
• pianificazione e sviluppo
• operazioni
• finanza e amministrazione

Come nel caso della gestione dei CED, una valutazione accurata può basarsi sul
benchmarking.

Un indicatore di massima dell’efficienza nella gestione dei sistemi distribuiti è il


rapporto tra il numero del personale di supporto e il numero di utenti del sistema. Questo
indicatore può essere riferito al personale complessivo o a quello presente in specifiche
aree di attività.

Dalle analisi di benchmarking del Gartner Group risulta che il rapporto tra la dimensione
dello staff complessivo di supporto e il numero di utenti varia da 1:10 a 1: 80.

Il numero del personale di supporto per utente cresce al crescere della complessità del
sistema (vedi grafico successivo); la complessità è misurata pesando opportunamente i
seguenti fattori di complessità relativi alle applicazioni e tecnologie da gestire e ai livelli
di servizio richiesti:

77
• Applicazioni
• % di applicazioni critiche a livello di azienda
• % di applicazioni critiche a livello dipartimentale
• % di applicazioni di produttività individuale
• Tecnologie
• n. Piattaforme
• tasso di rinnovamento
• % connessione in LAN
• % utenti mobili
• % di C/S
• % e-mail e groupware
• Supporto
• Dispersione degli utenti
• livelli di servizio (availability, tempi di ripristino, ecc.)

90
80
uten 70
ti 60
50
per
40
staff 30
20
10
0
2 3 4 5 6 7 8 9 10 11 12 13 14
indice di complessità

Per il solo supporto pc ed help desk di primo livello Gartner Group fornisce rapporti
staff/utenti diversificati in relazione al profilo dell’utente. Si passa da 1:30 per utenti
sofisticati e con livelli di servizio elevati a 1:60/100 per utenti medi fino a 1:125 per
utenti con minori esigenze di supporto.

78
Da una survey effettuata da su 300 aziende di varie dimensioni (fonte: Computer
Economics) è risultato che il rapporto staff/utenti decresce al crescere del numero di pc
supportati secondo la seguente tabella:

numero di pc installati personale di supporto Rapporto staff


PC supporto/pd.l.
50-250 4,2 1:41
251-500 5,5 1:77
501-1000 8,4 1:95
1001-1500 11,1 1:112
1500-5000 22,9 1:119

Per quanto riguarda il livello 2 dell’help desk, gestito centralmente dal gruppo di tecnici
focalizzato sulla infrastruttura di rete (server, hub, switch e router), l’indicatore da
utilizzare per il dimensionamento non è più il rapporto staff/utenti o pdl ma il rapporto
personale di staff/numero di server.

Nella tabella seguente è riportato il rapporto tra numero di server e personale per la
gestione dei server per diverse tipologie di server.

79
5.11.4. Gestione delle reti geografiche (WAN)

Dalle analisi di benchmarking del Gartner Group risulta che in una rete
multiprotocollo circa il 35% dei costi è rappresentato dai costi del
personale mentre il rimanente 65% è destinato ai costi di trasmissione ed
alle infrastrutture hardware e software.

Un indicatore di massima per il dimensionamento è il rapporto tra personale di staff


(direzione e amministrazione, attività operative, help desk, change management,
pianificazione, supporto sistemistico) e il numero di device (terminali, stampanti, server,
porte dial-up, ecc.).

Un valore medio orientativo è 1,5-2 persone di staff ogni 1000 device con un costo per
device di circa 230.000 lire (con tariffa annua di 140 milioni di lire).

I fattori di complessità che influenzano questo rapporto sono:


• il numero di protocolli
• il numero di siti
• la ridondanza
• i livelli di servizio (availability, tempi di risposta, MTTR, contingency
requirements)

5.12. Servizi di assistenza sistemistica


Si ricorre ai servizi di assistenza sistemistica per affiancare il personale operativo interno
che gestisce i sistemi. I servizi di assistenza sistemistica sono di solito realizzati
attraverso contratti nella forma “time e materials” nei quali il fornitore viene pagato in
base a una tariffa oraria, giornaliera o mensile prenegoziata e viene rimborsato al prezzo
di costo per le eventuali spese sostenute.

La stima dei costi richiede il piano degli impegni valorizzato con le tariffe di mercato per
le figure professionali richieste.

Nei casi in cui la gestione dei sistemi è affidata ad un fornitore esterno le prestazioni di
supporto sistemistico, ed i relativi costi, sono comprese nella fornitura. Nei paragrafi
precedenti sono stati forniti dei criteri per il dimensionamento del personale per la
gestione dei sistemi e delle reti per attività sia operative sia di supporto tecnico.

80
5.13. Servizi di data entry
I servizi di data entry vengono valutati in lire a carattere registrato e controllato su
supporto magnetico.

Per una stima di massima si possono assumere i seguenti valori:


• 2-3 lire per carattere nel caso di caratteri alfanumerici;
• 3-4 lire a carattere nel caso di caratteri numerici.

Nel caso in cui i dati da registrare siano contenuti all’interno di documenti e debbano
essere ricercati dall’operatore prima dell’inserimento, i costi possono aumentare; per una
stima più accurata occorre fare delle prove per verificare la produttività ed applicare poi
una tariffa giornaliera
La acquisizione di documenti tramite scanner varia con la dimensione e le caratteristiche
dei documenti e l’eventuale esigenza di predisporre una scheda di riferimento; per stime
di massima si può assumere 200-300 lire per pagine in formato A4.

5.14. Tariffe professionali


La conoscenza delle tariffe professionali praticate sul mercato è necessaria per stimare i
costi dei servizi effettuati da fornitori esterni per i quali è stato stimato il numero e la
tipologia di risorse impegnate.

Le tariffe professionali praticate dalle società di servizi IT sono definite sulla base del
costo del lavoro, comprensivo di tutte le componenti, e di una serie di voci addizionali
che rappresentano la quota dei costi aziendali attribuiti alla singola unità operativa (costi
commerciali, amministrativi e di management, spese generali, ammortamenti ed oneri
finanziari, utile lordo). Tali costi, che dipendono dalle dimensioni e dal tipo di azienda,
vengono suddivisi sul numero di addetti operativi. A questi costi si può aggiungere un
margine di protezione per rischi su commesse (ritardi, penali, ecc.). Le voci addizionali,
nel loro complesso, sono in media superiori al costo del lavoro.

Le tariffe per le diverse figure professionali variano in funzione di diversi fattori:


• esperienza della specifica persona e della qualità della società di appartenenza
• particolari conoscenze richieste in relazione all’ambiente del cliente
• area geografica
• entità dell’impegno (giorni, mesi o anni uomo) e durata del contratto
• disponibilità del personale
• acquisizione del servizio a gara o a trattativa privata
• strategicità del progetto per il fornitore
• rischio di commessa

Rispetto ai listini i fornitori praticano normalmente sconti fino al 30-35%,


principalmente in funzione della durata del contratto, della disponibilità di personale
non impegnato, della importanza strategica che il fornitore attribuisce al contratto. In
casi particolari dove si sommano più fattori che spingono verso la riduzione della tariffe

81
si possono registrare sconti superiori al 50% con tariffe che coprono appena i costi diretti
del lavoro. Ai fini delle stime dei costi è opportuno non fare riferimento a questi casi
anomali.

Nella tabella seguente vengono riportate, per le principale tipologie di figure


professionali, i range di variazione delle tariffe in Lire offerte sul mercato (fine 1998 -
inizio 1999).

figura professionale tariffa (lire per giorno)


area sviluppo e manutenzione software
− programmatore: 300.000-600.000
− analista 500.000-900.000
− capo progetto 800.000-1.200.000

area assistenza sistemistica


− sistemista senior 800.000-1.300.000
− sistemista 700.000-1.00.000
− sistemista junior 450.000-800.000

area gestione CED


− operatore senior 400.000-700.000
− operatore 320.000-500.000

assistenza e formazione
− assistente, addetto help-desk 500.000-750.000
− formatore 700.000-1.500.000

consulenza IT
− consulente 1.200.000-1.700.000

data entry
− operatore 260.000-350.000

82