Contract

Le Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della pubblica amministrazione hanno lo scopo di definire:

un quadro di riferimento complessivo per l’appalto pubblico di servizi ICT da parte delle amministrazioni;
metodi quantitativi da applicarsi per definire misure di qualità ed identificare processi di misura, allo scopo di fornire indicazioni concrete, pragmatiche, immediatamente applicabili, sia alle amministrazioni appaltanti che ai fornitori offerenti;
adeguate clausole, da utilizzarsi in fase di negoziazione, per la definizione di capitolati e contratti pubblici per la fornitura di beni e servizi nel settore ICT, relative alla descrizione delle attività da prevedersi contrattualmente, ai prodotti che dette attività realizzano (deliverables contrattuali), agli indicatori e misure di qualità da riferirsi sia alle attività che ai prodotti;
clausole successivamente utili nella fase di attuazione dei contratti ICT, per la necessaria azione di governo del contratto e lo svolgimento del monitoraggio per la verifica del rispetto dei requisiti contrattuali in termini di tempi, costi e stato avanzamento lavori, quantità e qualità attese dei servizi ICT richiesti.

Complessivamente le Linee guida rappresentano un metodo che fornisce concrete indicazioni operative sui processi e le attività inerenti l’approvvigionamento dei servizi ICT, applicabili al contesto della Pubblica Amministrazione italiana. Esse non pretendono di fornire generiche soluzioni preconfezionate che, evidentemente, non potrebbero soddisfare ogni possibile esigenza ed adattarsi ad ogni contesto, piuttosto l’intento è quello di isolare i bisogni specifici dell’ambito pubblico e le criticità maggiormente ricorrenti, per fornire indicazioni su come concretamente sia possibile governare queste situazioni al fine di migliorare la qualità delle forniture ICT.

Da questo punto di vista, quindi, le Linee guida non pretendono di costituire una innovazione metodologica, ma perseguono l’obiettivo, meno ambizioso ma più concreto di costituire un prontuario di consigli, buone pratiche e suggerimenti per affrontare casi concreti che potrebbero effettivamente prospettarsi nell’eseguire le attività tipiche di tutto il ciclo di vita dell’acquisizione delle forniture ICT.

È lasciato all’utilizzatore, il quale conosce i propri fabbisogni nel dettaglio, l’onere di selezionare, tra le diverse possibilità, le indicazioni o i suggerimenti più convenienti e concretamente applicabili, in funzione del contesto. Le Linee guida forniscono supporto per il raggiungimento di tale obiettivo dando indicazioni su come operare per:

l’analisi del contesto in cui calare le indicazioni operative suggerite;
l’applicazione delle indicazioni secondo necessità, previa scelta tra le diverse possibilità offerte;
il governo delle forniture ICT ed il monitoraggio degli indicatori di qualità;
il coinvolgimento attivo del personale ICT;
la formazione mirata nei confronti di risorse professionali, in possesso di molteplici tipologie di cultura (giuridica, amministrativa, informatica, manageriale), coinvolte a diverso titolo nel ciclo di vita dell’acquisizione delle forniture ICT.

L’approccio utilizzato può essere definito di tipo situazionale: le diverse pratiche e soluzioni possibili (opzioni) sono descritte nelle Linee guida tramite le proprie caratteristiche, i principali contesti d’uso, i vantaggi (pro) e gli svantaggi (contro), in modo da ottenere un pluralismo di pratiche proposte, per le quali nessuna soluzione è mai la migliore o peggiore in assoluto, ma rimane aperta la possibilità per chiunque di aggiungere la prassi preferita alle altre già codificate.

Dal punto di vista logico, per tener conto della consequenzialità e propedeuticità, gli argomenti sono stati sviluppati in modo tale che possano essere collocati all’interno di un ciclo di vita dell’acquisizione delle forniture ICT. Ad ogni fase di tale ciclo di vista corrispondono dei manuali che entrano nel merito delle rispettive tematiche:

Manuali applicativi, che forniscono indicazioni metodologiche di massima, ragionamenti, punti di attenzione, applicabili relativamente alla fase del ciclo di vita considerata.
Manuali operativi, che forniscono materiale riutilizzabile direttamente nella redazione di documenti.

Arricchiscono infine l’opera i Manuali di riferimento, i quali non hanno lo scopo di fornire indicazioni operative, ma quello di indagare argomenti correlati che possano completare ed integrare i contenuti precedentemente descritti, fornendo i riferimenti culturali di base e le indicazioni per possibili ulteriori approfondimenti.

In questa ottica il presente Manuale prende in considerazioni alcuni modelli internazionalmente riconosciuti che identificano e descrivono sistematicamente i processi per la gestione dei servizi di Information Technology e la Governance dell’ICT, convenzionalmente denominati “best practice”, letteralmente “migliori pratiche”.

La diffusione della conoscenza di dette best practice all’interno della pubblica amministrazione ha lo scopo di:

migliorare la cultura della Governance ICT nella Pubblica amministrazione;
diffondere la conoscenza dei metodi di lavoro più adottati fra i fornitori ICT per la definizione dei loro processi produttivi;
fornire utili approfondimenti delle tematiche trattate nelle Linee guida;
correlare i bisogni informativi della PA in tema di governance dell’ICT, codificati nelle Linee guida, con le migliori pratiche internazionali disponibili.

Coerentemente con tali obiettivi e senza alcuna pretesa di esaustività, rispetto ad un panorama che a livello internazionale si presenta estremamente variegato, si è scelto di circoscrivere la trattazione alle Best Practice più direttamente correlate agli aspetti trattati dalle Linee guida in tema di realizzazione di progetti e erogazione di servizi ICT:

Sviluppo e integrazione di prodotti software;
Governance dell’ICT;
Gestione dei servizi ICT;
Gestione dei progetti ICT.

Le best practice selezionate, riepilogate nella seguente tabella, costituiscono un insieme tra loro complementare, rappresentativo delle migliori pratiche esistenti a livello internazionale.

Best Practice	Ambito di applicazione
CMMI-DEV Capability Maturity Model Integration for Devolution	Sviluppo e integrazione di prodotti software
COBIT Control Objectives for Information and related Technology	Governance dell’ICT
ITIL Information Technology Infrastructure Library	Gestione dei servizi ICT
PM BOK Guide to the Project Management Body of Knowledge	Gestione dei progetti
PRINCE 2 Projects IN Controlled Environments	Gestione dei progetti

In considerazione della vastità delle best practice esistenti, i criteri di selezione adottati per limitare il numero di quelle da approfondire hanno privilegiato quelle dotate delle seguenti caratteristiche:

aderenza dei contenuti agli argomenti trattati dalle Linee guida, pur mantenendo un punto di vista complementare;
applicabilità all’ICT e/o alla Pubblica Amministrazione dei concetti e degli approcci codificati al loro interno;
indipendenza da specifici fornitori ICT, perché definite, evolute, promosse e diffuse da associazioni internazionali, costituite sia da Fornitori ICT che da organizzazioni rappresentanti la domanda di servizi ICT, che svolgono la propria attività senza fini di lucro;
diffusione in ambito europeo, sia tra i Fornitori ICT che, più limitatamente, all’interno della Pubblica Amministrazione;
reperibilità, dovuta ai limitati costi d’accesso e alla localizzazione in Italia o, in caso contrario, almeno nell’Unione Europea, delle associazioni che hanno il compito di definirle, evolverle, promuoverle e diffonderle;
accessibilità, agevolata dalla strutturazione della documentazione e dalla disponibilità di documentazione anche in lingua italiana oltre che in inglese.

Alla specifica trattazione di ogni best practice è dedicato un documento autonomo, autoconsistente e indipendente, che chiameremo “lemma”, in quanto, come per i lemmi di un comune dizionario, non è necessaria una fruizione sequenziale, ma è possibile una consultazione in funzione di specifiche esigenze informative da soddisfare.

Questa impostazione consente eventualmente di aggiungere ulteriori lemmi dedicati ad eventuali nuove best practice pertinenti agli argomenti progressivamente trattati dalle Linee guida.

Conseguentemente questo Manuale può intendersi come un dizionario delle best practice inerenti la realizzazione di progetti e l’erogazione di servizi ICT.

Diversamente dai lemmi del Manuale 4, “Dizionario delle forniture ICT”, i contenuti dei lemmi di questo Manuale non sono destinati ad un immediato utilizzo per la redazione dei documenti contrattuali. Con essi viceversa si vuole fornire un accesso guidato a vasti insiemi di conoscenza, correlati ai temi trattati dalle Linee guida, referenziando opportunamente la documentazione delle best practice spesso imponente e, per la maggior parte, in lingua inglese.

Il presente Manuale rappresenta, di contro, una sorta di guida alla lettura, in quanto è dedicato a rendere più agevole la consultazione dei lemmi, anticipandone gli aspetti salienti. In particolare

Il Cap. 3 del Manuale fornisce, per ogni Best Practice analizzata, una sintesi dei contenuti.

Il Cap. 4 del Manuale è dedicato ad analizzare l’applicabilità delle best practice, in relazione alle generiche macrocroattività, che tipicamente si succedono relativamente ad una fornitura ICT in ambito pubblico (analisi di fattibilità, realizzazione dei progetti, erogazione dei servizi ICT, analisi di impatto). La tabella seguente colloca le diverse best practice in relazione con dette macroattività specificando se la trattazione è approfondita (A) o solo accennata (C).

	CMMI-DEV	COBIT	ITIL	PMBOK	PRINCE2
macroattività
Analisi di fattibilità	A	A	C	C	A
Realizzazione dei progetti	A	A	C	A	A
Erogazione dei servizi ICT	A	A	A	C	C
Analisi di impatto	C	A	A	C	A

Il Cap. 5 del Manuale è dedicato ad esplicitare i riferimenti incrociati fra i bisogni della Pubblica Amministrazione, rappresentati dalle Linee guida, con l’apparato documentale delle Best Practice. Ciò non è finalizzato ad un paragone fra le Linee guida e le Best Practice trattate, perché esso è reso improponibile dalle divergenti finalità. Infatti mentre le Linee guida costituiscono un metodo, finalizzato ad un utilizzo operativo nella Pubblica Amministrazione Italiana, al contrario le Best Practice sono modelli che esprimono principalmente il punto di vista del Fornitore di prodotti o servizi ICT e non forniscono indicazioni univoche e vincolanti, ma necessitano di un adattamento alle situazioni operative vigenti.

Il Cap. 6 del Manuale, a completamento dei temi trattati, introduce alcuni Standard ISO, interessanti per la loro applicabilità in ambito ICT in relazione alle seguenti tematiche

Gestione della qualità;
Gestione della sicurezza ICT;
Gestione dei servizi ICT;
Gestione dei progetti.

Come per le Best Practice gli standard internazionali ISO trattati sono quelli ritenuti più pertinenti alla realizzazione di progetti e all’erogazione di servizi ICT.

Detti standard, riepilogati nella seguente tabella, permettono la certificazione dei sistemi produttivi di organizzazioni (fornitori ICT) impegnate nella realizzazione di progetti e l’erogazione di servizi ICT.

Standard	Ambito di applicazione
UNI EN ISO 9001:2000 Sistemi di gestione per la qualità. Requisiti	Gestione della Qualità
ISO/IEC 27001:2005 IT - Security techniques - Information security management systems - Requirements	Gestione della sicurezza ICT
ISO/IEC 20000-1:2005 IT - Service Management – Part 1: Specification	Gestione dei servizi ICT
UNI ISO 10006:2005 Linee guida per la gestione per la qualità nei progetti	Gestione dei progetti

Gli standard rappresentano un insieme di requisiti predeterminati di un sistema produttivo di un’organizzazione che fissano le caratteristiche di processi, o servizi, o organizzazione.

Diversamente dalle best practice, che oltre a fissare il “COSA” si debba fare all’interno del sistema produttivo, forniscono dettagli sul “COME” e su “CHI”, arrivando a definire attori, processi, attività e prodotti del sistema stesso, gli standard si limitano al “COSA” esplicitando vicoli che il sistema produttivo deve soddisfare.

Poiché gli stessi requisiti possono essere soddisfatti con approcci diversi, ne deriva che dagli standard non discendono dirette indicazioni su come debbano concretamente essere disegnati i processi produttivi di un’organizzazione.

Se correttamente applicati, gli standard permettono di certificare quel dato sistema produttivo come coerente con lo standard applicato.

Il Cap. 7 del Manuale presenta la modalità univoca con al quale sono descritte le best practice e egli standard, descrivendo la strutturazione delle informazione contenute nei lemmi, in modo da rendere più agevole per il lettore il reperimento delle informazioni di dettaglio.

Il valore aggiunto del presente Manuale sta proprio nella presentazione di diversi best practice e standard effettuata attraverso lemmi strutturalmente identici, allo scopo di facilitarne la comprensione e il confronto.

Riferimenti

Riferimenti a standard e norme sono direttamente riportati all’interno di ciascun lemma in relazione alle best practice ed agli standard trattati.

2.modalità di Lavoro

Le Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione sono state il frutto di un Gruppo di lavoro interdisciplinare, costituito dal Centro nazionale per l’informatica nella pubblica amministrazione (CNIPA), che ha operato dal Dicembre 2003 al Gennaio 2005 ed ha coinvolto alcune Amministrazioni centrali, due società di informatica a capitale interamente pubblico (CONSIP, SOGEI) e le associazioni di categoria dei fornitori ICT (Confindustria servizi innovativi e tecnologici e ASSINFORM).

A valle del completamento dei lavori di tale gruppo è proseguita la gestione delle Linee guida, finalizzata al mantenimento nel tempo della loro validità ed attualità, sotto la responsabilità del Xxxx. Xxxxx Xxxxxxx, già coordinatore del Gruppo di lavoro, ed attuale dirigente dell’Area divisionale “Metodologie per la qualità e per l’innovazione organizzativa”, del CNIPA. Tale attività di gestione si è caratterizzata per i seguenti obiettivi:

