LA STIMA DEI COSTI DEI SISTEMI INFORMATIVI … · uomo impegnato a costi standard o a tariffe di...

1

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 momenti 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.

2

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 sistemistiche, 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

3

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 vanno ad ampliare e rinnovare il portafoglio applicativo della amministrazione o ne modifichino in modo significativo alcune parti I costi di sviluppo si distinguono tra costi di costruzione (o

progettazione/realizzazione) 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.

costi per missione

Costi di unprogetto/sistema

Costi di sviluppo

Costi di esercizio

Costi di costruzione

Costi di avviamento

4

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 Diretti Indiretti Esterni

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:

5

• 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

impianti richiesti (elaboratori, linee di trasmissione, posti di lavoro, periferiche) a partire dalle caratteristiche funzionali, dai volumi elaborativi e dalle prestazioni richieste dal sistema (capacity planning)

• Valore di listino per fascia o per specifica configurazione + sconti volume

• Prezzo di mercato per unità prestazionale (ad es. MIPS, GB)

Costi sviluppo software Dimensionamento dello impegno in tempo uomo a partire dalle caratteristiche quali-quantitative del sistema da realizzare (dimensione applicazione in FP/ produttività)

Valorizzazione del tempo uomo impegnato a costi standard o a tariffe di mercato

Costi avviamento Dimensionamento dell’impegno in tempo uomo a partire dalla analisi delle singole attività pianificate

Valorizzazione del tempo uomo impegnato a costi standard o a tariffe di mercato

Costi gestione sistemi Dimensionamento dello impegno in tempo uomo a partire dalle attività pianificate sulla base delle caratteristiche quali-quantitative dei sistemi da gestire e dei livelli di servizio richiesti + altre risorse usate nell’erogazione del servizio (tecnologie, locali , materiali di consumo, ecc.)

Valorizzazione del tempo uomo impegnato a costi standard o a tariffe di mercato + valorizzazione altre risorse utilizzate

Costi manutenzione hardware e software

% del prezzo dell’hardware e del software in manutenzione

6

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). (quantificazione) (valorizzazione) 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.

Piano deiprogetti

Piano delle attivitàdi esercizio

Piano delle risorse (personale, infrastrutture tecnologiche,altre)

Piano della spesa Costi per risorsa, per missione, ecc.

7

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 • prestazioni professionali studio

fattibilità • prestazioni professionali analisi e

progettazione • hardware

− mainframe − dipartimentali − pc/ws − altre apparecchiature − altro hardware

• software − di base e d’ambiente − pacchetti applicativi − prestazioni professionali realizzazione

software − altro software • rete

− apparecchiature rete e cablaggio − software rete − prestazioni professionali per rete − altro rete

• formazione utenti • prestazioni collaudo • messa in produzione

− acquisto locali − acquisto impianti tecnologici − prestazioni messa in produzione − altro per messa in produzione

• prestazioni monitoraggio • altri costi ---------------------------------------------

b) esercizio • hardware

− locazione/leasing mainframe − locazione/leasing dipartimentali − locazione/leasing stazioni di

lavoro − locazione/leasing altre

apparecchiature − manutenzione mainframe − manutenzione dipartimentali − manutenzione stazioni di lavoro − manutenzione altre

apparecchiature • software

− locazione/leasing software di base e d’ambiente

− locazione/leasing pacchetti applicativi

− manutenzione software di base e d’ambiente

− manutenzione pacchetti applicativi

− prestazioni professionali manutenzione software

• rete − locazione/leasing apparecchiature

di rete − locazione/leasing software di rete − manutenzione apparecchiature di

rete − manutenzione software di rete

• 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 ---------------------------------------------

8

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.

quantificazione

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.

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

Costi del progetto: costi per risorsa, per missione, ecc.

9

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

− stampanti laser 3.5 − stampanti di linea 3.6 − scanner 3.7 − sottosistemi a disco per mainframe 3.8 − sottosistemi a disco per sistemi intermedi 3.9

− altre apparecchiature e altro hardware

− librerie robotizzate 3.10 − apparecchiature rete e cablaggio − sistemi di cablaggio e componenti di reti

(hub, switch, router, ecc.) 3.11

software software − Software di base e d’ambiente per mainframe

4.1

− software di base e d’ambiente per sistemi UNIX

4.2

− dbms 4.4 − network & system management, ecc.) 4.5

− di base e d’ambiente

− strumenti di sviluppo applicativo 4.6 − pacchetti applicativi per desktop 4.3 − pacchetti applicativi e altro software − 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.

