febbraio 2007
31/5
febbraio 2007
Linee guida sulla qualità dei beni e dei servizi ICT per la definizione e il governo dei contratti della PA
Manuale 5
Esempi di applicazione
31/5
febbraio 2007
i Quaderni n. 31 febbraio 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
9
Anno V Registrato al Tribunale di Roma
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
15
Xxx Xxxxxx, 00x 00000 Xxxx
Tel. (00) 00 00000.0
I Quaderni del Cnipa sono pubblicati all’indirizzo:
4.1 | Come selezionare le classi di fornitura | ||
E DEFINIRE LE ISTANZE 23 | |||
4.2 | COME INDIVIDUARE ATTIVITÀ E PRODOTTI 26 | ||
4.3 | Come selezionare indicatori di qualità e | ||
DEFINIRE VALORI SOGLIA 28 | |||
Stampa: | 4.4 | Come integrare classi di fornitura e |
21
ESEMPI DI APPLICAZIONE MANUALE APPLICATIVO
1. Generalità sul documento
2. Gruppo di Lavoro
3. Modalità di utilizzo delle classi di fornitura
3.1. LOGICHE DI COMPOSIZIONE DELLE CLASSI DI FORNITURA 16
3.2. INTERAZIONI TRA CLASSI DI FORNITURA E PROCESSI 19
4. Guida alla definizione della fornitura nel Capitolato Tecnico
Stilgrafica srl - Roma
PROCESSI TRASVERSALI 36
5.1 | Caso Full Outsourcing 5.1.1 Descrizione delle esigenze e del contesto | 40 41 |
5.1.2 Selezione classi di fornitura e definizione istanze 5.1.3 Individuazione delle attività e dei prodotti | 43 51 | |
5.2 | 5.1.4 Selezione indicatori di qualità e definizione valori soglia 5.1.5 Modulazione delle penali 5.1.6 Stesura del capitolato tecnico 5.1.7 Considerazioni conclusive Caso Crm 5.2.1 Descrizione delle esigenze e del contesto | 56 59 62 85 85 86 |
5.2.2 Selezione classi di fornitura e definizione ISTANZE | 89 | |
5.2.3 Individuazione delle attività e dei prodotti | 89 | |
5.2.4 Selezione indicatori di qualità e definizione valori soglia 5.2.5 Modulazione delle penali 5.2.6 Stesura del capitolato tecnico 5.2.7 Considerazioni conclusive | 90 91 93 120 |
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 Governo dei contratti ICT
Manuale applicativo Esempi di applicazione
Manuale operativo Dizionario delle forniture ICT
Manuale di riferimento
Modelli 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
Esempi di applicazione
Manuale applicativo
febbraio 2007
Versione 3.0
1. Generalità sul documento
Le Linee guida sulla qualità dei beni e servizi ICT per la definizione ed il governo dei con- tratti 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 proces- si di misura, allo scopo di fornire indicazioni concrete, pragmatiche, immediatamente applicabili, sia alle Amministrazioni appaltanti che ai fornitori offerenti;
• adeguate clausole, da utilizzarsi in fase di negoziazione, per la definizione di Capitolati e contratti pubblici per la fornitura di beni e servizi nel settore ICT, relative alla descrizione delle attività da prevedersi contrattualmente, ai prodotti che dette atti- vità realizzano (deliverables contrattuali), agli indicatori e misure di qualità da riferir- si sia alle attività che ai prodotti;
• clausole successivamente utili nella fase di attuazione dei contratti ICT, per la neces- saria azione di governo del contratto e lo svolgimento del monitoraggio per la verifi- ca del rispetto dei requisiti contrattuali in termini di tempi, costi e stato avanzamento lavori, quantità e qualità attese dei servizi ICT richiesti.
All’interno delle Linee guida lo scopo di questo Manuale applicativo è quello di aiutare a comprendere meglio le logiche di utilizzo delle Classi di fornitura elementari ICT contenu- te nel Manuale operativo “Dizionario delle Forniture ICT”. L’obiettivo non è quello di forni- re “ricette contrattuali” di immediato utilizzo, ma quello di dare indicazioni utili per la costruzione di Capitolati tecnici a partire dalle Classi di fornitura prima citate, attraverso esempi di applicazione delle Linee Guida a casi concreti. In particolare, gli esempi propo- sti consentono di rilevare i passi da compiere per definire la fornitura oggetto di un Capitolato tecnico, evidenziando:
• 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 e come rappresentare diverse istanze di fornitura a partire da un’unica Classe di fornitura;
• come selezionare e personalizzare, tra quelli proposti per ciascuna Classe di forni- tura, attività e prodotti (deliverables) da richiedere al Fornitore in esecuzione del contratto;
11
• come selezionare e personalizzare in funzione delle esigenze dell’Amministrazione, 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.
Il Manuale è strutturato in tre parti. Nella prima parte si riprendono e si completano alcu- ne considerazioni, in parte già rappresentate nei Manuali componenti le Linee guida, relative all’uso delle Classi di fornitura ed alle interazioni tra le classi stesse; nella secon- da parte si presentano i passi logici da compiere per arrivare alla stesura del Capitolato tecnico, a partire dalle Classi di fornitura descritte nel Dizionario e si descrivono le modalità di selezione e personalizzazione di attività, prodotti, indicatori di qualità e valo- ri soglia, in funzione delle esigenze dell’Amministrazione; nella terza parte si presenta- no degli esempi concreti di costruzione di Capitolati tecnici a partire dalle indicazioni contenute nelle Linee guida.
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 cen- trali, che le associazioni di categoria dei fornitori di servizi ICT.
Il Gruppo di Lavoro, di cui è referente l’Xxx. Xxxxx Xxxxxxx, Componente dell’Organo colle- giale del Cnipa, è stato coordinato dal Xxxx. Xxxxx Xxxxxxx, Dirigente del Cnipa. Fanno parte del Gruppo di lavoro:
Xxxxxx Xxxxxxxxxx in rappresentanza del Ministero di Giustizia
Xxxxx Xxxxx Xxxxx;
Xxxxxxxx Xxxx in rappresentanza del MIUR
Xxxxxxxxx Xxxxxxx in rappresentanza di FEDERCOMIN
Xxxxxxx Xxxxxxx in rappresentanza di CONSIP
Xxxxxxxx Xxxxxxxx Xxxxx;
Xxxxxxx X’Xxxxx in rappresentanza dell’INPS
Xxxxxxxx Xxxx in rappresentanza di ASSINFORM
Xxxxxxx Xxxx Xxxxx, consulente;
Xxxxxx Xxxxx in rappresentanza di SOGEI
Xxxxxxx X. Romano in rappresentanza di ANASIN/XXXxxx Xxxxxxx Xxxxxxx Xxxxx, consulente.
Pur non partecipando al Gruppo di lavoro, la Banca d’Italia ha messo a disposizione l’espe- rienza codificata nel proprio manuale di qualità del software e fornito utili indirizzi sul tema dei servizi afferenti allo sviluppo del software, in particolare si ringraziano:
Xxxxxxx Xxxxxxx Xxxxx Xxxxx
Le Amministrazioni direttamente coinvolte nel Gruppo di lavoro, hanno partecipato ai lavo- ri e contribuito alla redazione delle Linee anche per il tramite di proprio personale non direttamente rappresentato nel gruppo, si ringraziano per questo:
Xxxxxx Xxxxxxxxx Xxxxx Xxxxxxx Xxxx Xxxxxxxxxxx
Xxxxxxxxxx Xxxxxxxxxx Xxxxxx Xxxxx
13
Le imprese associate a Anasin/AITech, Assinform e Federcomin, chiamate a partecipare dalle proprie associazioni, hanno risposto con entusiasmo e partecipato alla definizione
delle Linee guida mettendo a disposizione le proprie fattive esperienze di erogazione dei servizi ICT e predisposizione di offerte.
Hanno contribuito con particolare continuità una ventina di diverse imprese, tra le più rap- presentative del mercato ICT nazionale, che hanno contribuito affiancando il gruppo di lavoro con circa 80 persone loro dipendenti.
Alcatel | ||
Bull | CSC Italia | Elsag |
Laser Memory card | Microsoft | Symantec |
ACI Informatica | Business Object | C&M Group |
COMPUWARE | EDS Italia | FINSIEL |
GETRONICS | IBM | ORACLE Italia |
SAP Italia | Sistemi Informativi | Telecom Italia |
Un particolare ringraziamento va pertanto a:
Xxxxx Xxxxxxxxxx | Xxxxxxxx Xxxxx | Xxxxxx Xxxxxx |
Xxxxxxxx Xxxxxxx | Xxxxx Xxxxxxx | Xxxxxxxx Xxxxxxxxx |
Xxxxx Xxxxxxxxxx | Xxxxxxx Xxxxxxxxxx | Xxxxxxxx Xxxxxxxx |
Xxxxx Xxxxxxx | Xxxxxxxxxx Xxxxxxxx | Xxxxx Xxxxxxxxxx |
Xxxxxxxx Xxxxxxxx | Xxxxx Xxxxxxxxxx | Xxxxxxx D’xxxxxxx |
Xxxxxxxx De Xxxxxxxxx | Xxxxxxx De Xxxxxxxxxx | Xxxxxxx Xx Xxxxx |
Xxxxx Xxxxxx | Xxxxxxxx di Xxxxxx | Xxxxx Di Xxx |
Xxxxxxx Xxxxxx | Xxxxx Xxxxxxx | Xxxxx Xxxxxx |
Xxxxxxxxx Xxxxxxx | Xxxxxxx Formato | Xxxxxxxxxx Xxxxxxx |
Xxxxxxxx Xxxxxxxx | Xxxxxx Xxxxxxxx | Xxxxxx Xxxxxxxx |
Xxxxxxxx Xxxxxxx | Xxxxxxxx La Commare | Xxxxxxxx Xxxxxxxx |
Xxxxxxxx Xxxxxxxxxx | Xxxxxxxxxx Xxxxxxx | Xxxxxxxx Xxxxxxxx |
Xxxxxxxx Xxxxxxxxx | Xxxxxxxxx Xxxxxxx | Xxxx Xxxxxxxx |
Xxxxxxxx Xxxxxxx | Xxxxxx Xxxxxx | Xxxxxxxxx Xxxxxxx |
Xxxxxxx Xxxxx | Xxxxxx Xxxxxxxxxxx | Xxxxxxxxxx Xxxxxx |
Xxxxxxxxx Xxxxxxxxxx | Xxxxx Xxxxxxxxxx | Xxxxxxxx Xxxxxxxxx |
Xxxxx Xxxxxxx | Franco Xxxxxxx | Xxxxxxxx Xxxxxx |
Xxxxxxx Xxxxxx | Xxxxx Xxxxxxx | Xxxxx Xxxxxxxxx |
Xxxxxxxx Xxxxxx | Xxxxxxxx Xxxxxxxxxxx | Xxxxxxxx Xxxxxxxxx |
Xxxxxx Xxxxx | Xxxxxx Xxxxxxxx | Xxxx Xxxxxxx |
Xxxxxxxx Xxxxxxxx | Xxxxxxxx Xxxxxxxxx | Xxxxxxx Xxxxxxx Xxxxx |
Xxxxxx Xxxxxx | Xxxxxxx Xxxxxx | Xxxxx Xxxxxxxx |
Xxxxxxxxxx Xxxxx | Xxxxxxxx Xxxxxxxxx | Xxxxx Xxxxxxxxx |
Xxxxxxx Xxxxxxxx Xxxxxxxx | Xxxxxxx N. Xxxxxxxxxx | Xxxxxxx Xxxxxxxx |
Xxxxxx Xxxxxx | Xxxxxxxx Xxxxxxx | Xxxxx Xxxxxxx |
Xxxxxxx Xxxxxxxx | Xxxxxxxxx Xxxxxx | Xxxxx Xxxxxxxxxx |
Xxxxxxx Xxxxxxxxxx | Xxxxxxxx Xxxxxxxxxx |
14
In varie fasi del lavoro il Gruppo si è avvalso anche dei contributi e dei suggerimenti di altre persone ed aziende ICT che, pur non essendo coinvolte operativamente nella scrittura delle Linee guida, hanno seguito con interesse i lavori.
3. Modalità di utilizzo delle Classi di fornitura
Nell’ambito delle attività di acquisizione di beni e servizi da parte di una Pubblica Amministrazione si susseguono diverse fasi che procedono dall’ambito di una visione più generale delle esigenze dell’Amministrazione, non solo attuali ma anche in prospettiva, attraverso scelte strategiche e gestionali, verso la definizione degli elementi di base che costituiranno l’impianto di gara con cui s’intende acquisire tali beni e/o servizi. Non c’è dubbio che la fase imprescindibile e di maggiore difficoltà, in genere, per le strutture dell’Amministrazione è quella in cui si deve affrontare la redazione dei documenti di gara nei quali concretizzare opportunamente le scelte necessarie per indirizzare correttamente le caratteristiche delle offerte verso la soddisfazione delle esigenze dell’utenza e di tutti gli altri portatori di interesse agli effetti dell’acquisizione.
In questa fase diventa fondamentale il momento della scrittura del Capitolato di gara e del relativo modello di contratto cui l’utilizzo del “Dizionario delle Forniture ICT elementari” può dare un diretto supporto fornendo “ricette contrattuali”, di immediato utilizzo, utili per rappresentare le esigenze della stazione appaltante, modificabili, copiabili e incollabili per l’elaborazione di contratti e Capitolati tecnici.
L’utilizzo di tale manuale, costituente una sorta di enciclopedia delle tipologie di forniture possibili deve comunque essere eseguita con una serie di accortezze che consentano, a par- tire da un materiale vasto quale quello reso disponibile, di
• scegliere le corrette Classi di fornitura relative alle proprie esigenze;
• applicarle in modo adeguato al contesto specifico da cui origina la necessità della for- nitura, in base alle indicazioni generali di utilizzo nonché ritagliandone e modifican- done opportunamente gli elementi di dettaglio;
• renderle coerenti tra di loro in una visione unitaria degli obiettivi della fornitura;
• dotarle di tutte le corrette strutture di gestione e controllo che possano garantire l’ef- ficacia e l’efficienza dei beni e servizi acquisiti.
Il presente capitolo intende introdurre ad una comprensione più ampia delle logiche e delle motivazioni che hanno portato all’attuale strutturazione del Dizionario delle Classi di forni- tura ed ai loro contenuti, specie laddove le stesse abbiano relazione con le scelte che si tro- verà a dover fare l’Amministrazione nel momento in cui definirà le caratteristiche generali della propria procedura d’acquisizione.
15
A tal fine e per facilitare, quindi, un utilizzo più consapevole dei lemmi del Dizionario, nei paragrafi seguenti si propongono una serie di considerazioni in merito a quanto detto ed in particolare:
• nel paragrafo 3.1 - Logiche di composizione delle Classi di fornitura si affronta l’or- ganizzazione complessiva del Dizionario, la sua logica di strutturazione nelle varie
Classi di fornitura, le relazioni fra le stesse da tener presenti nell’associarle o meno in un’unica fornitura;
• nel paragrafo 3.2 - Interazioni tra Classi di fornitura e processi trasversali, si forni- scono indicazioni su come richiamare i processi trasversali nella redazione di un Capitolato in rapporto alle Classi di fornitura primarie utilizzate.
3.1 Logiche di composizione delle Classi di fornitura
La suddivisione in classi distinte delle possibili forniture ICT, trattata nel Dizionario, in vari casi ha un effettivo ed evidente riscontro nella concretezza di abituali oggetti acquisiti dalle Pubbliche Amministrazioni in altri può sembrare un esercizio classificatorio delle possibili branche di operatività del settore ICT. In entrambi i casi ciò che deve essere tenuto in con- siderazione è soprattutto la plasticità del materiale reso così disponibile per favorire l’orga- nizzazione dei corpi capitolari, il cui obiettivo è la soddisfazione di un’esigenza nel suo insieme in genere più complessa di quanto può essere abbracciato dalle singole forniture e anche dalla loro semplice addizione o giustapposizione.
La struttura del Dizionario è infatti costituita mediante una serie di elementi, Classi di fornitu- ra, che vogliono rappresentare ognuno, nella loro definizione, il minimo comun denominato- re di tutte quelle esigenze d’acquisizione delle Amministrazioni in merito all’argomento rappre- sentato. Ogni Classe di fornitura, in tal senso, è da considerarsi un nucleo di cui non è consi- gliabile un’ulteriore suddivisione in distinte acquisizioni. Peraltro ognuna di tali classi, come meglio indicato nel successivo paragrafo 4, non è da adottarsi necessariamente in modo inte- grale ai fini dell’acquisizione d’interesse: il contenuto deve essere opportunamente ritagliato e personalizzato per essere adeguato al contesto reale in cui nasce ogni esigenza.
D’altra parte gli estensori dei contratti ICT, nel ricercare la soddisfazione dell’esigenza origina- ria dell’Amministrazione, spesso hanno la necessità di dover comporre insieme più tipi di for- nitura, variamente interrelati fra loro e finalizzati in modo specifico alle caratteristiche di un con- testo preesistente in cui dette forniture devono essere inserite in modo integrato: il caso, infat- ti, della creazione di una struttura informatizzata totalmente nuova, autonoma e non correlata a procedure preesistenti è solo un caso limite nell’ambito della Pubblica Amministrazione.
Quella organizzazione del Dizionario, di cui si è detto, vuol rendere più semplice questa opera di composizione predisponendo elementi opportunamente addizionabili, parzial- mente o integralmente, in un Capitolato, salvo una serie di considerazioni esposte nel seguito perché questa somma possa risultare congruente.
Struttura della catalogazione delle Classi di fornitura
16
Tutte le Classi di fornitura sono descritte in relazione al ciclo di vita delle forniture ICT adot- tato nelle presenti Linee guida e derivato, tramite un’opportuna semplificazione, dalla norma UNI CEI ISO/IEC 12207:2003 (per maggiori dettagli si rimanda al Manuale di riferi- mento “Modelli per la qualità delle forniture ICT”). Questo modello di ciclo di vita delle for- niture, che utilizza quanto proposto dalla norma anzidetta interpretandolo in modo esten- sivo per tutti i servizi ICT, si articola in due sezioni principali:
• processi primari, comprendente i processi di Acquisizione e di Fornitura, che trattano quanto concerne l’assegnazione della singola fornitura (argomento affrontato nei
manuali 2 e 3) ed il suo particolare espletamento tramite le relazioni necessarie con i destinatari della fornitura stessa, ed i processi più specificatamente operativi, che descrivono le modalità di Sviluppo, Gestione operativa e Manutenzione;
• processi trasversali, che riuniscono i processi indicati come di supporto ed organizza- tivi nella norma originaria, includendo quindi il processo di Documentazione e quel- lo di Gestione della Configurazione come tali e raccogliendo in un’unica classe, detta Gestione, tutti i processi organizzativi (riguardanti i presupposti e l’organizzazione delle modalità di svolgimento delle attività, indipendentemente dalla tipologia speci- fica) e in un’altra, detta Assicurazione Qualità, tutte le attività relative alle garanzie a priori e le verifiche a posteriori sulle caratteristiche qualitative dei risultati delle attivi- tà e l’eventuale necessità di rettifiche alle stesse per migliorarne il risultato.
L’applicazione di tale modello all’esplicitazione delle possibili esigenze della Pubblica Amministrazione parte dalla constatazione di una differenza sostanziale fra le due sezioni suddette:
• i processi primari sono modelli di organizzazione delle attività legati alle caratteristi- che specifiche degli oggetti di fornitura e quindi sono applicati differentemente secon- do la tipologia in questione: ogni fornitura ha caratteristiche che incidono sul modo di produrre, gestire e mantenere la stessa e conseguente diversa descrizione e sequenza delle attività coinvolte. Nel Dizionario ciò ha comportato la ricerca di una descrizione differenziata per ogni singola Classe di fornitura, perché la stessa potesse essere di reale ausilio nella scrittura dei documenti di gara;
• i processi trasversali costituiscono invece modelli di attività di controllo e supporto fondamentalmente simili per tutte le forniture e che, dovendo quindi affiancarle per assicurarne l’efficacia e la correttezza, si troverebbero ad essere documentati in modo replicato nella descrizione di ogni singola fornitura. Onde evitare un’inutile ridondan- za nel Dizionario si è pertanto seguita la strada di descrivere tali processi separatamen- te, come singole Classi di fornitura, chiarendo che gli stessi devono essere fruibili per il supporto a tutte le classi primarie.
17
La descrizione “economica” adottata nel Dizionario corrisponde all’analoga indicazione di buon senso da adottare nella redazione dei Capitolati: è evidente che l’assemblaggio in un’u- nica cornice contrattuale di più Classi di fornitura consiglia che i processi di supporto ed orga- nizzativi vengano ad essere condivisi tra tutte le Classi di fornitura utilizzate per garantire sem- plicità e coerenza all’impianto contrattuale. In altre parole è conveniente che i processi di sup- porto ed organizzativi siano esattamente i medesimi per tutte le Classi di fornitura; ciò signifi- ca che, nei Capitolati come nel Dizionario, le Classi di fornitura utilizzate si differenziano una dall’altra solo nella descrizione delle loro attività precipue mentre tutte quelle che si svolgono in modo più o meno simile in tutti i casi (documentazione, project management, ecc.) sono raccolte a fattor comune e definite una sola volta rispetto a tutte le attività incluse nel Capitolato. Evidentemente una qualsiasi fornitura (insieme di attività) è soggetta ad essere gestita e produce documentazione. Altrettanto evidentemente in un contratto vorremmo attua- ta una pianificazione integrata delle attività relative alle diverse Classi di fornitura che produca un’unica pianificazione dei lavori (piano di progetto), un unico rapporto di stato avanzamen-
to lavori (SAL) ed una gestione della documentazione omogenea. Questo significa che la Gestione e la Documentazione di più Classi di fornitura sarà attuata effettuando le stesse atti- vità descritte in un processo trasversale alle Classi stesse.
L’impianto più sopra descritto avrebbe dovuto comportare una proiezione del modello teo- rico tale da ripartire ogni argomento di fornitura nei confronti dei tre processi produttivi primari in cui si articola una fornitura: Sviluppo, Gestione operativa e Manutenzione. La ripartizione in questione è però indispensabile solo in casi in cui la complessità dell’argo- mento e quindi la sua dominabilità, come anche le modalità di erogazione, necessitano trat- tamenti distinti, come ad esempio nel caso dello sviluppo, gestione e manutenzione del software oppure dello sviluppo, gestione e manutenzione di sistemi. In altri casi, in cui il flusso delle attività, la loro interconnessione e i loro obiettivi non hanno caratteristiche del genere ma anzi costituiscono a volte un ‘continuum’ in cui una separazione in fasi erogabi- li in modo nettamente distinto risulterebbe una forzatura, si è preferito mantenere accorpa- te due o più delle stesse. Si pensi al caso della produzione di corsi di formazione piuttosto che alla gestione della sicurezza fisica o all’erogazione di attività di consulenza.
Pertanto, in modo diversificato all’interno del Dizionario, a volte si è scelto di accorpare le fasi fortemente integrate o che difficilmente possono essere oggetto di forniture separate, altre volte si è preferito trattare come Classi di fornitura separate uno o più dei processi di Sviluppo, Gestione operativa e Manutenzione.
In generale, anche al di là della strutturazione secondo i processi primari, la scelta di sud- divisione dei possibili argomenti oggetto di fornitura è stata dettata da ragioni di praticità, accorpando argomenti strettamente abbinati da caratteristiche operative (ad esempio il trat- tamento documentale e quello di acquisizione dati) e invece lasciando separate quelle for- niture complesse che, per semplicità, si è voluto trattate in modo indipendente (ad esem- pio distinguendo lo stesso tema della sicurezza in sicurezza logica e sicurezza fisica).
Il tutto sempre in un’ottica di estrema pragmaticità, mirando a costruire un documento che fosse fonte di un servizio utilizzabile nel più ampio modo possibile.
Utilizzo integrato delle Classi di fornitura
Ricapitolando, il Dizionario è costituito da una serie di Classi di fornitura non ulteriormen- te riducibile: la caratterizzazione delle necessità può essere effettuata a partire da tali clas- si, costituenti i mattoni elementari con i quali a ritroso comporre i contratti ICT. L’articolazione in Classi di fornitura ha lo scopo di facilitare l’utilizzo delle Linee guida e non presume che nei contratti ogni Classe di fornitura descritta nell’elenco che compone i lemmi del Dizionario debba essere acquisita in modo separato.
La redazione complessiva di un Capitolato necessita piuttosto di comporre più istanze di tali classi insieme per soddisfare l’esigenza reale complessiva di cui necessita la Pubblica Amministrazione. Dunque, sarà possibile ritrovare sovrapposizioni e correlazioni tra classi all’interno del Dizionario, di cui si deve tenere conto nella stesura di contratti e Capitolati tecnici, qualora, ed è il caso più frequente, essi comprendano più Classi di fornitura.
18
Quanto detto non riduce, infatti, i rapporti tra Classi di fornitura a pure somme e sottrazio- ni di elementi in quanto sussistono più delicati equilibri da considerare tra le stesse, soprat- tutto in relazione all’assicurazione dell’efficacia della fornitura ed al controllo su di essa:
• Vi sono Classi di fornitura che, sebbene descritte distintamente, perché può essere opportuna o necessaria l’acquisizione di una sola delle stesse in particolari condizio-
ni dello specifico contesto amministrativo, nel caso debbano essere acquisite entram- be è opportuno che siano affidate ad uno stesso fornitore; ciò perchè sia trattato con- gruentemente l’argomento che ha aspetti fortemente correlati tra le due forniture se non addirittura interdipendenti e non vi sia un rischio di forte perdita d’efficienza nel- l’interfacciamento tra due enti fornitori differenti.
Ad esempio, la decisione di acquisire simultaneamente servizi di Gestione e di Manutenzione dei Sistemi, seppure trattati come diverse e specifiche Classi di fornitu- ra, comporta abbastanza ovviamente il loro affidamento ad un unico fornitore data la condivisione degli oggetti da trattare, la necessità di scambio dettagliato di informa- zioni fra le due attività, il possibile rischio di ritardo negli interventi in caso d’interfac- ciamento fra diverse organizzazioni.
Analoga, anche se meno pressante, è l’utilità di assegnare le attività di Assistenza all’u- tente e Formazione riguardo l’introduzione di un nuovo sistema d’automazione ammi- nistrativa allo stesso fornitore che ne ha curato lo sviluppo e introduzione.
• Vi sono Classi di fornitura che, non solo sono descritte distintamente ma è assoluta- mente opportuno che siano affidate a diversi fornitori perché sia assicurata da rappor- ti di indipendenza o di controllo, la garanzia di esito delle attività in modo conforme alle attese dell’Amministrazione.
È questo il caso, ad esempio, di servizi rivolti alla Misura della Customer Satisfaction che non possono essere commissionati allo stesso fornitore cui sono appaltati altri ser- vizi fruiti in modo visibile dall’utenza, quali la Posta Elettronica o l’Assistenza in remo- to e locale. Analogamente non è possibile affidare la Direzione Lavori ad un fornito- re cui sono assegnati alcuni dei lavori soggetti a monitoraggio (Gestione Sistemi ad esempio), per un ovvio conflitto d’interessi dello stesso.
• Vi sono inoltre Classi di fornitura che, salvo adozione di apposite misure o predisposizio- ni interne all’Amministrazione, conviene sempre richiedere per mantenere un adeguato controllo dell’esecuzione del contratto in questione. Si tratta ad esempio del “Controllo dei livelli di servizio”, con il quale una Amministrazione può avere gli elementi per veri- ficare in itinere le prestazioni erogate dal fornitore rispetto agli obiettivi contrattuali.
3.2 Interazioni tra Classi di fornitura e processi
La distinzione tra Classi di fornitura “operative”, correlate ai processi primari e processi trasversali, relative ai processi di supporto e organizzativi, in relazione alla classificazio- ne invalsa dall’uso dello standard ISO 12207, non deve assolutamente ingannare su un’i- potetica opzionalità di questi ultimi: gran parte dei processi di supporto sono connatu- rati e indispensabili ad un corretto svolgimento delle attività di fornitura e pertanto imprescindibili.
Conseguentemente, i corrispondenti processi trasversali dovranno essere sempre conside- rati e inclusi con le dovute correlazioni alle Classi di fornitura presenti.
Non è infatti possibile supporre espletamento di forniture per le quali non ci sia:
19
• gestione (cioè Project Management della fornitura);
• documentazione (quella relativa alla gestione della fornitura quanto quella stretta- mente oggetto di fornitura, a volte coincidente con il prodotto ultimo della stessa,
come può essere ad esempio nel caso di erogazione di consulenza per la redazione di uno studio di fattibilità);
• gestione della Configurazione (dal minimum del tener conto delle versioni di un sin- golo documento alla gestione della configurazione HW e SW di un intero sistema informatico allocato in full outsourcing);
• assicurazione Qualità (con il relativo corpo di attività di verifica di vario livello che il fornitore deve svolgere per garantire la coerenza e correttezza della fornitura predi- sposta).
L’inclusione dei processi trasversali, come meglio descritto nel successivo paragrafo 4.4, deve comunque avvenire una volta sola per tutte le classi eventualmente rapportandosi ad esse con diverso livello delle modalità esecutive e delle garanzie di qualità richieste in fun- zione della tipologia di Classe di fornitura e della sua specifica istanza.
20
4. Guida alla definizione della fornitura nel Capitolato tecnico
Nel Manuale applicativo – Strategie di acquisizione delle forniture ICT – si fornisce una descrizione delle principali categorie negoziali relative alle acquisizioni di forniture ICT e dei documenti che complessivamente concorrono alla definizione di un contratto ICT. Il documento da cui dipendono principalmente le modalità di realizzazione della forni- tura, è il Capitolato tecnico, documento nel quale l’Amministrazione definisce i requisi- ti minimi della fornitura ed in base al quale le imprese concorrenti predispongono l’of- ferta tecnica.
Le modalità di definizione della fornitura nel Capitolato tecnico sono significativamente influenzate dalla tipologia e composizione della fornitura. Al riguardo si rileva che per l’acquisizione di prodotti software o di apparecchiature hardware è necessario un livel- lo di dettaglio elevato nella specificazione delle caratteristiche tecniche, livello che si riduce progressivamente per le acquisizioni di prestazioni di servizi ICT, sino a diventa- re generico in caso di outsourcing selettivo o globale dei servizi stessi, in cui l’Amministrazione è sostanzialmente interessata al risultato e delega al Fornitore la scel- ta delle modalità tecniche di realizzazione ed erogazione dei servizi.
Per contro, mentre nell’acquisizione di prodotti software o di apparecchiature hardware possono esistere delle forme di tutela per l’acquirente, che derivano dalla conformità a requisiti obbligatori e/o volontari (conformità a normative europee e/o strumenti standard di misurazione delle prestazioni), dichiarata ed assicurata dal Fornitore, per i servizi ICT, ivi incluso lo sviluppo di software ad hoc, è necessario specificare livelli di qualità di attività e prodotti, intermedi e finali, propri dei processi attuati per la realizzazione e l’erogazione dei servizi; tale specificazione può essere fatta ad un livello di dettaglio variabile, a seconda delle esigenze dell’Amministrazione, della complessità dei servizi e del contesto in cui si inseriscono (v. par. 4.3).
Nella maggioranza dei casi, i contratti ICT comprendono una pluralità di Classi di fornitura al loro interno, più o meno correlate fra loro che richiedono un’opera di assemblaggio più che di elencazione. Il Dizionario rappresenta, invece, un ventaglio di molteplici possibilità, le Classi di fornitura, isolate singolarmente non perché si suppongano necessariamente separate le possibilità di erogazione delle stesse ma per evidenziare più chiaramente la spe- cificità e diversità della singola Classe di fornitura interessata. L’esportazione dei contenuti del Dizionario verso i Capitolati dovrà quindi necessariamente passare per un’attenta opera di ricomposizione e correlazione di tutti gli elementi utili nel quadro del contesto tecnico- amministrativo in cui si opera l’acquisizione.
21
Dunque l’utilizzo di tale ausilio non può eliminare la complessa attività di scrittura di contratti e Capitolati tecnici: a tale scopo nel presente paragrafo ed in quanto segue s’in- tende sottolineare quali siano le linee guida con cui utilizzare congruentemente il sup-
porto fornito dalle descrizioni contenute nei lemmi suddetti, la particolare attenzione da prestare alle imprescindibili e necessarie attività di specificazione e taratura delle Classi di fornitura ICT elementari utilizzate e alla loro integrazione in un unico e coerente con- tratto ICT.
La composizione complessiva dei documenti di gara richiede dunque una serie di passi che devono essere collegati coerentemente a comporre un insieme organico e stabile. Tale opera può configurarsi organizzata secondo lo schema complessivo composto dai seguenti passi:
1. Individuazione delle esigenze da assolvere e definizione delle modalità generali d’ap- palto (tipologia di gara, estensione, esclusioni, caratterizzazione delle società parteci- panti, certificazioni di qualità ecc.).
2. Definizione dell’oggetto contrattuale ripartito nelle principali categorie di prodotti e servizi da richiedere, secondo la corrispondenza con l’assolvimento delle esigen- ze dell’Amministrazione. Ciò può dar luogo a raggruppamenti distinti di forniture con caratteristiche differenti e autonome da appaltare a distinti fornitori oppure molteplici lotti della stessa fornitura da appaltare ad uno o più fornitori (v. quanto detto in 3.1 al proposito).
3. Per ogni raggruppamento componente una fornitura, individuazione nel Dizionario delle Classi di fornitura che possono descriverne gli aspetti elementari. Per ogni esigenza relativa ad una Classe di fornitura specificazione delle caratteri- stiche distintive della stessa rispetto alle altre esigenze analoghe (processo di istan- ziazione).
4. Per ogni Classe di fornitura selezionata, derivazione dalla stessa delle attività, prodot- ti e requisiti di qualità che possono essere d’interesse per tutte o per una specifica istanza inclusa nella fornitura in questione (v. al proposito oltre, par. 4.2 e 4.3).
5. Individuazione delle relazioni da gestire tra le forniture individuate e che possono dar luogo ad attività aggiuntive di controllo e fasatura, vincoli sulle attività incluse, defini- zione di requisiti specifici per l’esecuzione.
6. Definizione delle attività relative ai processi trasversali in modo generale e integrato per tutte le forniture individuate (v. par. 4.4).
22
Ognuno dei paragrafi seguenti affronterà pertanto parte dei passi su esposti, a partire dal momento in cui la struttura deputata dell’Amministrazione, dopo aver chiarito le esigen- ze specifiche, il contesto in cui si inseriscono e la loro assolvibilità tramite la gara, ha già deciso di procedere all’esecuzione della gara stessa e ne ha definito le modalità proce- durali. Si affronteranno quindi le metodiche e le specifiche attenzioni che devono esse- re apportate nell’effettuare il processo di selezione e composizione delle Classi di forni- tura, accompagnandole con alcuni esempi e considerazioni significativi. Gli scenari disponibili nei successivi capitoli del presente manuale consentiranno poi di visualizza- re, nei suoi caratteri principali, la messa in pratica di tali considerazioni. Per tale motivo all’inizio di ogni scenario sarà brevemente richiamato il contesto specifico di ogni acqui- sizione per comprendere come si possa essere sopravvenuti a determinate scelte piutto- sto che altre.
4.1 Come selezionare le Classi di fornitura e definire le istanze
Ricordiamo che all’interno del Dizionario delle Forniture ICT ogni lemma include:
• la descrizione della Classe di fornitura ICT elementare;
• l’esplicitazione di “regole” per l’uso della Classe di fornitura;
• la descrizione delle attività;
• una tabella che riassume attività, prodotti e indicatori di qualità;
• una scheda per ogni indicatore di qualità;
• un glossario (opzionalmente).
Tale materiale fornito all’interno di ogni lemma del dizionario affronta ogni singolo argo- mento proponendo due tipi di ausili nettamente differenti:
• Linee guida e specifiche indicazioni su come redigere i paragrafi del Capitolato, sug- gerendo un promemoria dei vari ingredienti che contribuiscono a comporre il quadro d’insieme della fornitura ma di cui solo lo scrivente, conoscitore delle specifiche esi- genze della stazione appaltante, può definire le esatte dosi e miscele per ottenere un risultato coerente con le aspettative dei fruitori della fornitura.
• Descrizioni di dettaglio, in particolare per quanto riguarda le caratteristiche dei singo- li elementi ed attività implicate nella fornitura e per gli indicatori utili a monitorare i risultati dell’introduzione delle stesse. Queste possono essere selezionate tutte o in parte ed utilizzate pressoché come sono (in senso prettamente operativo: modalità “copia e incolla”) per la redazione delle parti relative del Capitolato tecnico.
Il processo di selezione delle Classi di fornitura idonee ad essere incluse parte dunque, necessariamente, con un’attenta lettura dell’indice del Dizionario e l’identificazione dell’am- bito di attività ricercate fino al dettaglio delle Classi di fornitura ricomprese (ricordiamo al proposito che il Dizionario è organizzato secondo tre livelli, di cui solo al terzo è presente la descrizione di dettaglio delle classi, i precedenti costituiscono un albero di ricerca che favorisce l’individuazione delle attività d’interesse).
Individuati i titoli delle possibili Classi di fornitura d’interesse la lettura del primo paragra- fo delle stesse (“Identificazione della Classe di fornitura…”) permette di chiarire la delimi- tazione della classe suddetta e quindi verificare la prima corrispondenza con quanto cerca- to. Nel paragrafo successivo l’approfondimento delle “Modalità di definizione della fornitu- ra” consente poi di verificare in dettaglio la varietà della casistica relativa alla fornitura per identificarvi quella d’interesse e gli eventuali vincoli, suggerimenti e correlazioni che devo- no essere tenuti presenti nella stesura del Capitolato sull’argomento.
Nell’effettuare la mappatura tra le forniture che s’intende acquisire e le Classi di fornitura descritte nel dizionario è utile tener presente le seguenti indicazioni:
23
• se la casistica ricercata è chiaramente e completamente descritta in quanto reperito nelle Classi di fornitura individuate si è abbastanza facilitati nella prosecuzione della redazione del Capitolato ma non si devono trascurare a) le possibili correlazioni tra le attività di distinte Classi di fornitura (ad es. prodotti o controlli che transitano da una all’altra) e b) l’identificazione delle appropriate ma distinte attività comuni (processi trasversali) nell’applicazione di tali classi al caso reale;
• se la casistica ricercata è solo parzialmente prevista dalla Classe di fornitura individua- ta si possono dare più casi; si tratta di un mix di prodotti e servizi per i quali devono essere considerate altre Classi di fornitura e quindi si tratta di comporre più Classi di fornitura insieme, mantenendo distinte le attività ma esplicitando le dipendenze e cor- relazioni oppure si tratta di attività ad alto contenuto innovativo che non sono descrit- te come tali (in tal caso è necessario procedere ad una particolare attività di specifica- zione prendendo a modello la classe con maggiore similarità all’attività in questione);
• le attività indotte e descritte nel Dizionario come specifiche Classi di fornitura devono comunque essere considerate distintamente: ad esempio, la richiesta di automatizzazio- ne di una procedura amministrativa comporta necessariamente l’addestramento del per- sonale riguardo la stessa che deve essere prevista nel Capitolato. L’attività deve essere descritta in base all’appropriata Classe di fornitura (“Formazione e addestramento”) e non confusa con le attività proprie di sviluppo dell’automazione (“Sviluppo e MEV di softwa- re ad hoc” e “Sviluppo sistemi”), seppure richiesto di svolgerla allo stesso fornitore.
Individuata una prima selezione delle classi d’interesse le stesse devono essere mappate verso le esigenze espresse per valutare la copertura delle stesse ed eventualmente integrar- le. L’analisi delle classi consultate e la mappatura verso le esigenze dell’Amministrazione devono prescindere da attività di verifica delle modalità di fornitura (assicurazione qualità), dalle caratteristiche di gestione e documentazione della stessa e dalle modalità di gestione della configurazione, in quanto le stesse dovranno essere tutte trattate, seppure con moda- lità variegate, sotto la forma di processi trasversali.
A questo punto è opportuno procedere alla redazione del Capitolato in modo progressivo, costruendo dapprima la definizione degli specifici oggetti contrattuali, scomponendo quin- di ogni Classe di fornitura adottata nelle specifiche istanze che individuano la realizzazione richiesta per l’assolvimento dell’esigenza in questione e procedendo al raccordo, ove necessario, fra le attività correlate delle varie Classi di fornitura. Al risultato dovranno esse- re integrate le congruenti descrizioni dei relativi processi trasversali. Il concetto di istanza è sostanziale per una redazione efficace del Capitolato, in quanto il processo di istanziazio- ne consente la caratterizzazione degli attributi della fornitura rispetto alle specifiche esigen- ze espresse nell’acquisizione senza variare le peculiarità generali che identificano la Classe di fornitura ed il modo di assolverla. Trattandosi di una specificazione ulteriore ne conse- gue che in ogni Capitolato, per ogni Classe di fornitura potranno essere presenti una o più istanze relative ad attività di fornitura analoghe ma caratterizzate da attributi differenti. La differenziazione tra un’istanza ed un’altra potrà essere relativa ai seguenti diversi fattori:
• Dimensionali: ad es. numero di FP di un’applicazione, utenti di un servizio di posta o di un servizio di assistenza in remoto, numero di server gestiti, ampiezza banda tele- fonica, ecc.
• Territoriali: localizzazione del servizio svolto o sua distribuzione sul territorio (ad esempio, gestione di un sistema unico, centrale, rispetto alla gestione di una rete di apparati regionali).
24
• Qualitativi: esigenza di alta rispondenza o meno del servizio alle richieste dell’uten- za, sia in termini di qualità dei singoli prodotti erogati che di loro disponibilità in modo più o meno continuativo oppure secondo necessità (ad esempio, servizi appli- cativi di sportello piuttosto che assistenza in locale per strutture di back-office).
Tali fattori comportano una diversa applicazione delle stesse attività previste per la classe e adeguate alla tipologia di esigenza espressa ma dettagliate differentemente
• nelle modalità d’esecuzione (ad esempio, è possibile immaginare la definizione di un ciclo di vita diverso per lo sviluppo di una piccola applicazione prototipale a suppor- to di una proposta d’innovazione piuttosto che per la definizione di un sistema di con- trollo di gestione stabile);
• nei costi previsti (ad esempio, un servizio che richiede presenza distribuita sul territo- rio sarà ovviamente molto più costoso di un servizio accentrato, un servizio continua- tivo in turnazione più di uno a carattere saltuario);
• nei livelli di servizio richiesti (la qualità d’esecuzione ha una sua equivalenza e dipenden- za dai corrispettivi erogati e quindi dev’essere richiesta al livello adeguato alle necessità effettive delle specifiche attività, per non costituire un dispendio inutile di risorse).
Esempio
Un esempio più complesso può forse chiarire meglio il concetto. Immaginiamo un contrat- to ICT con il quale una Amministrazione, con 600 dipendenti, 100 al centro ed i restan- ti nelle 10 sedi sparse sul territorio nazionale, intenda acquisire tre distinte procedure software che andranno realizzate ad hoc: la procedura A, della dimensione stimata di 900 function point, che automatizza il front office supporta la missione istituzionale dell’Amministrazione permettendo a cittadini e imprese l’accesso on-line ai procedimen- ti amministrativi; la procedura B, di 200 function point, che automatizza il back office; la procedura C, di 400 function point, che sarà utilizzata per un tempo limitato solo da pochi dipendenti per elaborare uno studio demografico. Unitamente allo sviluppo di software applicativo l’Amministrazione intende rinnovare l’hardware di ognuna delle sue sedi territoriali, 10 server e 500 postazioni di lavoro, e rifare tutta la rete locale della sede centrale, una LAN di 100 nodi predisponendo anche le connessioni verso tutte le sedi periferiche. L’Amministrazione già gestisce operativamente i propri sistemi informa- tivi automatizzati ed anche la gestione delle nuove procedure sarà a suo carico. Però intende affidare allo stesso fornitore anche l’attività gestione di un call center che serve tutti i suoi dipendenti e che in media gestisce 300 chiamate giornaliere. Utilizzando le Classi di fornitura identificate nel Dizionario possiamo rappresentare l’oggetto contrattuale relativo ai bisogni dell’Amministrazione come segue:
Classi di fornitura | N° | Istanze | Caratteristiche istanza |
Sviluppo SW | 3 | procedura A | 900 Function Point, alta qualità |
procedura B | 200 Function Point, media qualità | ||
procedura C | 400 Function Point, bassa qualità | ||
Fornitura HW | 2 | dipartimentali | 10 Server |
postazioni di lavoro | 500 PC | ||
Sviluppo Reti | 2 | LAN sede centrale | 100 Nodi, banda stretta |
WAN periferie | 10 Nodi, banda larga | ||
Assistenza utente | 1 | call center nazionale | 300 chiamate/GG |
25
Come si vede le Classi di fornitura elementari sono solo 4, relative allo sviluppo di softwa- re, alla fornitura di hardware, allo sviluppo di reti ed all’assistenza per gli utenti. Le Classi
di fornitura raggruppano un insieme di servizi ICT, istanze di fornitura, che presentano caratteristiche omogenee per finalità e per modalità di sviluppo, gestione operativa, manu- tenzione. Le istanze di fornitura sono complessivamente 8. Tutte e tre le procedure afferi- scono alla classe di sviluppo software, ma poiché le loro caratteristiche si differenziano in termini sia quantitativi che qualitativi è necessario trattarle contrattualmente ereditando dalla Classe di fornitura sviluppo software l’impianto contrattuale generale, ma specifican- do logiche di costo e di qualità diverse caso per caso. Solo la Classe di fornitura assistenza all’utente ha una sola istanza. La scrittura del contratto può partire dalle 4 Classi di fornitu- ra che devono essere “coniugate” a formare le 8 istanze di fornitura, ognuna delle quali deve trovare corrispondenza in un proprio accordo sui livelli di servizio (service level agreement). Il contratto è la cornice che definisce le regole generali all’interno delle quali collocare le attese relative alle singole istanze di fornitura.
Riepilogando, per ogni Classe di fornitura selezionata dal Dizionario deve essere inse- xxxx un’opportuna e distinta descrizione generale nel Capitolato che, prendendo spun- to da quanto indicato nella descrizione della classe nel Dizionario, vada a coprire tutti e solo gli aspetti di rappresentazione della tipologia di attività che si richiede di svolge- re nell’ambito della specifica acquisizione. A questa descrizione devono essere aggan- ciati gli specifici vincoli relativi al contesto in cui si svolge l’erogazione della fornitura e devono essere considerate le possibili interazioni tra le Classi di fornitura utilizzate nel Capitolato e, nel caso di più acquisizioni parallele, le possibili interazioni tra que- ste e quelle incluse in altri Capitolati (si tratta sempre, in sostanza, di valutare quali siano gli oggetti, i servizi, le conoscenze condivise o che devono transitare da una for- nitura ad un’altra).
Infine, per ogni Classe di fornitura descritta, devono essere differenziate le singole istanze richieste, specificandone dimensioni, qualità desiderata, distribuzione e gli altri eventuali attributi influenti sui mezzi (e quindi sul costo) per l’organizzazione dell’attività relativa e sulle attese in merito alla stessa dell’utenza coinvolta.
4.2 Come individuare attività e prodotti
L’aver selezionato delle Classi di fornitura, sulla base di quelle proposte nel Dizionario delle Forniture ICT, non implica che per ciascuna classe debbano essere ugualmente considera- ti, ai fini delle misure di qualità, tutti i processi, con le attività ed i prodotti indicati. L’identificazione delle attività e dei prodotti da prendere in considerazione per ciascuna Classe di fornitura selezionata è funzione sia delle caratteristiche della classe stessa, sia delle esigenze dell’Amministrazione, ivi inclusi dimensioni, criticità e rischi. Preferibilmente sarebbe utile redigere prima le attività applicabili in comune alle varie istanze e poi limitar- si, per semplicità, alla sola esplicitazione delle differenziazioni in relazione alle varie istan- ze che compongono la fornitura per esecuzione, dimensioni e qualità.
26
In sostanza, nel definire le singole attività da richiedere, non è assolutamente necessario includere tutte le attività descritte nella Classe di fornitura indicata ma solo quelle stretta- mente aderenti alle istanze incluse nella stesura dello specifico Capitolato, integrandole con i dettagli e i vincoli propri dello specifico contesto d’applicazione.
Le principali considerazioni da farsi sulla caratterizzazione di ogni istanza di fornitura riguardano l’integrazione delle attività incluse nella fornitura con le informazioni opportu- ne, secondo il caso, concernenti:
• politiche aziendali specifiche riguardanti l’oggetto di fornitura e che possono concer- nere argomenti più generali, quali la gestione della sicurezza, della riservatezza, del rischio, della proprietà dei prodotti di cui il fornitore deve essere messo al corrente e in condizione di poter adempiere alle stesse (ad esempio fornendogli documentazio- ne o abilitandolo all’uso di determinati strumenti e procedure);
• normative che devono essere adempiute nell’esecuzione delle attività, sia che si tratti di norme cogenti, nazionali o internazionali, che normativa tecnica di settore che l’Amministrazione ha inteso adottare;
• standard specifici, di programmazione, redazione documenti, formalizzazione azioni ecc. Il fornitore dev’essere informato chiaramente dal Capitolato riguardo gli standard che è tenuto ad osservare o che gli è richiesto di produrre nell’ambito dell’attività;
• modelli di cicli di vita (dove applicabili: software, documentazione, asset ecc.) previ- sti o utilizzabili (se opzionali) coerentemente connessi agli eventuali maggiori dettagli delle attività incluse ed ai loro prodotti;
• l’estensione dell’allocazione dell’attività: se l’attività è totalmente devoluta all’appaltante o se vi sono aspetti che s’intende mantenere sotto il controllo dell’Amministrazione. In tal caso tali aspetti devono essere esplicitati chiaramente. Ad esempio: è richiesto ad un for- nitore di assumere la gestione della rete, vincolando all’utilizzo di determinati strumenti software di monitoraggio della rete preesistenti di cui l’Amministrazione appaltante man- tiene il possesso e le prerogative riguardo alle decisioni sulla distribuzione delle licenze e l’aggiornamento del software relativo. La situazione va esplicitata come tale perché potrebbe costituire vincolo e rischio per l’efficacia di esecuzione del fornitore in determi- nate condizioni. Altro caso d’interesse è quello in cui per un contratto di System Integration è richiesto di fornire una soluzione completa (HW e SW) ma l’HW è in parte già patrimonio dell’Amministrazione: dev’essere definito con chiarezza se al Fornitore è richiesto di operare direttamente anche sull’hardware dell’Amministrazione o solo assi- stere all’esecuzione delle operazioni necessarie e dallo stesso indicate.
• le correlazioni di cui tener conto fra le varie Classi di fornitura per quanto riguarda, ad esempio, oggetti o informazioni condivise (ad esempio, i sistemi coinvolti sia nella Gestione Sistemi che nella Gestione Reti); oggetti o informazioni che devono transita- re da una classe ad un’altra (ad esempio, le modalità di consegna dell’esito di svilup- pi SW alla Gestione applicazioni); tali correlazioni hanno ancor più importanza nel caso si tratti di bandi distinti d’acquisizione (fornitori diversi).
Diverse delle raccomandazioni suddette possono già ritrovarsi come indicazioni conte- nute nelle singole Classi di fornitura presenti nel Dizionario, compresi i rapporti con altre Classi di fornitura. Nel redigere il Capitolato, a fianco di queste raccomandazioni, si devono sempre includere nelle descrizioni:
28
• gli oggetti e le informazioni che l’Amministrazione deve fornire per l’espletamento delle attività (ad esempio, nel caso della presa in carico della Gestione applicativa
deve essere fornito fondamentalmente il flusso di esecuzione delle procedure appli- cative mentre per la presa in carico della Manutenzione applicativa deve essere reso disponibile anche il codice sorgente, meglio se tramite la consegna di un inventario formale degli oggetti, e nel Capitolato deve esserne indicato il dimensionamento approssimativo);
• le richieste di affiancamento (iniziale, per presa in carico e finale, per passaggio di consegne) nel caso di attività in cui sia significativo il trasferimento di conoscenze acquisite sul campo tra fornitori dello stesso servizio (ad es. gestione sistemi o gestio- ne applicativa);
• la definizione della proprietà degli oggetti prodotti dal Fornitore durante l’esecuzione dei servizi contrattuali (software, documentazione, ecc.), sia per i semilavorati che per i rilasci;
• la richiesta di indipendenza dei prodotti consegnati dall’ambiente di sviluppo del for- nitore e quindi la possibilità di rileggere o utilizzare software, dati, hardware o docu- mentazione negli ambienti di proprietà dell’Amministrazione.
In ultimo, devono attentamente essere considerate le specificazioni delle attività relative ai processi trasversali, i quali avranno rilievo diverso in dipendenza della Classe di fornitura e, se il caso anche dell’istanza, cui danno supporto e che in relazione ad essa possono anche avere diverse modalità di svolgimento. Ad esempio, prendendo in considerazione le due Classi di fornitura “Sviluppo e MEV di software ad hoc” e “Trattamento documentale e acquisizione dati” calcoleremo lo stato avanzamento lavori per entrambe le classi, quindi effettueremo la stessa attività prevista dal processo di Gestione, ma in modi differenti: misu- rando la quantità di punti funzione del software collaudato per la prima Classe di fornitura e contando i caratteri alfanumerici acquisiti per la seconda.
Riepilogando, una volta definite le Classi di fornitura primarie coinvolte con le loro interre- lazioni e le istanze specifiche da assolvere, devono essere dettagliate le singole attività di cui le stesse si compongono, estraendole, per quanto possibile, dal contenuto delle Classi di fornitura utilizzate del dizionario e ampliandole ulteriormente con l’introduzione dei vin- coli, standard e altre personalizzazioni legate allo specifico modo richiesto per assolvere l’attività nel contesto in questione. Nel fare ciò vanno attentamente considerate tutte quel- le attività la cui responsabilità totale o parziale rimane appalto dell’Amministrazione e di cui devono essere chiaramente esplicitati i contorni.
Per ogni attività, con l’ausilio di tabelle analoghe a quelle che sono utilizzate nelle Classi di fornitura, devono essere specificati i prodotti attesi, indicando chiaramente quelli che sono da considerarsi deliverables contrattuali e rinviando gli altri ad un elencazione più tecnica inclusa nel Piano di Progetto specifico.
4.3 Come selezionare indicatori di qualità e definire valori soglia
28
Una volta individuati attività e prodotti, si selezionano tra quelli proposti nel Dizionario, rispettivamente per le attività e per i prodotti, gli indicatori di qualità che si ritengono mag- giormente significativi in funzione della tipologia di ciascuna Classe di fornitura e degli obiettivi di qualità attesa sul risultato finale.
È opportuno orientare la scelta degli indicatori in modo che sia efficace e non ridondante: gli indicatori selezionati devono consentire con uno sforzo sostenibile di effettuare il con- trollo delle prestazioni del fornitore e dei deliverables contrattuali, al fine di garantirne una qualità coerente con il livello atteso dall’Amministrazione.
La selezione degli specifici indicatori, tra quelli proposti all’interno delle singole Classi di fornitura del Dizionario (od eventuali altre proposte aggiuntive) deve assoggettarsi a crite- ri generali, quali:
• congruità col valore economico del contratto dell’estensione e specificità del set di indicatori scelto. Ha senso un impegno notevole in questo senso nei contratti di grande rilievo (ad esempio da 50 milioni di euro in su) mentre può essere più limi- tata la richiesta e le corrispettive attività di controllo che la stessa comporta nel caso di contratti di dimensione economica di moderata entità, specie se correlata a minori pretese in campo qualitativo;
• limitazione nel numero complessivo degli indicatori perché l’insieme sia dominabile;
• copertura coerente degli indicatori rispetto ai requisiti di qualità pregnanti per la fornitura, ovvero al livello effettivamente atteso dall’utenza della stessa (richie- dere ovunque la massima qualità possibile può costituire un inutile spreco di risorse);
• definizione quantitativa con formule inequivocabili e precisazione di chiare soglie di riferimento, preferibilmente orientando in un unico verso l’interpretazione delle formule (in modo che il superamento della soglia sia sempre interpretabile in senso negativo oppure, viceversa, lo sia il suo non raggiungimento).
Deve poi essere anch’essa dettagliata rispetto alle caratteristiche della Classe di fornitu- ra in questione, della specifica istanza e dell’aspetto affrontato dall’indicatore rispetto all’istanza. Come si è già detto, non è affatto scontato che le diverse istanze di una stes- sa Classe di fornitura abbiano identici attributi o richiedano la stessa qualità di trattamen- to anzi più facilmente si differenzieranno in ciò. Ad esempio, la tipologia di linguaggi e metodi utilizzati per attività di sviluppo o manutenzione software può influenzare diver- samente le caratteristiche manutentive o di riusabilità del software, il valore di picco pre- visto per il numero di utenti clienti di un’applicazione su base web influenza fortemen- te le scelte anche architetturali del sistema applicativo utilizzato. La tipologia del servi- zio applicativo (sportello, online, back-office ecc.) ha un diverso riflesso nella disponi- bilità dei sistemi che li devono supportare. La preesistenza o meno di standard docu- mentali può differenziare fortemente i risultati di servizi di gestione documentale. La stessa composizione del parco utenti può comportare diversi livelli d’attenzione in rela- zione alle necessità ed alle attese delle diverse tipologie di utenti.
Detto in modo più strutturato, gli obiettivi di qualità scelti per ogni istanza della fornitura, e quindi i corrispondenti indicatori da misurare, dovrebbero tener conto sempre della cor- relazione ai seguenti aspetti:
29
• frequenza di utilizzo del prodotto/servizio: cambia molto ovviamente se si tratta di un servizio saltuario di consulenza o reportistica piuttosto che un utilizzo con periodicità regolare o un servizio assiduo quale un’applicazione di sportello o una rete aziendale;
• estensione tipologica e geografica coinvolta: avere indicazioni sul funzionamento di un call center a valenza nazionale può essere molto differente da un servizio di help desk disponibile presso una sede locale ma anche il richiedere la fornitura di 50 work- station o di 2000 coinvolge modalità industriali di esecuzione completamente diverse e conseguenti diversi parametri di controllo;
• gestibilità, cioè quanto la fornitura deve essere autoconsistente e dimostrare la non necessità di correttivi in opera, garantendo sia la qualità attuale che la preservazione della qualità futura (dove applicabile tale concetto, ad esempio per i patrimoni soft- ware, per le reti e i sistemi).
Nelle Classi di fornitura presenti nel Dizionario si trova già un’ampia scelta di indicatori utilizzabili e altri possono essere progettati dall’Amministrazione, in base alle specifiche necessità (si raccomanda di farlo utilizzando un analogo schema di composizione degli stessi per assicurarsi di non dimenticare alcun aspetto nella loro definizione). In entram- bi i casi la descrizione proposta dell’indicatore si ferma in genere alla soglia in cui lo stesso deve essere opportunamente ritagliato rispetto alle istanze della fornitura da ero- gare, alla sua criticità, al livello di qualità atteso ecc.. Ciò si riflette sostanzialmente nella definizione dei valori di soglia da applicarsi a tali indicatori per ogni sezione di fornitu- ra in cui sono utilizzati.
Riepilogando: completata la definizione del “cosa e come” deve essere fornito, tramite classi, attività e prodotti, è necessario individuare gli elementi per la caratterizzazione oggettiva dei parametri critici della fornitura che ne consentano il controllo. Ciò deve esser fatto quanto più possibile in modo strutturato, procedendo a scegliere opportuni indicatori per ognuna delle Classi di fornitura da includere, tra quelli proposti nel Dizionario o progettandoli analogamente, e per ognuno di essi devono essere individua- te le istanze di fornitura cui devono essere applicati e i relativi valori di soglia, differen- ziandoli in base al livello di servizio o di qualità del prodotto attesa in modo congruo per la specifica sezione della fornitura.
Al fine di chiarire ancor meglio il concetto mostriamo un esempio di composizione di una tabella di indicatori.
Il caso, per dirla sommariamente, è quello di un outsourcing triennale della gestione e manutenzione dei sistemi informativi di un’Amministrazione che dispone di un sito cen- trale di riferimento, in cui è localizzato l’archivio centrale dei dati amministrati, e di pro- pri server distribuiti in periferia di supporto alle attività transazionali nelle sedi regiona- li che interrogano e aggiornano l’archivio centrale. Sono inoltre connessi 24h/24 server di altre Amministrazioni che possono necessitare di informazioni occasionalmente (enti di polizia ecc.)
6.2.1 | PGE | Gestione |
6.1.1 | PGD | Documentazione |
3.2.2 | GSI | Gestione sistemi |
3.2.3 | MSI | Manutenzione sistemi |
6.1.2 | PGC | Gestione della Configurazione |
6.1.3 | PAQ | Assicurazione Qualità |
Nel Capitolato saranno utilizzati contenuti estratti, seppure opportunamente adattati ed estesi, almeno dalle seguenti Classi di fornitura e processi trasversali coinvolti:
30
La fornitura si compone, sostanzialmente (si riportano solo alcuni dati d’interesse ai fini del- l’esempio), delle seguenti istanze, distinte dall’oggetto dell’attività e dal livello di servizio richiesto per lo stesso:
• la gestione completa (presa in carico, conduzione operativa e monitoraggio, schedu- lazione, malfunzioni, storage, ecc.) del sistema centrale con turnazione completa sulle 24h degli operatori addetti;
• la gestione completa dei sistemi periferici negli orari legati all’esecuzione delle attivi- tà amministrative e delle procedure locali (8-16);
• la manutenzione del sistema centrale, sia preventiva che correttiva;
• la manutenzione dei sistemi periferici, sia preventiva che correttiva;
• la gestione della configurazione di tutti gli apparati coinvolti HW e SW (inventario di det- taglio delle componenti, di cui dev’essere assicurato l’aggiornamento a fronte degli inter- venti di manutenzione che richiedono sostituzione o integrazione di parti del sistema).
La copertura richiesta per il servizio è di 24h/365gg l’anno per il sistema centrale ma con diversa valenza individuata per il livello di servizio dello stesso: alta disponibilità del sistema nella fascia 8-16 dal lunedì al venerdì (orario amministrativo) e più bassa in altri orari. La copertura del servizio per i sistemi periferici è limitata alle 8h dal lunedì al venerdì, dalle 8 alle 16, con minore criticità delle esigenze di servizio. Ciò vale a dire che gli indicatori scelti dovranno essere differenziati innanzitutto estraendo dalle Classi di fornitura suddette quegli indicatori che possano tenere sotto controllo le attività della classe incluse nella fornitura rispetto ai parametri essenziali. In questo caso, ad esempio, la disponibilità dei sistemi. Quindi, che l’indicatore deve essere confrontato con valori di soglia diversi e opportuni in relazione alla specifica istanza cui è applicato (sistema cen- trale vs. sistemi periferici) ed alla relativa classe di criticità applicabile, la quale può anche variare rispetto ad attributi specifici della stessa istanza (ad es. l’orario di utilizzo, come nell’esempio in questione).
Dei possibili indicatori considerabili in tale situazione e descritti nelle Classi di fornitura sud- dette (si rimanda alle stesse per i dettagli tecnici sull’utilizzo degli indicatori considerati), con- sideriamo solo quelli riportati sinteticamente e in forma semplificata nella tabella della pagina seguente, che focalizzano l’attenzione sul controllo dell’operatività del servizio richiesto.
Fermo restando l’utilizzo degli stessi indicatori come definizione e algoritmo, la loro valu- tazione, quanto a modalità di calcolo, soglia di confronto e ambito d’applicazione cambia quindi in dipendenza delle caratteristiche delle specifiche istanze della fornitura.
31
La tabella riassuntiva degli indicatori da introdurre nel Capitolato può essere esplicitata per chiarezza, per ogni Classe di fornitura indicata comprendendo tutte le sue istanze, fatte salve le caratteristiche distintive delle stesse, ad esempio per classe di criticità. Ad ognuna di tali tabelle devono essere fatte seguire le tabelle di dettaglio di esplicitazione delle moda- lità di calcolo dei singoli indicatori, eventualmente tramite la semplice copia delle tabelle relative già utilizzate all’interno del Dizionario, previa personalizzazione delle parti signifi- cativamente differenti (percentuali applicate, azioni contrattuali ecc.). Per quanto riguarda gli indicatori relativi ai processi trasversali, quali il CRAC nella tabella precedente, è oppor- tuno che siano specificati in tutte le tabelle di riepilogo per Classe di fornitura del Capitolato cui vengono opportunamente associati ma le tabelle di dettaglio che ne descrivono le
modalità di valutazione dovrebbero essere allegate solo ai paragrafi di descrizione specifi- ca delle attività connesse per i processi trasversali, quindi in un unico punto del Capitolato, evitando inutili ridondanze.
Codice | Indicatore | Descrizione | Valore di soglia per servizi ad alta disponibilità (servizi erogati tramite il siste- ma centrale nell’orario 8-16 dal lunedì al venerdì) | Valore di soglia per servizi a disponibilità normale (servizi erogati tramite il siste- ma centrale dalle h16 alle 8 e servizi erogati tramite i sistemi periferici nell’orario 8-16 dal lunedì al venerdì) |
DIS1 | Disponibilità del sistema automa- tico in linea | Misurazione della dura- ta temporale di tutti i fermi non programmati rispetto al periodo di erogazione del servizio | >= 99,5% | >= 98,5% |
FRTS | Fermi ripristinati nei tempi stabi- liti | Valutazione del nume- ro complessivo di fermi ripristinati entro il limite fissato contrat- tualmente rispetto a tutti i fermi occorsi | = 100% entro 4 ore dalla rile- vazione del problema | >= 98,5% entro 8 ore lavorati- ve dalla rilevazione del proble- ma |
ARCF | Accuratezza ri- pristino corretto funzionamento | Numero di interventi di manutenzione an- dati a buon fine al primo intervento ri- spetto al numero di chiamate effettuate | >= 98,0% | >= 95,0% |
TRCF | Tempestività ri- pristino corretto funzionamento | Percentuale di interven- ti di manutenzione cor- rettiva che rispettano i tempi contrattuali nel periodo di osservazione | >= 98,0% entro 8 ore lavorati- ve dalla rilevazione del proble- ma | >= 95,0% entro 48 ore dalla rilevazione del problema |
CRAC | Correttezza del- l’aggiornamento della configura- zione | Numero di aggiorna- menti che non compor- tano indisponibilità di funzioni all’utenza rispetto al numero tota- le degli aggiornamenti1 | >= 96,0% dei casi l’aggiorna- mento non provoca né fermi totali del sistema centrale né indisponibilità all’utenza di funzionalità critiche | >= 92,0% dei casi l’aggiorna- mento non provoca indispo- nibilità all’utenza di funziona- lità non critiche |
L’utilizzo degli indicatori nei Capitolati non è un mero esercizio metrico, ma costituisce un mezzo di indirizzo e controllo della fornitura che, per la sua garanzia, dev’essere necessa- riamente connesso ad azioni contrattuali che possano essere di stimolo o deterrente verso il fornitore nell’indurlo ad eseguire a regola d’arte la propria opera, entro i vincoli stabiliti. Ciò non significa necessariamente legare ogni indicatore ad una particolare penale ma, in generale, prevedere delle azioni contrattuali specifiche anche molto diverse, che possono configurarsi come incentivi (premio per consegne anticipate, ad esempio) oppure con lo scadenzare i pagamenti in relazione alle diverse fasi di consegna preve- dendo diverse gradualità del pagamento in relazione alla puntualità di consegna delle varie fasi.
32
1 In questo caso la formulazione dell’algoritmo dell’indicatore originario è stata invertita, utilizzando il numero dei casi che NON hanno provocato problematiche, per omogeneità alle altre definizioni utilizzate e quindi maggiore comprensibilità delle argomentazioni.
Chiariamo quest’ultimo punto con un esempio, in un semplice caso di sviluppo SW, fermo restando l’importo totale concordato, la previsione iniziale di dilazione del pagamento potrebbe essere: 10% alla definizione dei requisiti, 20% al completamento dell’analisi, 20% alla consegna del software, 40% al buon esito del collaudo, 10% alla corretta messa in eser- cizio. Il contratto potrebbe prevedere inoltre uno slittamento di porzioni dei pagamenti in relazione a ritardi nelle consegne: se si verificasse, ad esempio, una consegna dell’analisi o del software in ritardo di almeno il 10% del tempo previsto per la durata della fase relativa, il pagamento potrebbe essere ridotto al 50% di quanto previsto per quel passo e la porzio- ne rimanente resa disponibile in cumulo alla fase successiva.
Nel caso più abituale di definizione di penali è bene comunque tener presente alcune con- siderazioni fondamentali perché la loro costruzione non diventi mal correlata all’entità effettiva delle attività e quindi vessatoria:
1. Qualunque indicatore si sia scelto relativamente ad un prodotto o un servizio è pro- babile che lo sforamento dei valori soglia in sé non sia sempre una condizione d’al- larme determinante ma vari significativamente in relazione alla criticità che comporta rispetto all’attività impattata. Quindi è necessario individuare sempre preventivamen- te le classi di servizio di diversa criticità (spesso indicate anche come “classi di rischio”, al minimo due ma possono essere anche tre o quattro in dipendenza della sensibilità amministrativa sullo specifico argomento) per costruire un’opportuna modulazione delle penali applicabili in relazione alle stesse.
2. La reiterazione della problematica o la sua persistenza nel tempo è un fattore aggra- vante che dovrebbe dare luogo ad un escalation della penalizzazione applicata.
3. La definizione di ogni singola penale deve essere comunque valutata considerando anche l’ipotesi di possibili varie situazioni negative concomitanti che portino all’appli- cazione simultanea di più penali: devono sussistere indicazioni che esprimano un tetto massimo applicabile per il cumulo delle penali coinvolte, correlato alla gravità del danno apportato.
4. L’applicazione delle penali deve essere rapportata congruentemente con il valore eco- nomico della fornitura. La penale deve essere quindi sempre applicata in percentuale rispetto ai corrispettivi del periodo di riferimento.
Ovviamente non è immediata e lineare la concretizzazione delle indicazioni elencate, spe- cie laddove il corpo degli indicatori presenti sia piuttosto numeroso e complesso. La racco- mandazione che è opportuno dare è che, al fine di prevenire l’introduzione di predisposi- zioni eccessivamente punitive o non congrue con la realtà delle anomalie prese in conside- razione, dovrebbe essere sempre effettuata un’attività di “simulazione” prima del consoli- damento finale delle penali contrattuali. Per simulazione s’intende la costruzione di ipotesi realistiche su casi di criticità nella consegna della fornitura per calcolarne l’esito nell’appli- cazione delle penali, spingendosi fino alla loro conseguenza estrema (caso più sfavorevo- le). In pratica si tratta di costruire modelli matematici più o meno semplici che permettano di fare rapidamente considerazioni sui vari esiti possibili.
33
La simulazione dovrebbe consentire sempre di costruire o verificare meccanismi di cal- mierazione, in relazione a quanto detto precedentemente, che non rendano eccessiva- mente rischioso in partenza il contratto da stipulare per il fornitore ma al contempo
Codice | Indicatore | Servizi ad alta disponibilità (servizi erogati tramite il sistema centrale nel- l’orario 8-16) | SERVIZI A DISPONIBILITÀ NORMALE (servizi erogati tramite il sistema centrale dalle h16 alle 8 e servizi erogati tramite i sistemi periferici nell’orario 8-16) | ||
Valore soglia | Penale | Valore soglia | Penale | ||
DIS1 | Disponibilità del sistema automatico in linea | >= 99,5% | Per ogni 0,1% di disponibilità inferiore all’obiettivo si applica una penale pari allo 0,5% del corrispetti- vo relativo al periodo di riferimento | >= 98,5% | Per ogni 0,1% di disponibilità inferiore all’obiettivo si applica una penale pari allo 0,1% del corrispetti- vo relativo al periodo di riferimento |
FRTS | Fermi ripristi- nati nei tempi stabiliti | = 100% entro 4 ore dalla rilevazione del problema | Per ogni 0,1% di ripri- stini in meno nei tempi stabiliti si appli- ca una penale pari a 0,5% del corrispetti- vo relativo al periodo di riferimento. Per ogni 0,1% di ripristini impieganti più di 8 ore dalla segnalazione del problema si appli- ca una penale aggiun- tiva pari allo 0,05% del corrispettivo relati- vo al periodo di riferi- mento | >= 98,5% entro 8 ore lavorative dalla rileva- zione del problema | Per ogni 0,05% di ripristini in meno nei tempi stabiliti si appli- ca una penale pari a 0,1% del corrispetti- vo relativo al periodo di riferimento. Per ogni 0,1% di ripristini impieganti più di 24 ore dalla segnalazione del problema si appli- ca una penale aggiun- tiva pari allo 0,05% del corrispettivo relati- vo al periodo di riferi- mento |
ARCF | Accuratezza ripristino cor- retto funzio- namento | >= 98,5% | Per ogni 0,1% di ripri- stini in meno portati a buon fine al primo intervento si applica una penale pari allo 0,05% del corrispettivo relativo al periodo di riferimento | >= 95,0% | Per ogni 0,1% di ripri- stini in meno portati a buon fine al primo intervento si applica una penale pari allo 0,05% del corrispetti- vo relativo al periodo di riferimento |
TRCF | Tempestività ripristino cor- retto funzio- namento | >= 98,0% entro 8 ore lavorative dalla rileva- zione del problema | Per ogni 1% di inter- venti correttivi che non hanno rispettato i tempi di ripristino si applica una penale pari allo 0,05% del corrispettivo relativo al periodo di riferi- mento | >= 95,0% entro 48 ore dalla rilevazione del problema | Per ogni 1% di inter- venti correttivi che non hanno rispettato i tempi di ripristino si applica una penale pari allo 0,05% del corrispettivo relativo al periodo di riferi- mento |
CRAC | Correttezza aggiornamen- to della confi- gurazione | >= 96,0% dei casi l’aggiornamento non provoca né fermi totali del sistema né indisponibilità all’u- tenza di funzionalità critiche. | Per ogni 0,1% in meno di aggiornamenti che hanno provocato indi- sponibilità del sistema della soglia concordata si applica una penale pari allo 0,05% del corrispettivo relativo al periodo di riferimento | >= 92,0% dei casi l’aggiornamento non provoca indisponibili- tà all’utenza di funzio- nalità non critiche | Per ogni 0,1% in meno di aggiornamenti che hanno provocato indi- sponibilità del sistema della soglia concordata si applica una penale pari allo 0,05% del corrispettivo relativo al periodo di riferimento |
garantiscano il committente fornendo una struttura deterrente verso esecuzioni di bassa aderenza ai requisiti. Ricorrendo all’esempio precedentemente prodotto per quanto riguarda l’istanziazione degli indicatori possiamo vedere come si possa modulare la rela- tiva applicazione di penali.
34
Specifichiamo dunque le azioni contrattuali espletabili a fronte di ogni indicatore, tenendo in considerazione quanto appena detto relativamente alla definizione della singola penale e del- l’intero complesso e verifichiamo il possibile esito nel caso di una sua escalation (simulazione). Le penali, come mostrato nella precedente tabella, possono quindi essere modulate secon- do vari meccanismi:
• in primo luogo sono diversamente definite, a parità di indicatore, in relazione ad ogni classe di criticità presente: la particolare soglia del livello di servizio da rispettare per l’indicatore coinvolto, la differente quota d’incremento usata nella valutazione negati- va dell’indicatore (per ogni 1% in meno piuttosto che per ogni 5%) e l’ammontare della decurtazione economica in penalizzazione si vanno a comporre insieme per definire l’effettivo scotto dell’attività non eseguita congruentemente;
• nell’ambito della stessa classe si può anche correlare l’attribuzione di penali all’aggra- vamento delle problematiche distinguendo un’anomalia di primo livello (interruzione del servizio, ad esempio) da una persistenza dell’anomalia stessa (protrarsi dell’inter- ruzione oltre un certo termine) introducendo una quota penale aggiuntiva che tiene conto dell’escalation;
• inoltre, tutte le penali sono rapportate al periodo di riferimento della rilevazione (spesso, per comodità, coincidente con scaglionamenti della fatturazione) rispetto al quale devono essere valutate in diminuzione dei corrispettivi previsti.
L’esperienza gestionale o dati di rilevamento storicizzati dovrebbero essere utilizzati per far presagire quali siano le probabilità di ricorrenza degli eventi negativi per poter definire cor- rettamente la quota di penalizzazione da attribuire.
Infatti l’utilizzo prevalente delle percentuali potrebbe non risultare sensato se, ad esempio, per la solidità architetturale dei sistemi da presidiare, o per il contenuto periodo di riferimento (ad esempio, trimestrale) non è rilevabile un numero sufficiente di casi statisticamente valido.
Per chiarezza, consideriamo un esempio in dettaglio: il caso di interruzione di servizi ad alta disponibilità rilevata durante un periodo contrattuale supponendo che si siano verifica- te solo 8 interruzioni dell’operatività, tutte risolte nel giro di un’ora con l’eccezione di un caso in cui era necessario un componente hardware di ricambio che ha impiegato 6 ore ad essere ricevuto e installato (v. indicatore FRTS).
Si tratta dell’unico caso in cui il ripristino non ha comportato solo manovre gestionali ma l’innesco di attività di manutenzione correttiva eseguita entro le 8 ore (v. indicatore TRCF). Supponendo che le altre 7 interruzioni siano state di piccola entità per non più di 4 ore tota- li, la disponibilità complessiva del sistema è stata inficiata per 1,5% (v. indicatore DIS1, 10 ore di interruzione su 520 totali di operatività nel trimestre). L’indisponibilità periferica, secondaria a quella del sistema centrale non viene considerata.
Indicatore | Soglia da rispettare | Rilevamento | Discrepanza | Calcolo penale applicabile (% corrispettivi) |
DIS1 | 99,5% | 98% | 1,5% | 0,1x15x0,5 = 0,75 |
FRTS | 100% | 87,5% | 12,5% | 125x0,1x0,5 = 6,25 |
TRCF | 98% | 100% | 0% | 0 |
La situazione delle penali relative agli indicatori coinvolti alla fine del periodo, supponiamo trimestrale, si troverebbe ad essere quella esposta nella tabella seguente:
35
Il totale delle penali applicabili comporterebbe quindi una decurtazione dei corrispettivi del 7% sul totale previsto per il trimestre di riferimento.
Da notare che se l’intervento di manutenzione correttiva si fosse protratto oltre le 8 ore avrebbe dato luogo ad un’inadempienza del 100%, essendo l’unico evento del genere nel periodo e ciò avrebbe comportato un’ulteriore penale del 5% (100x1x0,05), portando al 12% il totale.
L’esempio suddetto serve a sollecitare una particolare attenzione alla considerazione delle possibili conseguenze, anche per semplici determinazioni matematiche, della definizione delle penali in quanto è possibile che anche eventi relativamente contenuti comportino penalizzazioni notevoli. Dovrebbe essere preferita una determinazione differenziata degli algoritmi per l’ambito dei piccoli numeri piuttosto che dove è possibile applicare piena- mente considerazioni statistiche.
In generale ciò porta comunque alla considerazione della necessità di stabilire dei tetti mas- simi per la composizione complessiva delle penali applicabili, indipendentemente dalle singole eventualità insorte. I tetti dovrebbero inoltre essere relazionati alle classificazioni di criticità dei servizi coinvolti, per congruenza con i relativi livelli di servizio.
Ad esempio, nel caso precedente potrebbe essere opportuno considerare un massimale del 15% per il complesso delle penali applicabili nel caso di incidenza sui servizi ad alta dispo- nibilità ed un distinto massimale del 5% per l’incidenza sui servizi a disponibilità normale. Il massimale deve essere considerato e calcolato distintamente per ogni classe di servizio, considerando l’effetto dell’intero gruppo di indicatori, per limitare l’escalation delle penali in rapporto alla criticità dell’ambito coinvolto. Va comunque sempre tenuto conto anche dell’ammontare complessivo di tali massimali, nell’ipotesi più pessimistica. Nel caso peg- giore dell’esempio suddetto si avrebbe una decurtazione al massimo del 20 % dei corrispet- tivi del fornitore nel periodo, quota assolutamente non trascurabile per lo stesso.
4.4 Come integrare Classi di fornitura e processi trasversali
Quanto detto per la definizione delle attività e dei prodotti relativi alle Classi di fornitura vale analogamente per tutto ciò che va a comporre i processi trasversali: a valle delle attivi- tà primarie dovranno essere descritte tutte le attività relative alla Gestione delle attività pro- gettuali, l’Assicurazione di Qualità delle stesse, la loro Documentazione e Gestione della Configurazione.
36
Qualunque sia l’attività inclusa nella fornitura di un servizio, anche se composto da molte- plici voci, la sua assegnazione ad un determinato fornitore coincide con l’esistenza di una responsabilità unica della fornitura e del suo controllo. Ne deriva naturalmente anche la necessità e la convenienza, ad esempio, di un unico Piano di progetto che abbia, a livello contrattuale, la visione della fornitura complessiva e ne rappresenti quindi gli elementi prin- cipali di pianificazione, correlati ai rilasci dei deliverables previsti. Ciò non esclude la pos- sibilità di estrazione di singoli piani operativi che dettaglino alcuni servizi, ad uso e consu- mo dei locali referenti degli stessi, ma questi sono da considerarsi documenti a valenza ope- rativa (eventualmente previsti e inclusi anch’essi come deliverables nel piano più generale) ma che non possono sostituire una visione integrale e centralizzata quale quella del Piano di Progetto complessivo. In esso dovranno quindi confluire tutti gli elementi relativi alle
istanze di tutte le Classi di fornitura incluse nel Capitolato con le relative caratterizzazioni dimensionali e qualitative.
Ricapitolando: tutti i prodotti relativi ai processi trasversali saranno quindi descritti un’uni- ca volta, raccogliendo le necessità da assolvere rispetto a tutte le Classi di fornitura. Si avrà quindi un unico paragrafo del Capitolato per la descrizione del Piano di progetto come per il Piano di Qualità ed il Piano di Gestione della configurazione, cui eventualmente si riman- derà, ove necessario, durante la descrizione delle varie classi. Ognuno di questi piani può comunque essere opportunamente organizzato in una o più sezioni, connesse alle diverse istanze delle Classi di fornitura presenti con relativa diversità di dettagli, per agevolare il controllo centralizzato delle caratteristiche dell’intera fornitura.
37
5. Scenari applicativi
Nella presente sezione si propongono due esempi di Capitolati tecnici costruiti applican- do il metodo indicato dalle Linee guida. L’obiettivo è quello di mostrare come, a partire da un insieme di esigenze e di requisiti predefiniti, è possibile definire una fornitura per- sonalizzando e componendo Classi di fornitura e processi trasversali descritti nel Dizionario delle forniture ICT.
Gli esempi presentati descrivono forniture che riguardano soluzioni complesse e di note- voli dimensioni economiche: si intende infatti sottoporre all’attenzione del lettore dei casi in cui la fornitura richiesta non equivalga ad una specifica classe presente nel Dizionario, ma sia articolata in una pluralità di servizi facenti capo a più Classi di fornitura tra quelle incluse nel Dizionario.
Gli scenari sviluppati, che comunque rispetto ai casi reali presi a riferimento sono notevol- mente semplificati per l’esigenza di dare risalto al metodo applicato piuttosto che alla solu- zione trattata, sono i seguenti:
• Caso Full Outsourcing – Lo scenario descrive il caso di una Amministrazione che intende affidare a due fornitori distinti rispettivamente il servizio di sviluppo e quel- lo di gestione del Sistema Informativo. Sebbene parlando di full outsourcing, le Classi di fornitura siano quasi la totalità delle classi presenti nel Dizionario, nello scenario si prendono in considerazione principalmente quelle classi relative a sviluppo e manu- tenzione di software e a gestione e manutenzione di sistemi, che comunemente costi- tuiscono i servizi “core” di un contratto di full outsourcing,
• Caso CRM – Lo scenario descrive l’esempio di una fornitura per la progettazione, rea- lizzazione e gestione di un Contact Center multicanale con finalità di “sportello vir- tuale unico” per l’erogazione di informazioni e servizi all’utenza. Tra le Classi di forni- tura presenti nel Dizionario di interesse per il caso indicato, l’accento è posto su quel- le classi, quali ad esempio lo sviluppo di software mediante soluzioni commerciali e l’assistenza agli utenti, che maggiormente caratterizzano una problematica di Customer Relationship Management.
39
L’ordine in base al quale gli esempi sono presentati è casuale: ciascun esempio è indi- pendente dagli altri ed è autoconsistente; inoltre le modalità espositive con cui gli argo- menti sono trattati in ciascun scenario sono eterogenee, a dimostrazione del fatto che le Linee guida propongono un metodo che facilita l’impostazione di un Capitolato, ma non impongono schemi rigidi, lasciando comunque al compilatore la facoltà di redigere gli atti contrattuali nella maniera più consona alle esigenze specifiche ed alle prassi in uso presso l’Amministrazione.
Per concludere, è d’obbligo un warning al lettore. Non si aspetti, chi si accinge a leggere gli scenari, un momento ricreativo: la lettura di un Capitolato tecnico è di per sé molto impe- gnativa e un testo che intende spiegare come utilizzare delle Linee guida per scrivere un Capitolato non può certo risultare di semplice lettura.
5.1 Caso Full Outsourcing
Lo scenario proposto riguarda un’Amministrazione di grandi dimensioni, articolata in uffici centrali, presenti sul territorio urbano di Roma, e uffici periferici distribuiti sul territorio nazionale. L’Amministrazione è preposta alle funzioni di indirizzo, programmazione e con- trollo in materia amministrativa di propria competenza; al conseguimento degli obiettivi istituzionali concorrono anche diversi Enti, che operano sotto la vigilanza dell’Am- ministrazione e che erogano servizi ai cittadini.
Il Sistema Informativo (S.I.) dell’Amministrazione è stato per anni sviluppato e gestito da un unico Fornitore, nell’ambito di una concessione che prevedeva, oltre alle attività di svilup- po del S.I. e dei servizi collegati, la gestione ed esercizio del S.I., ad esclusione delle attivi- tà di conduzione tecnica del CED, effettuate dal personale dell’Amministrazione.
In prossimità della scadenza della concessione, vista la necessità di individuare un Fornitore subentrante senza soluzioni di continuità nel funzionamento del S.I., vista la necessità di adeguare il S.I. a provvedimenti normativi di nuova emanazione e conside- rata anche la difficoltà di portare avanti la conduzione tecnica del CED con il solo per- sonale interno, l’Amministrazione ha avviato le procedure di gara previste dalla norma- tiva comunitaria per l’affidamento a soggetti esterni di tutti i servizi connessi allo svilup- po ed alla conduzione del S.I..
Dal momento che, con l’affidamento all’esterno anche dei servizi di conduzione tecnica del CED, le attività da esternalizzare coprivano nel complesso la funzione ICT, l’Am- ministrazione, anche sulla base delle esperienze pregresse, ha ritenuto poco strategico e poco conveniente continuare a delegare l’insieme delle attività ad un unico Fornitore, con il rischio di creare un legame indissolubile e di precludersi la possibilità di operare in futu- ro scelte differenti; d’altra parte, presentando le attività richieste un alto grado di correlazio- ne, sarebbe stata molto rischiosa un’elevata selettività nell’esternalizzazione dei servizi, soluzione che avrebbe comportato un impegno notevole del personale interno per assicu- rare la supervisione ed il coordinamento delle attività tra più fornitori.
L’Amministrazione ha quindi optato per una forma di multisourcing, prevedendo l’affida- mento rispettivamente dei servizi di sviluppo e dei servizi di conduzione del S.I. a due Fornitori distinti. In tal modo ha dovuto affrontare e regolamentare, già in fase di stesura dei documenti di gara, le problematiche connesse al coordinamento delle attività tra i due Fornitori, anche al fine di facilitare l’individuazione delle responsabilità in fase di esecuzio- ne contrattuale per eventuali disservizi all’utenza.
40
Di seguito si fornisce un quadro di sintesi delle esigenze dell’Amministrazione e del contesto di riferimento; si descrivono a seguire, applicando il metodo proposto dalle Linee guida di cui il presente Manuale è parte integrante, gli elementi oggetto dei servizi richiesti, le principali caratteristiche ed i livelli di qualità, le logiche di determinazione dei valori soglia e delle pena- li. Lo scenario si conclude, quindi, con la stesura del Capitolato tecnico, nel quale sono svilup- pate le parti che hanno rilevanza ai fini della applicazione delle Linee guida.
5.1.1 Descrizione delle esigenze e del contesto
L’Amministrazione dispone di un Sistema Informatico di grandi dimensioni, che nella con- figurazione corrente è costituito da:
• unità centrale di elaborazione (sistema mainframe) e sistemi server localizzati presso il CED;
• sistemi server dipartimentali, ubicati presso gli uffici periferici;
• postazioni di lavoro e stampanti, distribuite presso gli uffici centrali e gli uffici perife- rici;
• rete di telecomunicazione, che utilizza i servizi di trasporto della RUPA per connette- re la periferia al centro.
I server utilizzano sistemi operativi eterogenei (Microsoft Windows NT e Unix) e sono uti- lizzati in parte (server enterprise) per erogare direttamente servizi ai cittadini e per svolge- re servizi di supporto e/o servizi applicativi di tipo infrastrutturale; in parte (server di tipo workgroup) sono utilizzati specificatamente da un ristretto numero di utenti, per attività proprie degli uffici dipartimentali dell’Amministrazione.
Il patrimonio software è costituito da applicativi sviluppati ad hoc, con tecniche di svilup- po tradizionale e con tecniche di sviluppo object oriented.
Il S.I. rappresenta da tempo per l’Amministrazione uno strumento strategico per il cambia- mento e per assicurare l’efficienza degli uffici; l’emanazione di alcuni provvedimenti legis- lativi, tra i quali le prescrizioni in materia di e-government e le disposizioni in materia di federalismo fiscale, che hanno impatto sui flussi informativi della gran parte delle Amministrazioni dello Stato, rende necessaria per l’Amministrazione una reimpostazione strutturale del S.I., per renderlo rispondente alle nuove e più cogenti esigenze di comple- tezza, tempestività ed affidabilità delle informazioni. In particolare l’Amministrazione ha necessità di definire una nuova architettura tecnologica ed adeguare i flussi informativi tra centro e periferia, nonché verso Amministrazioni ed utenti esterni. L’Amministrazione inol- tre deve assicurare che il S.I. operi sempre correttamente e sia costantemente in linea con le evoluzioni tecnologiche e normative in itinere.
Per il ridisegno e la conduzione del S.I. l’Amministrazione, ha istituito una apposita Commissione, per svolgere tutte le attività propedeutiche all’espletamento di una gara comunitaria per l’affidamento a nuovi soggetti dell’evoluzione e gestione del S.I.; in parti- colare definire le modalità di outsourcing, le procedure concorsuali e sviluppare lo studio di fattibilità.
Nello studio di fattibilità la Commissione ha definito le linee di evoluzione del sistema rispetto ai provvedimenti normativi di nuova emanazione, ed ha evidenziato le seguenti principali aree di intervento, connesse allo sviluppo e conduzione funzionale e tecnica del S.I.:
41
a) Sviluppo di nuovi applicativi e revisione delle applicazioni esistenti. Il S.I. deve forni- re una infrastruttura funzionale alla applicazione dei provvedimenti normativi di nuova emanazione. È indispensabile da un lato integrare le applicazioni già esistenti con nuove applicazioni che supportino l’Amministrazione nello svolgimento delle nuove funzioni ad essa attribuite dal legislatore; dall’altro è necessario modificare
alcune applicazioni esistenti, sia per recepire i cambiamenti normativi, sia per favori- re un maggiore coordinamento delle attività svolte dagli uffici centrali e dagli uffici periferici. Occorre inoltre migliorare l’aspetto comunicativo verso l’esterno, anche al fine di far conoscere meglio le attività dell’Amministrazione ed i servizi erogati a citta- dini ed imprese.
b) Gestione e conduzione del S.I. È necessario garantire il corretto ed efficace funziona- mento delle applicazioni, dei sistemi centrali, dei sistemi periferici e delle reti di tele- comunicazione. A fronte dello sviluppo e/o evoluzione delle applicazioni, deve esse- re assicurato un adeguato aggiornamento e potenziamento delle infrastrutture tecno- logiche ed eventualmente logistiche.
La Commissione ha quindi ha deciso di procedere attraverso due distinte gare comunitarie, nella forma di appalto concorso, per selezionare due diversi fornitori, nel seguito Fornitore A e Fornitore B, ai quali affidare, per un periodo di tre anni, rispettivamente:
1. servizi di sviluppo del S. I. (Fornitore A). Includono la progettazione e lo sviluppo di nuove applicazioni, la modifica di applicazioni esistenti e le attività connesse, ivi incluse la manutenzione delle applicazioni e la formazione del personale sui temi col- legati alle nuove applicazioni;
2. servizi di gestione del S.I. (Fornitore B). Includono la gestione e conduzione di sistemi centrali e periferici, la gestione del CED, la gestione del parco applicativo esistente e l’as- sistenza, tramite i servizi di help-desk e di assistenza in loco, agli utenti del S.I..
Le due gare contemporanee realizzano per l’Amministrazione la transizione da un rappor- to di concessione ad un appalto di fornitura dei servizi informatici e si presentano comples- se soprattutto per gli aspetti che riguardano la definizione dei rapporti tra i diversi fornito- ri. La separazione delle attività di sviluppo e gestione tra due fornitori e l’utilizzo della infra- struttura hardware e software resa disponibile dall’Amministrazione, presuppone una forte azione di coordinamento, dalla fase di definizione dei nuovi sviluppi fino al rilascio e messa in esercizio dei prodotti realizzati; tale azione richiede l’applicazione di adeguate proce- dure tecniche ed amministrative che devono essere previste e, per quanto possibile, defini- te già in fase di stesura dei documenti di gara, anche allo scopo di facilitare la individuazio- ne di responsabilità per eventuali non conformità rilevate nel corso della esecuzione dei contratti e/o di eventuali disservizi agli utenti.
Nello sviluppo del presente scenario, si prende a riferimento la documentazione di gara prodotta dall’Amministrazione con il solo scopo di rilevare una esigenza reale e definire la fornitura applicando il metodo proposto dalle Linee guida: l’obiettivo, quindi, non è quel- lo di presentare una soluzione di full outsourcing, ma di mostrare come, a partire da un insieme di esigenze e requisiti predefiniti, sia possibile definire in un Capitolato tecnico una fornitura articolata in una pluralità di servizi, seguendo le indicazioni contenute nelle Linee guida ed in particolare personalizzando, componendo e coniugando Classi di forni- tura e processi trasversali descritti nel Dizionario delle forniture ICT.
42
Per tale motivo la problematica “full outsourcing” non è trattata in modo esaustivo: sono sviluppate con un maggior grado di dettaglio quelle Classi di fornitura corrispondenti ai ser- vizi che maggiormente caratterizzano un contratto di full outsourcing (sviluppo e manuten-
zione di software; gestione e manutenzione sistemi) e sono tralasciati del tutto i servizi di sicurezza, perchè strettamente legati alle politiche di sicurezza ed organizzative adottate dall’Amministrazione; per gli stessi motivi sia le caratteristiche del S.I. prima descritte, che le esigenze dell’Amministrazione sono state opportunamente semplificate.
Nei paragrafi che seguono, quindi, a partire dalle esigenze dell’Amministrazione, dal con- testo di riferimento, e dalle modalità di outsourcing prima indicate (affidamento a due for- nitori distinti dei servizi rispettivamente connessi allo sviluppo ed alla gestione del S.I.) si individuano e si definiscono i servizi da affidare a ciascun Fornitore, seguendo il metodo proposto dalle Linee guida. In particolare, lasciando da parte la documentazione di gara predisposta dall’Amministrazione, che è presa di volta in volta a riferimento solo per meglio dettagliare esigenze e contesto di riferimento, pur con le semplificazioni e personalizzazio- ni prima indicate, si simula il modo di procedere di chi, conoscendo le esigenze ed il con- testo e disponendo delle Linee guida, debba predisporre ex-novo i Capitolati tecnici per espletare le gare. Si presentano quindi i ragionamenti ed i passi logici che portano a defini- re la fornitura e si evidenziano eventuali difficoltà e/o elementi di attenzione rilevanti per la problematica affrontata o per l’applicazione delle Linee guida.
5.1.2 Selezione classi di fornitura e definizione istanze
Come indicato nel paragrafo 5.1.1, l’Amministrazione intende affidare al Fornitore A la pro- gettazione e lo sviluppo di nuovi sottosistemi applicativi, da realizzarsi sia con nuovo soft- ware ad hoc che con la modifica di software ad hoc esistente; si suppone, infatti, per sem- plificare il quadro di riferimento, che il patrimonio software applicativo sia costituito solo da software di tipo “custom”, e che detta caratteristica debba essere preservata nelle evolu- zioni successive del S.I.. Sono da affidare al Fornitore A anche i servizi comunemente con- nessi allo sviluppo del software, quali la manutenzione delle applicazioni realizzate e la for- mazione del personale sui temi collegati alle nuove applicazioni.
Scorrendo il Dizionario delle Forniture ICT, le Classi di fornitura di interesse sono: “SSW - Sviluppo e MEV di software ad hoc”; “MAC - Manutenzione correttiva ed adeguativi”; “FOR
- Formazione e addestramento”. Parlando di servizi di sviluppo, la classe “core” è rappre- sentata dalla classe “SSW - Sviluppo e MEV di software ad hoc”; pertanto, nel seguito dello scenario, si svilupperanno principalmente le considerazioni e gli esempi relativi alla classe indicata.
43
Con analoghi ragionamenti si possono individuare, scorrendo il Dizionario delle Forniture ICT, le classi da affidare al Fornitore B, al quale, come indicato nel paragrafo 5.1.1, l’Amministrazione intende affidare tutti i servizi connessi alla gestione e conduzione dei sistemi centrali, dei sistemi periferici e del CED, la gestione del parco applicativo esistente e l’assistenza, tramite i servizi di help-desk e di assistenza in loco, agli utenti del S.I.. Le Classi di fornitura di interesse dell’Amministrazione, che sarebbero di competenza del Fornitore B, sono: “GSW - Gestione applicativi e Basi Dati”; “GMR - Gestione e manuten- zione reti”; “SSI - Sviluppo sistemi”; “GSI - Gestione sistemi”; “MSI - Manutenzione sistemi”; “MAC - Manutenzione adeguativa e correttiva”; “ASS - Assistenza in remoto e in locale”; “GPL - Gestione e manutenzione delle postazioni di lavoro”; “MLS - Controllo dei livelli di servizio”.
Nel seguito, allo scopo di semplificare lo scenario, si svilupperanno ad un maggior livello di dettaglio le problematiche relative alle seguenti classi “core” di un servizio di conduzione tec-
nica di un S.I.: “GSI - Gestione sistemi”; “MSI - Manutenzione sistemi”; “MAC - Manutenzione adeguativa e correttiva”. Allo scopo di semplificare lo scenario, si ipotizza, infatti, che l’Amministrazione abbia da poco rinnovato l’infrastruttura hardware/software esistente e che dai nuovi sviluppi non debbano scaturire modifiche di configurazione tali da far ritenere neces- saria la Classe di fornitura “SSI - Sviluppo sistemi”, ferma restando la possibilità che se a segui- to della messa in linea di qualche nuovo applicativo e/o di nuove esigenze dovesse rilevarsi la necessità di apportare cambiamenti rilevanti di configurazione, detti cambiamenti richiedereb- bero verosimilmente modifiche anche alla gestione dei sistemi e dovrebbero necessariamente essere regolati attraverso apposite varianti contrattuali o atti addizionali. Si tralascia la classe “ASS - Assistenza in remoto e in locale”, perché trattata nell’esempio relativo al Caso CRM e la classe “GMR - Gestione e manutenzione reti”, perché si suppone che l’Amministrazione abbia affidato il complesso delle attività ai fornitori dei servizi RUPA; si tralasciano infine, per sempli- ficare lo scenario, le classi “GSW - Gestione applicativi e Basi Dati”, “GPL - Gestione e manu- tenzione delle postazioni di lavoro”; “MLS - Controllo dei livelli di servizio”.
Per quanto riguarda i processi trasversali, tutti i processi indicati nel Dizionario delle forniture ICT, sia di supporto che organizzativi, sono di interesse per l’Amministrazione; risulta tuttavia di particolare rilevanza, sia per il Fornitore A che è preposto allo sviluppo del software, che per il Fornitore B, responsabile della manutenzione del parco applicativo e della gestione dei com- ponenti hardware e software dei sistemi, la gestione della configurazione. Analogamente, a fronte della separazione delle attività di sviluppo e di gestione tra due fornitori, è essenziale per l’Amministrazione una forte azione di coordinamento, che può essere facilitata regolamen- tando le modalità di gestione del progetto attuate da ciascun Fornitore; il processo di gestione, inoltre, come meglio evidenziato nel seguito, ha una rilevanza strategica per pianificare e con- trollare le attività di sviluppo a carico del Fornitore A nel corso della esecuzione contrattuale. Per i motivi indicati, nell’ambito dei processi trasversali descritti nel Dizionario delle forniture ICT, saranno nel seguito sviluppati ad un maggior livello di dettaglio il processo “PGC - Gestione della Configurazione” e il processo “PGE - Gestione”.
Riassumendo, in base ai ragionamenti sopra esposti, si suppone che siano di interesse per l’Amministrazione le seguenti Classi di fornitura:
• Servizi di sviluppo del S.I. (da richiedere al Fornitore A);
SSW – Sviluppo e MEV di software ad hoc.
• Servizi di gestione del S.I. (da richiedere al Fornitore B);
GSI – Gestione sistemi;
MSI – Manutenzione sistemi;
MAC – Manutenzione adeguativa e correttiva.
Sono inoltre di interesse per l’Amministrazione e quindi dovranno essere richiesti ad entrambi i fornitori, con diverso livello di specializzazione in funzione delle Classi di forni- tura tutti i processi trasversali; nello scenario saranno sviluppati i seguenti, essenziali per assicurare il necessario livello di coordinamento tra le attività dei due fornitori:
44
• Processi Trasversali (da richiedere al Fornitore A e al Fornitore B);
PGE – Gestione;
PGC – Gestione della Configurazione.
Di seguito si descrive ciascuna classe e ciascun processo; nella descrizione si evidenziano solo quegli aspetti che caratterizzano la classe/il processo rispetto alle esigenze ed al con- testo di riferimento e/o eventuali elementi che fanno configurare limitazioni nell’applicazio- ne delle Linee guida; non si ripropone la descrizione completa di ciascuna classe e ciascun processo, per la quale si rimanda a quanto contenuto nel Dizionario delle forniture ICT.
Sviluppo e MEV di software ad hoc
Secondo le linee di evoluzione del S.I. delineate nello studio di fattibilità, il servizio dovrà includere interventi di sviluppo di nuovo software e modifica al software esistente, afferen- ti a 14 obiettivi dettagliatamente descritti in un allegato al Capitolato e classificati nelle seguenti tre tipologie:
a) obiettivi di sviluppo di tipo A: interventi volti a realizzare sottosistemi applicativi che supportino le funzioni istituzionali dell’Amministrazione e che consentano il presidio dei processi di governo;.
b) obiettivi di sviluppo di tipo B: interventi volti a migliorare il coordinamento tra gli uffi- ci dell’Amministrazione e che favoriscano il presidio dei processi di servizio;
c) obiettivi di sviluppo di tipo C: interventi volti a migliorare le informazioni ed i servi- zi on line resi disponibili verso l’esterno, attraverso il Portale dell’Amministrazione.
Per ciascuno dei 14 obiettivi definiti, l’Amministrazione ha specificato la normativa di riferimen- to, le azioni previste dall’intervento di automazione, l’architettura tecnica di massima di imple- mentazione dell’obiettivo ed i tempi entro i quali è richiesta la realizzazione dell’obiettivo.
Le applicazioni di nuova realizzazione, risultanti da nuovi sviluppi software e/o da modi- fiche al software esistente, a prescindere dalla tipologia di obiettivo (A, B, C) cui fanno rife- rimento, al pari delle applicazioni in esercizio che costituiscono il patrimonio applicativo del S.I., dovranno essere inquadrate in due classi di servizio che l’Amministrazione ha defi- nito per differenziare gli attributi di qualità del software da realizzare e dei servizi di con- duzione e di assistenza connessi:
• classe di servizio “non critica”, corrispondente al livello base per applicazioni che neces- sitano dell’erogazione dei servizi di conduzione e assistenza nei soli giorni lavorativi, con esclusione del sabato. Appartiene a tale livello la generalità delle applicazioni in eserci- zio presso gli Uffici dell’Amministrazione, che non rientrano nei due casi successivi;
• classe di servizio “critica”, corrispondente ad un livello superiore per cui si prevede l’e- rogazione dei servizi di conduzione e assistenza nella settimana lavorativa compreso il sabato mattina con livelli di servizio più severi rispetto al livello precedente. Appartengono a tale livello le applicazioni critiche rispetto alla erogazione diretta di ser- vizi al cittadino e le applicazioni con caratteristica di totale continuità di funzionamento.
45
La classificazione sopra indicata, pur comportando una differenziazione delle applicazioni da realizzare in base a caratteristiche qualitative, non fa ritenere necessaria la richiesta di più istan- ze di fornitura. L’Amministrazione, infatti, non ha indicato in dettaglio i sottosistemi applicativi da realizzare nell’ambito di ciascun obiettivo, sia per la difficoltà di specificare e pianificare a priori gli sviluppi da realizzare nel corso del periodo di durata contrattuale, sia per la volontà di costruire un contratto che le permettesse di gestire in modo flessibile i rapporti con il
Fornitore A, al fine di realizzare gli interventi evolutivi del S.I. previsti nell’ambito dei 14 obiet- tivi individuati secondo le priorità e le esigenze emergenti nel corso del triennio.
In sintesi, la fornitura si configura come acquisizione di prestazioni che saranno realizzate su richiesta dell’Amministrazione e remunerate ad unità di prodotto (Function Point), nel- l’ambito di un massimale contrattuale (13.500 FP per tre anni di durata contrattuale). Ciò richiede, come meglio evidenziato nel seguito, una rigorosa definizione in ambito contrat- tuale delle caratteristiche di qualità attesa e delle modalità di interazione tra Fornitore ed Amministrazione e rende necessario far precedere l’avvio di ciascun progetto di sviluppo da una propedeutica attività di analisi e pianificazione operativa, da sottoporre all’approva- zione dell’Amministrazione (cfr. processo di Gestione).
Oltre a requisiti qualitativi legati alle classi di servizio cui le applicazioni di nuova realizza- zione faranno riferimento e che, come si vedrà nel paragrafo 5.1.4. danno luogo alla defi- nizione di diversi valori soglia per alcuni indicatori di qualità del prodotto, esistono nel caso in esame un insieme di vincoli che è necessario specificare perché sono rilevanti ai fini della definizione di attività e prodotti richiesti al Fornitore e perché possono condizionare le scel- te progettuali: pur lasciando infatti al Fornitore la responsabilità di individuare e attuare la soluzione progettuale che meglio risponde ai requisiti specificati (design autority), aspetto che è particolarmente importante in un appalto concorso, possono esistere vincoli per lo più legati al contesto di riferimento, che necessariamente condizionano le modalità di pro- gettazione e realizzazione della fornitura.
Un vincolo tipico, che è anche molto frequente parlando di forniture per pubbliche Amministrazioni, è la necessità di assicurare la conformità a norme di riferimento. Nel caso in esame, la maggior parte degli interventi di sviluppo deve essere realizzata proprio per consentire all’Amministrazione di essere adempiente a specifiche norme di nuova emana- zione in materia di competenza della stessa Amministrazione; esistono poi norme correla- te alle problematiche gestite con gli interventi di automazione: è il caso x.xx. della norma- tiva in materia di protezione dei dati personali (D. Lgs. 196/2003) che trova applicazione per le tre tipologie di obiettivi, visto che il S.I. dell’Amministrazione tratta dati personali, o della normativa relativa agli standard di accessibilità W3C e alle Direttive governative rela- tive all’uso del dominio “xxx.xx”, che in questo caso trova applicazione per gli obiettivi di tipo C. Al di là della normativa di riferimento per ciascuna tipologia di obiettivi, che non viene nello scenario specificata sia per evitare di individuare una specifica Amministrazione, sia perché non rilevante allo scopo, ciò che è importante è evidenziare la necessità di specificare norme ed articoli delle norme per cui deve essere garantita la con- formità del prodotto finale o dello stesso processo di realizzazione. In linea generale, risul- ta costoso e poco efficiente definire e valutare indicatori di qualità del prodotto che con- sentano di verificare il requisito di conformità ad una norma, e questo è il motivo per cui nel Dizionario non ne vengono proposti: si richiede, invece, salvo casi particolari, la pre- sentazione di una dichiarazione di conformità da parte del Fornitore, che deve essere rila- sciata unitamente alla fornitura, preliminarmente all’avvio delle operazioni di collaudo ed accettazione della fornitura da parte dell’Amministrazione.
46
Altro requisito, che pone un vincolo alle modalità di realizzazione della fornitura, riguarda l’integrazione delle applicazioni di nuova realizzazione nel S.I. esistente, unita alla necessi- tà di preservare la modularità e la scalabilità del S.I, intesa come possibilità di effettuare integrazioni al software e ai moduli applicativi esistenti o di realizzarne di nuovi. Lasciando
al Fornitore la scelta della metodologia di sviluppo più consona ai propri processi produt- tivi, sulla base delle caratteristiche del patrimonio applicativo indicate nel paragrafo 5.1.1 e che dovranno essere dettagliatamente descritte in un allegato al Capitolato, l’Amministrazione dovrà specificare dei requisiti sulla metodologia di sviluppo che, nel caso in esame, potrà prevedere, a seconda delle caratteristiche degli obiettivi da realizzare, tecniche di modellazione tradizionale, object oriented o a componenti.
Altri vincoli alla scelta della metodologia, derivano dall’esigenza, espressa dall’Am- ministrazione, di verificare in corso d’opera l’aderenza dei prodotti realizzandi/realizzati ai requisiti specificati. Si dovrà allora richiedere, x.xx., che per gli obiettivi sviluppati con tec- niche di modellazione tradizionale (tendenzialmente obiettivi di tipo A e di tipo B) dovrà essere garantita, attraverso l’utilizzo di strumenti di ultima generazione, la tracciabilità tra i requisiti formalizzati ed i documenti output della progettazione (specifiche funzionali; spe- cifiche di collaudo), al fine di facilitare la verifica della piena aderenza delle funzionalità svi- luppate ai requisiti. Per gli obiettivi realizzati con metodologia object oriented e a compo- nenti (obiettivi di tipo A ed obiettivi di tipo C) l’esigenza di verificare versioni parziali e/o prototipi dei prodotti comporterà l’impiego di tool di modellazione. In tutti i casi possibili ed in particolare nello sviluppo con tecniche object oriented e a componenti, parlando di applicazioni che dovranno integrarsi in un S.I. esistente, la metodologia dovrà consentire il riuso di moduli software esistenti.
La necessità di preservare il patrimonio informatico dell’Amministrazione, comporta che tutti i prodotti sviluppati dovranno essere testati dal Fornitore A in un ambiente di collaudo che sarà realizzato e gestito dal Fornitore B; l’ambiente di collaudo dovrà essere utilizzato anche dal Fornitore B per verificare, prima del rilascio in esercizio, le modifiche derivanti dalle attività di manutenzione del parco applicativo in esercizio. Da tale requisito risulta necessaria una attività di coordinamento tra i due Fornitori: l’ambiente di collaudo in linea generale, riproduce in modo speculare l’ambiente di esercizio; per consentire l’esecuzione dei test di applicazioni di nuovo sviluppo, l’ambiente di collaudo dovrà essere attrezzato dal Fornitore B secondo le specifiche dettate dal Fornitore A. Il Fornitore B, quindi, dovrà organizzare il sistema di Configuration Management (cfr processo di Gestione della Configurazione) in modo da prevedere e tenere distinti gli ambienti logici di collaudo, manutenzione ed esercizio. Altri elementi di attenzione, che richiedono procedure di coor- dinamento tra i due fornitori, riguardano il rilascio in esercizio delle applicazioni di nuova realizzazione e la manutenzione delle stesse applicazioni che dovrà essere effettuata dal Fornitore A nel periodo di garanzia (12 mesi successivi al rilascio). In entrambi i casi, dai quali derivano modifiche ai componenti in esercizio, il Fornitore B dovrà svolgere specifi- ci test propedeutici all’accettazione in esercizio, tendenti a verificare che i nuovi componen- ti eseguano correttamente le funzioni, come descritto nei manuali, e che non determinino malfunzionamenti nelle altre componenti del S.I.. In tale attività di test il Fornitore B dovrà essere supportato dal Fornitore A, il quale dovrà predisporre e trasferire al Fornitore B tutta la documentazione necessaria affinchè il Fornitore B possa erogare il servizio di gestione (cfr Gestione sistemi – presa in carico di nuovi sistemi/applicazioni) e possa subentrare nella manutenzione delle applicazioni al termine del periodo di garanzia.
47
L’ambiente di sviluppo sarà invece a totale carico del Fornitore A, il quale dovrà provvede- re a rendere disponibili i locali nei quali verranno svolte le attività previste dal contratto, le necessarie dotazioni individuali di attrezzature informatiche per il proprio personale, non-
ché le risorse hardware e software necessarie per lo sviluppo e la memorizzazione delle procedure oggetto del contratto e per l’esecuzione dei test interni. L’ambiente di sviluppo dovrà essere connesso con l’ambiente di esercizio, gestito dal Fornitore B, che pertanto dovrà adottare idonee misure di sicurezza; la connessione sarà messa a disposizione a cura e spesa dell’Amministrazione.
Rispetto alle caratteristiche del S.I. descritte nel precedente paragrafo 5.1.1, il servizio riguarda la gestione dei sistemi centrali, che include servizi in ambito mainframe e servizi in ambito server management e la gestione dei sistemi periferici, che consiste essenzialmen- te in attività di server management. Le tre tipologie di sistemi richiedono diverse attività di gestione, come evidenziato nel successivo paragrafo 5.1.3, e comportano la necessità di specificare tre diverse istanze di fornitura.
Come indicato ai paragrafi 3.3 e 3.4 della classe Gestione Sistemi contenuta nel Dizionario, il modello organizzativo del servizio che si richiede al Fornitore di realizzare e che condiziona gli aspetti legati ai costi, ai rischi ed alla qualità, è funzione di un insieme di vincoli e requisiti.
Nel caso in esame il principale vincolo, che determina la scelta delle risorse da utilizzare per erogare il servizio, è rappresentato dall’architettura hardware e software del S.I., che l’Amministrazione ha da poco rinnovato e non intende modificare nel breve, sia per salva- guardare gli investimenti effettuati, sia per evitare che vi siano soluzioni di continuità nella fase di migrazione verso nuove piattaforme, soprattutto per quel che riguarda i prodotti di middleware sui quali poggiano gli applicativi in esercizio. Il Fornitore B quindi deve pren- dere in carico tutti i sistemi hardware e software presenti a livello centrale ed a livello peri- ferico, dettagliatamente descritti in un allegato al Capitolato, e deve gestire i relativi contrat- ti con i sub-fornitori, aspetto questo che condiziona il servizio di Manutenzione sistemi. Con tale vincolo, ferma restando l’architettura tecnica di base, si lascia comunque alla capacità progettuale del Fornitore la facoltà di amministrare e configurare al meglio le risorse dispo- nibili, eventualmente utilizzando anche ulteriori sistemi hardware e software, quali ad esempio strumenti per la segnalazione automatica di malfunzionamenti, che il Fornitore potrà acquisire per proprio conto, al fine di erogare i servizi nel rispetto dei livelli di qua- lità richiesti; nella condizione su esposta, sarà responsabilità del Fornitore segnalare all’Amministrazione, attraverso il monitoraggio delle prestazioni o all’atto della presa in carico di nuove applicazioni, la necessità di potenziare l’infrastruttura hardware e software. Altri elementi essenziali per consentire al Fornitore la formulazione dell’offerta tecnico econo- mica riguardano l’ubicazione e la proprietà dei sistemi da gestire. Per quanto riguarda l’ubica- zione dei sistemi, tutti i sistemi centrali e periferici sono ubicati in locali dell’Amministrazione e quindi non è richiesto al Fornitore di rendere disponibili propri locali.
48
L’Amministrazione intende poi mantenere la proprietà di tutto il software in suo possesso già in esercizio o già acquistato nel periodo antecedente alla erogazione dei servizi di out- sourcing da parte del Fornitore; per il nuovo software che eventualmente si renderà neces- sario installare sui sistemi, il Fornitore potrà acquistare per proprio conto e sarà proprieta- rio di tutto il software d’ambiente del tipo sistemi/ambienti operativi necessario a miglio- rare l’erogazione dei servizi; ogni altro software di ambiente a supporto degli applicativi o qualsiasi ulteriore software il Fornitore intenda installare sui sistemi dovrà essere preventi- vamente concordato con l’Amministrazione che provvederà ad acquisirlo, ne manterrà la
proprietà e metterà a disposizione del Fornitore le licenze d’uso. Analogamente, l’Amministrazione intende mantenere la proprietà di tutto l’hardware in suo possesso già in esercizio o già acquistato nel periodo antecedente alla erogazione dei servizi di outsour- cing da parte del Fornitore; il Fornitore è tenuto all’ acquisto, noleggio e manutenzione di eventuali prodotti hardware necessari al perseguimento dei livelli di servizio previsti.
Per la finestra di disponibilità dei sistemi e dei servizi, vale la classificazione nelle classi di servizio, critica e non critica, indicata nel precedente paragrafo relativo a Sviluppo e MEV di software ad hoc.
Sono inoltre rilevanti ai fini dell’organizzazione dei servizi le interazioni con altri Fornitori, in termini di dipendenze e di responsabilità. Nel caso in esame, parlando di gestione dei sistemi, oltre a dover governare, per conto dell’Amministrazione, i contratti con i sub-forni- tori responsabili della manutenzione delle apparecchiature e del software, il Fornitore B deve gestire i rapporti con i fornitori RUPA, responsabili degli aspetti connessi ai servizi di rete e con il Fornitore A, responsabile di curare il roll-out iniziale nell’ambiente d’esercizio e la manutenzione in garanzia delle nuove applicazioni e di specificare la configurazione dell’ambiente di collaudo per l’esecuzione dei test delle nuove applicazioni.
La manutenzione dei sistemi è strettamente connessa alla gestione dei sistemi; nel Dizionario delle Forniture ICT è presente come Classe di fornitura distinta dalla gestione non con l’intento di separare le due forniture, che è invece buona norma affidare ad uno stesso fornitore, quanto con lo scopo di isolare un servizio che generalmente vede coinvol- ti una pluralità di sub-fornitori e che richiede da parte del Fornitore B, responsabile del con- tratto con l’Amministrazione, una adeguata regolamentazione nell’ambito della gestione dei rapporti con ciascun sub-fornitore degli aspetti che possono influenzare i livelli di qualità dei servizi contrattualizzati con l’Amministrazione.
Nello scenario in esame non si ritiene necessario specificare diverse istanze di fornitura, visto che il servizio si attua attraverso interventi di prevenzione e di rimozione di malfunzionamen- ti (sostituzioni di componenti hw, installazione di patches, ecc.) che non variano con le carat- teristiche (mainframe, server) o con la dislocazione (ambito centralizzato o distribuito) dei sistemi, pur essendo richiesti livelli di servizio diversi in funzione delle classi di servizio, critica e non critica, descritte nel paragrafo “Sviluppo e Mev di software ad hoc”.
La classe eredita i vincoli ed i requisiti indicati nella gestione dei sistemi. Sono inoltre ele- menti caratterizzanti ed influenzano l’organizzazione del servizio l’eterogeneità dei sistemi, che impone al fornitore l’utilizzo di idonee risorse per la diagnosi dei problemi, e la dislo- cazione dei sistemi presso locali dell’Amministrazione sparsi su tutto il territorio nazionale, che costituisce un vincolo funzionale soprattutto perché pone limitazioni nella possibilità di accesso ai locali per l’esecuzione del servizio e richiede la presenza di referenti tecnici dell’Amministrazione per consentire l’intervento di ripristino delle funzionalità.
Manutenzione adeguativa e correttiva
49
Il servizio riguarda la manutenzione del parco applicativo in esercizio. Ad inizio fornitura il Fornitore B prende in carico il software ed i relativi documenti che rappresentano la defi- nizione del patrimonio applicativo in esercizio alla data, nella configurazione risultante da opportuni documenti predisposti dal Fornitore uscente (configurazione di base). Il servizio
riguarda inoltre la manutenzione delle applicazioni di nuova realizzazione, sviluppate dal Fornitore A, successivamente alla scadenza del periodo di garanzia, nel corso del quale la manutenzione è a carico del Fornitore A.
Gli aspetti rilevanti ai fini della organizzazione del servizio e che influenzano in particolare la scelta delle risorse necessarie per prestare il servizio, derivano dalle caratteristiche del patrimonio applicativo, consistente in software sviluppato ad hoc con metodologie tradizio- nali e/o object oriented. Nel caso in esame è critico l’aspetto che riguarda la disponibilità di informazioni per la erogazione del servizio: il Fornitore B subentra nella manutenzione di applicazioni realizzate e gestite per anni da uno stesso Fornitore, quindi ha necessità di disporre della documentazione di riferimento, oltre che del codice sorgente, e meglio anco- ra di usufruire di un periodo di affiancamento da parte del fornitore uscente. In ogni caso, comunque, la qualità del servizio sarà influenzata dalle caratteristiche qualitative delle applicazioni prese in carico, quali il grado di manutenibilità delle applicazioni ed il livello di documentazione del codice.
Per garantire continuità con il pregresso, i servizi di manutenzione degli applicativi dovran- no specializzarsi in servizi di manutenzione correttiva e servizi di manutenzione adeguati- va e migliorativa. I primi sono volti alla diagnosi e rimozione delle cause e degli effetti dei malfunzionamenti delle procedure e dei programmi; i secondi sono volti ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell’ambiente del S.I.. La manutenzione correttiva, a differenza della manutenzione adeguativa e migliorativa, segue una modalità di erogazione di tipo continuativo ed è, in linea di massima, non piani- ficabile essendo orientata alla rimozione di difetti causati dal software stesso. Per tale carat- teristica il servizio di manutenzione correttiva è retribuito attraverso la corresponsione di un canone fisso, commisurato alle dimensioni del patrimonio applicativo in esercizio (circa
45.000 FP); per la manutenzione adeguativa e migliorativa, il corrispettivo è determinato sulla base dei FP movimentati in ciascun periodo di riferimento.
Per quanto riguarda i requisiti di qualità, la definizione dei livelli di servizio deriva dalla classificazione delle applicazioni secondo classi di servizio, critica e non critica, definite nel paragrafo “Sviluppo e Mev di software ad hoc”.
Nello scenario in esame, che si caratterizza principalmente per la separazione delle attività di sviluppo e di gestione e manutenzione applicativa tra due fornitori diversi, il processo di gestione delle configurazioni assume una rilevanza notevole perché sia assicurata nel tempo la conoscenza, la completezza l’integrità e la consistenza del patrimonio applicativo dell’Amministrazione.
50
Il processo è parte integrante di ciascuna delle Classi di fornitura di interesse per l’Amministrazione precedentemente descritte, pur assumendo una valenza diversa in fun- zione della tipologia di fornitura. Ad inizio fornitura entrambi i fornitori prendono in cari- co le applicazioni, con la documentazione associata, in esercizio alla data, nella configura- zione risultante da opportuni documenti predisposti dal Fornitore uscente (configurazione di base). Le modifiche alla configurazione di base delle applicazioni, che determineranno la configurazione corrente, potranno derivare sia dalle attività del Fornitore A, nell’ambito dello Sviluppo e Mev di software ad hoc, sia dalle attività del Fornitore B, nell’ambito della Manutenzione adeguativa e correttiva. La configurazione corrente, rappresentando lo stato
di costruzione delle applicazioni in esercizio ad una data, dovrà essere controllata dal Fornitore B, attraverso la gestione di un registro di configurazione e l’applicazione di pro- cedure, concordate con il Fornitore A, per il rilascio in esercizio del nuovo software.
In particolare, per preservare l’integrità del patrimonio applicativo, oltre all’ambiente di svi- luppo, che sarà realizzato e gestito interamente dal Fornitore A, è necessario prevedere gli ambienti logici di collaudo, manutenzione ed esercizio, che saranno realizzati e gestiti dal Fornitore B. L’ambiente di collaudo sarà utilizzato sia dal Fornitore A, per verificare le nuove applicazioni, sia dal Fornitore B per verificare le applicazioni modificate a seguito delle attività di manutenzione.
Per la Gestione dei sistemi, a carico del Fornitore B, il processo di gestione della configura- zione è rilevante per registrare e gestire i cambiamenti alla configurazione di base ed alla configurazione corrente dei sistemi presi in carico ad inizio fornitura, a seguito degli inter- venti di manutenzione; risulta inoltre per il Fornitore B, oltre che un processo di supporto alla gestione dei sistemi, una istanza di fornitura, visto che l’Amministrazione ha espressa- mente richiesto, sia in ambito centrale che in ambito distribuito, un servizio di asset mana- gement, finalizzato a mantenere un inventario centralizzato, accessibile al personale dell’Amministrazione, dell’installato hardware e software sui sistemi centrali e periferici. Nel Dizionario delle forniture ICT tale servizio è trattato attraverso il processo di gestione delle configurazioni.
Oltre a regolare le attività svolte da ciascun fornitore, il processo di gestione consente all’Amministrazione di avere a disposizione gli strumenti necessari per esercitare il governo dei contratti e per coordinare le attività tra il Fornitore A ed il Fornitore B.
Nei confronti del Fornitore A, il processo di gestione deve regolamentare le modalità di pia- nificazione, realizzazione e consuntivazione dei sottosistemi applicativi riguardanti i singo- li obiettivi. Come evidenziato nella descrizione della classe Sviluppo e Mev di software ad hoc, in presenza di una fornitura che, per volontà dell’Amministrazione, si configura come acquisizione di prestazioni remunerate a unità di prodotto, è necessario che l’esecuzione di ciascun progetto di sviluppo sia preceduta da una accurata pianificazione, che specifichi le caratteristiche del sottosistema da realizzare, in termini di tempi previsti, dimensioni stima- te, deliverables e modalità di rilascio e da una coerente consuntivazione. Attraverso i pro- dotti delle attività di pianificazione e controllo del progetto, descritti nel Dizionario delle forniture e personalizzati come indicato nel successivo paragrafo 1.1.3, l’Amministrazione può avere gli strumenti per autorizzare o meno lo sviluppo dei singoli sottosistemi, defini- re e cambiare le priorità di sviluppo, verificare i dati di consuntivo ed autorizzare i relativi pagamenti. Gli stessi strumenti consentono di fasare le attività di competenza del Fornitore A e del Fornitore B, propedeutiche al rilascio in esercizio di nuove applicazioni.
Per il Fornitore B il processo di gestione si dovrà specializzare principalmente per quegli aspetti che riguardano, oltre che la pianificazione della qualità dei servizi, l’organizzazione delle risorse necessarie allo svolgimento delle attività previste dal contratto.
5.1.3 Individuazione delle attività e dei prodotti
51
Con riferimento alle attività ed ai prodotti descritti nel Dizionario delle forniture ICT si indica- no di seguito le attività ed i prodotti di interesse per ciascuna Classe di fornitura e processo
selezionati nel precedente paragrafo 5.1.2. Per la completa descrizione di attività e prodotti, si rimanda al Dizionario; nei paragrafi che seguono si pone l’attenzione su aspetti connessi alle specificità derivanti dal contesto di riferimento e dalle esigenze dell’Amministrazione.
Sviluppo e MEV di software ad hoc
Per ciascun intervento realizzativo/modificativo delle funzionalità del S.I., il Fornitore dovrà svolgere un insieme di attività e consegnare all’Amministrazione, contestualmente alla con- clusione di ciascuna attività, i relativi prodotti.
Le attività e i prodotti che caratterizzano il servizio di sviluppo e manutenzione evolutiva di software di tipo “custom”, sono descritti nel Dizionario delle forniture ICT – Sviluppo e MEV di software ad hoc – paragrafo 5.
Le specificità del caso in esame, derivanti per lo più dal contesto di riferimento e dai vinco- li e requisiti evidenziati nel precedente paragrafo 5.1.2 , rendono necessario in alcuni casi personalizzare e/o modificare le descrizioni proposte, come evidenziato nel seguito. Per quanto non citato, si rimanda alla descrizione presente nel Dizionario. Ovviamente quanto esposto vale per la realizzazione di obiettivi di rilevante entità, ovvero che sviluppano nuovi sottosistemi applicativi o modificano considerevolmente funzionalità esistenti, com- portando quindi modifiche all’architettura applicativa e funzionale del S.I..
Per consentire all’Amministrazione un più agevole controllo su quanto realizzato dal Fornitore A, visto che le attività di sviluppo e MEV sono pianificate di volta in volta attraverso il Piano di progetto e remunerate a unità di prodotto, è utile richiedere che nella Progettazione tecnica sia esplicitata, nell’ambito delle Specifiche funzionali, la descrizione delle azioni di mo- difica/implementazione del sistema necessarie a soddisfare i requisiti, con l’indicazione delle funzionalità interessate e dei moduli software da modificare/creare. Per le stesse ragioni, come prodotto della Realizzazione codifica, è utile richiedere un elenco dei moduli software realiz- zati e/o modificati ed un Report di conteggio dei FP, che contenga la descrizione dei parame- tri di riferimento utilizzati per la quantificazione dell’intervento. L’Amministrazione, come spe- cificato nel paragrafo 5.1.2, è interessata a verificare Prototipi in tutti i casi in cui la metodolo- gia di sviluppo adottata dal Fornitore in funzione delle caratteristiche dell’obiettivo da realizza- re lo consenta, al fine di verificare che il prodotto in fase di sviluppo soddisfi i requisiti.
A fronte dell’esigenza di verificare il requisito di conformità a norme, va richiesta, a valle della Qualificazione finale, la produzione di una Dichiarazione di conformità, nella quale il Fornitore attesti che quanto progettato e realizzato sia conforme alla norma presa a riferimento.
Visto che l’ambiente di collaudo dovrà essere predisposto dal Fornitore B, è utile estrapo- lare le specifiche dell’ambiente di collaudo dal documento Specifiche di collaudo ed inse- rirle in un documento ad hoc. La Realizzazione installazione, dovrà prevedere l’installazio- ne del prodotto, a cura del Fornitore B con il supporto del Fornitore A, solo nell’ambiente di collaudo; l’installazione del prodotto nell’ambiente di esercizio deve essere effettuata a valle del collaudo, ad inizio del periodo di avviamento (Diffusione e garanzia), periodo della durata di 12 mesi in cui il Fornitore A è responsabile di assicurare la manutenzione in garanzia e l’assistenza al Fornitore B per l’esercizio del prodotto di nuovo sviluppo. Per i motivi indicati, l’attività di Predisposizione del sistema non è significativa.
52
A completamento della Realizzazione del collaudo, più che il Verbale di collaudo che non è un prodotto richiesto al Fornitore B, visto che l’Amministrazione intende far eseguire i colludi delle nuove applicazioni da un apposita Commissione, è necessario esplicitare che viene rilasciato il
prodotto software nella configurazione finale risultante dal collaudo, dal momento che detta configurazione determina la “configurazione di base” del prodotto per cui vengono avviati l’eser- cizio da parte del Fornitore B e la manutenzione in garanzia da parte del Fornitore A; è inoltre utile richiedere l’elenco dei moduli software realizzati e/o modificati ed il Rapporto di riepilogo aggiornato, se variati rispetto a quelli consegnati a fine realizzazione, oltre ai documenti descrit- tivi dell’architettura applicativa e tecnica del S.I. aggiornati.
Le attività e i prodotti che caratterizzano il servizio di gestione dei sistemi, sono descritti nel Dizionario delle forniture ICT – Gestione sistemi – paragrafo 5.
La caratteristica principale che guida nella scelta e personalizzazione delle attività e dei prodot- ti, è che l’infrastruttura hardware e software che ospita il S.I. è di proprietà dell’Am- ministrazione: al Fornitore è richiesto di gestire detta infrastruttura nel rispetto dei livelli di qua- lità definiti dall’Amministrazione, impiegando i mezzi e le modalità più idonei per prestare il servizio nel rispetto dei requisiti contrattuali. Come prodotto della Progettazione tecnica, è utile richiedere anche le Specifiche di controllo qualità, con le quali l’Amministrazione ha la possi- bilità di verificare procedure e strumenti definiti dal Fornitore B per assicurare che il servizio sia erogato secondo le specifiche del servizio e nel rispetto dei livelli di qualità contrattuali. Le attività relative al collaudo (Progettazione collaudo e Realizzazione collaudo), riguardano per lo più il modello di funzionamento del servizio e sono volte ad accertare che quanto predispo- sto dal Fornitore, in termini di mezzi e procedure, consenta l’erogazione del servizio. Tali con- siderazioni valgono in linea generale anche per gli altri servizi di Manutenzione sistemi e di Manutenzione adeguativa e correttiva.
Particolare rilevanza nel caso in esame ha l’attività di Presa in carico di nuovi sistemi/appli- cazioni, che il Fornitore B deve svolgere ad inizio fornitura per subentrare al fornitore uscente e nel corso della esecuzione del contratto, ogni volta che il Fornitore A rilasci in esercizio nuovi sottosistemi applicativi.
Nello scenario in esame si possono definire tre istanze di fornitura, corrispondenti rispetti- vamente alla realizzazione dei servizi di gestione in ambito centralizzato, mainframe e ser- ver management, e in ambito periferico. In particolare, con riferimento alle attività trattate nel Dizionario, sono richieste le seguenti attività:
a) Gestione dei sistemi centrali – ambito mainframe
• Gestione operativa delle malfunzioni HW e SW
• Gestione operativa della Schedulazione
• Conduzione operativa e monitoraggio (Backup del sistema di base; Gestione dei sistemi on-line; Change management; Esecuzione delle procedure batch; Gestione dell’output; Distribuzione dell’output; Report management; User management)
• Gestione operativa dello storage (Gestione dei supporti magnetici; Gestione dello spazio su disco)
b) Gestione dei sistemi centrali – ambito server management
53
• Gestione operativa delle malfunzioni HW e SW
• Gestione operativa delle prestazioni
• Conduzione operativa e monitoraggio (Configurazione ed Amministrazione dei ser- ver; Monitoring e fault management dei server; Change management; Software distribution; Gestione stampe centralizzate; User management)
• Gestione operativa dello storage (Backup & Restore; Ripristino dati)
c) Gestione dei sistemi periferici
• Gestione operativa delle malfunzioni HW e SW
• Conduzione operativa e monitoraggio (Installazione, Movimentazione, Aggiunte, Cambiamenti (IMAC); Configurazione ed Amministrazione dei server; Monitoring e fault management dei server; Change Management; Software distribution; User/resource management)
• Gestione operativa dello storage (Backup & Restore; Ripristino dati)
L’attività di Conduzione operativa e monitoraggio include sottoattività specifiche di ciascu- na istanza e va personalizzata coerentemente; in aggiunta è necessario un maggior detta- glio per le attività di Software distribution e di Change Management, rispetto a quanto con- tenuto nel Dizionario.
Le attività e i prodotti che caratterizzano il servizio di manutenzione dei sistemi, sono descritti nel Dizionario delle forniture ICT – Manutenzioni sistemi – paragrafo 5.
La manutenzione riguarda tutte le apparecchiature hardware impiegate a livello centrale ed a livello periferico ed oggetto dei servizi di gestione e include l’aggiornamento del software stan- dard e dei sistemi/ambienti operativi; per l’erogazione del servizio il Fornitore B dovrà pren- dere in carico e gestire i contratti con i sub-fornitori. Dati i vincoli derivanti dai contratti in esse- re con i sub-fornitori, dalle classi di servizio definite dall’Amministrazione e dalle caratteristiche degli apparati hardware e software da gestire, l’Analisi dei requisiti e la Progettazione tecnica servono per lo più al Fornitore per organizzare il servizio, nel rispetto dei livelli di servizio con- trattualizzati con l’Amministrazione. Sono espressamente richieste dall’Amministrazione le atti- vità di Manutenzione preventiva, di Manutenzione correttiva e di Gestione della chiamata, atti- vità questa che include l’attivazione dei sub-fornitori per gli interventi tecnici volti al ripristino del corretto funzionamento dei sistemi. Tra i prodotti, è rilevante il Piano di servizio, come stru- mento attraverso il quale l’Amministrazione può autorizzare la sostituzione di apparecchiature obsolete e l’aggiornamento del software sopra indicato. È da prevedere l’emissione di un docu- mento di aggiornamento dell’architettura tecnica a fronte di modifiche consistenti derivanti dalle attività del servizio; dette modifiche devono infatti essere rese note al Fornitore A, respon- sabile della progettazione dei nuovi applicativi.
Manutenzione adeguativa e correttiva
54
Al pari dei servizi di gestione e dei servizi di manutenzione sistemi, per la predisposizione del servizio di Manutenzione adeguativa e correttiva sono necessarie tutte le attività che caratterizzano il ciclo di vita del servizio; le attività di analisi dei requisiti e di progettazione portano a definire il modello di funzionamento del servizio che sarà oggetto di collaudo da parte dell’Amministrazione. Tra le attività ed i prodotti indicati nel Dizionario delle fornitu- re ICT – Manutenzione adeguativa e correttiva – paragrafo 5, particolare rilevanza ha il
Piano delle modifiche, con il quale si forniscono all’Amministrazione elementi per valutare l’impatto dei singoli interventi di manutenzione adeguativa e migliorativa; per consentire all’Amministrazione di dare seguito al pagamento dei corrispettivi è necessario un rappor- to di riepilogo, Rapporto delle attività di manutenzione, in cui gli interventi eseguiti sono classificati in base alla tipologia e con l’indicazione dei FP movimentati nel caso di manu- tenzione adeguativa e migliorativa. Come prodotto dell’attività di Attuazione delle modifi- che, sono rilevanti nell’ambito della gestione dei rapporti con il Fornitore A, la documenta- zione del software e l’inventario dei moduli software aggiornati.
Le attività e i prodotti che caratterizzano il servizio, sono descritti nel Dizionario delle for- niture ICT – Gestione della Configurazione – paragrafo 5.
Per il Fornitore A, la gestione delle configurazioni è parte integrante del processo di svilup- po del software: può essere di interesse per l’Amministrazione ed eventualmente inserito come deliverable contrattuale il Piano di gestione della Configurazione.
Il Fornitore B deve invece garantire, nell’ambito della gestione dei sistemi, un servizio di asset management per i sistemi centrali e per i sistemi periferici, con l’obiettivo di mantene- re un inventario centralizzato relativo all’installato hardware e software. In tal senso sono richieste tutte le attività proprie del processo di gestione delle configurazioni: il Fornitore dovrà realizzare un Sistema di gestione dell’inventario, che sarà oggetto di collaudo da parte dell’Amministrazione. Il Fornitore dovrà inoltre svolgere le attività di Controllo e di Audit finalizzate a garantire il costante mantenimento e aggiornamento delle informazioni relative all’installato.
Tutte le attività previste nella descrizione del processo sono inoltre rilevanti a supporto dei servizi di manutenzione adeguativa e correttiva, per i quali è richiesto che il Fornitore pre- disponga un sistema di gestione delle configurazioni che consenta di definire e tenere sepa- rati gli ambienti logici di collaudo, esercizio e manutenzione e di gestire i cambiamenti di configurazione ai prodotti software in esercizio derivanti sia dalla manutenzione adeguati- va e correttiva che dal rilascio in esercizio di nuovi applicativi. Il sistema dovrà essere ogget- to di collaudo da parte dell’Amministrazione.
Le attività e i prodotti che caratterizzano il servizio, sono descritti nel Dizionario delle for- niture ICT – Gestione – paragrafo 5.
55
Tra le attività indicate, va caratterizzata la Pianificazione del progetto che deve essere effet- tuata dal Fornitore A: vista la necessità di definire volta per volta in dettaglio gli obiettivi di sviluppo da realizzare nel corso del contratto, nell’ambito di un massimale contrattuale, il Piano di progetto dovrà indicare la pianificazione a finire di tutte le attività contrattuali, con l’indicazione delle attività di sviluppo di nuovi obiettivi e di manutenzione evolutiva, l’indi- cazione delle fasi, dei deliverable, dei tempi previsti, e delle dimensioni pianificate in Function Point per ciascun obiettivo. Per consentire all’Amministrazione di dare seguito al pagamento dei corrispettivi per gli obiettivi di sviluppo completati, ciascun Piano di proget- to dovrà essere seguito da un documento di rendicontazione, Rapporto di riepilogo, che contenga i dati dimensionali effettivi delle attività di sviluppo e Mev eseguite rispetto ai valori stimati ed approvati dall’Amministrazione.
Nella gestione dei rapporti con il Fornitore B, il Piano di progetto si specializza nel Piano di servizio, in cui sono definiti organizzazione, tempi, modi per la conduzione di attività di gestione sistemi, manutenzione sistemi, manutenzione adeguativa e correttiva, che richie- dono l’approvazione dell’Amministrazione.
5.1.4 Selezione indicatori di qualità e definizione valori soglia
Agli indicatori di qualità sono collegate le azioni contrattuali di tutela per l’Amministrazione, di cui l’applicazione di penalità costituisce l’esempio più ricorrente. La scelta degli indica- tori e la determinazione dei relativi valori soglia, deve essere effettuata per quelle caratteri- stiche del servizio che si ritengono critiche per il perseguimento degli obiettivi del proget- to e/o per le quali eventuali inadempienze del Fornitore comporterebbero danni all’Amministrazione. Indicatori, valori soglia e corrispondenti azioni contrattuali devono essere commisurati al valore del servizio e più in generale, del contratto.
Nello scenario in esame si suppone che la misurazione dei livelli di qualità e la presenta- zione dei relativi documenti di rendicontazione sia effettuata con cadenza trimestrale. Ciascun Fornitore dovrà farsi carico di realizzare un sistema di misura dei livelli di qualità, inteso come insieme di strumenti hardware e software, procedure e quanto altro necessa- rio per effettuare le misurazioni richieste.
Nel seguito si evidenziano, distintamente per i servizi da affidare al Fornitore A ed al Fornitore B, gli indicatori di qualità che si ritengono rilevanti rispetto alle esigenze presen- tate nei paragrafi precedenti.
Servizi da affidare al fornitore A
I principali prodotti che servono all’Amministrazione per governare le attività di Sviluppo e Mev di software, sono il Piano di progetto, con il quale si autorizzano tempi e modi di rea- lizzazione di ciascun obiettivo di sviluppo e il Rapporto di Riepilogo, con il quale l’Amministrazione dà seguito al pagamento dei corrispettivi sulla base dei dati di consunti- vo effettivi presentati dal Fornitore e previa applicazione di penali per eventuali inadem- pienze riscontrate.
Fissando nel contratto tempi e modi di presentazione di detti documenti, è significativo l’in- dicatore RSC – Rispetto della scadenza contrattuale, relativo alla tempestività di consegna di ciascun Piano di progetto e Rapporto di Riepilogo.
56
Per quanto riguarda il prodotto software realizzato, oltre che alla tempestività di rilascio, è essenziale l’indicatore DIM1 – Dimensioni in FP, che dovrà essere valorizzato nel Rapporto di Riepilogo per consentire il pagamento dei corrispettivi rispetto alle dimensioni effettive degli obiettivi sviluppati; visto poi che le applicazioni di nuova realizzazione, al pari delle applica- zioni in esercizio, presentano caratteristiche di criticità più o meno elevata rispetto alla eroga- zione diretta dei servizi ai cittadini, è significativo l’indicatore NDIF – Difettosità delle applica- zioni che consente all’Amministrazione di tenere sotto controllo l’affidabilità delle nuove appli- cazioni rilasciate in esercizio, monitorando il tasso di errori rilevato con cadenza periodica (nel caso in esame trimestrale), sulle applicazioni misurate in FP. Dal momento che allo scadere del periodo di garanzia la manutenzione applicativa sarà a carico del Fornitore B, sono particolar- mente importanti gli indicatori di Manutenibilità/Modificabilità, COC - Complessità ciclomatica e LDO – Livello di documentazione, che andranno valorizzati per ogni modulo di nuova rea- lizzazione. Riepilogando, con riferimento agli indicatori proposti nel Dizionario per la Classe
di fornitura Sviluppo e Mev di software ad hoc e per i processi di Gestione e Gestione delle configurazioni, ai quali si rimanda per ogni dettaglio circa le modalità di valorizzazione delle misure, sono particolarmente significativi i seguenti indicatori, per i quali si indicano corrispon- dentemente i valori soglia.
a) Dimensioni delle applicazioni di nuova realizzazione.
Indicatore | Descrizione | Valore soglia |
DIM1 | Dimensioni in FP | Massimale stimato dal Fornitore nel Piano di progetto approvato dall’Amministrazione |
b) Affidabilità/Maturità delle applicazioni software di nuova realizzazione.
NDIF – Difettosità
Livello GRAVITÀ | Descrizione | Valore soglia | |
Classe di servizio critica | Classe di servizio non critica | ||
1 | Consistenti disservizi, gravi danni di immagine | 0,1% | 0,5% |
2 | Interruzioni del servizio con conseguenti danni di immagine | 0,5 % | 1% |
3 | Disservizi moderati | 1% | 2% |
4 | Disservizi lievi e facilmente recuperabili | 2,5% | 5% |
c) Manutenibilità/Modificabilità dei moduli software di nuova realizzazione.
Indicatore | Descrizione | Valore soglia |
COC | Complessità ciclomatica | < 21% |
LDO | Livello di documentazione | > 25% |
d) Efficienza temporale nella presentazione dei documenti contrattuali che consentono all’Amministrazione il governo del contratto.
Indicatore | Descrizione | Valore soglia |
RSC | Tempestività di presentazione del Piano di proget- to e del Rapporto di riepilogo | Entro la data indicata nel contratto |
Indicatore | Descrizione | Valore soglia |
RSC1 | Tempestività di presentazione della dichiarazione di pronti al collaudo per ciascuna applicazione | Entro la data indicata nel Piano di progetto appro- vato dall’Amministrazione |
e) Efficienza temporale nella presentazione al collaudo degli obiettivi di sviluppo.
57
Servizi da affidare al fornitore B
Con ragionamenti analoghi a quelli presentati per definire gli indicatori di interesse nella gestione dei rapporti con il Fornitore A, si possono individuare gli indicatori di qualità mag- giormente significativi per il governo del contratto con il Fornitore B. L’attività più onerosa nel- l’ambito della gestione dei sistemi è senza dubbio la conduzione operativa, che si specializza in funzione della tipologia di sistemi e dell’ambito di erogazione del servizio. In tal senso, l’in- dicatore CASS – Corretta esecuzione delle attività, dovrà essere valorizzato considerando tutte le attività di conduzione operativa che caratterizzano ciascuna tipologia/ambito di erogazione del servizio (corretta esecuzione delle operazioni di backup; corretta esecuzione delle proce- dure batch; corretta esecuzione delle operazioni di software distribution; ecc. ).
Vista la presenza di sistemi/applicazioni critiche rispetto alla erogazione di servizi agli uten- ti e/o che richiedono totale continuità di funzionamento, sono rilevanti gli indicatori di disponibilità dei sistemi e di efficienza nella risoluzione dei problemi, sia per quanto riguar- da le applicazioni che per quanto riguarda le componenti hardware e software di base. Per questi ultimi, data la distribuzione degli apparati su tutto il territorio nazionale, sono impor- tanti la tempestività di attivazione dei subfornitori, che implicitamente dà indicazioni anche sulla tempestività di rilevazione di ciascun problema da parte del Fornitore B, e la tempe- stività di ripristino del funzionamento, misurata a partire dal tempo di intervento.
In sintesi, con riferimento agli indicatori proposti nel Dizionario per le Classi di fornitura Gestione sistemi, Manutenzione sistemi, Manutenzione correttiva e adeguativa e per i pro- cessi di Gestione e Gestione della configurazione, ai quali si rimanda per ogni dettaglio circa le modalità di valorizzazione delle misure, sono particolarmente significativi i seguen- ti indicatori, per i quali si indicano corrispondentemente i valori soglia.
a) Funzionalità ed affidabilità della conduzione operativa e monitoraggio.
Indicatore | Descrizione | Valore soglia | |
CASS | Corretta esecuzione delle attività | ≥ 99 | |
DIS1 | Disponibilità dei sistemi | Classe di servizio critica | Classe di servizio non critica |
≥ 99,9% | ≥ 99,9% |
b) Efficienza nella manutenzione dei sistemi hardware e software.
Indicatore | Descrizione | Valore soglia | |
Classe di servizio critica(1) | Classe di servizio non critica | ||
TASF(2) | Tempestività di attivazione sub-fornitori | Entro 30’ nel 100% dei casi | Entro 1 ora nel 100% dei casi |
TRFC | Tempestività ripristino corretto funzionamento | Entro 4 ore da inizio intervento nel 100% dei casi | Entro 8 ore da inizio intervento nel 100% dei casi |
58
(1) Alla classe di servizio critica appartengono i “Problemi bloccanti”, ovvero guasti che impediscono l’eserci- zio di applicazioni che rientrano nella classe di servizio critica o che impediscono totalmente l’uso dello strumento (hardware; software di base; pacchetto di mercato)
(2) L’indicatore non è presente nel Dizionario. È calcolato come differenza tra tempo di attivazione, risultante da apposite Registrazioni mantenute dal Fornitore ed il tempo di rilevamento del problema.
c) Efficienza e funzionalità nella manutenzione del parco applicativo esistente.
RTRP – Rispetto dei tempi di risoluzione del problema
Tipologia manutenzione | Livello GRAVITÀ | Valore soglia | |
Classe di servizio critica | Classe di servizio non critica | ||
Correttiva | 1 | 4 ore nel 96% dei casi, entro 12 ore nel restante 4% | 8 ore nel 96% dei casi, entro 20 ore nel restante 4% |
2 | 12 ore nel 96% dei casi, entro 24 ore nel restante 4% | 16 ore nel 96% dei casi, entro 30 ore nel restante 4% | |
3 | 24 ore nel 96% dei casi, entro 64 ore nel restante 4% | 32 ore nel 96% dei casi, entro 72 ore nel restante 4% | |
4 | 64 ore nel 96% dei casi, entro 88 ore nel restante 4% | 64 ore nel 96% dei casi, entro 128 ore nel restante 4% | |
Adeguativa e migliorativa | Qualsiasi | 12 giorni nel 96% dei casi, 24 nel restante 2% | 20 giorni nel 96% dei casi, 36 nel restante 2% |
d) Efficienza nella presa in carico del sistema.
Indicatore | Descrizione | Valore soglia |
RSC | Disponibilità sistema di gestione delle configurazioni | Entro la data contrattuale di presentazione al collaudo |
RSC | Disponibilità del sistema per la gestione dell’inventario | Entro la data contrattuale di presentazione al collaudo |
5.1.5 Modulazione delle penali
Per la modulazione delle penali è necessario prendere in considerazione le modalità di tariffazione e pagamento dei servizi. Di seguito si presentano, distintamente per i contratti da stipulare con il Fornitore A e con il Fornitore B, i criteri adottati dall’Amministrazione per valorizzare i servizi e si definiscono le penali da applicare a fronte del superamento dei valori soglia, per gli indicatori descritti nel paragrafo precedente.
Contratto con il fornitore A – Valorizzazione e pagamento dei servizi
Per il contratto da stipulare con il Fornitore A, l’Amministrazione ha stimato un importo complessivo massimo, in tre anni, di circa 6 milioni di Euro oltre IVA.
Come già detto, la valorizzazione dello Sviluppo e Mev di software ad hoc è effettuata applicando come unità di misura il Function Point; l’Amministrazione ha stimato un’esi- genza di sviluppo di 13.500 FP nei tre anni di contratto. Ha inoltre stabilito un mix di ambienti di sviluppo (Java, ASP/Visual Basic, Terza generazione, SQL rispettivamente per 40%, 40%, 15%, 5%) sulla base del quale richiedere ai fornitori il prezzo unitario per FP ed ha definito dei parametri di aggiustamento del costo per FP in relazione all’am- biente utilizzato.
59
Il pagamento dei corrispettivi è effettuato sulla base dei FP effettivi, conteggiati a con- suntivo dal Fornitore tenendo conto dei parametri di aggiustamento relativi all’ambien- te utilizzato e nell’ambito di un massimale stimato dal Fornitore ed autorizzato dall’Amministrazione, attraverso l’approvazione del Piano di progetto.
Contratto con il fornitore A – Penali
Con riferimento agli indicatori definiti per i servizi da affidare al Fornitore A, si definiscono le seguenti penali.
a) Affidabilità/maturità delle applicazioni di nuova realizzazione
• NDIF – Difettosità: per applicazioni appartenenti alla classe di servizio critica, per ogni decimo di punto percentuale in più rispetto ai valori soglia indicati in corrispondenza dei livelli di gravità 1, 2, 3, 4 si applica una penale pari all’1% del valore contrattuale dell’applicazione;
• NDIF – Difettosità: per applicazioni appartenenti alla classe di servizio non critica, per ogni decimo di punto percentuale in più rispetto ai valori soglia indicati si applica una penale pari all’1% del valore contrattuale dell’applicazione per i livelli di gravità 1, 2, e pari allo 0,5% del valore contrattuale dell’applicazione per i livel- li di gravità 3 e 4.
b) Manutenibilità/Modificabilità dei moduli software di nuova realizzazione
• COC – Complessità ciclomatica: per ogni unità in aumento rispetto al valore soglia, si applica una penale pari allo 0,1% del valore contrattuale dell’applicazione;
• LDO – Livello di documentazione: per ogni unità in aumento rispetto al valore soglia, si applica una penale pari allo 0,2% del valore contrattuale dell’applicazione.
c) Efficienza temporale nella presentazione dei documenti contrattuali che consentono all’Amministrazione il governo del contratto.
• RSC – Tempestività di presentazione del Piano di progetto e del Rapporto di Riepilogo: per ogni giorno lavorativo di ritardo rispetto alla data prevista si applica una penale pari allo 0,05% (per ritardi fino al quinto giorno) o allo 0,1% (per ritardi oltre il quinto giorno), dell’importo corrispondente alle attività consuntivate nel perio- do cui ciascun rapporto si riferisce.
d) Efficienza temporale nella presentazione al collaudo degli obiettivi di sviluppo.
• RSC1 – Tempestività di presentazione della dichiarazione di collaudo per ciascun obiettivo di sviluppo: per ogni giorno solare di ritardo rispetto ai termini indicati nel Piano di progetto approvato dall’Amministrazione per la data di disponibilità al collaudo, si applica una penale pari all’1% del valore contrattuale dell’applica- zione.
Contratto con il fornitore B – Valorizzazione e pagamento dei servizi
60
Per il contratto da stipulare con il Fornitore B, l’Amministrazione ha stimato un importo complessivo massimo, in tre anni, di circa 25 milioni di Euro oltre IVA.
Di seguito si prospettano le singole voci di spesa definite dall’Amministrazione e le relative modalità di tariffazione e pagamento.
Componenti DI COSTO | Parametro DI TARIFFAZIONE | Tariffa PRATICATA | Modalità di pagamento |
Gestione Mainframe | MIPS mese installati | Euro/MIPS/mese | Canone mensile sulla base della configurazione in eser- cizio all’atto di stipula del contratto (ovvero all’inizio di ogni anno successivo) e compensazione fine anno |
Gestione Server centrali | Numero server centrali (30) gestiti mensilmente | Euro/server/mese | Canone mensile sulla base della configurazione in eser- cizio all’atto di stipula del contratto (ovvero all’inizio di ogni anno successivo) e compensazione fine anno |
Gestione Server periferici | Numero server distribuiti (40) gestiti mensilmente | Euro/server/mese | Canone mensile sulla base della configurazione in eser- cizio all’atto di stipula del contratto (ovvero all’inizio di ogni anno successivo) e compensazione fine anno |
Manutenzione Correttiva | FP gestiti | Euro/FP/mese | Canone mensile sulla base della configurazione in eser- cizio all’atto di stipula del contratto (ovvero all’inizio di ogni anno successivo) e compensazione fine anno |
Manutenzione adeguativa, migliorativa | FP movimentati | Euro/FP movimentato | A consumo mensile sulla base delle attività svolte |
Realizzazione ambiente di collaudo | Forfait | Euro TOT | Pagamento una tantum al completamento delle attività |
Realizzazione sistema gestione inventario | Forfait | Euro TOT | Pagamento una tantum al completamento delle attività |
Contratto con il fornitore B – Penali
Con riferimento agli indicatori definiti per i servizi da affidare al Fornitore B, si definiscono le seguenti penali.
a) Funzionalità ed affidabilità della conduzione operativa e monitoraggio
• CASS – Corretta esecuzione delle attività: per ogni punto percentuale in meno rispet- to al valore soglia, si applica una penale pari allo 0,5% del corrispettivo del periodo di riferimento;
• DIS1 – Disponibilità dei sistemi: per i sistemi appartenenti alla classe di servizio criti- ca, per ogni decimo di punto percentuale in meno rispetto al valore soglia si applica una penale pari all’1% del corrispettivo del periodo di riferimento; per i sistemi appar- tenenti alla classe di servizio non critica, per ogni decimo di punto percentuale in meno rispetto al valore soglia si applica una penale pari allo 0,5% del corrispettivo del periodo di riferimento.
b) Efficienza nella manutenzione dei sistemi hardware e software
• TASF – Tempestività di attivazione sub-fornitori: per la classe di servizio critica, per ogni decimo di punto percentuale in meno rispetto al valore soglia si applica una penale pari all’1% del corrispettivo del periodo di riferimento; per la classe di servizio non critica, per ogni decimo di punto percentuale in meno rispetto al valore soglia si applica una penale pari allo 0,5% del corrispettivo del periodo di riferimento;
61
• TRFC – Tempestività ripristino corretto funzionamento: per la classe di servizio cri- tica, per ogni decimo di punto percentuale in meno rispetto al valore soglia si applica una penale pari all’1% del corrispettivo del periodo di riferimento; per la
classe di servizio non critica, per ogni decimo di punto percentuale in meno rispet- to al valore soglia si applica una penale pari allo 0,5% del corrispettivo del perio- do di riferimento.
c) Efficienza e funzionalità nella manutenzione del parco applicativo esistente.
• RTRP – Rispetto dei tempi di risoluzione dei problemi: per la classe di servizio critica, per ogni decimo di punto percentuale in più, sia rispetto ai valori soglia indicati in cor- rispondenza dei livelli di gravità 1, 2, 3, 4 per la manutenzione correttiva, sia rispetto ai valori soglia indicati per la manutenzione adeguativa e migliorativa, si applica una penale pari all’1% del corrispettivo del periodo di riferimento;
• RTRP – Rispetto dei tempi di risoluzione dei problemi: per la classe di servizio non cri- tica, per ogni decimo di punto percentuale in più rispetto ai valori soglia indicati in corrispondenza dei livelli di gravità 1, 2 per la manutenzione correttiva si applica una penale pari all’1% del corrispettivo del periodo di riferimento; per ogni decimo di punto percentuale in più rispetto ai valori soglia indicati in corrispondenza dei livelli di gravità 3, 4 e rispetto ai valori soglia indicati per la manutenzione adeguativa e migliorativa, si applica una penale pari allo 0,5% del corrispettivo del periodo di rife- rimento.
d) Efficienza nella presa in carico del sistema
• RSC – Disponibilità sistema di gestione delle configurazioni, sistema di gestione del- l’inventario: per ogni giorno solare di ritardo rispetto ai termini indicati nel contratto per la data di disponibilità al collaudo, si applica una penale pari a 0,1% dell’importo della fornitura.
5.1.6 Stesura del capitolato tecnico
Sulla base dei ragionamenti esposti nei paragrafi precedenti, si procede nella stesura dei due Capitolati tecnici:
• per l’affidamento dei servizi di sviluppo (vedi pagg. da 61 a 70);
• per l’affidamento dei servizi di gestione (vedi pagg. da 71 a 82).
Nella descrizione che segue vengono sviluppate solo le parti del capitolato in cui trovano collocazione gli argomenti affrontati sino ad ora.
Si utilizza lo stile “corsivo” per commenti o indicazioni; lo stile “testo” per riportare parti di Capitolato.
62
CAPITOLATO DI GARA PER L’AFFIDAMENTO DEI SERVIZI DI SVILUPPO
A. PREMESSA
B. IL CONTESTO
C. DEFINIZIONE DELLA FORNITURA
C.1 Oggetto
C.2 Durata ed inizio delle attività
D. DESCRIZIONE DEI SERVIZI
D.1 Sviluppo e Mev di software ad hoc
D.1.1 Descrizione e requisiti
D1.2 Parametri per il dimensionamento
D.2 Manutenzione adeguativa e correttiva
D.3 Formazione ed addestamento
E. MODALITÀ DI ESECUZIONE
E.1 Gestione del progetto
E1.1 Pianificazione del progetto
E1.2 Esecuzione, Controllo e Rendicontazione E1.3 Pianificazione della qualità
E.2 Gestione delle configurazioni
E.3 Prodotti delle fasi di sviluppo
E.4 Assicurazione qualità
F. DIREZIONE LAVORI
X. XXXXXXXX
H. REQUISITI DI QUALITÀ E LIVELLI DI SERVIZIO
63
I. CESSAZIONE DEL SERVIZIO – ATTIVITÀ DI FINE CONTRATTO
A. PREMESSA
Introduzione e scopo della gara
omissis
Nel seguito si useranno i seguenti termini:
• Fornitore uscente: fornitore che attualmente è preposto alla erogazione dei servizi di sviluppo del S.I., con il quale l’Amministrazione ha stipulato una concessione di pros- sima scadenza.
• Fornitore/Fornitore subentrante: Fornitore aggiudicatario della gara per la fornitura dei servizi di cui al presente Capitolato;
• Fornitore B: Fornitore aggiudicatario della gara per l’erogazione dei servizi di gestione.
B. IL CONTESTO
Descrizione delle caratteristiche del S.I. dell’Amministrazione e delle esigenze alla base della richiesta di fornitura, analogamente a quanto indicato al paragrafo 5.1.1. Rimando ad allegati per la completa descrizione dell’architettura applicativa e tecnica del S.I.
omissis
C. DEFINIZIONE DELLA FORNITURA
C.1 Oggetto
Obiettivo della fornitura è l’erogazione di servizi connessi allo sviluppo ed evoluzione del
S. I. dell’Amministrazione.
Al Fornitore in particolare si richiedono i seguenti servizi:
I servizi sono indicati con riferimento alla classificazione prevista nel Dizionario, secondo quanto esposto al paragrafo 5.1.2. Per completezza si riportano, non in grassetto, anche quelli che nello scenario non sono trattati e che nel seguito non saranno considerati.
a) Sviluppo e manutenzione evolutiva del S.I.;
b) Manutenzione adeguativa e correttiva;
c) Formazione ed addestramento.
I requisiti e le modalità sono specificati nel successivo paragrafo D.
C.2 Durata ed inizio delle attività
Il periodo di durata contrattuale è fissato in tre anni. Sul nuovo software realizzato dovrà essere previsto un periodo di almeno dodici mesi di garanzia decorrenti dal collaudo con esito positivo, che il Fornitore dovrà erogare anche oltre la scadenza del contratto, nel caso di codice collaudato negli ultimi dodici mesi del contratto.
64
A partire dalla data di sottoscrizione del contratto (data di inizio attività), il Fornitore dovrà pro- cedere all’acquisizione delle conoscenze necessarie per poter subentrare al Fornitore uscente nella erogazione di tutti i servizi connessi allo sviluppo ed evoluzione del S.I. ed alla predispo- sizione dell’ambiente di sviluppo, secondo i requisiti indicati nel successivo paragrafo D. Tale fase dovrà completarsi nel tempo massimo di trenta giorni solari dalla data di inizio attività.
Durante tale periodo il Fornitore uscente garantirà l’affiancamento al personale del Fornitore, secondo le modalità indicate nel Piano di Migrazione, allegato2 al presente Capitolato.
D. DESCRIZIONE DEI SERVIZI
D.1 Sviluppo e Mev di software ad hoc
D.1.1 Descrizione e requisiti
Il servizio include interventi di sviluppo di nuovo software e modifica al software esistente, affe- renti a 14 obiettivi dettagliatamente descritti in allegato e classificati nelle seguenti tre tipologie:
a) Obiettivi di sviluppo di tipo A: interventi volti a realizzare sottosistemi applicativi che supportino le funzioni istituzionali dell’Amministrazione e che consentano il presidio dei processi di governo.
b) Obiettivi di sviluppo di tipo B: interventi volti a migliorare il coordinamento tra gli uffi- ci dell’Amministrazione e che favoriscano il presidio dei processi di servizio.
c) Obiettivi di sviluppo di tipo C: interventi volti a migliorare le informazioni ed i servizi on line resi disponibili verso l’esterno, attraverso il Portale dell’Amministrazione.
Le attività di sviluppo del software dovranno comprendere l’esecuzione di tutte le fasi con- nesse al ciclo di vita del servizio, ed in particolare:
Si inseriscono le attività di Analisi dei requisiti, Progettazione, Realizzazione, descritte nel Dizionario – Classe di fornitura Sviluppo e Mev di software ad hoc. Si specifica che la Installazione, sarà effettuata dal Fornitore B con il supporto del Fornitore, nell’ambiente di collaudo più avanti descritto e successivamente al collaudo con esito positivo, nell’am- biente di esercizio.
Le applicazioni di nuova realizzazione e/o derivanti da modifiche al software esistente dovranno integrarsi nel S.I. esistente, le cui caratteristiche sono descritte in allegato. Dovrà essere preservata la modularità e la scalabilità del S.I, intesa come possibilità di effettuare integrazioni al software e ai moduli applicativi esistenti o di realizzarne di nuovi. Per il soft- ware realizzato nell’ambito delle tre tipologie di obiettivi prima indicate, dovrà essere garantita e certificata dal Fornitore, secondo le modalità indicate al paragrafo G – Collaudi, la conformità alle seguenti norme:
Si inseriscono i riferimenti delle norme per cui deve essere garantita la conformità.
La metodologia di sviluppo potrà prevedere, a seconda delle caratteristiche degli obiettivi da realizzare, tecniche di modellazione tradizionale, object oriented o a componenti. Per gli obiettivi sviluppati con tecniche di modellazione tradizionale dovrà essere garantita, attra- verso l’utilizzo di strumenti di ultima generazione, la tracciabilità tra i requisiti formalizzati ed i documenti output della progettazione (specifiche funzionali; specifiche di collaudo), descritti più avanti nel paragrafo E.3 Prodotti delle fasi di sviluppo, al fine di facilitare la verifica della piena aderenza delle funzionalità sviluppate ai requisiti. Per gli obiettivi rea- lizzati con metodologia object oriented e a componenti la metodologia dovrà consentire la
2 Il richiamo ad allegati è fittizio. 65
verifica di versioni parziali e/o prototipi dei prodotti, attraverso l’impiego di tool di model- lazione. In tutti i casi possibili ed in particolare nello sviluppo di obiettivi con tecniche object oriented e a componenti, parlando di applicazioni che dovranno integrarsi in un S.I. esistente, la metodologia dovrà consentire il riuso di moduli software esistenti.
Tutti i prodotti sviluppati dovranno essere testati dal Fornitore in un ambiente di collaudo che sarà realizzato dal Fornitore B secondo specifiche emesse dal Fornitore e sarà gestito dal Fornitore B. L’ambiente di sviluppo sarà invece a totale carico del Fornitore, il quale dovrà provvedere a rendere disponibili i locali nei quali verranno svolte le attività previste dal contratto, le necessarie dotazioni individuali di attrezzature informatiche per il proprio personale, nonché le risorse hardware e software necessarie per lo sviluppo e la memoriz- zazione delle procedure oggetto del contratto e per l’esecuzione dei test interni. L’ambiente di sviluppo dovrà essere connesso con l’ambiente di esercizio, gestito dal Fornitore B; la connessione sarà messa a disposizione a cura e spesa dell’Amministrazione.
Il Fornitore dovrà supportare il Fornitore B nella presa in carico delle nuove applicazioni e dovrà fornire al Fornitore B tutta la documentazione necessaria affinché il Fornitore B possa erogare il servizio di gestione e possa subentrare nella manutenzione delle applicazioni al termine del periodo di garanzia.
D.1.2 Parametri per il dimensionamento
Il valore dimensionale massimo previsto per tutti gli interventi di sviluppo svolti nel perio- do di durata contrattuale, ivi comprese le attività di manutenzione evolutiva, non potrà eccedere i 13.500 Function Point.
Il mix di ambienti di sviluppo sulla base del quale dovrà essere definito il prezzo unitario per Function Point è mostrato nella tabella seguente.
Ambiente | Percentuale |
Java | 40% |
ASP/Visual Basic | 40% |
Terza generazione | 15% |
SQL | 5% |
Ambiente | Fattore di incremento della produttività |
Assembler | 0,3 |
C | 0,6 |
Cobol | 0,6 |
Cobol 400 | 0,7 |
C++ | 0,9 |
Java | 0,9 |
HTML-3 | 1,7 |
Visual Basic | 1,1 |
In funzione dello specifico ambiente di sviluppo, saranno applicati fattori di riduzione o aumento rispetto al prezzo standard. I parametri sono quelli riportati nella tabella seguen- te, che saranno utilizzati come divisori del prezzo per FP.
66
Per nuovi ambienti di interesse dell’Amministrazione o di altre Amministrazioni, diversi da quelli elencati, sarà concordato preventivamente il valore da assegnare all’incremento di produttività.
D.2 Manutenzione adeguativa e correttiva
omissis
D.3 Formazione e addestramento
omissis
E. MODALITÀ DI ESECUZIONE
E.1 Gestione del progetto
A partire dalla data di inizio attività, il Fornitore deve svolgere tutte le attività che consen- tono la conduzione coordinata del progetto, nel rispetto dei requisiti di tempi, costi e qua- lità di cui al presente documento, al contratto ed ai relativi allegati. In particolare,
Riprendere la descrizione della Pianificazione del progetto e della Pianificazione della qualità, descritte nel Dizionario - Processo di gestione.
E.1.1 Pianificazione del progetto
La pianificazione degli obiettivi di sviluppo sarà effettuata trimestralmente. Il Fornitore dovrà predisporre un Piano di progetto relativo a tutte le attività previste dal rapporto con- trattuale, indicando per ciascuna attività i tempi, le risorse necessarie ed il relativo impegno (stime a finire). Il Piano di progetto, approvato dall’Amministrazione, autorizzerà il Fornitore a dare seguito alle attività su base trimestrale.
Il Fornitore in particolare dovrà produrre:
a) un primo Piano di progetto in sede di presentazione dell’Offerta tecnica, che dia eviden- za di come intenda organizzare le proprie strutture per eseguire la fornitura richiesta, di quali risorse saranno assegnate, con indicazione dei relativi profili professionali e dei relativi ruoli/responsabilità, di quali strumenti e metodologie saranno utilizzati in caso di aggiudicazione della commessa;
b) una versione aggiornata del Piano di progetto, da consegnare all’Amministrazione Committente entro dieci giorni dalla sottoscrizione del contratto e, successivamente, entro il termine di dieci giorni solari dalla scadenza di ciascun trimestre e/o su richiesta dell’Amministrazione. Il Piano dovrà indicare, come specificato in seguito, la pianifica- zione degli obiettivi di sviluppo da realizzare nel trimestre di riferimento e la pianifica- zione a finire di tutte le attività di sviluppo. Il Piano di progetto, approvato dall’Amministrazione, autorizzerà il Fornitore a dare seguito alle attività pianificate per il trimestre cui il Piano si riferisce.
67
L’Amministrazione approverà i Piani di progetto di cui al precedente punto b) nei dieci gior- ni solari successivi alla presentazione, ovvero richiederà delle modifiche che dovranno essere apportate dal Fornitore nei successivi cinque giorni solari.
Il Piano di progetto dovrà contenere i dati di pianificazione per ciascun servizio del contrat- to per il quale sia prevista una modalità di erogazione basata su pianificazione preventiva. In particolare, per il servizio di Sviluppo e Mev di software ad hoc, il Piano di progetto dovrà descrivere le attività di sviluppo e di manutenzione evolutiva, con l’indicazione delle fasi, dei tempi previsti, dei deliverable e delle dimensioni pianificate in Function Point per ciascun obiettivo.
Il Piano di progetto di cui alla precedente lettera b), dovrà inoltre contenere informazioni generali sul progetto, che dovranno essere aggiornate nelle varie edizioni, qualora interven- gano elementi di modifica dei dati iniziali. Le principali informazioni richieste, ove applica- bili, sono le seguenti:
Si riprendono le informazioni tipiche di un Piano di progetto, presenti nel Dizionario
– Processo di gestione – Attività Pianificazione del progetto.
E.1.2 Esecuzione, Controllo e Rendicontazione
Il Fornitore dovrà svolgere le attività di sviluppo e manutenzione evolutiva nel rispetto del Piano di progetto approvato dall’Amministrazione per ciascun trimestre.
Con riferimento alle attività pianificate per ciascun trimestre, il Fornitore dovrà allegare al Piano di progetto un Rapporto di riepilogo delle prestazioni effettuate nel trimestre ovvero un documento che consenta di controllare lo stato delle attività e che consenta di rilevare per ciascun obiettivo di sviluppo concluso i dati dimensionali (FP) effettivi rispetto ai valo- ri stimati nel Piano di progetto.
Il documento dovrà indicare, rispetto ai dati di pianificazione contenuti nel Piano di proget- to cui il Rapporto si riferisce:
• lo stato delle attività relative allo sviluppo e alla manutenzione evolutiva, con l’indicazio- ne dei tempi effettivi di attivazione di ciascuna fase del ciclo di sviluppo, i deliverable prodotti e le dimensioni effettive in Function Point per ciascun obiettivo realizzato;
• l’andamento complessivo del progetto in termini di rispetto dei tempi, il riepilogo delle risorse impiegate, i FP residui, le eventuali criticità e, ove possibile, le relative azioni correttive previste o in essere.
Il rapporto di riepilogo approvato dall’Amministrazione autorizzerà il pagamento dei corri- spettivi, previa applicazione di eventuali penali a fronte del mancato rispetto dei livelli di qualità, come descritto nel successivo paragrafo H.
E.1.3 Pianificazione della qualità
Al fine di salvaguardare la specificità che il Contratto stipulato può assumere relativamente al Sistema Qualità in vigore, il Fornitore dovrà produrre, aggiornare in corso d’opera, gesti- re e consegnare all’Amministrazione un piano di qualità che:
a) fornisca lo strumento per collegare i requisiti specifici dei servizi contrattualmente richie- sti con le procedure generali del Sistema Qualità già esistenti;
68
b) espliciti le disposizioni organizzative e metodologiche adottate dal Fornitore allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;
c) dettagli i metodi di lavoro messi in atto dal Fornitore facendo riferimento o a procedure relative al proprio Sistema e per questo descritte nel Manuale Qualità, o a procedure svi-
luppate per lo specifico contrattuale, a supporto delle attività in esso descritte, in questo caso da allegare al piano;
d) indichi, in particolare, gli strumenti e le procedure utilizzate per garantire la gestione delle configurazioni;
e) specifichi le disposizioni organizzative e metodologiche adottate dal Fornitore per le atti- vità di interfaccia con l’Amministrazione e con il Fornitore B;
f) indichi, tra l’altro:
• gli obiettivi di qualità;
• le metriche per la misura della qualità effettivamente fornita, a fronte di quella attesa, inclusi i valori di soglia per le misure da svolgere che tengano conto delle indicazioni espresse in merito ai livelli di servizio di cui al successivo paragrafo H;
• i controlli da svolgere internamente per assicurare la qualità della fornitura e i relativi piani di verifica, incluse le specifiche responsabilità riguardo alla gestione delle non con- formità, alla gestione delle configurazioni ed al controllo delle sub-forniture;
• metodi, tecniche, strumenti, risorse, competenze previste dal Fornitore per assicurare la qualità della fornitura in corso d’opera;
g) garantisca il corretto e razionale evolversi delle attività contrattualmente previste e la tra- sparenza e tracciabilità di tutte le azioni messe in atto dalle parti in causa.
Il piano di qualità dovrà essere predisposto secondo le prescrizioni della norma EN ISO 10005.
E.2 Gestione delle configurazioni
Al fine di garantire l’integrità del patrimonio di software applicativo dell’Amministrazione il Fornitore sarà tenuto a definire un ambiente di collaudo, gestito e predisposto dal Fornitore B, distinto dall’ambiente di sviluppo e dall’ambiente di esercizio, in cui memorizzare tutto il codice sorgente ed eseguibile di tutte le applicazioni realizzate nel corso del contratto. Sono espressamente esclusi da questo trattamento tutti i prodotti normalmente reperibili sul mercato (Software standard) e di cui l’Amministrazione o il Fornitore detengono licenze d’uso a vario titolo (ad esempio, database, emulatori di terminale, ecc.). Sono espressamen- te inclusi in questo trattamento tutte le personalizzazioni eventualmente effettuate a prodot- ti di mercato. L’obiettivo è di verificare la compatibilità ed integrazione, nonché gli impatti di modifiche e/o aggiornamenti effettuati.
Ogni modifica a livello architetturale, di ambiente o di prodotto standard, dovrà essere testata in termini di compatibilità e integrazione prima di essere rilasciata in produzione. Il Fornitore, utilizzando l’ambiente di collaudo predisposto dal Fornitore B, verificherà l’inte- grazione, la coesistenza e, più in generale, gli effetti degli aggiornamenti, dei nuovi prodot- ti e dei processi di gestione prima dell’installazione.
69
L’ambiente sarà inoltre utilizzato dal Fornitore B per l’esecuzione dei test delle modifiche derivanti dalla manutenzione delle applicazioni in esercizio e sarà utilizzato, su richiesta e compatibilmente con le attività in corso, per test da parte dell’Amministrazione.
Il Fornitore dovrà predisporre e consegnare all’Amministrazione, entro trenta giorni solari dalla sottoscrizione del contratto, un Piano di gestione delle configurazioni.
Si riprendono i contenuti presenti nel Dizionario – Processo di Gestione della Configurazione – Pianificazione della configurazione e Realizzazione del servizio.
Il Fornitore dovrà consegnare al Fornitore B, contestualmente alla presentazione delle Specifiche funzionali e delle Specifiche di collaudo di cui al successivo paragrafo E.3, le Specifiche dell’ambiente di collaudo, necessarie per consentire la predisposizione/adegua- mento dell’ambiente di collaudo.
E.3 Prodotti delle fasi di sviluppo
Per ciascun intervento di sviluppo e di manutenzione evolutiva dovrà essere prodotta e consegnata all’Amministrazione, contestualmente alla conclusione di ciascuna delle attività di sviluppo (analisi dei requisiti, progettazione, realizzazione, ….) previste e secondo i tempi indicati nel Piano di progetto approvato dall’Amministrazione, i prodotti e i docu- menti indicati nella tabella che segue.
Attività | Prodotto |
Analisi dei requisiti | Specifica dei requisiti |
Progettazione tecnica | Specifiche funzionali (con elenco dei moduli software da modificare/creare) Prototipo |
Progettazione collaudo | Specifiche di collaudo Specifiche dell’ambiente di collaudo |
Realizzazione codifica | Prodotto software (elementi software integrati, con relativi dati e documentazione nella configurazione finale risultante dal test di prodotto) Elenco moduli software realizzati/modificati Report di conteggio dei Function Point |
Produzione della documentazione | Documentazione utente |
Qualificazione finale | Certificazione di rilascio al collaudo Dichiarazione di conformità |
Realizzazione del collaudo | Prodotto software nella configurazione di base (elementi software integrati, con relativi dati e documentazione nella configurazione finale risultante dal collaudo) Documentazione utente nella configurazione di base |
Per i prodotti, si inseriscono sintesi delle descrizioni presenti del Dizionario – Sviluppo e Mev di software ad hoc, con le personalizzazioni evidenziate per le attività ed i prodot- ti di tale classe nel paragrafo 5.1.3.
70
E.4 Assicurazione qualità
omissis
F. DIREZIONE LAVORI
omissis
X. XXXXXXXX
I servizi oggetto del presente Capitolato saranno sottoposti a collaudo da una Commissione nominata dall’Amministrazione e composta da un massimo di 3 membri.
Le operazioni di collaudo consisteranno nella verifica delle funzionalità realizzate attraver- so gli interventi di sviluppo e di manutenzione evolutiva.
Le attività di collaudo verranno svolte dalla Commissione di cui sopra, in contraddittorio con un rappresentante designato dal Fornitore.
Le Specifiche di collaudo dovranno essere redatte dal Fornitore e sottoposte preventiva- mente all’Amministrazione per accettazione entro il termine indicato nel Piano di progetto approvato dall’Amministrazione e comunque entro i venti giorni solari precedenti la data prevista di rilascio della dichiarazione di pronti al collaudo.
Tale documento, una volta accettato dall’Amministrazione, rappresenterà una guida per la Commissione di collaudo dell’Amministrazione, che potrà effettuare, comunque, tutte le prove che riterrà necessarie. Eventuali ulteriori prove che si deciderà di effettuare dovranno essere verbalizzate e costituiranno un addendum alle norme di collaudo sopra citate.
Secondo i tempi indicati nel Piano di progetto approvato dall’Amministrazione, il Fornitore comunicherà per iscritto all’Amministrazione il “pronti al collaudo”. Contestualmente alla emissione della dichiarazione di pronti al collaudo, il Fornitore consegnerà all’Amministrazione la dichiarazione di conformità alle norme specificate. Ove il collaudo non risulti positivo in tutto o in parte, il Fornitore dovrà rimuovere i malfunzionamenti riscontrati nei 20 giorni successivi.
H. REQUISITI DI QUALITÀ E LIVELLI DI SERVIZIO
I requisiti di qualità del software dovranno essere valutati dal Fornitore nelle fasi di analisi dei requisiti in relazione al profilo di qualità atteso dall’Amministrazione per ogni specifica applicazione realizzata o mantenuta, tenendo conto anche dell’ambiente di realizzazione. Le applicazioni di nuova realizzazione, ovvero risultanti da nuovi sviluppi software e/o da modifiche al software esistente, a prescindere dalla tipologia di obiettivo (A, B, C) cui fanno riferimento, al pari delle applicazioni in esercizio che costituiscono il patrimonio applicati- vo del S.I., dovranno essere inquadrate in due classi di servizio che determinano diversi attributi di qualità del software:
71
• classe di servizio “non critica”, corrispondente al livello base per applicazioni che necessitano dell’erogazione dei servizi di conduzione e assistenza nei soli giorni lavo- rativi, con esclusione del sabato. Appartiene a tale livello la generalità delle applica- zioni in esercizio presso gli Uffici dell’Amministrazione, che non rientrano nel caso successivo;
• classe di servizio “critica”, corrispondente ad un livello superiore per cui si prevede l’e- rogazione dei servizi di conduzione e assistenza nella settimana lavorativa compreso il
sabato mattina con livelli di servizio più severi rispetto al livello precedente. Appartengono a tale livello le applicazioni critiche rispetto alla erogazione diretta di ser- vizi al cittadino e le applicazioni con caratteristica di totale continuità di funzionamento.
In allegato si riporta la classificazione delle applicazioni in esercizio e dei sistemi, secondo i criteri sopra esposti.
Gli indicatori di qualità che il Fornitore dovrà valorizzare per ciascuna applicazione risul- tante da interventi di sviluppo di nuovo software e di manutenzione evolutiva, sono i seguenti.
Si inseriscono gli indicatori di qualità e i valori soglia definiti per i servizi da affidare al Fornitore A nel paragrafo 5.1.4.
Il Fornitore dovrà consegnare all’Amministrazione, in allegato al Rapporto di riepilogo di cui al paragrafo E.1.2 del presente Capitolato, la documentazione di riepilogo dei livelli di qualità delle applicazione realizzate. I report dovranno evidenziare i risultati delle misure effettuate, con gli eventuali scostamenti rispetto ai livelli di servizio contrattuali, l’indicazio- ne del conseguente ammontare delle penali, le motivazioni degli eventuali scostamenti in negativo ed i relativi correttivi.
La documentazione dovrà includere le informazioni di dettaglio sulle modalità di computo dei dati riportati su ciascun report.
I. CESSAZIONE DEL SERVIZIO – ATTIVITÀ DI FINE CONTRATTO
omissis.
72
CAPITOLATO DI GARA PER L’AFFIDAMENTO DEI SERVIZI DI GESTIONE
A. PREMESSA
B. IL CONTESTO
C. DEFINIZIONE DELLA FORNITURA
C.1 Oggetto
C.2 Durata ed inizio delle attività
D. DESCRIZIONE DEI SERVIZI
D.1 Sviluppo sistemi
D.2 Gestione sistemi
D.2.1 Gestione sistemi centrali – Ambito mainframe
D.2.2 Gestione sistemi centrali – Ambito server management
D.2.3 Gestione sistemi periferici
D.3 Manutenzione sistemi
D.4 Manutenzione adeguativa e correttiva
D.4.1 Manutenzione correttiva
D.4.2 Manutenzione adeguativa e migliorativa
D.5 Gestione applicativi e basi dati
D.6 Gestione e Manutenzione reti
D.7 Assistenza in remoto e in locale
D.8 Gestione e Manutenzione delle postazioni di lavoro
D.9 Controllo dei livelli di servizio
E. MODALITÀ DI ESECUZIONE
E.1 Gestione del progetto
E.1.1 Pianificazione del progetto
E.1.2 Esecuzione, Controllo e Rendicontazione
E.1.3 Pianificazione della qualità
E.2 Gestione delle configurazioni e Asset Management
E.2.1 Sistema di gestione delle configurazioni
E.2.1 Asset Management
E.3 Documentazione dei servizi
E.4 Assicurazione qualità
F. DIREZIONE LAVORI
X. XXXXXXXX
H. REQUISITI DI QUALITÀ E LIVELLI DI SERVIZIO
73
I. CESSAZIONE DEL SERVIZIO – ATTIVITÀ DI FINE CONTRATTO
A. PREMESSA
Introduzione e scopo della gara
omissis
Nel seguito si useranno i seguenti termini:
• fornitore uscente: fornitore che attualmente è preposto alla erogazione dei servizi di gestione del S.I., con il quale l’Amministrazione ha stipulato una concessione di prossi- ma scadenza.
• fornitore/Fornitore subentrante: Fornitore aggiudicatario della gara per la fornitura dei servizi di cui al presente Capitolato;
• fornitore A: Fornitore aggiudicatario della gara per l’erogazione dei servizi di sviluppo.
B. IL CONTESTO
Descrizione delle caratteristiche del S.I. dell’Amministrazione e delle esigenze alla base della richiesta di fornitura, analogamente a quanto indicato al paragrafo 5.1.1. Rimando ad allegati per la completa descrizione dell’architettura applicativa e tecnica del S.I.
omissis
C. DEFINIZIONE DELLA FORNITURA
C.1 Oggetto
Obiettivo della fornitura è l’erogazione di servizi connessi alla gestione del S.I. dell’Amministrazione.
Al Fornitore in particolare si richiedono i seguenti servizi:
I servizi sono indicati con riferimento alla classificazione prevista nel Dizionario, secondo quanto esposto al paragrafo 5.1.2. Per completezza si riportano (non in grassetto) anche quelli che nello scenario non sono trattati e che nel seguito non saranno considerati.
a) Sviluppo sistemi
b) Gestione sistemi centrali – Ambito mainframe
c) Gestione sistemi centrali – Ambito server management
d) Gestione sistemi periferici
e) Manutenzione sistemi
f) Manutenzione adeguativa e correttiva
g) Gestione applicativi e basi dati
h) Gestione e Manutenzione reti
i) Assistenza in remoto e in locale
j) Gestione e Manutenzione delle postazioni di lavoro
74
k) Controllo dei livelli di servizio
I requisiti e le modalità sono specificati nel successivo paragrafo D.
C.2 Durata ed inizio delle attività
Il periodo di durata contrattuale è fissato in tre anni. L’erogazione dei servizi dovrà partire dal
Si inserisce la data di scadenza del contratto con il Fornitore uscente. L’obiettivo è quello che non vi siano soluzioni di continuità nella migrazione ad un nuovo Fornitore; la data di inizio attività, a partire dalla quale comincerà la presa in carico del sistema, dovrà auspicabilmente essere precedente alla data di inizio della erogazione dei servizi.
A partire dalla data di sottoscrizione del contratto (data di inizio attività), il Fornitore dovrà predisporre quanto necessario per subentrare al Fornitore uscente nella erogazione di tutti i servizi oggetto del presente Capitolato.
Il Fornitore dovrà quindi procedere alla presa in carico del sistema ed all’acquisizione delle conoscenze necessarie, secondo quanto indicato nel Piano di Migrazione allegato al pre- sente documento. Tale fase dovrà completarsi nel tempo massimo di trenta giorni solari dalla data di inizio attività. Durante tale periodo il Fornitore uscente garantirà l’affiancamen- to al personale del Fornitore, secondo le modalità indicate nel Piano di Migrazione.
Entro trenta giorni solari dalla data di inizio attività, il Fornitore dovrà dichiarare per iscrit- to all’Amministrazione la disponibilità al collaudo dell’ambiente di gestione delle configu- razioni e dell’ambiente di gestione dell’inventario, secondo quanto descritto nel successivo paragrafo X - Xxxxxxxx.
D. DESCRIZIONE DEI SERVIZI
D.1 Sviluppo sistemi
omissis
D.2 Gestione sistemi
Il servizio riguarda la gestione dei sistemi centrali e periferici che costituiscono l’infrastrut- tura hardware e software del S.I. dell’Amministrazione. L’architettura tecnica ed applicativa è descritta in allegato.
Nella categoria “sistemi centrali” rientrano tutti i calcolatori, le periferiche che si trovano presso il CED dell’Amministrazione e sono utilizzati per l’erogazione di servizi al livello nazionale. In particolare:
• i sistemi mainframe;
• i sistemi server implementati su altre piattaforme eterogenee ed attualmente dislocati presso la sede del CED;
• tutte le periferiche (ad es. di stampa, memorie di massa) collegate ai calcolatori citati ed esse stesse attualmente collocate presso il CED.
Nella categoria “sistemi periferici” rientrano:
• sistemi server applicativi (calcolatori e periferiche ad essi collegati) utilizzati per la fruizione di servizi applicativi e server di workgroup (quali file server, print server, ecc.) adibiti a gruppi di utenti afferenti ai sistemi informativi locali;
75
• sistemi server infrastrutturali utilizzati per l’erogazione di servizi infrastrutturali (quali mail, DNS, ecc.) nell’ambito del S.I. dell’Amministrazione.
Il Fornitore dovrà prendere in carico tutti i sistemi hardware e software presenti a livello cen- trale ed a livello periferico, dettagliatamente descritti in allegato e dovrà gestire i relativi con- tratti con i sub-fornitori. Tutti i sistemi centrali e periferici oggetto del servizio sono ubicati in locali dell’Amministrazione; il Fornitore dovrà provvedere ad installare per proprio conto even- tuali componenti hardware e software che riterrà di utilizzare per erogare i servizi.
Tutto il software in esercizio è di proprietà dell’Amministrazione. Il Fornitore potrà acqui- stare per proprio conto e sarà proprietario di tutto il software d’ambiente necessario a migliorare l’erogazione dei servizi; ogni altro software di ambiente a supporto degli appli- cativi o qualsiasi ulteriore software il Fornitore intenda installare sui sistemi dovrà essere preventivamente concordato con l’Amministrazione che provvederà ad acquisirlo, ne man- terrà la proprietà e metterà a disposizione del Fornitore le licenze d’uso. Analogamente, l’Amministrazione intende mantenere la proprietà di tutto l’hardware in suo possesso già in esercizio o già acquistato nel periodo antecedente alla erogazione dei servizi di outsour- cing da parte del Fornitore; il Fornitore sarà tenuto all’ acquisto, noleggio e manutenzione di eventuali prodotti hardware necessari al perseguimento dei livelli di servizio previsti.
Il servizio di gestione dei sistemi dovrà comprendere l’esecuzione di tutte le fasi connesse al ciclo di vita del servizio, ed in particolare:
Si inseriscono le attività di Analisi dei requisiti, Progettazione, Realizzazione, descritte nel Dizionario – Classe di fornitura Gestione sistemi.
Per quanto riguarda la Realizzazione del servizio, sono richieste attività diverse in funzione della tipologia di sistema e dell’ambito di erogazione del servizio, come di seguito indicato.
D.2.1 Gestione sistemi centrali – Ambito mainframe
Al Fornitore sono richiesti i seguenti servizi:
a) Gestione operativa delle malfunzioni HW e SW;
b) Gestione operativa della Schedulazione;
c) Conduzione operativa e monitoraggio (Backup del sistema di base; Gestione dei sistemi on-line; Change management; Esecuzione delle procedure batch; Gestione dell’output; Distribuzione dell’output; Report management; User management);
d) Gestione operativa dello storage (Gestione dei supporti magnetici; Gestione dello spa- zio su disco).
Per ciascuna delle attività indicate si riprende la descrizione presente nel Dizionario – Gestione sistemi. L’attività di conduzione operativa si specifica in base alle sotto-attivi- tà indicate.
D.2.2 Gestione sistemi centrali – Ambito server management
Al Fornitore sono richiesti i seguenti servizi:
a) Gestione operativa delle malfunzioni HW e SW;
b) Gestione operativa delle prestazioni;
76
c) Conduzione operativa e monitoraggio (Configurazione ed Amministrazione dei server; Monitoring e fault management dei server; Change management; Software distribution; Gestione stampe centralizzate; User management).
Per ciascuna delle attività indicate si riprende la descrizione presente nel Dizionario – Gestione sistemi. L’attività di conduzione operativa e monitoraggio si specifica in base alle sotto-attività indicate.
D.2.3 Gestione sistemi periferici
Al Fornitore sono richiesti i seguenti servizi:
a) Gestione operativa delle malfunzioni HW e SW;
b) Conduzione operativa e monitoraggio (Installazione, Movimentazione, Aggiunte, Cambiamenti (IMAC); Configurazione ed Amministrazione dei server; Monitoring e fault management dei server; Change Management; Software distribution; User/resource management);
c) Gestione operativa dello storage (Backup & Restore; Ripristino dati).
Per ciascuna delle attività indicate si riprende la descrizione presente nel Dizionario – Gestione sistemi. L’attività di conduzione operativa e monitoraggio si specifica in base alle sotto-attività indicate.
D.3 Manutenzione sistemi
Il Fornitore dovrà assicurare la manutenzione degli apparati hardware e delle componenti software di base di tutti i sistemi oggetto del servizio di gestione, nel rispetto dei livelli di servizio indicati nel successivo paragrafo H.
In particolare il Fornitore dovrà:
• effettuare assistenza a server e periferiche. Per la strumentazione in garanzia, il Fornitore si conformerà alle istruzioni del programma di garanzia del costruttore durante il periodo di copertura della garanzia;
• effettuare la gestione logistica delle parti di ricambio e gestione della garanzia. Le parti di ricambio saranno quelle originali delle case costruttrici ad eccezione di quelle fuori produzione;
• riparare o sostituire parti hardware difettose;
• eseguire manutenzione preventiva periodica;
• effettuare upgrade dell’hardware secondo quanto indicato dal costruttore;
• sostituire temporaneamente l’apparecchiatura difettosa con altra equivalente.
Il Fornitore dovrà provvedere, quando necessario, all’aggiornamento di tutto il software standard e dei sistemi/ambienti operativi secondo adeguata analisi degli impatti.
Il Fornitore sarà tenuto a procedere a periodiche operazioni d’aggiornamento delle versio- ni dei prodotti software standard e dei sistemi/ambienti operativi in corrispondenza dei seguenti eventi:
• disponibilità di versioni significativamente più aggiornate rispetto a quelle in esercizio;
77
• scoperta di malfunzionamenti gravi nelle versioni in esercizio, per cui siano disponi- bili soluzioni “tampone” (patch) o rilasci di versioni che risolvano tali problemi.
Relativamente all’aggiornamento delle versioni del software applicativo il cui sviluppo è in carico al Fornitore A, il Fornitore riceverà comunicazione da tale Fornitore A sulla necessi- tà e/o convenienza per l’aggiornamento e congiuntamente ad esso procede alla pianifica- zione dell’installazione.
Relativamente al rimanente software standard e sistemi/ambienti operativi il Fornitore pro- cederà alla pianificazione dell’upgrade e all’aggiornamento sulla base della necessità/con- venienza individuate autonomamente.
Le attività di sostituzione di parti obsolete e di aggiornamento di versioni software dovranno essere autorizzate dall’Amministrazione, attraverso l’approvazione del Piano delle modifiche.
D.4 Manutenzione adeguativa e correttiva
Il Fornitore dovrà prendere in carico tutto il software applicativo in esercizio. La dimensio- ne complessiva, alla data, del patrimonio applicativo oggetto del servizio è pari a circa
45.000 Function Point; si prevede di massima che alla scadenza del contratto il numero tota- le di Function Point sia pari a 50.000. Per l’inventario dei moduli software che costituisco- no gli applicativi del S.I. e per le relative configurazioni, si rimanda al Piano di Migrazione allegato al presente documento.
Il Fornitore dovrà svolgere tutte le attività che caratterizzano il ciclo di vita del servizio, ed in particolare:
Si inseriscono le attività di Analisi dei requisiti e Progettazione descritte nel Dizionario
– Classe di fornitura Manutenzione adeguativa e correttiva.
Per quanto riguarda la Realizzazione del servizio, la manutenzione degli applicativi dovrà specializzarsi in manutenzione correttiva, adeguativa e migliorativa.
D.4.1 Manutenzione correttiva
Per manutenzione correttiva si intende la diagnosi e la rimozione delle cause e degli effet- ti dei malfunzionamenti delle procedure e dei programmi; tale attività è innescata da impe- dimenti all’esecuzione dell’applicazione/funzioni o da differenze riscontrate fra l’effettivo funzionamento del software applicativo e quello atteso, previsto dalla relativa documenta- zione o comunque determinato dalla prassi dell’utente. Il servizio di manutenzione corret- tiva è pertanto teso alla risoluzione dei difetti presenti nel codice sorgente, o nelle specifi- che di formato o di base dati attraverso la diagnosi e la rimozione delle cause e degli effet- ti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio.
L’attività di manutenzione correttiva dovrà essere erogata relativamente al software in eser- cizio, ivi compreso il software che il Fornitore nel corso del periodo contrattuale avrà modi- ficato o realizzato ex-novo.
L’impegno necessario allo svolgimento del servizio come sopra definito, dovrà essere pro- porzionale alla dimensione del software potenzialmente interessato e funzione della neces- sità di intervenire tempestivamente e in modo efficace per ripristinarne la piena operativi- tà, secondo i livelli di servizio definiti nel successivo paragrafo H.
78
L’impegno complessivo è stimato pari al 15% del valore complessivo del progetto, risultan- te dal valore dimensionale delle applicazioni nella versione corrente incrementato del valo- re dimensionale in Function Point degli obiettivi di sviluppo di nuova realizzazione, fatto
salvo il periodo di garanzia di 12 mesi, durante il quale la manutenzione correttiva sarà a carico del Fornitore A. La manutenzione correttiva segue una modalità di erogazione di tipo continuativo ed è, in linea di massima, non pianificabile essendo orientata alla rimo- zione dei difetti causati dal software stesso.
Il Fornitore dovrà rendere disponibile una piattaforma di trouble tickenting nella quale dovrà essere registrata ogni segnalazione ed ogni intervento di manutenzione attribuendo loro la corrispondente categoria di malfunzionamento (vedi livelli di servizio) e collegando tra loro le segnalazioni relative ad un unico guasto.
D.4.2 Manutenzione adeguativa e migliorativa
Per adeguativa si intende l’attività di manutenzione volta ad assicurare la costante ade- renza delle procedure e dei programmi all’evoluzione dell’ambiente tecnologico del sistema informativo, come ad esempio adeguamenti necessari per l’aggiornamento di versioni del software di base, adeguamenti intesi all’introduzione di nuovi prodotti o modalità di gestione del sistema, migrazioni di piattaforma, adeguamenti necessari per preservare l’efficienza degli applicativi al variare delle condizioni e dei carichi di lavo- ro (ad esempio per migliorie di performance, per aumento delle dimensioni delle basi dati, ecc.).
L’attività di manutenzione adeguativa e migliorativa dovrà essere erogata relativamente al software in esercizio, ivi compreso il software che il Fornitore nel corso del periodo con- trattuale avrà modificato o realizzato ex-novo.
L’impegno complessivo richiesto e la relativa quantificazione economica sono funzione dei FP movimentati per ciascun intervento.
Per quanto riguarda le modalità di esecuzione, gli interventi dovranno essere indicati, a pre- ventivo ed a consuntivo, rispettivamente nel Piano delle modifiche e nel Rapporto delle atti- vità di manutenzione.
Si riprende la descrizione dei documenti di pianificazione e rendicontazione sopra indicati dal Dizionario – Manutenzione adeguativa e correttiva.
D.5 Gestione applicativi e basi dati
omissis
D.6 Gestione e Manutenzione reti
omissis
D.7 Assistenza in remoto e in locale
omissis
D.8 Gestione e Manutenzione delle postazioni di lavoro
omissis
79
D.9 Controllo dei livelli di servizio
omissis
E. MODALITÀ DI ESECUZIONE
E.1 Gestione del progetto
Il Fornitore dovrà svolgere tutte le attività che consentono la conduzione coordinata del progetto, nel rispetto dei requisiti di tempi, costi e qualità di cui al presente documento, al contratto ed ai relativi allegati. In particolare,
Riprendere la descrizione della Pianificazione del progetto e della Pianificazione della qualità, descritte nel Dizionario- Processo di gestione.
E.1.1 Pianificazione del progetto
Il Fornitore dovrà predisporre un Piano di progetto relativo a tutte le attività previste dal rapporto contrattuale. Il Piano di progetto dovrà contenere almeno i seguenti elementi:
• l’organizzazione delle risorse necessarie allo svolgimento delle attività previste dal contratto, inclusi struttura dei gruppi di lavoro, responsabilità, carichi di lavoro, risor- se materiali;
• le fasi del progetto, i flussi in ingresso ed uscita dalle attività e quanto previsto in ter- mini di controllo ed assicurazione qualità;
• il programma temporale del progetto, con l’individuazione delle attività, delle loro relazioni e per ciascuna di esse, delle risorse dei tempi necessari per completarle;
• l’analisi dei rischi e dei problemi associati alle varie fasi.
Il Piano di progetto dovrà essere presentato in fase di offerta e revisionato a valle dell’ag- giudicazione e firma del contratto, per riflettere le eventuali variazioni intervenute durante il procedimento di gara. Nel corso della esecuzione del contratto il Piano di progetto sarà utilizzato dal Fornitore come Piano del servizio, ovvero per regolare tempi e modi di ese- cuzione di attività proprie di quei servizi, quali la manutenzione adeguativa e migliorativa e la manutenzione dei sistemi, che seguono una modalità di erogazione basata su pianifi- cazione preventiva. Ciascuna edizione del Piano di progetto dovrà essere sottoposta all’ap- provazione dell’Amministrazione.
E.1.2 Esecuzione, Controllo e Rendicontazione
Per tutti i servizi che seguono una modalità di erogazione basata su pianificazione preven- tiva (manutenzione adeguativa e correttiva; manutenzione sistemi; …) il Fornitore dovrà svolgere le attività previste nel rispetto del Piano di progetto (Piano del servizio) approva- to dall’Amministrazione.
80
Con riferimento alle attività pianificate ed approvate dall’Amministrazione, il Fornitore dovrà presentare con cadenza trimestrale, entro dieci giorni solari dalla scadenza di cia- scun trimestre, un Rapporto di riepilogo delle prestazioni effettuate nel trimestre ovvero un documento che consenta di controllare le attività effettuate rispetto a quelle pianifi- cate e l’impegno effettivo rispetto al pianificato (per gli interventi di manutenzione ade- guativi e correttiva, i FP movimentati). Il documento approvato dall’Amministrazione autorizzerà il pagamento dei corrispettivi per i servizi erogati in ciascun trimestre di rife- rimento.
E.1.3 Pianificazione della qualità
Al fine di salvaguardare la specificità che il Contratto stipulato può assumere relativamente al Sistema Qualità in vigore, il Fornitore dovrà produrre, aggiornare in corso d’opera, gesti- re e consegnare all’Amministrazione un piano di qualità che:
a) fornisca lo strumento per collegare i requisiti specifici dei servizi contrattualmente richie- sti con le procedure generali del Sistema Qualità già esistenti;
b) espliciti le disposizioni organizzative e metodologiche adottate dal Fornitore allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;
c) dettagli i metodi di lavoro messi in atto dal Fornitore facendo riferimento o a procedure relative al proprio Sistema e per questo descritte nel Manuale Qualità, o a procedure svi- luppate per lo specifico contrattuale, a supporto delle attività in esso descritte, in questo caso da allegare al piano;
d) indichi, in particolare, gli strumenti e le procedure utilizzate per garantire la gestione delle configurazioni;
e) specifichi le disposizioni organizzative e metodologiche adottate dal Fornitore per le atti- vità di interfaccia con l’Amministrazione e con il Fornitore A;
f) indichi, tra l’altro:
• gli obiettivi di qualità;
• le metriche per la misura della qualità effettivamente fornita, a fronte di quella attesa, inclusi i valori di soglia per le misure da svolgere che tengano conto delle indicazioni espresse in merito ai livelli di servizio, di cui al successivo paragrafo H;
• i controlli da svolgere internamente per assicurare la qualità della fornitura e relativi piani di verifica, incluse le specifiche responsabilità riguardo alla gestione delle non conformità, alla gestione delle configurazioni ed al controllo delle sub-forniture;
• metodi, tecniche, strumenti, risorse, competenze previste dal Fornitore per assicurare la qualità della fornitura in corso d’opera;
g) garantisca il corretto e razionale evolversi delle attività contrattualmente previste e la tra- sparenza e tracciabilità di tutte le azioni messe in atto dalle parti in causa.
Il piano di qualità dovrà essere predisposto secondo le prescrizioni della norma EN ISO 10005. Il Piano di qualità, dovrà essere presentato in fase di offerta e revisionato a valle dell’aggiu- dicazione e firma del contratto, per riflettere le eventuali variazioni intervenute durante il procedimento di gara.
E.2 Gestione delle configurazioni e Asset Management
E.2.1 Sistema di gestione delle configurazioni
81
L’organizzazione del sistema di gestione delle configurazioni dovrà prevedere gli ambienti logici di collaudo, manutenzione ed esercizio. L’ambiente di collaudo sarà uti- lizzato, oltre che dal Fornitore per verificare le modifiche al software in esercizio deri- vanti dal servizio di manutenzione adeguativa e correttiva, dal Fornitore A per eseguire test del nuovo software e dall’Amministrazione per l’esecuzione dei collaudi. Il Fornitore
B dovrà quindi prevedere idonee misure di sicurezza per garantire l’integrità delle appli- cazioni in esercizio.
Il servizio di gestione delle configurazioni, effettuato con l’ausilio di un prodotto di merca- to proposto dal Fornitore, dovrà consistere almeno nelle seguenti attività:
Riprendere la descrizione delle attività relative alla Identificazione della configurazio- ne, al Controllo della configurazione ed alla Registrazione dello stato di configurazio- ne, presente nel Dizionario – Processo di gestione della configurazione.
Il sistema di gestione delle configurazioni dovrà essere funzionale entro trenta giorni sola- ri dalla data di inizio attività; entro lo stesso termine il Fornitore dovrà consegnare all’Amministrazione il Piano di gestione delle configurazioni, che indichi le procedure, le l’organizzazione, le responsabilità, gli strumenti e la tempistica per le attività di gestione della configurazione.
Il servizio, richiesto sia per i sistemi centrali che per i sistemi periferici, consiste nella gestio- ne e controllo delle informazioni relative all’installato. Le informazioni da gestire riguarda- no le componenti hardware e software e le relative informazioni di configurazione.
In particolare il Fornitore dovrà:
• realizzare e gestire un inventario centralizzato relativo all’installato hardware e software;
• definire il processo necessario a garantire il costante mantenimento e aggiornamento delle informazioni relative all’installato;
• gestire le garanzie relative ai componenti hardware;
• gestire le licenze relative al software, per quanto concerne gli adempimenti, gli aggior- namenti e il rilevamento.
Il sistema utilizzato per implementare l’inventario dovrà permettere una verifica immedia- ta, da parte dell’Amministrazione della consistenza e dello stato di tutti i calcolatori, le peri- feriche, le apparecchiature di rete, il software di base e d’ambiente, il software applicativo ed in generale di tutte le apparecchiature ed i prodotti utilizzati dal Fornitore per l’eroga- zione dei servizi oggetto del contratto. Utenti autorizzati dell’Amministrazione dovranno potere accedere a queste informazioni con modalità “in linea” e con la possibilità di prele- vare le informazioni contenute per un’eventuale elaborazione fuori linea.
Il sistema per la gestione dell’inventario dovrà esser funzionale entro trenta giorni solari dalla data di inizio attività.
E.3 Documentazione dei servizi
Per tutti i servizi oggetto del contratto, il Fornitore dovrà produrre, aggiornare in corso d’o- pera, gestire e consegnare all’Amministrazione entro trenta giorni dalla data di inizio attivi- tà la documentazione di progetto.
Detta documentazione dovrà comprendere:
82
• le specifiche del servizio, che descrivano chiaramente il servizio, le caratteristiche del servizio e le condizioni di accettabilità per ciascuna caratteristica;
• le specifiche di realizzazione del servizio, che descrivano le modalità di realizzazione del servizio, le condizioni di accettabilità per ciascuna caratteristica di realizzazione del servizio, i requisiti delle risorse hardware, software ed umane utilizzate per svol- xxxx il servizio;
• le specifiche di controllo qualità del servizio, che descrivano metodi, strumenti, risor- se, per la misura delle caratteristiche di qualità dei servizi.
La documentazione di progetto presentata in fase di offerta dovrà essere revisionata a valle dell’aggiudicazione e firma del contratto, per riflettere le eventuali variazioni inter- venute durante il procedimento di gara, e dovrà essere approvata dall’Amministrazione. La documentazione di progetto dovrà inoltre essere aggiornata a seguito di varianti ai servizi.
E.4 Assicurazione qualità
omissis
F. DIREZIONE LAVORI
omissis
X. XXXXXXXX
I servizi oggetto del presente Capitolato saranno sottoposti a collaudo da una Commissione nominata dall’Amministrazione e composta da un massimo di 3 membri.
Le operazioni di collaudo consisteranno nella verifica del modello di funzionamento dei servizi e di quanto altro o necessario per l’erogazione dei suddetti servizi.
Saranno oggetto di collaudo in particolare:
• il sistema di gestione delle configurazioni;
• il sistema di gestione dell’inventario;
• i servizi di gestione sistemi e manutenzione adeguativa e correttiva.
Le attività di collaudo verranno svolte dalla Commissione di cui sopra, in contraddittorio con un rappresentante designato dal Fornitore.
Le specifiche di collaudo dovranno essere redatte dal Fornitore e sottoposte preventiva- mente all’Amministrazione per accettazione entro il termine di trenta giorni solari dalla data di inizio lavori.
Tale documento, una volta approvato dall’Amministrazione, rappresenterà una guida per la Commissione di collaudo, che potrà effettuare, comunque, tutte le prove che riter- rà necessarie.
83
Entro trenta giorni solari dalla data di sottoscrizione del contratto, il Fornitore comuniche- rà per iscritto all’Amministrazione il “pronti al collaudo”. Ove il collaudo non risulti positi- vo in tutto o in parte, il Fornitore dovrà rimuovere i malfunzionamenti riscontrati nei venti giorni successivi. A partire dalla nuova data di “pronti al collaudo”, nei dieci giorni succes- sivi la Commissione ultimerà le operazioni di collaudo.
H. REQUISITI DI QUALITÀ E LIVELLI DI SERVIZIO
I servizi di gestione e di assistenza, al pari delle applicazioni in esercizio e delle applicazio- ni di nuova realizzazione che costituiscono il patrimonio applicativo del S.I., dovranno essere inquadrati in due classi di servizio che determinano diversi attributi di qualità dei servizi oggetto del presente documento:
• classe di servizio “non critica”, corrispondente al livello base per applicazioni che neces- sitano dell’erogazione dei servizi di conduzione e assistenza nei soli giorni lavorativi, con esclusione del sabato. Appartiene a tale livello la generalità delle applicazioni in eserci- zio presso gli Uffici dell’Amministrazione, che non rientrano nel caso successivo;
• classe di servizio “critica”, corrispondente ad un livello superiore per cui si prevede l’e- rogazione dei servizi di conduzione e assistenza nella settimana lavorativa compreso il sabato mattina con livelli di servizio più severi rispetto al livello precedente. Appartengono a tale livello le applicazioni critiche rispetto alla erogazione diretta di ser- vizi al cittadino e le applicazioni con caratteristica di totale continuità di funzionamento.
In allegato si riporta la classificazione delle applicazioni in esercizio e dei sistemi secondo i criteri sopra esposti.
Gli indicatori di qualità che il Fornitore dovrà valorizzare per ciascun servizio sono i seguenti.
Si inseriscono gli indicatori di qualità e i valori soglia definiti per i servizi da affidare al Fornitore B, nel paragrafo 5.1.4.
Il Fornitore dovrà consegnare all’Amministrazione, in allegato al Rapporto di riepilogo di cui al precedente paragrafo E.1.2 del presente Capitolato, la documentazione relativa al riepilogo dei livelli di servizio erogati. I report dovranno evidenziare i risultati delle misure effettuate in ciascun trimestre di riferimento, con gli eventuali scostamenti rispetto ai livelli di servizio contrattuali, l’indicazione del conseguente ammontare delle penali, le motivazio- ni degli eventuali scostamenti in negativo ed i relativi correttivi.
I. CESSAZIONE DEL SERVIZIO – ATTIVITÀ DI FINE CONTRATTO
Il Fornitore dovrà garantire tutto quanto risulti necessario perché, alla scadenza del contrat- to, un nuovo Fornitore possa ad esso eventualmente subentrare nell’erogazione di tutti i servizi oggetto del presente Capitolato.
A tal fine il Fornitore dovrà:
• produrre e consegnare all’Amministrazione, entro sei mesi dalla scadenza del contratto un piano di migrazione contenente tutte le informazioni necessarie per consentire il subentro di altro Fornitore nell’erogazione dei servizi oggetto del presente Capitolato;
• procedere all’aggiornamento continuo del suddetto piano di migrazione, provveden- do di volta in volta alla consegna dello stesso all’Amministrazione, di modo che il documento sia puntualmente riferito allo scenario correntemente in esercizio;
84
• fornire, negli ultimi 2 mesi di contratto (periodo di trasferimento) e su richiesta dell’Amministrazione, tutto il supporto e la collaborazione necessaria al Fornitore subentrante.
5.1.7 Considerazioni conslusive
Il caso presentato è stato notevolmente semplificato, escludendo Classi di fornitura stretta- mente connesse con alcune classi esaminate, per l’esigenza di dare risalto non alla soluzio- ne trattata, quanto all’approccio seguito, suggerito dalle Linee guida, per arrivare alla defi- nizione della fornitura.
In uno scenario così complesso, che vede la separazione delle attività di sviluppo e di gestione tra due fornitori, con diverse responsabilità all’interfaccia, la scomposizione in Classi di fornitura e l’identificazione delle attività e dei deliverables “tipo” di ciascuna clas- se, proposte dal Dizionario, hanno offerto un metodo per definire in modo sistematico le attività richieste a ciascun fornitore ed hanno notevolmente semplificato l’individuazione degli elementi con i quali l’Amministrazione può sia coordinare le attività tra i due fornito- ri che esercitare il controllo sulle attività di ciascuno.
Estendendo tale considerazione, si fa rilevare come la segmentazione dei servizi in clas- si operata nel Dizionario, con la descrizione analitica del ciclo di vita di una fornitura di cui una specifica classe costituisce l’astrazione, consenta ad una Amministrazione di spe- cificare al meglio, in fase di stesura dei documenti di gara, quanto necessario per eser- citare le funzioni di governo del contratto; tale caratteristica permette altresì ad un Fornitore di individuare l’organizzazione più adeguata per erogare i servizi richiesti, definendo ed assegnando in modo sistematico le responsabilità all’interno della propria struttura e rispetto alle altre organizzazioni che a vario titolo sono coinvolte nella forni- tura (p. es. sub-fornitori o altre imprese in RTI).
È ovvio mettere in evidenza l’esigenza di considerare le Classi di fornitura come entità da personalizzare in funzione di specifiche esigenze: non esiste un servizio che sia iden- tico ad un altro, quindi non può esistere una descrizione di un servizio che sia sempre valida. Le modalità di definizione di una fornitura sono inevitabilmente influenzate dal contesto di riferimento, dalle scelte strategiche operate dall’Amministrazione e dalle procedure di acquisto in uso presso la stessa Amministrazione: ciò comporta un lavoro di adattamento dei contenuti presenti in ciascuna classe, generalmente validi per tutte le tipologie di forniture di cui la classe costituisce l’astrazione, alle specificità del contesto in esame. Tale aspetto emerge facilmente attraverso la lettura dello scenario, e risulta tanto più vero quanto più composita è la fornitura oggetto del contratto. Probabilmente in presenza di un contratto che deve regolare, ad esempio, solo lo sviluppo di software ad hoc, le personalizzazioni rispetto a quanto già contenuto nella classe “Sviluppo e Mev di software ad hoc” sono minime e necessarie solo per specificare vincoli e requisiti del contesto. In presenza di una fornitura articolata in molte classi, come nel caso dei servi- zi richiesti al Fornitore B, è evidente l’esigenza di eliminare o ridurre al minimo le ridon- danze o le sovrapposizioni tra attività e prodotti delle classi; in questa stessa ottica sono apprezzabili i vantaggi che si ricavano dal trattare il processo di gestione e gli altri pro- cessi di supporto in modo trasversale a tutte le classi che compongono la fornitura.
5.2 CASO CRM
85
Viene di seguito riportato l’esempio di una fornitura di progettazione, realizzazione e gestione di un Contact Center multicanale con finalità di “sportello virtuale unico” per
l’erogazione di informazioni e di servizi all’utenza di una Amministrazione di grandi dimensioni. Per la complessità tecnologica delle componenti e dei servizi richiesti e per i volumi gestiti, in un arco di tre anni di durata prevista di contratto, la dimensione eco- nomica dell’intera soluzione di Contact Center è superiore ai 40 Milioni di Euro.
Il metodo seguito e consigliato per queste dimensioni e complessità è quello di partire dalle esigenze dell’Amministrazione per definire la soluzione complessiva e le sue componenti principali in termini di servizio, con una loro definizione di massima. Sulla base della descri- zione di massima dei servizi componenti, selezionare dal dizionario delle forniture le clas- si che hanno un numero di attività significativo e coerente con la soluzione, suddividendo- le ulteriormente, se necessario, in termini di istanze. Ricavare dalle classi gli indicatori necessari per definire i livelli di servizio applicabili alla soluzione e che più interessano agli utenti dell’Amministrazione. Con questi elementi scrivere il Capitolato tecnico descrivendo in dettaglio i singoli servizi richiesti ricavando o aggiungendo le attività, i requisiti ed i vin- coli a partire dalle classi ed istanze selezionate. Descritti i servizi componenti, per queste dimensioni di fornitura vanno sempre dettagliate nel Capitolato le attività di gestione che possono estrarsi, personalizzandole all’Amministrazione, dalla classe Gestione del Dizionario.
Sono riportati in “corsivo” indicazioni e suggerimenti per lo sviluppo dei contenuti e per l’uso del dizionario delle forniture.
5.2.1 Descrizione delle esigenze e del contesto
L’Amministrazione appaltante ha un assetto organizzativo che si articola su tre livelli (Direzione Generale con funzioni di centro direzionale, Direzioni Regionali per la gestione del territorio, Agenzie di produzione per lo svolgimento delle attività produttive).
Gli utenti a cui si rivolge l’Amministrazione sono:
• le istituzioni: P.A. centrale e locale, gli istituti bancari, le Poste, ecc.;
• gli utenti esterni: i cittadini, le aziende (circa 1.400.000);
• gli utenti interni (oltre 30.000 dipendenti).
Il Sistema Informativo dell’Amministrazione è frutto dell’evoluzione di oltre 30 anni ed inte- gra: componenti web (Internet e Intranet), Call Center, basi dati e applicazioni in ambiente mainframe (oltre 16 TeraByte di dati, 5.000 Mips di potenza) e dipartimentale, sistemi inno- vativi di telecomunicazione (portali vocali, voice over IP), Personal Computer multimedia- li e valigette telematiche (per il personale che viaggia nelle strutture territoriali) connesse mediante telefoni cellulari.
L’architettura del sistema informatico si basa su 3 livelli:
• il Centro Elettronico Nazionale per le applicazioni centrali ed i sistemi di Data Warehouse;
• i Centri Dipartimentali per le applicazioni che gestiscono i rapporti con gli utenti, la posta elettronica, la documentazione ed il workflow;
86
• i Posti di Lavoro individuali: Personal Computer con Microsoft Windows 2000 per informatica individuale ed accesso con browser alle applicazioni intranet e con emu- latore 3270 per le altre applicazioni.
Il sistema di trasmissione dati attualmente in esercizio presso l’Amministrazione è basato su RUPA (Rete Unitaria della Pubblica Amministrazione).
In aggiunta alle connessioni telematiche “interne”, l’Amministrazione è collegata, utilizzan- do varie modalità, alle principali Amministrazioni Pubbliche Centrali e Locali, agli Istituti di Credito, alle Università ed Enti di Ricerca e Studio, alle Poste Italiane per lo scambio tele- matico delle informazioni.
Di particolare interesse per la fornitura in esame sono i contenuti attuali del sito Internet e del Call Center dell’Amministrazione:
• Il sito Internet dell’Amministrazione attualmente fornisce servizi di carattere infor- mativo e gestionale a diverse categorie di utenti, tra le quali rientrano i cittadini, le aziende, altre Amministrazioni centrali ed enti locali. Il sito WEB viene utilizzato per due aree funzionali: la prima essenzialmente di natura informativa, ossia come “strumento informativo” di trasparenza amministrativa per la conoscenza della materia trattata dall’Amministrazione, per la sua normativa, per la sua struttura e per le sue attività; la seconda di natura gestionale dei rapporti dell’Amministarzione verso gli utenti, ossia come un vero e proprio “strumento gestionale”. Alcuni dei servizi forniti si caratterizzano come Business-To-Consumer (B2C) e al tempo stes- so come Business-To-Business (B2B) in quanto le caratteristiche applicative del servizio garantiscono sia la possibilità di accesso da parte di utenti non dotati di sistema informatico proprio, sia l’interazione con sistemi informatici esterni in ter- mini di interscambio di dati.
• Il Call Center dell’Amministrazione, come il sito Internet, fornisce servizi di carat- tere informativo e di carattere gestionale sia in forma automatica che mediante ope- ratore telefonico. I servizi sono erogati attraverso un’infrastruttura tecnologica che comprende: un albero di risposta automatizzato, la gestione del database dei que- siti posti e delle risposte fornite, la gestione e la visibilità dei quesiti e dei flussi di risposta in architettura web ai vari livelli (centrale, regionale, agenzie) attraverso l’uso di un Workflow che unisce il Call Center con le varie sedi dell’Am- ministrazione, la navigazione ipertestuale mediante motore di ricerca sulle infor- mazioni generali dell’Amministrazione.
La struttura del servizio è articolata su tre livelli: il 1° livello fornisce risposte in xxx xxxx- xxxxxxxxx percorrendo un albero di navigazione; il 2° livello fornisce servizi mediante operatori esterni di Call Center; il 3° livello interviene nel caso in cui il quesito riguardi una consulenza specifica e richieda l’intervento del personale dell’Amministrazione della Sede competente. Tale livello viene attivato direttamente dagli operatori di Call Center che hanno a disposizione una procedura di Workflow integrata con la gestione del back-office delle varie sedi operative.
87
Parallelamente al servizio di inbound, è disponibile il servizio di outbound che effettua i servizi di richiamata agli utenti per il completamento dell’iter delle pratiche, realizza le cam- pagne per la verifica dei livelli customer satisfaction, le campagne informative su scadenze e adempimenti.
L’Organizzazione del Servizio inbound prevede l’operatività dalle 8.00 alle 18.00 dal Lunedì al Venerdì e dalle 8.00 alle 13.00 di ogni Sabato lavorativo, festività escluse.
L’Organizzazione dei Servizi outbound prevede l’operatività dalle 8.00 alle 18.00, dal Lunedì al Venerdì, festività escluse, assicurando 200 ore lavorative giornaliere da parte degli agen- ti outbound, distribuite su 20 postazioni operatore. I volumi annui gestiti sono di circa
4.000.000 di chiamate inbound e 1.000.000 di chiamate outbound.
L’Amministrazione sta rivedendo il proprio assetto organizzativo in chiave di Azienda di Servizi che opera in una logica di processi funzionali al raggiungimento del paradigma della “centralità dell’utente”. Tale riorganizzazione considera strategico l’utilizzo delle tecnologie ICT sia come elemento facilitatore del cambiamento in atto, sia come elemento essenziale per la integrazione delle attività svolte dalle strutture centrali e periferiche intorno ai pro- cessi che si stanno ridisegnando.
In questo scenario le esigenze ICT principali che stanno emergendo riguardano:
• Il proseguimento degli interventi in atto di virtualizzazione, delocalizzazione e dif- ferenziazione dei canali di accesso degli utenti ai servizi istituzionali (informativi e gestionali) dell’Amministrazione implementandoli ed arricchendoli di contenuti applicativi.
• Il miglioramento della qualità del servizio dell’Amministrazione verso l’utenza attra- verso l’integrazione dei canali di comunicazione (Call center, Sportelli sul territorio, WEB, Telefono, Posta elettronica,…) realizzando un’architettura tecnologica e di ser- vizi integrata ed omogenea che preveda l’uso di strumenti innovativi di colloquio e gestione delle relazioni con l’utenza.
In considerazione del fatto che è prossima la scadenza dell’attuale servizio in outsourcing del call center, l’Amministrazione intende soddisfare le nuove esigenze attraverso la realiz- zazione di un Contact Center multicanale che funga da “Sportello Virtuale Unico” per l’ero- gazione di Informazioni e Servizi a tutti gli utenti dell’Amministrazione.
Tenendo presente l’attuale stato dei sistemi informativi e dell’organizzazione, occorre inter- venire sul servizio operatori di call center ridisegnandone i processi e prevedendo l’uso delle nuove applicazioni, che verranno sviluppate integrate con gli altri canali a valle della reingegnerizzazione dei processi aziendali in atto. Per un corretto ed innovativo rapporto con gli utenti occorrerà dotare il Call Center e le altre funzioni dell’Amministrazione di stru- menti moderni di relazione con i clienti (CRM - Customer Relationship Management) e di conoscenza dei clienti (KM - Knowledge Management) presenti sul mercato, dei quali l’Amministrazione non è ancora in grado di valutare e gestire i contenuti. Occorre inoltre tenere presente che l’Amministrazione non intende sviluppare e gestire le infrastrutture tec- nologiche necessarie per la erogazione dei servizi del Contact Center, in quanto disegnate e sviluppate su tecnologie specifiche (telefoniche ed elaborative) non ancora note alle pro- prie strutture organizzative.
La forte relazione esistente tra le esigenze da soddisfare, associata all’innovazione tecnolo- gica ed organizzativa richiesta per la copertura delle medesime, hanno spinto l’Amministrazione a definire un’unica “Soluzione” da realizzarsi con una o più forniture nelle quattro aree di attività/prodotti che la compongono:
1. Servizio Operatori
2. Servizio di Sviluppo di un Sistema CRM e KM
88
3. Servizio di Sviluppo e Gestione delle Infrastrutture Tecnologiche
4. Servizio di Sviluppo di Applicazioni Software
5.2.2 Selezione classi di fornitura e definizione istanze
Per la definizione della fornitura nell’area di attività relativa al Servizio Operatori del Contact Center occorre tenere presente che l’Amministrazione intende esternalizzare tutte le attività degli operatori come già avviene con la fornitura in scadenza per gli operatori di call center. Gli operatori assistono in remoto gli utenti per l’utilizzo dei servizi on line, tele- fonici e di sportello dell’Amministrazione. Si farà quindi riferimento alla Classe di fornitura ASS - Assistenza in Remoto e in Locale, definendo per questa sette istanze, componenti il servizio che si intende realizzare: “Servizio Automatico in Linea”, “Servizio Operatori in Linea”, “Servizio di Interfacciamento ed integrazione con il Back Office dell’Am- ministrazione”, “Servizio Operatori Outbound”, “Servizio di Invio Corrispondenza”, “Sistema di Reporting del servizio”.
Per la fornitura del Servizio di Sviluppo del Sistema di CRM e di KM l’Amministrazione intende avvalersi di prodotti software commerciali di cui acquistare licenza dopo le attività di selezione, personalizzazione ed integrazione con il resto del sistema informativo. Si farà quindi riferimento alla classe PSW di “Personalizzazioni di Prodotti Esistenti”, operando con un’unica istanza per CRM e KM vista la loro forte integrazione.
Per la fornitura del Servizio di Sviluppo e Gestione delle Infrastrutture Tecnologiche necessarie alle funzionalità del Contact Center si farà riferimento alle classi SSI e GSI (Sviluppo e Gestione Sistemi). In particolare le due classi verranno fuse in un’unica Classe di fornitura in quanto trattasi di attività di selezione, personalizzazione e gestio- ne di prodotti Software ed Hardware sia telefonici che di elaborazione dati che forme- ranno l’infrastruttura del Contact Center, che sono e rimarranno di proprietà del fornito- re al termine del periodo contrattuale. Si vuole quindi lasciare libero il fornitore di sce- gliere la configurazione che ritiene più idonea o conveniente, fermi restando i requisiti ed i livelli di servizio richiesti.
Per la fornitura del Servizio di Sviluppo di Applicazioni Software relative ai servizi verso gli utenti in ottica di sportello multicanale si farà riferimento alla Classe di fornitura SSW. Dovendo l’Amministrazione richiedere i servizi da realizzare nel corso del contratto triennale, verranno attivate nel tempo successive istanze di fornitura tutte però afferenti allo stesso modello di pia- nificazione e sviluppo tecnico ed economico definito dall’Amministrazione.
Le dimensioni e la complessità della soluzione Contact Center in termini di integrazione di ser- vizi e di prodotti richiedono che venga posta particolare attenzione alla componente gestiona- le della fornitura sia in fase di realizzazione che di erogazione dei servizi agli utenti.
A tal fine viene presa in considerazione la Classe di fornitura PGE inserendo in essa due istanze, una rivolta alla gestione dello sviluppo ed erogazione dei servizi di contact center ed una relativa alla gestione delle attività di sviluppo applicativo software dei nuovi servizi da mettere a disposizione sullo sportello virtuale unico.
5.2.3 Individuazione delle attività e dei prodotti
89
Le attività ed i prodotti attesi delle singole Classi di fornitura verranno descritti in dettaglio nel Capitolato tecnico, tenendo presente che per ciascuna di esse vi sono diverse aree di attività, in sovrapposizione con le altre, da collocare nella descrizione dei servizi richiesti.
In particolare per la classe ASS le attività ed i prodotti richiesti riguardanti le infrastrutture HW e SW necessarie per il servizio operatori non vengono considerate in quanto collocate
nella classe SSI/GSI; vengono comunque lasciati nella classe ASS i requisiti necessari per la scelta ed il dimensionamento dei sistemi in quanto legati alla descrizione dei processi ed alle caratteristiche delle attività che si vogliono implementare nelle varie istanze della clas- se ASS. Per questa area di servizi è inoltre necessario un dettaglio molto spinto delle esigen- ze e delle misure dei livelli di servizio attesi in quanto è il canale di contatto con gli utenti maggiormente esposto in termini di visibilità, di contenuto e di volumi da erogare.
Per la classe PSW valgono le stesse considerazioni della classe ASS riguardo alle infrastrutture HW e SW necessarie per i sistemi di CRM e KM. Particolare enfasi deve essere data alla descri- zione delle funzionalità che si desidera implementare integrate con il resto del Sistema Informativo per tutti gli ambienti canonici di CRM (operativo, analitico e collaborativo).
Le attività di Sviluppo e Gestione delle infrastrutture HW e SW sono analizzate congiunta- mente in quanto l’Amministrazione, non essendo interessata a rilevare le infrastrutture stes- se al termine del contratto, non intende svolgere attività di verifica, integrazione o gestione ad esse relative. Vanno inoltre considerate in questa area di fornitura anche le attività rela- tive alla rete di connettività del Contact Center e alla logistica delle infrastrutture e dei loca- li per il personale del Servizio Operatori.
Per lo Sviluppo del Software applicativo occorre considerare tutte le attività necessarie per lo sviluppo dei nuovi servizi che scaturiranno dalle attività di reingegnerizzazione dei pro- cessi in atto e le attività di sviluppo per la integrazione di servizi esistenti nel contact cen- ter. Fissato un valore massimo di spesa nei tre anni di contratto, occorre descrivere il meto- do di sviluppo che si desidera adottare per integrare i processi di sviluppo del fornitore con quelli dell’Amministrazione in termini di attività/prodotti, nelle molteplici istanze di forni- tura che verranno attivate nella durata del contratto.
5.2.4 Selezione indicatori di qualità e definizione valori soglia
Dovendo subentrare con questa fornitura ad un contratto di servizio in scadenza, vanno inseriti nel Capitolato, oltre ai consueti piani di sviluppo e collaudo, anche i piani di rilascio con punti di verifica di stato avanzamento lavori e penali per ritardata consegna atti a garan- tire la continuità dei servizi del Call Center attuale.
Data la forte valenza della componente di relazione con gli utenti esterni della soluzio- ne richiesta, particolare attenzione va posta alla misura della qualità del servizio, non solo nel periodo di sviluppo e rilascio della soluzione, ma soprattutto nel periodo di ero- gazione dei servizi richiesti verso gli utenti. Vanno quindi definiti con attenzione gli indi- catori di qualità sia per la disponibilità delle infrastrutture richieste (non inferiore al 99.9% come per i sistemi dell’Amministrazione) sia per tutte le componenti del Servizio Operatori, misurando i tempi di attesa, che non devono essere superiori a quelli attuali, sia del servizio Automatico in Linea (non superiore a 5 sec), sia del Servizio Operatori in Linea (non superiore a 10 sec), sia del Servizio di Outbound (non superiore alle 24 ore). Per questi servizi vanno inoltre misurati i contatti telefonici perduti per controllare la efficacia del servizio operatori verso gli utenti.
90
Per la parte di fornitura relativa allo sviluppo di applicazioni software, trattandosi di servi- zi online, vanno definiti indicatori di livello di servizio sui tempi di risposta delle applica- zioni sviluppate; inoltre, essendo comprese nel servizio richiesto anche le attività di manu- tenzione correttiva, vanno misurati i tempi di risoluzione degli inconvenienti (non superio- ri alle 4 ore per gli errori bloccanti e 24 ore per quelli non bloccanti).
5.2.5 Modulazione delle penali
Per consentire di modulare le penali a fronte del superamento dei valori di soglia degli indi- catori definiti occorre fare presente che l’Amministrazione intende pagare i corrispettivi di fornitura sulla base:
• dei servizi erogati trimestralmente di Gestione e Sviluppo delle infrastrutture HW e SW del Contact Center;
• dei Servizi Operatore erogati trimestralmente per i contatti telefonici, fax, e-mail gestiti;
• sulla base dei singoli rilasci dello sviluppo software dei servizi di contact center.
Le penali sono trattate per livello di servizio:
a) Penali per Ritardo dell’Avviamento del Contact Center (indicatore RSC1)
Il superamento della data di rilascio deve trovare una penale progressiva proporzionale ai tempi di rilascio fino ad un valore massimo che l’Amministrazione definisce di trenta gior- ni oltre il quale occorre scindere il contratto. Per cui si definiscono le seguenti due penali:
• In caso di ritardo – per cause imputabili al Fornitore – nella dichiarazione di “pronti al collaudo” o conclusione delle prove di collaudo con esito positivo per ciascuno dei rilasci a 3, 6, 9, 12 mesi, l’Amministrazione applicherà al Fornitore una penale pari allo 0,2% del corrispettivo della intera fornitura, per ogni giorno solare di ritardo.
• In caso in cui il ritardo relativo alla conclusione delle prove di collaudo con esito posi- tivo, si protragga - per cause imputabili al Fornitore - per un periodo superiore a 30 giorni solari, costituirà grave inadempienza e l’Amministrazione avrà facoltà di dichia- rare la risoluzione di diritto del contratto.
b) Penali per Xxxxxxx di consegna per l’avvio in esercizio del Software Applicativo Sviluppato (Indicatore RSC2)
Xxxxxxx le stesse considerazioni delle penali precedenti, per cui si definiscono le seguenti due penali:
• In caso di ritardo - per cause imputabili al Fornitore - nel rilascio in esercizio delle applicazioni dei servizi di Call Center richiesti, l’Amministrazione applicherà al Fornitore una penale pari allo 0,2% del corrispettivo totale del piano di progetto con- cordato per il rilascio della applicazione richiesta, per ogni giorno solare di ritardo.
• Il caso in cui il ritardo relativo al rilascio in esercizio, si protragga - per cause imputabili al Fornitore - per un periodo superiore a 30 giorni solari, costituirà grave inadempienza e l’Amministrazione avrà facoltà di dichiarare la risoluzione di diritto del contratto.
c) Penali per il Servizio Operatori
91
Il Servizio Operatori prevede nei piani di lavoro del Fornitore un periodo di avviamento durante il quale vengono verificati i requisiti qualitativi richiesti, che non è possibile misurare nella fase di collaudo. Per questo periodo di avviamento, pur rimanendo inalterati i livelli di servizio definiti nel Capitolato, di cui si attende la stabilizzazione, vengono comunque appli- cate penali per indisponibilità del servizio operatori con una quota fissa per punto percentua- le di superamento della soglia definita, fino ad un massimo di indisponibilità del 40%.
• Durante il periodo di avviamento, qualora il “Servizio automatico in linea” (indicato- re DIS11) risulti indisponibile per una percentuale superiore al 20% del tempo totale di servizio previsto, l’Amministrazione applicherà al Fornitore una penale pari a Euro
1.000 (mille) per ogni punto percentuale eccedente detto valore di soglia; il caso in cui detta disponibilità durante il periodo di avviamento, risulti inferiore al 60% del tempo totale di servizio previsto, costituirà grave inadempimento e l’Amministrazione avrà facoltà di dichiarare la risoluzione di diritto del contratto.
• Durante il periodo di avviamento, qualora il “Servizio operatori in linea” (indicatore DIS12) risulti indisponibile per una percentuale superiore al 20% del tempo totale di servizio previsto, l’Amministrazione applicherà al Fornitore una penale pari a Euro
1.000 (mille) per ogni punto percentuale eccedente detto valore di soglia; il caso in cui detta disponibilità durante il periodo di avviamento, risulti inferiore al 60% del tempo totale di servizio previsto, costituirà grave inadempimento e l’Amministrazione avrà facoltà di dichiarare la risoluzione di diritto del contratto.
• Durante il periodo di avviamento, qualora il “Servizio outbound” (indicatore DIS13) risulti indisponibile per una percentuale superiore al 20% sul tempo totale di servizio previsto, l’Amministrazione applicherà al Fornitore una penale pari a Euro 1.000 (mille) per ogni punto percentuale eccedente detto valore di soglia; il caso in cui detta disponibilità, durante il periodo di avviamento, risulti inferiore al 60% sul tempo tota- le di servizio previsto, costituirà grave inadempimento e l’Amministrazione avrà facol- tà di dichiarare la risoluzione di diritto del contratto.
Al termine del periodo di avviamento ogni trimestre verranno applicate penali progres- sive per il superamento dei livelli di soglia per ognuna delle componenti del servizio operatori:
• Al termine di ogni trimestre, relativamente al “Servizio automatico in linea” ed agli indicatori “tempo di attesa“ (TRM1) e “percentuale di contatti entranti perduti” (CR11), l’Amministrazione applicherà al Fornitore una penale pari allo 0,5% dell’importo tri- mestrale del servizio operatori per ogni punto percentuale eccedente i valori di soglia previsti per TRM1 e CR11; relativamente al parametro “percentuale di contatti perduti per overflow del sistema” (CR12), l’Amministrazione applicherà al Fornitore una penale pari allo 0,5% dell’importo trimestrale cumulato delle infrastrutture HW e SW per ogni decimo di punto percentuale eccedente i valori di soglia previsti per CR12.
• Al termine di ogni trimestre, relativamente al “Servizio operatori in linea” ed agli indi- catori “tempo di attesa“ (TRM2), “percentuale di contatti entranti perduti” (CR13), “tempo di risposta a messaggi, fax, e-mail” (TRM3), l’Amministrazione applicherà al Fornitore - previa contestazione dell’addebito e valutazione delle ragioni addotte - una penale pari allo 0,5% dell’importo trimestrale del Servizio Operatori per ogni punto percentuale eccedente i valori di soglia previsti per TRM2, TRM3, CR13.
92
• Al termine di ogni trimestre, relativamente al servizio “Outbound” ed all’indicatore “tempo di attesa“ (TRM4), l’Amministrazione applicherà al Fornitore una penale pari allo 0,5% dell’importo trimestrale del Servizio Operatori per ogni punto percentuale eccedente i valori di soglia previsti per TRM4.
d) Penali per lo sviluppo di software applicativo
Per quanto riguarda i tempi di rimozione degli errori si stabilisce una penale fissa per ogni punto percentuale di superamento dei livelli di soglia; non viene stabilito un tetto massimo in quanto il peso progressivo della penale tende al valore del corrispettivo di manutenzione.
• Al termine di ogni trimestre, relativamente al servizio di manutenzione correttiva in garanzia ed agli indicatori “tempo di intervento e ripristino per guasti bloccanti“ (RERR1), “tempo di intervento e ripristino per guasti non bloccanti” (RERR2), l’Amministrazione applicherà al Fornitore una penale pari a Euro 1.000 (mille) per ogni punto percentuale eccedente i valori di soglia previsti per RERR1 e RERR2.
Per quanto riguarda i tempi di risposta delle transazioni sviluppate si stabilisce una penale fissa per ogni punto percentuale di superamento dei livelli di soglia; non viene stabilito un tetto massimo in quanto la penale viene riproposta ogni trimestre se non si interviene.
• Al termine di ogni trimestre, relativamente al parametro tempi di risposta delle trans- azioni di classe 1 e di classe 2 (TMR1 e TMR2), l’Amministrazione applicherà al Fornitore una penale pari a Euro 500 (cinquecento) per ogni punto percentuale ecce- dente i valori di soglia previsti per TMR1 E TMR2.
e) Penali per lo sviluppo e gestione delle infrastrutture HW e SW
Le infrastrutture sviluppate del Contact Center hanno come indice qualitativo l’affidabilità dei sistemi componenti. Data la forte integrazione di tutte le componenti, si prende come indice di affidabilità dell’intero sistema di Call Center la disponibilità del servizio automati- co, con un tetto massimo oltre il quale l’Amministrazione può scindere il contratto.
• Al termine di ogni trimestre, relativamente alla percentuale di disponibilità del servi- zio automatico in linea (DIS14), si applica una penale pari allo 0,5% dell’importo tri- mestrale cumulato delle infrastrutture HW e SW per ogni decimo di punto percentua- le di scostamento in diminuzione rispetto al valore richiesto di 99,9%.
• A partire dal termine del periodo di avviamento i casi in cui il “Servizio automatico in linea” o il “Servizio operatori in linea” o il “Servizio outbound” risulti indisponibile per una percentuale superiore al 20% sul tempo totale di servizio previsto per ciascun mese, costituiranno grave inadempimento e l’Amministrazione avrà facoltà di dichia- rare la risoluzione di diritto del contratto.
f) Penali per la efficienza di utilizzazione delle risorse (indicatore TRC)
Per ogni sostituzione aggiuntiva alla prima – per cause imputabili al Fornitore – nell’ar- co temporale di dodici mesi, verrà applicata una penale pari all’1% del totale dei servizi di sviluppo annui del periodo di osservazione.
5.2.6 Stesura del capitolato tecnico
93
L’analisi delle macro-attività da richiedere per la realizzazione del Contact Center evidenzia come queste siano fortemente integrate tra loro in termini di contenuto, di dimensionamen- to e di rilascio temporale. Questo aspetto ha spinto l’Amministrazione verso un approccio
di richiesta al mercato di un’unica fornitura esterna, favorendo i rischi di una monofornitu- ra di notevoli dimensioni, rispetto ai rischi di una gestione, molto complessa in termini di contenuti da parte del personale dell’Amministrazione, di più forniture da integrare tra loro. Una possibile alternativa alla monofornitura potrebbe essere quella di richiedere due forni- ture: una relativa alle attività di operatori di call center (che sono una frazione della Classe di fornitura ASS) ed una seconda fornitura per il resto delle restanti attività, lasciando all’Amministrazione il compito della gestione e controllo delle interfacce tra i due fornitori per la realizzazione ed il buon funzionamento del Contact Center.
Un’altra possibile alternativa alla monofornitura potrebbe essere quella di richiedere due forniture: una relativa allo Sviluppo del Software Applicativo ed una seconda per il resto delle restanti attività. In questo caso l’Amministrazione dovrebbe prevedere la verifica ed il controllo del corretto uso delle funzionalità del CRM da parte degli sviluppatori applicativi e la fasatura con le attività e la gestione degli operatori.
La stesura del Capitolato tecnico (vedi pagg da 93 a 118) si riferisce ad un approccio di monofornitura della soluzione richiesta. Vengono descritte le parti del Capitolato tecnico che riguardano:
• il sistema informativo attuale (con particolare attenzione e dettaglio dei servizi che verranno sostituiti in continuità di erogazione dalla fornitura richiesta);
• la descrizione dell’oggetto della fornitura (con riferimento alle classi del dizionario selezionate);
• i volumi in gioco per dare gli elementi di dimensionamento del prodotto/servizio richiesto;
• le modalità di gestione della fornitura che si vogliono adottare (con riferimento alla classe trasversale PGE del dizionario).
Non sono state descritte altre parti del Capitolato riguardanti la formazione e la documen- tazione per semplificare lo scenario e perché meno rilevanti rispetto agli altri servizi presi in considerazione, che caratterizzano la fornitura di un sistema CRM.
Si utilizza lo stile “corsivo” per commenti o indicazioni; lo stile “testo” per riportare parti di Capitolato.
94
CAPITOLATO DI GARA PER L’AFFIDAMENTO DEI SERVIZI DI SVILUPPO E GESTIONE
A. IL SISTEMA INFORMATIVO ATTUALE
A.1 Servizi attuali del Call-Center
A.1.1 Richiesta di duplicato di documento “YYY”
A.2 Servizi attuali del Sito Internet
B. OGGETTO DELLA FORNITURA
B.1 Servizio Operatori
B.1.1 Servizio automatico in linea
B.1.2 Servizio operatori in linea
B.1.3 Interfacciamento ed integrazione con il Back Office dell’Amministrazione
B.1.4 Servizio operatori outbound
B.1.5 Servizio di invio corrispondenza
B.1.6 Sistema di reporting servizio
B.2 Servizio di Sviluppo di un Sistema CRM e KM
B.3 Servizio di Sviluppo e Gestione delle Infrastrutture hardware e software
B.4 Servizio di Sviluppo di Software Applicativo
C. VOLUMI
C.1 Durata dei contatti
C.2 Scalabilità
D. GESTIONE DELLA FORNITURA
D.1 Xxxxxx e Tempi di Esecuzione
D.2 Proprietà delle Componenti
D.3 Personale dell’Amministrazione impiegato
D.4 Personale del Fornitore impiegato
D.5 Monitoraggio del Contratto
D.6 Il piano della qualità
D.7 Gestione dell’Avviamento del Contact Center
D.7.1 Pianificazione complessiva
D.7.2 Piano di continuità del servizio
D.7.3 Piano di sviluppo del CRM e KM
D.7.4 Collaudi
D.7.5 Avviamento
D.8 Gestione di sviluppo software dei servizi di Contact Center
D.8.1 Ciclo di sviluppo
D.8.2 Ambienti di sviluppo e luogo di lavoro
D.8.3 Pianificazione dello sviluppo dei servizi
95
D.8.4 Collaudi
A. IL SISTEMA INFORMATIVO ATTUALE
La prima parte del Capitolato tecnico deve descrivere il contesto organizzativo e tec- nologico in cui si cala la fornitura. Vanno quindi descritte l’organizzazione dell’Amministrazione ed il suo Sistema Informativo/Informatico. In particolare va dettagliata l’architettura informatica esplicitando quali sono i sistemi installati nelle varie sedi, le principali applicazioni, la loro architettura e dove sono collocate, i lin- guaggi di programmazione utilizzati, i database in uso nei vari sistemi e le loro dimensioni.
Dovendo sviluppare il tema del Contact Center, integrando quindi le funzionalità dell’at- tuale Call Center con le funzionalità del sito WEB e dei Sistemi Informativi, vanno descrit- ti in modo analitico e dettagliato tutti i servizi erogati su questi due canali.
A.1 Servizi attuali del Call Center
Occorre riportare l’elenco di tutti i servizi attualmente erogati dal Call Center speci-
ficando per ciascuno di essi, dopo una breve descrizione, gli ambienti con cui inte- ragiscono e le applicazioni richiamate componenti (Architettura Tecnica). Tale descrizione è necessaria per far capire gli ambienti ed il livello di integrazione del Sistema Informativo sui servizi che si andranno a sviluppare con il nuovo Contact Center.
Di seguito è riportato l’esempio di descrizione di un servizio.
omissis
A.1.1 Richiesta di duplicato di documento “YYY”
Gli utenti possono chiedere all’operatore del Call Center informazioni sul documento “YYY” inviato dall’Amministrazione agli utenti ogni 12 mesi.
Un duplicato del documento “YYY” può essere richiesto mediante telefonata al Call Center o tramite il sito Internet dell’Amministrazione.
Il duplicato richiesto telefonicamente verrà automaticamente stampato, imbustato e spedi- to all’interessato.
Il documento ricevuto per posta o stampato dal sito Internet è considerato un documento ufficiale dell’Amministrazione.
Architettura
La procedura effettua automaticamente una richiesta di individuazione della posizione anagra- fica all’Archivio Anagrafico Unico che consente la determinazione univoca dei dati dell’utente. Successivamente, mediante integrazione con la procedura centrale, produce il file di stam- pa in formato PDF, che riproduce esattamente il documento originale inviato all’utente.
Successivamente, le lettere vengono trasmesse al sistema Postel per completare le procedu- re di spedizione.
96
Le lettere così prodotte vengono spedite direttamente al domicilio degli utenti.
La tabella a pagina seguente individua i sistemi dove sono collocate le varie componenti applicative richieste.
CALL CENTER | Server INTERNET | Server Intranet | Mainframe CICS-IMS | ||
Individuazione posizione anagrafica | • | • | • | • | |
Elaborazione contenuti del documento | • | ||||
Produzione file di stampa | • | • | • | ||
Stampa duplicato | • | • | • |
omissis
A.2 Servizi attuali del Sito Internet
Come fatto per i servizi del call center occorre riportare la descrizione di ciascun servi- zio e la sua architettura applicativa, sia per la famiglia dei servizi di informazione che per quella dei servizi di gestione.
B. OGGETTO DELLA FORNITURA
Facendo riferimento alle modalità di descrizione delle Classi di fornitura in questa sezione vanno definiti gli obiettivi della fornitura nel suo insieme e per ogni Classe di fornitura componente le attività richieste, i requisiti, i livelli di servizio attesi.
La progettazione di tutte le componenti lo Sportello Unico dovrà essere tale da garantire una adeguata flessibilità finalizzata a recepire durante il periodo di vigenza contrattuale – in termini di ricadute ed effetti sui servizi dello Sportello Unico stesso – tutti gli eventuali nuovi servizi dell’Amministrazione e le nuove esigenze dell’utenza.
Di seguito vengono elencati i servizi richiesti:
B.1 Servizio Operatori
Prendendo come riferimento la classe ASS ed in particolare il paragrafo di descrizione delle attività e dei prodotti ed il paragrafo di analisi dei requisiti si selezionano le atti- vità che consentono di descrivere il servizio operatori che si vuole richiedere, aggiungen- done eventualmente altre non presenti per una descrizione più completa e consona al caso dell’Amministrazione.
97
Con questa Fornitura l’Amministrazione intende dotarsi di un Servizio dedicato di Operatori, di inbound e di outbound, utilizzando locali e strutture esterne all’Amministrazione (Centri di Servizio), opportunamente organizzati e dimensionati, secondo i requisiti di orario, di servizio, di skill degli operatori, tutor e responsabili di sala, che, in continuità con i servizi dell’attuale Call Center, svolgano le seguenti attività:
• disegno e dimensionamento del servizio operatori inbound e outbound;
• erogazione del servizio operatori negli orari stabiliti per l’intera durata contrattuale;
• gestione complessiva del personale impiegato, operatori, tutor, responsabili (selezio- ne, turnazione, ecc.);
• monitoraggio complessivo della qualità del servizio e interventi finalizzati al migliora- mento della stessa;
• utilizzo di procedure standard documentate, proposte dal Fornitore e approvate dall’Amministrazione, per l’erogazione del servizio, in cui siano chiaramente indicati ruoli, responsabilità, modalità operative e protocolli di comportamento per tutte le attività relative al Servizio Operatori di Call Center.
Il Servizio Operatori dovrà rispondere ai seguenti requisiti di carattere generale che dovran- no essere comunque presi in considerazione anche per la realizzazione degli altri servizi e delle infrastrutture:
• localizzazione preferenziale nelle Regioni del Sud (art. 31 Finanziaria 2002);
• articolazione in due o più siti, tra loro interconnessi, logicamente in maniera unitaria;
• dimensionamento del numero di posti operatore necessario a garantire i livelli di ser- vizio indicati nel presente Capitolato, in ragione dei volumi previsti;
• sezione dedicata ai cittadini disabili: ipovedenti, portatori di handicap motori (portali vocali e servizi a domicilio);
• sezione dedicata alla Provincia di Bolzano, in lingua Tedesca;
• sezione dedicata ai cittadini italiani residenti e che lavorano all’estero;
• sezione dedicata ai lavoratori stranieri: comunitari ed extracomunuitari, con servizi in lingua madre;
• supporto anche agli utenti che navigano in Internet sui siti dell’Amministrazione: pos- sibilità di assistenza telefonica in tempo reale (web Call Center/VoIP).
Il Servizio Operatori potrà essere erogato in diverse modalità e dovrà comprendere le seguenti aree di attività/servizio:
• Servizio automatico in linea;
• Servizio Operatori in linea;
• interfacciamento ed integrazione con il Back Office dell’Amministrazione;
• Servizio Operatori outbound;
98
• Servizio di invio corrispondenza;
• Sistema di reporting del servizio.