promuovere e favorire l’utilizzo delle Linee guida da parte delle amministrazioni centrali e locali mediante iniziative di diffusione della conoscenza e di formazione;
recepire indicazioni, suggerimenti, richieste, provenienti da amministrazioni e imprese;
aumentare l’estensione e la profondità degli argomenti trattati, per arrivare a coprire progressivamente tutti i temi pertinenti alla qualità delle forniture ICT o ad essi correlati, a partire dal presente manuale di riferimento;
aumentare la coerenza del disegno complessivo delle Linee guida ed affinare gli indicatori di qualità sulla base di prassi concrete;
mantenere attivo il canale di interazione sulla contrattualistica ICT che si è creato con le Associazioni di categoria ed i Fornitori stessi;
assicurare la disponibilità dei contenuti delle Linee guida attraverso molteplici canali di diffusione.

Il presente Manuale, frutto della politica sopra delineata, è stato realizzato da un gruppo di lavoro misto, costituito da componenti del CNIPA e membri delle sotto elencate organizzazioni:

AICQ (Associazione Italiana Cultura Qualità)
AIEA (Associazione Italiana Information Systems Auditors)
ISIPM (Istituto Italiano di Project Management)
itSMF (IT Service Management Forum)
PMI (Project Management Institute)
SEI (Software Engineering Insitute)

Un particolare ringraziamento va a chi ha direttamente partecipato alla redazione del manuale.

Xxxxx Xxxxx Xxxxx Xxxxxxxxx Xxxxx Xxxxxxx Xxxxxxx Xxxxx	CNIPA
Xxxxxxxx Xxxxxx	AIEA
Xxxxxx Xxxxxxx	itSMF
Xxxxxx Xxxxxxxx Xxxxxxx Xxxxx Xxxxxxxx Xxxxxxx Xxxxxxxx Xxxxxxxx Xxxxx Xxxxxxxxxxx Xxxxxxxxxxxx Xxxxxxxxxx Xxxxxx Xxxxxxxx	SEI
Xxxxxx Xxxxxxxxxxxxx Xxxxxxxx Xxxxxxxxxx Xxxx Xxxxxx	PMI
Xxxxxx Xxxxxxxx Xxxxxx Xxxxxxxx	ISIPM
Xxxxxxx Xxxxxxxx Xxxxxxx Xxxx Xxxxxxx Xxxxxxxx Xxxxxxx Xxxxxxxx Xxxxxxx Xxxxxxxx	XXXX – Comitato per la “Qualità del software e dei servizi IT”

Come già accaduto per gli altri Manuali che costituiscono le Linee guida, le imprese associate a Assinform afferenti alla Confindustria Servizi Innovativi e Tecnologici ne hanno condiviso l’impostazione ed i contenuti ritenuti coerenti con le proprie fattive esperienze di governo di contratti e progetti ICT.

3. Best Practice analizzate

Le best practice sono modelli di conoscenza strutturata e codificata, i cui contenuti sono ottenuti a partire da esperienze significative e ricorrenti, concretamente esperite da organizzazioni nell’ambito delle proprie attività di realizzazione di progetti e erogazione di servizi ICT. Dette esperienze sono successivamente generalizzate ed astratte, codificate in processi ed arricchite di istruzioni operative, esempi, check list, schemi documentali (template) ed altra documentazione complementare.

Le best practice applicabili in ambito ICT sono numerose ed hanno diverse finalità. La ricognizione oggetto del presente capitolo riguarda un insieme relativamente piccolo, ma significativo selezionato secondo criteri già esplicitati nel Cap. 1.