10

− software rete incluso nel costo delle apparecchiature (3.11) prestazioni e servizi servizi − prestazioni professionali studio

fattibilità − studi di fattibilità 5.2

− prestazioni professionali analisi e progettazione

− prestazioni professionali realizzazione software

− sviluppo software applicativo (compreso avviamento) e manutenzione evolutiva

5.3

− 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 − prestazioni messa in produzione

− servizi per il collaudo e la messa in produzione

5.5

− 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, dipartimentali, stazioni di lavoro, apparecchiature di rete, altre apparecchiature

− manutenzione prodotti hardware 5.7

− manutenzione software di base e d’ambiente, pacchetti applicativi e software di rete

− manutenzione prodotti software 5.8

− manutenzione ordinaria del software applicativo (MAC)

5.9 − prestazioni professionali manutenzione software

− manutenzione straordinaria anno 2000 5.10 − prestazioni professionali gestione

sistemi e assistenza utenti − gestione sistemi e reti (CED, pc/LAN, WAN, server)

5.11

− prestazioni per elaborazione dati − prestazioni professionali assistenza

sistemistica − assistenza sistemistica 5.12

− 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.

11

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.

12

2.2. Esempi di analisi del TCO Si riportano nel seguito, come primo esempio, i risultati di uno studio svolto nel 1995 dal Gartner Group per comparare i costi dei sistemi client/server con quelli dei sistemi basati su mainframe. I risultati, espressi in lire spese per posto di lavoro informatizzato all’anno, hanno evidenziato un costo per i sistemi C/S, pari a circa 9 milioni di lire all’anno 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.

TCO client/server vs. mainframe/terminali

mainframe/terminali

33%

34%

26%

7%

HW, SW e TLC

sviluppo egestionesupporto utenti

utenti finali

client/server21%

23%

15%

41%

13

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.

14

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.

15

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

16

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 rischio 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.

17

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, ecc.). Tali

prezzi vengono

rilevati sul mercato e

fanno riferimento a configurazioni medie3. Nella figura a lato è riportato, a titolo di

esempio, 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.

11

15

10,5

1211

9

7,7

11,5

76,66,6

6,6

10,2

8,6

7,2

2Q97 3Q97 4Q97 1Q98 3Q982Q98

IBM CMOS

Skyline 2

Amdahl

KDM/MIPS

Observed Selling Prices (+/- 10%, 1 year warranty)

© 1998 Ralf-Jürgen Sievers Consulting98_004st.ds4

6,6

5,8

4Q98

18

I prezzi medi di vendita dei mainframe sono diminuiti negli ultimi anni in misura rilevante scendendo da circa 100 milioni di lire/MIPS nel 1990 a meno di 10 milioni di 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) La continua riduzione dei 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

Cost per Configured OS/390 MIPSFonte: Gartner Group

Mid-Market Values of IBM's Large SystemsFonte: Gartner Group

19

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

20

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)

Rank Company Config tpmC $/tpmC Database

1 Sun Enterprise 10000 (64-way) 115,395.73 $105.63 Oracle8i v8.1.5.1

2 Digital AlphaServer 8400 (8 node x 12-way)

102,541.85 $139.49 Oracle8 v8.0.5

3 Sequent NUMA-Q 2000 E300 (64-way) 93,900.85 $131.67 Oracle8 Enterprise Edit'n

8.0.4

4 HP HP 9000 V2500 (32-way) 92,832.96 $86.94Oracle8i Enterprise Edit'n

8.1.5

5 IBM RS/6000 SP Model 309 (12 node x8-way)

57,053.80 $147.40 Oracle8 Enterprise Edit'n

8.0.4

6 Sun Enterprise 6500 (24-way) 53,049.97 $76.00 Sybase ASE 11.9.3

7 HP HP 9000 V2250 (16-way) 52,117.80 $81.17 Sybase ASE11.5 EBF

7817

8 Sun Ultra Enterprise 6000 c/s (2 node x22-way)

51,871.62 $134.46 Oracle8 Enterprise Edit'n

8.0.3

9 Sequent NUMACenter 2000 (32-way) 48,793.40 $127.53 Oracle8 Enterprise Edit'n

8.0.4

10 IBM AS/400e 9406-S40 (12-way) 43,169.85 $128.91 DB2 for AS/400 V4

Release 1

$/tpm(c)

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

21

Rank Company Config $/tpmC tpmC Database

