marzo 2007
31/7
marzo 2007
Linee guida sulla qualità dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA
Manuale 7 Governo
dei Contratti ICT
31/7
marzo 2007
i Quaderni n. 31 marzo 2007 Supplemento al n.1/2007
di Innovazione
i Quaderni
sommario
Linee guida sulla qualità dei beni e dei servizi ICT
PER LA DEFINIZIONE ED IL GOVERNO DEI CONTRATTI DELLA PA
3 PREMESSA
Anno V Registrato al Tribunale di Roma
9
n.523/2003
del 15 dicembre 2003
11
Direttore responsabile Xxxxxx Xxxxxxxxx
Quaderno a cura di:
Xxxxx Xxxxxxx (xxxxx.xxxxxxx@xxxxx.xx)
13
Redazione Centro Nazionale per l’Informatica nella
Pubblica Amministrazione
17
Xxx Xxxxxx, 00x 00000 Xxxx
Tel. (00) 00 00000.0
I Quaderni del Cnipa sono pubblicati all’indirizzo:
GOVERNO DEI CONTRATTI ICT MANUALE APPLICATIVO
3. Governare i contratti ICT
3.1. QUADRO DI RIFERIMENTO 18
3.1.1. ATTIVITÀ 20
3.1.2. ATTORI ED ORGANIZZAZIONE 27
3.1.3. COMPETENZE 29
3.1.4. FLUSSI INFORMATIVI 30
3.1.5. INTEGRAZIONE DI PIÙ CONTRATTI 37
3.2. DETTAGLIO DELLE ATTIVITÀ DI GOVERNO 40
41
4. Governo dei contratti per la realizzazione dei Progetti
Stampa: Stilgrafica srl - Roma
4.1. ATTIVITÀ DI COMPETENZA DEL FORNITORE 44
4.1.1. STABILIRE LA DIMENSIONE FUNZIONALE DEL SOFTWARE 44
4.1.2. PIANIFICARE IL PROGETTO 46
4.1.3. MISURARE LO STATO AVANZAMENTO LAVORI (SAL) 52
4.1.4. GOVERNARE LA QUALITÀ 56
4.2. ATTIVITÀ DI COMPETENZA DELL’AMMINISTRAZIONE 59
4.2.1. Controllare la pianificazione e lo stato
DI AVANZAMENTO LAVORI 59
4.2.2. Gestire la Comunicazione tra Amministrazione
E FORNITORE 61
4.2.3. GESTIRE IL RISCHIO 63
4.2.4. GESTIRE IL CAMBIAMENTO (VARIANTI) 68
4.2.5. GESTIRE L’AVVICENDAMENTO CONTRATTUALE 71
4.2.6. VERIFICARE GLI OGGETTI DI FORNITURA 73
4.2.7. DETERMINARE I CORRISPETTIVI E SALDARE LE FATTURE 75
79 5. GOVERNO DEI CONTRATTI PER L’EROGAZIONE DI SERVIZI
5.1. ATTIVITÀ DI COMPETENZA DEL FORNITORE 80
5.1.1. PREDISPORRE UN PIANO DELLA QUALITÀ 81
5.1.2. MONITORARE IL SERVIZIO 82
5.1.3. RILEVARE E RENDICONTARE I LIVELLI DI SERVIZIO 85
5.2. ATTIVITÀ DI COMPETENZA DELL’AMMINISTRAZIONE 86
5.2.1. CONTROLLARE GLI ADEMPIMENTI CONTRATTUALI 88
5.2.2. Controllare l’adeguatezza dei livelli
DI SERVIZIO RICHIESTI 90
5.2.3. SVOLGERE ATTIVITÀ DI CONDUZIONE 93
99 6. DOCUMENTI PER IL GOVERNO DEI CONTRATTI
6.1. INDICI COMMENTATI 99
6.1.1. PIANO DI PROGETTO 99
6.1.2. PIANO DELLA QUALITÀ 100
6.1.3. XXXXX XX XXXXXXXX XXX XXXXXX 000
6.1.4. GESTIONE MODIFICA CONTENUTO DEL PROGETTO 104
6.1.5. STATO AVANZAMENTO LAVORI 105
6.1.6. VERBALE DI VERIFICA ISPETTIVA DEI SISTEMI QUALITÀ 105
6.1.7. COMUNICAZIONI ESTEMPORANEE 106
6.1.8. ANALISI DELLA SODDISFAZIONE DELL’UTENZA 107
6.1.9. LIVELLI DI SERVIZIO RILEVATI 108
6.1.10. VERBALE DI COLLAUDO 109
Premessa
Allo scopo di incentivare l’acquisizione di prodotti e servizi ICT di qualità da parte delle pubbliche amministrazioni centrali e locali e supportare l’azione di governo dei contratti ICT, il Cnipa, nel dicembre 2003, ha istituito un apposito Gruppo di lavoro (GdL) dedicato alla qualità dei beni e dei servizi ICT.
Il GdL ha avuto come referente l’xxx. Xxxxx Xxxxxxx, Componente dell’Organo collegiale del CNIPA ed è stato coordinato dal xxxx. Xxxxx Xxxxxxx, dirigente del CNIPA. Ai lavori hanno partecipato, oltre al CNIPA, alcune amministrazioni centrali (INPS, Giustizia, MIUR), due società di informatica a capitale interamente pubblico (CONSIP, SOGEI) e le associazioni di categoria dei fornitori ICT (ANASIN/AITech, ASSINFORM; FEDERCOMIN). In aggiunta al GdL hanno contribuito alla redazione delle Linee guida un vasto gruppo di circa 120 perso- ne, dipendenti di diverse aziende, tra le più rappresentative del mercato ICT nazionale. Pur non partecipando direttamente al GdL un’utile collaborazione è stata offerta anche dalla Banca d’Italia.
A partire dal 2004 si sono realizzati sette manuali sulle Linee guida sulla qualità dei beni e servizi ICT per la definizione ed il governo dei contratti della pubblica ammini- strazione, per permettere alle amministrazioni pubbliche di attuare pienamente lo slogan posto alla base dei lavori: ottenere qualità dai fornitori di servizi ICT per for- nire qualità a cittadini ed imprese.
Non si è ha avuta l’ambizione di offrire un contributo innovativo dal punto di vista scientifi- co, piuttosto si è inteso fornire indicazioni di buon senso, pragmatiche e immediatamente applicabili, sia da parte delle amministrazioni, nel loro ruolo di stazioni appaltanti, che da parte dei fornitori, offerenti in fase di gara e, successivamente, firmatari dei contratti. Indica- zioni caratterizzate dall’essere state rese:
• indirizzate alla variegata tipologia di destinatari che ruotano attorno al processo di acquisizione di beni e servizi ICT;
• didatticamente utili per favorire la diffusione e la predisposizione di eventi formativi;
• di facile comprensione per tutte le diverse culture espresse delle professionalità a diverso titolo coinvolte nella definizione e governo dei contratti ICT;
• utilizzabili come base di partenza per la scrittura degli atti di gara;
3
• attuabili in fase di esecuzione dei contratti, perché concrete, semplici e non ambigue e basate su esperienze precedenti (best practices).
A valle del completamento dei lavori, l’evoluzione e la gestione delle Linee guida è stata affi- data all’Area “Governo e Monitoraggio Forniture ICT” del CNIPA, sotto la responsabilità
del xxxx. Xxxxx Xxxxxxx, già coordinatore del Gruppo di lavoro. In considerazione dei risultati raggiunti, allo scopo di garantire il mantenimento nel tempo della validità ed attualità delle Linee guida e massimizzarne l’utilizzo da parte delle amministrazioni, l’area opera per:
• recepire indicazioni, suggerimenti, richieste, provenienti sia da amministrazioni e imprese per il tramite dell’apposito canale di posta elettronica reso disponibile;
• estendere i Manuali e le classi di fornitura a nuovi servizi ICT, creando gruppi di stu- dio per l’approfondimento, aggiornamento, inserimento di specifici argomenti;
• avviare iniziative per diffondere la conoscenza delle Linee guida e favorirne l’uso da parte delle amministrazioni centrali e locali ed erogare interventi formativi sui conte- xxxx delle Linee guida;
• mantenere attivo il canale di interazione sulla contrattualistica ICT che si è creato con le Associazioni di categoria ed i Fornitori stessi.
Le Linee guida 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 descri- zione delle attività da prevedersi contrattualmente, ai prodotti che dette attività realiz- zano, 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 necessa- ria 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.
Per la stesura delle Linee guida si è adottato un approccio caratterizzato da:
• assunzione di punti di vista complementari per la definizione della qualità, il fruitore del servizio (utente finale), l’amministrazione appaltante il servizio (stazione appaltan- te), la qualità intrinseca del servizio;
• considerazione dell’intero ciclo di vita inerente l’acquisizione di una fornitura ICT (ela- borazione delle strategie di acquisto, definizione delle modalità di appalto, definizione del contratto, governo del contratto);
• considerazione di tutte le possibili dimensioni della qualità caratterizzanti prodotti e servizi ICT nelle diverse fasi del ciclo di vita;
• enfasi sulla concretezza attuata fornendo in termini pragmatici risposte a domande operative;
4
• eliminazione delle possibili ambiguità nell’adozione a livello contrattuale di livelli di servizio e indicatori di qualità.
Le Linee guida sono strutturate secondo 7 documenti distinti, denominati “Manuali” e 37 “Lemmi” allegati al Manuale operativo “Dizionario delle Forniture ICT elementari”.
1 Manuale d’uso “Presentazione e Utilizzo delle Linee Guida”
Questo manuale è il documento introduttivo alle Linee Guida, il suo scopo è quello di :
• evidenziare le motivazioni alla base delle Linee guida, illustrare il loro scopo, l’approc- cio adottato per la loro stesura, i destinatari ed i possibili percorsi di lettura, la struttu- ra ed i contenuti, le modalità d’uso dei diversi documenti che compongono le Linee Guida;
• esplicitare le Classi di fornitura elementari trattate nel Manuale operativo “Dizionario delle forniture ICT”;
• spiegare le modalità adottate di descrizione delle classi di fornitura ICT elementari e come usare le classi di fornitura per scrivere contratti e capitolati tecnici.
2 Manuale applicativo “Strategie di Acquisizione delle forniture ICT”
Questo manuale illustra alle amministrazioni interessate all’acquisizione di forniture ICT i vantaggi ed i rischi delle possibili scelte strategiche da compiere propedeuticamente alla realizzazione di una gara. Il suo scopo è quello di presentare ragionamenti, applicabili allo specifico contesto in cui si colloca l’amministrazione appaltante, in merito:
• alle possibili strategie di acquisizione delle forniture ICT ed alle implicazioni strategi- che, organizzative, economiche ed operative legate alle diverse scelte oltre che ai fat- tori critici di successo;
• alle diverse strategie attuabili per quanto concerne il software applicativo;
• alle possibili architetture contrattuali;
• alle diverse tipologie di contratti ICT ed all’organizzazione del contratto;
• ai contenuti del contratto ICT.
3 Manuale applicativo “Appalto pubblico di forniture ICT”
Questo manuale illustra alle stazioni appaltanti le forniture ICT le conseguenze derivanti dalle possibili scelte ed approcci inerenti l’appalto. Lo scopo di questo manuale è quello di esprimere ragionamenti applicabili alla gara che l’amministrazione deve realizzare coerente- mente alle strategie di acquisizione delle forniture ICT definite:
• la scelta dell’oggetto e della modalità di fornitura;
• scelta della procedura di gara;
• determinazione dei criteri di accesso alla gara;
• attribuzione del punteggio tecnico;
• attribuzione del punteggio economico;
• prevenzione dalle offerte anormalmente basse.
4 Manuale operativo “Dizionario delle Forniture ICT Elementari”
5
Questo manuale presenta il lessico dell’ICT raccolto in lemmi ordinati alfabeticamente che rappresentano specifiche tipologie di forniture ICT. Lo scopo di questo manuale è quello di fornire “ricette contrattuali”, di immediato utilizzo, utili per rappresentare contrattual- mente le esigenze della stazione appaltante, modificabili, copiabili e incollabili per l’elabo- razione di contratti e capitolati tecnici. Come un comune dizionario questo manuale si
consulta specificatamente, lemma per lemma, in funzione delle proprie esigenze. Ogni lemma prevede:
• la descrizione della Classe di fornitura ICT elementare;
• l’esplicitazione di “regole” per l’uso della classe di fornitura;
• la descrizione delle attività e dei relativi prodotti di queste attività;
• una tabella che riassume attività, prodotti e indicatori di qualità;
• una scheda per ogni indicatore di qualità;
• un glossario (facoltativo).
5 Manuale Applicativo “Esempi di applicazione”
Questo manuale aiuta a comprendere meglio le logiche di utilizzo dei lemmi contenuti nel Manuale operativo “Dizionario delle Forniture ICT Elementari”, proponendo esempi che consentono di approfondire i passi da compiere per definire la fornitura oggetto di un Capitolato tecnico:
• come individuare e personalizzare le Classi di fornitura di interesse a partire dalle esi- genze che spingono una Amministrazione ad avviare una procedura di gara;
• come selezionare e personalizzare attività e prodotti da richiedere al Fornitore in ese- cuzione del contratto;
• come selezionare e personalizzare indicatori di qualità e valori soglia per le attività ed i prodotti richiesti;
• come descrivere la fornitura nel Capitolato tecnico, integrando Classi di fornitura e processi trasversali.
6 Manuale di riferimento “Modelli per la qualità delle forniture ICT”
Questo manuale presenta i “Modelli per la qualità delle forniture ICT” illustrando gli standard e le logiche adottate per la descrizione delle forniture elementari e la definizione della loro qualità e fornisce i riferimenti culturali di base e puntamenti a possibili approfondimenti:
• i punti di vista per la definizione di qualità;
• i processi del ciclo di vita della generica fornitura;
• le categorie ed attributi di qualità della generica fornitura;
• alcuni modelli per la gestione dei contratti ICT;
• il glossario;
• la bibliografia (testi, articoli, siti).
7 Manuale Applicativo “Governo dei Contratti ICT”
6
Questo manuale fornisce elementi informativi utili per un efficace governo dei contratti ICT per la realizzazione di progetti e per la fornitura di beni e servizi. Tratta in maniera separata l’attività di governo per la realizzazione dei progetti da quella per l’erogazione dei servizi in quanto sono diversi i criteri di controllo, la gestione dei rischi e l’interazione amministrazione-fornitore. Sono anche separate le attività di competenza del fornitore da quelle dell’amministrazione allo scopo di indicare in modo esplicito i ruoli e le responsabi-
lità delle parti nel governo di un contratto. Descrive le modalità di governo dei contratti in termini di:
• struttura organizzativa e ruoli;
• attività e documenti di pianificazione e controllo;
• sistema di comunicazione tra il fornitore e l’amministrazione.
La logica di composizione dei manuali segue il ciclo di vita delle forniture ICT, iniziando dalle propedeutiche strategie di acquisizione, proseguendo all’appalto pubblico delle forni- ture ICT (una cui grossa componente è la redazione di capitolati tecnici attuabile sulla base del Dizionario delle forniture ICT, il cui utilizzo è esemplificato dagli esempi di applicazio- ne), per arrivare, a valle della stipula del contratto, al governo del medesimo.
Appalto pubblico di forniture ICT
Manuale applicativo
Strategie di acquisizione delle forniture ICT
Il primo manuale, che come precedentemente scritto, descrive la presentazione e l’ utilizzo delle Linee guida, rappresenta il cappello descrittivo dei diversi contenuti sviluppati, mentre i modelli per la qualità delle forniture forniscono i riferimenti e gli approfondimenti, più culturali e meno immediatamente operativi, a tutti i restanti manuali. Lo schema seguente rappresenta il disegno concettuale delle Linee guida del tutto indipendente dalla numerazione dei manuali.
Manuale d’uso Presentazione e utilizzo delle Linee Guida
Manuale operativo Governatore dei contratti ICT
Manuale applicativo Esempi di applicazione
Manuale operativo Dizionario delle forniture ICT
Manuale di riferimento Modalità per la qualità delle forniture ICT
La pubblicazione e distribuzione delle Linee guida prevede il concomitante utilizzo di diver- si canali costituiti:
• dalla sezione Qualità dei servizi ICT posta nell’home page del sito web del Cnipa all’indirizzo xxxx://xxx.xxxxx.xxx.xx/xxxx/xx-XX/ ;
• dal Cd-Rom Qualità dei Servizi ICT, distribuito direttamente dal Cnipa;
• dalla collana editoriale i Quaderni del Cnipa.
La struttura delle Linee guida sopra presentata sarà mantenuta invariata indipendentemente dal canale di distribuzione utilizzato.
7
Nella versione a stampa delle Linee guida che state leggendo relative al “Dizionario delle Forniture ICT”, vengono introdotti i concetti comuni alle singole classi di Fornitura esistenti, ma le stesse non vengono singolarmente riportate. Questo in quanto il Dizionario delle for-
niture ICT è ideato come un archivio di tipologie di forniture a cui attingere, in un’ottica di riuso ( copia e incolla dei contenuti), per l’elaborazione di contratti e capitolati tecnici. Le singole classi di fornitura, seguendo la logica di quanto scritto, possono quindi essere scari- cate direttamente dal sito CNIPA.
I Manuali stampati nell’ambito della collana editoriale i Quaderni, sono i seguenti:
• Quaderno n° 31 - manuale 1: Presentazione e utilizzo delle Linee guida;
• Quaderno n° 31 - manuale 2: Strategie di acquisizione delle forniture ICT;
• Quaderno n° 31 - manuale 3: Appalto pubblico di forniture ICT;
• Quaderno n° 31 - manuale 4: Dizionario delle forniture ICT;
• Quaderno n° 31 - manuale 5: Esempi di applicazione;
• Quaderno n° 31 - manuale 6: Modelli per la qualità delle forniture ICT;
• Quaderno n° 31 - manuale 7: Governo dei Contratti ICT.
Tutti gli aggiornamenti delle Linee guida sono pubblicati sul sito CNIPA dove ognuno dei Manuali e delle Classi di fornitura è identificato con un numero di versione ed una data per facilitare l’identificazione di quello più aggiornato. In ogni caso nella sezione del sito CNIPA già citata, vengono sempre segnalati gli aggiornamenti mentre i documenti obsoleti vengo- no rimossi e non sono più accessibili.
Nei due anni trascorsi dalla pubblicazione delle Linee guida sono state distribuite oltre
8.000 copie dei primi sei manuali e 4.000 copie del settimo manuale dedicato al “Governo dei contratti ICT” (rilasciato a marzo 2006).
Ovviamente questi risultati non sono un indicatore di qualità delle Linee guida, ma testimo- niano dell’elevato interesse che i temi trattati dalla Linee guida sollevano all’interno di amministrazioni e fornitori ICT.
Alla mera distribuzione delle Linee guida, si sono affiancate attività informative e formative volte alla loro diffusione:
• complessivamente, i convegni realizzati sono stati 13 per un totale di circa 2600 perso- ne coinvolte;
• parallelamente ai convegni sinora sono stati organizzati 6 interventi formativi che hanno coinvolto dirigenti e funzionari di pubbliche amministrazioni centrali e locali per un totale di 700 giorni persona;
• a valle dell’esperienza formativa maturata, sono stati realizzati materiali didattici per complessive 34 ore di lezione che, in conseguenza dell’interesse manifestato dai par- tecipanti agli eventi sopra riportati, sono stati resi disponibili sul sito CNIPA.
Per concludere vorremmo invitarvi ad esprimere la vostra valutazione delle Linee guida compilando sul sito CNIPA un semplice e sintetico questionario (Qualità dei Manuali: la vostra valutazione). Questo allo scopo di fornire indicazioni sulla qualità riscontrata nella let- tura e l’utilizzo dei manuali, fornendo al tempo stesso utili suggerimenti di miglioramento.
8
Responsabile Area
Governo e Monitoraggio Forniture ICT
Governo dei Contratti ICT
Manuale applicativo
febbraio 2007
Versione 0.0
1. Generalità sul documento
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 descri- zione delle attività da prevedersi contrattualmente, ai prodotti che dette attività realiz- zano (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 necessa- ria 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.
In particolare il presente manuale applicativo ha lo scopo di fornire alle amministrazioni elementi informativi utili per un efficace governo dei contratti ICT per la realizzazione di progetti e per la fornitura di beni e servizi. Oltre alle attività di competenza delle ammini- strazioni, si è ritenuto utile descrivere anche i compiti del fornitore per specificare le intera- zioni tra le parti e per fornire i riferimenti culturali generali utili alle amministrazioni per valutare l’operato del fornitore riguardo alla conduzione dei progetti e/o dei servizi.
Nel documento si prende in considerazione la parte del ciclo di vita della fornitura successi- va alla sottoscrizione del contratto e se ne descrivono la struttura organizzativa, i ruoli, le attività, i metodi più diffusi, i documenti di pianificazione e controllo, il sistema di comuni- cazione tra il fornitore e l’Amministrazione.
11
Si è inoltre ritenuto utile rappresentare gli aspetti specifici che occorre governare nell’esecu- zione di contratti affidati a più fornitori in quanto, in questi casi, l’Amministrazione, oltre a svolgere una più attenta attività di controllo, ha il compito di coordinare l’azione dei diversi fornitori.
In questa seconda versione del manuale sono recepiti i metodi di stima e di determinazione dei corrispettivi riferiti a contratti relativi a progetti di sviluppo software, suggeriti dal GUFPI
con il documento “Utilizzo contrattuale dei Function Point” pubblicato nel luglio 2006. L’uti- lizzo di tali metodi è descritto nel dettaglio nella seconda versione del manuale “Strategie di acquisizione delle forniture ICT”.
Riferimenti
• Norma UNI ISO 10006 - Sistemi di gestione per la qualità - Linee guida per la gestione per la qualità nei progetti;
• Norma ISO/IEC 9126-1:2001 - Software engineering - Product quality - Part 1: Quality model;
• Norma UNI EN ISO 9001:2000 - Sistemi di gestione per la qualità – requisiti;
• Norma UNI CEI EN 45012 - Requisiti generali degli organismi di valutazione e certifi- cazione dei sistemi qualità;
• Norma UNI ISO 30011/1 - Criteri generali per le verifiche ispettive dei sistemi qualita`
- Attività di verifica ispettiva.
• Decreto legislativo 12 febbraio 1993, n. 39 -. Norme in materia di sistemi informativi automatizzati delle amministrazioni pubbliche
• PMBOK - Project Management Body of Knowledge del PMI – Project Management Institute
• COBIT (Control Objectives for Information and related Technology)
• LGC-FP Linee Guida per l’uso Contrattuale dei Function Point – Documento tecnico 2006/01 – GUFPI-ISMA
12
2. Gruppo di Lavoro
Le Linee guida di cui il presente manuale fa parte integrante sono state elaborate da un Gruppo di lavoro, dedicato alla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti ICT della Pubblica Amministrazione. Il Gruppo di lavoro è stato costi- tuito nel dicembre 2003 dal Centro nazionale per l’informatica nella pubblica amministra- zione (CNIPA), in modo tale da rappresentare al suo interno sia alcune amministrazioni centrali, che le associazioni di categoria dei fornitori di servizi ICT.
Il Gruppo di Lavoro, di cui è stato referente l’Xxx. Xxxxx Xxxxxxx, Componente dell’Organo collegiale del CNIPA, è stato coordinato dal Xxxx. Xxxxx Xxxxxxx, Dirigente del CNIPA. Al Gruppo di Lavoro hanno partecipato, oltre al CNIPA, alcune amministrazioni centrali (INPS, Giustizia, MIUR), due società di informatica a capitale interamente pubblico (CONSIP, SOGEI) e le associazioni di categoria dei fornitori ICT (AITech,/ASSINFORM) afferenti alla Federazione Servizi Innovativi e Tecnologici di Confindustria. Ad integrazione del Gruppo di Lavoro hanno contribuito alla redazione delle Linee guida un vasto gruppo di circa 80 persone, dipendenti di diverse aziende, tra le più rappresentative del mercato ICT naziona- le. Pur non partecipando direttamente al Gruppo di Lavoro un’utile collaborazione è stata offerta anche dalla Banca d’Italia.
Dal gennaio 2005, a valle del completamento dei lavori, sciolto il Gruppo di lavoro, la gestione delle Linee guida è stata affidata all’Area Governo e Monitoraggio delle forniture ICT del CNIPA, sotto la responsabilità del Xxxx. Xxxxx Xxxxxxx, già coordinatore del Gruppo di lavoro.
In considerazione dei risultati raggiunti, allo scopo di garantire il mantenimento nel tempo della validità ed attualità delle Linee guida e massimizzarne l’utilizzo da parte delle ammini- strazioni l’Area opera per:
• recepire indicazioni, suggerimenti, richieste, provenienti sia da amministrazioni e imprese per il tramite dell’apposito canale di posta elettronica reso disponibile;
• estendere le classi di fornitura a nuovi servizi ICT;
• estendere i Manuali trattando più compiutamente altri temi connessi alla qualità delle forniture ICT a partire dala tematica del governo dei contratti ICT, che chiude il ciclo di vita dell’acquisizione delle forniture ICT tratteggiato dalle Linee guida e che è l’og- getto di questo manuale;
13
• aumentare la coerenza del disegno complessivo delle Linee guida ed affinare gli indi- catori 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;
• avviare iniziative per diffondere la conoscenza delle Linee Guida e favorirne l’uso da parte delle amministrazioni centrali e locali;
• prevedere la messa a punto di interventi di formazione sull’Acquisizione delle fornitu- re ICT, sulla base dei contenuti delle Linee guida;
• pubblicare le Linee guida in forma cartacea.
Per quanto concerne il presente manuale un particolare ringraziamento va a chi ha diretta- mente partecipato alla sua redazione e revisione.
Xxxxxx Xxxxxxxxx in rappresentanza di Istituto Italiano di Project Management Xxxxxxx Xxxxxxx Xxxxx in rappresentanza di C & M Group
Xxxxxxx Xxxxxxx in rappresentanza di CONSIP Xxxxx Xxxxx CNIPA
Xxxxxx Xxxxxxxxxx in rappresentanza di Istituto Italiano di Project Management Xxxxxxx Xxxxxxxx in rappresentanza di Istituto Italiano di Project Management Xxxxxxxx Xxxxxxxxxxx in rappresentanza di CONSIP
Xxxxxx Xxxxxx in rappresentanza di CONSIP Xxxxxxxxx Xxxxxxx in rappresentanza di CONSIP Xxxxxxx Xxxxx CNIPA
Xxxxxxx Xxxx CNIPA, consulente
Xxxxxx Xxxxxx in rappresentanza di CONSIP
Xxxxx Xxxxxxx CNIPA
Xxxxxx Xxxxx in rappresentanza di CONSIP
Xxxxx Xx Xxxxxxxx in rappresentanza di ARBEA, Agenzia della Reg. Basilicata Xxxxx Xxxxxx-Xxxxxxxx in rappresentanza di Lynkeus
Xxxx Xxxxxx in rappresentanza di TenStep Italia
Si ringraziano inoltre i componenti del gruppo di lavoro che hanno curato questa terza ver- sione del manuale che ha introdotto i temi relativi alla misura funzionale del software.
Xxxxx Xxxxx CNIPA
Xxxxxxxxx Xxxxxx in rappresentanza di CONSIP Xxxxxxxx Xxxxx in rappresentanza di GUFPI-ISMA
Xxxxx Xxxxxxx CNIPA
Xxxxxxx Xxxxx in rappresentanza di GUFPI-ISMA
Xxxxxxx Xxxxx CNIPA
Xxxxxxx Xxxx in rappresentanza di GUFPI-XXXX
Xxxxx Xxxx in rappresentanza di CONSIP
14
Dal punto di vista dello sviluppo dei contenuti particolarmente importante è stato il contri- buto offerto dalla CONSIP che ha messo ha disposizione l’esperienza maturata al proprio
G R U P P O D I L A V O R O
interno nel governo di complessi contratti inerenti forniture ICT per il Ministero dell’Econo- mia e delle Finanze. Utili sono state poi:
• la consulenza fornita dalla società TenStep Italia in tema di metodologia del project management afferente al Project management Institute (PMI);
• l’opera di revisione operata dall’Istituto Italiano di Project Management (ISIPM);
• il contributo offerto dall’associazione italiana degli utenti dei Function Point e metri- che del SW (GUFPI-ISMA) che ha messo ha disposizione l’esperienza maturata al pro- prio interno in tema di misura funzionale del software.
Come già accaduto per i precedenti Manuali che costituiscono le Linee guida, le imprese associate a AITech/Assinform afferenti alla Federazione Servizi Innovativi e Tecnologici di Confindustria ne hanno condiviso l’impostazione ed i contenuti ritenuti coerenti le proprie fattive esperienze di governo di contratti e progetti ICT.
15
3. Governare i contratti ICT
La Pubblica Amministrazione si è evoluta da tradizionale produttore di servizi pubblici a responsabile della produzione ed erogazione, da parte di fornitori privati, di una serie crescen- te di servizi, per ii quali deve essere garantito l’accesso a strati sempre più ampi della società.
Deve pertanto abbandonare il ruolo di produttore diretto, per assumere quello di regolatore
di servizi, che ha la responsabilità di:
• definire gli standard essenziali che il produttore effettivo deve rispettare;
• verificare che il servizio sia erogato alle condizioni previste, e con le modalità di tra- sparenza dei comportamenti tipiche dell’attività pubblica.
Ciò comporta, in un numero crescente di casi, la necessità che la Pubblica Amministrazio- ne, nella misura in cui non svolge più il ruolo di attore primario nell’attività di produzione, si ponga nei confronti dei Fornitori come acquirente non più di singoli beni (fattori produt- tivi che poi deve combinare), bensì di prodotti e servizi finiti.
Si rivolge infatti a soggetti, che sono privati, sia nella forma giuridica sia nei meccanismi gestio- nali, che si impegnano però a produrre cose utili per la comunità e ad accettare le regolamen- tazioni e gli standard qualitativi e di sicurezza adeguati all’importanza sociale di tali forniture.
Tale ruolo è peraltro coerente con quanto richiesto dal cittadino, che è passato da un rap- porto individuo-istituzione, di tipo giuridico-formale, ad un rapporto utente-fornitore di ser- vizi. Avendo sempre più rilievo, quindi, la soddisfazione del cliente (efficacia del servizio) ed i livelli di efficienza amministrativa.
Il maggiore grado di istruzione della popolazione, infatti, e la notevole quantità di informa- zioni (anche di provenienza estera) di cui tutti dispongono, consentono a chiunque di con- frontare la qualità dei servizi di cui usufruisce anche con le realtà di altri Paesi, agendo come stimolo al miglioramento. Miglioramento anche della competitività del sistema paese perché le aziende, dovendo ormai operare su mercati globalizzati, devono confrontarsi con- tinuamente in termini di efficienza con operatori stranieri concorrenti.
L’acquisizione di forniture ICT risponde pertanto alla necessità di commissionare i necessari potenziamenti e ammodernamenti tecnologici ed organizzativi dell’Amministrazione per l’e- spletamento delle sue funzioni nella nuova prospettiva illustrata.
Per far ciò vengono impostate iniziative progettuali a livello di pianificazione strategica ed ope- rativa nelle quali la parola “progetto” ha un’intrinseca ambiguità perché usata nel linguaggio corrente sia a livello macroscopico – strategico (es.: Progetto Certificazione della Firma Digita- le) sia a livello operativo – tecnico (es.: Progetto per la conversione di un programma informa-
tico), con conseguenti diverse relazioni (uno a molti, o viceversa) tra il livello progettuale e 17
quello contrattuale; possono cioè esistere sia progetti (di livello strategico) che danno luogo a più contratti, ovvero contratti che si attuano realizzando più progetti (di livello esecutivo).
Nel contesto di questo manuale, che ha fini puramente didattici, si considererà per semplicità un rapporto biunivoco (uno a uno) tra progetto e contratto.
In ogni caso, al termine del complesso processo di acquisizione (descritto nel Manuale applicativo “Strategie di acquisizione delle forniture ICT”), si arriva alla stipulazione di uno o più contratti ICT per la fornitura di prodotti e servizi finiti, che implicano una qualche delega operativa che l’Amministrazione concede ad uno o più Fornitori.
In generale ciò comporta per l’Amministrazione il rischio di trovarsi in una posizione di dipendenza. E’ necessario, quindi, che si faccia carico del governo del contratto per garan- tirsi un rapporto adeguato con il/i Fornitore/i.
3.1. Quadro di riferimento
Una corretta e costruttiva impostazione del governo dei contratti ICT, che di per sé è una logi- ca conseguenza della suddetta delega operativa, conduce anche ad una valutazione di quali siano i soggetti portatori di legittimi interessi nella materia regolata dai contratti stessi. In altri termini devono essere identificati ed opportunamente considerati tutti i cosiddetti stakeholders, ovvero i centri di opinione e responsabilità che hanno titolo di veder considera- to il proprio punto di vista sull’operazione: quindi non solo genericamente l’Amministrazione appaltante e il/i Fornitore/i direttamente coinvolti, ma anche specificamente tutti coloro (enti e/o persone) che sono soggetti attivi e/o passivi delle attività regolate da ciascun contratto.
Va quindi anche tenuto nella più opportuna considerazione sia il punto di vista degli uffici dell’Amministrazione esterni al controllo del contratto (Ufficio acquisti, Utenti interni, Responsabili dei processi amministrativi, Responsabile dei sistemi informativi automatizzati), sia quello degli utenti esterni (cittadini e imprese), sia quello dell’eventuale monitore ester- no e del Fornitore, come è esemplificato nella fig. 1.
18 Figura 1. Contratto ICT e stakeholders
In effetti, nel corso degli ultimi anni, grazie anche ad una serie di interventi legislativi con- nessi alla riforma della Pubblica Amministrazione, sono stati introdotti strumenti amministra- tivi innovativi, nuovi assetti organizzativi e meccanismi di controllo precisamente orientati a supportare un processo di miglioramento continuo nell’erogazione dei servizi.
Per quanto riguarda, nello specifico, i meccanismi di controllo, si è posta particolare atten- zione su quello che gli economisti chiamano controllo di gestione, sia esterno che interno. Il controllo esterno risponde all’esigenza di informazione da parte della generalità dei citta- dini sulle attività pubbliche ed è volto a far rispettare le regole, le procedure ed i vincoli che limitano le scelte degli amministratori e disciplinano i modi di porre in atto pubbliche attività.
Il controllo interno ha, invece, la prevalente finalità di verificare e/o di elevare il livello di efficienza e di efficacia raggiunto nel corso della gestione ordinaria e risponde ad esigenze di conoscenza interne ad ogni organismo produttivo che ha l’onere di realizzare gli obiettivi prestabiliti.
Tradizionalmente, nella Pubblica Amministrazione è stato privilegiato l’esercizio del control- lo esterno e si è tralasciato quello interno. Il primo è svolto da strutture specialistiche che hanno il compito di garantire la legittimità degli atti posti in essere dall’Amministrazione, mentre il secondo è esercitato all’interno dell’Amministrazione al fine di far conoscere agli organi di direzione i comportamenti operativi tenuti durante la gestione e gli effetti che questi hanno prodotto sugli obiettivi perseguiti.
In particolare, per quanto riguarda i contratti stipulati dalla PA nella materia concernente i servizi per lo sviluppo e la conduzione di sistemi informativi, la forma specifica di controllo interno è quella prevista dall’art. 13 del D.L. n. 39 del 1993 (istitutivo dell’AIPA, oggi CNIPA), il quale ha stabilito che l’esecuzione dei contratti in parola debba essere fatta oggetto di un periodico monitoraggio.
In generale, poiché, come già accennato in precedenza, la gestione del rapporto tra Ammi- nistrazione e Fornitore è fortemente condizionata dal rischio per l’Amministrazione di tro- varsi in una posizione di dipendenza, l’azione di governo del contratto deve garantire un rapporto paritetico.
Questo può essere facilitato, garantendo la trasparenza e la tracciabilità delle attività esple- tate dal Fornitore, mediante l’accesso da parte dell’Amministrazione al sistema produttivo utilizzato dal Fornitore medesimo. Nel linguaggio e nel senso definito dalla norma UNI EN ISO 9001: 2000 sulla qualità, garantendo all’Amministrazione l’accesso al sistema qualità ed alle registrazioni di qualità del Fornitore.
19
Sulla base di questo presupposto, governare il contratto significa per l’Amministrazione attuare un’attenta azione di Direzione Lavori, effettuare il monitoraggio continuo dei servizi erogati dal Fornitore e valutare periodicamente il livello di soddisfazione degli utenti finali dei servizi. Tutto ciò facilita la valutazione preventiva di possibili elementi di rischio, il rispetto dei tempi e dei costi previsti, il mantenimento dei livelli di servizio ed il raggiungi- mento degli obiettivi stabiliti.
A tal fine occorre fare riferimento sia all’oggetto della fornitura (bene o servizio), sia alle modalità con cui la fornitura viene realizzata e consegnata.
Nel primo caso ci si riferisce, per esempio, al profilo di qualità richiesto per un prodotto, ai suoi requisiti tecnici e funzionali contrattualmente stabiliti, oppure, nel caso di servizi, ai livelli di servizio fissati contrattualmente e misurati da specifici indicatori di qualità.
Riguardo alle modalità di erogazione della fornitura, gli elementi caratteristici riguardano i tempi di realizzazione e consegna (stati di avanzamento), la qualità dei processi produttivi e la gestione dei rischi.
Il controllo sul prodotto oggetto della fornitura deve essere svolto a monte dei collaudi su campioni o lotti di fornitura ed ha lo scopo di anticipare, rispetto al collaudo finale, l’even- tuale rilevazione di difformità, permettendo così al Fornitore di intervenire sul ciclo produt- tivo ed evitare il problema sul resto della fornitura.
Il controllo sulle modalità di erogazione del servizio consente invece di individuare situa- zioni potenzialmente critiche sulla qualità (con particolare riguardo alle conseguenze sugli utenti finali), sulle scadenze di consegna o sui costi, che potrebbero richiedere l’adozione di interventi preventivi finalizzati a mitigare i rischi individuati.
3.1.1. ATTIVITÀ
Una puntuale ed attenta azione di governo, effettuata durante tutto il ciclo di vita della for- nitura, rappresenta un atto di maturità dell’Amministrazione che, in questo modo, esprime la volontà di partecipare attivamente al proprio processo di informatizzazione. Ciò avviene sia definendo i requisiti e gli obiettivi del contratto da sottoporre a governo, sia controllan- do l’esecuzione del contratto dotandosi degli strumenti operativi idonei a verificare che le esigenze contrattualmente espresse siano soddisfatte nel migliore dei modi possibili.
Il governo del contratto comprende, quindi, lo svolgimento di attività di pianificazione, di controllo, di valutazione dei risultati, nonché la definizione e applicazione di azioni corretti- ve. Queste attività coinvolgono naturalmente i soggetti che operano direttamente (a monte e a valle) sulla fornitura (fornitore, committente, monitore, utente finale) e, quando si tratta di progetti / servizi segmentati su diversi contratti, anche i fornitori vincolati da altri contratti che devono essere coordinati da una struttura che ha il controllo del progetto / servizio nella sua interezza (v. più avanti §3.1.5). Ne consegue pertanto la necessità di una sinergia tra tali soggetti, nel rispetto delle competenze che devono essere chiaramente definite.
Per chiarire l’insieme di tali complesse attività si può far riferimento a ciò che, da molto tempo, nel mondo delle organizzazioni, sia pubbliche sia private, è individuato con i termi- ni Governance e Project Management (PM).
In realtà di governance si parla prevalentemente in contesti di alto livello (come nel caso della Corporate Governance), mentre il PM è utilizzato (con maggiore frequenza) in contesti manageriali a contenuto tecnico, dove è inteso anche come Project Governance.
In ogni caso entrambi gli argomenti restano praticamente confinati all’interno dell’orizzonte di una singola organizzazione e non vengono quasi mai applicati a relazioni con più sog- getti, qual è tipicamente il caso di un rapporto contrattuale.
20
Inquadrandoli invece nell’ambito specifico del governo dei contratti ICT, si può osservare che a partire da un contesto strategico e progettuale (Governance) si procede alla definizio- ne contrattuale, e infine si arriva, in sede di esecuzione, alla fase di PM.
In conseguenza di quanto esposto, il concetto di governo dei contratti ICT è un termine onnicomprensivo che include e si scompone in diverse azioni di governo che riguardano la responsabilità dell’Amministrazione e del Fornitore che possono riassumersi come riportato nella fig. 2.
Governance
PM
Dal Progetto
Al Contratto
Amministrazione | Fornitore |
• Direzione lavori | Project Management (Predisposizione SAL, eventualmente in con- tatto con il Monitore) |
• Pianificazione | |
• Controllo e verifica |
Figura 2. Governo del contratto, governance e PM
Dette azioni servono a supportare il Responsabile dei sistemi informativi automatizzati dell’Amministrazione (funzione prevista dall’art. 10, comma 1, del D.L. 3 febbraio 1993, n. 39) nell’identificazione delle possibili fonti di finanziamento, nella valutazione degli impatti di tipo economico ed organizzativo, nel controllo dell’avanzamento dei progetti e nel moni- toraggio dei livelli di servizio.
La Direzione Lavori
La Direzione Lavori è un compito dell’Amministrazione, normalmente svolto dal Responsa- bile del contratto o da un suo collaboratore, con il quale la stessa Amministrazione da un lato controlla il positivo andamento dei lavori secondo i patti contrattuali e dall’altro si tiene a disposizione del Fornitore per la necessaria cooperazione tra appaltante e appaltatore nella esecuzione dei lavori.
21
In alternativa il servizio può essere affidato ad una società specializzata, inclusa nell’elenco pre- disposto dal CNIPA ai sensi dell’art. 13 del D. Lgs. 39/93, che non risulti collegata con le impre- se parti dei contratti oggetto del servizio, ai sensi dell’art. 7 della legge 10 ottobre 1990, n. 287.
La Direzione Lavori deve essere intesa in ogni caso come attività di interlocuzione con il Project Management di pertinenza del Fornitore, cioè come capacità di segmentazione dei progetti, di definizione degli obiettivi contrattuali, di pianificazione e controllo di tempi, costi, risorse utilizzate e risultati ottenuti, di sintesi e reporting.
La Direzione Lavori comprende perciò funzioni di:
• gestione delle attività, che consiste nel verificare la disponibilità della documentazione e della pianificazione di dettaglio, consuntivare le attività, verificare l’effettiva eroga- zione dei servizi e dei prodotti, gestire i rischi di propria competenza, valutare lo stato di avanzamento dei lavori e analizzare gli scostamenti rispetto ad obiettivi, tempi, costi e utilizzazione di risorse;
• gestione delle eventuali varianti in corso d’opera, che consiste : nell’ identificazione delle cause, che le rendano necessarie, nella valutazione tecnica ed economica delle varianti proposte dal Fornitore, nella revisione dei documenti contrattuali a seguito della loro accettazione. L’esigenza di varianti può nascere da diverse motivazioni, endogene ed esogene al contratto, quali possono essere le variazioni funzionali e architetturali di componenti, le variazioni dei requisiti, la sicurezza, l’evoluzione della tecnologia, l’adeguamento a nuove normative, la riallocazione di risorse professionali, le variazioni di priorità tra sottoprogetti o la variazione dei piani operativi;
• controllo degli adempimenti e dei livelli di qualità contrattualmente previsti, effettuato mediante la verifica dell’accuratezza e della validità delle misure prodotte dal Fornito- re, la rappresentazione e l’interpretazione delle misurazioni effettuate;
• valutazione della soddisfazione degli utenti finali interni all’Amministrazione relativa- mente a beni e servizi contrattualmente dovuti;
• gestione delle eventuali non conformità rispetto alle prestazioni previste nel contratto (costi, tempi, quantità e qualità di prodotti e servizi) attraverso l’identificazione delle cause della non conformità - che può richiedere l’accesso ai processi produttivi messi in atto dal Fornitore - l’identificazione degli interventi, da effettuarsi da parte dell’Am- ministrazione e/o del Fornitore, ritenuti opportuni per sanare la non conformità e controllo della loro attuazione e verifica degli esiti.
• in relazione anche ai punti precedenti, approvazione della fatturazione predisposta dal Fornitore e gestione di eventuali penalizzazioni.
Pianificazione
Analogamente a quanto accennato in precedenza in relazione al termine progetto, anche l’attività di pianificazione può avere diversi significati in funzione del livello di governance al quale ci si riferisce.
Ad alto livello la pianificazione strategica riguarda certamente attività diverse dal contesto di governo del contratto al quale si fa riferimento nel presente manuale.
22
Per quanto riguarda l’ambito di governo del contratto, la pianificazione rappresenta il proces- so preliminare per la definizione delle attività operative necessarie per il raggiungimento degli obiettivi del progetto espressi nei documenti contrattuali tenendo conto dei vincoli esistenti.
La stesura dei documenti di pianificazione esecutiva (piano di progetto, piano di qualità) è
una responsabilità del Fornitore (come sarà illustrato nel successivo §4), ma ciò è possibile come conseguenza di una pianificazione preliminare, di competenza dell’Amministrazione, che porti all’identificazione degli obiettivi del progetto quanto più specifici e dettagliati, attraverso l’opportuna documentazione contrattuale (contratto, capitolato tecnico, ecc.). Questo aspetto riveste una particolare importanza, in quanto sovente le Amministrazioni tendono ad indicare le finalità del progetto in maniera piuttosto generica.
In sostanza, tale pianificazione preliminare ha lo scopo di assicurare che ogni azione neces- saria al conseguimento degli obiettivi venga prevista, definita, correlata con le altre, quotata in termini di costo e valutata in termini di rischio nella pianificazione esecutiva.
Pertanto, la pianificazione di un progetto è di fondamentale importanza sia per l’Ammini- strazione, perché esplicita le scadenze previste (milestone) e le consente di esercitare il con- trollo sull’andamento del progetto, sia per il Fornitore, perché prevede le aree di criticità e di rischio, consentendo il coordinamento delle risorse e l’ottimizzazione dei costi. La pianifi- cazione di progetto, realizzata in conformità ai vincoli esplicitati nel capitolato di appalto, una volta approvata, costituisce la baseline per l’esecuzione ed il controllo del progetto.
Poiché in sede di offerta il Fornitore si limita a rispondere a quanto richiesto nel Capitolato tecnico, la stesura di quest’ultimo rappresenta una delle fasi più rilevanti dell’intero proces- so di acquisto poiché consente di impostare una strategia di pianificazione e di controllo del rapporto, non unicamente condizionata dal prezzo della fornitura.
In realtà, nel passato tale strumento è stato, spesso, oggetto di equivoci che hanno riguardato:
• la sua predisposizione, molto spesso poco attenta alle leve gestionali che possono essere “innestate” al fine di creare coerenza fra funzioni, ruoli e strumenti innovativi e gestionali;
• la sua applicazione nelle diverse realtà della Pubblica Amministrazione dove in effetti il Capitolato tecnico è stato considerato, in molti casi, come uno strumento standard poco contestualizzato al concreto oggetto dello scambio economico, nonostante la sua natura giuridica di capitolato speciale e non generale.
In sostanza il Capitolato tecnico ha la funzione precipua di predeterminare il contenuto del contratto da stipulare in senso conforme agli interessi dell’Amministrazione. Perciò è orien- tato alla regolazione dell’assetto degli interessi conseguenti alla stipula contrattuale e, sul piano procedimentale, mira a rendere consapevoli le imprese di ciò in cui saranno coinvol- te con la partecipazione alle procedure concorsuali. In tal senso costituisce il primo e più importante strumento di governo del contratto.
Infatti il Capitolato tecnico è uno dei due principali allegati tecnici del contratto (l’altro è l’offerta) e definisce le caratteristiche tecniche delle forniture o dei servizi oggetto della gara, rispetto alle quali le imprese concorrenti predispongono la loro offerta tecnica. Per questo la presenza di omissioni, imprecisioni od errori nelle indicazioni fornite, può com- portare sia la presentazione di offerte difficilmente comparabili, con conseguenti difficoltà in sede di aggiudicazione, sia la nascita di contenziosi interpretativi in sede di esecuzione.
Ne consegue l’opportunità che il Capitolato tecnico:
23
• descriva accuratamente i requisiti funzionali, tecnici, temporali ed organizzativi della prestazione, definendo la quantità e qualità dei beni e/o dei servizi informatici richie-
sti ed i livelli di servizio attesi con le relative modalità tecniche ed organizzative di misurazione;
• richiami le norme e gli standard tecnici di riferimento ed espliciti la tipologia, la strut- tura, i contenuti, della documentazione richiesta relativa ai beni e/o servizi oggetto del contratto;
• preveda le modalità di esecuzione del contratto sotto il profilo temporale ed organiz- zativo evidenziando, ad esempio, i requisiti di sicurezza e regolamentando il rapporto tra l’Amministrazione ed il Fornitore in termini di attività e responsabilità attribuite alle parti. In particolare debbono essere previste:
• le procedure per la notifica e la gestione di eventi non prevedibili;
• le modalità di avviamento all’esercizio delle soluzioni fornite ed i fabbisogni di for- mazione del personale;
• le prescrizioni relative alla manutenzione ed alla garanzia;
• le modalità tecniche ed organizzative del monitoraggio del contratto e del collaudo ed accettazione di forniture e servizi;
• le eventuali modalità periodiche di rinegoziazione dei livelli di servizio, ridefinizione del volume delle forniture, verifica dell’aggiornamento delle tecnologie utilizzate.
• indichi sia gli argomenti che il fornitore deve trattare in sede di offerta (indice dell’of- ferta tecnica), sia le modalità di esposizione del dettaglio dei costi da inserire nell’of- ferta economica;
• preveda che, ove possibile, l’offerta sia integrata dalla prima versione (soggetta a suc- cessive revisioni per tutta la durata del progetto) di due documenti autonomi che ne costituiscono allegati e che conseguentemente divengono allegati contrattuali a tutti gli effetti: il piano di progetto ed il piano della qualità.
• il piano di progetto riassume gli obiettivi contrattuali identificando le tappe fonda- mentali del progetto e, in relazione ad esse, gli obiettivi da raggiungere, le attività principali, i prodotti contrattualmente attesi, gli impegni di risorse, tecnologiche e umane, la gestione della comunicazione e dei rischi, i tempi di massima di attuazione del contratto.
• il piano di qualità fornisce lo strumento per specificare i requisiti specifici dei servizi contrattualmente richiesti, con le procedure generali del sistema qualità del fornitore già esistenti. Per far questo deve:
• esplicitare le disposizioni organizzative e metodologiche adottate dal Fornitore allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;
• dettagliare i metodi di lavoro xxxxx in atto dal Fornitore, facendo riferimento o a pro- cedure relative al proprio sistema, e per ciò descritte nel manuale qualità, o a proce- dure sviluppate per lo specifico contratto, a supporto delle attività in esso descritte;
24
• supportare il corretto e razionale evolversi delle attività contrattualmente previste, nonché assicurare la trasparenza e la tracciabilità di tutte le azioni messe in atto dalle parti in causa.
Le modalità di controllo e verifica delle prestazioni, per quanto riguarda la consegna delle forniture e l’esecuzione dei servizi, assumono all’interno del contratto le due accezioni di controllo di prodotto o controllo della qualità, ed controllo di processo o assicurazione della qualità.
Il controllo di prodotto è rappresentato dalla regolamentazione dell’esecuzione dei collaudi e delle verifiche, rispettivamente riferibili alla fornitura di beni e all’erogazione di servizi, finalizzati all’accettazione formale delle forniture ed all’esame periodico delle prestazioni di servizio rese dal fornitore.
Il controllo di processo si lega alla previsione di monitoraggio che, come azione continua e parallela all’esecuzione del contratto a supporto della Direzione Lavori, tiene sotto controllo:
• le modalità di conduzione del contratto e lo stato avanzamento lavori;
• la quantità e la qualità dei beni forniti e dei servizi erogati ed i livelli di servizio;
• i processi messi in atto dal fornitore per l’erogazione dei servizi;
• l’analisi dei risultati effettivamente ottenuti, da rapportare agli investimenti effettuati.
Il collaudo è finalizzato a verificare che i beni e servizi ICT forniti siano conformi a quanto descritto nel contratto o nei suoi allegati e che siano in grado di svolgere le funzioni richie- ste. Le operazioni di collaudo sono destinate a consentire la verifica da parte dell’Ammini- strazione dell’esatto e completo adempimento da parte del Fornitore di quanto oggetto del contratto.
Il collaudo, in particolare in progetti ICT particolarmente complessi, dovrebbe solitamente essere effettuato, alla presenza di incaricati del Fornitore, dal committente. La realizzazione del collaudo da parte del committente è dettata da due fondamentali ragioni : la prima deri- va dal fatto che egli stesso ha seguito l’intero progetto e di conseguenza ne conosce bene il funzionamento, la seconda è che il committente (in particolar modo l’utente che ha attiva- mente fornito il proprio contribuito nella fase di analisi dei requisiti), ha la necessaria chia- rezza sugli obiettivi e sui risultati che si vogliono conseguire. Solo nell’eventualità di conte- stazioni con il fornitore andrebbe coinvolta una terza parte.
A cura della commissione di collaudo viene redatto un verbale, controfirmato dagli incari- cati del Fornitore nel quale vengono descritte le operazioni di verifica effettuate. Quando il collaudo risulti negativo, in quanto non vengono superate le prescritte prove, le operazioni di collaudo vengono ripetute con le stesse condizioni e modalità, entro un determinato ter- mine, fissato contrattualmente. In caso di ulteriore esito negativo può essere attivata una procedura di penalizzazione che deve essere contrattualmente prevista e che, secondo una gradualità di sanzioni, può anche arrivare alla risoluzione del contratto per inadempienza.
Nel caso di fornitura di beni il collaudo dovrebbe riguardare la totalità delle apparecchiatu- re oggetto del contratto. Tuttavia, in presenza di forniture contraddistinte da un elevato numero di apparecchiature dello stesso tipo, è possibile prevedere collaudi a campione.
25
In caso di contratti relativi a prestazioni di servizi ICT, come nei contratti di outsourcing, le operazioni di verifica ed accettazione delle prestazioni rese sono necessariamente rapporta- te alla natura della prestazione stessa. Per questo le verifiche potranno comportare sia l’ana- lisi da parte dell’Amministrazione dei rapporti periodici prodotti dal Fornitore e contenenti
la quantità e qualità delle risorse effettivamente impegnate, sia l’utilizzazione di strumenti di verifica diretta della prestazione e della sua efficienza ed efficacia, mediante la misurazione dei livelli di servizio contrattualmente previsti (Service Level Agreement - SLA).
Anche per quanto riguarda la prestazione di servizi si possono prevedere delle verifiche a campione delle prestazioni erogate, nei casi ove un collaudo esaustivo su tutte le istanze dei servizi resi risulti particolarmente laborioso od oneroso.
Relativamente agli aspetti della qualità, le forniture possono essere valutate oggettivamente attraverso la misura di specifici indicatori di qualità. Il problema è quello di selezionare un insieme di indicatori (Key Performance Indicators - KPI), da utilizzare come parametri valutativi del grado di conseguimento dell’obiettivo. In particolare, però, deve essere sottolineato che:
• non tutti gli indicatori generalmente considerati si correlano direttamente agli obiettivi (si tratta di indicatori mediati o indiretti);
• se è vero che più sono gli indicatori più saranno le informazioni disponibili per una esauriente panoramica dei risultati ottenuti, è anche vero che i costi di valutazione della qualità della fornitura lievitano in funzione del numero degli indicatori stessi.
La migliore soluzione sarebbe la previsione contrattuale di pochi indicatori con il massimo grado di significatività per l’efficienza / efficacia dell’attività o del servizio.
Alcune fondamentali regole dovrebbero orientare il comportamento del committente:
• principio di selettività e di pertinenza: si deve disporre di limitate ma significative informazioni da seguire costantemente per focalizzare l’attenzione sui fenomeni rile- vanti dai quali dipende la riuscita dell’operazione di governo del contratto
• principio di tempestività: esso permette di controllare il tempo fra la manifestazione di un evento anomalo significativo e la disponibilità dell’informazione per l’attuazione dei necessari feedback per il ripristino del rispetto delle disposizioni contrattuali.
Project management (Fornitore)
Indipendentemente dal Project Management che il Fornitore può adottare internamente all’organizzazione dei suoi processi produttivi, lo scopo dell’attività di Project Management nello specifico del governo dei contratti ICT è di supportare l’Amministrazione assicurando l’adeguata capacità di governo del contratto. Essa comprende perciò le stesse funzioni già trattate in relazione all’attività di Direzione Lavori dell’Amministrazione, ma riferite a quanto di pertinenza del Fornitore:
• gestione delle attività, che consiste nel rendere disponibile la documentazione e la pianificazione di dettaglio, consuntivare le attività, verificare l’effettiva erogazione di servizi e dei prodotti, gestire i rischi di propria competenza, valutare lo stato di avan- zamento dei lavori e analizzare gli scostamenti rispetto ad obiettivi, tempi, costi e uti- lizzazione di risorse;
• proposta delle eventuali varianti in corso d’opera;
26
• monitoraggio degli adempimenti e dei livelli di qualità contrattualmente previsti;
• gestione delle eventuali non conformità rispetto alle prestazioni previste nel contratto (costi, tempi, quantità e qualità di prodotti e servizi) attraverso l’identificazione delle
cause della non conformità e degli interventi ritenuti opportuni per sanare la non conformità, controllo della loro attuazione e verifica degli esiti;
• assistenza al collaudo che consiste nel fornire supporto nella verifica della conformità dei prodotti consegnati ai requisiti contrattuali. Per ogni bene / servizio da collaudare il Fornitore avrà il compito di specificare nel dettaglio i requisiti funzionali e di qua- lità, e per questi ultimi, i valori di soglia previsti dagli atti contrattuali e le metriche da adottare. È richiesta infine la collaborazione con la commissione di collaudo per defi- nire la schedulazione dei collaudi parziali, per eseguire le misure degli indicatori di qualità proposti e per verificare le funzionalità mediante i casi di test.
3.1.2. Attori ed organizzazione
In relazione agli orizzonti strategico, progettuale ed esecutivo accennati nel §3.1.1, inquadrati nell’ambito specifico del governo dei contratti ICT, si può osservare la corrispondenza necessa- ria, da un punto di vista organizzativo, tra l’organizzazione dell’Amministrazione e quella del Fornitore per una corretta interlocuzione tra gli attori impegnati nel governo dei contratti ICT. Esiste pertanto il livello funzionale strategico (Governance), competente per le strategie e le decisioni di alto livello, sia per l’Amministrazione, sia per l’eventuale Monitore esterno, sia per il Fornitore. Il livello funzionale di Project Management corrisponde invece alle respon- sabilità specifiche del governo del contratto su tutti e tre i fronti.
Per quanto riguarda esplicitamente gli attori coinvolti nel processo di governo del contratto, anche nel caso più generale, relativo ad una fornitura complessa (Progetto) suddivisa in una molteplicità di contratti, l’Amministrazione deve assicurare la presenza di un Responsabile del Contratto e degli utenti interessati per ciascun contratto. Inoltre, quando le attività di monitoraggio non siano gestite all’interno dell’Amministrazione, sarà presente un ente di monitoraggio (Monitore esterno). In particolare, per tutti i contratti che presentano criticità legate non solo alla dimensione della fornitura, ma anche all’importanza che essa riveste nel migliorare i servizi resi dall’amministrazione, alla complessità tecnologica e all’innovatività delle soluzioni, che tipicamente porta con sé sempre importanti elementi di rischio.
Il Responsabile del Contratto deve operare affinché il risultato finale sia realizzato in coe- renza con i costi, i tempi e le caratteristiche tecniche definite contrattualmente. Per fare ciò assicura la capacità di Direzione Lavori, e si avvale delle risorse organizzative disponibili.
Questa responsabilità si assolve attraverso un’opera di integrazione e di coordinamento degli sforzi di tutti coloro che partecipano al progetto e in particolare attraverso la gestione delle interfacce, cioè di tutti quei punti di interazione tra attori e tra fattori significativi per lo svolgimento del progetto.
Nel far questo deve:
• verificare lo stato di avanzamento dei lavori, valutare le possibili criticità ed eventual- mente richiedere l’adozione di azioni correttive al Fornitore;
• accertare la puntuale consegna dei prodotti contrattualmente dovuti, controllando il rispetto dei vincoli contrattuali (tempi, costi, qualità, livelli di servizio);
27
• alimentare il controllo di gestione interno svolto dalla funzione Pianificazione e con- trollo con le informazioni a consuntivo di competenza;
• coordinare e controllare le attività di competenza dell’Amministrazione (approvazione documenti, verifiche intermedie, collaudi, monitoraggio), perseguendo l’obiettivo che siano completate nei tempi, nei costi e nei requisiti di qualità pianificati;
• proporre varianti di progetto / servizio a fronte di esigenze emerse nelle attività di esecuzione;
• gestire i rapporti con il Fornitore, interloquendo con il suo corrispondente Responsa- bile del Contratto per il Fornitore, sia dal punto di vista operativo, sia in relazione al pagamento dei corrispettivi e all’applicazione delle penali.
Per il monitore esterno (se presente) il Direttore Tecnico del Monitoraggio ha come interlocutore il Responsabile del Contratto dell’Amministrazione al quale trasmette, per le valutazioni di competenza e l’avvio delle azioni ritenute necessarie, la documentazione rela- tiva alle attività di monitoraggio o verifica ex post dei contratti ICT.
In ogni caso l’attività svolta dal Monitore non si sostituisce alle funzioni di Direzione Lavori dell’Amministrazione, né alle funzioni di controllo interno del Fornitore (Assicurazione qua- lità e controlli qualità previsti dal ciclo di vita del Fornitore stesso.
Essa integra le capacità di governo del contratto da parte del Committente, attraverso verifi- che ed analisi di particolare profondità e complessità tecnica effettuate da una terza parte su incarico del Committente stesso, per rilevare eventuali scostamenti dagli obiettivi contrat- tuali, collaborando alla risoluzione delle criticità anche con proposte di azioni correttive e seguendone l’eventuale applicazione.
Da un punto di vista operativo la figura 3 riporta le corrispondenze dei vari attori del governo del contratto per le necessarie interlocuzioni ai diversi livelli funzionali
Livelli funzionali | Amministrazione | Monitore esterno (SE PRESENTE) | Fornitore | |
Governance | Responsabile Sistemi Informativi Automatizzati | Responsabile Procedimenti Amministrativi | Responsabile commerciale | Responsabile commerciale |
° ° ° ° ° ° ° ° | ||||
Project Management | Responsabile del contratto | Responsabile Utenti | Direttore Tecnico del Monitoraggio | Responsabile del contratto per il fornitore |
Esecuzione | Gruppo di governo del contratto | Gruppo di utenti | Gruppo di Monitoraggio | Gruppo esecutivo |
28 Figura 3. Interlocutori per il governo del contratto
3.1.3. Competenze
Quando esista una unità organizzativa impegnata in attività di governo dei contratti ICT o qualora le attività di monitoraggio vengano espletate all’interno dell’Amministrazione, le competenze che devono essere possedute sono riferibili ai seguenti temi:
• contrattualistica informatica,
• competenza sugli aspetti normativi ed operativi relativi al contratto di servizio ed all’appalto pubblico di servizi;
• esperienza nella stesura di contratti per la fornitura di servizi ICT fondati sull’uso dei livelli di servizio;
• esperienza nella partecipazione a commissioni di aggiudicazione per l’appalto di servizi ICT;
• analisi organizzativa,
• competenza sulle metodologie orientate ai processi per la modellizzazione, rappre- sentazione, ingegnerizzazione, di processi produttivi afferenti ai compiti istituziona- li delle Amministrazioni ed al disegno dei relativi sistemi informativi automatizzati di supporto;
• esperienza di progettazione ed assessment dei processi amministrativi;
• gestione dei progetti,
• competenza nella scomposizione funzionale e segmentazione di progetti e nella definizione degli obiettivi contrattuali;
• esperienza di pianificazione e controllo di tempi, costi, risorse utilizzate e risultati ottenuti;
• capacità di sintesi e produzione della documentazione di supporto alla gestione delle attività ed alla valutazione dello stato avanzamento lavori;
• assicurazione della qualità,
• conoscenza delle norme ISO 9000 e del sistema qualità italiano ed europeo;
• quadri di riferimento per la governance dei sistemi informativi; a titolo esemplifica- tivo si può far riferimento al COBIT, che è una metodologia utilizzata per l’imple- mentazione ed il miglioramento dell’IT Governance aziendale (governo delle strut- ture organizzative e dei processi che assicurano lo sviluppo dell’information tech- nology, finalizzato a raggiungere gli obiettivi aziendali)
• esperienza di verifiche ispettive sui processi produttivi afferenti ai servizi ICT, di collaudi di beni e servizi ICT, di sistemi informativi automatizzati;
• esperienza di assessment di progetti ICT, check-up e benchmark dei sistemi infor- mativi;
• ingegneria del software,
29
• conoscenza dei cicli di vita del software e degli attributi di qualità del software; esperienza nell’uso delle metodologie e degli strumenti CASE per l’analisi, la codifi- ca ed il test;
• competenza nella stima e dimensionamento di progetti di sviluppo e manutenzio- ne di applicazioni software;
• tecnologie informatiche e delle telecomunicazioni,
• conoscenza dei principali Fornitori, prodotti, architetture, tecnologie, metodologie, tendenze, afferenti ai settori dell’informatica e delle telecomunicazioni.
3.1.4. Flussi informativi
Nell’ambito delle attività di governo dei contratti ICT tra i diversi attori ci sono vari flussi informativi che si concretano nello scambio di comunicazioni formali / informali, periodi- che / estemporanee, una tantum / sistematiche.
Sui numerosi documenti formali, che hanno rilevanza ai fini contrattuali, le responsabilità sono diverse, come risulta dalla tabella 1, che ha, peraltro, solo un valore esemplificativo.
I contenuti schematici di tali documenti sono elencati di seguito.
Attori Documenti | Fornitore: Responsabile DEL CONTRATTO | Amministrazione: Responsabile Utenti | Amministrazione: Responsabile del contratto | Monitore esterno: Direttore tecnico del monitoraggio |
1 Specifiche dei requisiti | Viene informato | Xxxxxx | Xxxxxxx | |
2 Specifiche FUNZIONALI / TECNICHE | Emette | Partecipa all’approvazione | Approva | Controlla |
3 Piano di progetto | Emette | Viene informato | Approva | Controlla |
4 Piano di qualità | Emette | Viene informato | Approva | Controlla |
5 Piano di gestione dei rischi | Viene informato | Viene informato | Emette | Controlla |
6 Stato avanzamento lavori (SAL) | Emette | Approva | Controlla | |
Viene informato | Viene informato | Xxxxxx | Xxxxxxxxx all’emissione | |
8 Analisi della soddisfazione dell’utenza | Emette | Partecipa | Approva | Controlla |
9 Livelli di servizio rilevati | Emette | Viene informato | Approva | Controlla |
10 Verbale di collaudo | Viene informato | Viene informato | Xxxxxx | Viene informato |
11 Gestione modifica contenuto di progetto | Emette | Viene informato | Approva | Controlla |
12 Fatturazione | Emette | Approva | Controlla |
30 Tabella 1. Matrice delle responsabilità per i principali flussi di comunicazione per il Governo dei contratti
Contenuto dei principali flussi informativi
1. Specifiche dei requisiti. I requisiti rappresentano le caratteristiche generali che il pro- dotto / servizio richiesto deve possedere, coerentemente con il contenuto dei documenti contrattuali. Essi sono rappresentati in un documento contenente, prima di tutto, una descrizione in linguaggio naturale, con eventuale supporto di grafica e diagrammi (usando, a titolo di esempio, il linguaggio di modellazione standard UML), dei servizi che il sistema in oggetto deve fornire, insieme ai vincoli da rispettare sia in fase di sviluppo che durante l’operatività; poi l’insieme delle specifiche di dettaglio, in forma più strutturata e contrattua- lizzabile (sono un modello astratto del funzionamento del sistema).
L’analisi dei requisiti contiene, ad esempio nel caso di fornitura di software:
• le specifiche funzionali e prestazionali, propedeutiche alla fase di approfondimento di competenza del fornitore di cui al punto successivo, incluse le caratteristiche dell’am- biente nel quale il software deve operare;
• le caratteristiche delle interfacce;
• le condizioni per la qualificazione del software;
• i vincoli riguardanti la sicurezza logica, inclusa quella dei dati trattati secondo quanto specificato dalle norme ISO 17799 in materia di sicurezza dei sistemi informativi;
• le specifiche ergonomiche ed i vincoli di usabilità riguardanti le modalità di interazio- ne uomo macchina;
• l’identificazione dei dati da trattare;
• i requisiti per l’installazione e l’accettazione;
• la documentazione per l’utilizzo da parte degli utenti (il manuale utente);
• i requisiti di gestione e manutenzione del prodotto.
Il documento di specifiche dei requisiti deve essere caratterizzato da:
• correttezza: deve descrivere esattamente ciò che intende rappresentare;
• non ambiguità: le specifiche non devono essere interpretabili in diverse maniere;
• completezza: deve includere la descrizione di tutto ciò che serve descrivere;
• completezza interna: ogni termine o notazione introdotti devono essere descritti;
• consistenza: non ci devono essere conflitti o contraddizioni nelle descrizioni;
• stabilità: non deve essere soggetto a continue modifiche;
• verificabilità: deve essere possibile misurarne le caratteristiche di qualità;
• modificabilità: deve poter essere modificato, se necessario, con facilità; conservando le versioni precedenti del documento ed annotando i cambiamenti apportati;
• tracciabilità: deve corrispondere a specifiche esigenze, problemi, elementi dei domini analizzati.
31
2. Specifiche funzionali / tecniche. Questi documenti, realizzati dal fornitore e derivanti dalle specifiche dei requisiti riportate al punto 1, richiedono per la loro realizzazione, una attività di analisi maggiormente approfondita. Infatti i requisiti emessi inizialmente dal com-
mittente, non sono sufficientemente dettagliati da consentire al fornitore di soddisfarli senza una ulteriore fase di analisi che ne definisca completamente tutte le caratteristiche. Dopo aver definito il modello di riferimento, che descrive l’Amministrazione da informatizzare, si dovrà tradurre i requisiti posti dal committente dettagliando il “che cosa”, producendo le specifiche funzionali, e il “come” producendo le specifiche di realizzazione.
• Il modello di riferimento descrive in modo formale ed integrato l’organizzazione, oggetto di analisi, come gli scopi che intende perseguire in un determinato contesto, prescindendo da considerazioni di carattere tecnologico o inerenti una particolare soluzione applicativa.
L’oggetto di analisi riguarda detta organizzazione vista come l’insieme delle funzioni svolte per il conseguimento degli obiettivi assegnati; le unità organizzative implicate nell’esecuzio- ne dei compiti; i flussi informativi che queste si scambiano per lo svolgimento delle attività di competenza; l’insieme delle informazioni scambiate dal sistema con l’ambiente esterno.
• Le specifiche funzionali descrivono al massimo grado di dettaglio, il comportamento dell’organizzazione oggetto di analisi rappresentata dal modello di riferimento, indivi- duando le modalità di interazione tra il sistema informativo proposto e l’utente, ovve- ro ciò che il sistema informativo deve fare per soddisfare i requisiti dell’utente.
• Le specifiche di realizzazione definiscono sulla base delle scelte tecnologiche ed orga- nizzative, le modalità di realizzazione degli strumenti informatici atti a supportare le componenti funzionali e informative, individuate nella fase di progettazione dell’archi- tettura dell’organizzazione, oggetto del processo di automazione.
3. Piano di progetto. Il documento contiene le informazioni utili per la pianificazione, l’e- secuzione ed il controllo di tutte le attività necessarie per la realizzazione del progetto. Gli elementi informativi che deve contenere riguardano:
• l’organizzazione del progetto: sono riportate le singole attività ed i passaggi basilari nella conduzione del progetto, l’organigramma (struttura organizzativa), i contatti e le interfacce tra le organizzazioni coinvolte nel progetto, ossia quelle dell’Amministrazio- ne, del Fornitore (contatti ed interfacce), ed i responsabili delle principali attività (responsabilità nel progetto);
• il processo gestionale: sono descritti gli aspetti tipici di gestione del progetto, cioè gli obiettivi e le priorità nella gestione, i presupposti, le dipendenze ed i vincoli, la gestione dei rischi, i meccanismi di osservazione e controllo, la pianificazione delle risorse;
• il processo tecnico: sono illustrati gli aspetti tecnici del progetto quali i metodi, gli strumenti e le tecniche, la documentazione di prodotto / servizio, le funzioni di sup- porto;
32
• la suddivisione e tempificazione del lavoro: sono individuate attività e compiti, le interdipendenze tra le attività, le risorse stimate, le tempificazioni previste per il pro- getto a livello di singole attività.
Per un esempio di tale rapporto si faccia riferimento al § 6.1.1
4. Piano di qualità. Costituisce il documento di riscontro per la valutazione della qualità del prodotto / servizio, rispetto al quale valutare il livello qualitativo dei beni e servizi forniti, in tutte le fasi del ciclo di vita della fornitura e su tutti i prodotti intermedi delle fasi, anche in riferimento alle effettive esigenze dell’utenza (interna / esterna, intermedia
/ finale).
Tale documento deve:
• definire gli obiettivi qualitativi del progetto, espressi in forma di proprietà misurabili associate alle caratteristiche qualitative desiderate, con i relativi valori di soglia;
• definire la rilevanza degli obiettivi qualitativi nel contesto progettuale ed il peso delle eventuali correzioni da apportare per correggere risultati non in linea con le aspettati- ve (necessario per i criteri di accettazione);
• stabilire tempi, metodi, tecniche e risorse per la valutazione del livello di possesso di queste caratteristiche nei milestones o nei prodotti finiti;
• stabilire le responsabilità per le valutazioni;
• individuare le norme di riferimento;
• contenere i collegamenti ai piani di gestione della configurazione e della documentazione;
• contenere i collegamenti al Piano di progetto, dove si definiscono i criteri di accetta- zione, di accettazione con riserva o di rifiuto dei componenti forniti.
Per un esempio di tale rapporto si faccia riferimento al § 6.1.2
5. Piano di gestione dei rischi.
In questo documento vengono individuati i vari fattori di rischio che potenzialmente sareb- bero in grado di ostacolare il raggiungimento degli obiettivi contrattuali. Questi rischi, di diversa natura, potrebbero ad esempio essere legati alla dimensione del contratto o essere associati al processo, all’ambiente di sviluppo, alla qualità, ai livelli di servizio, ai costi o dipendere dall’integrazione con altri contratti.
Una volta identificati, i rischi vengono classificati secondo la combinazione di due parame- tri: l’Entità dell’impatto che il rischio potrebbe avere sul contratto (tempi, costi, obiettivi) e la Probabilità che il rischio possa manifestarsi.
Infine, nel documento vengono definite per ciascun rischio, le relative strategie per affron- tarlo o tenerlo sotto controllo. Tali strategie indicano le attività pianificate, le risorse coinvol- te e le date previste per il loro completamento.
Per un esempio di tale rapporto si faccia riferimento al § 6.1.3
6. Stato di avanzamento lavori (SAL). Il documento ha lo scopo di fotografare la situazio- ne corrente del progetto in termini temporali ed economici. I suoi contenuti rivestono parti- colare importanza in quanto da esso dipendono le decisioni su azioni da intraprendere in corso d’opera. Il documento dovrebbe contenere le seguenti informazioni:
33
• avanzamento dei lavori alla data: deve essere presente una descrizione analitica della modalità di rilevazione dei dati e di determinazione dello stato di avanzamento dei lavori. Il livello dello stato di avanzamento deve essere raffrontato con quello atteso alla data e deve essere indicato lo scostamento e l’eventuale ritardo.
• ritardo a finire: deve essere determinato lo slittamento della data di completamento del progetto e l’eventuale incremento dei costi nel caso in cui non si adottino azioni correttive.
• interventi sul progetto: in presenza di ritardi significativi devono essere illustrate le azioni correttive da adottare per recuperare i ritardi ed evitare ulteriori slittamenti. Si deve stimare l’impatto di tali azioni sul progetto e determinare la data di completa- mento a fronte degli interventi proposti.
I contenuti indicati dovrebbero essere presentati anche mediante l’utilizzo di grafici e tabel- le per favorire la lettura degli eventi rappresentati dai dati.
Per un esempio di tale rapporto si faccia riferimento al § 6.1.5
7. Rendicontazione periodica dell’attività di governo. Durante tutta la durata di ese- cuzione del contratto l’attività di Direzione Lavori, per dare efficacia all’azione di gover- no, deve essere necessariamente dialettica, dinamica e continua nel tempo. Come tale, richiede un colloquio tempestivo e costante del Responsabile di progetto con il Direttore Tecnico del Monitoraggio (se presente) e con il Fornitore, allo scopo di garantire, in una ottica di prevenzione, il raggiungimento degli obiettivi contrattuali. Questo colloquio è supportato:
• da un lato, da comunicazioni di carattere estemporaneo finalizzate alla esecuzio- ne e rendicontazione di specifiche attività, alla segnalazione di problemi e proposizio- ne delle relative soluzioni (verifiche ispettive, apertura e chiusura delle non confor- mità e delle azioni correttive, convocazioni e verbali di riunioni, suggerimenti su varianti in corso d’opera), che hanno lo scopo di informare tempestivamente l’Ammi- nistrazione ed il Fornitore in merito a eventi accaduti, eventuali problemi, valutazioni e suggerimenti del Monitore, decisioni concordate nelle riunioni congiunte e nelle verifiche ispettive.
• dall’altro, dalla rendicontazione periodica sullo stato di avanzamento dei lavori, sul rispetto dei livelli di servizio e dei vincoli contrattuali, sull’autorizzazione al pagamen- to delle fatture, sulla applicazione di penali.
Tali documenti rappresentano il quadro aggiornato sullo stato della fornitura e dovranno contenere le seguenti informazioni:
• Valutazione dell’avanzamento delle attività e evidenziazione di eventuali ritardi nella fornitura rispetto a quanto pianificato, indicando le cause che li hanno provocati. Oltre allo stato di avanzamento,le altre informazioni riguardano:
• la situazione dei collaudi;
• la valutazione del rischio di non rispetto dei vincoli temporali contrattuali;
• il tracciamento dei rilievi legati a eventuali ritardi della fornitura;
• le soluzioni proposte e il loro stato (aperto, in corso, chiuso);
34
• la previsione a finire;
• eventuali proposte di applicazione di penali.
• Qualità e livelli di servizio per consentire di valutare la qualità dei prodotti consegnati e i servizi erogati dal Fornitore, attraverso la presentazione delle caratteristiche di qua- lità e dei livelli di servizio misurati. I contenuti sono:
• livelli di servizio misurati e relativi valori soglia contrattualmente previsti;
• indicatori di qualità e valori soglia contrattualmente previsti;
• valutazione del sistema di misura degli indicatori di qualità e dei livelli di servizio adottato dal Fornitore;
• valutazione del rischio di non rispetto dei vincoli di qualità contrattuali;
• tracciamento dei rilievi relativi alla qualità dei prodotti ed ai livelli di servizio;
• interventi correttivi proposti e loro stato;
• eventuali proposte di applicazione di penali.
• Visite ispettive:
• piano delle visite;
• rendicontazione delle visite ispettive effettuate dal Monitore e da Enti di certificazione;
• tracciamento dei rilievi relativi al processo produttivo;
• interventi correttivi proposti e loro stato.
• Pagamenti e penali: situazione del pagamento delle fatture e/o dell’applicazione delle penali previste contrattualmente.
Un esempio di rendicontazione periodica è costituito dal Rapporto sull’andamento del contratto. Questo ha lo scopo di aggiornare periodicamente l’Amministrazione in merito alle principali e più rilevanti informazioni sull’andamento del contratto. L’obiettivo del rap- porto dovrebbe essere quello di:
• consolidare e consuntivare ad una certa data lo stato del contratto e delle attività di governo messe in atto per garantirne il buon fine;
• dare conto dell’azione di governo svolta, permettendone la valutazione, in base a misure oggettive di efficacia ed efficienza;
• fornire le informazioni di sintesi necessarie a comparare i dati rilevati sullo specifico contratto con quanto afferente a contratti e progetti confrontabili, al fine di permettere una valutazione sulla soluzione scelta e sulle modalità di realizzazione della soluzione messe in atto, nonché di supportare l’identificazione e la pianificazione degli eventuali interventi di miglioramento.
I requisiti che il rapporto dovrebbe soddisfare allo scopo di facilitarne la lettura sono i seguenti:
• utilizzo di una struttura e di una organizzazione dei contenuti invariante, sia nel tempo, che in relazione a diversi contratti, conforme quanto più possibile alla struttura delineata dal CNIPA (cfr. testo del documento in: xxx.xxxxx.xxx.xx - Attività Servizi per la P.A. – Monitoraggio grandi progetti – Rapporti di monitoraggio), con una dimensione compresa tra le 15 e le 35 pagine ed emissione con cadenza ;
35
• presenza di contenuti di facile reperimento in relazione alla struttura adottata, focaliz- zati sui fatti più significativi ai fini del governo del contratto, omogenei nelle modalità espositive e nel livello di sintesi adottati;
• evidenza di informazioni di riepilogo sullo stato quantitativo e qualitativo del contratto alla fine del periodo temporale cui il rapporto si riferisce, in relazione alle:
• prescrizioni esplicitamente identificate negli atti contrattuali (studio di fattibilità, analisi costi / benefici, contratto, offerta, piano di progetto, piano di qualità, manuale della qualità);
• esigenze implicite dell’Amministrazione, desumibili dalla documentazione di piani- ficazione e programmazione disponibile, o formalizzate sotto la responsabilità della Direzione Lavori;
• dati e informazioni di confronto derivanti da attività di check-up dei sistemi infor- mativi, benchmark dei servizi ICT, assessment dei progetti, effettuate su entità com- parabili con il contesto organizzativo e tecnologico in cui il contratto si colloca;
• evidenza, in considerazione della periodicità del rapporto, di informazioni sull’anda- mento e sulle tendenze del contratto, dal suo inizio alla fine del periodo temporale cui il rapporto si riferisce, ottenute attraverso:
• indicatori chiaramente messi in relazione con quelli relativi ai rapporti precedente- mente emessi, atti a mostrare l’evoluzione nel tempo delle misure rilevate evitando al lettore la consultazione simultanea di più rapporti;
• rappresentazione, per mezzo di grafici e tabelle, dell’andamento nel tempo di indi- catori ritenuti significativi ad un adeguato livello di sintesi;
• correlazione dell’azione di governo effettuata con l’andamento nel tempo del con- tratto al fine di consentire la valutazione della sua efficacia;
• dati di dettaglio aggregati in viste sintetiche delle quali vanno illustrati i criteri di composizione.
8. Analisi della soddisfazione dell’utenza. Il documento ha lo scopo di rendicontare i risultati dell’indagine sul gradimento dell’utenza relativamente all’erogazione, da parte dei fornitori dell’Amministrazione, di specifici servizi.
In particolare il documento dovrà presentare le seguenti informazioni:
• Descrizione del servizio: informazioni che permettano di caratterizzare ogni servizio oggetto dell’indagine;
• Metodo di indagine: descrizione della metodologia adottata per la rilevazione, elabo- razione e valutazione delle informazioni fornite dal campione di utenza;
• Descrizione del campione di utenza selezionato in termini di numerosità e di percen- tuale rispetto agli utenti a cui è rivolto il servizio, tipologie e caratteristiche degli utenti coinvolti nella rilevazione, modalità di somministrazione del questionario (telefono, fax, interviste dirette, etc), percentuale di rispondenti suddivisi per tipologia;
• Presentazione dei risultati delle rilevazioni.
36
9. Livelli di servizio rilevati. L’attività di rilevazione dei livelli di servizio è svolta dal For- nitore il quale ha il compito di fornire al Committente / Monitore il quadro di sintesi dei
dati raccolti. A questo scopo viene redatto un documento in cui sono riportati i valori degli indicatori calcolati a partire dai dati di rilevazione. Per ogni indicatore devono essere inoltre descritte le modalità di rilevazione, cioè la frequenza di rilevazione, la metrica, gli strumenti di misura, il procedimento di calcolo e gli arrotondamenti.
Per un esempio di tale rapporto si faccia riferimento al § 6.1.9
10. Verbale di collaudo.
Il documento contiene informazioni inerenti il contratto per l’identificazione dello specifico oggetto del collaudo, le attività realizzate con le relative date di inizio e completamento, il luogo in cui queste si sono svolte, i principali documenti di riferimento utilizzati, la compo- sizione del team.
Viene inoltre riportato l’esito dei controlli (tecnici e funzionali) effettuati durante l’attività di collaudo, elencando le anomalie riscontrate o l’ inadeguatezza del prodotto ai requisiti pre- visti. Infine viene riportato l’esito complessivo e globale del collaudo svolto e in caso di conclusione positiva, l’accettazione viene attestata tramite la sottoscrizione del rapporto di collaudo da parte dei responsabili dell’Amministrazione e del Fornitore
Per un esempio di tale rapporto si faccia riferimento al § 6.1.10.
11. Gestione modifica contenuto di progetto. A seguito delle attività di analisi mirate al miglioramento dei processi e dei servizi, vengono emessi dei documenti il cui contenuto consiste in suggerimenti su varianti in corso d’opera. Tali documenti devono riportare: la descrizione degli obiettivi contrattuali oggetto della variante proposta, la descrizione delle cause che hanno prodotto l’esigenza della variante, gli obiettivi della variante, la descrizione della variante, l’analisi dei costi, la valutazione del rischio di insuccesso, le risorse coinvolte. Per un esempio di tale rapporto si faccia riferimento al § 6.1.4
12. Fatturazione. L’emissione delle fatture è tipicamente disciplinata nel contratto. Essa può avvenire a seguito della realizzazione di attività, consegna di prodotti o erogazione di servizi, che sono controllati mediante documenti specifici realizzati dal fornitore, quali il documento di avanzamento progetto, il documento di collaudo, il documento di completa- mento milestone, il documento presenze/attività, etc, che se approvati dal responsabile del Committente, autorizzerà il fornitore all’emissione della fattura.
3.1.5. Integrazione di più contratti
37
In una logica di outsourcing selettivo l’Amministrazione, per Progetti complessi che richie- dono diverse categorie tecnologiche di forniture, quindi diversi contratti, può rivolgersi a diversi fornitori per ognuna delle tipologie di servizi richiesti. Ciò comporta un aumento della complessità di gestione della fornitura e del rischio di conflitti di competenza tra i diversi fornitori.
I diversi contratti / progetti possono interagire tra loro in una combinazione di:
• logica di integrazione (che richiede un coordinamento di giusta integrazione);
• logica di parallelismo (che richiede un coordinamento di omogeneità e di sincronismo).
I compiti dell’Amministrazione, in questo caso, sono:
• pianificazione generale del progetto;
• controllo di congruità dei piani specifici di ogni singolo contratto;
• controllo stato avanzamento lavori complessivo e rilevazione di eventuali criticità di tempi tra contratti diversi – coordinamento attività di individuazione delle soluzioni;
• collaudi: poiché oltre al collaudo della fornitura ci sono i collaudi di integrazione par- ziale e il collaudo di integrazione finale, c’è bisogno di un’attività di coordinamento tra i collaudi;
• definizione di standard intercontrattuali per garantire l’armonizzazione e la coerenza sostanziale degli standard operativi/tecnici/gestionali adottati nei diversi contratti e dai diversi interlocutori in modo da evitare disallineamenti.
Operativamente si può dar luogo a tavoli di coordinamento per eventuali spartizioni in lotti omogenei o a una gestione cosiddetta per portafoglio di progetti per valutare:
• assegnazioni di priorità;
• interferenze realizzativo / economiche;
• attività di project office.
La definizione chiara e univoca delle priorità è la prima condizione di successo ai fini della gestione di un ambiente multicontratto.
La pianificazione per singolo progetto tende a limitare questa capacità di analisi della pro- blematica multiprogetto, poiché prevede che il rischio di ritardi o eventi imprevisti dipenda dall’incertezza del solo progetto oggetto di pianificazione. In realtà, è determinante il peso di ciò che potremmo definire effetto domino: le cause di rischio su un progetto in un ambiente multiprogetto dipendono dall’incertezza del progetto stesso ma anche dall’incer- tezza di tutti gli altri progetti.
La visione per portafoglio di progetti e l’analisi storica delle interdipendenze tra le attività dovrebbero consentire di facilitare i processi di pianificazione, ricorrendo alla base di dati accumulati nel tempo e all’esperienza capitalizzata su progetti passati. In particolare, secon- do l’esperienza rilevabile, è possibile costruire dei modelli di progetto che hanno cicli di sviluppo simili e per i quali possono essere standardizzati i carichi di lavoro ed i tempi di realizzazione.
Sintetizzando quanto detto sinora, l’ambiente multicontratto sembra richiedere particolare attenzione non tanto sulla strumentazione per la gestione del singolo contratto, quanto invece sulla definizione delle condizioni che regolano l’ambiente in questione. Si tratta cioè di costruire un’architettura gestionale che consenta la riduzione del rischio attraverso:
38
• la definizione di priorità “strategiche” tra progetti, univoche, condivise e basate su approcci di valutazione razionale, che consentano di limitare i danni generati da even- ti di progetto che si riflettono sull’intero “portafoglio”;
• la pianificazione e il controllo dei progetti a livello master e la riduzione dell’incertez- za attraverso l’analisi e la costruzione di standard.
Altro aspetto da considerare in un progetto complesso, che può non riguardare esclusiva- mente l’acquisizione di servizi ICT, è che esso può comprendere, oltre ai già ricordati con- tratti con fornitori diversi, anche attività a carico dell’Amministrazione.
Questo avviene per esempio in logiche di integrazione o riuso di infrastrutture hardware e software preesistenti su cui viene chiamato ad operare un nuovo fornitore. In questo caso è responsabilità dell’amministrazione trasferire le conoscenze (macchine, documentazione,
…) dal vecchio fornitore al nuovo.
In questo caso il governo dell’intero progetto, che è responsabilità dell’Amministrazione, consiste nell’esecuzione delle attività di Project Management che integrano quelle di cia- scun contratto di fornitura e le completano con le proprie, ponendo particolare attenzione a quelle attività che condizionano l’esecuzione di ciascun contratto ma sono esterne a esso.
Relativamente al coordinamento delle attività, oltre a quanto già detto, in fase di imposta- zione e di svolgimento particolare attenzione deve essere posta ai punti di interazione tra le organizzazioni coinvolte. Ciò comporta la necessità di gestire una Pianificazione a livello dell’intero progetto, in cui:
• i singoli contratti sono da suddividere in una o più macro attività al fine di identificare e controllare le interazioni oltre che fra i diversi fornitori, fra i fornitori e l’Amministra- zione (passaggi di responsabilità, attività da eseguire da parte di altri, attività da ese- guire in modo congiunto);
• la misura dell’avanzamento dell’intero progetto è dato dall’insieme degli avanzamenti delle attività comprese nei contratti e di quelle a carico dell’Amministrazione stessa;
• i rischi dell’intero progetto comprendono quelli derivanti dallo svolgimento dei singoli contratti e quelli derivanti dalle attività a carico dell’Amministrazione o di altri soggetti nell’ambito dell’intero progetto.
L’approvazione del Piano di Progetto e del Piano della Qualità relativamente ad ogni singo- lo contratto costituisce operativamente la presa in carico delle attività che ricadono sotto la responsabilità dell’Amministrazione e la garanzia della coerenza del singolo contratto con gli obiettivi prefissati e con le altre componenti dell’intero progetto.
Project office. Nei progetti complessi esistono spesso dei veri e propri uffici di progetto che, come nel mondo della produzione industriale, curano tutta la pianificazione e la con- suntivazione dei lavori (ad esempio in un cantiere per la costruzione di grandi opere civili). Nei progetti di minori dimensioni è spesso il project manager o un suo collaboratore a svol- xxxx tale mansione.
Normalmente il Project Office agisce trasversalmente a tutti i progetti dell’organizzazione, ponendosi come struttura capace di:
39
• dare supporto alla pianificazione delle attività;
• gestire e monitorare ogni area di progetto;
• individuare i problemi e superare le criticità;
• affiancare e monitorare i gruppi di lavoro per il raggiungimento degli obiettivi;
• istituire momenti di confronto tra i responsabili delle diverse azioni;
• fornire strumenti di lavoro in team per ottimizzare l’impegno delle risorse e aumentar- ne la mobilitazione, il coinvolgimento e la condivisione;
• gestire la comunicazione.
3.2. Dettaglio delle attività di governo
Nei capitoli che seguono sono trattate, separatamente in due sezioni (capitoli 4 e 5), le atti- vità di governo per la realizzazione dei progetti e quelle per l’erogazione dei servizi, in quanto sono diversi i criteri di controllo, la gestione dei rischi e l’interazione Amministrazio- ne-Fornitore. All’interno di ogni sezione si è ritenuto utile trattare separatamente le attività di competenza del Fornitore da quelle dell’Amministrazione allo scopo di indicare in modo esplicito i ruoli e le responsabilità delle parti nel governo di un contratto.
Le metodologie e i modelli di supporto utili per lo svolgimento delle attività operative di governo sono solo sinteticamente illustrate all’interno del presente manuale, in quanto esse sono descritte in modo più ampio nel manuale di riferimento delle linee guida “Modelli per la qualità delle forniture ICT”. Per il personale che dovrà applicare tali metodologie o modelli è necessario fare riferimento ai testi specializzati indicati nella bibliografia.
Nell’ultimo capitolo (6) sono riportati gli schemi ed i relativi contenuti informativi dei prin- cipali documenti tipicamente utilizzati per il controllo della fornitura o per la comunicazio- ne tra le parti. Tali documenti dovrebbero essere personalizzati in base alle specificità della fornitura, ai requisiti/vincoli contrattuali ed in funzione del ruolo ricoperto dall’Amministra- zione nell’esecuzione della fornitura.
40
4. Governo dei contratti per la realizzazione dei Progetti
Nell’espletamento di un contratto gli attori coinvolti, Amministrazione-Fornitore o Ammini- strazione-Monitore-Fornitore, hanno specifici compiti ed interessi. Per la buona riuscita del contratto è importante che ciascuno di essi si senta fortemente motivato e coinvolto negli obiettivi da raggiungere, che necessariamente devono essere condivisi. Ciò non toglie che ognuno debba mantenere il proprio ruolo e le proprie competenze.
Per poter governare l’attuazione di un contratto è necessario approfondire quanto già defi- nito al suo interno e nel capitolato ad esso allegato. Nel contratto stipulato con il Fornitore sono sicuramente presenti informazioni che determinano:
• l’obiettivo, ossia cosa realizzare;
• i tempi di realizzazione;
• i costi;
• i livelli di qualità;
• i prodotti finali, ossia il prodotto realizzato corredato da tutta la documentazione necessaria.
In genere, i tempi di realizzazione del prodotto e/o del servizio costituiscono per l’Ammini- strazione il vincolo più importante; spesso infatti, per esigenze amministrative o legislative, i prodotti devono essere disponibili entro date improrogabili.
Nei documenti contrattuali non sempre si scende ad un livello di dettaglio tale da consenti- re immediatamente la sua attuazione. Ciò implica che occorre identificare in modo chiaro e inequivocabile una serie di metodi, strumenti e informazioni fondamentali per far sì che tutti gli attori coinvolti possano “comunicare” tra loro.
41
Parlare di comunicazione può sembrare ovvio ma non lo è. Molti progetti possono nau- fragare per informazioni sottintese, non dette, mai chiarite. È da tener presente che gli attori coinvolti hanno estrazioni diverse, mentalità diverse e usano linguaggi diversi: si pensi all’esperto informatico e al funzionario amministrativo. Ognuno dei membri del team deve quindi sia condividere gli obiettivi contrattuali sia cercare la giusta lunghez- za d’onda per comunicare con gli altri interlocutori. È bene quindi definire, sin dall’ini- zio, quali saranno le modalità di comunicazione, come devono essere fatti i documenti che verranno prodotti dal Fornitore e approvati dall’Amministrazione, la periodicità, l’oggetto e i partecipanti alle riunioni. Spesso vengono utilizzati modelli standard di documenti allegati ai documenti contrattuali, quali i modelli predisposti, ad esempio,
per i piani di progetto, di qualità, di gestione del rischio che vengono stilati in fase di avvio e revisionati in corso d’opera, come anche per i rapporti di monitoraggio della fornitura.
Il responsabile di progetto dell’Amministrazione ha interesse ad esigere la massima chia- rezza e trasparenza dal Fornitore. In fase di avvio, è bene che si arrivi a definire un maggior livello di specificazione rispetto a quanto previsto contrattualmente che tenga anche conto dell’eventuale offerta migliorativa presentata dal Fornitore. Ovviamente, un contratto ben scritto lascia poche possibilità di interpretazione e ne rende più semplice la gestione.
In particolare è bene che venga concordato:
• come si misura l’avanzamento (SAL) delle attività presenti nel piano di progetto, la struttura del documento che il Fornitore dovrà redigere e la periodicità degli incontri per la sua verifica (cfr. paragrafi 4.1.2 e 4.2.1);
• come gestire i rischi che potrebbero presentarsi durante lo svolgimento delle atti- vità, individuando quelli più probabili, stimandone l’entità e facendo preparare al For- nitore un piano di gestione da sottoporre all’approvazione dell’Amministrazione (cfr. paragrafo 4.2.3);
• come gestire i cambiamenti in corso d’opera in quanto, per i più svariati motivi, è possibile che vengano messi in discussione requisiti già definiti e approvati o in corso di realizzazione (cfr. paragrafo 4.2.4).
Durante tutta l’attività di governo viene consigliato al responsabile di progetto dell’Am- ministrazione di tenere traccia di tutte le informazioni significative che possono tornare utili anche dopo la conclusione del contratto stesso. Come previsto nella norma ISO 10006 (cfr. § 6.1.4), storicizzare le informazioni del contratto determina un valore aggiunto che può essere utile per il governo di contratti successivi. In pratica, si può prevedere la costituzione di un archivio elettronico dei contratti, nel quale ciascun responsabile può annotare in modo strutturato tutto ciò che ha caratterizzato il suo contratto: dati caratteristici (tipologia, durata, costi, Fornitore, utenti, prodotti, collabo- ratori, strutture dell’Amministrazione interessate ….), richieste di cambiamento, scosta- menti dei dati di consuntivo rispetto al preventivo, rischi che si sono presentati e solu- zioni adottate, problemi incontrati nella gestione del Fornitore e altro ancora. Queste informazioni possono costituire una preziosa banca dati consultabile dai responsabili di progetto dell’Amministrazione quando devono fare stime di tempi e costi o individuare e stimare i rischi.
42
Analogamente, poiché i deliverable di contratto sono generalmente costituiti da un insieme strutturato di elementi quali risorse hardware, prodotti software e documenti che nel tempo devono essere gestiti, è necessario disporre di un sistema che si occupi della con- servazione, della gestione di questi elementi e delle correlazioni tra loro esistenti: il siste- ma di gestione della configurazione (Configuration G Ch’ange Management System). In questo sistema può essere documentato tutto l’hardware e il software rilasciato in esercizio
in modo da avere sempre aggiornato l’inventario dell’Amministrazione (hw e sw inven- tory). Stessa cosa per il patrimonio documentale se gestito direttamente dall’Amministrazio- ne e non dal Fornitore.
Tutto ciò, se fatto in corso d’opera, costa poco tempo in quanto le informazioni possono essere registrate mano a mano che il responsabile le acquisisce. Più oneroso diventa se deve essere fatto a contratto ormai concluso; il rischio è che non venga fatto mai e che l’e- sperienza resti solo nella memoria del singolo responsabile: ciò non porta all’Amministra- zione il valore aggiunto atteso.
Nel governo dei contratti due aspetti risultano particolarmente significativi:
• la conoscenza da parte dell’Amministrazione dei metodi, delle tecniche e degli stru- menti adottati dal Fornitore nel corso del progetto;
• le attività finalizzate al miglioramento ed all’innalzamento della qualità.
Per metodi, tecniche e strumenti si intendono tutti quelli normalmente utilizzati per il governo dei progetti di natura informatica sulle diverse attività come pianificazione, stato avanzamento lavori, governo della qualità, ecc.
Il responsabile dell’Amministrazione deve conoscere i metodi, le tecniche e gli strumenti adottati dal Fornitore al fine di poter interagire con quest’ultimo in maniera paritetica. Per questo motivo è buona norma che l’Amministrazione richieda esplicitamente al Fornitore l’utilizzo di tutti quei metodi, di quelle tecniche e di quei strumenti che essa stessa sia in grado di comprendere al meglio, anche in base agli skill professionali di cui è in posses- so.
Nei paragrafi che seguono sono fornite informazioni generali su alcuni tra i metodi e le tec- niche più utilizzati per poter procedere nelle attività tipiche di governo di un progetto ICT. Per gli approfondimenti si rimanda a testi specifici.
Tra le attività utili ad un continuo processo di miglioramento e finalizzate all’innalzamento della qualità durante il governo del contratto si possono citare l’assessment, il benchmark, la rilevazione della customer satisfaction e la scelta di un Fornitore certificato.
L’assessment è un’attività di misurazione che può essere effettuata per verificare lo stato del contratto e delle risorse impiegate. Può essere svolto più volte durante il corso del contratto e i risultati delle misurazioni possono essere confrontati nel tempo. L’analisi dei dati può evidenziare scostamenti dai risultati attesi: in questi casi sarà compito del responsabile del- l’Amministrazione l’attuazione di soluzioni adeguate.
L’assessment dovrebbe essere effettuato sulla base di una metodologia che preveda i seguenti passi:
• individuazione delle variabili da misurare;
• organizzazione delle sessioni di misura;
• verifica qualità dei dati relativi alle variabili misurate;
• scelta degli indicatori elementari sulla base delle variabili qualitativamente valide;
43
• calcolo degli indicatori elementari;
• scelta degli indicatori complessi basati su indicatori elementari;
• calcolo degli indicatori complessi;
• eventuale confronto con riferimenti esterni;
• analisi e diagnosi.
Il benchmark è un processo, estemporaneo o programmato, di ricerca, misurazione, com- parazione di parametri del contratto con dati pubblici di altre amministrazioni o presenti su database internazionali quali ad esempio il DB dell’ISBSG (International Software Bench- marking Standards Group). Per fare la comparazione è possibile utilizzare i dati strutturati che sono presenti nell’archivio elettronico dei contratti, prendendo a riferimento contratti con analoghe o quanto più possibile simili caratteristiche (temporali, economiche, di forni- tura,…). Un piano di benchmarking interno può richiedere di decidere a priori quali carat- teristiche rilevare e monitorare per confronto in tutti i contratti avviati.
Questo strumento è molto utile principalmente in fase di stesura del contratto in quanto consente di avere riferimenti precisi da altre realtà sul rapporto prestazioni/prezzo e qualità
/prezzo.
La certificazione del Fornitore, disciplinata dalla Xxxxx XX XXX 00000, è affidata ad un Organismo di Certificazione accreditato da un ente di accreditamento (in Italia il SINCERT) che esegue verifiche ispettive con ispettori accreditati. Oggetto di verifica sono l’organizza- zione, le politiche di produzione e la conformità rispetto alla norma UNI EN ISO 9001:2000. L’Amministrazione può verificare la certificazione del Fornitore, se quest’ultimo l’ha dichia- rata in sede d’offerta. Può inoltre avvalersi di tutte le garanzie che la certificazione offre tra le quali periodiche visite ispettive, concordandole con il Fornitore stesso, che può effettuare direttamente (visite di seconda parte) o richiedere ad organismi terzi accreditati (visite di terze parti) sempre eseguiti in osservanza alla norma che disciplina le stesse (UNI EN ISO 30011).
4.1. Attività di competenza del fornitore
4.1.1. Stabilire la dimensione funzionale del software
L’esigenza di stabilire la dimensione funzionale del software è presente sia nei contratti nei quali è prevista la determinazione del corrispettivo “a corpo”, sia nei contratti nei quali è prevista la determinazione del corrispettivo “a consuntivo”.
Nei contratti “a corpo”, nei quali il prodotto da realizzare è predefinito,il prezzo è fisso ed è stabilito all’inizio del progetto, l’attività è necessaria solamente ai fini dell’inventario delle funzionalità applicative e quindi per determinare la dimensione del patrimonio funzionale applicativo dell’Amministrazione.
44
Nei contratti “a consuntivo”, nei quali la quantità dei prodotti effettivamente forniti viene misurata a consuntivo, si rendono necessarie per il governo ed il controllo della fornitura una serie di attività di stima e misura da porre in relazione alle diverse fasi del ciclo di svi- luppo del software:
Attività | Quando | Finalità | Utilizzo contrattuale |
Stima iniziale | Avvio progetto | Predisposizione del piano di lavoro, valutazione da parte dell’Amministrazione sull’opportunità di autorizzare l’avvio effettivo del progetto | Il fornitore è vincolato a fornire la stima con le evidenze che hanno condotto alla stima |
Stime o misure intermedie | Al termine della fase di analisi o progettazione o fase analoga | Determinazione con un buon margine di precisione del prezzo totale/finale della fornitura | Nel caso in cui la misura intermedia superi la stima autorizzata all’avvio del progetto l’Amministrazione deve autorizzare la quota aggiuntiva. Le misure intermedie possono essere utilizzate per stabilire dei meccanismi di tolleranza indicando degli scostamenti percentuali massimi con la misura finale anche al fine della determinazione del prezzo totale/finale |
Stime o misure intermedie dei cambiamenti di requisiti in corso d’opera | In corso d’opera | Determinazione del prezzo del cambiamento dei requisiti in corso d’opera | |
Misura finale | Al termine della fase di realizzazione | Determinazione dell’ammontare finale di FP per il prodotto e del prezzo totale/finale della fornitura | Nel caso in cui la misura finale superi quanto in precedenza autorizzato l’Amministrazione deve autorizzare la quota aggiuntiva |
Si specifica che i termini misura e stima indicano distinte modalità di stabilire la dimensione del software.
Le stime si basano normalmente su informazioni meno dettagliate di quelle necessarie alla misura e sono effettuate in dipendenza degli elementi di valutazione a disposizione. La misura può essere effettuata allorquando tutti gli elementi di valutazione sono disponibili.
Attualmente il metodo maggiormente utilizzato per la misura del software è il metodo stan- dard della Function Point Analysis IFPUG (International Function Point User Group); la stima richiede l’utilizzo di metodi diversi comunque compatibili con i principi e gli oggetti della Function Point Analysis IFPUG. La letteratura indica diversi metodi per stimare il size in FP, alcuni di questi sono indicati al cap. 9 del manuale “Strategie di acquisizione delle forniture ICT”.
45
Infine si precisa che per la determinazione dei corrispettivi, oltre che stimare la dimensione del software di nuova realizzazione, occorre stimare sia il riuso di funzionalità già realizzate che l’eventuale replicazione di funzionalità su ambienti tecnologici diversi.
4.1.2. Pianificare il Progetto
La pianificazione rappresenta il processo preliminare di analisi mirato a definire in maniera puntuale le attività operative che sarà necessario eseguire, in quale ordine e con quali tempi, per il raggiungimento degli obiettivi del progetto espressi dall’Amministrazione nei documenti contrattuali considerando i vincoli esistenti.
Quanto stabilito in tale fase serve successivamente da guida nel corso delle attività di pro- getto e da riferimento per il controllo dell’avanzamento delle attività progettuali.
In sostanza, la pianificazione mira a:
• assicurare che ogni azione necessaria al conseguimento degli obiettivi sia stata previ- sta, definita e correlata con le altre, quotata in termini di costo, valutata in termini di rischio;
• assicurare che per ogni azione necessaria al conseguimento dell’obiettivo siano state previste le risorse per implementarla;
• rendere chiaro ed esplicito ai diversi attori coinvolti in che modo, in quali tempi, con quali costi e con quali risorse ogni azione necessaria deve essere implementata.
Pertanto, la pianificazione di un progetto è utile:
• all’Amministrazione, perchè esplicita le scadenze previste (milestone) e le consente di esercitare il controllo sull’andamento del progetto;
• al Fornitore, perché prevede le aree di criticità e di rischio, consentendo il coordina- mento delle risorse e l’ottimizzazione dei costi.
L’attività di pianificazione non è di per sé produttiva, ma serve ad ottimizzare le attività direttamente produttive; pertanto, essa rappresenta un costo che deve essere sostenuto al fine di ridurre il rischio di non conseguire gli obiettivi del progetto. Tale rischio sarebbe più elevato qualora si procedesse, invece, affrontando i problemi man mano che essi si presen- tano e concatenando le attività operative a seconda delle disponibilità del momento.
In linea generale, durante il processo di pianificazione si seguono diversi passi successivi che sono qui brevemente descritti.
Definizione degli obiettivi del progetto
La stesura del piano di progetto comincia con una definizione accurata degli obiettivi del progetto. Consiste nella definizione puntuale dei risultati da raggiungere, specificando i pro- dotti, tipicamente documenti, che attestino il raggiungimento di tali risultati. Nell’individua- zione degli obiettivi l’approccio da seguire dovrebbe essere quello di porsi nell’ottica di individuare cosa deve essere fatto per raggiungere le finalità che il progetto si pone.
46
L’attività di identificazione degli obiettivi è tanto più agevole quanto più è specificato e det- tagliato l’obiettivo generale del progetto a livello di documentazione contrattuale (contratto, capitolato tecnico, ecc.). Questo aspetto riveste una particolare importanza, in quanto sovente le Amministrazioni tendono ad indicare le finalità del progetto in maniera piuttosto generica. In questa fase il Fornitore deve individuare gli obiettivi operativi del progetto
attraverso un’attività di confronto e di condivisione di diverse idee e proposte. In tal modo di solito si viene a creare una gerarchia di obiettivi. La tecnica normalmente utilizzata per la scomposizione del progetto in obiettivi e per la rappresentazione degli stessi è la WBS (Work Breakdown Structure).
Definizione delle attività da svolgere
Tipicamente, per il raggiungimento di ciascun obiettivo, devono essere svolte diverse atti- vità, ciascuna delle quali può, a sua volta, essere descritta da uno o più compiti elementari. In questa fase vengono censite le attività ed i compiti necessari al raggiungimento degli obiettivi precedentemente individuati. Si tratta, spesso, di una fase delicata in quanto cia- scuna persona del team di progetto, essendo specialista di una determinata materia, ha la propria visione operativa del progetto e tende ad imporla agli altri. E’ necessario pertanto, come per tutto il lavoro di definizione del piano, pervenire ad una visione condivisa del progetto adottando, probabilmente, una serie di compromessi.
La definizione delle attività scaturisce parzialmente dal lavoro fatto nella definizione degli obiettivi e può avvalersi delle medesime tecniche di rappresentazione WBS.
Individuazione delle competenze necessarie
L’esecuzione delle attività di progetto richiede l’impegno di persone dotate delle necessarie competenze e capacità tecniche, organizzative e relazionali. In questa fase vanno quindi individuate tali competenze, indipendentemente dal fatto di averle effettivamente nell’ambi- to della propria organizzazione. In tal modo, e quindi non considerando la reale disponibi- lità di risorse, è possibile:
• avere le idee chiare su come dovrebbe essere composto il team del progetto per poterlo realizzare nella migliore composizione possibile;
• avere una oggettiva base di informazioni per poter ricercare le competenze più ido- nee da impegnare sul progetto.
Definizione e assegnazione delle risorse
Definite le attività da svolgere e le competenze richieste, è a questo punto possibile indivi- duare le persone e le altre risorse (hardware, software, ecc.) necessarie ed assegnare alle stesse i rispettivi compiti e responsabilità. Particolarmente utile in questa fase è lo strumento rappresentato dalla “matrice delle responsabilità”.
47
A questo punto dovrebbero essere disponibili tutte le informazioni necessarie per stimare i tempi del progetto: obiettivi, attività e disponibilità temporale delle risorse. In questa fase si descrivono le attività nella loro sequenza e nel loro parallelismo, indicando le persone e le risorse coinvolte e stimando i tempi di inizio e di fine di ogni attività e, conseguentemente, dell’intero progetto.
Risultano di particolare ausilio, nella fase di definizione dei tempi, le tecniche che adottano rappresentazioni di tipo reticolare che permettono di determinare le attività critiche (quale il
CPM, metodo del percorso critico, oppure tecniche di analisi probabilistica della durata, quale il PERT) ed il diagramma di GANTT.
I principali strumenti del processo di pianificazione
Durante l’illustrazione delle fasi del processo di pianificazione sono stati indicati alcuni stru- menti di ausilio che sono normalmente utilizzati. Di seguito si fornisce un breve cenno sugli stessi, dei quali è possibile reperire maggiori informazioni in letteratura.
LA WORK BREAKDOWN STRUCTURE (WBS)
La Work Breakdown Structure (WBS), talvolta denominata Project Breakdown Structure (PBS), è una forma di scomposizione strutturata del progetto utile nella fase di definizione degli obiettive e delle attività. Essa viene costruita cominciando a rispondere ad una domanda semplice ma essenziale: cosa bisogna fare concretamente?
Partendo dalle finalità del progetto vengono individuati i singoli obiettivi e, per ciascuno di essi, vengono definiti i confini ed individuati i sottobiettivi di cui si compongono. Tali sotto- biettivi sono raggiunti espletando determinate attività che a loro volta sono costituite da uno o più compiti elementari. Man mano che procede l’analisi da parte del team si rappre- senta la gerarchia di obiettivo, sottobiettivi, attività e compiti in una struttura ad albero rove- sciato, che rappresenta la struttura scomposta del lavoro da svolgere per raggiungere le finalità del progetto. Ciascun ramo dell’albero rappresenta un gruppo omogeneo di attività, raccolte attorno ad un medesimo sottobiettivo: leggendo dall’alto verso il basso la WBS si individuano le informazioni di maggiore dettaglio del lavoro da compiere.
Nel lavoro di costruzione della WBS si consiglia di individuare le attività autoconsistenti, ossia tali da produrre un output (deliverable) e con durata variabile in base alle dimensioni temporali ed economiche del progetto. Pur non potendo generalizzare, si può affermare che le attività di durata troppo breve difficilmente possono produrre un output, mentre quelle di durata troppo lunga di solito possono essere ulteriormente scomposte. Normal- mente attività di durata eccessivamente lunga possono sfuggire al monitoraggio e nascon- dere problemi. Durante il controllo dell’avanzamento vengono viste come attive o in corso d’opera e solo in prossimità della scadenza si riescono ad evidenziare eventuali ritardi per i quali potrebbe essere troppo tardi per intervenire con azioni correttive.
Nella WBS il fornitore inserisce tutte le attività sotto la propria responsabilità e quelle non a proprio carico ma necessarie allo svolgimento del contratto. I vincoli, che possono nascere dall’esecuzione delle attività non a carico del fornitore, hanno ovviamente rilevanza per l’Amministrazione, costituendo, se non puntualmente previste e eseguite, potenziali impedi- menti al rispetto del contratto.
48
La rilevanza organizzativa di tali attività deve essere massima per l’Amministrazione che, nell’ambito del governo dell’intero progetto, deve assicurarne l’esecuzione e eventualmente l’indirizzamento (es. assegnazione ad altro fornitore o ad altra Amministrazione o a compo- nenti dell’Amministrazione stessa).
Di seguito si riporta, a titolo di esempio, una possibile rappresentazione della struttura logi- ca di una WBS.
Progetto
1
Sottoprogetto
1.1
Sottoprogetto
1.2
Sottoprogetto
1.3
Pacchetto di lavoro 1.1.1
Pacchetto di lavoro 1.1.2
Pacchetto di lavoro 1.2.1
Pacchetto di lavoro 1.2.2
Pacchetto di lavoro 1.3.1
Pacchetto di lavoro 1.3.2
Il reticolo di progetto
Il reticolo di progetto è la rappresentazione grafica reticolare delle attività, che illustra la sequenza temporale di tutti i compiti che devono essere svolti affinchè il progetto venga completato. Di fatto il reticolo di progetto rappresenta l’evoluzione ed il completamento della WBS. Infatti, le attività ed i compiti individuati nella WBS non sono caratterizzati dalla loro sequenza temporale e pertanto, tramite la sola WBS, non si è in grado di stabilire come si collocano le attività nel tempo e quali relazioni di precedenza esistono tra le stesse. Tut- tavia, la WBS rappresenta il punto di partenza per la costruzione del reticolo delle attività, in quanto è lo strumento in cui le stesse sono completamente censite.
Obiettivo del reticolo di progetto è quello di definire il piano delle attività nel rispetto delle scadenze previste e dei vincoli di precedenza, usando le risorse disponibili e, successiva- mente, quello di seguire e controllare l’avanzamento del progetto.
In un reticolo di progetto devono essere sempre presenti due eventi ‘milestone’ fondamentali: l’inizio e la fine del progetto. È opportuno che nella pianificazione siano sempre presenti le milestone ossia gli eventi fondamentali di un progetto, in particolare quelli previsti dal contratto. Di seguito si riporta, a titolo di esempio, una possibile rappresentazione della struttura logi- ca di un reticolo di progetto “a precedenze” in cui i legami delle attività sono tutti del tipo fine-inizio, e le durate delle attività sono espresse in giorni .
49
Come si può notare, da una tale rappresentazione è possibile ricavare importanti informa- zioni, quali:
• la data di inizio e di fine del progetto;
• le date di inizio e di fine per ciascuna attività;
• i vincoli tra le attività;
• gli eventuali percorsi critici, rappresentati nel precedente schema da box con il bordo più marcato, che rappresentano le sequenze di attività per le quali non sono ammessi ritardi, in quanto porterebbero ad un ritardo del progetto nel suo complesso.
Il diagramma di GANTT
Il diagramma di GANTT è lo strumento normalmente utilizzato per rappresentare la pianifi- cazione e la schedulazione di progetto. Esso viene, altresì, utilizzato per monitorare e valu- tare lo stato di avanzamento del progetto in relazione ai tempi previsti per le diverse atti- vità. Attraverso tale strumento è possibile, alle date fissate per il controllo, effettuare un confronto immediato fra il lavoro pianificato e quello effettivo e valutare gli eventuali ritardi e gli eventuali anticipi delle attività.
La rappresentazione tramite il GANTT consente di leggere in modo chiaro ed esaustivo lo stato di tutte le attività del progetto e di individuare i responsabili delle attività stesse per concordare azioni di recupero o rischedulare le attività. Questo tipo di report sugli avanza- menti delle attività è senza dubbio di immediata comprensione ed è molto utilizzato nella pratica.
Di seguito si riporta un esempio di diagramma di GANTT.
Attività A Attività B Attività C Attività D Attività E
Mesi progetto 1 2 3 5 6 7 8 9 10 11
La matrice delle responsabilità
50
E’ opportuno utilizzare la matrice delle responsabilità per associare i compiti ai coordinatori responsabili della loro esecuzione. La scelta di assegnare persone e responsabilità sulle atti- vità deve essere compiuta sulla base delle effettive competenze, conoscenze e capacità. La matrice delle responsabilità indica:
• alle persone, su cosa saranno impegnate a fare nel progetto, e con quale responsabi- lità;
• alle altre organizzazioni coinvolte nel progetto (Amministrazione, altri fornitori del- l’Amministrazione), quali attività, propedeutiche o comunque correlate a quelle asse- gnate nel contratto al fornitore, devono eseguire;
• ai responsabili del coordinamento delle attività, come sono allocati gli altri responsabili. La matrice delle responsabilità costituisce, inoltre, un forte elemento di motivazione delle per- sone, in quanto segnala il grado di partecipazione e di importanza di una risorsa nel progetto. Di seguito si riporta un tipico esempio di matrice delle responsabilità.
Work Breakdown Structure Livello 1 2 3 4 | Team di Progetto | |||
Xxxxxxx | Xxxxx | Verdi | Gialli | |
Sistema informativo del personale | X | |||
Gestione paghe e stipendi | X | |||
Analisi | X | |||
Analisi dati | X | |||
Analisi funzioni | X | |||
Integrazione d/f | X | |||
Progettazione | X | |||
Realizzazione | X | |||
Collaudo | X |
Il piano di progetto
Per ogni attività contrattualmente prevista dovrà essere predisposto dal Fornitore, e mante- nuto costantemente aggiornato, un piano di progetto che riporti attività, tempi e impegni.
Il piano è il risultato del processo di pianificazione, ossia di definizione delle attività da svolgere, di descrizione delle modalità con cui interagiscono e interdipendono, di definizio- ne e allocazione delle risorse nelle varie attività, di tempificazione e di definizione dei costi associati al lavoro. Il piano non è solo lo strumento di descrizione del progetto, ma rappre- senta anche un importante strumento di gestione del progetto: in esso devono essere pre- senti le informazioni utili per organizzare il lavoro, coordinare le risorse, controllare l’anda- mento del progetto, osservare con particolare attenzione le attività più critiche ai fini del conseguimento degli obiettivi prefissati.
51
La versione iniziale del piano di progetto deve essere prodotta dal Fornitore all’inizio delle attività progettuali e deve essere formalmente approvata dall’Amministrazione. In particola- re, l’Amministrazione dovrà verificare che esso sia coerente con i propri obiettivi e che recepisca quanto dichiarato dal Fornitore in fase di offerta. Sovente infatti a livello di capito- lato tecnico, oltre a richiedere in maniera esplicita lo svolgimento di determinate attività, viene data la facoltà al Fornitore di offrire attività aggiuntive, soluzioni particolari, anticipo nei tempi di esecuzione di particolari attività. Questi aspetti, che spesso contribuiscono ad indirizzare l’Amministrazione nella scelta di un’offerta, devono essere recepiti all’interno del piano di progetto.
Il piano di progetto non è un documento da produrre una tantum ma, al contrario, esso va mantenuto costantemente aggiornato, in quanto normalmente rappresenta lo strumento con cui periodicamente il Fornitore e l’Amministrazione verificano lo stato di avanzamento dei lavori, e concordano eventuali ripianificazioni e rimodulazioni di attività. La periodicità con cui il piano di progetto deve essere prodotto dal Fornitore è specificata a livello contrattuale e di solito dipende da fattori quali la complessità del progetto, la sua dimensione, l’impor- tanza per l’Amministrazione. Normalmente essa è mensile o bimestrale.
Anche le versioni del piano di progetto successive alla prima devono essere formalmente consegnate dal Fornitore ed approvate dall’Amministrazione. L’approvazione del piano da parte dell’Amministrazione potrebbe in alcuni casi rappresentare l’atto formale che autorizza il Fornitore a fatturare le attività consuntivate nel periodo di riferimento del piano, ma sareb- be più opportuno realizzare uno specifico documento che dettagli le milestone raggiunte, le attività realizzate o i servizi erogati e poi, conseguentemente, procedere alla fatturazione.
Un aspetto spesso trascurato nel piano di progetto è quello relativo al servizio di garanzia. Se contrattualmente è previsto un periodo di garanzia di 24 mesi come stabilito dalle nuove Normative europee, questo può essere visto come l’evento conclusivo del progetto. In que- sto caso il Fornitore dopo l’accettazione della fornitura dovrà assicurare, anche nel piano di progetto, la presenza delle risorse necessarie per coprire il periodo di garanzia. A tutela del- l’Amministrazione, è possibile riservare una piccola percentuale (ad esempio il 5%) dell’am- montare del contratto da corrispondere a conclusione della garanzia.
Nel capitolo 6 del presente manuale è riportata la struttura tipica del piano di progetto.
4.1.3. Misurare lo Stato Avanzamento Lavori (SAL)
Come accennato in precedenza, le versioni successive alla prima del piano di progetto nor- malmente rappresentano i documenti con cui contrattualmente viene formalizzato lo stato di avanzamento delle attività.
Dal punto di vista pratico, il Fornitore può utilizzare diversi criteri con cui misurare l’avan- zamento e quindi l’andamento delle attività di natura progettuale. Di seguito si fornisce un breve cenno a tali criteri, di cui in letteratura è possibile reperire maggiori informazioni.
Con questo criterio la percentuale di avanzamento di un’attività è posta a zero fino a che essa non sia completamente ultimata; al suo completamento essa viene posta a cento. Con tale criterio, di fatto, si ignora totalmente lo stato di un’attività fino a quando essa non viene ultimata. Pertanto, esso può essere utilizzato quando:
• non ha importanza seguire in dettaglio le modalità di realizzazione di una determinata attività;
• le attività vengono espletate in tempi molto contenuti.
52
Con il presente criterio la percentuale di avanzamento delle attività non ancora iniziate viene posta a zero, quella delle attività iniziate viene posta a cinquanta e quella delle attività
terminate viene posta a cento. Tale criterio risulta indicato nel caso di sviluppo di software. Il metodo introduce ‘errori sistematici’ nella stima del completamento delle attività, ossia sovrastima le attività appena iniziate e sottostima le attività prossime al completamento; come è possibile intuire, in media questi errori si compensano: infatti è difficile pensare ad un piano che preveda la maggior parte delle attività che iniziano nello stesso tempo. Que- sto metodo è particolarmente utile quando si hanno attività contenute nel tempo e quando il committente non necessita di informazioni dettagliate. Queste ultime possono essere richieste al Fornitore nel caso in cui si abbia evidenza di eventuali slittamenti o ritardi rispetto alla pianificazione approvata in precedenza.
La percentuale di avanzamento è data dalla percentuale di completamento delle unità ele- mentari che compongono un task. La caratteristica di questo criterio è la totalizzazione pro- gressiva dei singoli componenti, rapportata al totale. Questo metodo ha il pregio di essere particolarmente preciso e di fornire l’indicazione dell’evoluzione nel tempo dell’attività. Esso si usa quando si ha una visione della costituzione interna di un task e dei semilavorati, di cui il piano di progetto ha previsto la stima. Normalmente il metodo è applicabile per task di cui si dispone di un’analisi molto dettagliata e che abbiano output omogenei e misu- rabili.
La percentuale di avanzamento è posta uguale alla totalizzazione progressiva dei pesi pon- derati assegnati ad eventi specifici. La caratteristica principale di questo metodo è data dal fatto che al verificarsi di un dato evento la percentuale di avanzamento viene incrementata in maniera predefinita. Tale metodo si usa quando si ha una visione complessiva di un task, ma non si conoscono a fondo i dettagli. Il metodo è applicabile in caso di:
• esistenza di eventi significativi ai quali legare l’avanzamento percentuale;
• possibilità di certificare il verificarsi di eventi significativi in maniera incontestabile;
• task di lunga durata, con notevole incidenza economica.
Output proporzionale all’input
La percentuale di avanzamento è calcolata in base alla percentuale di risorse effettivamente consumate in una certa data rispetto alla quantità pianificata. Per poter utilizzare tale meto- do è necessario individuare le risorse significative da prendere in considerazione e l’effetti- vo consumo delle stesse. Il metodo viene usato quando è facile rilevare il consumo delle risorse che fanno scattare l’incremento della percentuale di avanzamento e quando tale rile- vazione presenta un buon livello di precisione. Normalmente esso è usato quando il ciclo produttivo adottato è stabile e quando vi è una produttività costante nel corso del tempo.
53
In questo caso la percentuale di avanzamento delle attività viene stimata direttamente da chi effettua la rilevazione. Il responsabile dell’attività fornisce direttamente la stima dell’avanzamen-
to, congiuntamente all’indicazione del lavoro erogato; non esiste una procedura di rilevazione definita. Tale metodo risulta poco oneroso, ma al tempo stesso molto soggettivo. Esso dovreb- be essere usato solo quando il committente ha in qualche modo la possibilità di controllare la stima fornita dal Fornitore; purtroppo, invece, esso è usato molto spesso, favorendo la cosid- detta “sindrome del quasi completato”, ovvero l’avanzamento è molto rapido all’inizio, per poi rallentare man mano che la percentuale di avanzamento si avvicina al cento per cento.
Il metodo di misurazione Earned Value
L’Earned Value è un metodo di valutazione complessiva di un progetto, sia in termini di costi che in termini di tempi, basato sull’utilizzo delle tecniche precedentemente descritte. Esso si fonda sul concetto di “valore assorbito” (Earned Value) da un certo compito, inteso come valorizzazione ai costi di budget dell’attività già realizzata alla data.
L’Earned Value si differenzia significativamente da altri metodi utilizzati per misurare l’avan- zamento di un progetto, quali ad esempio il metodo della percentuale di completamento e il metodo delle unità di completamento. Entrambi questi metodi intendono esprimere in modo quantitativo lo stato di avanzamento di un progetto, il primo mediante una percen- tuale che esprime la frazione complessiva del progetto che è stata realizzata, il secondo attribuendo dei punteggi che esprimono il grado di completamento di ciascuna singola atti- vità del progetto (dove il punteggio 1, ad esempio, esprime il fatto che l’attività è stata ini- ziata, e i punteggi successivi, fino ad un massimo ad esempio di 4, esprimono il grado di avanzamento dell’attività esaminata).
L’Earned Value, invece, rappresenta il lavoro realmente eseguito valorizzato ai costi previsti dal budget.
Il metodo implica la determinazione dei seguenti valori:
• il costo previsionale o di budget delle attività programmate: BCWS (Budgeted Cost of Work Scheduled);
• il costo a valori previsionali o di budget associato alle attività di progetto completate: BCWP (Budgeted Cost of Work Performed);
• il costo consuntivo associato alle attività di progetto effettivamente completate: ACWP (Actual Cost of Work Performed).
Lo stato di avanzamento raggiunto dal progetto (Earned Value) è misurato mediante la grandezza BCWP, che esprime appunto la dimensione economica del lavoro completato espressa con i medesimi criteri utilizzati per valorizzare il budget di progetto.
La valorizzazione delle tre grandezze sopra esposte consente di determinare i seguenti indi- catori:
• lo scostamento di costo (cost variance), dato dalla differenza tra i costi previsti a bud- get per il lavoro eseguito e il costo effettivo per le attività completate, ovvero:
scostamento di costo (cost variance) = BCWP – ACWP
ovvero
54 CPI (Cost Performance Index) = BCWP / ACWP
dove CPI rappresenta un indicatore delle performance di costo che esprime un rendi- mento positivo se superiore a 1 e viceversa;
• lo scostamento di schedulazione (schedule variance) o di performance dei tempi, dato dalla differenza tra i costi previsti a budget per le attività completate e il costo previsto a budget per il lavoro programmato, ovvero:
scostamento di schedulazione (schedule variance) = BCWP – BCWS ovvero
SPI (Schedule Performance Index) = BCWP : BCWS
dove SPI rappresenta un indicatore della performance dei tempi, che esprime un rendi- mento positivo se superiore a 1 e viceversa.
L’opportuna combinazione di questi valori, quindi, determina lo scostamento dei costi e dei tempi e ne quantifica l’indice di efficienza. Inoltre, l’analisi grafica dell’evoluzione di questi valori su più periodi di rendiconto consente di ottenere le stime “al completamento” e “a finire” delle attività.
Nella figura che segue è riportato un esempio delle informazioni che è possibile desumere da una rappresentazione grafica degli indicatori ricavabili attraverso il metodo dell’Earned Value.
BCWP
ACWP
BCWS
55
Dalla rappresentazione grafica riportata si può desumere l’entità del ritardo temporale nel- l’avanzamento del progetto se si confronta la curva di costo-tempo relativa al lavoro effetti- vo con la medesima curva relativa al lavoro previsionale. In particolare, il punto B del grafi-
co esprime il livello di costo raggiunto alla data di riferimento sulla base del lavoro effetti- vamente svolto. Il punto A esprime, invece, in quale momento temporale si sarebbe dovuto sostenere lo stesso livello di costi espresso dal punto B. La differenza tra i punti A e B lungo l’asse orizzontale esprime, pertanto, il ritardo temporale nello svolgimento complessi- vo del progetto.
Quella qui riportata non è l’unica rappresentazione grafica che è possibile ottenere con gli indicatori descritti. Ve ne sono anche altre, dalle quali è possibile ricavare altre indicazioni, per le quali si rimanda a testi specifici.
4.1.4. Governare la Qualità
Il piano di qualità definisce le caratteristiche qualitative cui deve sottostare l’intera fornitura. Come indicato nella deliberazione n. 49/2000 del CNIPA, è necessario che l’Amministrazio- ne richieda al Fornitore, come parte integrante dell’offerta tecnica, la predisposizione di un piano della qualità, che:
• fornisca lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del sistema qualità del Fornitore già esistenti;
• espliciti le disposizioni organizzative e metodologiche adottate dal Fornitore, allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;
• dettagli i metodi di lavoro messi in atto dal Fornitore, facendo riferimento o a proce- dure relative al proprio sistema, e per ciò descritte nel manuale qualità; o a procedure sviluppate per lo specifico contrattuale, a supporto delle attività in esso descritte, in questo caso da allegare al piano;
• garantisca il corretto e razionale evolversi delle attività contrattualmente previste, non- ché la trasparenza e la tracciabilità di tutte le azioni messe in atto dalle parti in causa, il Fornitore, il committente, l’eventuale organismo di ispezione accreditato dall’Ammi- nistrazione.
E’ buona norma che l’Amministrazione definisca uno standard per la stesura del documento e che sia richiesto al Fornitore di seguire tale standard in fase di presentazione del docu- mento stesso. La stessa deliberazione CNIPA n. 49/2000 individua l’indice tipo del piano di qualità, che è riportato nel presente manuale al capitolo 6.
Poiché il piano della qualità è predisposto in fase di offerta, si deve prevedere contrattual- mente che esso sia revisionato a valle della firma del contratto, per riflettere le eventuali variazioni intervenute durante il procedimento di selezione del Fornitore. Infatti, durante tale procedimento, il Fornitore che si aggiudica la procedura concorsuale espletata dall’Ammini- strazione, potrebbe aver offerto proposte migliorative rispetto a quanto richiesto dall’Ammi- nistrazione a livello di capitolato tecnico. Laddove tali proposte migliorative abbiano rilevan- za dal punto di vista del piano di qualità è necessario che tale documento sia opportuna- mente modificato.
56
Il piano di qualità dovrà essere aggiornato solo in caso di necessità, ovvero a seguito di significativi cambiamenti di contesto in corso d’opera. Tuttavia è utile sottoporre il docu- mento a verifiche periodiche per verificarne la sua applicabilità nel corso del tempo.
Nel caso di obiettivi particolarmente critici nell’ambito di un progetto, oltre al piano genera- le della qualità, può essere richiesto al Fornitore di presentare ulteriori piani di qualità riferi- ti, appunto, ad obiettivi specifici.
In tali piani dovranno essere evidenziate le differenze o le deroghe da quanto previsto nel Piano della Qualità Generale.
Il piano di qualità, e gli eventuali piani specifici di obiettivo, devono essere sottoposti ad approvazione formale da parte dell’Amministrazione. In particolare, l’Amministrazione dovrà verificare che essi siano coerenti con i livelli di qualità attesi dall’Amministrazione e dettagliati nell’ambito del capitolato tecnico e del contratto. Inoltre, sarà necessario verifica- re che nel documento siano recepite eventuali proposte migliorative presenti nell’offerta del Fornitore.
La condivisione ed approvazione del documento riveste una particolare importanza in quanto, di fatto, a partire dal piano di qualità e sulla base di quanto in esso riportato, scatu- riranno impegni precisi sia per il Fornitore che per l’Amministrazione. In particolare:
• il Fornitore dovrà essere in grado di garantire gli impegni assunti e di rispettare i livelli di qualità definiti;
• l’Amministrazione dovrà essere in grado di verificare che quanto dichiarato ed offerto dal Fornitore sia effettivamente rispettato.
Pertanto, a partire dal piano di qualità approvato, scaturiranno impegni precisi per le parti. Nell’ambito dell’Amministrazione dovranno essere presenti le competenze e l’organizzazione adeguate per poter verificare il rispetto, da parte del Fornitore, dei livelli qualitativi offerti.
Tipicamente, nell’ambito delle attività di natura progettuale, i livelli di qualità della fornitura si estrinsecano in indicatori di qualità, che possono essere di diverso tipo a seconda della tipologia della fornitura. Per ogni indicatore di qualità sono previsti dei valori di soglia che devono essere rispettati dal Fornitore. Per attività di sviluppo software, ad esempio, si pos- sono prevedere indicatori come quelli di seguito riportati (si tratta di un’elencazione esem- plificativa e non esaustiva):
• tasso di scostamento casi di test: è la percentuale di test eseguiti con successo, rispetto al numero di test previsti nelle specifiche di test approvate dall’Amministrazione;
• grado di copertura funzionale: è la percentuale di funzioni sviluppate rispetto a quelle richieste dall’utente in un certo lasso di tempo;
• grado di completezza della documentazione: è la percentuale di funzioni descritte nella documentazione rispetto a quelle sviluppate;
• difettosità nel primo anno di esercizio: è il numero dei malfunzionamenti di classe 1 o 2 rilevati sul prodotto nel primo anno successivo al rilascio in esercizio;
57
• difettosità in collaudo: è la percentuale del numero di malfunzionamenti riscontrati in fase di collaudo rispetto al numero totale di malfunzionamenti riscontrati durante l’in- tero ciclo di vita adottato per la realizzazione del software.
• xxxxx di commenti: è la percentuale del numero di commenti sul volume totale del codice sorgente;
• codice inerte: è la percentuale di codice inerte rispetto al totale del codice sorgente;
• difettosità rilevata nei 3 mesi successivi ad una modifica al software: è il numero di malfunzionamenti emersi nei 3 mesi successivi ad una modifica al software dipendenti dall’intervento effettuato;
• grado di comprensione delle funzioni da parte dell’utente: è la percentuale del nume- ro delle funzioni comprese dall’utente rispetto al numero totale di funzioni.
In corso di esecuzione delle attività contrattuali il Fornitore dovrà rendicontare periodica- mente all’Amministrazione sul rispetto o sul mancato rispetto dei livelli qualitativi offerti e formalizzati nel piano di qualità. Lo strumento con cui il Fornitore dovrà fornire evidenza sull’andamento dei diversi indicatori di qualità è un documento, che potrebbe essere chia- mato “Misure inerenti gli indicatori di qualità”, che deve essere formalmente consegnato dal Fornitore ed approvato dall’Amministrazione.
In via preliminare il Fornitore dovrà dare evidenza all’Amministrazione sul processo e sulle modalità di misurazione che intende adottare per il monitoraggio dei diversi indicatori; tale processo e tali modalità dovranno essere condivisi dall’Amministrazione. Questo aspetto riveste una particolare importanza per evitare che vi siano ambiguità nelle modalità di cal- colo dei diversi indicatori.
La periodicità con cui dovrà essere prodotto il documento “Misure inerenti gli indicatori di qualità” può variare da caso a caso ma, in generale, essa dovrebbe essere compresa tra il trimestre ed il semestre.
Il documento “Misure inerenti gli indicatori di qualità” dovrebbe contenere, per ciascun indicatore oggetto di monitoraggio, le seguenti informazioni:
• codice e nome dell’indicatore;
• periodo di riferimento;
• applicabilità nel periodo;
• formula di calcolo;
• dati elementari utilizzati per la misurazione;
• valore rilevato nel periodo di riferimento;
• valore di soglia;
• indicazione se il valore rilevato da luogo a rilievo o penale;
• importo dell’eventuale penale da applicare;
• note.
L’Amministrazione dovrà essere in grado di verificare che gli indicatori riportati nel rapporto sui livelli di servizio rispecchino fedelmente la realtà. A tal fine essa potrà:
• richiedere al Fornitore di dare evidenza della veridicità degli indicatori forniti e del rispetto delle modalità di determinazione degli stessi precedentemente concordate;
• effettuare controlli a campione.
58
Nel caso in cui dalle rendicontazioni periodiche emerga il mancato rispetto dei requisiti qualitativi richiesti, l’Amministrazione dovrà applicare le sanzioni contrattualmente previste.
In generale esse possono essere di due tipi:
• penali;
• rilievi.
E’ bene osservare che le penali non hanno come obiettivo quello di far risparmiare il commit- tente in funzione di un minore livello qualitativo dei prodotti forniti. D’altra parte, difficilmen- te il valore delle penali può essere commisurato al danno realmente subito, per il quale lo strumento contrattuale più adeguato è quello delle clausole di responsabilità e delle cauzioni. Nei contratti sono comunque di norma inserite penali che servono a ridurre il corrispettivo, modulandolo proporzionalmente alla minore qualità del prodotto effettivamente ricevuto. Poiché il contratto definisce un corrispettivo commisurato, appunto, alla qualità del prodot- to ricevuto, è una logica conseguenza che il committente non debba pagare per quello che non ha ricevuto, qualora il livello qualitativo sia inferiore a quello atteso.
Tuttavia, le penali devono essere viste, all’interno di un accordo tra le parti, anche come uno strumento di governo dei contratti, a disposizione del committente. Attraverso questo strumento, il committente deve poter prevenire i danni maggiori, utilizzandole come segna- le di allarme per il Fornitore che provvede a predisporre le più adeguate azioni correttive a fronte di eventuali inadempienze. La formalizzazione dell’allarme, evidenziata dal sanziona- mento, responsabilizza il Fornitore a tutti i livelli di gestione del contratto.
I rilievi sono le azioni di avvertimento effettuate dall’Amministrazione al Fornitore, conse- guenti il non rispetto di taluni indicatori di qualità. Essi consistono in comunicazioni formali al Fornitore che non prevedono di per sé l’applicazione di penali, ma costituiscono un avvertimento sugli aspetti critici della fornitura e, se reiterati e accumulati, possono dare luogo all’applicazione di penali.
Le due tipologie di sanzioni, penali e rilievi, possono essere entrambe previste contrattual- mente. La scelta se prevedere l’applicazione dell’una o dell’altra dipende dall’importanza dei singoli indicatori di qualità. Tipicamente, il mancato rispetto degli indicatori considerati più importanti dall’Amministrazione comporterà direttamente l’applicazione di penali, men- tre il mancato rispetto degli indicatori considerati meno importanti dovrebbe comportare la formalizzazione di rilievi.
Nell’ambito delle attività di governo della qualità si suggerisce all’Amministrazione, qualora si avvalga di un Fornitore in possesso della certificazione ISO, di prevedere contrattualmen- te clausole che consentano all’Amministrazione stessa di poter procedere, in qualsiasi momento, alle verifiche ispettive, svolte nel rispetto di quanto prescritto dalla serie di norme EN ISO 10011, imponendo al Fornitore di prestare la propria collaborazione per consentirne lo svolgimento.
4.2. ATTIVITÀ DI COMPETENZA DELL’AMMINISTRAZIONE
4.2.1 Controllare la pianificazione e lo stato di avanzamento lavori
59
Tutte le tecniche e gli strumenti che il Fornitore utilizza durante la fase di pianificazione del progetto e di consuntivazione periodica dello stato di avanzamento lavori devono essere
conosciuti dall’Amministrazione, al fine di esercitare il proprio ruolo di controllo e di moni- toraggio del progetto. Infatti, nel governo dei contratti di fornitura, le principali attività di competenza dell’Amministrazione riguardano i processi di controllo e verifica del raggiungi- mento degli obiettivi contrattuali stabiliti in fase di pianificazione, nel rispetto dei tempi, dei costi e degli standard di qualità concordati.
Per poter espletare questi compiti, l’Amministrazione deve partecipare alle prime fasi del ciclo di vita del progetto ed, in particolare, alla definizione ed all’approvazione dell’ambito e degli obiettivi del progetto.
La definizione chiara e completa degli obiettivi e dell’ambito del progetto è la condizione necessaria pere l’efficacia dell’attività di pianificazione e di controllo.
La funzione del controllo è volta a monitorare l’attività di sviluppo del progetto, a rilevare gli scostamenti tra ciò che si sta verificando e ciò che è stato programmato e ad analizzare le cause che hanno determinato detti scostamenti.
L’attività di controllo non deve essere limitata ad una verifica a posteriori delle attività rea- lizzate dal Fornitore, ma deve, invece, porsi l’obiettivo di scoprire ed evidenziare i problemi affinché siano risolti in tempo utile. Pertanto il controllo, per essere efficace, non deve limi- tarsi ad avallare l’accettazione di una fornitura, ma contribuire a che la fornitura stessa sod- disfi in pieno le esigenze dell’ Amministrazione committente.
L’obiettivo dell’attività di controllo da parte dell’Amministrazione è, nel breve termine, quel- lo di identificare gli scostamenti dalle prescrizioni contrattuali. Da questo obiettivo discen- dono due tipi di azioni:
• identificare azioni preventive e correttive atte a superare le anomalie rilevate e a man- tenere il progetto nei tempi e nei costi previsti;
• modulare l’adeguamento delle tariffe, inizialmente calcolate sulla base di una stima di volumi e prestazioni attese, e delle penali sullo scostamento rispetto ai valori presta- zionali concordati.
Nel lungo termine l’attività di controllo è legata all’evoluzione delle forme contrattuali. Da questo obiettivo discende l’azione di rilevamento dei dati a consuntivo e la scelta dei volu- mi e dei livelli prestazionali da inserire nella rinegoziazione del contratto o nella stesura del contratto successivo.
Il controllo del progetto è un’attività ciclica nella quale si confrontano i consuntivi con la baseline di riferimento e si correggono le deviazioni. Il compito dell’Amministrazione, in qualità di controller del progetto, consiste nei seguenti passi:
• rilevare le informazioni sullo stato di avanzamento. Tali informazioni sono rilevate tipicamente in occasione dell’emissione periodica del piano di progetto da parte del Fornitore e durante le riunioni periodiche del progetto ed includono:
• date di inizio e fine delle singole attività elementari;
• lo stato delle singole attività elementari (Non-iniziata, Iniziata, Completata);
• lo stato delle milestones più significative;
• i progressi (percentuale di completamento, stima a finire).
60
• analizzare le variazioni: dopo aver aggiornato le informazioni di stato, occorre xxx- xxxxxxx l’impatto di qualsiasi deviazione sulla pianificazione e sui costi.
• revisionare e ripianificare il progetto: una volta analizzate le variazioni, occorre intraprendere le azioni necessarie nella residua parte del progetto, aggiornando la pia- nificazione.
Anche il controllo dei costi, come quello della schedulazione, viene esercitato dall’Ammini- strazione in sede di verifica dello stato di avanzamento per identificare scostamenti signifi- cativi tra le spese effettive e il budget e per intraprendere misure correttive. Il controllo dei costi richiede:
• la definizione iniziale dei budget per le singole attività;
• la misurazione delle spese a fronte del budget e l’identificazione degli scostamenti;
• l’accertamento della correttezza delle spese;
• l’attivazione di misure appropriate di controllo qualora esistano degli scostamenti di budget.
I sistemi di controllo basati sul valore assorbito (Earned Value) (vedi par. 4.1.2) rappresen- tano per l’Amministrazione uno strumento efficace di controllo degli aspetti che riguardano le performance contrattuali, quali ad esempio:
• la documentazione delle richieste di pagamento in corso d’opera, con il raffronto dei costi sostenuti e del corrispondente valore assorbito;
• il rendiconto dell’avanzamento, rispetto al piano progettuale e alle sue milestone;
• la convalida della metodologia di stima sulla quale si basa il controllo dell’avanzamen- to del progetto;
• l’analisi degli scostamenti;
• le informazioni da fornire ai responsabili finanziari del progetto.
Per quanto riguarda il controllo dell’avanzamento delle attività progettuali si suggerisce inol- tre all’Amministrazione di richiedere al Fornitore di utilizzare metodi semplici, quali quelli indicati al paragrafo 4.1.2 (cinquanta/cinquanta e milestone intermedie). Qualora, invece, l’Amministrazione si avvalga di un ‘monitore’ è possibile usare metodi più precisi ed artico- lati da concordare con il Fornitore.
4.2.2. Gestire la Comunicazione tra Amministrazione e Fornitore
La comunicazione tra Amministrazione e Fornitore rappresenta un importante elemento per il successo delle iniziative progettuali. In generale essa può essere di due tipi:
• di natura contrattuale: consiste negli adempimenti contrattualmente previsti dalle parti;
• di natura extracontrattuale: consiste nello scambio di informazioni finalizzato alla scel- ta tra diverse soluzioni progettuali, alla condivisione di decisioni, al superamento di criticità e più in generale al raggiungimento degli obiettivi progettuali.
La comunicazione di natura extracontrattuale può essere:
61
• estemporanea;
• programmata.
La comunicazione di natura estemporanea consiste nei contatti frequenti ed informali che avvengono tra le parti per informarsi reciprocamente su notizie inerenti il progetto. Essa garantisce l’allineamento rapido tra l’Amministrazione ed il Fornitore su problematiche di natura tecnica e, in generale, quanto più è frequente tanto più è indicativa dell’interesse e dell’impegno delle parti sul progetto. Normalmente tale tipo di comunicazione può avveni- re, oltre che mediante incontri diretti laddove Amministrazione e Fornitore operino nella medesima sede, con strumenti quali il telefono e la posta elettronica. Sebbene si tratti di contatti informali è preferibile l’utilizzo di strumenti che consentano di tenere traccia delle informazioni scambiate, in modo tale che le stesse, all’occorrenza, possano essere riutilizza- te. A tal fine sarebbe utile privilegiare, per quanto possibile, l’utilizzo della posta elettronica. Oltre al normale e costante confronto tra i diversi attori, una prassi spesso utilizzata con successo è quella di effettuare riunioni di progetto con una determinata periodicità (comu- nicazione programmata). La periodicità può essere variabile in funzione della durata del progetto, delle criticità che si verificano in corso d’opera, dell’importanza del progetto per gli utenti. In funzione di questi aspetti la periodicità ottimale può essere compresa tra la set- timana ed il mese.
Per le riunioni di progetto il responsabile dell’Amministrazione predispone l’elenco degli argomenti di cui discutere, in base alla sua conoscenza delle criticità del momento e delle esigenze degli utenti. L’elenco degli argomenti di discussione deve comunque essere condi- viso dal responsabile del Fornitore e dagli utenti interessati, i quali hanno facoltà di propor- re modifiche od integraziooni. Oltre ai responsabili dell’Amministrazione e del Fornitore, alle riunioni periodiche di progetto dovrebbero partecipare tutti coloro che possono essere utili nella discussione degli argomenti all’ordine del giorno: utenti del sistema o di parte di esso, risorse del Fornitore particolarmente skillate sugli argomenti di discussione, rappre- sentanti di altri progetti per diversi motivi correlati, ecc.
In generale, le riunioni periodiche di progetto devono configurarsi come incontri di tipo “decisionale”, nel senso che a tali riunioni devono partecipare tutti coloro che siano in grado di assumere decisioni sugli argomenti all’ordine del giorno e dalle quali scaturiscano attività operative per l’Amministrazione e per il Fornitore. Di seguito si riporta un elenco indicativo e non esaustivo di possibili argomenti di discussione da trattare nel corso delle riunioni periodiche di progetto:
• decisioni su scelte di analisi in caso di disaccordo tra utenti diversi;
• valutazione di nuove esigenze degli utenti e decisione sulla loro realizzazione;
• valutazione di elementi di rischio e predisposizione di apposite contromisure;
• decisione su avviamento in esercizio di nuove funzionalità/processi ed individuazione delle relative modalità;
• punto della situazione su obiettivi particolarmente critici o rilevanti.
62
Al fine di tenere traccia delle decisioni assunte in sede di riunione e di monitorare lo svolgi- mento delle azioni decise da parte dei diversi attori, è opportuno che i resoconti delle riu- nioni stesse siano condivisi e formalizzati.
Nell’ambito della comunicazione un aspetto rilevante è rappresentato dall’utilizzo, da parte dell’Amministrazione, del meccanismo dell’escalation.
Il responsabile del progetto dell’Amministrazione può utilizzare l’escalation sia nei confronti del Fornitore, sia all’interno dell’Amministrazione stessa. Tipicamente, nei confronti del For- nitore essa viene utilizzata in caso di insorgenza di problemi, di competenza appunto del Fornitore, che non vengono risolti con la dovuta tempestività ed efficacia da parte del grup- po di progetto e che pertanto richiedono l’intervento da parte di un livello decisionale gerarchicamente più elevato nell’ambito della struttura del Fornitore, al fine di sollecitare in modo adeguato il gruppo di progetto.
All’interno dell’Amministrazione il responsabile del progetto normalmente si rivolge al pro- prio responsabile gerarchico per due ordini di motivi:
• per l’assunzione di decisioni che esulano dalla propria competenza o che per l’impor- tanza che rivestono, richiedono un conforto da parte di un livello decisionale più ele- vato;
• per la risoluzione di problemi interni all’Amministrazione che richiedono un interven- to dall’alto.
Il rischio di un progetto può essere definito come la eventualità di non riuscire a raggiunge- re uno o più degli obiettivi specificati e concordati per esso, con i conseguenti danni che ne derivano.
Il rischio principale cui va incontro un progetto è il suo fallimento, ossia il mancato rag- giungimento dei benefici attesi. Tuttavia, sono significativi anche altri rischi, come la lievita- zione dei costi (costi non previsti e costi sottostimati) e l’allungamento dei tempi (fasi non previste, durata delle fasi sottostimata).
La gestione del rischio è onerosa in termini di tempo, impegno e denaro ma è fondamenta- le per il successo di un progetto e deve essere disciplinata da regole e non lasciata al caso. In questo contesto, il ruolo di chi gestisce un contratto è quello di identificare e compren- dere i fattori di rischio e, quindi, di pianificarne la gestione incorporandola nella pianifica- zione generale e supportandola con opportuni strumenti contrattuali.
Per gestire il rischio è necessario definire delle procedure che dovranno facilitare i soggetti incaricati di individuare, quantificare, prevenire e controllare gli eventi rischiosi.
Nella realtà, purtroppo, la valutazione del rischio è un’attività che o non viene svolta in modo esplicito oppure viene svolta solo all’inizio del progetto. I rischi, invece, cambiano col passare del tempo nella loro natura, nella probabilità di manifestazione così come nella entità del danno che possono procurare ed è, quindi, necessario reiterare il processo di valutazione.
Le attività di gestione del rischio dovranno essere svolte sia in predeterminati momenti del Ciclo di Vita del progetto (Studio di Fattibilità, Esame delle Specifiche Funzionali, Rilasci parziali) sia ogni qual volta lo si ritenga necessario per via della variazione delle condizioni progettuali.
Gestire il rischio significa essenzialmente eseguire tre passi fondamentali:
63
• prima di tutto, individuare i fattori di rischio e prevedere gli eventi rischiosi che, mani- festandosi, possono ostacolare il raggiungimento degli obiettivi progettuali;
• successivamente, analizzare e classificare i fattori di rischio individuati, definendo quali saranno oggetto di una risposta pianificata;;
• infine, progettare e mettere in azione delle contromisure che permettano di monitora- re per intervenire nel modo più appropriato sui singoli elementi di rischio; nello stes- so tempo, bisogna valutare l’efficacia delle contromisure adottate per poter verificare che il rischio sia rientrato all’interno dei valori di soglia definiti e, eventualmente, ope- rare le opportune modifiche.
Individuazione dei fattori di rischio
Una classificazione indicativa dei più frequenti fattori di rischio che si presentano in un pro- getto prevede la suddivisione in classi che fanno riferimento sia al contesto applicativo che a quello organizzativo di un progetto e che derivano, in genere, dal grado di complessità e di incertezza del progetto:
• Fattori derivanti dalla complessità:
• Complessità gestionale;
• Dimensioni del progetto;
• Aspetti contrattuali.
• Fattori derivanti dall’incertezza:
• Incertezza dei requisiti;
• Innovazione tecnologica.
La complessità gestionale riguarda essenzialmente le problematiche di carattere organizzati- vo e operativo delle amministrazioni. I fattori comprendono:
• Importanza strategica del progetto;
• Interfacciabilità con altri progetti;
• Utenza/Committenza eterogenea;
• Forte impatto sull’organizzazione, sulle procedure, sulla definizione dei ruoli;
• Complessità nella definizione dei processi;
• ….
Le dimensioni del progetto riguardano il numero di risorse umane ed economiche coinvol- te. I fattori da considerare sono:
• Numero di stakeholder;
• Numero di mesi/persona previsti;
• Dimensioni del sistema informativo (espresse per esempio mediante il metodo dei
Function point);
• Costo del progetto;
• ….
Gli aspetti contrattuali riguardano:
64
• Vincoli legali e norme;
• Clausole relative alla manutenzione;
• Rapporti con il Fornitore relativamente a:
• Personalizzazioni;
• Incremento delle prestazioni;
• Livelli di servizio garantiti;
• Coinvolgimento di terze parti;
• …
L’incertezza dei requisiti rappresenta nell’ambito della pubblica amministrazione il fattore di rischio più ricorrente e riguarda:
• la stabilità dell’ambiente e dei processi;
• la chiarezza e la stabilità dei requisiti;
• la conoscenza ed esperienza del contesto applicativo ed organizzativo da parte degli utenti/committenti;
• il livello di dettaglio nella formalizzazione delle informazioni e dei processi;
• …
Il rischio rappresentato dall’innovazione tecnologica riguarda principalmente gli aspetti tec- nici del progetto. Può dipendere dai seguenti elementi:
• utilizzo di nuovo hardware/software di base;
• utilizzo di nuovi strumenti di sviluppo;
• integrazione di tecnologie eterogenee;
• affidabilità e mantenibilità del prodotto;
• facilità di evoluzione e di personalizzazione;
• scalabilità;
• misurabilità delle prestazioni;
• installazioni multiple;
• gestione della configurazione;
• incoerenza/conflitto con l’architettura preesistente;
• …
Analisi del rischio
L’obiettivo di questa attività è quello di dare una base, per quanto possibile, misurabile alla valutazione del rischio generale di progetto.
Il risultato finale dell’analisi, condotta sia dal punto di vista qualitativo (priorità dei rischi classificati secondo la probabilità che si verifichino) sia dal punto di vista quantitativo (esame dell’impatto degli effetti generati dagli eventi di rischio) è un voto sulla pericolosità di ogni elemento di rischio rispetto alla riuscita del progetto.
65
Lo strumento attraverso il quale si arriva a tale determinazione è la “matrice di probabilità e impatto” (vedi § 6.1.3), che specifica le combinazioni di probabilità e impatto che portano alla classificazione dei rischi in priorità bassa, media o alta.
Fattori di rischio | Alto | Medio | Basso |
Complessità gestionale | |||
Importanza strategica del progetto | X | ||
Interfacciabilità con altri progetti | X | ||
… | |||
Valutazione della classe | X | ||
Dimensioni del progetto | |||
Numero di stakeholder | X | ||
Numero di mesi/persona previsti | X | ||
… | |||
Valutazione della classe | X | ||
Vincoli legali e norme | X | ||
Clausole relative alla manutenzione | X | ||
… | |||
Valutazione della classe | X | ||
Incertezza dei requisiti | |||
Stabilità dell’ambiente e dei processi | X | ||
Chiarezza e stabilità dei requisiti | X | ||
… | |||
Valutazione della classe | X | ||
Innovazione tecnologica | |||
Utilizzo di nuovo hardware/software di base | X | ||
Utilizzo di nuovi strumenti di sviluppo | X | ||
… | |||
Valutazione della classe | X | ||
Valutazione generale del progetto | X |
Tale classificazione porta alla definizione di tre classi di rischio all’interno delle quali si pos- sono classificare i progetti:
• Classe A: Il prodotto/servizio è caratterizzato da una elevata criticità dovuta alle possi- bili responsabilità connesse all’importanza dei dati elaborati ed al loro potenziale impatto sull’esterno. Un malfunzionamento del prodotto/servizio può provocare danni gravi e diffusi verso terzi o causare una consistente perdita di immagine;
66
• Classe B: Il prodotto/servizio implica limitate responsabilità in caso di malfunziona- menti pur trattando dati rilevanti e informazioni riservate. Un malfunzionamento del prodotto può provocare danni gravi o causare una certa perdita di immagine;
• Classe C: Il prodotto/servizio gestisce informazioni non critiche e un eventuale mal- funzionamento comporta la sola perdita del lavoro svolto o danni limitati.
Modalità di gestione del rischio
Esistono, in generale, due possibili strategie nell’affrontare i rischi di un progetto.
1. La gestione dell’emergenza, ossia non prevedere alcun task specifico ma semplicemente accantonare una riserva di risorse (temporali ed economiche) per rispondere entro dei limi- ti tollerabili al presentarsi di un evento sfavorevole;
2. La mitigazione del rischio, ossia un processo di sviluppo delle alternative e di determi- nazione delle azioni che consentono di ridurre gli impatti e/o di ridurre le probabilità di insuccesso degli obiettivi del progetto.
Ovviamente, la seconda strategia è auspicabile per progetti appartenenti a classi di rischio elevato e, tra le azioni che permettono di minimizzare l’impatto che i singoli elementi di rischio possono avere sulla riuscita generale del progetto, assumono particolare importanza le scelte relative alla:
• segmentazione del progetto;
• definizione di un piano di lavoro che comprenda specifici punti di decisione;
• definizione delle modalità di controllo del progetto.
La segmentazione del progetto è un approccio generale alla realizzazione di un progetto e rappresenta la scelta di non effettuare il progetto stesso in una soluzione unica bensì di adottare una strategia di divisione del progetto in sottoprogetti stabilendo degli obiettivi intermedi più facilmente controllabili.
In questo ambito, le modalità di realizzazione individuate sono:
• Realizzazione incrementale. La realizzazione ed il collaudo avvengono per parti suc- cessive, ogni parte contiene un sottoinsieme delle funzionalità e dei servizi previsti dal progetto generale. Questa modalità è maggiormente indicata per situazioni con fattori di rischio derivanti dalla complessità e richiede che i requisiti siano completamente definiti prima dell’avvio della realizzazione e che rimangano invariati nel corso delle successive installazioni.
• Realizzazione evolutiva. La realizzazione ed il collaudo avvengono per versioni suc- cessive e ogni versione può contenere o tutte le funzionalità del progetto o un loro sottoinsieme. Questa modalità si applica a progetti nei quali i fattori di rischio deriva- no dall’incertezza ed i requisiti sono influenzati dal collaudo o dalla sperimentazione.
La definizione dei punti di decisione consiste nella determinazione di momenti specifici in cui si prenderanno decisioni su come proseguire le attività stabilendo dei punti fermi su cui basare gli ulteriori sviluppi. In tal caso, dovranno essere previste delle modalità contrattuali coerenti con tale strategia individuando dei prodotti intermedi ai quali associare la conclu- sione di un task e la cui approvazione formale consenta l’avvio del task successivo.
Gli esempi più diffusi di prodotti intermedi e relativi punti di decisione sono:
67
• Documenti di definizione dei requisiti;
• Documenti di definizione delle specifiche di dettaglio;
• Produzione di prototipi;
• Produzione di un sistema sperimentale o pilota che consenta una verifica intermedia per una successiva versione finale.
La definizione delle modalità di controllo del progetto consiste nella valutazione dell’effica- cia e dell’efficienza dimostrata sul campo dal piano delle attività previste per la gestione del rischio al fine di confermarne la validità o di innescare una fase di revisione del sistema.
Il controllo del progetto si attua essenzialmente tramite l’individuazione degli standard di realizzazione e la verifica sullo stato di avanzamento delle attività del progetto.
Nell’ambito della realizzazione di progetti, considerato che il rischio principale è che il pro- getto non si concluda nei tempi preventivati e con i costi previsti, assume particolare importanza l’utilizzo di misure appropriate di controllo sull’avanzamento delle attività.
Naturalmente, occorre utilizzare dei criteri il più possibile oggettivi di valutazione dell’avan- zamento reale delle attività e di misura dell’impegno effettivamente profuso. La percentuale di avanzamento è rilevabile con diversi criteri e la precisione del rilevamento è sempre fun- zione dei dati resi disponibili dal Fornitore, del costo della rilevazione e della valenza dei dettagli ottenibili.
Il ricorso a queste tecniche tipiche del “project management” (analisi Earned-Value, la tec- nica delle milestone, delle unità completate, etc..) è sempre raccomandabile poiché le stime basate su analisi soggettive, non comprovate, sulla percentuale di completamento di un’atti- vità sono poco attendibili e difficilmente individuano in tempo utile la presenza di scosta- menti rispetto alla pianificazione.
I sistemi di controllo rappresentano per l’amministrazione committente uno strumento effi- cace di controllo dei fornitori e degli aspetti che riguardano le performance contrattuali quali, ad esempio:
• la documentazione delle richieste di pagamento in corso d’opera;
• il rendiconto dell’avanzamento, rispetto al piano progettuale e alle sue milestone;
• la convalida della metodologia di stima sulla quale si basa il controllo dell’avanzamen- to del progetto;
• l’analisi degli scostamenti.
4.2.4. Gestire il cambiamento (Varianti)
Nel corso della vita di un contratto i cambiamenti sono inevitabili dato che è impossibile, in sede di pianificazione, prevedere tutti i problemi e tutte le circostanze che si possono pre- sentare. La necessità di apportare varianti a quanto concordato in sede di stesura del con- tratto può dipendere da diverse cause:
• cambiamento dei requisiti;
• estensione dell’ambito del progetto;
• variazioni funzionali ed architetturali;
• necessità di natura produttiva, manutentiva o di esercizio;
68
• standardizzazione;
• sicurezza;
• evoluzione della tecnologia;
• adeguamento a nuove normative;
• riallocazione di risorse professionali;
• variazioni di priorità tra sottoprogetti o dei piani operativi;
• …
Le principali cause di ritardo e di maggiore spesa dei progetti sono il cambiamento dei requisiti in corso d’opera e l’incontrollata estensione dello scopo e degli obiettivi del pro- getto rispetto al piano originale.
Nel caso di requisiti software il vero problema non è rappresentato dal fatto che questi cambiano durante la vita di un progetto, ma dalla mancanza di un quadro di riferimento disciplinato di processi di pianificazione e controllo.
Un approccio strutturato, compatibile con la Function Point Analysis IFPUG, che permetta di quantificare, sia in forma preventiva che consuntiva, l’impatto di una richiesta di cambia- mento dei requisiti dal punto di vista della quantità di funzionalità interessate (Functional Change Request) e della loro valorizzazione dovrebbe prevedere di misurare i cambiamenti di requisiti funzionali che emergono nel corso del processo di sviluppo o di manutenzione dell’applicazione “come se” fossero requisiti di manutenzione evolutiva espressi sul sistema “già terminato”. Vedi cap. 9 del manuale “Strategie di acquisizione delle forniture ICT”.
Una misurazione efficace del tasso di cambiamento dei requisiti consente di valutare e migliorare il processo di gestione dei requisiti (troppi cambiamenti di requisiti possono essere indice di una gestione dei requisiti non efficace) e di riconoscere la variazione del- l’impegno lavorativo effettivamente svolto dal Fornitore (a fronte di previsioni e consuntivi basati rispettivamente sui soli requisiti iniziali e sulle funzionalità effettivamente completate e rilasciate a fine progetto).
E’ quindi necessario fornirsi di strumenti che permettano di valutare l’impatto di ogni cam- biamento di requisiti in termini di: aspetti tecnici, durata della realizzazione del cambiamen- to, carichi di lavoro. Solo misurando tali parametri è possibile valutare adeguatamente le priorità, i costi e i benefici di una eventuale accettazione di un cambiamento di requisiti.
Quindi in generale, gestire il cambiamento significa definire un processo che assicuri meto- di e procedure standardizzate per un’implementazione efficiente di tutte le esigenze di cam- biamento al fine di minimizzare gli impatti sulla qualità del prodotto/servizio oggetto del contratto, sui tempi e sui costi pianificati.
69
La corretta gestione dei cambiamenti comporta l’identificazione, la valutazione, l’autorizza- zione, la documentazione, la realizzazione ed il controllo delle modifiche. A tal fine, colui che gestisce il contratto deve svolgere un ruolo attivo nelle procedure di controllo dei tempi e dell’ambito del progetto, verificando che tutte le richieste di cambiamento siano approvate ufficialmente, implementate correttamente nel rispetto dei tempi e dei costi pia- nificati e con un rischio minimo per gli elementi già esistenti. Per poter fare questo deve avere sempre come riferimento la baseline del progetto stesso, ossia un piano di lavoro condiviso ed approvato ufficialmente con cui viene confrontata l’esecuzione del progetto e vengono misurati gli scostamenti.
Un altro fattore critico di successo della gestione dei cambiamenti (Critical Success Factor – CSF) è la comunicazione. Un difetto di comunicazione è molto spesso la ragione per cui i cambiamenti non sono implementati correttamente .Tanto più è alto il numero di stakehol- der informati, quanto più sono maggiori le probabilità che la modifica sia implementata correttamente.
A questo proposito, è anche importante stabilire un formato standard per la documentazio- ne delle richieste di modifica. Esistono diversi livelli di dettaglio nella definizione di una richiesta di modifica in funzione dell’ambito nel quale la richiesta ha origine. Nella maggior parte dei casi la richiesta di cambiamento nasce da una esigenza dell’utente e, passando per i diversi livelli di analisi svolti dal responsabile del contratto, dal project manager e dal responsabile della realizzazione, si arricchisce di informazioni che ne consentono la corretta gestione.
I dati che una richiesta di modifica, cartacea o elettronica, deve sempre includere sono:
• numero di identificazione della richiesta;
• motivo della modifica;
• soggetto proponente;
• classificazione della priorità della modifica;
• classificazione dell’impatto determinato dalla modifica;
• soggetto che autorizza la modifica;
• data dell’autorizzazione;
• identificazione degli oggetti impattati dalla modifica (con eventuale numero di versione);
• pianificazione della realizzazione (analisi dei costi, eventuale revisione del percorso critico);
• valutazione del rischio;
• stato aggiornato della richiesta (generata, valutata, rifiutata, accettata, in realizzazione, rilasciata).
Frequentemente l’Amministrazione può avere interesse a sapere qual è l’esatta composizio- ne dei prodotti esistenti e il loro stato in rapporto alle varianti che sono state apportate su ciascuno di essi. Pertanto, è consigliabile stabilire ed applicare una procedura severa per il controllo e la documentazione delle caratteristiche fisiche e funzionali dei prodotti di conse- gna. Ciò è possibile attraverso la gestione della configurazione.
La gestione della configurazione è il processo che definisce le modalità per l’identificazione, il controllo, la manutenzione ed il mantenimento delle versioni dei prodotti di consegna previsti dal contratto (elementi hardware, oggetti software, documentazione).
Ogni oggetto di consegna deve avere un corredo di attributi archiviati in un database di configurazione. Gli attributi principali sono:
• nome dell’oggetto (univoco);
• categoria di appartenenza (hardware, software, documentazione);
70
• descrizione;
• numero di versione;
• locazione (ad es. libreria software);
• soggetto responsabile;
• stato (archiviato, in uso, in fase di test);
• relazioni con altri oggetti.
In particolare per la documentazione, al procedere delle fasi di progettazione e realizzazio- ne, a mano a mano che vengono rilasciati documenti di specificazione e lotti di documenti conclusivi delle varie progettazioni di dettaglio, si sviluppa l’albero della documentazione del prodotto costituito da documenti quali:
• requisiti;
• specifiche;
• disegni di dettaglio;
• elenchi di oggetti che indicano la composizione del prodotto nelle sue parti.
Ogni variante deve essere documentata, generando uno scatto di revisione dei corrispon- denti documenti, ognuno dei quali deve riportare l’elenco delle variazioni apportate.
L’adozione di sistemi informatici di gestione della configurazione di prodotto è una scelta politica del Fornitore ma può essere un requisito imposto contrattualmente dall’Amministra- zione, direttamente o indirettamente attraverso l’imposizione di una normativa di qualità di riferimento.
A tale scopo, si può fare riferimento al documento CNIPA “Linee guida sulla qualità dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA” nel quale la gestione della configurazione è indicata come una delle classi di fornitura su cui costruire le regole generali di un contratto.
4.2.5. Gestire l’avvicendamento contrattuale
Molto spesso i progetti informatici nell’ambito della Pubblica Amministrazione presentano caratteristiche di notevole complessità, circostanza per la quale essi non si concludono nel- l’ambito di un singolo contratto, ma vengono realizzati attraverso contratti diversi che si sus- seguono nel tempo. Poiché, di norma, i contratti vengono stipulati in seguito all’espleta- mento di procedure concorsuali, capita spesso che un progetto possa essere inizialmente realizzato da un Fornitore al quale può subentrarne un altro. Per questo motivo è molto importante che l’Amministrazione, oltre a vigilare costantemente sulla completezza, accura- tezza e conservazione della documentazione di progetto, preveda apposite clausole contrat- tuali che favoriscano l’avvicendamento tra diversi fornitori. In generale, quindi, è buona norma prevedere a livello di capitolato tecnico e di contratto l’esecuzione delle seguenti attività:
• addestramento a inizio fornitura (solo nel caso di contratti che prevedano la continua- zione di progetti già iniziati);
71
• manutenzione su chiamata;
• trasferimento di know-how.
Per tali attività può essere richiesto, ai concorrenti che partecipino alla procedura concor- suale per l’aggiudicazione della fornitura, di formulare apposite proposte tecnico-organizza- tive sulle modalità di erogazione. Per tali proposte saranno quindi previsti, a livello di disci- plinare di gara, dei punteggi da assegnare in sede di valutazione delle offerte tecniche.
Si riporta, di seguito, una breve descrizione delle citate attività.
Addestramento a inizio fornitura
Consiste nella possibilità, data al Fornitore che subentra ad un altro Fornitore su un proget- to, di richiedere all’Amministrazione un lasso di tempo considerato congruo, normalmente 2-3 mesi, antecedente la data di inizio fornitura, in cui poter usufruire di addestramento, al fine di permettere al proprio personale di prendere in carico al meglio le diverse attività progettuali.
Tale addestramento potrà consistere, ad esempio, in riunioni di lavoro, esame della docu- mentazione esistente con assistenza di personale esperto, affiancamento nell’operatività quotidiana di manutenzione correttiva e gestione condotta dal Fornitore uscente, senza ese- guire direttamente le attività (training on the job).
Le modalità di fruizione e la relativa pianificazione di tale addestramento devono essere concordate con l’Amministrazione, anche sulla base delle proposte che il Fornitore avrà fatto in sede di offerta. Ovviamente l’Amministrazione dovrà garantire la presenza di pro- prio personale esperto, o di soggetti terzi dalla stessa designati.
Manutenzione su chiamata
Consiste in un servizio di supporto su chiamata, da erogare per un certo numero di mesi, a fine contratto. In questo modo l’Amministrazione si riserva la facoltà di richiedere l’interven- to del Fornitore uscente per la risoluzione di eventuali malfunzionamenti o per ulteriori approfondimenti sul software precedentemente rilasciato. L’Amministrazione dovrà valutare, in base alla complessità del progetto ed alle proprie capacità di potersi sostituire al Fornito- re uscente, la durata ottimale per il servizio ed il suo dimensionamento. Normalmente la durata ottimale è compresa tra i tre ed i sei mesi.
Le modalità di erogazione del servizio e la relativa pianificazione devono essere concordate tra l’Amministrazione ed il Fornitore, anche sulla base delle proposte che il Fornitore potrà fare in sede di offerta.
72
Nel corso dell’esecuzione del contratto, e soprattutto durante gli ultimi mesi di esecuzione delle attività contrattuali, il Fornitore uscente, su richiesta dell’Amministrazione, dovrà tra- sferire al personale dell’Amministrazione e del Fornitore subentrante, il know-how sulle attività condotte, al fine di rendere l’eventuale prosecuzione delle attività quanto più effica- ce possibile, secondo un programma formativo che preveda, ad esempio, docenze, sessioni riassuntive, sessioni di lavoro congiunto, presentazioni, tavole rotonde, ecc., su funzioni, scelte architetturali, codice sorgente e documentazione progettuale.
Nell’ambito di tale attività si può richiedere al Fornitore uscente di ospitare il personale del nuovo Fornitore in affiancamento nell’operatività quotidiana di manutenzione correttiva e di gestione condotta dal Fornitore uscente, senza che peraltro il nuovo fornitore abbia la possibilità di eseguire direttamente le attività (training on the job).
Le modalità di erogazione e la relativa pianificazione del trasferimento di know-how saran- no concordate tra l’Amministrazione ed il Fornitore, anche sulla base delle proposte che il Fornitore potrà fare in sede di offerta.
Un altro aspetto importante da considerare, in caso di avvicendamento tra fornitori su un progetto, è quello relativo alla messa a disposizione del Fornitore che subentra di tutta la documentazione progettuale prodotta dal Fornitore uscente. In generale, è raro che le Amministrazioni siano adeguatamente attrezzate dal punto di vista della gestione e della
,conservazione della documentazione tecnica di progetto. Qualora lo fossero non ci sareb- bero particolari problemi, in quanto sarebbero in grado di rendere facilmente disponibile tale documentazione al nuovo Fornitore che subentra.
Poiché, invece, la gestione della documentazione di progetto viene normalmente delegata al Fornitore, l’Amministrazione, da un lato, dovrà assicurarsi che durante l’esecuzione del progetto essa venga effettuata secondo i criteri e le procedure dichiarati dal Fornitore in fase di offerta e dall’altro dovrà essere in grado di prendere in consegna, a fine contratto, tutti i documenti prodotti dal Fornitore uscente, chiedendo al Fornitore che subentra di continuarne la gestione.
4.2.6. Verificare gli oggetti di fornitura
L’Amministrazione è tenuta a verificare che i deliverable di progetto siano conformi a quan- to previsto contrattualmente e che soddisfino i requisiti dalla stessa richiesti. La verifica del- l’Amministrazione sui singoli oggetti di fornitura può determinare l’approvazione o la man- cata approvazione degli stessi. La verifica sui prodotti di fornitura ha una duplice rilevanza:
• formale: spesso l’approvazione dei prodotti ha una valenza di tipo contrattuale, ovve- ro con questo atto si sancisce la corretta esecuzione di determinate attività che il For- nitore è autorizzato a fatturare;
• sostanziale: l’approvazione serve all’Amministrazione a verificare puntualmente il con- tenuto dei prodotti rilasciati dal Fornitore ed a verificare che quanto fornito sia confor- me a quanto richiesto. Inoltre, spesso, l’approvazione di determinati prodotti consente di considerare chiusa una fase progettuale e rappresenta una sorta di autorizzazione a procedere con una o più fasi correlate alla precedente (ad esempio, tipicamente, in un progetto con ciclo di vita tradizionale l’approvazione dei documenti di analisi determina appunto la fine di tale fase e l’inizio della fase di disegno).
Normalmente l’approvazione dei deliverable di progetto da parte dell’Amministrazione può essere:
73
• esplicita: in questo caso è un atto formale con il quale l’Amministrazione comunica al Fornitore l’approvazione di un determinato prodotto;
• implicita: un deliverable si intende approvato quando sia trascorso un certo lasso di tempo previsto contrattualmente senza che l’Amministrazione comunichi nulla al For- nitore.
L’utilizzo dell’approvazione implicita dovrebbe essere limitato il più possibile in quanto normalmente è indice di scarsa attenzione sul contenuto dei deliverable prodotti e dere- sponsabilizza l’Amministrazione nell’attività di verifica e controllo che invece è tenuta ad effettuare. Anche dal punto di vista del Fornitore, l’approvazione esplicita rappresenta un elemento di certezza che quanto prodotto soddisfi effettivamente le aspettative del com- mittente.
Così come l’approvazione, anche la mancata approvazione di prodotti dovrebbe essere for- malmente notificata al Fornitore, evidenziando i motivi che non consentono di considerare un prodotto conforme a quanto richiesto e chiedendo al Fornitore di eliminare le non conformità riscontrate.
Nelle attività di verifica degli oggetti di fornitura andrebbero adottati alcuni accorgimenti che, anche se possono apparire banali, talvolta non vengono rispettati:
• Competenza nel controllo: per ogni deliverable consegnato dal Fornitore l’Amministra- zione dovrebbe valutare chi sia il soggetto maggiormente titolato ad effettuare le dovute verifiche, ovvero individuare la persona o le persone che hanno la competen- za adeguata per controllare la rispondenza del prodotto a quanto richiesto. Ad esem- pio, nel caso in cui ci sia da approvare un manuale utente, è logico pensare che la persona più titolata ad effettuare la verifica sia un utente del sistema; nel caso in cui ci sia da approvare un manuale di gestione, la verifica dovrebbe essere effettuata da parte di chi prenderà in gestione il sistema, e così via. Non è detto che un unico skill professionale sia sufficiente ad effettuare tali verifiche. Ad esempio, per i documenti di progettazione tecnica di una determinata funzione software, oltre alla verifica da parte dell’utente che ha dettato i requisiti e che è in grado di determinare la rispon- denza di quanto progettato ai requisiti stessi, potrebbe essere necessario il supporto di un tecnico in grado di interpretare in modo corretto le metodologie, le tecniche ed i formalismi utilizzati nei documenti di progettazione;
• Continuità nelle diverse fasi: molto spesso i diversi deliverable contrattualmente previsti sono tra loro collegati per motivi diversi: ad esempio i documenti di analisi, di disegno ed il manuale utente di determinate funzioni software afferiscono allo stesso oggetto, seppure consegnati in diverse fasi. Ne consegue che, in casi del genere, sia dal punto di vista della competenza, sia dell’economicità, è utile che i diversi oggetti di fornitura siano verificati da un’unica entità (persona fisica o gruppo di persone competenti);
74
• Tempi di approvazione: talvolta nei contratti si prevedono tempi di approvazione dei deliverable contrattuali inadeguati: ad esempio tempi uguali per tutti i delivera- ble, indipendentemente dalla loro complessità, tempi particolarmente ristretti o vice- versa tempi particolarmente lunghi. Si ritiene che in fase di impostazione del con- tratto l’Amministrazione debba porre la dovuta attenzione nella previsione dei tempi di approvazione dei deliverable. In particolare si dovrebbe considerare la comples-
sità di ciascun prodotto di consegna ed in funzione di essa tarare adeguatamente il tempo previsto per l’approvazione. In generale vanno evitati tempi particolarmente ristretti che possono comportare una verifica superficiale, ma al tempo stesso andrebbero evitati tempi eccessivamente lunghi che potrebbero rallentare le attività del Fornitore.
Un caso particolare di verifica degli oggetti di fornitura è il collaudo dei prodotti software realizzati nell’ambito delle attività progettuali. Il collaudo del software è un’attività che nor- malmente da parte dell’Amministrazione prevede il coinvolgimento di un gruppo di lavoro composto da diverse figure, quali:
• gli utenti finali del sistema, i quali devono verificare che il software realizzato sia ade- rente alle proprie esigenze;
• i tecnici informatici che hanno seguito l’attività di realizzazione del software, che hanno il compito, a partire dai requisiti formali e prendendo spunto dal Piano di test prodotto dal Fornitore, di predisporre il Piano di collaudo da seguire durante l’attività.
Il collaudo deve essere eseguito nei tempi previsti dal Piano di progetto, con il supporto del Fornitore. La durata del collaudo è dipendente dalle caratteristiche, dalle dimensioni e dalle criticità del software realizzato.
Oltre alla rispondenza del software realizzato a quanto richiesto dagli utenti, sarà oggetto di verifica, durante il periodo di collaudo, tutta la documentazione della fase realizzativa, come ad esempio:
• manuali utente;
• documenti di configurazione;
• documenti di gestione.
Il Fornitore dovrà provvedere all’eliminazione degli eventuali vizi e difformità riscontrati durante le operazioni di collaudo, secondo i tempi di ripristino indicati nel Capitolato Tec- nico o nel Piano della Qualità.
Nel caso in cui, durante il collaudo, vengano rilevate anomalie che secondo l’Ammini- strazione, per numero e/o gravità, non permettano il prosieguo delle attività, il collau- do sarà interrotto e riprenderà ex novo dal momento in cui le anomalie saranno state rimosse.
Delle operazioni di collaudo deve essere redatto un apposito rapporto, condiviso formal- mente tra Amministrazione e Fornitore, in cui siano tracciate le attività svolte durante il col- laudo stesso. In caso di esito positivo, il collaudo si conclude con l’accettazione formale dei componenti della fornitura sottoposti a verifica. Nel capitolo 6 è riportato un possibile indi- ce tipo del rapporto di collaudo.
4.2.7. Determinare i corrispettivi e saldare le fatture
75
Un aspetto tipicamente legato allo stato di avanzamento lavori è quello della determinazio- ne dei corrispettivi e della fatturazione delle attività.
In generale, come indicato nel manuale “Strategie di acquisizione delle forniture ICT”, le modalità di remunerazione delle attività possono suddividersi in due categorie:
• “a corpo”, in cui non sono utilizzate misure della quantità di fornitura resa;
• “a consuntivo”, in cui sono utilizzate misure della quantità di fornitura effettivamente resa.
Si ritiene che la modalità “a corpo” presenti una gestione contrattuale più semplice per l’Amministrazione, la quale non ha l’onere di effettuare verifiche sull’impegno di risorse uti- lizzate dal Fornitore e sui costi in corso d’opera, basandosi semplicemente sui corrispettivi contrattualmente stabiliti all’inizio del progetto.
Tuttavia, per poter utilizzare la remunerazione a corpo, è necessario che l’Amministrazione definisca, con una certa precisione, i requisiti funzionali e qualitativi del progetto già a livel- lo di capitolato. E’ quindi necessario che siano esplicitate in modo chiaro ed esaustivo le esigenze dell’utente, sia in termini di contenuti che in termini temporali.
Se non sono presenti questi presupposti si adotta il modello “a consuntivo”. L’Amministra- zione,in questo caso, determina i corrispettivi al termine della fornitura in base alle dimen- sioni del prodotto/servizio fornito ed al costo unitario del medesimo stabilito contrattual- mente:
Corrispettivo = dimensioni (prodotto/servizio fornito) x costo unitario contrattuale
Per la misura delle dimensioni del prodotto software, normalmente si adotta la dimensione funzionale determinata in base al metodo standard della Function Point Analysis IFPUG, (vedi cap. 9 del manuale “Strategie di acquisizione delle forniture ICT”).
Per entrambi i modelli è possibile, anche per attività di sviluppo software, suddividere il pagamento in quote da erogare in funzione del raggiungimento di specifici obiettivi, ad es.: al completamento di predeterminate fasi progettuali, fino al conseguimento del corrispetti- vo totale contrattualmente previsto. Naturalmente per il modello a consuntivo le quote, tranne l’ultima, saranno determinate sulla base di un corrispettivo stimato. L’ultima quota sarà determinata tenendo conto del corrispettivo relativo a quanto effettivamente realizzato e detraendo da questo le quote già fatturate.
In linea generale per la determinazione delle quote dovrebbe quindi essere utilizzata la seguente formula:
Quota fase i-esima = corrispettivo totale x peso percentuale della fase i-esima
Uno strumento utile per la determinazione dei corrispettivi parziali è quindi una tabella che indichi il peso percentuale di ogni fase del progetto sul totale.
76
Nel caso di uno sviluppo software, a puro titolo indicativo, si fornisce di seguito una tabella di peso percentuale delle fasi progettuali, per un ciclo di sviluppo a cascata, che tiene conto dell’ impegno lavorativo, delle figure professionali necessarie per l’esecuzione delle
diverse fasi progettuali, delle tariffe di tali figure e del contributo che ogni figura professio- nale fornisce ad ogni fase in percentuale:
Fase | Percentuale Attività % |
Definizione | 5 – 15 |
Analisi | 10 – 30 |
Disegno | 10 – 30 |
Realizzazione e test | 30 – 50 |
Collaudo | 5 – 15 |
Si ritiene opportuno precisare che le percentuali contrattualmente previste per la fatturazio- ne siano stabilite rimodulando le percentuali corrispondenti alle fasi realizzate in modo da tener conto del rischio connesso al pagamento, nelle fasi iniziali/intermedie, di quote consi- stenti della fornitura. Naturalmente tale considerazione vale anche per la determinazione delle percentuali di fatturazione per il modello “a corpo”.
Al termine delle fasi progettuali per le quali è contrattualmente previsto il pagamento di un corrispettivo (conclusione ovviamente accettata formalmente da parte dell’Amministrazione dopo aver verificato che siano stati rispettati i criteri di completamento), il Fornitore è auto- rizzato ad emettere le fatture corrispondenti.
I criteri di completamento delle diverse fasi, e quindi anche di quelle che comportano pagamenti, devono essere chiaramente definiti a livello contrattuale. Normalmente essi con- sistono:
• nella consegna di deliverable di varia natura (documenti, software, componenti hardware) da parte del Fornitore nel rispetto dei requisiti tecnici, dei tempi e dei livel- li qualitativi richiesti e concordati tra le parti;
• nell’accettazione dei deliverable da parte dell’Amministrazione, una volta verificato, appunto, il rispetto dei requisiti tecnici, dei tempi e dei livelli qualitativi.
Sia la consegna dei deliverable da parte del Fornitore, che l’accettazione degli stessi da parte dell’Amministrazione devono essere atti formali posti in essere dalle parti. L’accetta- zione dei deliverable da parte dell’Amministrazione differisce a seconda della natura del bene consegnato dal Fornitore. Nel caso di consegna di un documento, l’accettazione del- l’Amministrazione si estrinseca mediante una lettera di approvazione; in caso di consegna di oggetti software ed hardware, gli stessi devono essere sottoposti a collaudo da parte del- l’Amministrazione. Delle operazioni di collaudo effettuate deve essere data adeguata evi- denza (rapporto di collaudo) e la conclusione positiva delle stesse deve essere formalizzata tramite un verbale di collaudo.
77
Uno strumento utile per l’Amministrazione per tenere sotto controllo l’andamento delle diverse fasi progettuali ed avere al tempo stesso visibilità sui prodotti (deliverable) contrat- tualmente previsti è la matrice “attività-prodotti”, consistente in una tabella in cui per cia- scuna fase progettuale è riportata una descrizione delle attività di cui si compone e l’elenco dei deliverable che devono essere prodotti. Tale tabella normalmente è già presente nel
piano di progetto redatto dal Fornitore e può essere utilizzata dall’Amministrazione a que- sto scopo, eventualmente arricchendola con ulteriori informazioni quali data di completa- mento pianificata, data di completamento effettiva, livelli qualitativi richiesti, ecc.
Modalità di valorizzazione di progetti interrotti precocemente
Nel caso di progetti interrotti precocemente occorre riconoscere un valore economico alle attività svolte. In questo caso al prezzo finale deve essere applicato un coefficiente di remu- nerazione pari alla sommatoria delle percentuali relative alle fasi svolte.
Per la determinazione del corrispettivo “ridotto” può essere quindi utilizzata la seguente for- mula:
Corrispettivo = Corrispettivo totale x ∑ %fasi svolte
Questa modalità di determinazione del corrispettivo dovrebbe essere prevista nei documen- ti contrattuali al fine di evitare elementi di conflittualità tra committente e fornitore.
Si rimanda al cap. 9 del manuale “Strategie di acquisizione delle forniture ICT” per una con- testualizzazione sulle forniture software.
78
5. Governo dei contratti per l’erogazione di servizi
La norma ISO 8402 definisce il servizio come “risultato di attività svolte sia all’interfaccia tra fornitore e cliente, che all’interno dell’organizzazione del fornitore, per soddisfare le esigen- ze del cliente”. In questo paragrafo si fa riferimento a quei servizi in cui le prestazioni si ripetono nel corso del periodo di erogazione.
I servizi hanno un ciclo di vita che si compone delle fasi di definizione di massima dei requisiti, di progettazione e di realizzazione/collaudo del sistema per l’esecuzione del servi- zio alle quali segue la fase di erogazione agli utenti. La fase di definizione di massima dei requisiti è antecedente alla stipula del contratto, mentre le fasi di progettazione e realizza- zione del servizio sono solo in alcuni casi regolate dal contratto. Nelle schede delle classi di fornitura relative ai servizi sono descritte anche queste ultime attività e sono riportati i deli- verable contrattuali e gli indicatori tipici da esplicitare negli atti contrattuali per garantire un efficace governo anche di queste fasi produttive, quando è necessario. Ma quando è oppor- tuno che l’Amministrazione svolga un’azione di regolazione e controllo di queste fasi? Per rispondere a questa domanda è necessario valutare i vantaggi e gli svantaggi per l’Ammini- strazione nel seguire le fasi propedeutiche all’erogazione di un servizio.
Un importante vantaggio risiede nel fatto che un accurato controllo dei risultati della pro- gettazione e realizzazione da parte dell’Amministrazione consente di individuare eventuali carenze e di richiedere la revisione di alcuni elementi del progetto, in modo da evitare che questi, durante l’erogazione del servizio, producano livelli di servizio inferiori a quanto richiesto o, nei casi più gravi, abbiano come conseguenza la sospensione del servizio. L’a- nalisi del risultato della progettazione e l’esame di come è realizzato il sistema per l’eroga- zione del servizio consentono di svolgere una valutazione dei rischi per assicurarsi che il grado di rischio di disservizi in fase di erogazione sia accettabile.
Un secondo vantaggio può presentarsi nel caso in cui l’Amministrazione fornisca uno o più elementi che compongono il sistema necessario all’erogazione del servizio. Tipica è la for- nitura delle infrastrutture da parte dell’Amministrazione che devono essere correttamente dimensionate in funzione di parametri quantitativi e qualitativi del servizio. In questo caso il vantaggio risiede nel fatto che le parti possono concertare, nel corso della progettazione e realizzazione, tutti gli aspetti di dettaglio nella realizzazione del sistema per l’erogazione del servizio tenendo conto di vincoli ed esigenze di entrambe le parti.
79
Il coinvolgimento e, quindi, la responsabilizzazione dell’Amministrazione nelle fasi di proget- tazione e realizzazione, presenta però alcuni svantaggi. In primo luogo, una forma di approvazione da parte dell’Amministrazione del risultato di queste fasi può avere come con- seguenza una ridotta responsabilità del fornitore sulla qualità del servizio che sarà erogato.
Un secondo svantaggio riguarda i costi aggiuntivi che l’Amministrazione deve sostenere a seguito del numero dei controlli e dei ricicli di lavorazione di queste due fasi. Tali costi possono variare sia in relazione, naturalmente, alla complessità del sistema da realizzare, che in funzione della presenza all’interno dell’Amministrazione di professionalità in grado di valutare il risultato delle fasi di progettazione e realizzazione del sistema.
Naturalmente, non è necessario che l’Amministrazione controlli le fasi di progettazione e realizzazione del sistema tutte le volte che intende affidare l’erogazione di un servizio ad un soggetto esterno. Per tutti i servizi in cui i sistemi di supporto all’erogazione sono semplici o fortemente standardizzati questa esigenza non si presenta.
Nel caso in cui l’Amministrazione decida di controllare le suddette fasi è opportuno che il contratto sia stilato tenendo conto delle indicazioni riportate nelle specifiche classi di forni- tura, sia per quanto riguarda i deliverable contrattuali e la loro struttura, sia per gli indicatori di qualità necessari per il controllo in corso d’opera.
Riguardo invece all’attività di governo del contratto, relativamente a queste specifiche fasi, si rimanda ai paragrafi sul governo dei contratti per la realizzazione dei progetti.
Nella fase successiva, cioè quella di erogazione del servizio, le attività di governo sono finalizza- te a garantire la qualità delle prestazioni nel rispetto di quanto stabilito contrattualmente. A que- sto scopo è necessario valutare in modo continuativo la qualità mediante la misura dei livelli di servizio per individuare tempestivamente eventuali criticità ed adottare azioni correttive.
Sarebbe opportuno, inoltre, che in corso d’opera si procedesse ad effettuare delle rilevazio- ni su come il servizio è percepito dall’utente, in quanto è questo l’elemento che misura l’ef- fettiva adeguatezza del servizio stesso. Infatti possono presentarsi situazioni in cui i valori di soglia definiti contrattualmente per i livelli di servizio non corrispondono alle effettive esi- genze dell’utenza. Questo può verificarsi sia per l’inesperienza dell’Amministrazione su uno specifico servizio, sia per il variare delle esigenze dell’utenza nel corso dell’erogazione.
I valori di soglia iniziali possono risultare sovradimensionati o sottodimensionati: nel primo caso la conseguenza è che si sta erogando un servizio con un livello qualitativo inutilmente elevato, quindi con costi non giustificati, mentre nel secondo caso il servizio non soddisfa le esigenze degli utenti con il rischio di una riduzione della qualità dei servizi erogati dal- l’Amministrazione.
Per poter gestire queste possibili situazioni, è necessario che il contratto preveda elementi di flessibilità che consentano di modificare in corso d’opera i valori di soglia stabiliti inizial- mente e di determinare in modo univoco i nuovi corrispettivi economici da riconoscere al fornitore.
Nel caso in cui l’Amministrazione debba affidare le rilevazioni di “soddisfazione dell’utenza” ad un fornitore esterno, perchè non dispone di risorse con le competenze necessarie a svolgere questo servizio, è opportuno che selezioni un fornitore diverso da chi eroga il servizio oggetto della rilevazione.
5.1. Attività di competenza del fornitore
80
Come accennato nel paragrafo precedente, le attività che preliminarmente il fornitore deve svolgere riguardano la progettazione e la realizzazione del sistema necessario per l’eroga- zione del servizio.
Queste fasi possono non essere disciplinate dal contratto. In questo caso non è presente una interazione con il committente (approvazioni, collaudi) ed i vincoli posti al fornitore sul risultato di queste fasi sono indiretti e riguardano il rispetto sia dei tempi di inizio dell’e- rogazione del servizio, sia dei valori di soglia relativi ai livelli di servizio.
Contestualmente all’inizio della fase di erogazione del servizio il fornitore deve avviare le attività che garantiscano sia il rispetto, nel corso dell’intera fornitura, dei livelli di qualità stabiliti contrattualmente o concordati in corso d’opera, sia la trasparenza verso il commit- tente sulle caratteristiche del servizio fornito.
Il fornitore ha anche il compito di alimentare il sistema di rendicontazione del servizio ero- gato e di gestire i rischi che, nel caso dei servizi, riguardano essenzialmente il degrado delle prestazioni. Le procedure di gestione dei rischi sono analoghe a quelle descritte nei para- grafi precedenti per i progetti. I fattori di rischio sono però diversi e sono individuabili nel sistema utilizzato per l’erogazione del servizio, compreso il personale.
Fattori di rischio riguardano ad esempio il corretto funzionamento delle centrali telefoniche, dei personal computer, del software applicativo e delle reti di connessione ma anche le prestazioni dei servizi utilizzati dal fornitore per l’erogazione del servizio principale, che possono essere a carico di subfornitori. Altri fattori di rischio riguardano il personale impie- gato e si riferiscono al livello di competenza sullo specifico servizio, all’entità del turnover che si può prevedere, alla consistenza numerica rispetto all’impegno (produttività).
Il fornitore ha il compito di individuare questi fattori di rischio, definire le azioni preventive mirate a mitigare i rischi, stabilire azioni da attuare nel caso si verifichi l’evento critico, adot- tare un sistema di controlli mirati che consenta di individuare in tempo le criticità per poter attuare le azioni di contrasto. Tutti questi elementi devono essere descritti nel piano di gestione dei rischi che dovrà essere completato prima dell’inizio dell’erogazione del servizio per poter avviare le previste azioni preventive. Nel corso dell’erogazione del servizio il for- nitore deve assicurarsi che quanto indicato sul piano sia eseguito.
5.1.1. Predisporre un Piano della Qualità
La qualità di erogazione di un servizio può essere definita, analogamente alla qualità di un prodotto, come l’insieme delle caratteristiche che conferiscono ad esso la capacità di soddi- sfare esigenze espresse o implicite. Queste caratteristiche sono valutate attraverso indicatori (livelli di servizio) basati su rilevazioni di dati elementari ripetute con frequenza stabilita nel corso dell’intero periodo di erogazione del servizio. Il profilo di qualità del servizio, quindi, è definito utilizzando livelli di servizio idonei a misurarne la qualità e stabilendo per ognu- no di questi specifici valori di soglia. Analogamente ai prodotti, anche il profilo di qualità dei servizi è riportato su un documento, il Piano di qualità, nel quale sono anche indicati i criteri di controllo e gestione che il fornitore intende attuare per assicurare il livello qualita- tivo stabilito. Nel paragrafo 6 è riportato uno schema generale di piano di qualità.
81
Il Piano di qualità viene redatto dal fornitore a seguito della stipula del contratto, ripren- dendo il profilo di qualità di ogni specifico servizio dai documenti di gara o, se migliorati- vo, da quello proposto dal fornitore nell’offerta tecnica con la quale ha partecipato alla gara. Il piano è sottoposto all’approvazione dell’Amministrazione e viene aggiornato duran-
te l’erogazione dei servizi ogni volta che si rende necessario modificare i requisiti di qualità di un servizio, a seguito di nuovi accordi tra le parti, che possono derivare da una errata interpretazione iniziale delle esigenze dell’utenza da parte dell’Amministrazione, o da muta- te necessità nel corso della fornitura. E’ tipico il caso di contratti di durata pluriennale per l’erogazione di servizi rilevanti per i compiti dell’Amministrazione, nel corso dei quali sono condotte indagini sulla soddisfazione degli utenti per verificare l’adeguatezza rispetto alle esigenze. Gli elementi che possono emergere dai risultati di queste indagini possono riguar- dare sia l’inadeguatezza degli indicatori a misurare la qualità del servizio, sia l’errata defini- zione dei valori di soglia stabiliti. Nel primo caso occorre introdurre nuovi indicatori, metri- che e valori di soglia, mentre nel secondo caso è sufficiente modificare i valori di soglia. Tali modifiche possono comportare degli intereventi sul sistema di rilevazione del fornitore che è disegnato in coerenza con gli indicatori presenti nel Piano di qualità.
5.1.2. Monitorare il servizio
Lo scopo di questa attività è quello di prevenire la riduzione dei livelli di qualità del servi- zio dovute a specifiche criticità che emergono durante il processo di erogazione e di rimuo- vere le cause che hanno prodotto disservizi. Per svolgere questa attività è necessario che il fornitore realizzi un cruscotto dei servizi, cioè un sistema integrato di controllo basato su un insieme di indicatori in grado di misurare le prestazioni dei propri processi primari di ero- gazione del servizio e dei processi e servizi di supporto ai primi (Decision Support System DSS – Knowledge Management System KMS)
Per processo si intende la sequenza delle attività necessarie all’erogazione del servizio. Esso si compone di tre fasi fondamentali: l’informazione sul servizio, l’erogazione vera e propria, la gestione del disservizio.
La prima fase si compone di adempimenti preparatori, prevalentemente di trasferimento di informazioni al potenziale utente, quali per esempio la descrizione analitica del servizio, i tempi e le modalità operative di erogazione, eventuali vincoli. Una corretta attuazione della fase preliminare pone le premesse per un buon servizio.
La fase di erogazione vera e propria è naturalmente quella più complessa, in quanto può essere composta da più processi primari che interagiscono tra loro e, per questo, devono essere adeguatamente coordinati. La fase di gestione del disservizio, spesso sottovalutata, riveste un ruolo importante nel processo, in quanto consente di limitare i danni prodotti all’utente a seguito di un disservizio.
Prerequisito fondamentale per poter controllare l’erogazione di un servizio è l’adozione da parte del fornitore di un processo descritto in modo formale, in cui siano identificate tutte le attività svolte e siano connesse tra loro, secondo il flusso temporale con cui vengono effettuate. Le attività dovrebbero essere descritte nel dettaglio, in modo da rendere il pro- cesso controllabile, ripetibile e affidabile e per garantire omogeneità del servizio nel tempo. La presenza di un piano di qualità non garantisce di per se il rispetto di questo prerequisito. Per questo motivo è sempre opportuno valutare i contenuti di questo documento.
82
Per controllare efficacemente il processo di erogazione occorre identificare quelle attività che possono rappresentare elementi di criticità, sia riguardo a variazioni quantitative del servizio sia perché presentano una prevalente componente umana per l’esecuzione. Per queste atti-
vità occorre eseguire misurazioni di prestazione con specifici indicatori che si aggiungono ai livelli di servizio stabiliti contrattualmente e che consentono di svolgere analisi sulle cause di eventuali disservizi. E’ opportuno utilizzare anche i cosiddetti indicatori continui che permet- tono di monitorare e misurare l’andamento qualitativo di un processo sul medio periodo e, quindi, di analizzare le tendenze per svolgere eventuali azioni di prevenzione.
Per la raccolta e l’esame delle misurazioni, il fornitore si avvale tipicamente di strumenti di supporto quali il foglio di raccolta dati, gli istogrammi, diagrammi a torta, diagrammi di Pareto, diagrammi di correlazione e le carte di controllo.
Il foglio di raccolta dati ha lo scopo di registrare in modo ordinato i dati elementari raccolti per la misura degli indicatori di processo. Infatti alcuni dati possono essere raccolti auto- maticamente ma altri devono essere recuperati o aggregati con procedimenti manuali e dovrebbero poi essere registrati possibilmente in formato rielaborabile per essere inseriti nel sistema integrato di controllo.
Gli istogrammi sono rappresentazioni grafiche nelle quali ogni dato è rappresentato dalla superficie di un rettangolo. I rettangoli hanno tutti la medesima base e il confronto fra le loro superfici è possibile grazie alle diverse altezze. I rettangoli possono essere posizionati in verticale o in orizzontale. Inoltre, possono essere disegnati uno di seguito all’altro senza spazi intermedi, in modo da formare un’unica superficie (istogramma) oppure separata- mente a strisce verticali (ortogramma). Gli istogrammi sono utili quando occorre rappresen- tare numerosi dati di cui bisogna considerare sia ogni singolo valore isolatamente, che la loro somma. Si usano anche quando, nello stesso grafico, si vogliono operare confronti tra dati ottenuti in rilevazioni diverse: non si fa altro che disegnare rettangoli affiancati di colori diversi per facilitare il raffronto. Di seguito è riportato un esempio di istogramma.
83
I diagrammi a torta o areogrammi suddividono un cerchio in fette di dimensioni propor- zionali alla quota percentuale del valore della misura singola sull’intero fenomeno. Questo diagramma non evidenzia i valori assoluti degli elementi misurati ma solo i rapporti tra essi e quindi è usato per evidenziare come si ripartiscono i vari strati di cui un fenomeno è composto. Di seguito è riportato un esempio di diagramma a torta.
I diagrammi di Pareto sono la sovrapposizione di due diagrammi: uno è un istogramma, in cui tutte le misure sono state ordinate per valore decrescente, l’altro è una linea che rappre- senta la quota percentuale del totale progressivo delle misure, ovvero la percentuale di influenza della prima misura in corrispondenza della prima barra dell’istogramma, la per- centuale di influenza della somma delle prime due misure in corrispondenza della seconda barra e così via. Questo diagramma mette, quindi, in evidenza quali elementi sono rilevanti dal punto di vista quantitativo e quanto incidono. Quando la curva si appiattisce gli ele- menti sono poco rilevanti, viceversa risultano molto rilevanti quando la curva si impenna. Di seguito un esempio di diagramma di Pareto.
84
I diagrammi di correlazione utilizzano piani cartesiani in cui sono riportate due grandezze associate ad un fenomeno per valutare se esiste una correlazione tra le medesime ed even- tualmente definirne le caratteristiche. Questo diagramma permette di identificare, per esem- pio, grandezze correlate ad un livello di servizio che dipendono da una singola attività del-
l’intero processo produttivo, misurando le quali è possibile prevedere i valori che assumerà il livello di servizio correlato ed eventualmente intervenire sul processo allo scopo di ridur- re i rischi di disservizio.
Le carte di controllo sono grafici che riproducono l’andamento di un fenomeno nel tempo. Un fenomeno può essere caratterizzato da un andamento tipico nel tempo oppure da una regolarità. Nel primo caso si verifica che il fenomeno segua un andamento storicamente con- solidato, mentre nel secondo caso gli elementi di controllo riguardano la banda di oscillazio- ne, il valore medio, derive, etc. Queste rappresentazioni sono utili per il monitoraggio di interventi di miglioramento dei processi finalizzati ad aumentare il valore medio delle presta- zioni od a rendere le stesse più omogenee nel tempo, ma sono utili anche per individuare l’inizio di nuovi trend ed intervenire tempestivamente sulle cause che li hanno prodotti.
Il fornitore, supportato dal monitoraggio delle attività e dei livelli di servizio e dall’analisi dei risultati delle rilevazioni effettuate, individua le azioni preventive e correttive allo scopo di rimuovere le cause che hanno prodotto livelli di servizio inadeguati. Il ciclo di controllo si conclude con la valutazione dell’efficacia delle azioni preventive o correttive attraverso analisi comparative dei dati di rilevazione prima e dopo l’intervento.
Nel caso in cui il committente contribuisca all’erogazione del servizio fornendo risorse, stru- menti, infrastrutture, è necessario che esso sia coinvolto nelle attività, a partire dall’analisi dei risultati delle rilevazioni. In questo caso la comunicazione tra le parti non può essere limitata ad una semplice rendicontazione dei livelli di servizio, ma dovrebbe essere ben più articolata ed essere gestita dal fornitore secondo un piano predefinito di comunicazione, approvato dal committente, che definisca tempi, procedure, frequenze, contenuti e moda- lità di gestione delle eccezioni.
5.1.3. Rilevare e rendicontare i livelli di servizio
I livelli di servizio sono lo strumento fondamentale con cui si misura il raggiungimento degli obiettivi concordati tra fornitore e committente. L’accordo sui livelli di servizio costitui- sce la garanzia sulla qualità del servizio erogato ed è lo strumento oggettivo per verificare le prestazioni di servizio.
85
Come detto, i livelli di servizio sono descritti nel documento “Piano di qualità” nel quale sono definiti, in relazione alle metriche da utilizzare, i criteri di rilevazione dei dati di detta- glio, gli algoritmi di aggregazione dei medesimi, gli arrotondamenti, etc. Il fornitore ha il compito di rilevare i dati avvalendosi di specifici strumenti, registrarli, elaborarli e rendicon- tarli. Queste attività, che garantiscono la trasparenza sulla qualità del servizio erogato, devo- no essere anch’esse caratterizzate dalla trasparenza nella loro esecuzione. Il committente, infatti, prende a riferimento la documentazione di rendicontazione per valutare il servizio ed eventualmente applicare le penali previste contrattualmente. Anche il processo di rilevazione e rendicontazione dei livelli di servizio, quindi, deve essere efficacemente documentato per consentire al committente di eseguire agevolmente delle verifiche mirate a garanzia dell’ac- curatezza e validità delle misure prodotte dal fornitore, sia attraverso l’esame dei processi di misura, che mediante l’esecuzione, a campione, di una parte delle misure già effettuate.
Il fornitore si avvale normalmente di applicazioni software per l’elaborazione e la rendicon- tazione dei dati. I requisiti di dette applicazioni possono essere stabiliti dal committente
che, in questo caso, segue anche le fasi di progettazione e realizzazione svolgendo, in tal modo, un controllo preventivo sui dati che saranno rendicontati, attraverso l’approvazione delle specifiche di elaborazione e aggregazione dei dati e mediante il collaudo finale del- l’applicazione. Se il committente dispone già di un sistema di elaborazione e rendicontazio- ne dei dati, può essere richiesta al fornitore una personalizzazione delle applicazioni esi- stenti, da realizzare nel corso delle fasi di progettazione e realizzazione del servizio. Il forni- tore può utilizzare, inoltre, elementi hardware e software di misura che possono interagire con il sistema di elaborazione e rendicontazione trasferendo automaticamente i dati rilevati. Nella fase di erogazione il fornitore svolge tipicamente anche altre attività di conduzione operativa del sistema di elaborazione e rendicontazione quali la gestione delle utenze, lan- cio di procedure software, backup e manutenzione.
Le modalità di rendicontazione dei risultati delle rilevazioni ed elaborazioni effettuate dovrebbero essere descritte nel dettaglio sui documenti contrattuali; negli stessi documenti dovrebbero essere indicati la struttura ed i contenuti informativi dei prospetti di stampa, la frequenza di consegna, i destinatari, gli eventuali meccanismi di approvazione ed i relativi tempi. Queste indicazioni dovrebbero produrre il documento “piano delle consegne” da sti- lare prima dell’inizio dell’erogazione del servizio e che dovrà essere approvato dal commit- tente ed essere il riferimento delle attività di rendicontazione.
5.2. Attività di competenza dell’Amministrazione
Come accennato nel paragrafo precedente l’Amministrazione può concorrere con proprie risorse nell’erogazione di un servizio. Essa, infatti, può fornire personale, strumenti o infra- strutture al fornitore, che dovranno essere gestiti in coerenza con le specifiche esigenze del servizio stesso.
In questo caso, tra le attività di governo del contratto, occorre considerare anche il control- lo su quanto di competenza dell’Amministrazione.
Un ruolo attivo dell’Amministrazione può essere un elemento di criticità per la presenza di due esecutori con un obiettivo comune e responsabilità diverse.
Presupposto indispensabile per mitigare i rischi derivanti da queste modalità di erogazione del servizio è quello di definire in modo analitico, sui documenti contrattuali, anche i com- piti dell’Amministrazione, utilizzando elementi oggettivi per il controllo quali indicatori di prodotto e di prestazioni.
In questo modo il fornitore è in grado di valutare in modo preciso il contributo dell’Ammi- nistrazione e può stimare correttamente il livello qualitativo del servizio che è in grado di fornire.
Le responsabilità, inoltre, sono conseguentemente individuate: l’Amministrazione deve for- nire quanto concordato per il supporto con i requisiti quantitativi e qualitativi stabiliti, il for- nitore deve erogare il servizio nel rispetto del profilo di qualità richiesto.
86
Nel corso della fase di erogazione del servizio l’Amministrazione, nel caso abbia un ruolo attivo, ha il compito di controllare che il supporto che fornisce per l’erogazione del servizio rispetti i vincoli temporali e di qualità ed eventualmente intervenire con azioni correttive.
Questo significa che l’Amministrazione deve costituire, prima dell’inizio dell’erogazione del servizio, un team di persone preposto a svolgere queste attività.
L’Amministrazione può affidare le attività di controllo e l’individuazione delle eventuali azioni correttive ad una società esterna che abbia le medesime competenze richieste per il monitoraggio dei contratti. Se è già presente una società che svolge il monitoraggio sul con- tratto ci si può avvalere di questa anche per queste specifiche attività.
Secondo la normativa vigente, infatti, l’Amministrazione deve svolgere il monitoraggio su tutti i contratti di grande rilievo, che abbiano cioè un particolare rilievo per l’importo della fornitura oppure per l’importanza che essa riveste nello svolgimento dei compiti istituziona- li dell’Amministrazione.
Il monitoraggio fornisce un importante supporto al governo dei contratti da parte dell’Am- ministrazione. Esso consiste in un insieme coordinato di azioni di controllo sui processi adottati dal fornitore, sul rispetto dei requisiti contrattuali sui servizi richiesti, sull’adeguatez- za della fornitura rispetto alle effettive esigenze.
Un importante elemento che offre garanzie sull’operato del fornitore riguarda certamente la qualità del processo adottato dal medesimo. Un processo è di qualità se è controllabile e controllato attraverso un sistema di gestione della qualità che utilizza modelli di riferimento che derivano da norme internazionali riconosciute e diffuse.
Un processo di qualità fornisce elevate garanzie di realizzare quanto stabilito contrattual- mente, in quanto è possibile svolgere un’azione di prevenzione sui disservizi, rimuovendo le cause di non conformità rilevate sui processi di erogazione del servizio, prima che que- ste producano un decadimento delle prestazioni.
Un processo di qualità controllato, inoltre, consente una diminuzione dei costi di gestione del contratto per il fornitore in quanto, oltre a prevenire parte dei disservizi, si stabilisce un rapporto di fiducia tra le parti dal quale ne consegue una riduzione del numero di controlli sul processo da parte dell’Amministrazione, sempre onerosi per il fornitore.
Questo vantaggio economico per il fornitore è anche un vantaggio indiretto per l’Ammini- strazione in quanto si riduce il rischio di operare con una controparte in sofferenza econo- mica che tipicamente tenta di recuperare riducendo la qualità dei servizi da erogare.
Poter avere, quindi, la garanzia di un fornitore che adotti processi di qualità significa per l’Amministrazione governare più agevolmente il contratto e con minori rischi. Questa garanzia può derivare dal possesso, da parte del fornitore, di una certificazione di confor- mità dei propri processi aziendali ai modelli previsti dalle norme ISO rilasciata da uno degli organismi accreditati da appositi enti nazionali.
Il possesso della certificazione dovrebbe, quindi, essere un elemento che concorre alla valutazione dei potenziali fornitori nelle gare di appalto dei servizi ICT.
87
Nella fase successiva alla stipula del contratto, cioè nel corso di erogazione dei servizi, gli aspetti di qualità possono essere garantiti attraverso un attento e accurato controllo da parte dell’Amministrazione sugli adempimenti contrattuali del fornitore e sull’adeguatezza dei livelli di servizio richiesti.
Il controllo di questo secondo aspetto permette di correggere caratteristiche di qualità che vengono valutate dall’utenza inferiori alle aspettative. Tutto ciò è possibile se il contratto
prevede la possibilità di contrattare e modificare in corso d’opera l’accordo sui livelli di ser- vizio da erogare.
In ogni caso tale rilevazione può risultare utile per la stipula dei contratti successivi.
Nel corso dell’erogazione dei servizi l’Amministrazione, oltre alle attività di controllo, ha il compito di svolgere tutte quelle attività di conduzione che riguardano la gestione dei paga- menti, la gestione dei rischi e la chiusura del contratto. Nei paragrafi successivi sono descritte le attività di competenza dell’Amministrazione che riguardano sia i controlli sia le attività di conduzione.
5.2.1. Controllare gli adempimenti contrattuali
Tutte le caratteristiche del servizio che l’Amministrazione affida ad un fornitore dovrebbero essere descritte sui documenti contrattuali. In questo modo il fornitore ha un riferimento certo sulle modalità di erogazione del servizio e l’Amministrazione è in grado di controllare agevolmente quanto fornito. Il servizio deve essere descritto in termini di obiettivi che devono riflettere il punto di vista e le aspettative dell’utente. Quando il servizio è particolar- mente complesso o innovativo devono essere inoltre indicati e descritti i processi di produ- zione al fine di eliminare possibili ambiguità. Occorre poi esplicitare i criteri di attivazione del servizio, cioè le modalità di richiesta da parte dell’utente del singolo intervento, ed i cri- xxxx di chiusura, cioè l’evento che determina il completamento dell’intervento. Devono esse- re definiti i livelli di servizio ed i relativi valori di soglia che rappresentano il profilo qualita- tivo del servizio, le penali associate e le dimensioni quantitative massime previste per il ser- vizio. Nel contratto deve essere anche descritto il sistema di rendicontazione all’Amministra- zione, in particolare devono essere individuati i prospetti di riscontro, i relativi contenuti informativi e la loro periodicità di consegna.
L’Amministrazione deve tenere costantemente sotto osservazione i livelli di servizio che, se ben definiti, rappresentano l’elemento primario di valutazione del servizio. Solo se questi indicatori non rispondono a quanto stabilito è opportuno eseguire specifiche indagini su altri aspetti.
88
Il profilo qualitativo minimo che il committente accetta è definito dall’insieme dei valori di soglia dei livelli di servizio. Tali valori possono essere quelli richiesti in fase di gara oppure essere quelli presenti nell’offerta del fornitore nel caso in cui quest’ultimo abbia presentato una proposta migliorativa. I valori dei livelli di servizio sono rilevati, elaborati e rappresen- tati dal fornitore che li rendiconta al committente. Gli strumenti di rendicontazione devono essere definiti in modo da facilitare l’individuazione di criticità da parte di quest’ultimo, evi- denziando i livelli di servizio fuori soglia, indicando gli scostamenti e riportando l’anda- mento dei valori rilevati nel tempo. Può essere utile riportare i riferimenti di eventuali docu- menti consegnati dal fornitore che segnalano l’applicazione di azione correttive a fronte di precedenti sforamenti dei valori di soglia. L’insieme di queste informazioni fornisce all’Am- ministrazione un quadro di riferimento che permette di valutare l’entità del fenomeno ed i rischi aggiuntivi e di stabilire se la situazione è sotto controllo.
Un approfondimento sui dati rendicontati dal fornitore è sempre opportuno quando il ser- vizio può procurare danni anche a fronte di un lieve degrado. L’approfondimento può
riguardare l’analisi delle rilevazioni precedenti sui livelli di servizio basato anche su altri dati del servizio, quali i volumi erogati, i picchi di richiesta nell’arco della giornata, del mese o dell’anno, la distribuzione delle richieste per tipologia di utenza o altri dati che possono essere significativi e che dovrebbero essere identificati prima dell’erogazione del servizio e richiesti tra i dati di rendicontazione.
Se l’Amministrazione ritiene che la situazione non sia completamente sotto controllo deve iniziare ad utilizzare gli strumenti a propria disposizione per intervenire sul fornitore. Uno strumento può essere quello di prospettare l’applicazione delle penali previste contrattual- mente in quanto queste, oltre a produrre un danno economico, sono in molti casi anche un deterrente psicologico. In questo modo si può convincere il fornitore a intervenire anche con azioni economicamente onerose.
Un’alternativa, che richiede un ruolo più attivo dell’Amministrazione, consiste nel controlla- re i processi adottati dal fornitore mediante visite ispettive allo scopo di verificare che siano rispettate le indicazioni riportate nella documentazione contrattuale e nel manuale di qua- lità. In questo caso se si rilevano non conformità ed il fornitore non interviene nei modi e/o nei tempi stabiliti sta l’Amministrazione può prospettare, nel caso il fornitore sia in possesso di una certificazione di qualità, l’invio di una segnalazione agli organi che rilasciano la certi- ficazione, finalizzata ad avviare un processo di nuova verifica del possesso dei requisiti. Questa alternativa è possibile solo nel caso in cui l’Amministrazione disponga delle compe- tenze per poter svolgere visite ispettive sul processo del fornitore o si avvalga di una società di monitoraggio.
Come detto, le attività di rilevazione e rendicontazione dei livelli di servizio sono a carico del fornitore il quale, per svolgere questa attività, si avvale di un sistema che si compone di strumenti di misura e trasmissione dei risultati, prodotti hardware e software per la registra- zione, elaborazione e presentazione dei risultati, procedure per la manipolazione dei dati, personale con varie competenze. Il sistema è testato prima dell’inizio dell’erogazione del servizio dal fornitore e collaudato dall’Amministrazione se è previsto che essa segua le fasi di progettazione e realizzazione del servizio stesso. Questi controlli garantiscono, solo in parte, la correttezza dei dati rendicontati durante l’erogazione del servizio, che è anche legata ad una adeguata manutenzione delle componenti del sistema, alla corretta applica- zione delle procedure di manipolazione dei dati ed infine alla presenza di malfunzioni del sistema non individuate durante le fasi di test e collaudo.
L’Amministrazione deve perciò pianificare, nel corso dell’erogazione dei servizi, dei control- li cadenzati sul sistema di rilevazione e rendicontazione, finalizzati a verificare l’attendibilità dei dati messi a disposizione dal fornitore. In aggiunta possono essere eseguiti ulteriori controlli quando emergono dei segnali disomogenei rispetto ai livelli di servizio rendiconta- ti (es. utenza insoddisfatta e livelli di servizio entro i valori di soglia).
89
Il controllo, eseguito a campione, deve essere esteso a tutte le fasi che contribuiscono alla creazione del dato di rendicontazione, a partire dalla rilevazione dei dati elementari. Nel caso siano previste delle procedure manuali è opportuno che l’Amministrazione esegua controlli finalizzati a verificare la corretta applicazione delle procedure previste esaminando tutta la documentazione intermedia prodotta.
5.2.2. Controllare l’adeguatezza dei livelli di servizio richiesti
Il profilo qualitativo di ogni servizio affidato ad un fornitore viene definito e richiesto dalle amministrazioni e dovrebbe derivare dalle esigenze dell’utenza nella sua accezione più ampia (compresi gli stakeholders).
Prima di richiedere un servizio, l’Amministrazione dovrebbe rilevare tali esigenze e delinea- re un profilo di qualità mediante adatti livelli di servizio e relativi valori di soglia.
In alcuni casi questa operazione è piuttosto difficile, per esempio quando è la prima volta che il servizio viene richiesto o quando cambiano aspetti rilevanti. Ci si può avvalere dell’e- sperienza di altre amministrazioni per il medesimo servizio ma le esigenze potrebbero esse- re diverse.
La valutazione precisa dell’adeguatezza del servizio fornito può essere eseguita solo in corso d’opera attraverso una rilevazione del grado di soddisfazione di chi utilizza il servizio. Tale valutazione è utile anche se non si tratta di servizi che sono richiesti per la prima volta, in quanto le esigenze degli utenti possono mutare nel tempo ed è quindi necessario mante- nere sempre attivo un canale comunicativo di questo tipo.
La rilevazione del grado di soddisfazione degli utenti misura le differenze che percepiscono gli utenti stessi tra le prestazioni erogate e le proprie esigenze implicite, esplicite e latenti. Essa deve essere preparata, cioè devono essere individuati i servizi e selezionati i metodi di rilevazione più idonei. In alcuni casi l’obiettivo non è un servizio nel suo complesso ma uno o più specifici elementi considerati prevalenti nella costruzione della qualità.
Occorre inoltre individuare con precisione i confini dell’utenza, individuandone le caratteri- stiche che possono incidere sulla valutazione (posizione geografica, intensità di utilizzo del servizio), le componenti di giudizio che si ritiene utile valutare, il livello di precisione che si vuole ottenere.
Dopo aver scelto l’ambito di intervento si decide se coinvolgere tutte le tipologie di utenza o parte di esse, che possono risultare rappresentative e che, comunque, sono di particolare interesse per il servizio.
Prima di iniziare la raccolta dei dati, è opportuno verificare se esistono informazioni già disponibili, anche raccolte da altri soggetti per scopi diversi, che possono essere utili come spunto per la progettazione del questionario o per la scelta del metodo di campionamento. Nei casi in cui il servizio è rivolto al cittadino ed è ritenuto rilevante dall’Amministrazione, è opportuno realizzare un sistema di registrazione permanente dei dati raccolti, definendo le specifiche modalità di raccolta in funzione del loro utilizzo.
Questo sistema dovrebbe anche contenere dati interni all’Amministrazione (flussi di utenza, la distribuzione nell’arco della giornata, tipologie di richieste di servizio, etc).
Sulla base delle informazioni disponibili, si procede alla scelta del modello da utilizzare. Due di questi sono ritenuti particolarmente adatti alla valutazione della soddisfazione dell’u- tenza nell’ambito dei servizi: rilevazione delle attese e delle percezioni, valutazione della soddisfazione ponderata.
90
Nel primo modello viene posta a confronto la qualità come è percepita dall’utente con le sue aspettative (qualità attesa).
Per ogni bisogno si rileva la soglia di tolleranza e si verifica in quale misura la qualità per- cepita da chi ha usufruito di un servizio è superiore o inferiore rispetto a quella attesa.
Questo metodo presenta però dei limiti se è applicato ad un vecchio utente del servizio, in quanto, per quest’ultimo, diventa molto difficile pensare a quali erano le sue aspettative in origine dopo un utilizzo che si protrae nel tempo, e tende a sovrapporre le aspettative con la qualità del servizio percepita.
Nel caso in cui il servizio è nuovo o è stato modificato profondamente questo problema non si presenta.
La valutazione della soddisfazione ponderata è la tecnica più diffusa. Con questa metodolo- gia si rilevano due valutazioni su diverse dimensioni del servizio: l’importanza che l’utente attribuisce a quella dimensione e quanto è soddisfatto in relazione alla stessa.
Dall’esperienza si è rilevato che un limite di tale metodo riguarda la difficoltà dell’utente a distinguere il concetto di importanza da quello di soddisfazione.
Per ovviare a questo problema si può procedere attraverso una rilevazione indiretta sull’im- portanza delle dimensioni del servizio.
Vengono inserite nel questionario domande relative alla soddisfazione complessiva del ser- vizio. In questo modo ogni intervistato fornisce un punteggio su ognuna delle dimensioni di qualità e sulla qualità complessiva del servizio.
Correlando, poi, il punteggio di ogni dimensione della qualità con quello della soddisfazio- ne complessiva si può valutare l’importanza e il contributo di ciascuna dimensione di qua- lità nell’ottenere un buon livello di soddisfazione complessiva.
Dopo aver definito il modello di riferimento si procede alla raccolta dei dati. Essa è prece- duta da una rilevazione preliminare per individuare le caratteristiche principali del servizio identificandole con i nomi utilizzati dagli utenti. In questo modo è possibile predisporre un questionario facilmente comprensibile e che si riferisce a dimensioni di qualità condivise con l’utente.
La redazione del questionario si compone di un insieme di domande che mirano a racco- gliere in modo omogeneo le informazioni oggetto dell’indagine, in quanto agli intervistati vengono poste le medesime domande con la stessa sequenza.
La stesura del questionario rappresenta una fase veramente critica, in quanto la stessa domanda, formulata in modo diverso, può dare origine a risultati molto diversi. Per ovvia- re, almeno in parte, a questo problema è opportuno che il questionario sia sottoposto a collaudo.
I test del questionario devono essere ripetuti fino a quando non terminano le modifiche al testo. Questo permette di evitare interventi durante l’utilizzo tra una rilevazione e quella successiva che renderebbero impossibile il confronto tra i dati.
Le modalità di rilevazione più utilizzate sono l’intervista personale, l’intervista telefonica e l’autocompilazione. Le ultime due sono le più utilizzate in quanto meno costose.
La scelta della tecnica più appropriata va effettuata caso per caso in base a diversi fattori, quali la tipologia del servizio oggetto di indagine, la tipologia della rilevazione (prima rile- vazione o rilevazioni successive), le sue caratteristiche, il target a cui si rivolge, il budget ed i tempi disponibili per la rilevazione.
91
Insieme alla modalità di rilevazione occorre anche stabilire le dimensioni del campione oggetto della rilevazione. Si può scegliere di fare un’indagine estesa a tutti gli utenti o su una parte di essi.
Quando si opera su un campione, l’obiettivo è comunque quello di ottenere dei risultati che descrivono comunque l’intero universo degli utenti.
Normalmente le indagini di customer satisfaction sono realizzate su un campione per con- tenere sia i costi che i tempi di realizzazione. Ad ogni campione è associato un rischio di errore legato al grado di rappresentatività del campione. Comunque eseguendo un’indagine estesa a tutto l’universo si presentano rischi di errore di altro tipo quali imprecisioni, omis- sioni, errori nel trasferimento dei dati, più frequenti in indagini con un elevato numero di intervistati.
La scelta sulla dimensione del campione non dovrebbe essere dettata dalla necessità di contenere i costi ed i tempi, in quanto un campione ridotto potrebbe fornire risultati non significativi rendendo inutile la rilevazione.
Il dimensionamento del campione deve essere fatto tenendo conto sia del contesto della rilevazione, sia della qualità del risultato che si vuole ottenere. Per contesto della rilevazio- ne si intende la numerosità dell’utenza ed il suo grado di eterogeneità mentre per qualità di rilevazione è riferita all’errore ammesso.
Con l’aumentare del numero degli utenti dovrebbe crescere la dimensione del campione ma non in modo proporzionale in quanto un’utenza di dimensioni limitate, e quindi un campione ridotto, è fortemente esposto a rischi di distorsione. Il campione, in questi casi, può aumentare in misura meno che proporzionale in quanto utilizzando numeri più grandi si riduce il rischio di scarsa rappresentatività.
Anche il grado di eterogeneità dell’utenza è un fattore importante per dimensionare il cam- pione in quanto più esso aumenta più lievitano i rischi di selezionare un campione poco rappresentativo. Il grado di eterogeneità va determinato sulla base dei comportamenti del- l’utenza in relazione al fenomeno che si vuole analizzare.
L’errore ammesso è infine l’errore dovuto al tipo di campionamento che si ritiene accettabi- le ai fini della specifica rilevazione. Al crescere delle dimensioni dell’errore ammesso dimi- nuisce la dimensione del campione.
Definito il campione ed eseguita la rilevazione si procede all’elaborazione e interpretazione dei risultati.
I dati sono aggregati in modo da evidenziare gli aspetti significativi quali la distribuzione degli utenti per livello di soddisfazione, gradazione per importanza dei bisogni espressi, valori attesi minimi e massimi.
Le elaborazioni consistono nel calcolare le medie aritmetiche, medie ponderate che consen- tono di pesare la soddisfazione su un aspetto del servizio rispetto all’importanza che ad esso attribuisce l’intervistato.
Risultano, inoltre, interessanti i dati elaborati sulle variabilità in quanto indicano quanto varia la valutazione tra i diversi intervistati.
92
I dati elaborati devono essere interpretati focalizzando aspetti specifici, quali per esempio la distribuzione nel tempo degli utenti insoddisfatti, le ragioni di insoddisfazione ed i pesi attribuiti in base all’importanza ed altre valutazioni finalizzate ad individuare le azioni di miglioramento e le relative priorità.
L’attività di interpretazione dei dati è facilitata dall’utilizzo di grafici e tabelle. Ad esempio si usano spesso i grafici in cui sulle ordinate è riportato il grado di soddisfazione relativamen-
te ad un aspetto del servizio e sulle ascisse il peso attribuito al medesimo. Il grafico è sud- diviso in quattro quadranti ed all’interno di ogni quadrante sono indicati gli aspetti del ser- vizio che rientrano nel range dei valori attribuito al quadrante.
Di seguito è riportato un tipico esempio di rappresentazione grafica della rilevazione sulla soddisfazione degli utenti.
Tempo di attesa | Competenza | |
Empatia | Tempo per la soluzione |
S
o d d i s f a z i o n e
Peso
L’aspetto indicato nel quadrante in basso a destra deve essere prioritariamente preso in considerazione per migliorare le prestazioni in quanto è ritenuto importante dall’utenza e non è adeguato alle aspettative.
Nel quadrante in alto a sinistra ci sono aspetti ritenuti di scarsa importanza che però soddi- sfano pienamente l’utenza. Per questo occorre sensibilizzare i potenziali utenti sull’impor- tanza dell’aspetto.
Nel quadrante in basso a sinistra ci sono aspetti che dovrebbero essere migliorati ma con bassa priorità in quanto l’utenza attribuisce a questi scarsa importanza.
Nel riquadro in alto a destra infine ci sono gli aspetti del servizio ritenuti importanti dei quali gli utenti si ritengono pienamente soddisfatti. Per questi è necessario un monitoraggio attento delle prestazioni per mantenere alto nel tempo il livello di soddisfazione.
Sulla base di queste considerazioni si deve procedere ad individuare le azioni idonee da applicare ai processi di erogazione agendo sul numero di risorse da impegnare e sulle spe- cifiche competenze, sugli strumenti da utilizzare e sulle procedure con azioni che ne migliorino l’efficacia.
Gli interventi dovrebbero poi essere validati attraverso una successiva analisi di soddisfazio- ne degli utenti.
5.2.3. Svolgere attività di conduzione
93
In aggiunta alle attività di controllo, l’Amministrazione deve svolgere attività di carattere gestionale che riguardano i pagamenti al fornitore, la gestione dei rischi e tutte le attività correlate con la chiusura del contratto.
Senza entrare nel merito delle procedure di pagamento adottate nella Pubblica Amministra- zione, che esulano dalla trattazione del presente manuale, si ritiene utile richiamare i princi- pali modelli di determinazione dei corrispettivi economici descritti nel manuale sulle “strate- gie di acquisizione delle forniture ICT”, con le relative modalità di determinazione dei corri- spettivi, allo scopo di evidenziare quali specifici controlli finalizzati al pagamento dovrebbe- ro essere effettuati in base al modello adottato.
Nel modello a corpo sono stabiliti all’interno del contratto sia il prezzo del corrispettivo complessivo che la segmentazione dei pagamenti (canone, stati d’avanzamento). Occorre distinguere due tipologie di oggetto per questo modello: fornitura di prodotti ICT, messa a disposizione di risorse professionali e ICT. Nel primo caso (es. fornitura di personal compu- ter) la segmentazione è a stati di avanzamento. La misura di riferimento per determinare il momento dei pagamenti è lo stato di avanzamento della fornitura che deve essere rilevato con frequenza prestabilita e valutato utilizzando evidenze oggettive (verbali di consegna, verbali di collaudo/approvazione) ed i criteri per il calcolo che devono essere stabiliti sulla documentazione contrattuale (diversi pesi per tipologia di prodotto, arrotondamenti, etc.). Il personale dell’Amministrazione a cui è affidato questo compito autorizza i pagamenti a fronte del raggiungimento degli obiettivi di avanzamento previsti ed eventualmente deter- mina il valore delle penali nel caso rilevi inadempienze da parte del fornitore. In questo caso le penali sono tipicamente associate a ritardi nella consegna dei beni o a collaudi ripe- tutamente non superati.
Sempre nel modello a corpo, ma nel caso in cui l’oggetto a cui il corrispettivo si lega è
costituito dalla messa a disposizione di un insieme di risorse ICT e professionali, per le quali è già stabilita sia la quantità che la qualità, si usa invece la segmentazione dei paga- menti a canone. In questo caso sia i momenti di pagamento, sia i relativi importi da corri- spondere sono già stabiliti a meno di eventuali penali che tipicamente sono correlate al mancato rispetto dei vincoli qualitativi e quantitativi delle risorse. L’Amministrazione deve eseguire un costante controllo sulle risorse professionali messe a disposizione dal fornitore mediante la rilevazione nominativa delle presenze. Essa deve controllare, inoltre, che i vin- coli stabiliti per le sostituzioni del personale vengano rispettati al fine di mantenere costante il grado di professionalità delle risorse che sono messe a disposizione.
94
Nel modello a consuntivo il corrispettivo è determinato in base alle prestazioni effettiva- mente erogate dal fornitore. Esse possono riguardare il numero ed il profilo di risorse pro- fessionali utilizzate, la quantità dei prodotti ICT forniti oppure i volumi di servizio erogati. Nel primo caso i contratti possono prevedere dei vincoli sulla produttività del personale: in questo caso l’Amministrazione, a fine contratto o con cadenza prestabilita deve misurare le dimensioni di quanto realizzato/erogato e calcolare la produttività media in base alle risorse messe a disposizione. Questo maggior onere per l’Amministrazione è ampiamente giustifi- cato dal fatto che in questo modo si mantiene un costante controllo sull’operato delle risor- se e, di conseguenza, sui costi della fornitura. L’Amministrazione deve attentamente control- lare, inoltre, che i profili professionali delle risorse messe a disposizione siano coerenti con i vincoli contrattuali, in quanto il personale rappresenta, nella maggior parte dei casi, un importante elemento di rischio per le forniture di servizi.
Nel caso in cui le prestazioni riguardino la quantità di prodotti ICT forniti, le attività di rile- vazione sono analoghe a quelle descritte per il modello a corpo. Le modalità di determina- zione dei corrispettivi sono diverse in quanto, in questo caso, l’importo da riconoscere non è stabilito contrattualmente ma è calcolato in base alle quantità di prodotto effettivamente fornita.
Infine, se le prestazioni riguardano un servizio il cui corrispettivo è determinato in base all’entità dei volumi erogati, le attività di rilevazione sono tipicamente svolte dal fornitore con strumenti di rilevazione automatica che alimentano un sistema di rendicontazione. Com- pito dell’Amministrazione, in questo caso, è quello di verificare l’affidabilità dei dati rendi- contati dal sistema attraverso controlli a campione sul processo adottato dal fornitore per la rilevazione, elaborazione e rendicontazione dei dati utilizzati per il calcolo dei corrispettivi.
Le attività relative a questo aspetto, e che sinteticamente riguardano l’individuazione dei fat- tori di rischi (Risk Assessment), la definizione di azioni preventive e di contrasto, la predi- sposizione di un piano di attività di controllo e la sua esecuzione nel corso dell’erogazione del servizio, sono tipicamente di competenza del fornitore. Se si tratta, però, di servizi che hanno particolare rilevanza (elevato numero di utenti serviti, elevati danni agli utenti a seguito di disservizi, etc), o nei casi in cui si voglia comunque una maggiore garanzia sulla corretta erogazione del servizio, è opportuno che l’Amministrazione richieda contrattual- mente la documentazione inerente alla gestione dei rischi per verificarne l’esistenza, valu- tarne i contenuti e, durante l’erogazione, controllare a campione il rispetto del piano per la gestione dei rischi. Riguardo ai contenuti di questo documento l’Amministrazione deve focalizzare l’attenzione sulle azioni di prevenzione e di contrasto e valutarne l’adeguatezza rispetto alla specificità del servizio. Se si tratta di un servizio in cui l’intervento umano è prevalente occorre valutare se la formazione e l’addestramento del personale è sufficiente, se sono previste azioni preventive di riduzione del turnover (per esempio retribuzioni di mercato al personale), se le procedure per l’avvicendamento del personale prevedono periodi di affiancamento adeguati. Un altro elemento da non sottovalutare riguarda il numero di risorse allocate rispetto alla mole di lavoro prevista (produttività media del per- sonale). Maggiore è il valore di produttività atteso più è bassa la capacità di compensazione del gruppo operante rispetto a situazioni critiche dovute ad assenza massiccia del personale per malattia o per altri eventi non prevedibili.
Se il servizio richiesto è invece caratterizzato da un ridotto intervento umano e le prestazio-
95
ni dipendono dal funzionamento di apparati hardware, strumenti, reti di connessione, pro- dotti software, ecc., gli eventi critici riguardano guasti e malfunzionamenti dei medesimi. In questo caso le azioni di prevenzione riguardano l’adozione di prodotti con elevata qualità ed in particolare con alta affidabilità durante l’utilizzo. Questa può essere garantita sia dalla fama dell’azienda produttrice sia dal fatto che il prodotto è stato ampiamente testato dal mercato. Le azioni di contrasto riguardano i servizi di assistenza e di manutenzione e, in particolare, i relativi valori di soglia per i livelli di servizio che misurano la tempestività di intervento e di ripristino degli elementi utilizzati nell’erogazione del servizio. Essi devono essere compatibili con le prestazioni richieste per il servizio principale.
Esiste poi un elemento di rischio che è gestito esclusivamente dall’Amministrazione ed è presente in tutti i casi in cui il corrispettivo del servizio è calcolato in base alle risorse effet- tivamente erogate ed è previsto un tetto massimo di spesa non superabile. L’elemento di rischio aggiuntivo è il raggiungimento del tetto di spesa prima del completamento del con- tratto con l’impossibilità di poter richiedere, da quel momento in poi, nuovi interventi. L’Amministrazione può gestire tale situazione pianificando, per quanto possibile, gli inter- venti sulla base di priorità prestabilite in relazione, per esempio, al tipo di intervento. Occorre inoltre tener conto della frequenza con cui si presentano interventi improcrastina- bili per mantenere a disposizione, fino alla fine del contratto, una posta economica per poter svolgere questi interventi. Il periodo che può risultare critico è quello antecedente alla scadenza del contratto. Per stabilire la frequenza e le dimensioni di questo tipo di interventi, si può fare riferimento ai dati storici del servizio. In base a questi dati ed in rela- zione al tempo residuo si stabilisce il valore economico da lasciare a disposizione che va rideterminato periodicamente.
Per i contratti di erogazione dei servizi in alcuni casi è necessario che il fornitore, a ridosso della scadenza contrattuale, svolga delle attività finalizzate a favorire l’avvicendamento di un altro fornitore nell’erogazione di uno o più servizi. I casi tipici riguardano i servizi per i quali è imprescindibile la continuità dei livelli di servizio. Al fornitore con il contratto in sca- denza è richiesto di trasferire le informazioni riguardanti l’utilizzo degli strumenti di supporto all’erogazione del servizio, nel caso in cui tali strumenti siano messi a disposizione dall’Am- ministrazione e quindi debbano essere utilizzati anche dal fornitore subentrante, le procedu- re per l’erogazione del servizio ed eventualmente altri argomenti specifici inerenti il servizio da erogare. Le informazioni da trasferire e le relative modalità (affiancamento, sessioni in aula, ecc.) dovrebbero essere definite contrattualmente. L’Amministrazione ha il compito sia di operare affinché la nuova fornitura sia avviata in tempi compatibili con la durata dell’af- fiancamento, sia di esaminare il piano di affiancamento predisposto dal fornitore uscente per verificare la presenza di tutte le attività necessarie e la coerenza con le date di riferimento del vecchio e del nuovo contratto. Nel corso dell’affiancamento l’Amministrazione deve veri- ficare, come per tutti gli altri servizi, il rispetto del piano concordato e dei vincoli di qualità. Nel periodo antecedente la scadenza del contratto, inoltre, l’Amministrazione deve iniziare a pianificare il rilascio delle risorse (personale, strumenti, locali, etc.) che sono state impe- gnate sia nell’attività di governo, sia quelle eventualmente impegnate direttamente nelle attività di erogazione del servizio. Anche in questo caso è opportuno che venga stilato un piano di rilascio dopo aver identificato tutte le attività ancora da realizzare o completare, con le relative risorse allocate. Il piano deve essere trasmesso agli uffici preposti alla gestio- ne delle risorse (es. uff. del personale) concordando la data di consegna che deve essere compatibile con i tempi necessari per la ricollocazione del personale.
Un ultimo passo, a volte trascurato, ma sicuramente importante, specialmente se il servizio
96
è rivolto direttamente al cittadino, è la valutazione del servizio a conclusione della sua ero- gazione, finalizzata al suo miglioramento attraverso le esperienze maturate. Se questa atti- vità è già svolta nel corso dell’erogazione del servizio, a conclusione del contratto è suffi-
ciente raccogliere, classificare, elaborare e registrare i dati rilevati. Un servizio è finalizzato a soddisfare i bisogni dell’utenza, quindi il profilo di qualità del servizio deve essere deriva- to da quanto si attende chi l’utilizza (qualità attesa). A volte le amministrazioni non dispon- gono di queste informazioni e richiedono al fornitore un profilo di qualità diverso (qualità richiesta), che può anche essere migliore rispetto alle aspettative. Nella fase di erogazione poi, il fornitore può dare il servizio con un profilo di qualità (qualità erogata) che si scosta con quanto richiesto accrescendo ancora la distanza tra le effettive esigenze dell’utenza ed il servizio erogato.
Il grafico che segue rappresenta le possibili situazioni che possono determinarsi.
Qualità erogata dal fornitore
1
2
3
4
5
6
7
Qualità contrattualmente richiesta
La situazione ottimale è la perfetta sovrapposizione tra i tre cerchi della qualità. Normal- mente invece la sovrapposizione dei tre cerchi riguarda solo un’area che, nel caso del dise- gno, è contraddistinta dal numero 4. Le altre aree hanno il seguente significato:
1. esigenze degli utenti non considerate nella richiesta di servizio e non assolte dal ser- vizio erogato;
2. esigenze degli utenti non considerate nella richiesta di servizio ma casualmente assolte dal servizio erogato;
3. esigenze degli utenti considerate nella richiesta di servizio e non assolte dal servizio erogato (non rispetto da parte del fornitore dei valori di soglia stabiliti);
4. esigenze degli utenti considerate nella richiesta di servizio e assolte dal servizio ero- gato;
5. qualità erogata non attesa (inutile) e non richiesta;
97
6. qualità erogata non attesa ma richiesta;
7. qualità richiesta non attesa e non erogata.
L’analisi dei dati raccolti deve essere finalizzata ad aumentare l’area del settore 4 ed a ridur- re le aree dei settori 5, 6, 7 in quanto inutili.
Come è già stato precisato il riferimento è la qualità attesa - i cui dati sono rilevati dall’inda- gine sulla soddisfazione degli utenti - che deve garantire una rilevazione su tutti gli aspetti di interesse degli utilizzatori del servizio, mediante dei questionari che consentano di rileva- re le valutazioni anche su caratteristiche non specificatamente previste in fase di progetta- zione del questionario stesso (note a disposizione del compilatore). In caso contrario il cer- chio della qualità attesa sarebbe incompleto e non si potrebbe migliorare la qualità del ser- vizio per le caratteristiche non rilevate.
Per ogni caratteristica occorre considerare l’importanza che viene attribuita dall’utenza: nel caso in cui una o più caratteristiche risultino irrilevanti, l’Amministrazione deve modificare il sistema dei livelli di servizio definito per descrivere il profilo di qualità da richiedere al for- nitore, eliminando gli indicatori che fanno riferimento alla caratteristiche in questione, in quanto fonti di costo del servizio ma inutili ai fini della qualità.
Per quanto riguarda le caratteristiche considerate rilevanti per l’utenza, occorre considerare, per ognuna di esse, il grado di soddisfazione espresso e confrontare questo dato con quan- to rilevato in fase di erogazione, mediante la misura degli indicatori specifici della caratteri- stica. Se l’utenza risulta soddisfatta significa che il servizio è stato erogato in modo adegua- to. Come valori di soglia degli indicatori dovrebbero essere assunti i valori misurati. In questo senso occorre verificare i valori di soglia stabiliti nel contratto ed eventualmente modificarli nei contratti successivi.
Nel caso in cui l’utenza risulti insoddisfatta in relazione ad una caratteristica di qualità, occorre innanzitutto verificare se il servizio è stato erogato nel rispetto dei valori di soglia relativi alla caratteristica. Se non è così, il problema è legato al mancato rispetto dei vincoli contrattuali da parte del fornitore ed è opportuno valutare l’articolazione delle penali anche in funzione dell’importanza che viene attribuita al servizio dagli utenti. Se invece il servizio è stato erogato dal fornitore nel rispetto dei valori di soglia stabiliti, anche in questo caso occorre riesaminare questi ultimi e rimodularli, tenendo conto delle aspettative degli utenti, per essere utilizzati nei contratti successivi.
Infine, dall’analisi della rilevazione della soddisfazione degli utenti, possono evidenziarsi delle caratteristiche di qualità ritenute importanti alle quali non sono associati livelli di servi- zio nel profilo di qualità richiesto al fornitore. In questo caso occorre innanzitutto indivi- duare gli indicatori che consentano di misurare efficacemente la caratteristica, sia consultan- do la specifica classe di fornitura riportata nel manuale delle classi, sia facendo ricerche su quanto proposto in letteratura, sia avvalendosi di esperienze di altre amministrazioni. Nei casi in cui non sia possibile definire degli indicatori efficaci si può utilizzare la soddisfazio- ne dell’utenza per la valutazione della caratteristica. Il costo di questa misura potrebbe non giustificare sempre i benefici ed è quindi opportuno valutare in ogni caso questo aspetto durante la scelta degli indicatori.
98
A conclusione della valutazione del servizio l’Amministrazione dovrebbe produrre una scheda di sintesi in cui sono evidenziate le caratteristiche di qualità salienti, i relativi indica- tori ed i valori di soglia aggiornati. Utilizzando queste schede nei futuri contratti si garanti- sce la coerenza tra l’evoluzione delle esigenze degli utenti ed i livelli di servizio richiesti contrattualmente ai fornitori.