In questo capitolo si presenta una sintesi delle Best Practice analizzate. Per maggiori dettagli su ogni best practice si rimanda ai lemmi, documenti indipendenti fruibili singolarmente scaricabili via internet dal sito istituzionale CNIPA (xxxx://xxx.xxxxx.xxx.xx, sezione “Qualità delle Forniture ICT” sulla sinistra in basso dell’home page).

CMMI-DEV: Capability Maturity Model Integration for Development

È un modello di definizione e valutazione dell'efficacia dei processi afferenti all’ingegneria del software (sviluppo, manutenzione, integrazione di software applicativo) o dei sistemi, che ne definisce un approccio al miglioramento. Il CMMI può aiutare per l’integrazione fra le funzioni di un’organizzazione, per fissare obiettivi di miglioramento, per ridurre i rischi di progetto.

Si basa una specializzazione del Capability Maturity Model (CMM) originariamente sviluppato dal Software Engineering Institute (SEI), un ente di ricerca e sviluppo, finanziato dal governo federale degli Stati Uniti d’America e affiliato alla Carnegie Mellon University (CMU).

In questo manuale è analizzata solo la componente, detta anche “costellazione”, CMMI-DEV v1.2 destinata principalmente agli sviluppatori di software. L’approccio adottato dal modello è quello di definire un insieme di aree di processo critiche (Process Area, PA), che consentano, quando siano propriamente implementate, di definire e migliorare i processi di un’organizzazione dedita alla realizzazione di prodotti software ICT.

Questo tipo di attività, normalmente, è di tipo progettuale. Tuttavia esistono condizioni, che spesso ricorrono nella relazione con la Pubblica Amministrazione, nelle quali non è inconsueto considerare lo sviluppo software come erogazione di un servizio: si pensi ad esempio il caso di un contratto quadro che preveda lo sviluppo di software applicativo i cui corrispettivi siano calcolati sulla base di misure funzionali (function points).

In generale questa approssimazione è applicabile in condizioni per le quali i requisiti tecnici e di qualità non siano parametri soggetti a variazione. Questo è appunto il caso in cui ci interessa indagare il contributo CMMI-DEV, che, ovviamente, è applicabile anche nella casistica più generale,

Nella valutazione del miglioramento dei processi CMMI individua due possibili itinerari di evoluzione organizzativa:

La rappresentazione continua, nella quale le aree di processo sono raccolte in quattro famiglie (categorie) in funzione degli obiettivi perseguiti:

Gestione di Progetto (Project Management);
Gestione di Processo (Process Management);
Supporto (Support);
Sviluppo Tecnico (Engineering

La rappresentazione scalare, che individua 5 livelli di maturità utilizzabili per la valutazione del sistema informativo aziendale:

Livello 1: Iniziale;
Livello 2: Gestito;
Livello 3: Definito;
Livello 4: Quantitativo;
Livello 5: Ottimizzato.

Riassumendo, i concetti fondamentali su cui si basa il modello in parola sono le 4 Categorie in cui sono organizzate le 22 Aree di processo e i 5 livelli di maturità.

Il SEI rende disponibili diverse certificazioni, sia per la propria rete di partner, al fine di convalidare l’affidabilità dei servizi offerti dai professionisti associati, sia per le organizzazioni che adottano uno dei modelli delle costellazioni CMMI, al fine di convalidare la corretta interpretazione ed applicazione dei principi del modello relativo. La certificazione aziendale è articolata su tre diversi livelli, che possono essere raggiunti con il superamento di esami con crescenti livelli di indagine e di approfondimento, condotti da personale autorizzato dal SEI.

COBIT: Control OBjectives for Information and related Technology.

È un sistema di best practice finalizzate al governo ed il controllo dei sistemi informatici (Information Technology Governance) redatto dall’Information Systems Audit and Control Association (ISACA) e successivamente gestito dall’IT Governance Institute (ITGI).

Fornisce un quadro di riferimento fatto di domini e processi e presenta le attività in una struttura gestibile e logica. Le buone pratiche contenute in COBIT sono condivise dagli esperti e riguardano principalmente il controllo piuttosto che gli aspetti operativi con l’intento di fornire un riferimento con valenza generalizzata che raccoglie le migliori prassi nella gestione e Governance dell’ICT, senza particolari specificità ad ambiti di mercato o settori industriali.

In COBIT è dichiarato l’obiettivo di proporsi come modello che possa supportare l’Alta Direzione nell’implementazione di opportune pratiche di IT Governance, ma interessa tutti gli operatori aziendali impegnati nella conduzione dei sistemi informativi. COBIT è costituito dalle seguenti componenti:

Board Briefing on IT Governance 2nd edition, e IT Governance Implementation Guide, destinati all’alta direzione, aiutano a comprendere necessità, responsabilità, problematiche e step progettuali legati all’IT Governance.
Framework, che definisce la struttura dei vari processi IT articolati in 4 domini (Planning and Organization, Acquisition and Implementation, Deliver and Support, Monitoring and Evaluation);
Control Objectives, che forniscono un insieme di requisiti da considerare per un controllo efficace dei processi IT;
Control Practices, che definiscono come implementare i controlli sui processi IT
Audit Guidelines (IT Assurance Guide using COBIT), che aiutano nello svolgimento di attività di IT assurance suggerendo le modalità di valutazione del disegno e dell’operatività dei controlli IT;
Management Guidelines/Maturity Model, un insieme di linee guida relative ai livelli di maturità, fattori critici di successo e indicatori di performance dei processi IT.

I concetti fondamentali su cui si basa il modello in parola sono i 4 domini, suddivisi in 34 processi su cui possono essere posti 210 Obiettivi di controllo. Le pratiche di controllo suggerite sono circa 1.000.

La prima versione di COBIT risale al 1996 ed è stata il risultato di un gruppo di ricerca pluriennale di ISACA. Tale organizzazione rilascia certificazioni alla persona, articolate su più livelli, che attestano la conoscenza e le competenze raggiunte sul modello. Non esistono invece certificazioni aziendali in assenza di specifiche norme da adottare e rispettare.

ITIL: Information Technology Infrastructure Library.

È una raccolta di Best Practice, ispirate dalla pratica per la gestione dei servizi ICT e fornisce una descrizione dettagliata di importanti pratiche, con cheklist complete, compiti, procedure e responsabilità. ITIL è caratterizzato da un approccio innovativo, che privilegia l’utilizzabilità rispetto all’organicità ed omogeneità della trattazione. Ad alto livello ITIL è focalizzato sulle componenti della gestione del Servizio e su come queste sono tra loro correlate. Il ciclo di vita dei Servizi è caratterizzato da cinque fasi, ciascuna trattata all’interno di uno specifico volume di ITIL:

Service Strategy;
Service Design;
Service Transition;
Service Operation;
Continual Service Improvement

Ogni fase del ciclo di vita è caratterizzata da degli obiettivi che, partendo dalla definizione delle strategie, si fanno sempre più operativi. Ogni volume di ITIL è una raccolta di migliori pratiche, molto spesso organizzate come processi, omogenee da punto di vista delle finalità, che complessivamente hanno come riferimento cardinale la soddisfazione del business e del cliente.

Per dare un’idea delle dimensioni del modello in parola si può dire che, complessivamente, i 5 servizi ora descritti, sono articolati in 22 processi e 24 attività che non sarebbe produttivo descrivere ora in maggior dettaglio.

ITIL si presenta come una metodologia estremamente flessibile per la progettazione e l’implementazione di un modello di gestione dei servizi ICT che vada bene per qualsiasi organizzazione.

Le Best Practice di ITIL sono state sviluppate per essere adattate e questa peculiarità ha reso l’ambito di applicazione molto vasto. Infatti le indicazioni sull'erogazione di servizi, e sui processi e mezzi necessari a supportarli, possono essere idonee a qualsiasi organizzazione ICT, sia quelle al cui interno esista una funzione ICT, indipendentemente dal settore di riferimento e dalla natura dei propri clienti, sia quelle che abbiano la fornitura dei servizi ICT come core business.

Per quanto riguarda la copertura essa è amplia e approfondita relativamente all’erogazione dei servizi ICT, mentre le attività di realizzazione del software sono ancora trattate in modo piuttosto marginale. Tale situazione comunque potrà evolvere perché il modello conosce continui aggiornamenti ed estensioni.

Non esistono dirette certificazioni aziendali di conformità ad ITIL, di fatto tale certificazione è assolta dalla ISO 20000. Tuttavia esistono certificazioni professionali, articolate in più livelli, rilasciate da Organizzazioni di Training accreditate, attestanti il livello di competenze ed expertise.

PMBOK: guide to the Project Management Body Of Knowledge

Il PMBOK costituisce il testo di riferimento che si propone di raccogliere l’insieme delle conoscenze relative alla gestione dei progetti. In esso sono identificate e descritte le conoscenze e le pratiche riconosciute applicabili nella maggior parte dei progetti. La guida definisce i processi e gli strumenti finalizzati alla possibilità di realizzare con successo un progetto.

Tale guida è pubblicata dal Project Management Institute (PMI), un’associazione senza scopo di lucro fondata nel 1969 a Philadelphia in Pennsylvania, riconosciuta a livello internazionale, come autorevole nel campo del Project Management e riferimento fondamentale per tutti coloro che sono interessati alla professione del Project Manager.

In più di trent’anni di attività organizzata dal PMI, i vari gruppi di lavoro coinvolti hanno cercato di produrre una guida sempre più sistematica e organizzata cercando di affinare i concetti trattati, di recepire le osservazioni dei revisori, di aggiungere documentazione di pratiche e tecniche e strumenti riconosciuti validi, di usare un linguaggio che otre ad essere chiaro e facilmente traducibile sia condiviso dalla comunità di coloro che vogliano discutere e applicare la disciplina trattata.

Il PMBOK presenta la disciplina della Gestione progettuale organizzando la conoscenza concernente tale dominio in due dimensioni trasversali: i processi di project management (suddivisi a loro volta in cinque insiemi) e le aree di conoscenza utili per il project management.

I processi elementari (caratterizzati da flusso, input e output) da mettere in atto per la realizzazione di un progetto sono stati raccolti in gruppi di processi correlati tra loro: i gruppi di processi di avvio e di chiusura, da eseguirsi una sola volta, i gruppi di pianificazione ed esecuzione, che formano un ciclo e si innescano a vicenda ad ogni variazione progettuale ed il gruppo di processi di monitoraggio e controllo, attività trasversali e di integrazione da condurre durante tutta la durata progettuale.

Gli stessi processi elementari, utilizzando un diverso punto di vista, sono raggruppati rispetto ad una tematica andando a costituire così un’area di conoscenza, la quale raggruppa l’insieme di processi e/o attività necessarie per eseguire e completare il progetto relativamente alla tematica trattata.

I concetti fondamentali su cui si basa PMBOK sono i 5 gruppi di processo, che cadenzano l’evoluzione del progetto e le 9 aree di conoscenza che raccolgono le informazioni utili per il capo progetto.

I destinatari sono tutte le organizzazioni che utilizzano la modalità di lavoro a progetti, sia al proprio interno sia verso i propri clienti, all'esterno, in quanto interessate ad avere, fra i propri membri, persone in possesso di approfondita cultura nell’ambito del Project Management. Le certificazioni PMI riguardano le persone e sono articolate su più livelli per coprire tutti i possibili ruoli impegnati nella gestione progettuale.

Metodologia TenStep

Un approfondimento ‘operativo’ rispetto a quanto previsto dal PMBOK, che arriva a definire esaustivamente i processi afferenti al project management, è fornito dalla metodologia TenStep, sviluppata dall’omonima organizzazione americana specializzata nello sviluppo di metodologie di business e servizi di formazione e consulenza. A completamento della trattazione inerente il PMBOK di seguito si accenna a questa metodologia.

Il‘Processo di Project Management TenStep’ è un processo flessibile e scalabile adatto per gestire qualsiasi lavoro come un progetto sulla base di dieci passi (ten step); è applicabile in modo diverso a secondo della dimensione del progetto che viene determinata dai seguenti fattori: l’impegno previsto, l’esperienza del capo progetto, la complessità unita alla criticità.

La metodologia comprende processi, tecniche, best practice, modulistica e materiale di formazione e può essere adottata per gestire qualsiasi tipo di progetto anche se molti riferimenti ed esempi sono forniti per progetti di sviluppo software.

La struttura del processo è composta da dieci passi di cui due iniziali:

definizione del lavoro;
sviluppo del piano di lavoro e del budget;
gestione del piano di lavoro e del budget;
gestione dei problemi;
gestione del contenuto;
gestione della comunicazione;
gestione del rischio;
gestione della documentazione;
gestione della qualità;
gestione delle metriche.

I primi due processi sono essenziali e sono interdipendenti fra loro. Gli altri otto processi sono indipendenti e si applicano con rigore crescente in base alle dimensioni, alla complessità ed all’importanza del progetto.

La metodologia TenStep si propone di seguire il capo progetto dall’avvio al compimento del progetto; spiega, fornendo esempi, come applicare le tecniche enunciate nel PMBOK e fornisce modelli (template) dei deliverable.

Occorre sottolineare che il PMBOK ed il Processo TenStep non sono in contrapposizione tra loro; in TenStep si definisce il PMBOK come “una base fondamentale delle aree di conoscenza … ma non è una metodologia che si può utilizzare per gestire direttamente un progetto”.

Al fine di evidenziare le analogie e le differenze tra i due approcci, in TenStep è presente una mappatura delle nove aree di conoscenza del PMBOK con i processi descritti nei dieci passi della metodologia TenStep.

Il Gruppo TenStep, su licenza del PMI, ha sviluppato un prodotto denominato ‘TenStep PB’, anche in lingua italiana. Si tratta dell’abbinamento dello schema di riferimento del PMI, contenuto nel PMBOK 2004, (la guida al Project Management Body of Knowledge), con le spiegazioni approfondite dei processi della metodologia TenStep.

PRINCE2: PRojects IN Controlled Environments.

È un metodo strutturato di project management per organizzare, gestire e controllare i progetti sulla base di un approccio generico e flessibile, basato sulla pratica. La genericità deriva dal fatto che sia stato formulato per essere utilizzabile come metodologia per la gestione di progetto applicabile indipendentemente dall’oggetto e dalle dimensioni del progetto.

Il metodo, che affronta tutte le discipline coinvolte nel project management, si concentra in particolare sugli aspetti relativi alla giustificazione del progetto e al collegamento dello stesso con le esigenze del business.

La best practice si caratterizza per essere orientata al risultato: un progetto per poter essere eseguito deve rappresentare, nella terminologia utilizzata in Prince2, un business case, cioè deve costantemente tendere ad un obiettivo preciso che possieda la capacità di creare valore per l’organizzazione o altrimenti va abbandonato. Il business case ,deve essere espresso in termini di rapporto costi/benefici misurabili, affinché possa essere costantemente controllato (ex ante, in itinere, ex post)

Un altro aspetto importate della metodologia è il fatto che il controllo in un progetto PRINCE2 è strutturato su due livelli composti da un Comitato di Progetto (Project Board), con la responsabilità di decidere, e il Project Manager a cui è attribuita la responsabilità di coordinare l’esecuzione del progetto e un potere decisionale da esercitarsi nei limiti delle tolleranze ammesse.

PRINCE2 è strutturato secondo tre entità principali:

Un set di 8 processi interconnessi fra di loro e svolti in modo controllato, che coprono la preparazione, l’esecuzione e la chiusura dei progetti ed illustrano in modo cadenzato le attività che devono essere eseguite.
Un set 8 componenti, cioè i moduli indispensabili per una corretta implementazione del progetto da parte dei processi, che esplicitano la filosofia di base che caratterizza il metodo e come possa essere utilizzata.
Un set di 3 tecniche che rappresentano delle combinazioni di operazioni tali da consentire lo svolgimento di un’azione ed il conseguimento del relativo risultato. Una sola di tali tecniche è imposta dalla prassi: la “tecnica di pianificazione basata sul prodotto”, a causa degli evidenti benefici che arreca. Per il resto il metodo demanda al project manager la responsabilità di quali tecniche effettivamente utilizzare.

4.applicabilità delle Best Practice analizzate

E’ interessante analizzare l’applicabilità delle best practice presentate nel capitolo precedente in funzione di alcune loro caratteristiche salienti. Ciò consente di evidenziare analogie o differenze, identificare eventuali punti di forza o di debolezza in funzione di vari scenari che possono essere identificati.

Tali considerazioni trasversali hanno il fine di orientare l’accesso alle informazioni relative ad ogni best practice, in funzione delle specifiche esigenze del lettore e non debbono essere intese come un confronto qualitativo tra le diverse best practice. In effetti un benchmark delle best practice non ha senso essendo essere per lo più complementari e finalizzate a diversi scopi.

Un aspetto che verrà indagato riguarda l’applicabilità delle Best Practice alle macroattività che caratterizzano genericamente ogni fornitura ICT. Si rende necessario quindi definire meglio tali macroattività, già introdotte nel Cap.1.

Le Linee guida trattano del il rapporto Cliente-Fornitore nel particolare caso in cui il Cliente, sia una Amministrazione Pubblica che abbia affidato in outsourcing, ad un Fornitore ICT esterno (outsourcer), lo sviluppo e l’esercizio del proprio sistema informativo automatizzato o di parti di esso.

Tale situazione comporta un rilevante impatto organizzativo per l’organizzazione Cliente, la quale, spogliata dalle attività operative, demandate al Fornitore, si trova comunque a dover esercitare un complesso di strategie, di logiche, di processi decisionali, operativi e comunicativi che possono complessivamente essere definiti Governance dell’ICT.

Lo scopo fondamentale della Governance dell’ICT è quello di creare un assetto strutturato del sistema informativo aziendale, che ne garantisca:

il costante funzionamento
il mantenimento di una qualità accettabile dei servizi
l’allineamento con le esigenze istituzionali
la rispondenza ai criteri di economicità propri della pubblica amministrazione.

La figura precedente illustrata schematicamente la logica del rapporto Cliente-Fornitore nelle condizioni precedentemente illustrate.

Il flusso, illustrato dalle frecce nello schema, individua quattro macroattività operative critiche (rappresentate dai box), che si succedono ciclicamente durante una fornitura ICT. Nello schema si riconoscono tre macrofasi (rispettivamente prima, durante e dopo il termine del rapporto contrattuale) durante le quali è chiaramente indicato a chi spetta l’onere della responsabilità esecutiva delle attività fra Amministrazione e Fornitore ICT.

Tuttavia, nel caso concreto, permangono macroattività di responsabilità del Cliente, indicate chiaramente nello schema, per le quali si potrebbe comunque ricorrere ad un fornitore esterno, ovviamente diverso ed in contraddittorio con l’outsourcer. Ciò capita nel caso, concretamente quanto mai realistico, nel quali le Amministrazioni debbano far fronte a carenze di expertise ovvero non siano in grado di gestire, con risorse interne, l’intenso picco di lavoro collegato a tali attività, le quali devono necessariamente concludersi in tempi brevi e definiti a priori.

La tabella che segue mostra un quadro sinottico dei risultati dell’analisi di applicabilità delle Best Practice relativamente alle macroattività indicate nello schema ed ad altri aspetti ritenuti salienti.

	CMMI-DEV	COBIT	ITIL	PMBOK	PRINCE2
Macroattività A=Trattazione approfondita C=Cenni
Analisi di fattibilità	A	A	C	C	A
Realizzazione dei progetti	A	A	C	A	A
Erogazione dei servizi ICT	A	A	A	C	C
Analisi di impatto	C	A	A	C	A
Ambito di applicazione: uso che ne può fare un’organizzazione	Sviluppo e Integrazione prodotti ICT	ICT Governance Controllo e gestione servizi ICT	Gestione dei servizi ICT	Gestione progettuale	Governo e gestione del progetto
Finalità: obiettivi per i quali è stata sviluppata la Best Practice	Miglioramento della qualità dei processi di gestione produzione ed integrazione prodotti sw, rispetto a 5 livelli di maturità	Definizione di un quadro dei processi ICT e relativi obiettivi di controllo. Definizione e miglioramento della governance ICT	Offrire indicazioni e supporto operativo per l’erogazione dei servizi ICT	Raccogliere ed organizzare tutto lo scibile riguardo la Gestione Progetti	Definizione di un metodo generale di project management
Destinatari principali: Individua gli stakehoder principali	Organizzazione che sviluppa software e fa system integration	Organizzazione che fornisce servizi ICT (gestione ,sviluppo, erogazione). Funzioni incaricate della definizione delle scelte strategiche ICT e funzioni incaricate di definire le organizzazioni IT e i relativi processi.	Organizzazione che eroghi servizi ICT	Organizzazione che gestisce un progetto. Project managers	Organizzazione che gestisce un progetto. Project managers
Destinatari cointeressati: altri stakeholder interni od esterni all’organizzazione	Cliente dei servizi forniti da un Fornitore ICT	Dirigenti funzione ICT con responsabilità di controllo (Security, & Privacy, Compliance, Assurance)	Cliente dei servizi forniti da un Fornitore ICT	Committente del progetto	Committente del progetto
Specificità: sono evidenziati i processi specificamente indirizzati dalla Best Practice
Pubblica amministrazione
Forniture ICT		X	X
Relazione cliente-fornitore	X	X	X	X	X
Punto di vista Cliente			X	X	X
Punto di vista Fornitore	X		X	X	X
Contesto d'uso in ambito PA: sono evidenziati i processi specificamente indirizzati dalla Best Practice
PA acquirente di forniture ICT	X	X	X	X	X
PA gestore di progetti	X	X	X	X	X
PA erogatrice di servizi		X	X
Livello di dettaglio
Strategie		X	X
Controllo dei processi	X	X	X	X	X
Esecuzione dei processi	X		X	X	X
Istruzioni operative			X
Certificazione: oggetto della certificazione
Persone	X	X	X	X	X
Organizzazioni ICT	X
Centri di formazione			X
Lingua utilizzata	ENG	ITA/ENG	ENG	ITA/ENG	ITA/ENG

Nei paragrafi seguenti commenteremo la precedente tabella cercando di confrontare da una parte le best practice applicabili in ambito ICT (CMMI-DEV, COBIT ed ITIL) dalle altre due, che vantano un’applicabilità del tutto generale alla gestione di progetti (PMBOK, PRINCE2).

STUDIO DI FATTIBILITÀ

Le attività necessarie alla realizzazione dello Studio di Fattibilità, documento necessario ad avviare una fornitura ICT, sono quelle maggiormente qualificanti la macrofase precontrattuale. La tematica è affrontata dalle Linee guida sotto vari profili: il Manuale 8, “Analisi di fattibilità per l’acquisizione delle forniture ICT”, è dedicato a questo argomento, individua gli obiettivi e le tematiche da trattare.

CMMI-DEV è l’unica best practice, fra quelle considerate, che indirizza specificamente le attività inerenti alla fattibilità tecnica. In particolare l’area di processo “Soluzione Tecnica” (TS), che ha proprio lo scopo di progettare, sviluppare e realizzare una soluzione tecnica che soddisfi i requisiti del prodotto da realizzare, trova larga applicabilità nel caso di sviluppo di sistemi applicativi.

L’analisi dei rischi è una pratica che viene abbozzata durante la fattibilità per poi trovare applicazione durante la realizzazione progettuale. Indicazioni approfondite si hanno quindi dalle raccolte che includono tale finalità, incluso COBIT.

Per quando riguarda l’analisi del rapporto costi benefici un contributo specifico, valido in modo particolare per l’ICT, può provenire da Prince2. Interessante a tale proposito è la fase preprogettuale di “Starting up” di PRINCE2, riconducibile ad attività che nel ciclo di vita dell’acquisizione delle forniture ICT sono proprie dello studio di fattibilità.

REALIZZAZIONE DEI PROGETTI

Generalmente ogni definizione di progetto, che possiamo incontrare nella letteratura specialistica, evidenzia le caratteristiche di complessità dell’impresa, unicità e durata determinata, le quali determinano la necessità di una continua pianificazione e del controllo di vincoli interdipendenti (costi-tempi-qualità).

Poiché per la realizzazione di un progetto capita sovente la necessità di dovere affrontare problemi nuovi, o posti in maniera innovativa, la gestione progettuale è diventata materia di studio, nel tentativo di fissare principi e best practice che possano essere utili in molteplici occasioni e circostanze. Ciò è particolarmente apprezzato in ambito ICT, nel quale non si dispone di tecniche ingegneristiche consolidate da lungo tempo, e quindi la corretta gestione progettuale emerge spesso come fattore critico di successo.

Per questo motivo, nel presente paragrafo, prenderemo in considerazione due raccolte di Best Practice destinate al capo progetto, particolarmente diffuse ed utilizzate nel mondo dell’ICT:

PMBOK è una guida per il project manager nel quale sono trattate tutte le “Aree di conoscenza” necessarie per una corretta gestione progettuale. Vengono fornite indicazione sulla corretta successione delle attività progettuali ma, programmaticamente, lascia al project manager l’onere di decidere sul loro concreto utilizzo.
L’approccio di PRINCE2 è diverso e maggiormente prescrittivo, in quanto esso si connota come metodologia applicabile all’organizzazione e alla conduzione dei progetti. A tal fine esso è corredato di esempi, elementi grafici e schemi di conoscenza, che potrebbero essere applicati in ogni fattispecie progettuale.

A parte queste differenze di impostazione si assiste ad un’ampia sovrapposizione fra gli argomenti trattati dalle due Best Practice e sono pochi quelli trattati in modo esclusivo da una sola.

PRINCE2 si differenzia per includere il punto di vista del committente attraverso le pratiche per la misura e costante verifica del business case, ovvero una componente del metodo che indirizza la valutazione ed il monitoraggio del rapporto costi benefici. Viceversa PMBOK dedica una maggiore attenzione all’organizzazione di progetto e alla gestione dei possibili stakeholder di cui è necessario soddisfare i requisiti.

Dal punto di vista del livello di dettaglio PMBOK risulta una metodologia maggiormente completa sui processi di project management, mentre PRINCE2 non risulta, per esempio, altrettanto accurato nell’individuare i fabbisogni di risorse umane da allocare sui vari processi e non prevedono nulla di analogo alla “Gestione dell’approvvigionamento del progetto”. D’altra parte solo XXXXXX tratta la fase preprogettuale di “Starting up”, riconducibile ad attività che nel ciclo di vita dell’acquisizione delle forniture ICT sono proprie dello studio di fattibilità.

PMBOK e PRINCE2 prevedono una certificazione della persona attraverso uno schema di certificazione analogo che, in entrambi i casi, attesta il livello di conoscenza sulla metodologia.

EROGAZIONE DEI SERVIZI ICT

In questo paragrafo di concentreremo sulle best practice dedicate alle organizzazioni ICT, non trattate nel paragrafo precedente. Complessivamente esse mostrano molti profili di complementarietà in diversi aspetti. Le difformità, che pure eistono, non impedirebbero quindi un’applicazione congiunta.

Se si considera l’ambito di applicazione ed i destinatari, appare evidente come la vocazione principale di ITIL sia la gestione dei servizi ICT, mentre CMMI-DEV affronta le problematiche legate allo sviluppo del software ed integrazione dei sistemi (attività che in questo contesto possono essere considerate alla stessa stregua di servizi).

Dal punto di vista del livello di dettaglio COBIT, coerentemente con le proprie finalità, mostra un profilo maggiormente strategico mentre al contrario CMMI-DEV ed ITIL mostrano caratteristiche maggiormente operative, in campi fra di loro ampiamente complementari.

I tre modelli quindi, complessivamente, forniscono supporto a tutto il ciclo di produzione ed erogazione di prodotti/servizi ICT

CMMI prevede il rilascio di certificazioni aziendali articolate su crescenti livelli di maturità. Il modello quindi individua concreti e misurabili obiettivi di miglioramento dei processi che dovrebbero essere in grado di garantire una sempre più elevata affidabilità e capacità di prevedere i risultati dei processi di produzione.

ITIL non prevede certificazioni aziendali in quanto, di fatto, questo compito è assolto dalla certificazione di conformità ISO/IEC 20000.

ITIL è rivolto alle organizzazioni che erogano Servizi ICT, indipendentemente dal settore di riferimento e dalla natura dei propri clienti (interni o sul mercato). Fra questi abbiamo: le funzioni che contribuiscono ad erogare i processi ICT, le società fornitrici che erogano servizi IT e numerosi attori fornitori di strumenti a supporto dell’esecuzione dei processi ICT.

COBIT è invece un modello che si propone di fornire strumenti di controllo dell’ICT, indipendentemente dalla finalità aziendale e dal contesto organizzativo. COBIT si rivolge principalmente ai Dirigenti implicati nella definizione delle scelte strategiche per fornire loro strumenti di governo, anche se nella pratica COBIT è compreso ed applicato soprattutto dal management della funzione ICT. Codestinatari sono i responsabili delle singole aree e gli auditor, interni e/o esterni, che utilizzano la metodologia per la loro attività nell’ambito della gestione dell’ICT.

Dal punto di vista strutturale COBIT e CMMI-DEV organizzano i processi secondo una logica che potremo definire “tradizionale”, omogenea in tutte le loro parti, che fornisce il medesimo supporto per tutti i processi trattati. ITIL invece si basa su un paradigma innovativo dell’organizzazione dei processi: un unico ciclo di vita di attività che partono dalla definizione strategica fino al controllo della esecuzione.

ANALISI DI IMPATTO

L’analisi di impatto l’attività che serve a valutare le ricadute di un progetto ICT dopo la sua conclusione. In ambito pubblico tale valutazione dovrà adottare criteri specifici in quanto non sono sempre applicabili quelli economicistici validi per l’impresa privata. Può infatti capitare che un’Amministrazione realizzi un progetto di successo, anche economicamente in perdita, purché come contropartita si realizzino adeguati benefici per i cittadini e le imprese.

La valutazione di tale benefici e la comparazione con i costi sostenuti dal progetto è un’attività tutt’altro che banale, per la quale si rimanda al caso di studio di applicazione della metodologia e-GEP, di cui al Manuale 8, “Analisi di fattibilità per l’acquisizione delle forniture ICT”.

Tale premessa tende ad escludere contributi organici da parte delle Best Practice analizzate, in quanto destinate ad organizzazioni private, le cui funzione ICT sono subordinate al business. Ciò tuttavia non esclude contributi specifici, in particolare:

COBIT indirizza le attività di gestione strategica degli investimenti ICT
ITIL la progettazione dei servizi
PRINCE2 la valutazione del Business case, che può continuare anche dopo la chiusura progettuale.

5.corrispondenza best practice - Linee guida

E’ utile mettere in relazione i contenuti delle Linee guida con gli argomenti sviluppati dalle varie Best Practice.

Acquisire una fornitura ICT non è un fatto puntuale che esaurisce i suoi effetti nel momento in cui è compiuto. Al contrario, l’inserimento di tecnologie ICT nelle attività di un’organizzazione comporta prima un’analisi e una ridefinizione basilare delle strategie e dispiega successivamente i suoi effetti in un arco temporale molto ampio, con benefici e ricadute rilevanti.

Per tale fondamentale motivo le attività proposte dalle Linee Guida CNIPA sono organizzate in un ciclo di vita per l’acquisizione delle forniture ICT, definito nel Manuale 1, “Presentazione ed Utilizzo delle Linee Guida”, che ha inizio dal momento in cui l’esigenza viene percepita dall’Amministrazione, contestualizzata all’interno di predefinite strategie e definita in un apposito progetto. Procede attraverso la selezione del fornitore, applicando la normativa prevista per gli appalti pubblici ed infine si conclude con l’acquisizione della fornitura ICT, secondo le modalità definite dal contratto stipulato con il fornitore selezionato e, successivamente nella valutazione dei risultati finali.

Nella tabella di cui alle pagine seguenti, i contenuti dei Manuali delle Linee guida (di tipo applicativo ed operativo) sono contestualizzati all’interno delle fasi del ciclo di vita un modo da poterne definirne implicitamente la propedeuticità.

La trattazione nelle best practice di questi stessi argomenti è così valutata:

Approfondito (A), se l’argomento corrispondente è trattato in modo più approfondito rispetto alle Linee guida;
Accennato (C), se l’argomento corrispondente è solo accennato.
Non trattato (N), se l’argomento corrispondente non è minimamente trattato.

FASI	ARGOMENTI	SUNTO ESSENZIALE	CMMI-DEV	COBIT	ITIL	PMBOK	PRINCE2
Definizione strategie di acquisizione	Strategie di acquisizione forniture ICT (Man.2 Cap.4)	Le decisioni riguardo le modalità di acquisizione producono effetti rilevanti sull’organizzazione e sul business e quindi devono essere prese con la consapevolezza della loro valenza strategica. Per tale motivo vengono date indicazioni su come valutare le diverse alternative strategiche possibili, le quali vanno dall’affidarsi completamente alle proprie risorse interne (insourcing) al delegare completamente all’esterno (full outsourcing)	C	A	A	C	C
	Strategie di acquisizione sw applicativo (Man.2 Cap.5)	Vengono analizzate le opzioni maggiormente ricorrenti nello sviluppo software: il riuso, lo sviluppo ad hoc opposto a quello basato su software personalizzabile e, in questo caso, l’ipotesi di soluzioni open source rispetto a quelle commerciali.	C	A	C	N	C
	Architetture contrattuali (Man.2Cap.6, Man.2 Cap.7)	Vengono illustrati pro e contro delle varie opzioni che possono essere utilizzate (contratti quadro, suddivisione in lotti, utilizzo del subappalto) nell’ambito delle varie tipologie contrattuali (forniture, servizi, misto).	C	C	C	C	N
	Contenuti Contrattuali (Man.2 Cap.8)	Vengono illustrati i tipici contenuti del corpo contrattuale: norme regolatrici, durata contrattuale, definizione dell’oggetto, condizioni della prestazione, controlli e verifiche, determinazione dei corrispettivi, forme di tutela.	C	C	C	C	C
Analisi di fattibilità	Fattibilità tecnica (Man.8 Cap.6, Man.8Cap.8)	Momento centrale dell’analisi di fattibilità è l’elaborazione del progetto di massima della soluzione che comporta la definizione dei Requisiti della soluzione proposta, le Specifiche generali del sistema, le Modalità di realizzazione e di attuazione.	A	C	C	C	C
	Analisi del rischio (Man8 Cap.7)	L’analisi del rischio è un processo trasversale che inizia durante la fattibilità per poi proseguire nell’elaborazione del capitolato e l’esecuzione progettuale.	A	A	C	A	A
	Gestione del cambiamento (Man.8 Cap.10)	Il capitolo illustra le azioni che si devono intraprendere per agevolare l’attuazione di processi di innovazione tecnologica gestendo le difficoltà di natura organizzativa che fatalmente insorgono. Anche in questo caso si tratta di un processo trasversale	A	A	C	C	A
Selezione del fornitore	Dimensionamento della fornitura (Man.2Cap.9, Man.2 Par.10.3, Man.3 Par. 3.5)	Sono illustrate le tecniche di valutazione delle dimensioni della fornitura di utilità per la determinazione della base d’asta negli appalti pubblici.	C	C	C	N	A
	Criteri di valutazione delle offerte (Man.3 Par.3.6, Man.3Par.3.10)	Le procedure di appalto prevedono che la negoziazione del contratto avvenga tramite la valutazione delle offerte attraverso criteri predeterminati. Le Linee guida danno indicazioni su come gestire tale problematica.	C	C	A	C	N
	Criteri di accesso alla gara (Man.3 Par.3.8)	Sono date indicazioni sui criteri, da usare durante le procedure selettive, per predeterminare le caratteristiche minime dei partecipanti.	C	C	C	N	A
Definizione del contratto	Definizione del capitolato tecnico (Man.4 Xxx.0, Xxx.0 Xxx.0, Xxx.0 Xxx.0, Man.5 Cap.5)	Per questa attività le Linee guida mettono a disposizione un set di 32 Classi di fornitura ICT elementare e 4 Processi Trasversali, la cui opportuna composizione produce dei semilavorati generalmente validi nei casi concretamente esperibili.	A	N	C	C	C
Governo del contratto	Governo dei contratti per la realizzazione di Progetti (Man.7 Cap.4)	Vengono fornite specifiche indicazioni sulla modalità di governo dei contratti che prevedono la realizzazione di progetti, riprendendo molteplici temi già trattati nella fattibilità, da un’ottica diversa.	A	A	A	A	A
	Governo dei contratti per l’erogazione dei Servizi (Man.7 Cap.5)	Vengono fornite specifiche indicazioni sulla modalità di governo dei contratti che prevedono l’erogazione di servizi ICT quali la garanzia della qualità, il monitoraggio dei livelli di servizio, ecc.	C	A	C	N	N
	Documenti per il governo dei contratti (Man.7 Cap.6)	Vengono forniti numerosi template dei documenti che potrebbero essere utilizzati per la conduzione contrattuale.	C	C	C	C	A
Verifica dei risultati	Analisi di impatto (Cap.9 Man.8)	Il rapporto costi - benefici dell’iniziativa è il parametro fondamentale per decidere l’avvio e la prosecuzione di ogni soluzione progettuale. Si tratta di un processo trasversale che prevede numerose tecniche di controllo per valutare tale parametro ex-ante, in itinere e ex post.	C	A	A	C	A

A commento di quanto riportato nelle precedenti tabelle, osserviamo che solo ITIL e COBIT sono in grado di dare un contributo alla definizione delle strategie, in quanto indirizzano i processi decisionali di alto livello. Occorre anche rilevare che le architetture e i contenuti contrattuali e la selezione del fornitore, a causa della natura eminentemente giuridica degli argomenti, non si prestano ad una trattazione nelle best practice.

Analogamente sono poco rilevanti i contenuti riguardanti i criteri della valutazione delle offerte. D’altra parte anche le indicazioni fornite delle Linee Guida si limitano ad aspetti eminentemente procedurali.

Nella fase di governo del contratto le indicazioni fornite dalle best practice sono viceversa piuttosto approfondite. Ancora una volta si evidenzia la specializzazione di CMMI-DEV, PMBOK, PRINCE2 per conduzione di progetti e di ITIL per l’erogazione di servizi.

La successiva tabella mette in relazione le Classi di Fornitura con le best practice. Si può considerare un dettaglio di quanto riportato precedentemente a proposito della Definizione del capitolato tecnico (punto 11 della tabella precedente).

Classi di fornitura		CMMI-DEV	COBIT	ITIL	PMBOK	PRINCE2
Codice 1.1.1 SSW	Sviluppo e MEV di software ad hoc	A		C
Codice 1.1.2PSW	Personalizzazione e MEV di prodotti esistenti	A		C
Codice 1.1.3 SSC	Sviluppo e MEV mediante soluzioni commerciali	A		C
Codice 1.2.1GSW	Gestione applicativi e Basi Dati	A		A
Codice 1.2.2 MAC	Manutenzione correttiva ed adeguativa (MAC)	A		A
Codice 1.2.3MSW	Migrazione e conversione applicazioni	A		C
Codice 1.3.1ASS	Assistenza in remoto e in locale			A
Codice 1.3.2FOR	Formazione e addestramento	C
Codice 2.1.1ISW	Integrazione di prodotti software e basi dati	C		C
Codice 2.1.2 ISI	Integrazione di sistemi e infrastrutture	C		C
Codice 2.2.1ASP	Servizi applicativi in modalità ASP			A
Codice 2.2.2PEL	Posta elettronica			C
Codice 2.2.3PEC	Posta elettronica certificata			C
Codice 2.2.4INT	Servizi Internet			C
Codice 2.2.5WEB	Gestione contenuti WEB			C
Codice 2.3.1CFD	Certificazione delle firma digitale			C
Codice 2.3.2CAS	Gestione di Carte per l'Accesso ai Servizi			C
Codice 3.1.1SRT	Sviluppo Reti			C
Codice 3.1.2GMR	Gestione e manutenzione reti			A
Codice 3.2.1SSI	Sviluppo sistemi	A		C
Codice 3.2.2GSI	Gestione sistemi			A
Codice 3.2.3MSI	Manutenzione sistemi			A
Codice 3.3.1SIL	Gestione della sicurezza logica			A
Codice 3.3.2SIF	Gestione della sicurezza fisica			A
Codice 3.3.3COP	Continuità operativa			A
Codice 3.4.1TDO	Trattamento documentale e acquisizione dati	C		C
Codice 3.4.2WFM	Gestione elettronica dei documenti	C		A
Codice 3.5.1CLS	Controllo dei livelli di servizio			A		A
Codice 3.6.1GPL	Gestione e manutenzione delle postazioni di lavoro	C		A
Codice 4.1.1CON	Consulenza				C	C
Codice 4.1.2DLA	Direzione lavori	C			A	A
Codice 4.1.3MCS	Misura della Customer Satisfaction	C		A	C	C
Codice 4.2.1IMD	Ingegneria e Mano d’opera
Codice 5.1.1FPD	Prodotti Hardware e Software
Codice 6.1.1PGD	Documentazione	C			A	A
Codice 6.1.2 PGC	Gestione della Configurazione	A		A	A	A
Codice 6.1.3 PAQ	Assicurazione della Qualità	A			A	A
Codice 6.2.1PGE	Gestione e Processi Organizzativi	A			A	A

Nei paragrafi seguenti, per ogni best practice saranno forniti, se esistono, i riferimenti bibliografici, relativamente alla documentazione ufficiale di riferimento.

Come già fatto precedentemente la trattazione nelle best practice dei diversi argomenti è così valutata:

Approfondito (A), se l’argomento corrispondente è trattato in modo più approfondito rispetto alle Linee guida;
Accennato (C), se l’argomento corrispondente è solo accennato.
Non trattato (N), se l’argomento corrispondente non è minimamente trattato.

Ad ogni argomento è associato, quando è possibile, uno o più riferimenti bibliografici alla documentazione delle best practice, come puntamenti a possibili ulteriori approfondimenti. Accanto ai riferimenti è riportato nuovamente il giudizio espresso nella tabella sinottica, seguito da un sunto essenziale che anticipa i contenuti referenziati.

Questo non vuole incoraggiare un accesso frammentario alla documentazione, si ritiene che le metodologie vadano fruite in modo globale ed integrato, l’intento è quello di fornire una mappatura di riferimento che faciliti approfondimenti ulteriori delle tematiche trattate dalle Linee guida.

CMMI-DEV

Come riferimento sono citate le Process Area che trattano l’argomento corrispondente.

Argomenti	Codice	Riferimenti	Sunto CMMI-DEV
Strategie di acquisizione forniture ICT (Man.2 Cap.4)	C	SAM TS	L’area di processo SAM, Supplier Agreement Management, descrive come gestire un rapporto di fornitura e come valutare differenti strategia di acquisizione. L’area di processo TS, Technical Solution, richiede l’investigazione di diverse soluzioni tecniche alternative, tra cui l’acquisizione
Strategie di acquisizione sw applicativo (Man.2 Cap.5)	C	SAM TS	L’area di processo SAM, Supplier Agreement Management, descrive come gestire un rapporto di fornitura e come valutare differenti strategia di acquisizione. L’area di processo TS, Technical Solution, richiede l’investigazione di diverse soluzioni tecniche alternative, tra cui l’acquisizione.
Architetture contrattuali (Man.2Cap.6, Man.2 Cap.7)	C	SAM	L’area di processo SAM, Supplier Agreement Management, ipotizza diverse tipologie di contratto da porre in essere tra cliente e fornitore.
Contenuti Contrattuali (Man.2 Cap.8)	C	SAM	L’area di processo SAM, Supplier Agreement Management, descrive i possibili contenuti di un contratto di fornitura
Fattibilità tecnica (Man.8 Cap.6, Man.8Cap.8)	A	TS DAR	La definizione e l’analisi della fattibilità tecnica rientrano nella ricerca e valutazione della soluzione oggetto dell’area di processo TS. L’area di processo DAR, Decision Analysis and Resolution propone l’utilizzo di tecniche strutturate per la valutazione di alternative.
Analisi del rischio (Man8 Cap.7)	A	RSKM PP	L’area di processo RSKM descrive le esigenze di una corretta gestione dei rischi, mentre l’area di processo PP, Project Planning, ne descrive l’utilizzo nel contesto della pianificazione di progetti
Gestione del cambiamento (Man.8 Cap.10)	A	OPF OPD OT OPP OID	Tutte le aree di processo relative alla Gestione di Processo indirizzano le tecniche per la gestione del cambiamento. In particolare, OPF, Organization Process Focus, introduce i concetti relativi ad una organizzazione per processi, mentre OID, Organization Innovation and Deployment, descrive il cambiamento basato su un’analisi quantitativa dei processi
Dimensionamento della fornitura (Man.2Cap.9, Man.2 Par.10.3, Man.3 Par. 3.5)	C	SAM PP	L’area di processo PP, Project Planning, richiede di stimare diverse caratteristiche importanti di un progetto, in termini di dimensioni (linee di codice, function point, ecc.), risorse e costi necessari al raggiungimento dell’obiettivo. L’area di progetto SAM richiede l’utilizzo delle stime nella valutazione e quantificazione della fornitura.
Criteri di accesso alla gara (Man.3 Par.3.8)	C	SAM	L’area di processo SAM descrive la necessità di individuare dei criteri oggettivi per l’assegnazione di attività in appalto.
Criteri di valutazione delle offerte (Man.3 Par.3.6, Man.3Par.3.10)	NC	SAM	L’area di processo XXX descrive la necessità di individuare dei criteri oggettivi per la selezione fra le proposte di appalto.
Definizione del capitolato tecnico (Man.4 Xxx.0, Xxx.0 Xxx.0, Xxx.0 Xxx.0, Man.5 Cap.5)	A	REQM RD PI VAL VER CM PPQA MA PMC IPM RSKM	Diverse aree di processo indirizzano la definizione del capitolato tecnico e, in particolare, tutti gli aspetti relativi ai requisiti del prodotto/servizio da realizzarsi (REQM, RD), alla sua integrazione in ambiente operativo (PI), alla verifica della corrispondenza ai requisiti (VER), alla validazione della possibilità di operare correttamente nell’ambiente a cui è destinato (VAL), alla gestione delle configurazioni (CM), all’attività di controllo qualità (PPQA) e al controllo dell’esecuzione del progetto (MA, PMC, IPM, RSKM)
Governo dei contratti per la realizzazione di Progetti (Man.7 Cap.4)	NA	PP PMC IPM RSKM	Le aree di processo relative alla gestione di progetto descrivono esigenze e tecniche per il governo dei progetti.
Governo dei contratti per l’erogazione dei Servizi (Man.7 Cap.5)	C	PP PMC IPM RSKM	Le aree di processo relative alla gestione di progetto descrivono esigenze e tecniche per il governo dei progetti.
Documenti per il governo dei contratti (Man.7 Cap.6)	C	SAM CM	L’area di processo XXX descrive i documenti essenziali per il governo dei progetti in appalto. CM (Configuration Management) fornisce le indicazioni per la gestione della configurazione di documenti e altri elementi critici dei progetti.
Analisi di impatto (Cap.9 Man.8)	C	OPP	La caratterizzazione statistica e quantitativa dei processi, introdotta dall’area di processo OPP, Organizational Process Performance, consente di sviluppare dei modelli predittivi delle prestazioni dei processi, che facilitano l’analisi di impatto

COBIT

Le sigle riportate nella colonna riferimenti identificano il collegamento al dominio, processo, o obiettivo di controllo COBIT.

Argomenti	Codice	Riferimenti	Sunto COBIT
Strategie di acquisizione forniture ICT (Man.2 Cap.4)	A	PO1 PO3 AI3	La fase di definizione delle strategie di acquisizione delle forniture ICT è collegabile ai processi COBIT: - PO1 - Definire un Piano Strategico per l'IT - PO3 - Definire gli indirizzi tecnologici - AI3 - Acquisire e mantenere l’infrastruttura tecnologica
Strategie di acquisizione sw applicativo (Man.2 Cap.5)	A	AI1 AI2	I processi COBIT AI1 e AI2 trattano rispettivamente la Identificazione delle soluzioni automatizzate e l’Acquisizione e mantenimento del software applicativo
Architetture contrattuali (Man.2Cap.6, Man.2 Cap.7)	C	AI5	Il processo AI5 fornisce dei cenni sulle modalità di approccio e gestione degli approvvigionamento delle risorse IT
Contenuti Contrattuali (Man.2 Cap.8)	C	AI5 DS2	Il processo AI5 fornisce dei cenni sulle modalità di approccio e gestione degli approvvigionamento delle risorse IT Il processo DS2 dà indicazioni sulle modalità di gestione e monitoraggio della relazione con terze parti e sulla modalità di gestione dei rischi connessi al fornitore.
Fattibilità tecnica (Man.8 Xxx.0, Xxx.0Xxx.0)	X	XX0 XX0 XX0 AI3	I processi PO2 (Definire l’architettura delle informazioni) e PO3 (Gestire gli indirizzi tecnologici) forniscono indicazioni sui criteri da tenere in considerazione per valutare la fattibilità tecnica di un progetto. I processi relativi al dominio Acquisizione e Implementazione (AI) trattano i requisiti relativi allo studio di fattibilità tecnica antecedente l’acquisizione di risorse tecnologiche e applicative.
Analisi del rischio (Man8 Cap.7)	A	PO9 PO10.9 AI1.2 DS2.3	Il processo COBIT PO9 tratta le modalità di analisi, gestione e monitoraggio dei rischi di natura IT Nell’ambito della gestione dei progetti vengono fatti dei cenni sulle modalità con le quali è opportuno far fronte ai rischi di progetto (Project Risk Management). Ulteriori cenni alla gestione dei rischi sono rintracciabili negli obiettivi di controllo AI1.2 (analisi dei rischi in fase di studio di fattibilità) e DS2.3 (gestione dei rischi relativi ai fornitori).
Gestione del cambiamento (Man.8 Cap.10)	A	PO4 PO10 AI6 AI4.2	La gestione del cambiamento dal punto di vista organizzativo viene considerata nell’ambito dei processi: - PO4 – Definire l’organizzazione ICT, in modo che sia in grado di supportare e comunicare adeguatamente con le altre funzioni dell’organizzazione - PO10 – Gestire i programmi e i progetti IT La gestione del cambiamento dal punto di vista tecnico trova in COBIT specifica trattazione nell’ambito del processo AI6 (Gestire le modifiche) IL processo AI4.2 fornisce delle indicazioni relative alla modalità di trasferimento delle conoscenze dall’IT agli utenti
Dimensionamento della fornitura (Man.2Cap.9, Man.2 Par.10.3, Man.3 Par. 3.5)	X	XX00.0 XX0.0 XX0.0	Xxx nel processo di gestione progetti (PO10) che nel processo di gestione degli investimenti IT (PO5) sono sottolineati aspetti connessi al corretto dimensionamento (budgeting) della fornitura.
Criteri di accesso alla gara (Man.3 Par.3.8)	C	AI5.3	Nel processo acquisizione delle risorse IT viene indirizzata la necessità di definire criteri di selezione relativi ai fornitori IT (obiettivo di controllo AI5.3).
Criteri di valutazione delle offerte (Man.3 Par.3.6, Man.3Par.3.10)	C	PO5.5 PO8.3	Gli obiettivi di controllo riportati si riferiscono alla valutazione dei benefici e alla definizione di standard di acquisizione e sviluppo
Definizione del capitolato tecnico (Man.4 Xxx.0, Xxx.0 Xxx.0, Xxx.0 Xxx.0, Man.5 Cap.5)	N
Governo dei contratti per la realizzazione di Progetti (Man.7 Cap.4)	A	PO8 DS1 DS2 AI (1-7)	I processi indicati si riferiscono alla gestione della qualità, alla definizione e gestione dei livelli di servizio e alla gestione dei servizi di terze parti. Tutto il dominio AI (Acquisizione e Implementazione) è applicabile ai progetti di implementazione.
Governo dei contratti per l’erogazione dei Servizi (Man.7 Cap.5)	A	PO8 DS(1-13) ME1	Tutto il dominio DS (Delivery and Support) fa riferimento alla erogazione dei servizi.
Documenti per il governo dei contratti (Man.7 Cap.6)	C	PO8 AI5 DS1 DS2	COBIT prevede uno specifico processo (AI5) con riferimenti diretti alla gestione dei contratti
Analisi di impatto (Cap.9 Man.8)	A	PO5 AI1.3	L’aspetto di impatto economico finanziario e di costi-benefici di un progetto viene trattato nell’ambito dei processi: - PO5 – Gestire degli investimenti IT - AI1 - Identificare le soluzioni automatizzate (per ciò che attiene l’analisi preliminare costi benefici).

ITIL

Le sigle riportate nei riferimenti sono le iniziali che individuano i libri di cui si compone il framework ITIL (Service Strategy; Service Design; Service Transition; Service Operation; Continual Service Improvement.).

Argomenti	Codice	Riferimenti	Sunto ITIL
Strategie di acquisizione forniture ICT (Man.2 Cap.4)	A	SS-6.5	Il paragrafo illustra le possibili strategie di sourcing nell’ambito del più ampio panorama delle strategie di organizzazione dell’ICT (SS-6).
Strategie di acquisizione sw applicativo (Man.2 Cap.5)		SD-3.11	Il paragrafo illustra i possibili modelli per erogare il servizio (insourcing, outsourcing, co-sourcing, partnership o multi-sourcing, business process outsourcing, application service provision, knowledge process outsourcing )ed i relativi vantaggi e svantaggi.
Architetture contrattuali (Man.2Cap.6, Man.2 Cap.7)	C	SD-3.11.3	Il paragrafo presenta i possibili approcci per lo sviluppo delle soluzioni (RAD, Waterfall, pacchetti, ecc..), evidenziando vantaggi e svantaggi.
Contenuti Contrattuali (Man.2 Cap.8)		SO-6.5.3	Nell’ambito della trattazione della tematica dell’Application Management (SO 6.5), il paragrafo affronta il tema del make or buy.
Fattibilità tecnica (Man.8 Cap.6, Man.8Cap.8)	C	SD-4.2.5.1	Nell’ambito della trattazione della tematica del Service Level Management (4.2), il paragrafo affronta l’architettura degli accordi contrattuali che la Best Practice chiama SLA. In particolare, illustra alcuni approcci per l’organizzazione di tali accordi e le dipendenze tra di essi.
Analisi del rischio (Man8 Cap.7)	C	SD-4.2	Nell’ambito della trattazione della tematica del Service Level Management (4.2), il paragrafo affronta i contenuti degli accordi contrattuali (SLA).
Gestione del cambiamento (Man.8 Cap.10)		SD-Appendix F	Un esempio di accordo.
Dimensionamento della fornitura (Man.2Cap.9, Man.2 Par.10.3, Man.3 Par. 3.5)		SD-5	Il capitolo esamina le tipologie di requisiti, le tecniche per definirli, i contenuti.
Criteri di accesso alla gara (Man.3 Par.3.8)	C	SD-4.5.5	Il paragrafo presenta tecniche di analisi dei rischi in relazione al tema della Service Continuity.
Criteri di valutazione delle offerte (Man.3 Par.3.6, Man.3Par.3.10)	A	ST, in particolare ST-3.2, ST4, ST5	L’intero libro Service Transition ha per obiettivo quello di offrire best practice per assicurare un passaggio ottimale di un servizio dalla fase di progettazione a quella di erogazione.
Definizione del capitolato tecnico (Man.4 Xxx.0, Xxx.0 Xxx.0, Xxx.0 Xxx.0, Man.5 Cap.5)		SD-Appendix A	L’appendice definisce i contenuti di un Service Design Package che definisce i contenuti di un servizio da realizzare.
Governo dei contratti per la realizzazione di Progetti (Man.7 Cap.4)	A	SS-5.1.3.4	Overview della Business Impact Analysis, una tecnica per l’analisi di impatto.
Governo dei contratti per l’erogazione dei Servizi (Man.7 Cap.5)		SS-5.2	Il paragrafo affronta l’analisi degli investimenti.
Documenti per il governo dei contratti (Man.7 Cap.6)	C	SD3	Overview delle attività di progettazione dei servizi. Informazioni su come identificare e documentare i business requirements.
Analisi di impatto (Cap.9 Man.8)	A	SD-3	Overview delle attività di progettazione dei servizi. Informazioni su come identificare e documentare i business requirements.

PMBOK

Argomenti	Codice	Riferimenti	Sunto PMBOK
Strategie di acquisizione forniture ICT (Man.2 Cap.4)	C	Cap 12 Gestione degli Approvvigionamenti	Il PMBOK tratta tali strategie in un ambito piu’ generale che va oltre l’ICT. L’Area di Conoscenza di Gestione dell’Approvvigionamento affronta tale aspetto sia nel Processo di Pianificazione degli Acquisti, che analizza e determina, per gli elementi da acquisire, se, quando e con quale modalità acquisirli, sia nel Processo di Pianificazione delle Forniture, che documenta i requisiti di prodotti, servizi e risultati oggetto di approvvigionamento e individua i potenziali fornitori.. In particolare, nel PMBOK, le scelte di Outsourcing/Insourcing fannno parte dell’Analisi e Decisione “Make or Buy”; sono inoltre trattate altre tecniche quali i “Moduli Standard”, il “Parere degli Esperti”, il “Tipo di Contratto”. I risultati dei due processi citati sono il capitolato contrattuale, i criteri di valutazione, il piano e i documenti di approvvigionamento.
Strategie di acquisizione sw applicativo (Man.2 Cap.5)	N
Architetture contrattuali (Man.2Cap.6, Man.2 Cap.7)	C	Cap 12 Gestione degli Approvvigionamenti	Il PMBOK tratta le architetture contrattuali nel paragrafo sugli “strumenti e tecniche” nel processo di Pianificazione degli Acquisti dell’Area di Conoscenza sulla Gestione degli Approvvigionamenti, sotto la voce “Tipi di Contratto”, strutturandone l’esposizione sulla base di diversi criteri quali il grado di rischio cui sono soggetti l’acquirente e il fornitore, i requisiti imposti dall’acquirente al fornitore, il grado di concorrenza del mercato. Le categorie più generali sono: Contratto a Prezzo Prefissato o a Importo Forfetario, Contratto con Rimborso Spese, Contratto Time & Material.
Contenuti Contrattuali (Man.2 Cap.8)	C	Cap 12 Gestione degli Approvvigionamenti	Il PMBOK affronta i contenuti contrattuali citati nelle Linee Guda nei paragrafi sugli “output”, ovvero dei risultati, ottenuti dai processi di Pianificazione degli Acquisti e di Pianificazione delle Forniture, afferenti all’Area di Conoscenza sulla Gestione degli Approvvigionamenti, sotto la voce “Piano di gestione dell’approvvigionamento”, “Capitolato Contrattuale”, “Documenti di Approvvigionamento”, “Criteri di Valutazione”.
Fattibilità tecnica (Man.8 Cap.6, Man.8Cap.8)	C	Cap 2.1 Ciclo di vita del progetto Cap 5 Gestione dell’Ambito Cap 6 Gestione dei Tempi	Nel PMBOK la fattibilità è considerata con diverse accezioni; la più comune interessa il Ciclo di vita del Progetto laddove sia necessario effettuare uno studio di fattibilità per decidere se intraprendere o meno il progetto. Inoltre, alcuni argomenti trattati dalle Linee Guida sono ripresi nelle aree di conoscenza : della gestione dell’ambito di progetto, volta ad assicurare la completezza del progetto; della gestione dei tempi di progetto;
Analisi del rischio (Man8 Cap.7)	A	Cap 11 Gestione dei Rischi	L'area di conoscenza della gestione dei rischi di progetto riguarda la conduzione dei processi legati alla pianificazione della gestione dei rischi, alla loro identificazione e analisi, alla preparazione delle risposte ai rischi e al loro monitoraggio e controllo nel corso del progetto
Gestione del cambiamento (Man.8 Cap.10)	C	Tutte le Aree di Conoscenza – dal cap 4 al cap 12	Il tema traspare in tutte le aree di conoscenza, tuttavia viene approfondito nel processo di gestione degli stakeholder, ovvero dei portatori di interesse per i risultati del progetto stesso, nell’ambito della Area della Conoscenza sulla Gestione della Comunicazione al cap. 10 del PMBOK.
Dimensionamento della fornitura (Man.2Cap.9, Man.2 Par.10.3, Man.3 Par. 3.5)	N
Criteri di accesso alla gara (Man.3 Par.3.8)	N
Criteri di valutazione delle offerte (Man.3 Par.3.6, Man.3Par.3.10)	C	Cap 12 Gestione degli Approvvigionamenti	Il PMBOK affronta i criteri di valutazione citati nelle Linee Guida nei paragrafi sugli “output”, ovvero dei risultati, ottenuti dai processi di Pianificazione delle Forniture, afferenti all’Area di Conoscenza sulla Gestione degli Approvvigionamenti, sotto la voce “Criteri di Valutazione”.
Definizione del capitolato tecnico (Man.4 Xxx.0, Xxx.0 Xxx.0, Xxx.0 Xxx.0, Man.5 Cap.5)	C	Tutte le aree di Conoscenza – dal cap 4 al cap 12	PMBOK può servire per indirizzare le classi di fornitura sugli aspetti progettuali, nonché per identificare le migliori pratiche di definizione di un capitolato tecnico, senza tuttavia specificare ulteriori aree ICT, al di fuori di quella sopra citata.
Governo dei contratti per la realizzazione di Progetti (Man.7 Cap.4)	A	Tutte le aree di Conoscenza – dal cap 4 al cap 12	Tutto il PMBOK è attinente a questo argomento. Nel dettaglio, il Processo di Amministrazione del Contratto, nell’ambito della Gestione dell’Approvvigionamento, stabilisce input, strumenti e tecniche oltre che risultati
Governo dei contratti per l’erogazione dei Servizi (Man.7 Cap.5)	N
Documenti per il governo dei contratti (Man.7 Cap.6)	C	Tutte le aree di Conoscenza – dal cap 4 al cap 12	Il PMBOK fa degli accenni a tali documenti definendone la casistica, senza fornire template predefiniti. Secondo il PMBOK, i documenti per il governo dei contratti comprendono il contratto e tutte le schedulazioni di supporto, le richieste di modifica al contratto, qualsiasi documentazione tecnica elaborata dal fornitore e altre informazioni sullo stato di avanzamento del lavoro, come i deliverable, i report sulle prestazioni del fornitore, le garanzie, i documenti finanziari, quali le fatture e i registri dei pagamenti, i risultati delle ispezioni relative al contratto.
Analisi di impatto (Cap.9 Man.8)	C	Cap 11 Gestione dei Rischi	L'area di conoscenza che affronta tale tema è quella relativa alla gestione dei rischi. L’analisi di impatto è uno dei risultati del processo di Pianificazione della Gestione dei Rischi di Progetto. In particolare, essa prevede che ai rischi vengano assegnate delle priorità in base alle loro potenziali implicazioni sul raggiungimento degli obiettivi del progetto. L’approccio più comune per l’assegnazione delle priorità ai rischi è dato dall’utilizzo di una una matrice di probabilità e impatto che stabilisce la misura del livello di rischio sulla base della probabilità dell’evento e del relativo impatto.

PRINCE2

Argomenti	Codice	Riferimenti	Sunto essenziale
Strategie di acquisizione forniture ICT (Man.2 Cap.4)	C	Cap. 13	Descrive la componente Business Case che guida alla redazione del Business Case che guida il progetto nel suo complesso e indirizza nella scelta della tipologia di scelta fra make or buy.
Strategie di acquisizione sw applicativo (Man.2 Cap.5)	C	Cap. 4	Descrive le modalità con cui prendere le decisioni relativamente allo sviluppo o acquisizione esterna.
Architetture contrattuali (Man.2Cap.6, Man.2 Cap.7)	N	-	-
Contenuti Contrattuali (Man.2 Cap.8)	C	Cap. 13, Cap. 4, Appendice A e altre	Viene data particolare importanza a tre aspetti dei prodotti che devono essere consegnati: qualità, costo e tempi. Questi tre parametri vengono formalizzati nel documento “Product Description” (Appendix A.22) che indica tutti gli aspetti che deve avere il prodotto che verrà prodotto per poter essere accettato, tali elementi sono una componente del contratto.
Fattibilità tecnica (Man.8 Cap.6, Man.8 Cap.8)	C	Cap. 13, e altre	PRINCE2 guida alla gestione del progetto di fattibilità tecnica pertanto da un contributo “metodologico”, inoltre PRINCE2 definisce il Business Case che definisce gli obiettivi del progetto, all’interno del manuale vengono illustrati i contenuti per lo sviluppo di un corretto e completo Business Case, inoltre vengono definiti i prodotti che il progetto deve andare a produrre definendone le caratteristiche, le modalità di accettazione e i criteri di qualità.
Analisi del rischio (Man8 Cap.7)	A	Cap. 17	Descrive la componente per la gestione dei rischi del progetto. Definisce tutti i sottoprocessi di PRINCE2 che gestiscono i rischi di progetto. Descrive le tolleranze ai rischi, le responsabilità, l’ownership, inoltre descrive il ciclo di gestione dei rischi.
		Cap. 4, 5, 6, 7, 8, 9, 10, 11	Descrivono le attività che vengono svolte all’interno dei sottoprocessi, dei diversi processi definiti in PRINCE2, che sono coinvolti nel ciclo di gestione dei rischi del progetto.
		Appendix C	Descrive le diverse categorie dei rischi che possono presentarsi nel corso della gestione dei rischi di progetto.
		Appendix A.34	Definisce come dovrebbe essere costituito il risk log (registro dei rischi) del progetto nel quale vengono registrati tutti i rischi individuati all’interno del progetto nel corso delle diverse fasi del progetto.
Gestione del cambiamento (Man.8 Cap.10)	A	Cap. 4, 5, 6, 7, 8, 9, 10, 11	PRINCE2 da un contributo di tipo metodologico nella gestione del cambiamento permettendo di affrontare e valutare correttamente e gestire tutte le parti.
		Cap. 20	Descrive la componente per la gestione dei cambiamenti nel progetto.
		Cap. 23	Descrive la tecnica di Change Control consigliata da PRINCE2 per la gestione delle Request for Change nel progetto.
		Cap. 6, 7, 9	Sono descritti i sottoprocessi di PRINCE2 coinvolti all’interno del metodo PRINCE2.
		Appendix A2	Vengono fornite le informazioni di dettaglio su come dovrebbe essere redatto un Business Case per il governo del progetto.
Dimensionamento della fornitura (Man.2Cap.9, Man.2 Par.10.3, Man.3 Par. 3.5)	A	Cap. 4, 5, 6, 7, 8, 9, 10, 11	PRINCE2 da un contributo di tipo metodologico nel dimensionamento della fornitura, inoltre affronta il dimensionamento del costo del progetto. Vengono descritti tre aspetti dei prodotti che devono essere consegnati: qualità, costo e tempi. Questi tre parametri vengono formalizzati nel documento “Product Description” (Appendix A.22) che indica la descrizione del prodotto che deve essere consegnato e tutti gli aspetti che deve avere il prodotto stesso per poter essere accettato, tali elementi sono una componente del contratto.
Criteri di accesso alla gara (Man.3 Par.3.8)	A	Tutte le parti	PRINCE2 illustra best practice per la progettazione e gestione dei progetti sia ICT che non. Molti aspetti delle best practice possono essere utilizzati per esprimere requisiti per l’accesso alla gara. In particolare risultano utilizzate richieste di qualifiche professionale delle risorse offerte. Più in generale molti elementi del framework possono essere trasformati in requisiti: ad esempio la suddivisione in fasi del progetto, gestione delle tolleranze delle fasi, ecc.. PRINCE2, comunque, non fornisce indicazioni specifiche da prevedere nelle gare.
Criteri di accesso alla gara (Man.3 Par.3.8)	A	Pubblicazione PRINCE2 Maturity Model	Il livello di maturità delle organizzazioni nella gestione del progetti (P2MM) potrebbe essere utilizzato come modello di valutazione dell’accesso alla gara. Le indicazioni possono essere anche utilizzate come guida alla valutazione di come un’organizzazione gestisce realmente i progetti per i propri Clienti.
Criteri di valutazione delle offerte (Man.3 Par.3.6, Man.3Par.3.10)	N
Definizione del capitolato tecnico (Man.4 Xxx.0, Xxx.0 Xxx.0, Xxx.0 Xxx.0, Man.5 Cap.5)	C	Cap. 4, 5, 6, 7, 8, 9, 10, 11	PRINCE2 da un contributo sia metodologico nella gestione del progetto di definizione del capitolato di gara che contributi specifici per quegli aspetti relativi alla gestione dei progetti all’interno del capitolato tecnico.
Definizione del capitolato tecnico (Man.4 Xxx.0, Xxx.0 Xxx.0, Xxx.0 Xxx.0, Man.5 Cap.5)	C	Cap. 4, 5, 6, 7, 8, 9, 10, 11	PRINCE2 da un contributo sia metodologico nella gestione del progetto di definizione del capitolato di gara che contributi specifici per quegli aspetti relativi alla gestione dei progetti all’interno del capitolato tecnico.
Governo dei contratti per la realizzazione di Progetti (Man.7 Cap.4)	A	Cap. 6	Il metodo PRINCE2 è un metodo per la gestione dei progetti, inoltre il processo Directing a Project è un processo per il governo dei progetti da parte del committente.
		Cap. 13	Viene descritto che cos’è un business case, che cosa dovrebbe contenere il Business case che guida il progetto, informazioni su come sviluppare il business case.
		Appendix A2	Vengono fornite le informazioni di dettaglio su come dovrebbe essere redatto un Business Case per il governo del progetto.
Governo dei contratti per l’erogazione dei Servizi (Man.7 Cap.5)	N
Documenti per il governo dei contratti (Man.7 Cap.6)	A	Varie parti	Vengono descritti tre aspetti dei prodotti che devono essere consegnati: qualità, costo e tempi. Questi tre parametri vengono formalizzati nel documento “Product Description” (Appendix A) che indica la descrizione del prodotto che deve essere consegnato e tutti gli aspetti che deve avere il prodotto stesso per poter essere accettato (criteri di accettazione utilizzati nella fase di test e collaudo), tali elementi sono una componente del contratto. In particolare l’Appendix A30 descrive il Project plan, l’Appendix A31 il Project Quality plan.
Analisi di impatto (Cap.9 Man.8)	A	Cap. 13, Appendix C	Il Business Case permette di analizzare tutti gli aspetti del progetto e lo guida dall’inizio alla fine. All’interno del Business Case si analizza formalmente l’impatto di tutti i diversi aspetti. In particolate viene descritto che cos’è un business case, che cosa dovrebbe contenere il Business case che guida il progetto, informazioni su come sviluppare il business case.

6.Standard iso analizzati

L’Organizzazione internazionale per la standardizzazione, ISO (International Organization for Standardization), è la più importante organizzazione a livello mondiale per la definizione di norme tecniche e lo sviluppo di Standard, che comprende gli organismi nazionali di standardizzazione di 157 paesi del mondo. Missione dell’ISO è la produzione di Standard che vengono codificati attraverso l’emissione di norme, cioè di documenti tecnici di applicazione volontaria.

Gli Standard considerati nella presente sezione stabiliscono i requisiti per la definizione e la valutazione di altrettanti sistemi gestionali relativi alle organizzazioni aziendali.

La norma UNI EN ISO 9001, recepita, armonizzata e diffusa in Italia dall'UNI (Ente Nazionale Italiano di Unificazione), si differenzia per l’applicabilità ampia e generale, non limitata all’ambito ICT. Il particolare interesse in ambito pubblico è dovuto al fatto di costituire un modello di riferimento per la qualificazione e selezione dei fornitori negli appalti e per la gestione dei relativi contratti

Le altre due norme qui considerate, sono state sviluppate congiuntamente con la Commissione Elettrotecnica Internazionale (IEC, International Electrotechnical Commission) e sono di particolare interesse e rilevanza per il mondo ICT, anche se la loro applicazione può non riguardare unicamente le organizzazioni informatiche.

Occorre infine sottolineare che questi Standard appartengono ognuno a tre più ampi insiemi normativi (famiglie di norme), e sono integrati da ulteriori norme accessorie e linee guida per l’applicazione.

Pur rimanendo sullo sfondo nella presente trattazione, costituiscono un ordito indispensabile per la loro completa definizione. In questo Manuale, per la rilevanza in ambito, ICT, verrà approfondita solo la UNI ISO 10006:2005, sulla quale ci soffermeremo nel seguito.

UNI EN ISO 9001:2000 Sistemi di gestione per la qualità

La famiglia ISO 9000 identifica una serie di norme e linee guida che propongono l’applicazione di un sistema di gestione per la qualità basato sul modello “Plan-Do-Check-Act” (PDCA) e pensato per monitorare i processi aziendali affinché siano indirizzati al miglioramento dell’efficacia e dell'efficienza della organizzazione, oltre che alla soddisfazione del cliente.

In particolare UNI EN ISO 9001:2000 (nome completo della norma recepita in Italia) definisce i requisiti minimi che deve avere un Sistema di Gestione per la Qualità (SGQ) affinché un’organizzazione possa garantire al cliente quanto concordato, ed è focalizzata sull’obiettivo dell’efficacia. Il contenuto della norma è generalizzato per favorirne l’applicabilità a qualsiasi organizzazione e quindi, da questo punto di vista, si discosta dagli altri framework destinati alle organizzazioni che operano in un contesto più specifico per le problematiche ICT.

Per aiutare le organizzazioni appartenenti al settore ICT e che si occupano di software, ad applicare, interpretandoli correttamente, i requisiti della UNI EN ISO 9001:2000, la ISO ha pubblicato la norma guida ISO/IEC 90003 (disponibile in Italia come UNI EN ISO/IEC 90003:2005 Guida per l’applicazione della ISO 9001:2000 al software per elaboratore).

Destinatarie dello standard, che presenta una forte specificità nella relazione cliente-fornitore, risultano sia Fornitori che intendono attuare un SGQ, sia acquirenti che intendono assicurarsi a proposito dei prodotti loro forniti, sia terze parti preposte alla valutazione di un SGQ di un’organizzazione appaltatrice.

La norma, fornendo i requisiti del sistema di gestione per la qualità, è, nell’ambito della famiglia ISO 9000, la norma di riferimento per i rapporti contrattuali e le certificazioni.

Per quanto riguarda le soglie di accesso agli appalti pubblici, la normativa prevede esplicitamente che la certificazione da richiedere, ovvero i documenti alla stessa equiparabili, sia basata sulla norma in parola. Rilevante in tale contesto è la Deliberazione AIPA 49/2000, inerente le “Regole tecniche e criteri operativi per l’utilizzo della certificazione EN ISO 9000 nell’appalto di contratti relativi a progettazione, realizzazione, manutenzione, gestione e conduzione operativa dei sistemi informativi automatizzati”. Per approfondire tale tematica si può fare riferimento a quanto riportato nel Manuale 3 “Appalto Pubblico di forniture ICT” delle Linee guida.

La norma prevede la Certificazione del sistema di gestione per la qualità, che attesta la conformità ai requisiti della struttura organizzativa, delle responsabilità, delle procedure, dei procedimenti e delle risorse messe in atto per la conduzione aziendale per la qualità. Le certificazioni sono emesse da un organismo di certificazione accreditato.

UNI ISO 10006:2005 Linee guida per la gestione per la qualità nei progetti

L’ISO attua la sua opera di standardizzazione tramite l’emissione di norme cogenti (il cui rispetto è considerato obbligatorio per la corretta certificazione delle attività coinvolte) o di linee guida per la facilitazione e la diffusione della cultura e delle buone pratiche promosse dall’organizzazione. Il modello UNI ISO 10006:2005, dal titolo, “Linee guida per la gestione della qualità nei progetti”, ricade evidentemente nella seconda tipologia ed ha l’obiettivo di fornire un’ottica di generalizzazione delle attività cardine per l’assolvimento del compito progettuale, qualsiasi sia la natura del progetto e degli oggetti da esso trattati e favorire l’inquadramento dell’argomento nell’ambito più strutturato dei Sistemi di gestione per la qualità.

Nel definire il proprio campo d’applicazione tuttavia, la norma UNI ISO 10006 specifica che essa “non costituisce da sola una guida per la “gestione del progetto”, ma fornisce consigli per la qualità nei processi di gestione del progetto. La guida per la qualità nei processi relativi al prodotto del progetto, e per l’approccio per processi, è fornita dalla norma UNI ISO 9004:2000 “Sistemi di gestione per la qualità - Linee guida per il miglioramento delle prestazioni”. Pertanto le attività sono inquadrate nell’operato di un Sistema di Gestione per la Qualità del progetto, direttamente emanato dall’organizzazione che ha costituito il gruppo di progetto e per quanto possibile allineato col sistema di gestione della qualità della stessa.

La norma UNI ISO 10006:2005, che tratta specificatamente i “processi di gestione del progetto”, ha carattere di guida e quindi non è utilizzabile per scopi di certificazione; deve essere utilizzata congiuntamente alla ISO 9004, che tratta i processi di realizzazione del prodotto, e quindi le due norme dovrebbero essere utilizzate congiuntamente; pone come presupposto l’esecuzione dei processi legati alla gestione del progetto nel quadro di un Sistema di Gestione per la Qualità, allineandosi così alla norma ISO 9001. In quanto linea guida, la norma non definisce alcun requisito “cogente” in termini di “gestione del progetto”; analogamente non definisce requisiti “aggiuntivi” rendendo più rigorosa l’applicazione di un sistema di gestione per la qualità nel caso di un’organizzazione che produca/eroghi i propri prodotti/servizi per commessa. Inoltre essa ha carattere generale e non presenta particolari specificità sia in relazione all’ambito (pubblico/privato) che al tipo di fornitura; in quanto standard che si pone l’obiettivo di costituire una guida relativa all’applicazione della gestione per la qualità nei progetti, trova maggiormente applicazione per quanto riguarda la PA come gestore e come acquirente di servizi ICT.

Per quanto riguarda i contenuti il modello sviluppa un circolo virtuoso di tipo Plan-Do-Check-Act costituito dalle seguenti attività: Responsabilità della Direzione, Gestione delle risorse, Realizzazione del prodotto, Misurazione, analisi e miglioramento. Tra queste possiamo considerare il primo e ultimo raggruppamento come maggiormente relativi al metodo e all’organizzazione orientate al miglioramento, mentre i due raggruppamenti centrali (“Gestione delle risorse” e “Realizzazione del prodotto”) sono quelli più peculiari alle attività di Project management.

Il framework individua una distinzione tra “organizzazione madre” e “organizzazione incaricata del progetto”, essendo la prima quella che decide di intraprendere il progetto e la seconda quella cui è assegnato il compito di portarlo a compimento. Ciò potrebbe focalizzare la lettura sulle implicazioni riguardo i compiti e le responsabilità esigibili distintamente dall’organizzazione che assegna l’esecuzione dei progetti e da quelle deputate a realizzarli effettivamente in analogia con quanto capita tra ente appaltante che decide l’esecuzione del progetto e ne definisce gli obiettivi e l’appaltatore chiamato ad eseguirlo

La norma è stata elaborata per essere utilizzata da parte di due generi di utenti: coloro che hanno esperienza nella gestione di progetti (“project manager”), come pure da parte di coloro che hanno esperienza nella gestione per la qualità (“quality manager”) e che sono chiamati ad operare in organizzazioni di progetto.

ISO/IEC 20000-1:2005 Information Technology - Service Management

La norma è uno Standard dedicato ai servizi IT ed ai relativi sistemi di gestione. La ISO/IEC 20000 si configura come una famiglia di norme (20000-1) e linee guida (20000-2) finalizzate a sostenere il miglioramento della efficacia e della efficienza delle organizzazioni erogatrici di servizi IT. Lo Standard nasce nel 2005 quando riprende ed internazionalizza un’esperienza di successo in ambito britannico (British Standard, BS 15000). Lo Standard ha l’obiettivo di fissare le caratteristiche di base di un sistema organizzativo dedicato alla gestione dei servizi IT consentendone valutazioni di conformità e misure del livello di capacità. Lo Standard riconosce l’importanza dei servizi IT, ne individua le specificità e stabilisce l’esigenza di una risposta adeguata ai problemi che si incontrano nella impostazione e nell’esercizio di un Sistema di gestione del servizio. Si collega con l’impostazione ITIL da cui storicamente deriva. Si propone di facilitare la costituzione di catene di fornitura di servizi consentendo l’interconnessione di sistemi di gestione di servizi IT appartenenti ad organizzazioni diverse. In generale lo standard può essere utilizzato per:

monitorare e migliorare la qualità del servizio;
confrontare i servizi di gestione ICT;
porre un punto di riferimento per una valutazione indipendente;
dimostrare la capacità di fornire servizi in grado di soddisfare i requisiti posti dal cliente.

Le organizzazioni destinatarie della norma sono classificabili in tre ampie tipologie: Fornitori, Acquirenti e Terze parti. I requisiti espressi dalla norma sollecitano le organizzazioni all’attivazione di un sistema di gestione dei servizi IT che strutturalmente risponda ai principi del TQM ed alla metodologia “Plan-Do-Check-Act” (PDCA).

Per dare un’idea delle dimensioni della norma si può dire che i processi della gestione dei servizi si dividono in due categorie (primari e di sistema); i quattordici processi primari si ripartiscono in cinque gruppi di processo per un totale complessivo di 163 prescrizioni elementari (SHALL) che rappresentano i requisiti dei processi.

La certificazione secondo la norma ISO 20000-1 in Italia è rilasciata alle organizzazioni da Enti accreditati da SINCERT, analogamente a quanto avviene per UNI EN ISO 9001:2000.

ISO/IEC 27001:2005 Information Security Management Systems

Gli standard ISO della serie 27000 sono dedicati al vasto tema della sicurezza delle informazioni. Fra questi la ISO 27001 del 2005, che rimpiazza e integra precedenti standard come il BS 7799, è il documento normativo di certificazione al quale un'azienda deve fare riferimento per costruire, mantenere e migliorare un SGSI (Sistema di Gestione della Sicurezza delle Informazioni) presso un’organizzazione. Lo standard è basato sulle indicazioni e linee guida fornite dal documento ISO 27002 (Linee guida per la gestione di un sistema per la sicurezza del'informazione).

Dal momento che l'informazione è un bene che aggiunge valore all'impresa, e che ormai la quasi totalità delle informazioni sono custodite su supporti informatici, ogni organizzazione deve essere in grado di garantire la sicurezza dei propri dati, in un contesto dove i rischi informatici causati dalle violazioni dei sistemi di sicurezza sono in continuo aumento. L'obiettivo dello standard è proprio quello di proteggere i dati e le informazioni, in qualunque forma e supporto si trovino,da minacce di ogni tipo, al fine di assicurarne l'integrità, la riservatezza e la disponibilità, e fornire i requisiti per adottare un adeguato sistema di gestione della sicurezza delle informazioni (SGSI) finalizzato ad una corretta gestione dei dati dell'azienda.

La norma si concentra sul trattamento delle informazioni e non sul loro contenuto. Pertanto destinatarie dello standard possono essere organizzazioni private, di qualsiasi dimensione operanti in tutti i settori merceologici e dei servizi, ovvero agenzie governative o amministrazioni ed enti pubblici, sia centrali che locali. L'impostazione dello standard ISO/IEC 27001 è coerente con quella del Sistema di Gestione per la Qualità ISO 9001:2000. Il Risk management, basandosi sull'approccio per processi, definito nella politica per la sicurezza, deve contenere l’identificazione dei rischi, l’analisi dei rischi, la valutazione ed il trattamento dei rischi, il riesame e la rivalutazione dei rischi. I Requisiti della norma sono di carattere generale e predisposti per essere applicati da tutte le organizzazioni. L’obiettivo di fondo della norma è quello di fornire i requisiti per il miglioramento continuo del sistema di sicurezza in modo da aderire ad un modello internazionalmente riconosciuto.

Di fondamentale importanza sono i controlli specificati all’Annesso A. Questo documento contiene i 133 "controlli" a cui, l'organizzazione che intende applicare la norma, deve attenersi. Essi vanno dalla politica e dall'organizzazione per la sicurezza, alla gestione dei beni e alla sicurezza delle risorse umane, dalla sicurezza fisica e ambientale alla gestione delle comunicazioni e dell' operativo, dal controllo degli accessi fisici e logici alla gestione di un monitoraggio e trattamento degli incidenti (relativi alla sicurezza delle informazioni). La gestione della Business Continuity e il rispetto normativo, completano l'elenco degli obiettivi di controllo.

Sono ammesse esclusioni nei 133 “controlli” richiesti. L’Organizzazione deve dichiarare i controlli esclusi come “non applicabili” e darne una motivazione.

Lo Standard ISO /IEC 27001: 2005 riguarda la certificazione di Sistemi di gestione per la Sicurezza delle Informazioni. Nella certificazione del Sistema di gestione per la sicurezza possono essere previsti :

Tutti i processi dell’Organizzazione;
Uno o più processi primari e relative interfacce;
Un processo critico e relative interfacce;
Uno o più processi primari e uno o più processi di supporto e relative interfacce.

7.Applicabilità degli standard analizzati.

In analogia con le Best Practice la tabella di cui alla seguente pagina rappresentata un quadro sinottico delle principali caratteristiche degli standard considerati.

Gli Standard analizzati sono norme di sistema e, in quanto tali, differiscono in modo marcato da standard di tipo tecnico relativi ad uno specifico processo o attività o metodologia.

Le norme di sistema sono volutamente generalizzate per poter essere adattate alle diverse tipologie di aziende o organizzazioni interessate alla loro applicazione e, di conseguenza, non esprimono requisiti stringenti, quanto piuttosto requisiti generali, di alto livello, applicabili a tutte le organizzazioni ed ai loro sistemi di gestione.

Le tre norme condividono l’approccio basato sul ciclo di Denim (plan – do – check – act) e la visione fondata sul modello TQM (Total Quality Management) e su valori guida come l’attenzione al cliente, il miglioramento continuo (sia del processo produttivo che delle prestazioni del personale), l’introduzione di metodi oggettivi di misura, l’attenzione ai risultati.

Essendo norme generalizzate ed indirizzate al sistema aziendale, la loro copertura dei processi aziendali nell’ambito del sistema di gestione di appartenenza (qualità, service management, sicurezza informazioni) è totale anche se non vi sono riferimenti specifici al singolo processo, attività o organizzazione. Sta agli utilizzatori, alla loro professionalità e competenza, “interpretare i requisiti ed il modello gestionale” e trasformarlo nell’applicazione pratica e specifica richiesta.

Sempre per quanto riguarda la copertura occorre notare che la gestione della sicurezza informatica è uno dei processi di erogazione del servizio della ISO/IEC 20000-1. La stessa norma specifica che le organizzazioni già certificate ISO/IEC 27001 soddisfano i requisiti di sicurezza propri dello standard.

Lo schema di certificazione è comune ai tre standard. Le organizzazioni possono essere valutate nella loro conformità con le norme ISO e, nel caso che la valutazione sia positiva, possono essere certificate dagli Enti Ufficiali di certificazione. Tali enti devono a loro volta essere accreditati da un’Organizzazione di Accreditamento di un paese membro della ISO.

	ISO 9001	ISO 10006	ISO 20000-1	ISO 27001
Ambito di applicazione	Sistema di Gestione di una organizzazione indirizzato alla Qualità (Quality management system).	Gestione e Qualità del progetto	Sistema di Gestione di una organizzazione erogante servizi ICT.	Sistema di Gestione per la sicurezza delle informazioni (Security management system).
Finalità	Specificare i requisiti di un Sistema di Gestione di una organizzazione orientata alla Qualità (SGQ).	Fornire indicazione per conseguire la qualità nella conduzione dei progetti	Specificare i requisiti minimi di un sistema di gestione che garantisce l’adozione di processi idonei per erogare servizi ICT di qualità e costi concordati	Specificare il modello dei requisiti al fine di impostare, implementare, utilizzare, monitorare, rivedere, manutenere e migliorare un Sistema di Gestione della Sicurezza delle Informazioni (SGSI).
Destinatari principali	Ogni tipo di organizzazione	Organizzazione che gestisce un progetto. Project e quality managers	Organizzazioni che erogano servizi ICT	Organizzazioni che trattano informazioni.
Destinatari cointeressati	Cliente di una organizzazione fornitrice di beni e/o servizi.	Committente del progetto	Cliente di una organizzazione che gli eroga servizi informatici.	Cliente di una organizzazione a cui ha affidato la gestione delle proprie informazioni, o che gestisce informazioni che lo riguardano.
Specificità
Pubblica amministrazione
Forniture ICT
Gestione progetti	X	X		X
Erogazione servizi			X	X
Relazione cliente-fornitore	X	X	X	X
Punto di vista Cliente		X		X
Punto di vista Fornitore	X	X	X	X
Contesto d'uso in ambito PA
PA acquirente di forniture ICT	X	X	X	X
PA gestore di progetti	X	X		X
PA erogatrice di servizi	X		X	X
Livello di dettaglio
Strategie
Controllo dei processi	X	X	X	X
Esecuzione dei processi			X
Istruzioni operative
Certificazione
Persone			X
Organizzazioni ICT	X		X	X
Centri di formazione			X
Diffusione
lingua	ITA/ENG	ITA/ENG	ENG	ITA/ENG

8.Modalità adottate per la Descrizione dei lemmi

Ogni lemma possiede la stessa strutturazione delle informazioni, in modo da facilitare al lettore il reperimento delle informazioni di interesse. Nel seguito viene presentato un indice commentato che fornisce, relativamente ad ogni capitolo, indicazioni riguardo i contenuti.

Cap.1 Obiettivi e ambito

In questo capitolo introduttivo vengono descritti gli obiettivi che il framework intende raggiungere e che possono orientare in prima istanza l’interesse del lettore. Tipicamente si tratta di obiettivi di miglioramento di processi aziendali. Viene inoltre specificato in quale contesto nel quale framework può trovare applicazione.

Cap.2 Storia

Ogni Framework ha subito nel corso degli anni modifiche ed affinamenti, più o meno consistenti, che sono state apportate con la finalità di mantenerlo attuale ed agganciato allo sviluppo del mercato ICT. In questo capitolo sono ricostruite tali vicende affinché il lettore possa conoscere le motivazioni che hanno portato alla nascita di una Framework, in quale ambito è stato sviluppato, le principali milestone successive.

Tutto ciò può giovare sia alla comprensione dell’utilità Framework sia alla creazione di corrette aspettative su come esso possa essere effettivamente applicato.

Inoltre, poiché può accadere che in un dato momento storico coesistano diverse versioni dello stesso Framework, questo capitolo può dare lumi su quale versione approcciare.

Cap.3 Destinatari

In questo capitolo sono individuati i principali soggetti destinatari del Framework, che, a seconda dell’ottica adottata, potranno essere ruoli o profili professionali, se si stratta di persone, oppure tipologie di organizzazioni.

Vengono inoltre descritte le culture coinvolte (amministrativa, legale, manageriale, ICT) ed le competenze che sarà necessario sviluppare nel caso di un progetto di adozione.

Il capitolo si chiude allargando l’analisi a tutti i soggetti interessati (stakholder), che possono ricavare benefici dall’adozione del Framework, anche se non direttamente coinvolti.

Cap.4 Specificità

In questo capitolo viene anticipato quali contenuti specifici sono stati sviluppati che possono trovare sovrapposizione con quelli delle linee guida.

Tali argomenti possono riguardare:

la pubblica amministrazione (sia centrale che locale);
le forniture ICT;
la relazione contrattuale (specificando se dal punto di vista del cliente o del fornitore);
lo sviluppo di progetti;
l’erogazione di servizi.

Cap.5 Contenuti

Questo è il capitolo centrale di ogni lemma. I contenuti sono sviluppati secondo uno schema costante che prevede l’esplicitazione dei processi indirizzati dal framework, le loro relazioni e propedeuticità, attraverso uno schema grafico.

Questo elemento introdurrà ad una disamina e classificazione dei processi trattati, unitamente ad una loro articolazione in fasi di un ciclo di vita (specifico per ogni Framework), mettendo eventualmente in luce le relazioni con il ciclo di vita delle Linee Guida.

Saranno indicate altresì le strategie ed i requisiti individuati per raggiungere gli specifici obiettivi di ogni Framework.

Cap.6 Modalità di applicazione

In questo capitolo vengono in primo luogo riportati i possibili usi sia in ambito PA (acquisizione forniture ICT, gestione progetti ICT, erogazione servizi ICT, erogazione di procedimenti amministrativi) sia in ambito di fornitori di servizi ICT.

Vengono discussi opportunità criticità da affrontare nell’applicazione. Si forniranno inoltre le caratteristiche peculiari di un processo di adozione fornendo indicazioni per individuare le più significative variabili progettuali: i principali driver dei tempi e dei costi necessari, una stima dell’impatto organizzativo, in termini di formazione e riqualificazione del personale, le possibili ricadute, ecc.

Cap.7 Documentazione disponibile

La documentazione disponibile potrebbe essere ponderosa, costituita da diversi documenti, che possono avere finalità e destinatari diversi, che generalmente sono messe a disposizione a titolo oneroso. Il capitolo costituisce una guida per l’acquisizione, la consultazione e lo studio della documentazione ufficiale disponibile, specificando informazioni quali:

lo schema di relazioni e gerarchie a cui sottostanno i documenti
la lingua utilizzata
la diffusione raggiunta in ambito internazionale
le modalità di reperimento, ecc

Cap.8 Certificazioni esistenti

In questo capitolo viene specificato se esistono delle certificazioni legate al Framework e, in questo caso, quale ne è l’oggetto, il processo che porta alla certificazione ed i destinatari. Infatti ad ogni Framework possono essere associate diverse tipologie di certificazioni attestanti specifiche particolarità.

Oltre ad elencare le certificazioni esistenti in questo capitolo vengono trattati argomenti connessi come:

la diffusione raggiunta in ambito europeo e in ambito internazionale,
gli organismi di certificazione (o gli enti di accreditamento) costituiti in Italia ed in Europa,
i possibili utilizzi della certificazione in ambito contrattuale.

Cap.9 Formazione disponibile

Saranno fornite informazioni sulle caratteristiche dei corsi disponibili sul mercato, come:

contenuti
obiettivi e percorsi formativi
destinatari
materiali didattici messi a disposizione
tipologia ed ambito di validità delle attestazioni rilasciate.

Cap.10 Estratto del glossario

Inevitabilmente ogni Framework sviluppa un proprio vocabolario nel quale ci si può imbattere sia in termini del tutto nuovi (soprattutto in forma di acronimi), sia in termini noti ma utilizzati con un’accezione particolare e, ancora più frequentemente, termini usuali, almeno in ambito ICT, il cui il significato però ha bisogno di essere specificato per mettere a fuoco sottili sfumature. L’obiettivo di questo capitolo è quello di fornire un adeguato supporto alla lettura, risolvendo possibili ambiguità.

Cap.11 Associazioni di riferimento

In questo capitolo sono fornite indicazioni sulle associazioni che in ambito italiano, europeo o internazionale, si preoccupano dell’aggiornamento e della diffusione del Framework. Per ogni associazione verrà definito lo scopo ed i servizi erogati verso i propri associati.

Cap.12 Indicazioni bibliografiche

In questo ultimo capitolo sono elencate le indicazioni bibliografiche che il lettore può trovare utili per proseguire da solo nell’approfondimento delle tematiche trattate dal Framework. Oltre ai testi più diffusi saranno segnalate riviste specializzate e siti internet attinenti.


Numero d'Oggetto/Part Number	Ed./Issue	Data/Date	Com. Mod./Ch. Notice	Manuale di riferimento Ricognizione di alcune Best Practice applicabili ai contratti ICT
MANUALE 9	2.0	29.05.2009	---
Centro Nazionale per l’Informatica nella Pubblica Amministrazione				Pagina 32/52

Document Metadata

Table of Contents

Contract

Document Metadata