1 Compaq ProLiant 7000 c/s (4-way) $18.84 22,478.90

M'soft SQL Server 7.0 Ent Ed'tn

2 Compaq ProLiant 5500 6/400 $21.71 17,715.90


3 Unisys Aquanta QS/2V (4-way) $22.11 19,118.37


4 Unisys Aquanta QR/2V (4-way) $22.19 19,118.37


5 Compaq ProLiant 7000 c/s (4-way) $22.50 19,725.10


6 Compaq ProLiant 3000-6/500-1S (2-way) $22.64 12,033.60


7 Unisys Aquanta ES5045 (4-way) $22.99 24,328.67


8 HP NetServer LH 4 (4-way) $23.10 19,050.17


9 Siemens Primergy 870-40 (4-way) $23.41 23,570.33


10 Unisys Aquanta QR/2 (4-way) $23.73 21,354.55


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 prestazioni dei sistemi, 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

Unix Server: TPC-CPerformance History

22

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.

23

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.

24

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.

25

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.

tipo configurazione n. utenti L/ML 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.

y = 3147.9x-0.1954

R2 = 0.6516

0

500

1000

1500

2000

2500

0 20 40 60 80 100 120

numero di utenti

pres

so p

er u

tent

e

26

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:

27

• 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

28

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à.

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.

fasce di pc(fonte: Intel)

Q2’99Q3’98 Q4’98 Q1’99

Pentium IIprocessor333 MHz

Celeronprocessor66MHz FSB

300A MHz


366/333 MHz

Celeron™processor66MHz FSB300 MHz

Celeron processor66MHz FSB

333/300A MHz


333 MHz


333 MHz

Pentium® IIprocessor

100MHz FSB450 MHz

Pentium IIprocessor

100MHz FSB400 MHz

Pentium IIprocessor

100MHz FSB450/400 MHz

Pentium IIprocessor


Pentium IIprocessor

100MHz FSB350 MHz

Pentium IIprocessor


Katmai100MHz FSB

450 MHz

Katmai100MHz FSB

500 MHz

Celeron processor66MHz FSB

366 MHz

Pentium IIprocessor

100MHz FSB400 MHz

Katmai450 MHz

Pentium II proc.450 MHz

Pentium IIprocessor

100MHz FSB

400 MHz

Pentium IIprocessor

100MHz FSB450 MHz

Pentium IIprocessor

100MHz FSB450 MHz

Katmai100MHz FSB

500 MHz

Katmai100MHz FSB

500 MHz

Sys Price(w/o monitor)

Professional>$2.5K

MainstreamPerformance 3$2.0-2.5K



Basic BusinessPC 2$900-1,200Basic BusinessPC 1<$900

29

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.

30

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.

31

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.

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

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

0

200000

400000

600000

800000

1000000

1200000

1400000

0 100 200 300 400 500 600 700 800 900 1000

pagine al minuto

migliaiadilire

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

32

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)

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

prezz i di listino delle stampanti di linea(fonte SIRMI)

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

50000

0 500 1000 1500 2000 2500

linee al minuto

mig

liaia

di l

ire

33

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.

price/capacity IBM RAMAC(Source: GartnerGroup)

1

2

500 1,000 1,500

85 percent discount assumed, systems with average configuration

RVA (Without Snapshot)

RSA

RAMAC3+9390

RAMAC3+9390, RVA:first

systemsecond system

DM/MB

Gbytes

34

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).

35

3.9. Sottosistemi a disco 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

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:

fonte:GartnerGroup

36

• 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).

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

Cartridge Capacityfonte: Gartner Group

37

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.

38

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.

Per le apparecchiature di rete la stima di dettaglio è basata sulla specifica configurazione (prezzo di listino + sconti volume).

Scenario dei Prezzi relativi 1H98Tecnologia Apparecchia-

turaVelocità Prezzo per

PortaShared Fast Ethernet Hub 100 Mbps $ 100Switched Fast Ethernet Switch 100 Mbps $ 150Switched TokenRing Switch 16 Mbps $ 350Shared FDDI Concentrator 100 Mbps $ 680Switched FDDI Switch 100 Mbps $ 3200ATM Switch 622 Mbps $ 4200Shared Gigabit Ethernet Hub 1 Gbps $ 1400Switched Gigabit Ethernet Switch 1 Gbps $ 2000

39

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).

40

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à (MIPS)

minimo massimo mediana

<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).

41

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.

42

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)

01020304050

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.

43

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.

44

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.

45

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.

46

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.

47

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

48

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

49

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;

50

• 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.

51

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

52

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.

53

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 − distribuzione della elaborazione − prestazioni − utilizzo intensivo della

configurazione − frequenza delle transazioni − inserimento dati interattivo − efficienza per l’utente finale

− aggiornamento interattivo − complessità elaborativa − riusabilità − facilità di installazione − facilità di gestione operativa − molteplicità di siti − facilità di modifica

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.

54

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 Assembler 320 C 128 Cobol e Cobol II 107 Pascal 91 PL/1 80 Fortran 95 71

5.3.4.1. Linguaggio

istruzioni per FP

C++ 53 Java 53 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.

55

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.

La correlazione esistente tra il livello di un linguaggio e la produttività di sviluppo non è lineare. I benefici si ottengono principalmente nella fase di codifica e, in misura minore, in fase di integrazione e test. Per 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 la 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 strutturati

con impiego di metodi strutturati5 linguaggio

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

LANGUAGE LEVEL PRODUCTIVITY AVERAGE PER STAFF MONTH-------------- -------------------------• 1 - 3 5 to 10 Function Points• 4 - 8 10 to 20 Function Points• 9 - 15 16 to 23 Function Points• 16 - 23 15 to 30 Function Points• 24 - 55 30 to 50 Function Points• Above 55 40 to 100 Function Points

56

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’impegno 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

57

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 si dà convenzionalmente è che il costo cresce esponenzialmente con la complessità, cioè:

costo = F(dimensione)n con n>1

In realtà una attenta analisi dei dati dimostra che, benché sia vero che le dimensioni del progetto 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.

Produttività in funzione delladimensione (NESMA)

05

10152025

produttività (FP/MU)

<100

100-

250

250-

500

500-

750

750-

1000

1000

-150

0

>150

0

dimensione del sistema (FP)

58

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.

59

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.

60

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

61

• 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

62

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.

63

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.

64

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.

65

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;

• 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

canone di manutenzione mensile per M IPS

0

50

100

150

200

250

300

3084 3090-E 3090-J 9021 9672

US

$

66

• 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.

canone di manutenzione mensile per GB

020406080

100120140

3380-STD

3380E

3380-k

3390-2

3390-3

RAMAC

RAMAC-2U

S $

67

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 interventi 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

68

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 precisione 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;

69

• 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

(costo della non qualità)

00.5

11.5

2

0 1 2 3 4 5 6 7 8 9 10

età della applicazione

ore-uomo per FP

enhancementtotal

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.

70

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.

71

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à hardware

software servizi

Oggetti impattati

da adeguare

acquisto/ noleggio hardware

adegua-mento licenze software

acquisto/ noleggio di tool

acquisto/ noleggio pacchetti software

di supporto all’utilizzo di tool

supporto sistemisti-co per aggiorna-mento licenze e migrazioni

di conversione anno 2000

noleggio ambiente di test

hardware X X X software base

X X X

pacchetti sw X X X applicazioni

X X X X X X X X

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.

72

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:

9Per 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%.

73

• 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;

• disponibilità 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ò comportare 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.

74

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 sincronizzazione Soluzione tecnica

I/O logica contenuto struttura ampliamento del campo anno

X X X X Alta

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.

75

Le attività da svolgere sono indicate nella tabella seguente: operative System Operations

Operations Support

Tape Operations

Help Desk

Print Operations

Microfiche Operations

Production Control

Management

supporto tecnico Operating System Support

Subsystem Support

Internal Systems Support

Performance Analysis

Capacity Planning

Storage Management

System Security

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.

76

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 servizi tecnici si può assumere un rapporto di 1:2 rispetto al personale operativo. Altri fattori che influenzano il numero di risorse impiegate per MIPS sono: • 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.

00.05

0.10.15

0.20.25

0.30.35

0.40.45personale

operativo

perMIPS

<80 80-135

135-215

215-400

>400 2500-3000

MIPS installati

77

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:

78

• 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.)

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.

0102030405060708090

2 3 4 5 6 7 8 9 10 11 12 13 14

indice di complessità

utenti

per

staff

79

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 PC

Rapporto staff 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.

80

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.

81

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

82

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

LA STIMA DEI COSTI DEI SISTEMI INFORMATIVI … · uomo impegnato a costi standard o a tariffe di...

Documents

Transcript of LA STIMA DEI COSTI DEI SISTEMI INFORMATIVI … · uomo impegnato a costi standard o a tariffe di...