Capitolato Tecnico Lotto 1

Il presente Capitolato Tecnico, corredato con le Schede Allegate che saranno citate nel corpo del testo, descrive nel dettaglio lo stato dell‟arte dell‟asset tecnologico oggetto dell‟appalto, nonché i servizi richiesti all‟Impresa aggiudicataria. La descrizione che segue è in linea con quanto anticipato nel Capitolato Speciale d‟Appalto correlato al Bando di Gara e, specificatamente, al Lotto 1 della medesima Gara. Nel seguito il Data Center potrà essere indicato con l‟acronimo “DC” (che pertanto non va inteso come „Data Communication‟).

Si ricorda, per completezza, che il citato Bando di Gara prevede anche un Lotto 2, riguardante un Servizio di Project Management Tecnico e Controllo Qualità delle attività oggetto del Lotto 1. Per il Lotto 2 è stato redatto un apposito e separato Capitolato Tecnico.

Si sottolinea che le Schede Allegate potranno essere oggetto di revisioni utili ad attualizzarle in fase di allestimento del servizio.

Le principali scelte strategiche dell‟Amministrazione in materia informatica riguardano:

⮚ l‟adozione di sistemi standard de jure o de facto,

⮚ la cooperazione, nel medesimo complesso, di ambienti e sistemi operativi eterogenei,

⮚ la concentrazione delle principali applicazioni e banche dati in un‟unica infrastruttura installata presso il Data Center di cui è responsabile il Dipartimento Risorse Tecnologiche e Servizi Delegati,

⮚ la condivisione dei principi sopra indicati e delle scelte di realizzazione da loro discendenti da parte di tutti gli “stakeholder” dell‟ICT dell‟Amministrazione (utenti, imprese di gestione, fornitori di HW, SW e applicazioni, ecc.), nei confronti dei quali l‟Impresa aggiudicataria dovrà impegnarsi alla massima collaborazione.

Le strategie adottate nell‟ambito in argomento prevedono, in particolare:

⮚ di mantenere una architettura HW/SW prevalentemente multi-operativa basata su ambienti UNIX, WINDOWS e LINUX;

⮚ di mantenere aggiornate ai livelli tecnologicamente avanzati le configurazioni Hardware e Software di base (Sistemi Operativi, DBMS e Software d‟Ambiente) dei sistemi di elaborazione e rendere il più possibile omogeneo il software di base installato nelle postazioni di lavoro periferiche dotate di piattaforma Microsoft;

⮚ di mantenere alti i livelli di investimento sulle infrastrutture di Telecomunicazione (rete dati, fonia e radio);

⮚ di operare in base alle regole di documentazione e di Quality Assurance di riferimento e in base a metodologie di progettazione e sviluppo che favoriscano le tecniche di riuso;

⮚ insistere nelle iniziative di “server consolidation” volte a concentrare le applicazioni nel Data Center per massimizzare i servizi di supporto centralizzati operativi in tale ambiente, fruire delle soluzioni di sicurezza disponibili, creare condizioni di maggiore interoperabilità fra banche dati e applicazioni, allestire a minor costo applicazioni con componenti di front end fruibili attraverso i servizi del Portale.

2 ARCHITETTURA DEL SISTEMA INFORMATIVO E TELEMATICO DELL’AMMINISTRAZIONE

L'infrastruttura tecnologica del sistema informativo e telematico dell‟Amministrazione, nelle sue macro componenti, è riassumibile nei seguenti punti:

⮚ presenza di una infrastruttura di comunicazione attraverso la quale si istradano i servizi di trasmissione dati necessari per supportare le attività informatiche dell‟Amministrazione (attualmente sono oltre 220 le sedi comunali interconnesse fra loro);

⮚ presenza di una infrastruttura, centralizzata presso il DC di Roma Capitale, dotata di sistemi di elaborazione mediante i quali si garantiscono le applicazioni principali e vitali per l‟Amministrazione;

⮚ disponibilità di una infrastruttura di rete LAN in ogni ufficio dell‟Amministrazione a servizio di una utenza costituita da circa 14.000 postazioni di lavoro;

⮚ disponibilità di un‟infrastruttura di elaborazione periferica basata su server distribuiti e in via di parziale consolidamento presso lo stesso Data Center.

3 CONFIGURAZIONE HARDWARE E SOFTWARE DEI SISTEMI DI ELABORAZIONE DEL DATA CENTER

Le configurazioni hardware e software dei sistemi di elaborazione installati nel DC – la cui gestione e conduzione è oggetto del presente appalto – e le altre informazioni utili per la valutazione del servizio richiesto sono riportate nelle seguenti schede (dette schede e tutte le altre schede tecniche allegate potranno essere oggetto di aggiornamento):

⮚ Scheda Allegata C – Inventario del software di base e d‟ambiente

⮚ Scheda Allegata D – Inventario degli ambienti e delle applicazioni

⮚ Scheda Allegata E – Inventario dell‟hardware

⮚ Scheda Allegata F – Schemi di configurazione delle infrastrutture hardware

⮚ Scheda Allegata G – Sistema di gestione

⮚ Scheda Allegata H – Logistica e impiantistica del Data Center

⮚ Scheda Allegata I – Servizio e infrastruttura per la Continuità Operativa

⮚ Scheda Allegata N – Carico stampe annuale

L‟insieme delle applicazioni e delle infrastrutture HW e SW descritte nelle schede allegate corrisponde alla situazione attuale del DC. È ovvio che, durante l‟arco temporale della fornitura, ci si devono aspettare evoluzioni – sia quantitative, sia qualitative – delle applicazioni e delle infrastrutture in funzione del mutare delle esigenze degli utenti dell‟Amministrazione (interni ed esterni) e delle normative.

In particolare, e come indicato nel Capitolato Speciale, l‟Amministrazione prevede una evoluzione quantitativa in crescita delle infrastrutture complessivamente sintetizzabile in un 25% anno su anno. Tale previsione deriva dall‟esame del trend storico effettivo, misurato nel quadriennio 2008-2011, che ha visto una crescita:

⮚ del 95% (pari al 25% anno su anno) dei diversi “ambienti” logici di sviluppo, test, collaudo ed esercizio (mediante attivazione di nuovi server fisici e/o nuove macchine virtuali e/o nuove partizioni mainframe),

⮚ del 120% (pari al 30% anno su anno) della potenza di elaborazione dei sistemi installati (in termini di MIPS per i sistemi mainframe o, per i server Intel e Power, di unità di misura tratte dai più comuni benchmark disponibili in letteratura, come il CPU2000 o il CPU2006 dello Standard Performance Evaluation Corporation),

⮚ del 145% (pari al 35% anno su anno) della capacità di memorizzazione a disco.

Dal punto di vista qualitativo – e coerentemente agli standard indicati al Cap. 1 – si può prevedere una sostanziale “tenuta” dell‟architettura attuale (Unisys-Dorado/OS2200, IBM- Power/AIX, Intel/Windows+Linux, DBMS Oracle, Websphere, SAP, ecc.), i cui rispettivi “pesi” potranno tuttavia variare anche significativamente, non esclusa la progressiva eliminazione di alcune componenti. L‟Amministrazione, inoltre, potrà valutare la possibilità di inserire nuove apparecchiature o prodotti nel complesso HW/SW del DC e si riserva di introdurre soluzioni di approvvigionamento, disimpegno e bilanciamento dinamico delle risorse indipendenti dall'hardware utilizzato.

Come già specificato nel Capitolato Speciale (Art. 4), le evoluzioni quantitative e qualitative del DC, nei limiti sopra indicati, non saranno considerate come “variazioni nell‟entità dei servizi appaltati” e, dunque, non incideranno sul canone complessivo previsto dall‟appalto. In altri termini, l‟ambiente descritto dalle schede allegate sopra citate rappresenta il quadro del Data Center al momento dell‟avvio della Fornitura, non ne costituisce vincolo (nei limiti della crescita sopra stimata).

A fronte di tali evoluzioni, inoltre, sarà a carico dell‟Impresa l‟adeguamento delle competenze del proprio personale in modo da assicurare, anche nell‟erogazione dei servizi impattati dal cambiamento, l‟invarianza dei livelli di qualità contrattuali.

4 ALTRE INFORMAZIONI SUL SERVIZIO RICHIESTO

Oltre alle informazioni contenute nelle schede già citate – relative allo stato attuale del DC e, in parte, alle sue evoluzioni attese dall‟Amministrazione – il presente Capitolato Tecnico è corredato di altre cinque schede finalizzate ad una migliore definizione del servizio atteso dall‟Impresa aggiudicataria del Lotto 1 e della documentazione richiesta, ovvero:

⮚ Scheda Allegata A1 – Modello di Offerta Economica

⮚ Scheda Allegata B1 – Modello di Offerta Tecnica

⮚ Scheda Allegata O1 – Ruoli e Responsabilità

⮚ Scheda Allegata P1 – Tabella dei Livelli di Servizio e delle Penali

⮚ Scheda Allegata Q – Modello di Piano di Qualità

5 DESCRIZIONE DEI SERVIZI RICHIESTI

In questa sezione vengono descritti i servizi richiesti all‟Impresa aggiudicataria. La terminologia e la struttura descrittiva dei servizi è affine, per quanto possibile (considerando la realtà di Roma Capitale), a quanto definito da DigitPA nelle sue pubblicazioni (2009-2010) sulla qualità delle forniture dei servizi ICT.

Per ciascun servizio si riportano:

⮚ una descrizione sintetica dello stesso,

⮚ gli obiettivi cui il servizio è finalizzato,

⮚ la lista delle attività attraverso le quali il servizio viene espletato,

⮚ la lista degli SLA tramite i quali Roma Capitale misurerà la qualità di fornitura del servizio stesso (in questa sede gli SLA sono indicati solo in modo qualitativo: la definizione formale degli stessi, con le relative soglie e penali sono oggetto della citata Scheda Allegata P1).

A proposito di quest‟ultimo punto si precisa che, nella definizione formale dei Livelli di Servizio contenuta nella Scheda Allegata P1, si utilizza talvolta il termine Qualità in riferimento a

procedure/processi o ad azioni; per una “lettura” più agevole si precisa che il termine va inteso nel modo seguente

1. la Qualità delle azioni va correlata alla caratteristica fondamentale dell‟efficacia, quindi una azione é Non Conforme, rispetto alla misura del Livello di Servizio, se non si raggiunge il risultato (= risultato assente, incompleto, non definitivo)

2. la Qualità di procedure/processi va correlata alle caratteristiche di efficacia, completezza e consistenza, quindi una procedura/processo é Non Conforme se:

⮚ applicando la procedura (o le linee-guida formalizzate) non si raggiunge il risultato

⮚ si raggiunge il risultato operando in modo diverso da quanto previsto da procedura/linee-guida

⮚ le indicazioni di procedura/linee-guida risultano risultano incomplete o contraddittorie per il caso presentatosi.

Quanto sopra si applica, ovviamente, anche a tutti gli altri riferimenti al termine “Qualità” presenti nell‟intera documentazione di Gara.

In ogni caso, riguardo la qualità dei servizi offerti, sarà di primario riferimento quanto l'Impresa documenterà nel apposito documento (Piano della Qualità) di cui si tratta nel Cap.9.

Nell‟offerta inoltrata all‟Amministrazione l‟Impresa dovrà produrre una propria descrizione dei singoli servizi, specificando con sufficiente dettaglio le modalità di erogazione, le risorse coinvolte, gli strumenti utilizzati e le tempistiche previste per le attività ripetitive.

La descrizione dei servizi dovrà essere poi ulteriormente dettagliata dal‟Impresa aggiudicataria tramite due documenti – da predisporre, per ciascun servizio, a inizio fornitura – ovvero:

⮚ un Manuale Operativo, che descriverà obiettivi, metodologie, procedure, strumenti, ruoli e competenze del personale addetto, ecc.,

⮚ un Piano Operativo, che descriverà le tempistiche delle attività ripetitive.

5.1 GENERALITA’

Al solo scopo di consentire una “lettura” agevole dell‟intero sistema dei servizi richiesti, gli stessi sono stati classificati in tre “Aree”:

1. Area di Governo e Coordinamento: sono i servizi finalizzati, appunto, al governo e al coordinamento generale della fornitura e all‟interfacciamento dell‟Impresa con la Committente Roma Capitale. I servizi di quest‟area potrebbero definirsi “di staff”, ovvero con funzioni di ausilio a tutti gli altri servizi.

2. Area di Innovazione: sono i servizi specificatamente indirizzati all‟evoluzione dell‟infrastruttura HW e SW del DC di Roma Capitale, con due principali obiettivi:

a. adeguare l‟infrastruttura a supportare le nuove esigenze applicative e normative che interverranno nel corso della Fornitura,

b. realizzare le trasformazioni – suggerite soprattutto tramite il Servizio di Sviluppo Sistemi, ricompreso nell‟Area stessa – tese a migliorare continuamente l‟infrastruttura del DC, in termini di efficienza, efficacia, sicurezza, gestibilità, manutenibilità, ecc.

3. Area di Esercizio: sono i servizi “classici” di gestione (operativa, sistemistica, della continuità operativa e della sicurezza logica e fisica) concepiti per permettere il corretto funzionamento quotidiano del DC.

Come anticipato nel Capitolato Speciale, tutti i Servizi di tutte le Aree vengono erogati in modo continuativo e costante. Fa eccezione il Servizio di Sviluppo Sistemi (dell‟Area di Innovazione) che è un “servizio a richiesta” e, come tale, sarà erogato di volta in volta con tempi e modalità concordati con l‟Amministrazione.

5.2 AREA DI GOVERNO E COORDINAMENTO

La complessità della Fornitura, sia per l‟articolazione dei servizi richiesti, sia per l‟eterogeneità dell‟infrastruttura da gestire, richiede un governo e un coordinamento ben definiti in termini di obiettivi, responsabilità, metodi e tempi. Devono essere altrettanto ben definite le interfacce tra l‟Impresa e l‟Amministrazione Committente, nonché le documentazioni che devono essere mante- nute e scambiate tramite dette interfacce.

È opportuno ricordare che, nel governo dei servizi oggetto del presente appalto, l‟Ammini- strazione sarà coadiuvata anche dall‟Impresa aggiudicataria del Lotto 2, che dovrà collaborare sull‟intero progetto, ed in modo particolare sulle attività ricomprese nell‟area di Governo e Coordinamento. Tale ultima Impresa potrà essere indicata di seguito come “Impresa di PMT/CDQ”.

All‟Impresa aggiudicataria del Lotto 1 si richiedono i seguenti servizi:

⮚ un Servizio di Direzione Lavori, finalizzato al governo e al coordinamento di tutti gli altri servizi della Fornitura e ad interfacciare la Committente, gli altri “attori” coinvolti nel funzionamento del DC (Fornitori di Applicazioni, Fornitori HW e SW, Ente locatore, ecc.) e l‟Impresa aggiudicataria del Lotto 2 (servizio di PMT/CDQ),

⮚ un Servizio di Controllo dei Livelli di Servizio, finalizzato a monitorare e rendicontare i livelli di servizio forniti dall‟Impresa nel corso del contratto,

⮚ un Servizio di Documentazione, finalizzato a produrre, gestire, aggiornare e scambiare con la Committente, tutta la documentazione richiesta dai singoli Servizi.

5.2.1 DLA – SERVIZIO DI DIREZIONE LAVORI

5.2.1.1 Descrizione generale del servizio

La Fornitura, in ragione dell‟articolazione dei servizi richiesti e dell‟infrastruttura da gestire, nonché del numero di interfacce con le quali si dovrà confrontare (in primis l‟Amministrazione, ma poi anche gli altri “attori” coinvolti, come i Fornitori HW e SW, quelli Applicativi, l‟Ente locatore, ecc.) richiede un‟organizzazione di governo e coordinamento ben definita.

A tal fine si ritiene utile strutturare questa organizzazione (fatta di persone e procedure) in un vero e proprio servizio ad hoc, qui descritto.

5.2.1.2 Obiettivi del servizio

Gli obiettivi primari del servizio sono due:

⮚ un obiettivo “interno” all‟Impresa, finalizzato al coordinamento di tutte le risorse impegnate, nel quadro di una visione d‟insieme degli altri 10 servizi forniti. Il coordinamento deve essere effettuato controllando costantemente, tra l‟altro:

o il rispetto degli obiettivi e dei tempi condivisi con l‟Amministrazione,

o il rispetto dei Livelli di Servizio,

o la corretta soluzione dei “conflitti” in funzione delle priorità stabilite dall‟Amministrazione,

o l‟ottimizzazione di allocazione delle risorse condivise tra più servizi,

o l‟approssimarsi di eventuali situazioni critiche (di risorse, scadenze, rischi operativi, ecc.) con l‟obiettivo di effettuare una prima analisi interna all‟Impresa e poi, se è il caso, allertare l‟Amministrazione,

⮚ un obiettivo “esterno”, relativo a un interfacciamento prioritario con la stessa Amministrazione (coadiuvata, come detto, da un‟Impresa responsabile del PMT/CDQ) e, secondariamente, con gli altri “attori” coinvolti. A tal proposito è opportuno sottolineare che mentre l‟interfacciamento con l‟Amministrazione è un obiettivo primario del servizio (e ruolo e compito fondamentale di chi lo svolge) e dunque l‟Impresa ne è pienamente responsabile, quello con gli altri “attori” (Fornitori, utenti, Enti terzi) è “strumentale” allo svolgimento della Fornitura e, in genere, sarà effettuato in condivisione con i referenti dell‟Amministrazione (che sono i veri committenti). In altri termini, le eventuali situazioni di “conflitto” con gli altri attori dovranno essere risolte dall‟Amministrazione, eventualmente con il supporto tecnico/organizzativo dell‟Impresa.

5.2.1.3 Attività ricomprese nel servizio

Le principali attività svolte dal servizio sono:

⮚ il coordinamento delle attività di gestione di tutti i Servizi offerti nel Contratto e delle risorse dell‟Impresa coinvolte. L‟Impresa è ovviamente libera di definire, al suo interno, un‟organizzazione intermedia di coordinamento che preveda, ad esempio, singoli responsabili dei diversi servizi, tuttavia l‟Amministrazione farà in ogni caso riferimento alle due figure di seguito descritte (Responsabile di Gestione e Responsabile del Progetto);

⮚ il supporto e l‟affiancamento dell‟Amministrazione in tutti i rapporti a carattere tecnico/organizzativo con gli altri “attori” coinvolti nella gestione del DC (Applicativi, Fornitori HW e SW, Ente locatore);

⮚ una continua verifica sulla gestione generale della Fornitura e sull‟efficacia/efficienza del DC, evidenziando eventuali aree di miglioramento e proponendo all‟Amministrazione interventi di ottimizzazione sia sulle politiche e sulle procedure gestionali (nei limiti stabiliti dal Contratto), sia sulle scelte tecnologiche;

⮚ il monitoraggio continuo, nel suo complesso, della qualità dei servizi di gestione dell‟intera infrastruttura oggetto del servizio.

L‟Amministrazione chiede all‟Impresa di assegnare la responsabilità del servizio ad una sua risorsa ben identificata, denominata “Responsabile di Gestione”, che comunicherà ufficialmente con la Amministrazione. Ovviamente l‟Impresa è libera di definire una catena di deleghe e sostituzioni al suo interno, ma l‟Amministrazione farà comunque riferimento alla figura che le è stata comunicata.

Al fine di rendere trasparente e rapido il meccanismo d‟interfacciamento, da parte sua l‟Amministrazione definisce un “Direttore Tecnico dei Lavori” che fungerà da controparte del Responsabile di Gestione.

Amministrazione e Impresa avranno poi un livello più alto (meno operativo) d‟interfacciamento, attraverso le due figure di Responsabile del Progetto (per l‟Impresa) e del Responsabile del Contratto (per l‟Amministrazione), che non hanno, ovviamente, alcun ruolo “di servizio”. La tabella seguente indica, in modo schematico, i ruoli e le principali competenze delle quattro figure indicate:

AMMINISTRAZIONE

IMPRESA Lotto 1

Responsabile del Contratto

Responsabile del Progetto

cura i rapporti di alto livello con l’Impresa verifica la corretta fornitura del Servizio nel suo complesso

autorizza gli interventi straordinari richiesti dall’Impresa

esamina le contestazioni sottoposte

cura i rapporti di alto livello con l’Amministrazione

comunica tempestivamente le problematiche e le novità più rilevanti

sottopone all’Amministrazione l’approvazione di eventuali interventi straordinari e rilevanti

dall’Impresa e prende le necessarie decisioni a riguardo

approva i corrispettivi trimestrali, autorizzando, in particolare, l’applicazione delle eventuali penali indicate dal Direttore Tecnico dei lavori

approva l’esecuzione degli interventi a richiesta vagliati tecnicamente dal Direttore dei Lavori

discute con l’Impresa le eventuali segnalazioni di possibili necessità di adeguamenti del canone

non previsti dal contratto

sottopone all’Amministrazione eventuali contestazioni relative ai servizi erogati

segnala preventivamente e per tempo

all’Amministrazione ogni situazione anomala che, a detta dell’Impresa, potrebbe giustificare un adeguamento del canone

Direttore Tecnico dei Lavori

Responsabile di Gestione

partecipa con il Responsabile di Gestione dell’Impresa a tutte le riunioni di SAL stabilite dal contratto e a tutte le riunioni necessarie con gli altri “attori” coinvolti nel funzionamento del DC, ovvero:

o Fornitori HW e SW

o Ente locatore

o Fornitori di altri servizi ICT (es.: tlc)

o Fornitori di Servizi Applicativi

riceve e valuta tecnicamente tutta la documentazione tecnica prodotta dall’Impresa, con particolare attenzione a:

olivelli di servizio,

ocapacity planning,

osegnalazioni di criticità della sicurezza logica o fisica

in caso di mancato rispetto dei livelli di servizio che implichino – secondo contratto – l’applicazione di penali, ne calcola l’importo e ne sottopone l’approvazione al Responsabile del Contratto

valuta tecnicamente gli interventi a richiesta proposti dall’Impresa o alla stessa richiesti e sottopone all’approvazione del Responsabile del Contratto quelli che ritiene utili ed economicamente efficaci

effettua il monitoraggio (mediante appositi SAL) degli interventi a richiesta approvati e avviati, segnalando tempestivamente all’Impresa eventuali significativi scostamenti

dai piani concordati

partecipa con il Direttore Tecnico dei Lavori dell’Amministrazione a tutte le riunioni di SAL stabilite dal contratto e a tutte le riunioni necessarie con gli altri “attori” coinvolti nel funzionamento del DC, ovvero:

o Fornitori HW e SW

o Ente locatore

o Fornitori di altri servizi ICT (es.: telecomunicazioni)

o Fornitori di Servizi Applicativi

effettua un “super-coordinamento” dei diversi Servizi, curando in particolare le attività di un certo rilievo “cross” tra due o più di essi controlla i livelli di servizio

garantisce l’applicazione delle procedure e delle metodiche stabilite dal contratto

All‟avvio della Fornitura, l‟Amministrazione e l‟Impresa definiranno congiuntamente un‟agenda di incontri periodici finalizzati a istituzionalizzare un livello minimo garantito di interfacciamento per la gestione del Contratto. Tali incontri saranno poi integrati, durante la Fornitura, dagli altri scambi che si renderanno necessari in funzione delle problematiche riscontrate e delle attività da svolgere.

Gli incontri periodici potranno avere obiettivi diversi, cui corrisponderanno di conseguenza anche scadenze e partecipanti diversi. L‟Amministrazione chiede comunque, come minimo:

⮚ un incontro settimanale tra Direttore Tecnico dei Lavori e Responsabile di Gestione, per l‟esame delle attività in corso,

⮚ un incontro mensile di tutte e quattro le figure con i rappresentanti dei Fornitori delle Applicazioni, per l‟esame delle principali attività e delle problematiche inerenti il DC che coinvolgono le applicazioni (creazione di nuovi ambienti, rilasci in produzione di significativa entità, eventuali gravi problematiche in corso, migrazioni software, analisi prestazionali, ecc.).

In generale, in tutti gli incontri di cui sopra l‟Amministrazione sarà supportata dall‟Impresa di PMT/CDQ.

5.2.1.4 SLA relativi al servizio

È evidente che il Servizio ha un profilo di alto livello gestionale, difficilmente misurabile con SLA di tipo quantitativo. Ne sono stati comunque definiti, con riferimento al rispetto del protocollo d‟interfacciamento condiviso e alla rapidità d‟aggiornamento della documentazione di rendicontazione del servizio stesso (verbali degli incontri in agenda).

5.2.2 CLS – SERVIZIO DI CONTROLLO DEI LIVELLI DI SERVIZIO

L'Impresa, durante tutto l'arco contrattuale, dovrà garantire il livello dei servizi offerti secondo le modalità e la qualità definite in questo Capitolato Tecnico e nell‟apposita Scheda Allegata P1. A tale proposito, l‟ Impresa è tenuta ad effettuare una continua rilevazione dei livelli di servizio offerti, curandone anche la relativa rendicontazione all‟Amministrazione, con la produzione di apposita reportistica. Di ciò si occupa questo Servizio.

5.2.2.1 Descrizione generale del servizio

Come descritto in questo stesso documento, ognuno degli 11 Servizi offerti dall‟Impresa viene valutato, dal punto di vista qualitativo, mediante alcuni parametri (Livelli di Servizio) che ne caratterizzano l‟erogazione. Questi parametri sono informalmente descritti negli appositi paragrafi di ciascun servizio, mentre la Scheda Allegata P1 li elenca dettagliatamente, in forma tabellare, indicando per ciascuno di essi le modalità di rilevazione e calcolo, le soglie di accettazione da parte dell‟Amministrazione, nonché i parametri di calcolo delle penali, in caso dette soglie non vengano rispettate.

È chiaro che un argomento così delicato, richieda un servizio ad hoc per il controllo costante dei Livelli di Servizio definiti, al fine di evitare disagi all‟Amministrazione e problemi contrattuali all‟Impresa.

È altresì evidente come il controllo dei Livelli di Servizio, per essere efficace a 360°, debba essere organizzato, dall‟Impresa, con modalità tecnico/organizzative che permettano una verifica predittiva dell‟andamento “tendenziale” dei Livelli di Servizio, in modo da poter intervenire sui livelli qualitativi di erogazione dei servizi prima che questi siano “fissati” dai processi periodici di calcolo e rendicontazione. Insomma il servizio deve provvedere non solo ad una passiva rendicontazione “ex post” della qualità dei servizi erogati, ma anche ad utilizzare “ex ante” la raccolta continua dei dati necessari alla misura dei Livelli di Servizio e la loro elaborazione mirata, come “sensori” sempre attivi, che possono prevenire eventuali situazioni di degrado. Questa funzione di controllo preventivo è il principale obiettivo del servizio.

5.2.2.2 Obiettivi del servizio

In coerenza con quanto sopra descritto, gli obiettivi del servizio sono così sintetizzabili:

⮚ verifica continua della rispondenza dei Livelli di Servizio dei vari servizi del Contratto, con gli obiettivi richiesti dall‟Amministrazione, tramite il medesimo;

⮚ attivazione di interventi (all‟interno dell‟Impresa, ma non solo) di reazione ad eventuali segnali di degrado dei Livelli di Servizio, al fine di evitare (possibilmente in via preventiva) il superamento delle soglie stabilite dal Contratto;

⮚ rendicontazione periodica dei Livelli di Servizio, secondo le modalità e le tempistiche indicate dal Contratto;

⮚ discussione con l‟Amministrazione di eventuali casi controversi di misurazione di Livelli di Servizio, soprattutto nei casi di contestazione di superamento delle soglie.

5.2.2.3 Attività ricomprese nel servizio

In fase di Allestimento del Servizio (inteso come intero “servizio di gestione del D.C.”, dunque nei primi tre mesi della Fornitura), l‟Impresa e l‟Amministrazione potranno concordare eventuali maggiori dettagli tecnico/organizzativi di misurazione dei Livelli di Servizio definiti in questo Capitolato Tecnico e nella specifica Scheda Allegata P1, i cui criteri generali e le cui rispettive penali non saranno però modificabili.

L'Impresa è quindi tenuta a produrre, con le periodicità indicate nella Scheda Allegata P1, dei report standard che, sulla base degli indicatori concordati, offrano una visione dell‟andamento delle metriche di qualità di ciascun servizio erogato come dettagliatamente definito nella citata scheda allegata. Nel caso del report mensile di eventuali livelli non conformi (Livello di Servizio 2.01 della Scheda Allegata P1) si ha un report non standard, bensì a contenuto variabile, fino alla semplice comunicazione di assenza di segnalazioni.

A tale proposito, ed a supporto della funzione di controllo preventivo, si richiede all'Impresa di:

⮚ definire, documentare e validare uno specifico processo di gestione dei livelli di servizio, che preveda la raccolta continua dei dati necessari alla misura;

⮚ avvalersi di un insieme di strumenti atti ad elaborare i dati ed a fornire la reportistica richiesta e con cui l'Amministrazione possa condividere il monitoraggio della qualità dei servizi erogati.

I dati raccolti per la misura dei Livelli di Servizio devono essere accessibili – direttamente o in copia aggiornata entro un giorno lavorativo - all‟Amministrazione ed all‟Impresa di PMT/CDQ.

L'Impresa è inoltre tenuta a comunicare all‟Amministrazione gli eventuali interventi attivati al suo interno in reazione ad eventuali segnali di degrado dei Livelli di Servizio.

I Livelli di Servizio richiesti prescindono da eventuali malfunzionamenti derivanti da impedimenti e condizioni d‟ ambiente non gestibili attraverso il presente appalto (es.: alimentazione elettrica, impianto di condizionamento, attività di altri fornitori autorizzati dall‟Amministrazione ad operare direttamente su alcune componenti infrastrutturali del sistema informativo di Roma Capitale).

5.2.2.4 SLA relativi al servizio

La qualità del Servizio di Controllo dei Livelli di Servizio viene misurata sulla disponibilità on- line degli aggiornamenti della reportistica di competenza e sulla disponibilità dei dati di misura.

5.2.3 PGD – SERVIZIO DI DOCUMENTAZIONE

5.2.3.1 Descrizione generale del servizio

Il progetto derivante dal presente capitolato sarà di dimensioni, complessità e durata tali da dover prevedere una struttura formale di supporto – soprattutto al Responsabile di Progetto e al Responsabile dei Lavori – per la gestione delle comunicazioni e della documentazione. A tale scopo è appositamente dedicato questo Servizio.

Come richiesto per tutti i servizi, l‟Impresa aggiudicataria dovrà descrivere le modalità di esecuzione delle attività previste dal servizio nel Manuale Operativo, mentre la loro

tempificazione sarà indicata nel Piano Operativo. I due documenti saranno predisposti e mantenuti dall‟Impresa d‟intesa con l‟Amministrazione.

5.2.3.2 Obiettivi del servizio

Gli obiettivi del servizio sono:

⮚ definire, servizio per servizio, i documenti che devono essere prodotti, la loro tipologia (documenti operativi, documenti di progetto), la loro struttura di massima (contenuti e forma), la periodicità di aggiornamento, tempi e modi di distribuzione all‟Amministrazione,

⮚ controllare che la documentazione prodotta rispetti le definizioni di cui sopra,

⮚ progettare e realizzare un Repository di tutta la documentazione, accessibile on-line dall‟Impresa e dall‟Amministrazione secondo regole prestabilite,

⮚ assicurare il costante aggiornamento dei contenuti di tale Repository.

Si intende che la “definizione dei documenti che devono essere prodotti” non può prescindere dal “corpus” documentale minimo richiesto, descritto in questo Capitolato e riassunto nell‟apposito capitolo 8.

5.2.3.3 Attività ricomprese nel servizio

A parte le attività iniziali del Servizio (definizione di dettaglio del “corpus” documentale per l‟intero Contratto e progettazione e realizzazione del relativo Repository), le attività continuative del servizio sono:

⮚ supportare i responsabili dei diversi Servizi nella produzione di tutta la documentazione di progetto, con particolare attenzione al Piano della Qualità e ai Manuali e Piani Operativi, e con riferimento anche ai verbali delle sedute dei vari comitati previsti, alle documentazioni specifiche di progetto e alle comunicazioni di qualsiasi tipo e formato;

⮚ garantire la memorizzazione nel Repository di tutta la documentazione prodotta e la custodia – ove eventualmente richiesto (ad es. in caso di presenza di firme) – del formato cartaceo dei documenti, verificando la corrispondenza formale e sostanziale tra le versioni elettroniche e cartacee,

⮚ assicurare la disponibilità on-line (Intranet) e/o la distribuzione cartacea della documentazione di progetto a tutti gli aventi diritto (nell‟Impresa, presso l‟Amministrazione e presso l‟Impresa aggiudicataria del Lotto 2);

⮚ assicurare lo scambio di comunicazioni ufficiali tra Amministrazione e Impresa.

5.2.3.4 SLA relativi al servizio

La qualità del Servizio viene misurata sul rispetto della richiesta frequenza di aggiornamento dei diversi documenti e sulla disponibilità on-line (Repository) delle ultime versioni dei medesimi.

5.3 AREA DI INNOVAZIONE

Il complesso costituito dalle infrastrutture hardware, software e procedurali del DC costituisce un organismo in continua trasformazione evolutiva, sia per ragioni funzionali (nuovi servizi IT forniti dall‟Amministrazione), sia per ragioni fisiologiche (crescita dei volumi dell‟utenza), sia per ragioni normative (nuove regole imposte dall‟esterno), sia, infine, per ragioni di adeguamento tecnologico (superamento delle inevitabili obsolescenze dell‟hardware e del software utilizzato).

Gli aspetti a carattere più quantitativo di tale evoluzione sono stati evidenziati già nel Capitolato Speciale, dove si è sottolineato che l‟Amministrazione si aspetta, nel triennio della Fornitura, una crescita dal 25% al 35%, anno su anno (secondo gli elementi in considerazione), delle dimensioni del DC. L‟evoluzione, tuttavia, non sarà solo quantitativa, in quanto potranno intervenire, in qualsiasi momento, tutti gli altri fattori sopra accennati a generare la necessità di modifiche architetturali in qualche caso anche significative.

Allo scopo di governare questo processo di continua trasformazione del DC, si chiedono all‟Impresa due servizi:

⮚ un Servizio di Evoluzione Programmata dei Sistemi, finalizzato soprattutto al governo degli aspetti più prevedibili (e perciò “programmabili”) della trasformazione. Tra questi, tipicamente, quello della crescita quantitativa dei volumi trattati (in genere prevedibili e programmabili tramite un processo di Capacity Planning) e quello delle modifiche dovute ad esigenze applicative (anch‟esse prevedibili e programmabili),

⮚ un Servizio di Sviluppo Sistemi, finalizzato invece al governo dei fattori di trasformazione meno prevedibili (almeno a medio-lungo termine), come l‟inserimento di un nuovo prodotto hardware o software la cui utilità non era prevista, ovvero l‟improvvisa esigenza di adottare nuove metodiche imposte dalla normativa o di effettuare interventi urgenti richiesti dal vertice dell‟Amministrazione. In questo secondo servizio, inoltre, saranno ricomprese anche attività a carattere più prettamente “consulenziale”, ovvero finalizzate al suggerimento di interventi tecnologici per il miglioramento dell‟intera struttura del DC.

È dunque evidente che il primo servizio sarà effettuato in modo continuativo, secondo le indicazioni di seguito riportate. Il secondo servizio, invece, sarà fornito attraverso una serie di interventi effettuati con modalità tipicamente “a progetto”, ciascuno dei quali seguirà un suo iter che partirà da una proposta, passerà per uno stadio autorizzativo, per essere poi eseguito e monitorato.

Come indicato nel Capitolato Speciale, l‟impegno richiesto all‟Impresa per il Servizio di Sviluppo Sistemi sarà stabilito di volta in volta in base alle esigenze dei singoli progetti. Si stabilisce fin d‟ora, comunque, che l‟Impresa dovrà rendere disponibili due diverse figure professionali, una di profilo elevato (es. “architetto” o “analista” ICT), l‟altra a carattere più operativo (es. “sistemista senior”), in misura necessaria caso per caso, per un ammontare cumulativo massimo per l‟intero mandato pari a:

⮚ n° 180 gg/uomo per la figura di tipo alto,

⮚ n° 300 gg/uomo per la figura di tipo più operativo.

Si sottolinea, inoltre, che le proposte dei “progetti” del Servizio di Sviluppo Sistemi possono partire:

⮚ dall‟Amministrazione, nel momento in cui riceve indicazioni su interventi che richiedono, appunto, un approfondimento tecnologico sul DC, o qualora sollecitata da Fornitori hardware o software che propongono l‟adozione di particolari nuove tecnologie,

⮚ dall‟Impresa stessa, che – con atteggiamento proattivo – deve costantemente considerare le aree di possibile ottimizzazione tecnologica e/o organizzativa del DC e proporre all‟Amministrazione, ove lo ritenga utile, corrispondenti interventi migliorativi.

Si chiarisce, infine, che i due servizi di quest‟area hanno carattere prevalentemente di analisi progettuale. I loro prodotti saranno generalmente rapporti (es. di Capacity Planning), studi di fattibilità, relazioni tecniche, pianificazioni di massima di progetti realizzativi, ecc. La progettazione operativa e la successiva realizzazione degli interventi che poi saranno effettivamente approvati dall‟Amministrazione ed effettuati, saranno oggetto dei Servizi dell‟Area di Esercizio (ad esempio del Servizio di Manutenzione Sistemi) o anche di altre forniture ad hoc assegnate ad altre Imprese.

5.3.1 EPS – SERVIZIO DI EVOLUZIONE PROGRAMMATA DEI SISTEMI

5.3.1.1 Descrizione generale del servizio

Il servizio ha lo scopo principale di rendere sostenibile l‟evoluzione “ordinaria” del DC, che è determinata principalmente da due istanze: una soprattutto “qualitativa”, derivante principalmente dalla trasformazione evolutiva dei servizi applicativi, l‟altra prevalentemente “quantitativa”, che dipende dalla crescita fisiologica dei volumi trattati (numero di transazioni, di utenti, di dati gestiti e acceduti, di stampe prodotte, di messaggi inviati, ecc.).

5.3.1.2 Obiettivi del servizio

Gli obiettivi del servizio sono sostanzialmente due:

⮚ supportare lo sviluppo applicativo ordinario, con le necessarie conoscenze tecnologiche (sistemi operativi, DBMS, prodotti per lo sviluppo ed il test, ecc.) dell‟ambiente attuale del DC, al fine di velocizzare le attività dei gruppi applicativi, riducendone gli eventuali errori relativi alle infrastrutture e al loro utilizzo ottimale;

⮚ predisporre e poi gestire un processo continuo di controllo sull‟utilizzo delle risorse hardware e software di base del DC, stimandone costantemente il trend di crescita in relazione ai volumi applicativi trattati, al fine di prevedere per tempo le eventuali situazioni di saturazione ed elaborare strategie di soluzione alle stesse, tramite interventi operativi sulle infrastrutture esistenti ovvero – nel caso ciò non risolva – tramite tempestiva sollecitazione all‟Amministrazione di un loro potenziamento.

5.3.1.3 Attività ricomprese nel servizio

Supporto sistemistico allo sviluppo e rilascio dei servizi applicativi

L‟Impresa dovrà garantire un supporto di tipo tecnico sistemistico nell‟ambito della definizione delle architetture e delle soluzioni tecnologiche adottate per lo sviluppo o la modifica di piattaforme applicative per l‟erogazione dei servizi istituzionali e strumentali dell‟Amministrazione. Nello specifico, il supporto richiesto vede un coinvolgimento del personale dell‟Impresa nelle seguenti fasi del ciclo di vita di un‟applicazione di business dell‟Amministrazione:

⮚ studi di fattibilità: nella definizione e validazione di ipotesi di soluzione in relazione alle piattaforme tecnologiche hardware e software adottate, sia infrastrutturali che gestionali;

⮚ disegno delle specifiche funzionali ed architetturali: nel supporto specialistico e documentale alla definizione delle specifiche e/o nella verifica e validazione del disegno proposto da società esterne o dalla stessa Amministrazione nella definizione di specifici servizi applicativi;

⮚ disegno gestionale: nella definizione e/o validazione delle specifiche e delle architetture relative all‟infrastruttura di gestione a supporto di specifici servizi applicativi;

⮚ sviluppo del codice e delle procedure: supporto specialistico e di validazione, per gli aspetti di tipo tecnologico ed infrastrutturale, nello sviluppo di codice e di procedure applicative;

⮚ test funzionali e di integrazione: supporto specialistico e di validazione nella definizione dei test di verifica dei servizi applicativi prima del loro rilascio in ambiente di produzione;

⮚ rilasci in ambiente di produzione: supporto specialistico nella definizione dei piani e delle procedure di rilascio in produzione dei servizi applicativi;

⮚ analisi dei problemi: supporto specialistico, nell‟ambito delle competenze infrastrutturali e tecnologiche, per l‟analisi e la risoluzione di problemi di tipo applicativo;

⮚ procedure di aggiornamento: supporto specialistico nella definizione e validazione delle modalità di esecuzione degli aggiornamenti ai servizi applicativi.

Nell‟ambito di questo servizio l‟ Impresa deve anche garantire la disponibilità di proprio personale specializzato per l‟effettuazione di limitate attività di programmazione quali, ad esempio, la scrittura di software di servizio, lo sviluppo di fix o la preparazione di specifiche procedure di installazione.

Il servizio richiesto deve anche indirizzare attività di supporto nelle fasi di definizione e realizzazione degli standard architetturali e tecnologici alla base dell‟intera infrastruttura del sistema informatico comunale, nell‟ambito delle competenze sistemistiche coinvolte dall‟erogazione dei servizi del presente appalto.

Sarà responsabilità dell‟Amministrazione definire, concordare e gestire le modalità d‟interazione del personale dell‟Impresa con quello delle diverse società incaricate dall‟Amministrazione dello sviluppo delle proprie applicazioni di servizio.

Supporto alla pianificazione delle risorse

Questa parte del Servizio di Evoluzione Programmata dei Sistemi richiede all‟Impresa di adottare metodologie, procedure e strumenti che, sulla base delle strategie e dei piani di crescita del sistema informatico Comunale e/o dei livelli di servizio richiesti dall‟Amministrazione nell‟erogazione dei servizi IT, siano in grado di fornire gli elementi dimensionali necessari per la definizione dei piani di adeguamento delle risorse operative e di sistema.

L‟Impresa dovrà quindi effettuare costantemente operazioni di rilevazione e misurazione dell‟utilizzo delle principali risorse informatiche, quali ad esempio:

⮚ capacità di elaborazione delle diverse unità di sistema;

⮚ capacità di elaborazione e di immagazzinamento delle unità di storage e di archiviazione dei dati;

⮚ capacità trasmissiva delle unità e dei dispositivi di rete;

e dovrà periodicamente, almeno su base trimestrale, farne rapporto all‟Amministrazione.

In base all‟analisi dei trend di crescita dei valori di consumo delle principali risorse del DC, l‟Impresa dovrà definire con l‟Amministrazione i relativi piani di adeguamento delle risorse (“Capacity Planning”).

In particolare, a partire dall‟elaborazione statistica dei dati forniti dagli strumenti di analisi adottati e dall‟individuazione delle tendenze presenti nell‟uso corrente delle risorse, deve essere possibile effettuare proiezioni di medio periodo, fornendo all‟Amministrazione gli elementi necessari per definire:

⮚ l‟evoluzione richiesta agli asset informatici di sistema e di sottosistema;

⮚ le azioni di adeguamento di vari parametri di configurazione dei sistemi e sottosistemi;

⮚ un utilizzo ottimale, da parte degli utenti, delle risorse informatiche in funzione dei carichi di lavoro.

I dati raccolti devono inoltre permettere di individuare eventuali e potenziali criticità nell‟utilizzo delle risorse informatiche, rispetto ai requisiti dettati dai livelli di servizio correnti, e, quindi, di intraprendere opportune azioni correttive al fine di prevenire un possibile degrado delle prestazioni dei servizi informatici offerti internamente ed esternamente dall‟Amministrazione.

5.3.1.4 SLA relativi al servizio

Per quanto riguarda il supporto sistemistico allo sviluppo applicativo, tutte le attività previste – fatta salva l‟estemporaneità caratteristica delle attività di supporto all‟analisi ed alla risoluzione dei problemi applicativi – saranno effettuate dal personale dell‟Impresa in modalità prevalentemente progettuale e sulla base di un Piano di Lavoro concordato con i responsabili dell‟Amministrazione. Le attività richieste avranno come oggetto la produzione di specifiche relazioni e/o di documentazioni di specifica funzionale e/o architetturale.

Ne deriva che la qualità del servizio verrà determinata sulla base della disponibilità dimostrata dall‟Impresa a fornire il supporto richiesto, nei tempi di volta in volta concordati.

Per quanto riguarda l‟attività di Capacity Planning la qualità del servizio viene invece misurata sulla tempestiva disponibilità on-line dei rapporti trimestrali.

5.3.2 SSI – SERVIZIO DI SVILUPPO SISTEMI

5.3.2.1 Descrizione generale del servizio

Nel quadro di questo servizio, l‟Impresa dovrà progettare gli interventi sulle infrastrutture e le procedure gestionali del DC rese necessarie da modifiche (applicative, normative, tecnologiche) richieste nel corso della Fornitura.

Si richiede inoltre all‟Impresa, attraverso un‟accurata analisi e valutazione dell‟insieme delle infrastrutture affidate a inizio Fornitura nonché dei processi gestionali in essere, di proporre all‟Amministrazione eventuali interventi tecnici e/o organizzativi finalizzati a migliorare il funzionamento generale del sistema in termini di efficienza, efficacia, sicurezza, gestibilità, manutenibilità, ecc.

Ovviamente le analisi dell‟Impresa potranno essere avviate anche su richiesta dell‟Amministrazione (in particolare in fase di avvio della Fornitura) e saranno comunque sempre indirizzate secondo i requisiti e le priorità dalla stessa espresse. Tuttavia, come già detto, il servizio non deve operare esclusivamente con modalità reattive rispetto alle richieste che emergono nel corso della Fornitura, ma deve rappresentare un supporto valido, continuo e proattivo, grazie a competenze specialistiche, all‟individuazione di nuove opportunità di miglioramento dei processi e di ottimizzazione nell‟utilizzo di risorse tecniche, umane ed economiche.

Come richiesto per tutti i servizi, l‟Impresa aggiudicataria dovrà descrivere le modalità di esecuzione delle attività previste dal servizio nel Manuale Operativo, mentre la loro tempificazione sarà indicata nel Piano Operativo (vista la peculiarità di questo servizio, il Piano Operativo sarà prevedibilmente molto scarno, limitandosi, ad esempio, ad indicare alcune scadenze periodiche di condivisione con l‟Amministrazione dello stato dell‟arte del Data Center e delle proposte progettuali presentate/autorizzate/in corso, nonché di evidenziazione di esigenze o criticità particolari). I due documenti saranno predisposti e mantenuti dall‟Impresa d‟intesa con l‟Amministrazione.

5.3.2.2 Obiettivi del servizio

L‟obiettivo primario del Servizio è quello di progettare interventi sulle infrastrutture del DC:

⮚ resi necessari da attività straordinarie di sviluppo applicativo (introduzione di nuove applicazioni e/o significative modifiche architetturali di quelle esistenti),

⮚ proposti all‟Amministrazione in quanto migliorativi del complesso stesso del DC, in termini sia tecnologici sia organizzativi.

Le proposte migliorative possono essere relative ad un diverso utilizzo delle infrastrutture esistenti ovvero relative ad una sostituzione parziale o totale di alcune infrastrutture con altre più efficaci o più efficienti.

Tali proposte possono inoltre riguardare anche la sola organizzazione del lavoro, ovvero alcune caratteristiche della medesima (standard, metodologie, documentazione, formazione, ecc.).

Come più volte detto le proposte possono nascere da richieste esplicite dell‟Amministrazione, oppure da idee autonome dell‟Impresa. In ogni caso l‟effettuazione dello studio dovrà essere approvata dall‟Amministrazione.

5.3.2.3 Attività ricomprese nel servizio

Poiché il Servizio sarà espletato in forma di attività progettuali al momento non prevedibili, qui di seguito ne possiamo elencare solo alcuni possibili casi esemplificativi:

⮚ collaborazione con gli applicativi per la progettazione delle infrastrutture HW/SW a supporto di nuove applicazioni (basi dati, server, ecc.) e/o per la revisione delle infrastrutture esistenti nel caso di significative reingegnerizzazioni di applicazioni già in servizio;

⮚ studi, analisi e ricerche per: approfondire temi particolari, approntare modelli previsionali descrivendo gli scenari alternativi in corrispondenza di proposte diverse ed analizzandone i risultati;

⮚ valutazione di nuovi prodotti hardware o software installati in prova nel DC,

⮚ realizzazione di quadri di sintesi per fornire informazioni di sintesi sui dati raccolti nell‟ambito del sistema informativo;

⮚ supporto alle decisioni dell‟Amministrazione (analisi dei fabbisogni, individuazione di strumenti tecnologici, formazione, raccolta di indicazioni per sviluppi futuri ecc.);

⮚ supporto nella reingegnerizzazione dei processi supportati dal sistema informativo e nella definizione dei requisiti dei nuovi sistemi;

⮚ valutazione dell‟impatto dei cambiamenti normativi sul sistema informativo;

⮚ analisi e valutazioni dell‟impatto dovuto all‟introduzione di una nuova tecnologia sulla organizzazione, sui processi amministrativi, sul sistema informativo preesistente;

⮚ progettazione di standard e metodologie per contribuire alla definizione ed al perfezionamento degli standard procedurali e tecnologici correnti, in particolare in occasione di nuove esigenze di servizio e/o di nuove normative rivolte agli enti della Pubblica Amministrazione;

⮚ modellizzazione organizzativa dell‟ambiente informatico, per l‟ottimizzazione dei processi gestionali e della relativa struttura organizzativa (ruoli, competenze, relazioni) dell‟ambiente informatico al fine di garantire una maggiore efficacia ed efficienza delle unità, sia dell‟Amministrazione sia dell‟Impresa stessa, predisposte alla sua gestione.

In fase di avvio della Fornitura l‟Amministrazione potrà attivare immediatamente il Servizio, chiedendo all‟Impresa di produrre, entro un tempo definito e limitato (comunque entro i primi tre mesi di Allestimento del Servizio), un “programma di attività” per i mesi a seguire. Gli obiettivi del programma saranno concertati tra Impresa e Amministrazione, sulla base delle principali priorità da quest‟ultima individuate. Tra queste, a scopo esemplificativo, potrebbero essere ricomprese:

⮚ lo sviluppo di un modello di misurazione del workload tecnologico delle varie applicazioni, che possa poi alimentare un sistema di accounting verso l‟utenza finale (oggetto di uno studio successivo);

⮚ l‟inventario di tutti i server applicativi ancora esterni al DC e lo studio di fattibilità di un processo di integrazione degli stessi nel D.C. centralizzato;

⮚ lo studio di fattibilità per una possibile evoluzione dell‟architettura tecnologica del DC, con l‟obiettivo di una progressiva maggiore omogeneizzazione delle infrastrutture presenti.

Come specificato nel Capitolato Speciale, un primo programma di attività (o “programma di sviluppo iniziale”) potrà essere anticipato già in sede di Offerta dalla stessa Impresa, che potrà formularlo prendendo spunto dagli esempi sopra elencati o, comunque, dalla realtà del DC oggetto dell‟appalto, nei limiti di quanto descritto dalla documentazione di gara. Tale programma sarà oggetto di valutazione tecnica in sede di Gara (v. Capitolato Speciale, criterio a.3.12 di punteggio tecnico per il Lotto 1) e, in caso di aggiudicazione, sarà base di discussione per l‟avvio del presente Servizio di Sviluppo Sistemi.

5.3.2.4 SLA relativi al servizio

In considerazione della forte variabilità (per obiettivi, tipologia e tempo necessario) delle attività che possono essere richieste nell‟ambito di questo servizio, gli SLA sono stati definiti in funzione degli impegni via via definiti tra Amministrazione e Impresa, in termini di scostamento della “fine lavori” da quanto preventivato.

Uno SLA a parte, più restrittivo, viene definito per la valutazione dei prodotti in prova, spesso regolati da accordi con altri Fornitori.

5.4 AREA DI ESERCIZIO

È l‟area dei servizi più tipici di un DC, quelli che contribuiscono a governarne il funzionamento quotidiano e la corretta erogazione dei servizi IT dallo stesso forniti all‟utenza finale, assicurando tutte quelle attività operative, giornaliere e periodiche, rese necessarie per l‟ erogazione dei servizi informatici istituzionali e strumentali dell‟ Amministrazione.

Si struttura in sei servizi:

⮚ un Servizio di Gestione della Configurazione, finalizzato a raccogliere e mantenere tutte le informazioni relativa agli asset hardware e software gestiti, nonché alla configurazione fisico/logica con la quale gli stessi si correlano tra loro. Il servizio governa anche la corretta gestione delle modifiche (Change Management), puntando alla perfetta e continua corrispondenza delle informazioni gestite con la realtà del DC;

⮚ un Servizio di Gestione dei Sistemi (generalmente indicato come “Servizio di Sala Macchine”), per la gestione operativa quotidiana dell‟hardware e del software del DC (elaboratori, unità di storage, sistemi e sottosistemi applicativi di esercizio, sviluppo e test, stampanti, operazioni di backup/restore ed archiviazione dei dati di ambiente e applicativi). Il servizio è responsabile anche del monitoraggio e dell‟automazione di sistemi, sottosistemi e procedure e delle funzioni di “Service Desk” (come in seguito meglio illustrato) e di gestione di primo livello dei problemi1;

⮚ un Servizio di Manutenzione dei Sistemi (generalmente indicato come “Servizio Sistemistico”), finalizzato all‟installazione e manutenzione dei software oggetto dell‟appalto (aggiornamento delle versioni, installazione delle patch), alla gestione delle configurazioni, anche in termini di adeguamento dei parametri di funzionamento, al supporto sistemistico alla manutenzione delle procedure applicative, siano esse in produzione, in sviluppo o in test, al supporto ai fornitori hardware per la manutenzione delle apparecchiature, alla gestione di secondo livello dei problemi;

⮚ un Servizio di Continuità Operativa. Questo prevede sia la definizione e realizzazione di un processo di controllo proattivo delle infrastrutture finalizzato a garantirne la massima disponibilità, sia la definizione, realizzazione e gestione di un processo (generalmente indicato come “Disaster Recovery”) finalizzato a garantire la ripartenza dell‟operatività dei servizi IT offerti dall‟Amministrazione in un sito diverso dal DC, nel

1 Qui e nel seguito, per semplicità, si parla di gestione di problemi come comprensiva di gestione degli incidenti (obiettivo = superamento) e gestione dei problemi (obiettivo = rimozione delle cause).

caso questo diventi indisponibile per cause impreviste (naturali, incidentali, delittuose).

Riguardo al processo di D.R. si specifica che, come sarà dettagliatamente descritto più avanti, lo stesso dovrà articolarsi in tre fasi ben distinte:

o in una prima fase dovrà fornire – senza soluzione di continuità – un “servizio base”, almeno equivalente a quello attualmente operativo (vedi Scheda Allegata I, parte prima) in termini soprattutto di RTO/RPO garantiti. Nel frattempo, l‟Impresa si farà carico di studiare e proporre all‟Amministrazione una soluzione tecnico/organizzativa “evolutiva” che possa rispondere meglio alle esigenze attuali dell‟Amministrazione, nonché alle ultime indicazioni contenute nel CAD per la Pubblica Amministrazione;

o la seconda fase, previa approvazione dell‟Amministrazione, prevede la realizzazione della soluzione evolutiva proposta;

o a realizzazione ultimata si avvierà la terza fase, nella quale l‟Impresa migrerà il servizio di Continuità Operativa dalla soluzione base a quella evolutiva.

Si specifica che per tutto l‟arco della Fornitura (e dunque durante tutte e tre le fasi) l‟Impresa è comunque responsabile unica sia della gestione ordinaria del servizio (manutenzione, documentazione, formazione, test periodici, ecc.) sia di quella straordinaria in caso di disastro (disponibilità del sito, delle infrastrutture di recovery e del personale di gestione, per un tempo non inferiore a tre mesi a partire dal momento di dichiarazione del disastro, garantendo la prosecuzione di erogazione dei servizi informatici forniti dall‟Amministrazione e garantendo il ritorno al sito ordinario, il cui ripristino infrastrutturale resta però responsabilità dell‟Amministrazione);

⮚ un Servizio di Gestione della Sicurezza Logica, finalizzato alla gestione dei sistemi HW/SW di sicurezza logica, alla gestione delle entità logiche definite di concerto con l‟Amministrazione e al supporto specialistico sulle tematiche relative agli aspetti di conformità con la normativa vigente in materia di sicurezza e tutela della privacy nel trattamento informatico dei dati. Il servizio effettuerà anche il monitoraggio delle violazioni di sicurezza e dei tentativi di intrusione e la gestione centralizzata degli incidenti di sicurezza;

⮚ un Servizio di Gestione della Sicurezza Fisica, finalizzato al monitoraggio della reportistica generata dai sistemi di sicurezza fisica gestiti da altri “attori” (Ente locatore, società che effettua il servizio di guardiania, ecc.), con l‟obiettivo di evidenziare all‟Amministrazione eventuali situazioni critiche. Nell‟ambito del servizio, l‟Impresa fornirà anche assistenza all‟Amministrazione nei rapporti con il proprietario dei locali per l‟impiantistica (alimentazione ordinaria e di backup, condizionamento, impianti antincendio, ecc.)

Per funzione di “Service Desk”, citata nel servizio di Gestione dei Sistemi, si intende quella di “point of access” unico per tutte le comunicazioni, da e verso l‟esterno dell‟Impresa, di tipo operativo e relative a tutti i servizi dalla stessa resi. Tali comunicazioni riguarderanno prevalentemente la segnalazione e la successiva gestione dei problemi, ma non esclusivamente: attraverso il Service Desk, ad esempio, si potrà richiedere la disattivazione o la riattivazione di un servizio, la modifica di parametri di funzionamento o semplici informazioni.

Questo Capitolato individua la funzione di Service Desk all‟interno del servizio di Gestione dei Sistemi, per due motivi:

⮚ perché dotato di competenze e strumenti in grado di risolvere immediatamente la gran parte delle richieste ricevute dall‟esterno;

⮚ perché operativo H24.

L‟Amministrazione lascia tuttavia facoltà all‟Impresa di proporre soluzioni organizzative diverse, purché siano rispettati il principio di unicità del “p.o.a” e l‟insieme delle caratteristiche funzionali più avanti dettagliatamente descritte.

5.4.1 PGC – SERVIZIO DI GESTIONE DELLA CONFIGURAZIONE

5.4.1.1 Descrizione generale del servizio

La gestione della configurazione è un processo che ha lo scopo di assicurare la conoscenza, la completezza, l‟integrità, la consistenza e la correttezza delle componenti di un sistema, in particolare in relazione alle dipendenze esistenti tra le stesse, attraverso la registrazione della configurazione iniziale e la conoscenza dello stato delle modifiche proposte, della loro motivazione, della loro approvazione, della loro attuazione e della loro evoluzione.

Si sottolinea che il servizio in argomento accorpa due servizi che la terminologia ITIL v.3 identifica separatamente, ovvero il servizio di “Assett and Configuration Management” e quello di “Change Management”.

In altri termini il servizio richiede:

⮚ un‟identificazione iniziale della configurazione (inventario dell‟hardware e del software di base, delle componenti applicative, delle basi dati);

⮚ la registrazione di tale configurazione su un‟apposita base dati opportunamente predisposta e dotata di strumenti di aggiornamento e reportistica;

⮚ il controllo delle successive modifiche alla configurazione (mediante un‟apposita procedura tecnico/organizzativa di gestione dei cambiamenti, che preveda anche precise regole di autorizzazione) e l‟aggiornamento della base dati in coerenza con le modifiche apportate.

Sarà cura dell‟Amministrazione, a seguito di richiesta da parte dell‟Impresa, fornire tutti i dati che la stessa dimostrasse di non poter rilevare autonomamente.

5.4.1.2 Obiettivi del servizio

L‟obiettivo di questa tipologia di servizi è quello di amministrare e mantenere la configurazione dell‟intera infrastruttura tecnologica centrale del sistema informativo comunale, nonché il suo adeguamento alle necessità evolutive dei servizi informatici erogati dall‟Amministrazione. L‟obiettivo si esplica attraverso due aspetti principali:

1. la conoscenza corretta e dettagliata di tutte le componenti del sistema del DC dell‟Amministrazione (Assett and Configuration Management). Ciò si ottiene tramite una base dati contenente l‟identificazione e le caratteristiche di:

a. infrastrutture hardware (server, sistemi storage, switch, ecc.),

b. software di base e middleware installati sui diversi server,

c. struttura logica dei sistemi virtualizzati,

d. applicazioni, con relativa descrizione dell‟architettura dei server e dei software utilizzati,

e. basi dati, con relativa descrizione dell‟architettura, delle applicazioni che vi accedono e dello spazio a disco utilizzato,

2. il controllo su tutte le modifiche applicate alle componenti di cui sopra (Change Management). Ciò si ottiene mediante la predisposizione e la successiva gestione di una procedura di governo delle modifiche che preveda:

a. l‟intero iter di controllo autorizzativo delle medesime,

b. l‟aggiornamento della base dati della configurazione in coerenza con le modifiche apportate.

Il processo tecnico di applicazione delle singole modifiche, invece, non è parte di questo servizio, bensì di quelli che riguardano il componente modificato (nella maggior parte dei casi si tratterà del Servizio di Manutenzione dei Sistemi).

5.4.1.3 Attività ricomprese nel servizio

Le attività che l‟Impresa deve effettuare sono: inventario iniziale delle componenti del sistema, predisposizione e gestione della base dati della configurazione, definizione della procedura di controllo delle modifiche e sua successiva manutenzione.

Inventario iniziale delle componenti del sistema.

L‟Impresa è tenuta, entro il periodo previsto di allestimento, ad effettuare la validazione ed il consolidamento dei dati di inventario relativi alle componenti costituenti il sistema del DC.

Per le componenti hardware, software di base e middleware, i dati caratteristici delle componenti inventariate devono riportare almeno le seguenti informazioni:

⮚ il numero di matricola

⮚ la tipologia ed il modello

⮚ la casa costruttrice

⮚ il numero di serie attribuito dal costruttore

⮚ gli estremi del provvedimento d'acquisizione

⮚ le informazioni logistiche

⮚ la data di scadenza della garanzia

⮚ gli estremi del contratto di noleggio/acquisto

⮚ gli estremi del contratto di manutenzione

⮚ la configurazione (schema delle connessioni, per l‟hardware)

⮚ la versione (per il software ed il middleware),

⮚ per ogni sistema e sottosistema, le librerie dei dati di configurazione e di gestione esistenti,

⮚ i dati sulle licenze d‟uso (per il software ed il middleware).

Riguardo tale ultimo punto si sottolinea che, nell'effettuare il consolidamento dei dati di inventario del software, l‟Impresa è tenuta anche alla verifica dell'esistenza delle licenze che garantiscano all'Amministrazione il diritto all'utilizzo dei software installati sulle apparecchiature oggetto dell‟appalto. Qualora l‟Impresa verificasse l'esistenza di prodotti non previsti dai contratti in essere, essa è tenuta ad informare l'Amministrazione onde questa avvii le procedure di regolarizzazione della relativa posizione contrattuale, di propria competenza.

L‟Impresa dovrà poi realizzare una “mappa logica” di tutti i server esistenti identificando almeno:

⮚ quelli fisici e quelli virtualizzati,

⮚ la tipologia (application server, DB server, ecc.)

⮚ i software installati,

⮚ la configurazione di processori e memoria RAM,

⮚ se di test, collaudo o esercizio,

⮚ le applicazioni che l‟utilizzano.

Relativamente alle applicazioni, l‟Impresa – coinvolgendo le Imprese fornitrici dei rispettivi software applicativi – dovrà realizzarne l‟inventario, identificando almeno le seguenti informazioni:

⮚ il nome dell‟applicazione,

⮚ il Fornitore applicativo di competenza,

⮚ un referente dell‟Amministrazione di competenza,

⮚ una descrizione sintetica delle funzioni svolte dall‟applicazione,

⮚ i software utilizzati,

⮚ le librerie dei programmi applicativi,

⮚ i server (fisici o virtuali) che l‟applicazione utilizza (in test, collaudo ed esercizio),

⮚ le basi dati cui l‟applicazione accede,

⮚ i principali file in input/output, in particolare quelli eventualmente scambiati con l‟esterno,

⮚ le eventuali stampe centralizzate prodotte presso il DC (con indicazione della periodicità e dei volumi medi),

⮚ la tipologia dell‟utenza (interna o esterna all‟Amministrazione, Internet, ecc.),

⮚ i dati sull‟orario di servizio garantito,

⮚ gli eventuali dati sulle prestazioni garantite,

⮚ i dati sulla continuità operativa garantita (disponibilità, RTO, RPO),

⮚ il tipo di sicurezza logica utilizzata (se interna all‟applicazione o esterna, tramite LDAP, ecc.).

L‟inventario delle basi dati dovrà invece contenere almeno:

⮚ il nome della base dati,

⮚ il Fornitore applicativo di competenza,

⮚ un referente dell‟Amministrazione di competenza,

⮚ una descrizione sintetica del contenuto,

⮚ il DBMS utilizzato con eventuali software aggiuntivi,

⮚ le librerie di configurazione,

⮚ i DB server (fisici o virtuali) utilizzati (in test, collaudo ed esercizio),

⮚ le applicazioni che vi accedono,

⮚ un‟indicazione generica sullo spazio a disco necessario (BD “piccola”, “media”, “grande”, “grandissima”),

⮚ i dati relativi ai backup “applicativi”, cioè non a fini DR (tipologia, periodicità, tempi di conservazione, ecc.).

Predisposizione della base dati della configurazione.

L‟Impresa predisporrà una base dati (“Repository”) contenente tutte le informazioni di inventario sopra indicate. Per questa attività essa l‟Impresa può partire dalla corrispondente base dati già realizzata dal precedente Fornitore del servizio (arricchendola di eventuali dati mancanti e aggiornandola, se necessario, alla stato del sistema che gli è stato affidato) ovvero, se lo ritiene opportuno, di costruirne una nuova.

In ogni caso la base dati e gli strumenti che la gestiscono dovranno garantire:

⮚ la possibilità di aggiornamenti rapidi e controllati (deve essere definito un sistema autorizzativo differenziato) con time-stamp,

⮚ la possibilità di effettuare controlli “incrociati” sui vari elementi (es.: quali applicazioni usano un certo software di base),

⮚ ampia possibilità di reportistica, anche personalizzata,

Per tutto l‟arco contrattuale, l‟Impresa deve mantenere costantemente aggiornato il Repository della configurazione rispetto alla realtà esistente. Tale aggiornamento dovrà garantire l‟allineamento durante le diverse attività operative conseguenti ad installazione, trasferimento, cambiamento ed eventuale dismissione delle componenti della configurazione sopra indicate.

Entro il ventesimo (20°) giorno lavorativo dalla data di inizio lavori, l‟Impresa è tenuta a produrre un primo report inventariale generale evidenziando all‟Amministrazione gli eventuali dati ancora mancanti e le relative motivazioni. In ogni caso, entro i 20 giorni lavorativi successivi tutti i dati dovranno essere stati inseriti.

L‟Impresa è inoltre tenuta a produrre un report inventariale generale su base almeno trimestrale, in cui si evidenzino gli scostamenti dall‟equivalente report precedente.

Nell‟ambito del servizio, l‟Amministrazione dovrà essere abilitata all‟uso degli strumenti di inquiry on-line e reportistica per almeno cinque utenze. Analoghe abilitazioni, per almeno altre tre utenze, dovranno essere concesse – in accordo con l‟Amministrazione – agli addetti dell‟Impresa di PMT/CDQ.

Procedura di gestione delle modifiche.

Sulla base di metodologie standard e utilizzando gli strumenti di automazione e controllo previsti nella presente fornitura, l‟Impresa dovrà definire e documentare un processo di gestione dei cambiamenti, inclusivo di strumenti ed aspetti organizzativi che, quale parte integrante del Manuale di Qualità, verrà consolidato con l‟Amministrazione durante la fase di allestimento del servizio. Anche per questo aspetto l‟Impresa può partire, se la ritiene adeguata, dalla procedura già operativa nel corso della precedente fornitura, adeguandola o migliorandola eventualmente per quanto necessario.

In ogni caso la procedura dovrà garantire:

⮚ la minimizzazione dell‟impatto delle procedure di cambiamento sulla disponibilità e sulla qualità dei servizi di Information Technology erogati dall‟Amministrazione;

⮚ l‟utilizzo di metodologie e procedure standard per il rilascio delle modifiche in ambiente di esercizio;

⮚ l‟utilizzo, per quanto possibile, di strumenti operativi e di controllo che minimizzino l‟intervento manuale degli operatori di sistema (automazione dei processi);

⮚ il rilascio delle modifiche in esercizio secondo le modalità definite per ogni specifico caso dall‟Amministrazione;

⮚ il tracciamento dei cambiamenti apportati e delle relative motivazioni (correzione di problemi associati, aggiornamenti tecnologici, miglioramenti funzionali, ottimizzazioni prestazionali, etc.);

⮚ la pianificazione, condivisa con l‟Amministrazione, delle attività di aggiornamento.

L‟Impresa dovrà avere la massima attenzione per tutte le modifiche suscettibili di impatti sugli ambienti di esercizio. In particolare deve farsi carico della pianificazione, del coordinamento, della realizzazione, della validazione e del rilascio in ambiente di esercizio dei cambiamenti alle procedure, sia applicative che di sistema, necessari a garantire il corretto funzionamento dei servizi informatici erogati. Per tutti questi aspetti devono essere formalizzati, in questo servizio, indicazioni precise (attività, metodi, strumenti, responsabilità) o criteri di riferimento.

5.4.1.4 SLA relativi al servizio

Il corretto funzionamento del servizio sarà valutato su due direttive:

⮚ da una parte si valuterà l‟affidabilità e la reattività alle modifiche della base dati mantenuta dall‟Impresa, nei confronti della realtà della configurazione attuale. Gli indicatori riguarderanno il numero di eventuali scostamenti rilevati mediante indagini campionarie, il tempo necessario per completare il primo censimento, la disponibilità dell‟accesso alle informazioni,

⮚ dall‟altra parte si valuterà la qualità del processo di gestione delle modifiche. Gli indicatori rileveranno le condizioni di errore dovute alla procedura in termini di indicazioni non corrette o carenza di indicazioni necessarie.

5.4.2 GSI – SERVIZIO DI GESTIONE DEI SISTEMI

5.4.2.1 Descrizione generale del servizio

Oggetto di questo servizio è assicurare tutte quelle attività operative, giornaliere e periodiche, rese necessarie dall‟erogazione dei servizi informatici istituzionali e strumentali dell‟Amministrazione erogati tramite le infrastrutture IT del DC.

L‟Impresa, per tutte le attività che non richiedano indispensabilmente la prossimità fisica degli operatori alle infrastrutture hardware del DC, dovrà erogare il sevizio operando presso un proprio Centro di Controllo, utilizzando apposite connessioni di rete e strumenti software adeguati.

L‟Amministrazione rende disponibili all‟Impresa, presso il DC, cinque (5) posti di lavoro parte dei quali potranno essere utilizzati per espletare il Servizio di Gestione Sistemi. Si richiede in ogni caso all‟Impresa un presidio fisso H24 presso il DC costituito da almeno due operatori contemporaneamente presenti nei locali.

Inoltre, in considerazione della peculiarità di questo servizio (che prevede l‟esecuzione ripetitiva, su base giornaliera, di centinaia di attività interdipendenti la cui corretta pianificazione ed esecuzione sono obiettivi qualificanti il servizio stesso), l‟Impresa dovrà produrre quotidianamente un Piano Operativo Giornaliero per le attività pianificate nelle 24 ore successive (48 nei prefestivi e 72 nei venerdì). Il P.O. Giornaliero – generalmente prodotto in via automatica dai più comuni strumenti di schedulazione in commercio – dovrà essere inoltrato all‟Amministrazione in tempo utile per le eventuali modifiche o aggiunte dell‟ultimo momento.

5.4.2.2 Obiettivi del servizio

Obiettivo del servizio è il funzionamento di tutte le infrastrutture hardware e software del DC, garantendo l‟esecuzione di tutte le attività operative non automatizzabili e dunque demandate ad apposito personale tecnico esecutivo.

5.4.2.3 Attività ricomprese nel servizio

Il servizio prevede tutte le attività di tipo operativo sui sistemi di elaborazione, sulle unità di storage e su quelle di stampa centralizzate nonché delle apparecchiature ausiliarie (es. taglierine) oggetto dell‟appalto, siano esse di esercizio o di test e collaudo, necessarie a garantire modalità di erogazione dei servizi informatici dell‟Amministrazione adeguate ai livelli di servizio richiesti.

In particolare, l‟Impresa, per quanto riguarda i sistemi di elaborazione, dovrà:

⮚ coordinare le eventuali attivazioni e chiusure dei sistemi operativi e dei sottosistemi come richiesto dal Piano Operativo Giornaliero di erogazione dei servizi applicativi (derivato dal citato Piano Operativo generale),

⮚ fornire il supporto operativo richiesto sia nelle fasi di analisi che di risoluzione delle problematiche che vedono coinvolte le componenti hardware e software del DC,

⮚ fornire il supporto operativo necessario all‟applicazione delle modifiche richieste alle componenti di sistema, sottosistema ed applicative centrali generate da interventi estemporanei o programmati,

⮚ fornire il supporto operativo richiesto nel passaggio in esercizio di nuove componenti applicative o di modifiche alle stesse,

⮚ attivare e controllare l‟ esecuzione dei lavori di elaborazione necessari all‟erogazione dei servizi applicativi secondo il previsto Piano Operativo (es.: “schedulazione e controllo” delle procedure applicative e di gestione),

⮚ garantire la gestione operativa delle ripartenze delle componenti di sistema e/o sottosistema in caso di malfunzionamento,

⮚ gestire le attività di interazione con gli enti esterni, le cui procedure verranno concordate in fase di allestimento del servizio,

⮚ controllare la messaggistica dei sistemi e dei sottosistemi per un continuo monitoraggio dello stato, operativo e prestazionale, delle componenti hardware e software dei sistemi elaborativi centrali,

⮚ adottare, in caso di anomalie del sistema, gli eventuali interventi correttivi di prima istanza, secondo le indicazioni ricevute dalle strutture di supporto di secondo livello o secondo le specifiche definite nell‟ambito del Manuale Operativo predisposto per le attività del centro,

⮚ adottare soluzioni di monitoraggio, sia per i sistemi di base che per i sottosistemi operativi ed applicativi, per segnalare eventuali effetti di degrado o potenziali condizioni di indisponibilità dei servizi applicativi erogati dal centro. In tale ambito rientra il monitoraggio dei servizi applicativi, la cui funzionalità (nel senso di disponibilità e rispondenza alle prestazioni attese) dovrà essere verificata per l‟intera “catena applicativa”: tale monitoraggio sarà effettuato mediante un apposito ambiente predisposto dall‟Impresa nell‟ambito del servizio di Manutenzione (MSI);

⮚ nel caso di rilevazione di malfunzionamenti, segnalare tempestivamente il problema alle apposite strutture di supporto specialistico secondo le procedure definite all‟interno del Manuale Operativo e concordate in fase di allestimento del servizio,

⮚ collaborare alle operazioni di installazione e test di nuove unità di elaborazione e/o di nuove piattaforme operative o di gestione,

⮚ fornire il necessario supporto operativo di sala macchine ad ogni altro servizio e in primo luogo a quelli di backup/restore e continuità operativa,

⮚ monitorare gli impianti elettrici, quelli di condizionamento termico e, comunque, tutti i sistemi di controllo delle condizioni operative d‟ ambiente in cui opera l‟ infrastruttura tecnologica centrale del sistema informativo comunale (temperatura, umidità, base tempi, etc.),

⮚ attuare il controllo preventivo delle apparecchiature dal punto di vista della disponibilità, basato sul monitoraggio dello stato delle stesse e su manutenzioni/verifiche pianificate, secondo i processi e le pianificazioni definiti dal servizio di Continuità Operativa;

Per quanto riguarda i sistemi di archiviazione dei dati, l‟Impresa dovrà:

⮚ effettuare la gestione delle nastroteche per tutti i sistemi coinvolti dal servizio,

⮚ effettuare le attività di caricamento e scaricamento manuale dei supporti magnetici nelle librerie a nastro,

⮚ curare il ricevimento e la custodia dei supporti magnetici che provengono da enti esterni,

⮚ garantire il necessario supporto ai responsabili dell‟Amministrazione per la spedizione dei supporti magnetici ad enti esterni sulla base di uno scadenzario fornito dall‟Amministrazione stessa,

⮚ curare l‟archiviazione dei supporti in nastroteca,

⮚ controllare le scorte di supporti magnetici per far fronte alle previste esigenze,

⮚ effettuare l‟archiviazione delle copie di sicurezza dei dati nei depositi stabiliti,

⮚ controllare la regolarità della movimentazione dei supporti a nastro per/da il sito di immagazzinamento, sulla base dei report forniti dal prodotto di gestione automatica della nastroteca.

L‟Impresa dovrà farsi carico di effettuare la gestione amministrativa, operativa e di monitoraggio delle diverse unità di stampa centralizzate ed ausiliari (es. taglierine) presso la sede del DC. In particolare dovrà:

⮚ curare il monitoraggio delle condizioni operative degli apparati centralizzati di stampa e le eventuali azioni di intervento per garantirne la continuità operativa in caso di malfunzionamenti bloccanti ma di semplice risoluzione,

⮚ effettuare le richieste di intervento specialistico sugli apparati di stampa in caso di malfunzionamenti bloccanti di complessa risoluzione,

⮚ curare la gestione delle taglierine e di ogni altra apparecchiatura inerente la post- lavorazione delle stampe,

⮚ garantire la gestione delle procedure di manutenzione ordinaria sugli apparati di stampa e ausiliari,

⮚ fornire il supporto ai responsabili dell‟Amministrazione per la gestione del materiale di consumo, nella pianificazione delle scorte e nelle procedure di approvvigionamento.

L‟Impresa dovrà farsi carico di effettuare la gestione amministrativa, operativa e di monitoraggio delle stampe secondo le procedure attualmente previste dall‟ Amministrazione. In particolare dovrà:

⮚ eseguire la gestione operativa di produzione delle stampe sulla base della tipologia e dei volumi previsti dall‟Amministrazione, sia in condizioni ordinarie (Piano Operativo), sia straordinarie (scadenze elettorali, censimenti, ecc.),

⮚ fornire supporto alla gestione delle procedure di distribuzione delle stampe centralizzate, attraverso le risorse ed i canali messi a disposizione dall‟Amministrazione.

In generale, ma con particolare riguardo alle attività di questo servizio che presuppongono il trattamento diretto dei dati dell‟Amministrazione (memorizzati o stampati) oggetto dell‟Appalto, si sottolinea che l‟Impresa, ed il relativo personale, è tenuta ad erogare il servizio nel rispetto della massima riservatezza e confidenzialità sui contenuti informativi di cui viene in possesso.

Nella regolamentazione del servizio, come già accennato, oltre alle attività esecutive di cui sopra, l‟Impresa dovrà definire e mantenere sia uno specifico Piano Operativo in cui siano indicate tutte le attività giornaliere o comunque periodiche richieste dalla gestione e conduzione del sistema informativo centrale, sia un Manuale Operativo in cui siano indicate le relative procedure a carico del proprio personale operativo.

Ad avvio fornitura l‟Amministrazione inoltrerà all‟Impresa il Piano Operativo ed il Manuale Operativo in vigore al termine della precedente fornitura: sarà compito dell‟Impresa rivedere i due documenti ed eventualmente adeguarli ai propri standard interni e/o alla situazione attuale del DC, entro il primo trimestre della fornitura. Successivamente sarà cura dell‟Impresa mantenere i due documenti costantemente aggiornati alle modifiche apportate al DC.

L‟Impresa, oltre ad assicurare la copertura dei turni del personale operativo, stabiliti secondo le indicazioni descritte sulle modalità di erogazione del servizio, dovrà fornire, in ogni fascia oraria, un livello di operatività sufficiente a garantire l‟erogazione dei servizi applicativi e gestionali previsti dal Piano Operativo. A questo proposito, dovrà comunque essere assicurato, con l‟adeguato potenziamento del personale di sala, il livello di servizio richiesto anche in caso di particolari eventi che caratterizzano l‟operato dell‟Amministrazione quali, ad esempio, elezioni o manifestazioni.

L‟Impresa dovrà gestire le sue risorse presenti nel DC nel rispetto delle norme, degli standard e dei criteri di sicurezza definiti e preventivamente concordati con l‟Amministrazione.

L'Impresa è tenuta a produrre, con periodicità almeno trimestrale, un report sulle principali attività operative dell‟ultimo periodo con evidenza delle eventuali variazioni e/o eccezioni su quelle pianificate. Ciò vale con riferimento ai sistemi di elaborazione, a quelli di storage e ai sistemi di stampa (con la rendicontazione dei volumi delle stampe prodotte per tipologia).

Funzione di “Service Desk”.

Si descrive separatamente la funzione di Service Desk perché, come già indicato, l‟Impresa potrebbe proporre soluzioni organizzative alternative e posizionare diversamente questa funzione, che tuttavia dovrà rispettare le caratteristiche di seguito indicate.

Il Service Desk, che dovrà essere esplicitamente e chiaramente identificato (con recapiti telefonici fissi e mobili e indirizzi e-mail), rappresenterà un “single point of access” tra l‟Impresa e i seguenti enti ad essa esterni:

⮚ le UU.OO. con competenze ICT del Dipartimento Risorse Tecnologiche e Servizi Delegati,

⮚ l‟Help Desk di 1° livello dell‟Amministrazione(*),

⮚ il Gestore della Rete Dati,

⮚ il Gestore degli immobili e dell‟impiantistica del DC,

⮚ tutti i Fornitori esterni di:

o apparati hardware,

o prodotti software di base, d‟ambiente e gestionali,

o sistemi software applicativi.

Non dovranno instaurarsi, invece, contatti diretti del Service Desk con gli utenti finali degli strumenti IT dell‟Amministrazione (personale di Dipartimenti e Municipi), le cui istanze dovranno essere filtrate e rappresentate dall‟Help Desk di 1° livello.

È infine ovvio, ma è bene ribadirlo, che il Service Desk rappresenta un‟interfaccia di tipo squisitamente operativo. Tutte le richieste di tipo progettuale o, comunque, di attività o problematiche di più ampio respiro dovranno seguire canali e processi più consoni, gestiti in particolare dal servizio di Direzione Lavori.

Il Service Desk dovrà essere dotato di strumenti di “trouble ticketing” adeguati per la tracciatura di tutte le chiamate e del loro intero iter gestionale.

5.4.2.4 SLA relativi al servizio

Gli SLA relativi a questo servizio riguarderanno:

⮚ il rispetto del Piano Operativo (disponibilità di sistemi e sottosistemi nelle fasce orarie stabilite, eventuali ritardi nella schedulazione dei batch e nella produzione delle stampe, correttezza delle procedure di salvataggio dati, ecc.);

⮚ la reattività ai problemi (tempi di ripartenza di sistemi e sottosistemi in caso di caduta degli stessi, tempi di risoluzione per problemi semplici e tempi di richiesta intervento per problemi complessi alle stampanti, tempi di allarme per inconvenienti sui sistemi di alimentazione e condizionamento, ecc.).

Alle tre “famiglie” di sistemi gestiti (elaboratori, storage, stampanti) sono associati SLA diversi in relazione alla natura stessa delle diverse apparecchiature.

5.4.3 MSI – SERVIZIO DI MANUTENZIONE DEI SISTEMI

5.4.3.1 Descrizione generale del servizio

È il servizio, generalmente indicato come “sistemistico”, espletato da tecnici specialisti di prodotto (sistemi operativi, DBMS, prodotti di monitoraggio, prodotti di supporto allo sviluppo applicativo, ecc.) che operano costantemente per l‟aggiornamento programmato del software,

(*) L’Help Desk di 1° livello è, a sua volta, un “p.o.a.” unico cui fanno riferimento – per tutte le problematiche ICT – gli utenti finali (Dipartimenti, Municipi, ecc.). Esso è già da tempo operativo (risponde al numero interno 0667104349) ed è organizzativamente inserito nel servizio di Desktop Fleet Management.

l‟installazione delle correzioni, le personalizzazioni richieste, la configurazione di ambienti e basi dati e quant‟altro necessario per mantenere la corretta operatività del complesso delle infrastrutture hardware e software del DC.

5.4.3.2 Obiettivi del servizio

Si possono distinguere due obiettivi principali del servizio:

⮚ il primo ha carattere “reattivo”. Riguarda ogni intervento dei “sistemisti” per risolvere i problemi derivanti da errori insiti nel software di base (es.: installazione di correzioni), per rispondere a richieste applicative (es.: revisione di strutture di basi dati o di configurazioni di ambienti), per installare nuovo hardware, ecc.

⮚ il secondo ha carattere “proattivo”. Nell‟ambito del servizio, infatti, l‟Impresa dovrà anche farsi carico di verificare costantemente lo stato delle piattaforme hardware e software esistenti, mantenendo quanto più possibile omogenei e allineati i sistemi operativi e gestionali, nel quadro degli standard interni stabiliti dall‟Amministrazione nonché di quelli che l‟evoluzione tecnologica del mercato IT proporrà durante l‟arco della Fornitura. Tutto ciò, ovviamente, definendo con l‟Amministrazione gli inevitabili impatti sulla realtà esistente, concordandone i piani operativi di cambiamento e garantendo la massima continuità nel supporto offerto dai fornitori primari delle piattaforme adottate.

5.4.3.3 Attività ricomprese nel servizio

Il servizio prevede tutte le attività di tipo tecnico/specialistico sui sistemi di elaborazione, sulle unità di storage e su quelle di stampa oggetto dell‟appalto, siano esse di esercizio o di test e collaudo, necessarie a garantire modalità di erogazione dei servizi informatici dell‟Amministrazione adeguate ai livelli di servizio richiesti.

In particolare, l‟Impresa, per quanto riguarda i sistemi di elaborazione, dovrà amministrarne le configurazioni hardware e software, effettuando tutte quelle attività necessarie a mantenere aggiornate, ed allineate con le esigenze dei servizi informatici offerti dall‟Amministrazione, tutti i dati e le informazioni di configurazione e di personalizzazione delle piattaforme di sistema, hardware e software, e dei sottosistemi coinvolti dal presente appalto. Le diverse attività richieste dal servizio possono essere classificate secondo le seguenti categorie:

⮚ “System Administration”, attività di personalizzazione dei sistemi hardware e delle relative piattaforme operative di base, per gli ambienti IBM, Unisys, e Microsoft, secondo le architetture previste dall‟erogazione dei servizi applicativi, rivolte all‟ottimizzazione delle prestazioni e dell‟utilizzo delle risorse di elaborazione ed alle problematiche di controllo dei processi di elaborazione;

⮚ “Software Administration”, che include tutte le procedure ed attività legate all‟installazione, all‟aggiornamento ed alla manutenzione di tutto il software di sistema e/o di sottosistema coinvolto dal presente appalto. Nello specifico l‟Impresa dovrà farsi carico di:

o monitorare lo stato corrente di disponibilità, da parte delle ditte produttrici, delle nuove versioni, release o livelli di aggiornamento delle componenti software al fine di proporne la loro valutazione da parte dell‟ Amministrazione;

o installare i prodotti selezionati in ambiente di test per verificarne la loro affidabilità e fornire ulteriori elementi di valutazione all‟ Amministrazione;

o definire ed effettuare tutte le prove richieste per la verifica della compatibilità del nuovo software con la realtà infrastrutturale esistente in modo da prevenire eventuali malfunzionamenti o disservizi;

o validare ed eseguire le procedure di installazione delle componenti di sistema e sottosistema in ambiente di produzione;

o definire delle procedure di aggiornamento che riducano al minimo i tempi di ripristino in caso di errore nell‟ applicazione di una qualsiasi modifica al software di base;

o aggiornare le competenze amministrative ed operative del proprio personale in modo da fornire l‟ adeguato supporto alle piattaforme software di sistema adottate;

o definire, concordare e pianificare gli interventi di manutenzione programmata delle componenti di sistema e sottosistema;

o promuovere, verso l‟ Amministrazione, l‟ adozione di modifiche alle componenti di sistema e/o dei sottosistemi centrali al fine di migliorare la qualità dei servizi informatici erogati.

Sarà in ogni caso responsabilità dell‟Impresa concordare con l‟ Amministrazione la validità e le modalità di installazione dei nuovi rilasci del software di base messi a disposizione dalle ditte produttrici. Sarà inoltre responsabilità dell‟Impresa, in occasione dell‟ entrata in esercizio di nuove componenti software, di sistema o di sottosistema, di acquisire la relativa documentazione amministrativa ed operativa per la raccolta delle informazioni necessarie alle procedure di gestione ed alla definizione delle politiche operative in caso di anomalie;

⮚ “Subsystem Administration”, consistente nell‟amministrazione dei sottosistemi (es.: transaction processing, internet services, ERP, etc.) con particolare cura alla personalizzazione richiesta dai servizi applicativi, all‟ottimizzazione delle prestazioni relative ai tempi di risposta per gli utenti dei servizi, alle problematiche di interfaccia con altri sottosistemi (es.:. DBMS) e/o altre applicazioni in caso di architetture complesse (es.: ambienti applicativi SAP);

⮚ “Application Services Monitoring”, consistente soprattutto nell‟obbligo di predisporre e mantenere – per ciascuna applicazione – un apposito “ambiente di monitoraggio dell‟intera catena applicativa”, in grado di evidenziare la funzionalità istante per istante del servizio (nel senso di disponibilità e rispondenza alle prestazioni attese) in tutte le sue componenti (rete TLC esclusa), in modo da presentare un‟immagine della funzionalità quanto più possibile vicina a quella percepita dall‟utente finale. Tale ambiente di monitoraggio sarà poi affidato agli operatori del Servizio di Gestione (GSI). Nell‟ambito dell‟attività di monitoraggio dei servizi applicativi, viene poi richiesto all‟Impresa di realizzare e produrre periodicamente, con cadenza almeno trimestrale, un‟apposita reportistica, che evidenzi i consumi delle risorse di sistema (“workload”) attribuibili ai vari servizi applicativi erogati. Sarà cura dell‟Amministrazione definire le politiche e le modalità di attribuzione dei consumi delle risorse e concordarne la loro applicazione con i fornitori del servizio. Tale monitoraggio del workload applicativo potrà essere utilizzato dall‟Impresa per il Capacity Planning e/o dall‟Amministrazione per il ribaltamento dei costi ICT agli utenti finali;

⮚ “Data Base Administration”, che riguarda la personalizzazione dei sottosistemi hardware e software di gestione delle Basi Dati (Oracle, DB2, ecc.) secondo le esigenze dettate dalle architetture dei servizi applicativi e con particolare attenzione all‟ottimizzazione delle prestazioni di input/output ed efficienza nell‟uso degli spazi all‟interno della gerarchia delle unità di storage esistenti. In generale, ma con particolare riguardo a questa attività, si sottolinea che l’Impresa, ed il relativo personale, è tenuta ad erogare il servizio nel rispetto della massima riservatezza e confidenzialità sui contenuti informativi di cui viene in possesso nel trattamento delle basi informative oggetto dell’appalto;

⮚ “Storage and Backup/Restore Administration”. L‟attività riguarda la gestione amministrativa, operativa e di monitoraggio delle diverse unità di storage e delle relative infrastrutture di controllo (es.: Disk Systems, Tape Libraries, File Systems, SAN, switch, etc.), nonché delle procedure definite per garantire il salvataggio e la conservazione di sicurezza dei dati applicativi. L‟Impresa dovrà garantire la massima disponibilità e l‟integrità fisica dei dati e l‟ottimizzazione delle prestazioni di accesso ai medesimi. È nell‟ambito di questo servizio che vengono, quindi, effettuate tutte le procedure di salvataggio dei dati finalizzate alla ricostruzione delle basi dati correnti nell‟eventualità di un malfunzionamento hardware e/o software che ne comprometta il loro utilizzo. La soluzione di processo proposta dall‟Impresa per il servizio di backup/restore dovrà almeno garantire gli stessi aspetti funzionali e prestazionali esistenti alla presa in carico del servizio. L‟Impresa avrà quindi la responsabilità di:

o garantire la gestione amministrativa ed operativa del parco delle unità di storage (dischi, nastri, etc.) esistente;

o effettuare il monitoraggio delle diverse unità per segnalarne il livello prestazionale e le eventuali anomalie;

o definire e validare periodicamente le procedure per la gestione delle situazioni di emergenza (procedure di salvataggio, ripristino dei dati e ripartenza dei servizi applicativi impattati);

o effettuare analisi di utilizzo delle unità di storage per individuare soluzioni di ottimizzazione delle prestazioni (tuning) e di bilanciamento del carico di lavoro rispetto alle modalità di accesso;

o gestire la disponibilità degli spazi di immagazzinamento dei dati;

o fornire il supporto richiesto per l‟analisi previsionale delle necessità di storage sulla base delle necessità previste per le diverse applicazioni di business;

o rispettare le condizioni generali e le politiche di volta in volta definite dall‟Amministrazione in relazione alla conservazione dei propri dati.

⮚ “Printing Systems Administration”, che prevede l‟amministrazione delle configurazioni delle unità di stampa, sia nelle sue componenti hardware che in quelle software;

⮚ “Network Administration”, che prevede l‟amministrazione delle configurazione dei sottosistemi hardware e software di controllo della connettività di rete presenti negli ambienti host e sui server. L‟attività è principalmente rivolta a garantire la massima disponibilità dei canali di comunicazione da e verso le sedi periferiche comunali e l‟ottimizzazione delle prestazioni nell‟esecuzione del processing transazionale e nel trasferimento dei dati (salvo che per gli aspetti prettamente trasmissivi della rete, di pertinenza del Gestore TLC);

⮚ “Management Infrastructure Administration”, ovvero l‟amministrazione delle personalizzazioni definite nell‟ambito dell‟infrastruttura hardware e software preposta alla gestione dell‟intero DC e dei servizi applicativi da esso erogati. L‟attività include, ad esempio, la definizione e manutenzione delle configurazioni relative agli strumenti di monitoraggio e di controllo dei sistemi e sottosistemi centrali, di pianificazione automatica delle operazioni o di registrazione del traffico transazionale di tipo Internet;

⮚ “Tuning”, inteso come attività continuativa di analisi e verifica dell‟intera architettura di elaborazione del sistema informativo comunale per l‟evidenziazione di soluzioni critiche o comunque non rispondenti agli standard di servizio predefiniti e per la definizione e la proposta di corrispondenti soluzioni di ottimizzazione delle prestazioni del sistema e dei sottosistemi coinvolti dal presente appalto. Questa attività è rivolta ad ottenere una maggiore efficienza nell‟utilizzo delle risorse elaborative (riduzione dei costi) ed una migliore qualità (affidabilità e prestazioni) dei servizi applicativi erogati;

⮚ “Automation”. Con questa attività vengono promosse, concordate con l‟Amministrazione, disegnate e sviluppate tutte le procedure di automazione richieste per ottimizzare e rendere più efficiente l‟attività operativa. A questo proposito si precisa che il Fornitore dovrà prevedere soluzioni automatizzate per la schedulazione

ed il controllo dei processi elaborativi che consentano di gestire in modo integrato tutte le piattaforme operative oggetto della presente fornitura. Tali soluzioni dovranno considerare i processi elaborativi nella loro interezza, agendo secondo una logica di workflow e rispondendo dinamicamente ai possibili eventi, in modo da gestire e controllare le componenti che risiedono sulle diverse piattaforme e che contribuiscono all‟erogazione dei servizi informatici dell‟Amministrazione (“catena applicativa”).

Una trattazione a parte richiede l‟attività di “Problem Management” (che comprende al suo interno anche quella di Supporto di Xxxxxxx Xxxxxxx), che è in un certo qual modo trasversale a tutte le precedenti.

L‟Impresa è tenuta, nell‟ambito delle piattaforme di sistema e dei sottosistemi operativi e gestionali coinvolti dal presente appalto, a fornire il supporto richiesto per l‟analisi e la risoluzione di tutte le problematiche che incidono sulla disponibilità e sulle prestazioni dei servizi applicativi, interni ed esterni, erogati attraverso l‟infrastruttura centralizzata oggetto del presente appalto.

È a carico dell‟Impresa la definizione della struttura organizzativa e di processo ritenuta più idonea all‟erogazione del servizio. Questa struttura verrà automaticamente attivata dall‟instradamento delle richieste di intervento da parte delle unità di supporto di primo livello secondo le procedure concordate in fase di allestimento del servizio.

Alle strutture di primo livello – tra cui si intendono sia il Service Desk fornito dal Servizio di Gestione Sistemi, sia l‟Help Desk di 1° livello che fornisce assistenza agli utenti finali – resta integralmente l‟onere della problem determination delle malfunzioni segnalate e la loro gestione nei confronti di tutti gli attori coinvolti con particolare riferimento agli utenti finali.

L‟Amministrazione si farà carico, in fase di allestimento del servizio, di promuovere tutte quelle iniziative che dovessero rendersi necessarie allo sviluppo delle opportune interazioni con i servizi qui offerti dall‟Impresa.

Le attività di gestione dei problemi dovranno indirizzare tutte le problematiche inerenti la funzionalità operativa e le caratteristiche prestazionali relative ai:

⮚ sistemi e sottosistemi hardware centralizzati,

⮚ sistemi e sottosistemi operativi di base,

⮚ sottosistemi di controllo delle unità di storage,

⮚ sottosistemi di controllo delle unità di rete,

⮚ sottosistemi di controllo delle unità di stampa,

⮚ sottosistemi di gestione,

⮚ procedure operative di esercizio.

Sarà inoltre cura del personale specialistico coordinarsi o veicolare specifiche problematiche verso le strutture interne o le società esterne a cui l‟Amministrazione ha demandato la responsabilità della realizzazione degli ambienti applicativi. È responsabilità dell‟Impresa gestire i rapporti con i centri di assistenza dei fornitori delle componenti hardware o software, oggetto del presente appalto, con cui vige un relativo contratto di manutenzione.

Nel caso di malfunzionamenti è richiesto che la struttura di Supporto di Secondo Livello si faccia carico di:

⮚ coordinare e supportare l‟intero iter di analisi, diagnosi e risoluzione del problema;

⮚ attivare le strutture di sviluppo per l‟eventuale modifica di procedure interne;

⮚ attivare le strutture operative per il rilascio e l‟applicazione delle eventuali modifiche;

⮚ comunicare l‟avvenuta risoluzione del problema per la sua chiusura alla struttura che l‟ha segnalato;

⮚ effettuare le necessarie escalation, verso l‟Amministrazione e verso le ditte fornitrici richiedendo il rispetto dei tempi previsti di intervento.

È, quindi, nell‟ambito di questo servizio che viene richiesta all‟Impresa la piena gestione delle procedure previste dalle condizioni contrattuali di manutenzione ed il controllo delle relative attività erogate dalle diverse ditte fornitrici delle componenti hardware e software di proprietà dell‟Amministrazione e coinvolte dal presente bando.

L‟infrastruttura di registrazione e tracciamento dei problemi sarà messa a disposizione dall‟Amministrazione e dell‟Impresa di PMT/CDQ. Con tale infrastruttura viene tracciata l‟origine, la tipologia la severità del malfunzionamento ed i relativi tempi d‟intervento. A tale proposito, e per le componenti hardware e software oggetto dell‟appalto, l‟ Impresa sarà tenuta a rispettare i livelli di servizio secondo quanto definito in questo Capitolato Tecnico e nella citata Scheda Allegata P1.

L‟Impresa, oltre all‟attività richiesta in caso d‟interventi legati alla risoluzione di eventuali malfunzionamenti, è tenuta al rispetto delle tempificazioni e dei piani definiti per le attività di amministrazione delle configurazioni. È, altresì, responsabilità dell‟Impresa garantire la massima affidabilità dei cambiamenti di configurazione indotti dalle attività di amministrazione dei diversi ambienti.

L'Impresa è tenuta a produrre, con cadenza almeno trimestrale, un report delle principali attività effettuate nell‟ultimo periodo relativamente al presente servizio di manutenzione.

5.4.3.4 SLA relativi al servizio

Con una certa analogia agli SLA relativi al servizio operativo, anche quelli riguardanti i servizi “sistemistici” misurano:

⮚ il rispetto delle tempificazioni condivise con l‟Amministrazione (per l‟amministrazione delle configurazioni, per gli aggiornamenti del software, ecc.) e la disponibilità di supporto agli Applicativi,

⮚ la rapidità e l‟efficacia nella soluzione dei problemi (bontà delle procedure di ripristino, tempestività e capacità di risoluzione dei malfunzionamenti di bassa, media ed alta priorità, ecc.).

In particolare, nella valutazione dei livelli di servizio relativi al Problem Management, viene assunta la seguente classificazione delle priorità dei problemi che ne determina l‟urgenza di intervento e di risoluzione:

⮚ “alta priorità”, quando il malfunzionamento rende indisponibile un servizio critico all‟insieme dei propri utenti;

⮚ “media priorità”, quando l‟ indisponibilità riguarda solo alcune funzioni critiche di un servizio;

⮚ “bassa priorità”, quando l‟ impatto non compromette l‟operatività degli utenti del servizio.

5.4.4 COP – SERVIZIO DI CONTINUITÀ OPERATIVA

5.4.4.1 Descrizione generale del servizio

Nell‟ambito di questo servizio si richiede all‟Impresa di

A. mettere in atto un processo di controllo preventivo delle apparecchiature dal punto di vista della disponibilità, basato sul monitoraggio dello stato delle stesse e su manutenzioni/verifiche pianificate e finalizzate alla massimizzazione della continuità sul DC attuale di Roma Capitale;

B. garantire, attraverso la disponibilità di una infrastruttura informatica remota (“Centro di Ripristino”) e di apposite procedure debitamente documentate, la continuità operativa e funzionale delle applicazioni critiche per i servizi IT erogati dall‟Amministrazione in caso

di “disastro”, secondo l‟elenco delle applicazioni e delle condizioni minime temporali di ripristino fornite nella tabella riportata nella Scheda Allegata I.

Per “disastro” si intende la cessazione totale e prolungata della operatività del DC attuale di Roma Capitale, a seguito di un qualsiasi evento non pianificato, sia esso naturale o comunque provocato da condizioni incontrollabili. Le modalità di ripartenza dei servizi, presso il Centro di Ripristino, dovranno essere descritte all‟interno di un apposito “Piano di Disaster Recovery” che l‟Impresa dovrà redigere e pubblicare, previa approvazione dell‟Amministrazione, entro i primi 3 mesi di avvio della Fornitura.

A. Processo di controllo preventivo

Per assicurare tale processo l‟Impresa deve provvedere a:

⮚ Ricerca di tutte informazioni provenienti/rilevabili dalle apparecchiature e definizione delle modalità di utilizzo delle informazioni in ottica di verifica dello stato di disponibilità e di rilevazione/prevenzione di guasti

⮚ Analisi delle segnalazioni, relative a funzionamento e disponibilità, previste dalle apparecchiature (errori ricoverabili, warning) e accordi con i produttori/manutentori delle stesse per la disponibilità di segnalazioni non direttamente rilevabili dall‟impresa

⮚ Costruzione di un quadro di insieme delle informazioni rilevabili/ottenibili sullo stato delle apparecchiature, sugli eventi potenzialmente pericolosi per la disponibilità e sul livello di copertura del controllo preventivo effettuabile

⮚ Stesura di un piano di manutenzione preventiva, in accordo con i produttori/manutentori delle apparecchiature

⮚ Definizione di una procedura operativa per la attuazione del controllo preventivo da parte del servizio di Gestione dei Sistemi. A fronte di qualsiasi situazione che incrementi la probabilità di interruzione o degrado dei servizi erogati dal DC, tale procedura deve prevedere la segnalazione all‟Amministrazione e l‟avvio di una Azione Preventiva che ripristini le condizioni standard di disponibilità

⮚ Adeguamento di detta procedura e del quadro di insieme a fronte di modifiche nella configurazione del DC.

B. Servizio di Disaster Recovery

Nella descrizione del servizio, si deve tener presente che l‟Amministrazione già dispone – nell‟ambito del Contratto in essere di Gestione del proprio DC – del Servizio di Continuità Operativa descritto nella citata scheda allegata e caratterizzato dai seguenti aspetti principali:

⮚ la disponibilità, come Centro di Ripristino, di un DC sito fuori Roma, dotato di infrastrutture qualitativamente analoghe a quelle del DC, che vengono rese disponibili, in service, all‟Amministrazione, sia in caso di disastro, per la ripartenza dei servizi IT coperti dal servizio, sia per le periodiche prove di ripristino concordate nel contratto. Il Centro di Ripristino non è esclusivo di Roma Capitale, ma è utilizzato anche per servizi – non solo di Disaster Recovery – forniti ad altri clienti;

⮚ l‟utilizzo di procedure a nastro (backup giornaliero dei dati a Roma, trasporto dei nastri in apposito sito protetto diverso da quello sopra citato, ripristino dei dati da nastro a disco nel Centro di Ripristino, quando necessario) per il ripristino dei dati;

⮚ parametri di RTO e RPO, come indicato nella citata scheda allegata, che ovviamente tengono conto delle attuali modalità di ripristino dei dati, sopra indicate.

A ciò va aggiunto che, nel corso del 2010, l‟Amministrazione ha avviato un progetto finalizzato a migliorare drasticamente i parametri (RTO e RPO) di ripristino dei soli servizi Anagrafici e Elettorali forniti nell‟ambiente mainframe Unisys. A tale scopo ha progettato, acquisito e installato un sottosistema disco a ciò dedicato, che è stato inserito nel Centro di Ripristino. Il sottosistema, dimensionato per i soli dati Anagrafici ed Elettorali, ne permette il mirroring remoto continuativo

(asincrono) dal Centro di Roma a quello di Ripristino, riducendo perciò lo RPO di questi servizi a 5 minuti circa e lo RTO a poche ore.

Il sistema è stato testato con esito positivo e sarà rilasciato dopo l‟attivazione di un idoneo collegamento di rete (100 Mb/s circa) tra il Centro di Roma e quello di Ripristino.

Come già indicato, l‟Impresa deve:

1. rilasciare all‟Amministrazione, al completamento dei 3 mesi della fase di allestimento e transizione, un “sistema base” di Continuità Operativa (comprensivo delle infrastrutture e procedure di Disaster Recovery) che garantisca, senza soluzione di continuità, livelli di servizio almeno equivalenti a quelli forniti dal corrispondente servizio in essere al momento dell‟avvio del contratto. Rispetto al servizio in essere tale “sistema-base” dovrà comunque assicurare anche taluni limitati requisiti aggiuntivi che vengono esplicitati nella Scheda Allegata I. Qualora l‟Impresa non fosse in grado di rilasciare tale sistema al completamento della fase di transizione, essa si impegnerà a proseguire a sue spese il servizio in essere, per tutto il tempo necessario al subentro del nuovo e ad implementarvi comunque i requisiti aggiuntivi di cui sopra;

2. realizzare - totalmente a suo carico ed entro 9 mesi dalla data di affidamento del servizio – un “progetto evolutivo“ per la Continuità Operativa che – in linea con le indicazioni CAD per la PA e con le nuove esigenze di Roma Capitale – migliori significativamente i livelli di servizio e l‟efficienza economica del servizio “base”. Il progetto del nuovo servizio evoluto per la Continuità Operativa dovrà essere presentato in sede di Offerta di Gara sulla base dei requisiti specificati dall‟Amministrazione nella già citata Scheda Allegata I. Detto Progetto sarà elemento di valutazione tecnica dell‟offerta secondo quanto indicato nell‟art. 36 del Capitolato Speciale;

3. prendere in carico sia la gestione “ordinaria” sia quella “straordinaria” (cioè in caso di disastro) del servizio, prima nella sua forma “base”, poi in quella “evoluta”.

E’ inteso che anche il Servizio di Continuità Operativa è soggetto alla riserva di crescita (stimata in un 25% anno su anno) delle infrastrutture oggetto di gestione, di cui al Cap. 3.

In altri termini il canone previsto in offerta per tale servizio dovrà prevedere non solo la soluzione evolutiva (progettazione e realizzazione), ma anche le eventuali crescite quantitative (nei limiti sopra indicati) delle infrastrutture per il Disaster Recovery, derivanti dalle modifiche richieste dall‟Amministrazione della “base applicativa” soggetta a Continuità Operativa. Tali modifiche possono comprendere:

⮚ la crescita fisiologica delle applicazioni già soggette a C.O. all‟avvio del servizio (per le quali, dunque, oltre al potenziamento delle infrastrutture “normali” si dovrà provvedere anche a quello delle infrastrutture di ripristino);

⮚ l‟inserimento di nuove applicazioni, non soggette a C.O all‟avvio del servizio,

⮚ la modifica dei parametri RTO/RPO per applicazioni già soggette a C.O., che possono comportare il potenziamento delle infrastrutture di ripristino.

Poiché per quanto riguarda il Disaster Recovery è richiesto – oltre che dalle più diffuse “best practicies” anche dalla normativa per la P.A. – che l‟Amministrazione sia dotata di un apposito documento ufficiale, denominato “Piano di Disaster Recovery”, che descrive l‟intero processo (infrastrutture HW e SW dedicate, procedure di replica o salvataggio dei dati, procedure di emergenza, test periodici, ecc.), il Manuale Operativo ed il Piano Operativo, riporteranno, per il DR, solo le caratteristiche generali del servizio fornito, rimandando, per le descrizioni di dettaglio, al Piano di DR, anch‟esso predisposto e mantenuto dall‟Impresa d‟intesa con l‟Amministrazione.

5.4.4.2 Obiettivi del servizio

Gli obiettivi del servizio sono due:

⮚ garantire, mediante la definizione e la successiva realizzazione del processo di controllo preventivo di cui al punto (A), la massima disponibilità delle infrastrutture (in particolare di quelle critiche) del DC;

⮚ garantire, mediante la definizione, la realizzazione e la gestione del processo di Disaster Recovery di cui al punto (B), la corretta ripartenza, dopo un evento disastroso, di un sottoinsieme definito dei servizi IT erogati dall‟Amministrazione, nel più breve tempo possibile e, comunque, entro i limiti temporali (RTO) e con la perdita limitata di dati (RPO) indicati dall‟Amministrazione. Si intende che l‟Impresa dovrà garantire la gestione delle infrastrutture di Recovery (nel sito “secondario”) per tutto il tempo necessario, tra il momento del disastro ed il recupero (a cura dell‟Amministrazione) del DC “ordinario”.

5.4.4.3 Attività ricomprese nel servizio

Predisposizione del Processo di Controllo Preventivo delle Infrastrutture.

Durante la fase di allestimento e transizione l‟Impresa deve:

⮚ attuare le prime 5 attività elencate al sottopunto “A. Processo di controllo preventivo” del precedente paragrafo di “Descrizione generale del servizio”

⮚ sottoporre all‟approvazione dell‟Amministrazione il piano di manutenzione preventiva e la procedura operativa di controllo

⮚ addestrare il personale del servizio di Gestione dei Sistemi per la attuazione del processo di controllo preventivo secondo il piano di manutenzione preventiva e la procedura operativa approvati.

Terminata la fase di transizione, per l‟intera durata della fornitura l‟Impresa dovrà:

⮚ garantire l‟esecuzione del processo di controllo preventivo sulla base dell‟ultima versione approvata di procedura e piano

⮚ attuare le azioni opportune a fronte di qualsiasi situazione di rischio per la disponibilità

⮚ adeguare procedura e/o piano a fronte di modifiche nella configurazione del DC o a fronte di necessità emerse

⮚ sottoporre le modifiche all‟approvazione dell‟Amministrazione.

Disaster Recovery – Predisposizione dell’Infrastruttura

Nel Centro di Ripristino, l‟Impresa dovrà predisporre un‟infrastruttura IT che riproduca l‟architettura e le prestazioni relative ai sistemi ed alle banche dati esistenti nel sistema informativo comunale oggetto dell‟appalto garantendo la normale erogazione del servizio – per le applicazioni definite nel Recovery Plan – pur con le limitazioni del caso. Il Centro di Ripristino, la cui infrastruttura s‟intende a carico dell‟Impresa, dovrà essere remotamente connesso con le diverse sedi del sistema informativo comunale in modo da rendere pressoché trasparente per gli utenti finali la sorgente di erogazione dei servizi applicativi soggetti a continuità operativa.

Si richiede, altresì, che la sede del Centro di Ripristino ricada nell‟ambito del territorio nazionale nazionale entro 200km dal Data Center di Roma Capitale e la connessione verso le infrastrutture che garantiscono le comunicazioni delle diverse sedi periferiche del sistema informativo comunale sia completamente a carico dell‟Impresa, avvalendosi, eventualmente, dei servizi di interconnessione messi a disposizione delle Pubbliche Amministrazioni dal Sistema Pubblico di Connettività (SPC) ) concordando con l‟Amministrazione i relativi accordi di utilizzo.

I tempi massimi (RTO) per il ripristino dell‟operatività degli utenti dei servizi applicativi dovranno ricadere entro uno specifico intervallo temporale dalla “Dichiarazione di Disastro‟ da parte del responsabile dell‟Amministrazione, corrispondente alle condizioni minime temporali definite nella tabella contenuta nella citata scheda allegata.

L‟Impresa dovrà altresì rispettare gli RPO definiti dall‟Amministrazione per ciascuna applicazione, ovvero il tempo massimo accettato di disallineamento dei dati, dallo stato immediatamente precedente il disastro.

Come già detto, sono a carico dell‟impresa tutti gli oneri relativi alla progettazione, alla realizzazione, alla manutenzione e alla gestione del Centro di Ripristino (fatto salvo quanto relativo alle apparecchiature di proprietà dell‟Amministrazione, già operative presso il Centro di Ripristino). Sarà a carico dell‟Impresa anche il sistema di connessione dati tra il Centro di Roma e quello di Ripristino, necessario a garantire il flusso di allineamento dei dati definito nella soluzione migliorativa proposta dall‟Impresa.

Disaster Recovery – Gestione ordinaria del Servizio.

Per “gestione ordinaria” del servizio – dapprima nella sua forma base e successivamente in quella evoluta – si intende la gestione tecnica dell‟infrastruttura di ripristino e delle procedure di allineamento dei dati, e di tutte le attività organizzative finalizzate al corretto funzionamento della soluzione.

Il DC di Ripristino dovrà essere infatti costantemente tecnologicamente allineato a quello di ordinaria operatività di Roma, così come le procedure di allineamento dei dati tra i due siti – comunque siano realizzate – dovranno costantemente seguire le modifiche via via apportate alle strutture delle basi dati di Roma.

Sono dunque a carico dell‟Impresa il processo di gestione e tutte le attività operative periodiche di allineamento del sistema informativo comunale, oggetto del servizio, con l‟infrastruttura del Centro di Ripristino. Rimane comunque escluso dal servizio tutto il materiale accessorio necessario alla sua erogazione, quale ad esempio, supporti di registrazione ed archiviazione (es. nastri magnetici, etc.) e carta per stampanti, in quanto a carico dell‟Amministrazione.

Parallelamente l‟Impresa dovrà tenere aggiornata tutta la documentazione relativa a infrastrutture e procedure (citato “Piano di DR”), per permettere una rapida e corretta esecuzione del ripristino dell‟operatività in caso di disastro. L‟importanza che riveste tale documentazione (in termini di completezza, chiarezza e disponibilità) è evidente, soprattutto se si considera il suo utilizzo in un frangente così straordinario e improvviso come un “disastro”.

Proprio in considerazione di tutto quanto detto sopra, un ruolo fondamentale del servizio è quello assegnato alle “prove” di Disaster Recovery.

L‟Impresa dovrà organizzare e rendere disponibile, presso il Centro di Ripristino, l‟esecuzione di un minimo di 2 (due) ed un massimo di 5 (cinque) test annui per un massimo di 25 (venticinque) giorni lavorativi, dietro preavviso da parte dell‟Xxxxxxxxxxxxxxx xx xxxxxx 00 (xxxxxx) giorni solari.

I test dovranno prevedere la ripartenza, presso il Centro di Ripristino, di un sottoinsieme (di volta in volta condiviso con l‟Amministrazione) dei servizi IT oggetto di Continuità Operativa e un loro test funzionale effettuato da personale dell‟Amministrazione.

È fatto infine obbligo all‟Impresa di garantire la conformità con la normativa vigente, in tutte le fasi e in tutte le componenti del presente servizio. In particolare è responsabilità dell‟Impresa assicurare la protezione e la riservatezza dei dati sensibili attuando tutte quelle procedure di sicurezza che verranno ritenute necessarie dall‟Amministrazione e concordate nella fase di allestimento del servizio. In merito alla sicurezza dei dati, l‟Amministrazione sarà quindi l‟unica responsabile della scelta e dell'attuazione delle opportune tabelle di controllo degli accessi, dell'uso e delle politiche di sicurezza dei dati registrati sul sistema.

Si intende fin d‟ora, infine, che l‟insieme dei servizi indicati dall‟Amministrazione come oggetto di Continuità Operativa (specificati nell‟apposita Scheda allegata al Capitolato Tecnico, comprensivi dei rispettivi RTO e RPO) è soggetto a subire variazioni nei limiti dei trend di crescita indicati nelll‟art. 2 del Capitolato Speciale: entro tali limiti l‟Impresa si impegna ad adeguare a suo carico il servizio di Continuità Operativa reso.

Disaster Recovery – Gestione straordinaria del Servizio.

Per “gestione straordinaria” del servizio – dapprima nella sua forma base e successivamente in quella evoluta – si intende la gestione dell‟operatività dei servizi IT oggetto di Continuità Operativa, successivamente all‟evento disastroso.

In altri termini si intende la prosecuzione di tutti i servizi oggetto del presente appalto:

⮚ limitatamente ai servizi IT erogati dall‟Amministrazione, per i quali è garantita la continuità operativa, come indicato nella scheda allegata,

⮚ utilizzando le infrastrutture del Centro di Ripristino ed il personale necessario per il proseguimento dell‟erogazione di tutti i servizi oggetto del presente appalto.

Stante l‟eccezionalità della situazione, l‟Amministrazione concorderà con l‟Impresa, entro le prime due settimane di operatività presso il Centro di Ripristino, eventuali deroghe al contratto di servizio, rese indispensabili dallo stato tecnologico e organizzativo determinatosi con l‟evento disastroso.

In termini generali, comunque, l‟Impresa si impegna a condurre la gestione straordinaria del servizio fino a quando non sarà nuovamente reso disponibile un DC “ordinario” (coincidente o diverso da quello attuale, per un massimo di tre mesi dalla data di “dichiarazione del disastro”.

Tutte le attività organizzative, tecniche ed economiche finalizzate a rendere nuovamente disponibile un DC ordinario restano a carico dell‟Amministrazione.

Sarà invece a carico dell‟Impresa l‟attività tecnico/organizzativa (da condividere e pianificare con l‟Amministrazione) di ritorno dell‟operatività dal DC di ripristino a quello ordinario, non appena disponibile.

NB: la “nuova” soluzione di Disaster Recovery proposta dall’Impresa sarà oggetto di valutazione tecnica da parte della Commissione di Gara, con particolare riferimento alla potenziale capacità di soddisfare i requisiti migliorativi indicati nella seconda parte della Scheda Allegata I.

5.4.4.4 SLA relativi al servizio

Gli SLA relativi al servizio riguardano sia la gestione ordinaria (aggiornamento del DR-Plan, pianificazione ed esito dei test), sia quella straordinaria (rispetto dei parametri di RTO e RPO in caso di vero disastro). Nella proposta di servizio migliorativo rispetto al servizio attuale l‟Impresa dovrà indicare eventuali SLA migliorativi e/o integrativi rispetto a quelli descritti nelle Schede Allegate I e P1.

5.4.5 SIL – SERVIZIO DI GESTIONE DELLA SICUREZZA LOGICA

5.4.5.1 Descrizione generale del servizio

Attraverso questo servizio si richiede all‟Impresa di farsi carico della gestione amministrativa, operativa e di monitoraggio delle soluzioni di sicurezza logica attualmente messe in atto dall‟Amministrazione in tema di identificazione ed autenticazione degli utenti, interni ed esterni, dei servizi applicativi erogati, di controllo degli accessi alle risorse di sistema e della loro non ripudiabilità, di confidenzialità delle informazioni, di integrità sia dei dati che degli asset informatici.

In questo servizio sono anche inclusi servizi di supporto mirati a coadiuvare l‟Amministrazione nelle problematiche di conformità con la normativa vigente in materia di sicurezza, confidenzialità, privacy e trattamento informatico dei dati.

5.4.5.2 Obiettivi del servizio

Gli obiettivi del servizio sono sostanzialmente due:

⮚ il monitoraggio costante dei sistemi di sicurezza logica a protezione del DC, evidenziando prontamente all‟Amministrazione:

o eventuali malfunzionamenti o deficienze dei medesimi,

o l‟occorrenza di “incidenti” (Incident Management);

⮚ la promozione, verso l‟Amministrazione, di eventuali iniziative per un miglioramento e un‟ottimizzazione delle soluzioni adottate.

5.4.5.3 Attività ricomprese nel servizio

Nell‟ambito del servizio, l‟Impresa dovrà fornire il supporto necessario a garantire l‟integrità del sistema informatico comunale in caso di possibili esposizioni dell‟infrastruttura di sicurezza a nuove minacce o rischi derivanti dall‟ambiente esterno. L‟Impresa, ed il relativo personale, è tenuta ad erogare il servizio nel rispetto delle correnti disposizioni di legge in materia (DLGS 196/2003).

In termini di specifiche attività ricomprese nel servizio, l‟Impresa dovrà in particolare:

⮚ provvedere alla gestione amministrativa delle utenze dotate di privilegi di amministratore di qualsiasi livello degli ambienti di sistema o di sottosistema del Dipartimento responsabile del DC (unicità del punto di amministrazione della sicurezza);

⮚ garantire che le soluzioni e le attività di gestione offerte siano conformi con l‟infrastruttura di sicurezza dell‟Amministrazione, con gli standard interni e di mercato e con le politiche definite in merito;

⮚ effettuare le procedure periodiche di ”vulnerability assessment” per la verifica delle possibili esposizioni dell‟infrastruttura di sicurezza adottata;

⮚ gestire i firewall e gli altri dispositivi (IDS, IPS) attraverso le attività di modifica delle configurazioni e di monitoraggio remoto;

⮚ allestire e gestire l‟infrastruttura per effettuare il monitoraggio per la rilevazione di eventuali violazioni o tentativi di intrusione da parte di utenze non autorizzate (intrusion detection);

⮚ effettuare il monitoraggio delle procedure antivirus per verificarne l‟esecuzione, pianificata o estemporanea, secondo le politiche definite in merito dall‟Amministrazione;

⮚ gestire l‟attuale infrastruttura hardware e software per l‟utilizzo di dispositivi elettronici per l‟accesso sicuro ai sistemi;

⮚ garantire la conservazione dei “log‟ degli apparati di sicurezza nel rispetto della normativa vigente.

La gestione degli incidenti di sicurezza include l‟insieme delle strategie e delle tecniche, siano esse di natura organizzativa, procedurale e/o tecnologica, che l‟Impresa è tenuta ad adottare per individuare e rispondere tempestivamente ed efficacemente a qualsiasi azione illecita, non autorizzata o non conforme alle politiche di sicurezza, che coinvolga le basi informative, le infrastrutture di elaborazione o, in generale, l‟intera organizzazione dei servizi erogati, a meno delle attività di competenza di altre società ed attinenti ad altre forniture o servizi.

Alcune categorie comuni di incidente di sicurezza sono rappresentate da:

⮚ tentativi di intrusione o azioni, intenzionali o accidentali , che inducono un disservizio o un danneggiamento dei dispositivi, con conseguente malfunzionamento delle componenti hardware o software dei sistemi di elaborazione;

⮚ non conformità con le politiche definite dall‟Amministrazione e/o dalla normativa vigente in merito a confidenzialità, protezione ed integrità del patrimonio informativo gestito nell‟erogazione dei servizi di IT;

⮚ violazione delle politiche di accesso definite dall‟Amministrazione nell‟ambito dei servizi, delle basi dati e delle risorse tecnologiche di elaborazione.

Nell‟ambito della gestione degli incidenti, dunque, l‟Impresa dovrà:

⮚ individuare rapidamente una violazione o un incidente, attraverso le seguenti macro- fasi:

o identificazione dell‟incidente di sicurezza, realizzata attraverso la raccolta degli eventi e la correlazione in base a specifiche regole;

o attribuzione di priorità dell‟incidente di sicurezza, realizzata attraverso una preventiva identificazione dei sistemi e delle risorse critiche per l‟operatività dell‟Amministrazione. A tali sistemi e risorse sono assegnati valori in termini di confidenzialità, integrità e disponibilità degli stessi. Inoltre deve essere possibile determinare il livello di vulnerabilità di tali sistemi e risorse attraverso l‟integrazione con strumenti standard di rilevazione di vulnerabilità;

o notifica dell‟incidente di sicurezza, realizzata attraverso la comunicazione dello stato di allarme (con le informazioni necessarie a qualificarlo), affinché si attivi il processo vero e proprio di risposta. La soluzione tecnologica di gestione degli incidenti di sicurezza prevede l‟integrazione con strumenti di notifica/alerting attraverso posta elettronica o altri canali di comunicazione tempestivi e sicuri;

o risposta all‟incidente di sicurezza e ripristino delle funzionalità originarie, realizzata attraverso l‟integrazione con strumenti di trouble-ticketing, nonché attraverso l‟interfaccia stessa dello strumento che costituisce un punto di raccolta delle attività intraprese per il contenimento e la risoluzione dell‟incidente di sicurezza;

o monitoraggio e revisione dell‟incidente di sicurezza, realizzata attraverso la produzione di report e la visualizzazione di reportistica grafica ad uso delle strutture interne dell‟Amministrazione. Lo strumento permette inoltre di tracciare le operazioni compiute a fronte della creazione di un incidente di sicurezza, in termini di rispetto dello SLA definito dalle parti per la tempestiva chiusura dell‟incidente stesso;

⮚ proteggere l‟integrità delle risorse del sistema informatico dell‟Amministrazione da minacce esterne,

⮚ verificare la conformità alle politiche di sicurezza definite dall‟Amministrazione e/o dalla normativa vigente (vedi legge sulla Privacy, Basilea II, etc.),

⮚ analizzare gli incidenti individuando gli impatti e promuovendo le strategie correttive e/o di protezione per ridurre od eliminare i rischi.

Si richiede all‟Impresa di avvalersi delle infrastrutture tecnologiche, hardware e software, già disponibili presso il DC, con eventuali modifiche ed integrazioni ritenute necessarie, e documentate in offerta, per l‟ottimizzazione del servizio erogato dal sistema informatico dell‟Amministrazione.

Nell‟ambito dell‟infrastruttura di gestione della sicurezza va inclusa l‟infrastruttura di raccolta e correlazione degli eventi di sicurezza originati da varie sorgenti, come quelli relativi ai sistemi di infrastruttura tecnologica, quelli generati dalle componenti di tipo applicativo o quelli generati a livello di dispositivi di interconnessione e di accesso.

Come sopra indicato, il servizio richiesto dovrà garantire la gestione amministrativa ed operativa delle procedure di autenticazione degli utenti che si attestano ai sistemi informatici installati presso il DC oggetto del presente appalto e la definizione dei profili di accesso alle risorse

di sistema congruenti con il relativo ruolo di utenza. A tale proposito, sarà cura dell'Amministrazione emettere una specifica richiesta di inserimento, aggiornamento o cancellazione e fornire per ciascun utente, attraverso il responsabile dell'ufficio di appartenenza o del responsabile locale della sicurezza informatica, tutte le informazioni di configurazione necessarie per l'erogazione del servizio.

La soluzione di gestione offerta, che costituirà nel suo insieme il Security Operation Center del Comune (SOC), dovrà completamente integrarsi con l‟ infrastruttura attualmente presente nell‟ambito del sistema informatico comunale, ed evolversi sulla base dei piani programmatici e degli obiettivi strategici definiti in quest‟ambito dall'Amministrazione. L‟Impresa, nei limiti dettati dal rispetto dei livelli di servizio richiesti, dovrà effettuare tutte le attività di supporto attraverso un adeguato bilanciamento tra le risorse della propria struttura di presidio e quelle remotamente disponibili presso una propria sede. Data la criticità del servizio la sua erogazione dovrà prevedere risorse qualificate in cui dovrà essere inclusa almeno una figura dotata di certificazione come auditor BS7799 ed in cui la presenza di certificazioni del tipo:

⮚ Certified Lead Auditor BS7799 e aggiornamento alla ISO27001

⮚ Certified Information System Auditor

⮚ Certified information systems security professionals costituirà elemento positivo di valutazione dell‟offerta.

L'Impresa è tenuta a produrre, con cadenza almeno trimestrale, un report delle principali attività di amministrazione effettuate nell‟ultimo periodo di servizio e delle risultanze delle attività di monitoraggio in termini di violazioni alle politiche di sicurezza in atto.

Nell‟ambito del servizio, infine, all‟Impresa si richiede di fornire supporto al personale incaricato dell‟Amministrazione, per la stesura e l‟aggiornamento del documento programmatico di definizione e messa in atto delle opportune politiche di sicurezza (“DPS”) sulla base della normativa vigente per la Pubblica Amministrazione.

5.4.5.4 SLA relativi al servizio

La qualità del servizio viene valutata sostanzialmente tramite misure della tempestività di erogazione del servizio relativamente all‟amministrazione delle utenze, alle procedure di vulnerability assessment e a quelle di aggiornamento dei sistemi antivirus.

5.4.6 SIF – SERVIZIO DI GESTIONE DELLA SICUREZZA FISICA

5.4.6.1 Descrizione generale del servizio

La Sicurezza Fisica, per come è attualmente organizzata la gestione del DC, è competenza del‟Amministrazione (per quanto riguarda il personale in servizio nel sito e il controllo degli accessi, gestito tramite un apposito servizio di Guardiania) e del proprietario dei locali e imprese dallo stesso incaricate, per quanto riguarda i sistemi e gli impianti di:

⮚ protezione dei locali,

⮚ alimentazione elettrica (comprese le funzioni di continuità e generazione autonoma),

⮚ condizionamento,

⮚ prevenzione incendi.

All‟Impresa, pertanto, si chiedono solo compiti di monitoraggio e supporto, come di seguito specificato.

L‟Impresa, infine, è responsabile dell‟integrità fisica degli apparati che le vengono affidati in gestione tramite il presente contratto, fatti ovviamente salvi i presupposti al contorno garantiti dai sistemi di sicurezza di cui sopra.

5.4.6.2 Obiettivi del servizio

Gli obiettivi del servizio sono due:

⮚ effettuare un monitoraggio costante dei “log” prodotti dai vari sistemi di sicurezza fisica già operativi presso il DC, al fine di evidenziare eventuali situazioni critiche,

⮚ coadiuvare l‟Amministrazione nella definizione di soluzioni migliorative dello stato di sicurezza fisica del DC, fornendo supporto specialistico nell‟interfacciamento della stessa con i responsabili dei sistemi di sicurezza (principalmente Ente locatore).

5.4.6.3 Attività ricomprese nel servizio

Nell‟ambito del servizio l‟Impresa dovrà:

⮚ fornire il supporto richiesto dalle attività amministrative di configurazione dei dispositivi e delle applicazioni gestionali preposte al controllo degli accessi nei locali riservati alle infrastrutture oggetto del presente appalto;

⮚ assicurare l‟integrità fisica delle apparecchiature informatiche di proprietà dell‟Amministrazione, presenti presso i locali DC oggetto del presente appalto, e presidiati dal personale dell‟Impresa stessa. Ciò, ovviamente, nel presupposto di un corretto funzionamento di tutti i sistemi ausiliari di alimentazione, condizionamento e prevenzione incendi, che non sono responsabilità dell‟Impresa.

In fase di allestimento del servizio sarà cura dell‟Impresa definire e concordare con l‟Amministrazione gli aspetti procedurali di svolgimento del servizio, sulla base delle politiche e degli obiettivi strategici definiti in quest‟ambito dall‟Amministrazione stessa. L‟Amministrazione metterà l‟Impresa in grado di svolgere tutte le mansioni richieste attraverso tutte le azioni di sua competenza che si rendessero necessarie e ufficializzando al proprio interno le misure di sicurezza fisica adottate.

5.4.6.4 SLA relativi al servizio

La qualità del servizio sarà monitorata principalmente in relazione alla tempestività di segnalazione di criticità nei sistemi di sicurezza fisica, ove ciò non avvenga direttamente dagli enti degli stessi direttamente responsabili.

6 FASCE ORARIE

Il Servizio si prefigura a carattere continuativo. La sua erogazione è articolata nell‟arco delle 24 ore, per tutti i giorni dell‟anno solare, sulla base di predefinite “fasce orarie”, così di seguito indicato:

Fascia oraria	Xxxxxx	Xxxxxx
Antimeridiana	Lunedì – Venerdì	8.00 – 13.00
Pomeridiana	Lunedì – Venerdì	13.00 – 18.00
Mattutina	Lunedì – Sabato	7.00 – 8.00
Sabato	Sabato	8.00 – 13.00
Serale	Lunedì – Venerdì	18.00 – 24.00

Notturno	Lunedì – Sabato	0.00 – 7.00
	Sabato	13.00 – 24.00
Festivo	Domenica	0.00 – 24.00

Vengono inoltre considerati giorni festivi, e quindi assimilabili alla Domenica, tutte le festività nazionali come risultano da calendario.

Per ciascun anno solare nell‟ambito dell‟intero arco contrattuale, è richiesto all‟Impresa l‟erogazione del servizio per almeno 6 (sei) fine settimana (dalle 0.00 del Sabato alle 24.00 della Domenica) in cui il livello di prestazione richiesto è analogo a quello riservato alla normale fascia oraria degli altri giorni feriali. Il relativo corrispettivo è inteso incluso nel canone annuo proposto nell‟offerta. L‟Amministrazione si impegna a fornire un preavviso di almeno due settimane dalla specifica richiesta di servizio.

Nel caso di specifiche ed estemporanee necessità dell‟Amministrazione, come ad esempio per tornata elettorale, fiere, mostre e, in generale, eventi promossi da Roma Capitale, l‟Impresa è tenuta a fornire un servizio aggiuntivo a richiesta nell‟ambito delle tipologie previste dal presente capitolato. In questa situazione l‟Amministrazione concorderà preventivamente con l‟impresa la composizione e la pianificazione dei servizi richiesti, il cui corrispettivo verrà valutato al momento sulla base dei costi unitari per i servizi a richiesta/a progetto (cfr. Area Innovazione - Servizio Sviluppo Sistemi) specificati in fase di offerta .

7 MODALITA’ DI ESPLETAMENTO DEL SERVIZIO

È responsabilità dell'Impresa dotarsi dell'infrastruttura organizzativa, logistica e tecnologica necessaria a svolgere in piena autonomia le attività oggetto del servizio richiesto nel presente capitolato.

7.1 INFRASTRUTTURA LOGISTICA

L‟Impresa dovrà farsi carico di allestire, presso una propria sede, un‟infrastruttura logistica, qui indicata come “Centro di Gestione”, presso cui opera il proprio personale nel fornire, secondo le modalità e i contenuti sopra descritti, tutti i Servizi che non richiedano inevitabilmente la presenza fisica degli addetti presso il DC (sostanzialmente tutti, meno il Servizio di Gestione Sistemi, per il quale è invece richiesto, al contrario, un presidio H24 – v. Descrizione Generale del Servizio GSI). È inteso che particolari interventi sulle infrastrutture (es.: installazioni, riconfigurazioni, test, ecc.) potranno richiedere la presenza fisica di personale dell‟Impresa addetto a servizi diversi dal GSI, ma ciò avrà carattere eccezionale e temporaneo.

La predisposizione del Centro di Gestione sarà preferibilmente costituita da almeno due locali: uno da dedicare alle attività operative e l‟altro da dedicare ad attività di studio, analisi, presentazioni ed incontri su temi specifici di gestione. I locali dovranno essere adatti allo scopo, in conformità a quanto previsto dalla normativa vigente, e dotati dall‟Impresa di tutte le attrezzature necessarie per lo svolgimento delle attività di pertinenza. In particolare, il locale destinato alle attività di controllo e di amministrazione dovrà essere dotato di almeno 15 (quindici) postazioni di lavoro, di un proprio autonomo sistema di back-up/restore di tutta la documentazione di progetto e di sistemi atti a garantire lo svolgimento di tutte le attività richieste secondo gli standard e i livelli qualitativi previsti.

In merito all‟erogazione del servizio di Continuità Operativa, per sua stessa natura, parte delle attività verranno svolte nell‟ambito del Centro di Ripristino, messo a disposizione dall‟Impresa.

7.2 STRUTTURA ORGANIZZATIVA

L‟impresa dovrà dotarsi di una struttura organizzativa qualitativamente e quantitativamente adeguata all‟erogazione dei servizi previsti dalla fornitura.

Il dimensionamento generale della struttura e la scelta dei singoli specialisti è demandata all‟Impresa e sarà oggetto di valutazione tecnica in sede di gara. Di seguito, comunque, si indicano alcuni requisiti minimi in termini sia qualitativi sia quantitativi. Si richiedono:

⮚ un Responsabile di Progetto con le seguenti caratteristiche personali e professionali:

o ampia conoscenza dei prodotti informatici in generale, ed in particolare degli ambienti elaborativi richiesti;

o esperienza minima di 12 anni di cui almeno 2 in attività di coordinamento di progetti complessi ed in particolare di progetti di informatizzazione nella Pubblica Amministrazione;

o esperienza pluriennale di metodologie e strumenti di pianificazione e gestione dei progetti;

o elevata capacità di coordinamento, motivazione e guida di gruppi di lavoro;

o capacità di autoinformazione unita alla conoscenza di tecniche di presentazione e gestione delle riunioni e ad una sviluppata capacità negoziale;

o formale certificazione nell‟area del project management;

⮚ un Architetto Tecnologico con le seguenti caratteristiche personali e professionali:

o solide esperienze di Design Architetturale con particolare riferimento a identificazione delle aree di intervento, definizione degli strumenti adatti, delle componenti software, delle modalità di interoperazione e di migrazione e di eventuali necessità di personalizzazione;

o esperienze e forte sensibilità all‟analisi dell‟Impatto Organizzativo con particolare riferimento a implicazioni a livello organizzativo derivanti dalla soluzione identificata e suggerimenti relativi alla definizione della struttura organizzativa (persone, locazione, skills, formazione…);

o esperienze di disegno e dimensionamento dei sistemi, sia rivolti al singolo componente che nella visione d‟insieme, con particolare riferimento agli aspetti di scalabilità, disponibilità, affidabilità ed espansibilità, interoperabilità e comunicazione tra sistemi diversi;

o esperienze e capacità di consulenza e pianificazione;

o capacità di costruire modelli o progetti pilota per verificare proposte o soluzioni a problemi e di sviluppare criteri di misura per valutare prodotti e stimarne le prestazioni e la conformità con le specifiche di progetto;

o capacità di risolvere problematiche di integrazione fra ambienti eterogenei;

o conoscenza delle tecniche e delle tecnologie per l'interscambio di dati, i protocolli di livello superiore e la security;

o buone capacità gestionali, che lo rendono in grado di coordinare un piccolo gruppo e di reagire attivamente a problemi ed esigenze sopravvenute;

o capacità di stimare correttamente e di pianificare il lavoro necessario, sia proprio che delle altre risorse che operano nella propria area di responsabilità;

o capacità di gestione dei conflitti;

o esperienza nel ruolo maturata in almeno 7 anni di attività presso clienti, preferibilmente nell‟ambito della Pubblica Amministrazione;

⮚ due Sistemisti Senior, con le seguenti caratteristiche:

o esperienza minima di 10 anni di cui almeno 5 nella funzione maturata presso ambienti tecnologici complessi. Fatta salva la specializzazione primaria (che può essere diversa), le due figure devono però essere almeno parzialmente interscambiabili sui tre primari ambienti del DC oggetto della fornitura, ovvero l‟ambiente OS220, l‟ambiente AIX e l‟ambiente Windows/Linux;

o esperienza nella gestione, installazione, personalizzazione e migrazione di prodotti di IT;

o esperienza nella verifica delle prestazioni e dimensionamento delle risorse;

o capacità di supporto tecnico e risoluzione problemi sulle architetture, gli ambienti ed i prodotti impiegati nell‟area progettuale/servizio di competenza;

o esperienza di metodologie e strumenti di pianificazione.

⮚ un Senjor Security Consultant, con caratteristiche di:

o almeno 10 anni di esperienza nel settore della Sicurezza Logica, con apposite certificazioni (es.: CISSP);

o esperienze di controllo e gestione della Sicurezza Fisica;

⮚ Sistemisti, in numero a discrezione dell‟Impresa, ma sufficiente a garantire i livelli di servizio richiesti e con specializzazioni sui singoli prodotti presenti nel DC (sistemi operativi, DB management system, middleware, ecc.) distribuite in modo da garantire un minimo di interscambiabilità per ciascuna piattaforma tecnologica. Le diverse figure dovranno comunque rispondere ai seguenti requisiti:

o Sistemisti Esperti, con:

▪ esperienza minima di 8 anni di cui almeno 4 nella funzione maturata presso ambienti tecnologici complessi;

▪ esperienza di gestione, installazione, personalizzazione e migrazione;

▪ esperienza di Database Administrator su RDBMS, Oracle e/o DB2;

▪ capacità di verifica delle prestazioni e dimensionamento delle risorse;

▪ capacità di supporto tecnico alla risoluzione dei problemi;

o Sistemisti, con:

▪ esperienza minima di 4 anni di cui almeno 2 nella funzione maturata presso ambienti tecnologici complessi;

▪ esperienza di gestione, installazione e personalizzazione;

▪ capacità di verifica delle prestazioni;

▪ capacità di supporto tecnico e risoluzione dei problemi sugli ambienti ed i prodotti impiegati nell‟area di competenza;

o Sistemisti junior, con:

▪ esperienza almeno 2 anni nella funzione maturata presso ambienti tecnologici di media complessità;

▪ esperienza sugli ambienti ed i prodotti impiegati nell‟area di competenza.

⮚ Operatori di sistema, in numero a discrezione dell‟Impresa sufficiente a garantire i livelli di servizio richiesti e con un meccanismo di “turnazione” che permetta la richiesta copertura H24 con presenza minima nel DC di due operatori contemporaneamente, anche di notte e nei giorni festivi. Dovrà essere inoltre garantita, in ogni istante, la capacità operativa su tutte le piattaforme tecnologiche esistenti nel DC. È richiesta:

o esperienza minima di 2 anni;

o attitudine al lavoro di gruppo e disponibilità a lavorare su turni;

o esperienza sugli ambienti operativi nel servizio di competenza.

Per le prime quattro figure (Responsabile di Progetto, Architetto Tecnologico e Senior Security Consultant, Sistemisti) l‟Impresa dovrà fornire, in fase di gara, dettagliata documentazione circa le esperienze ed il profilo professionale posseduti (ancorché, se vuole, in modo anonimo).

Per tali figure costituisce elemento di valutazione la presenza di certificazioni corrispondenti al ruolo o alle aree di attività di competenza (es. PM, DB Administration, Oracle, sistemi operativi, sicurezza).

Sarà fattore di maggiore valutazione la presenza di almeno una figura con possesso di certificazione SAP.

Il personale dell‟Impresa dovrà operare secondo le seguenti modalità:

⮚ per il Servizio GSI, con personale operativo presso il DC dimensionato sulla base delle necessità dettate dalle attività operative giornaliere necessarie a garantire la

puntuale erogazione e l‟adeguata disponibilità dei servizi informatici erogati dal centro. In ogni caso con un minimo di 2 unità che garantiscono il presidio H24 richiesto e con un massimo di 5 unità corrispondenti ai posti di lavoro assicurati dall‟Amministrazione;

⮚ con la presenza temporanea, quando necessario, presso gli Uffici del Dipartimento del Responsabile di Progetto e/o del Responsabile di Gestione, per interfacciare la direzione del Dipartimento stesso, in occasione degli incontri periodici definiti e per qualunque problematica di carattere contrattuale, organizzativa o tecnologica;

⮚ con la presenza temporanea, quando necessario, presso gli Uffici del Dipartimento di specialisti dedicati ad attività di supporto necessarie a garantire i livelli di qualità richiesti dai servizi informatici erogati;

⮚ con tutto il resto del personale, dedicato ad attività di amministrazione, di supporto e di gestione e controllo dell‟infrastruttura tecnologica oggetto del presente appalto, operante presso il Centro di Gestione dell‟Impresa.

Per quanto riguarda le funzioni a carattere specialistico di presidio e controllo delle infrastrutture, previste nell‟ambito di molteplici servizi, l‟Impresa dovrà garantire la presenza nel Centro di Gestione di almeno 5 (cinque) risorse sistemistiche nella fasce orarie “Antimeridiana” e “Pomeridiana”.

Per quanto riguarda le altre fasce orarie (“Serale”, “Notturna”, “Mattutina”, “Sabato” e “Festiva”), l‟Impresa dovrà assicurare un servizio sistemistico di reperibilità, al fine di garantire i livelli di servizio con le relative penalità definiti nella Scheda Allegata P1.

Tali risorse dovranno possedere competenze specialistiche necessarie ad offrire il supporto richiesto dalle varie problematiche operative, architetturali e tecnologiche coinvolte dall‟infrastruttura informatica centrale dell‟Amministrazione e a garantire i servizi IT erogati dall‟Amministrazione in quella fascia oraria. Nell‟erogazione dei servizi richiesti, l‟Impresa ed il relativo personale sono tenuti al rispetto delle correnti disposizioni di legge in materia secondo il D.lvo n. 196/2003 e relative integrazioni.

7.3 INFRASTRUTTURA TECNOLOGICA

L‟infrastruttura tecnologica di gestione del DC può essere fisicamente e logicamente suddivisa in due principali macro componenti:

⮚ una componente di gestione centralizzata ed integrata che estenda ed aggiorni le piattaforme gestionali attualmente esistenti presso l‟Amministrazione;

⮚ un‟ulteriore componente, presente presso il Centro di Gestione dell‟Impresa, composta dalle stazioni remote di tale infrastruttura, necessarie alle attività di monitoraggio, di controllo ed operative del personale sistemistico dell‟Impresa.

La componente presso il Centro di Gestione è completamente a carico dell‟Impresa (inclusi gli aspetti contrattuali relativi ai prodotti HW e SW che la costituiscono). Sono inoltre a carico dell‟Impresa tutte le attività operative necessarie per l‟aggiornamento di ambedue le componenti, mentre rimane a carico dell‟Amministrazione l‟acquisizione delle componenti infrastrutturali hardware e software necessarie per la componente centralizzata.

L‟aggiornamento e l‟estensione della componente centralizzata dovrà inoltre indirizzare i requisiti espressi all‟interno dei servizi esposti nel presente documento e, in particolare:

⮚ rendere disponibile una base dati di configurazione che descriva tutte le componenti, hardware e software, caratteristiche dei sistema informativo comunale, e delle relazioni che le caratterizza (“Configuration Management”);

⮚ offrire una componente che supporti il flusso di controllo e gestione dei cambiamenti alle componenti tecnologiche ed applicative dell‟ambiente informatico comunale (“Change Management”);

⮚ offrire una componente di gestione dei problemi, di responsabilità dell‟Impresa, che si integri, sia in termini di processo che tecnologici, con le procedure e la piattaforma di controllo degli incidenti e dei problemi messa a disposizione dall‟Amministrazione (“Problem Management”);

⮚ offrire funzionalità di monitoraggio caratterizzate da un‟adeguata copertura di tutte le componenti tecnologiche ed applicative esistenti, attraverso una console di gestione direzionale che mostri lo stato di operatività di ciascun servizio applicativo erogato dal sistema informatico comunale, integrandosi ed estendendo le soluzioni di monitoraggio attualmente presenti presso il centro;

⮚ integrarsi con le attuali piattaforme architetturali di gestione della sicurezza logica adottate dall‟Amministrazione;

⮚ offrire funzionalità di automazione nell‟ambito dei processi gestionali coinvolti dai servizi offerti dall‟Impresa;

⮚ rendere disponibile una piattaforma di reportistica e di gestione dei livelli di servizio che misuri e visualizzi la qualità dei servizi IT erogati dall‟Amministrazione, la qualità dei servizi gestionali caratteristici del presente bando e quella relativa ai contratti che l‟Amministrazione ha in essere con fornitori esterni e coinvolti dai servizi gestionali offerti dall‟Impresa;

⮚ offrire modalità di accesso, sia al personale dell‟Impresa, sia a quello dell‟Amministrazione, sia – ove richiesto – al personale dell‟Impresa aggiudicataria del Lotto 2, attraverso interfacce di tipo Web.

La componente di gestione centralizzata dovrà avvalersi, aggiornandole ed estendendole, delle attuali piattaforme tecnologiche adottate dall‟Amministrazione. Durante la fase di transizione (allestimento del servizio) l‟Impresa dovrà inoltre farsi carico, sulla base dell‟architettura definita per le componenti gestionali centralizzate appositamente predisposte per l‟erogazione del servizio, della migrazione, ove richiesto, delle basi dati di gestione preesistenti dall‟attuale infrastruttura verso quella di arrivo.

Rimangono a carico dell‟Amministrazione per l‟intera durata del servizio oggetto del presente appalto, i contratti di noleggio e manutenzione hardware e delle licenze software di base e di gestione relative alle apparecchiature installate nel sito primario.

Sono completamente a carico dell‟Impresa le eventuali licenze di altre componenti, al di fuori di quelle sopra descritte, che dovessero essere utilizzate dal proprio personale nell‟ambito dei servizi di gestione erogati.

Per le problematiche connesse all'erogazione del servizio, rimane comunque a carico dell'Impresa:

⮚ l'infrastruttura di rete, ad alta velocità e sicura, per la connessione remota del Centro di Gestione con il DC;

⮚ la disponibilità del servizio telefonico per le chiamate verso il Centro di Gestione e/o verso la funzione di Service Desk;

⮚ la disponibilità delle stazioni remote dell‟infrastruttura di gestione, necessarie alle attività di monitoraggio, di controllo ed operative del personale sistemistico dell‟Impresa.

7.4 ULTERIORI CARICHI DELL’IMPRESA

Sono, inoltre, a carico dell'Impresa i costi del personale di gestione, della strumentazione di produttività adottata, dei materiali utilizzati, dei locali, delle attività di trasporto, e d‟ogni altro elemento strumentale, al di fuori di quanto sopra riportato, che si renda necessario per l‟erogazione del servizio.

Sono a carico dell‟Impresa i costi di smaltimento dei propri materiali di consumo, tecnologici e non, che risultino non più utilizzabili nell'ambito delle attività previste dall‟erogazione del servizio oggetto del presente appalto.

I ruoli e le responsabilità che spettano all‟Impresa e all‟Amministrazione nell‟ambito delle attività associate all‟erogazione del servizio sono descritte nella Scheda Allegata O1.

I Livelli di Servizio erogati dovranno essere conformi a quanto riportato nella Scheda Allegata

P1.

8 DOCUMENTAZIONE

L'Impresa è tenuta a creare e mantenere aggiornati, senza ulteriore corrispettivo rispetto al prezzo offerto, il Piano della Qualità, il Piano di Formazione, il Piano di Progetto , i Manuali e Piani Operativi relativi ai singoli servizi, e il Piano di Disaster Recovery, nonché ogni altra documentazione operativa e tecnica – redatta in lingua originale italiana – idonea ad assicurare il funzionamento delle infrastrutture Hardware e Software oggetto dell‟appalto.

Dovrà essere inoltre garantito l‟aggiornamento di tutta la documentazione a corredo dell‟inventario hardware, software, delle banche dati e dei programmi applicativi. Il contenuto della documentazione di cui sopra potrà, di comune accordo fra le parti, essere variato ed integrato nel corso dei lavori, al fine di ottimizzarne l‟efficacia.

L'Impresa è inoltre tenuta a fornire tutta la documentazione, sviluppata nell'ambito dell'allestimento del servizio e/o modificata durante tutta la sua erogazione, riguardante:

⮚ la strumentazione, standard e non, adottata nell'erogazione del servizio,

⮚ le metodologie ed i processi di gestione utilizzati,

⮚ i manuali operativi adottati dai propri addetti al servizio.

Tutta la documentazione dovrà essere disponibile per l‟Amministrazione in modalità WEB e con possibilità di scaricare i documenti medesimi mediante i formati standard di mercato e quelli adottati dall‟Amministrazione.

9 PIANO DELLA QUALITA’

L'Impresa dovrà presentare, in sede di allestimento del servizio, un Piano della Qualità dei servizi offerti, che risponda

⮚ ai principi di assicurazione e gestione della qualità definiti nelle norme ISO 9001 e/o ISO 20000 vigenti

⮚ alle Linee Guida applicabili della norma UNI ISO 10005:2007 “Linee guida per i piani della qualità”.

Struttura e contenuto minimo del Piano della Qualità devono rispondere allo schema riportato nella citata Scheda Allegata Q.

L'Impresa dovrà assicurare la qualità dei servizi erogati, attraverso la presenza al suo interno di specifiche funzioni di verifica, validazione e riesame della qualità sui prodotti e sui processi, che si devono basare sui principi prescritti dalle norme citate.

L'Impresa si impegnerà a realizzare uno specifico sistema di controllo della qualità, relativo al presente appalto e ad attivarlo fin dall‟inizio dei lavori, registrando tutti i parametri di qualità dei servizi erogati.

10 PIANO DI FORMAZIONE

Il Piano di Formazione che l'Impresa dovrà formulare dovrà assicurare il completo trasferimento all‟Amministrazione di tutte le competenze necessarie all'utilizzo ed al controllo delle soluzioni proposte nell'erogazione del servizio. I servizi di formazione dovranno essere rivolti essenzialmente al personale del Dipartimento Risorse Tecnologiche e Servizi Delegati che interfaccia l'Impresa per i servizi ad essa affidati.

11 ALLESTIMENTO E RILASCIO DEL SERVIZIO E PIANO DI PROGETTO

L‟allestimento del servizio da parte dell‟impresa deve avvenire secondo quanto disposto dal Capitolato Speciale e del presente Capitolato Tecnico in termini di logistica, organizzazione, sicurezza , documentazione e quanto altro necessario.

Inoltre l‟Impresa deve seguire le disposizione dell‟Amministrazione, mentre questa è impegnata nella fase di rilascio del servizio da parte della precedente impresa appaltatrice e descritto nel Capitolato Speciale al fine di acquisire tutti gli elementi necessari per svolgere adeguatamente e proficuamente il servizio appaltato.

Nel quadro della documentazione richiesta al termine del periodo di allestimento, l‟Impresa dovrà produrre un Piano di Progetto che

a. formalizzerà la struttura organizzativa effettiva per il governo del progetto e la erogazione dei servizi, con il modello organizzativo, la descrizione del Team di Progetto, i ruoli e le responsabilità, le regole di comunicazione interne al Team e con il Dipartimento Risorse Tecnologiche e Servizi Delegati;

b. descriverà, nei tempi e nei modi, tutti i “transitori” previsti nel corso della fornitura, per tutti i servizi erogati.

Mentre, infatti, la descrizione delle attività operative “di routine” è demandata ai Manuali e Piani Operativi, mediante il Piano di Progetto l‟Impresa dovrà descrivere come affronterà i processi “straordinari” quali, ad esempio:

⮚ la messa in esercizio, a fine allestimento, dei diversi servizi,

⮚ il passaggio, per il servizio di Continuità Operativa, dalla “forma base” a quella “evoluta”,

⮚ la fase di rilascio finale del servizio.

Il Piano di Progetto sarà utilizzato durante il Collaudo del servizio e, successivamente, come riferimento organizzativo di alto livello e per la governance di tutti i “transitori”. Dovrà essere inoltre aggiornato dall‟Impresa a fronte di cambiamenti organizzativi o di eventuali modifiche dei servizi che producano nuovi “transitori” non previsti ad inizio fornitura.

12 COLLAUDO DEL SERVIZIO

Il collaudo del servizio sarà effettuato dall‟Amministrazione tramite una commissione appositamente eletta e formata da elementi interni ed esterni all‟Amministrazione stessa. Le modalità di collaudo saranno definite dalla stessa Impresa aggiudicataria, ma saranno ovviamente sottoposte all‟approvazione dell‟Amministrazione, secondo il processo di seguito indicato.

Entro 30 giorni lavorativi dalla data di consegna dei lavori il fornitore dovrà consegnare all'Amministrazione un documento contenente le Specifiche di dettaglio delle prove di collaudo (SDPC), contenente la specifica dettagliata delle attività di collaudo relative a tutti gli aspetti dei diversi servizi oggetto della fornitura.

Per quanto riguarda l'Area di Governo e Coordinamento, le SDPC dovranno consentire di verificare come, sul piano metodologico e tecnologico, il fornitore fornirà i servizi DLA, CLS e PGD. Tra l'altro dovrà essere specificato:

1. come verificare le modalità di misura dei livelli di servizio previsti,

2. come verificare le modalità di calcolo delle relative penali,

3. come verificare le funzionalità del Repository dei documenti di progetto.

Per quanto riguarda l'Area di Innovazione, le SDPC dovranno consentire di verificare come, sul piano metodologico e tecnologico, il fornitore fornirà i servizi EPS e SSI. Tra l'altro dovrà essere specificato:

4. come verificare i metodi e le tecniche di report sullo stato di utilizzo dei sistemi del DC,

5. come verificare i metodi e le tecniche usati per segnalare in tempo utile l‟approssimarsi di stati di saturazione di singole componenti.

Per quanto riguarda l'Area di Esercizio, le SDPC dovranno consentire di verificare come, sul piano metodologico e tecnologico, il fornitore fornirà i servizi PGC, GSI, MSI, COP, SIL e SIF. Tra l'altro dovrà essere specificato:

6. come verificare i metodi e le tecniche per l' attività di censimento continuo delle componenti HW e SW,

7. come verificare le funzionalità del Configuration Management Data Base,

8. come verificare le funzionalità del Disater Recovery simulando disastri e ripristini in modo esaustivo,

9. come verificare le funzionalità di monitoraggio delle violazioni di sicurezza e dei tentativi di intrusione (intrusion detection) e gestione centralizzata degli incidenti di sicurezza.

Il documento SDPC sarà esaminato dall'Amministrazione che potrà approvarlo integralmente, richiedere emendamenti o non approvarlo.

In caso di non approvazione, sarà facoltà del dell'Amministrazione riassegnare la fornitura al fornitore successivo nella graduatoria di gara.

Sulla base delle SDPC approvate dall‟Amministrazione, la stessa provvederà, mediante la citata apposita Commissione di collaudo, entro 5 giorni dall'approvazione, al collaudo dei servizi oggetto della fornitura.

L‟esito positivo del collaudo di ciascun servizio consentirà il rilascio del servizio. La data del verbale di collaudo, congiuntamente sottoscritto, verrà considerata quale data di accettazione ed attivazione dei servizi oggetto della fornitura. Tale data sarà considerata come l‟inizio dell‟erogazione dei servizi, salvo diverso accordo tra le parti sulla data di inizio dell‟erogazione.

In caso di esito negativo ripetuto, sarà facoltà dell'Amministrazione riassegnare la fornitura al fornitore successivo nella graduatoria di gara.

13 GLOSSARIO

Si riportano, nella seguente tabella, i significati attribuiti, nel presente documento, ad alcuni termini dal medesimo utilizzati, riportati in ordine alfabetico. Si sottolinea che l‟elenco non è esaustivo nei confronti di tutti i termini (a carattere tecnico, organizzativo o economico) utilizzati, non riportando quelli che si ritengono ampiamente descritti nel capitolato e allegati (es.: Livelli di Servizio) o comunque poco soggetti a errori d‟interpretazione (es.: CPU).

Ambienti logici

Sono costituiti da singoli “ambienti operativi” isolati e auto-consistenti, coincidenti con le singole istanze dei diversi sistemi operativi. In sostanza possono essere:

▪ singoli server fisici “mono-boot” (generalmente Windows o Linux),

▪ singole “macchine virtuali” Windows, Linux o AIX,

▪ singole partizioni logiche (LPAR) OS2200.

Amministrazione	Il termine indica: ▪ Roma Capitale, nel suo complesso, ▪ lo specifico Dipartimento Risorse Tecnologiche e Servizi delegati, responsabile della gestione del Data Center (vedi) e dunque dell‟assegnazione, per gara, dei servizi richiesti dal presente capitolato Il contesto non dovrebbe lasciare dubbi circa l‟accezione che al termine viene attribuita di caso in caso.
Continuità Operativa	Anche detta “Business Continuity”. È la caratteristica richiesta per i servizi ICT forniti dall‟Amministrazione, che devono essere: ▪ erogati con continuità (ovvero senza interruzioni) nei limiti temporali e con i livelli di servizio condivisi con i singoli utenti, ▪ in caso di interruzioni inevitabili, ripristinati nel più breve tempo possibile e comunque secondo i parametri indicati. Il secondo punto comprende il concetto di Disaster Recovery (vedi)
Data Center	Il termine indica: ▪ i locali del DC, utilizzati da Roma Capitale per ospitare una serie di infrastrutture ICT finalizzate all‟erogazione, da parte dell‟Amministrazione, di servizi informatici per l‟Amministrazione stessa e per i Cittadini, ▪ un sottoinsieme delle infrastrutture ICT di cui sopra, anche detti “Sistemi Centrali”, oggetto dei servizi richiesti dal presente capitolato. Il contesto non dovrebbe lasciare dubbi circa l‟accezione che al termine viene attribuita di caso in caso.
DC	Vedi “Data Center”
Disaster Recovery	È parte della Continuità Operativa. Mentre questa, infatti, ha l‟obiettivo di evitare le interruzioni di servizio e di minimizzarne in ogni caso i danni (qualora siano inevitabili), il Disaster Recovery è appunto finalizzato a limitare i danni delle interruzioni più gravi: quelle che rendano inagibile, per un tempo medio-lungo, l‟intero Data Center o sue parti vitali. Il processo di Disaster Recovery prevede, pertanto, la ripartenza dell‟operatività – totale o ridotta – presso un “Centro di Recovery” (o “di Ripristino” o “Secondario”), fino a quando non sarà riusabile il Data Center (“primario”). Il processo di Disaster Recovery, in termini applicativi, è caratterizzato dai parametri di RTO e RPO (vedi) richiesti per i singoli servizi applicativi.
DR	Xxxx “Disaster Recovery”
Incidenti e Gestione degli Incidenti	Si intendono con il termine “incidenti” tutti gli eventi non pianificati e non previsti che possono interrompere l‟erogazione di un servizio o ridurne il livello di qualità stabilito nel contratto (SLA). La Gestione degli Incidenti è il processo reattivo che si innesca ad ogni incidente, finalizzato a ridurne quanto più possibile gli effetti dannosi sui servizi impattati (ad esempio avviando una procedura di “by-pass”). Vedi anche “Problemi e Gestione dei Problemi.
Manuale Operativo	Documento che descrive le caratteristiche di un singolo servizio (obiettivi, metodologie, modalità di erogazione, risorse e strumenti utilizzati, ecc.)
Piano Operativo	Documento che descrive le caratteristiche temporali di erogazione di un singolo servizio (scadenze, durate, periodicità, ecc.)
Piano Operativo Giornaliero	È previsto solo per il Servizio di Gestione dei Sistemi. Viene dedotto giornalmente dal Piano Operativo “generale” di tale servizio e descrive, normalmente, le attività da effettuare nelle 24 ore successive. In caso di festività e prima dei week-end descrive le 48 o 72 ore successive.

Problemi e Gestione dei Problemi	Si intendono con il termine “problemi” le condizioni – indesiderate – che sono causa di “incidenti” (vedi). La Gestione dei Problemi è il processo che, partendo dall‟analisi degli incidenti, ne determina le cause (cioè i problemi) e disegna una o più azioni finalizzate alla loro rimozione definitiva. Il processo è più spesso reattivo, ma può essere anche proattivo, se si basa su un‟analisi dei punti deboli del sistema, cercando di individuare a priori i possibili problemi che, magari, non hanno ancora determinato incidenti. NB: nel testo del Capitolato si parla di “Gestione dei Problemi” includendo in questo termine – per semplicità espositiva – la Gestione degli Incidenti.
PMT/CDQ	È un servizio – richiesto dall‟Amministrazione ad altra Impresa e oggetto del Lotto 2 della gara – di supporto all‟Amministrazione stessa per il Project Management Tecnico ed il controllo di qualità dei servizi oggetto del presente capitolato.
RPO	O “Recovery Point Objective”. Si riferisce al processo di Disaster Recovery (vedi) ed indica – per ogni singolo servizio applicativo – la quantità massima accettabile di aggiornamento dei dati che si può perdere a seguito del “disastro”. Viene espresso in termini temporali (tipicamente “ore” o “minuti”) e indica l‟intervallo temporale immediatamente precedente il disastro durante il quale erano stati “inseriti” gli aggiornamenti che si può accettare di perdere. Esempio: se per l‟applicazione “X” si dice che lo RPO è di 15 minuti, significa che si può accettare, al massimo, la perdita degli aggiornamenti ai suoi dati inseriti negli ultimi 15 minuti prima del disastro. RPO può essere uguale a zero (non si possono perdere dati) o infinito (non ha alcuna importanza la perdita dei dati). Attenzione: si può avere anche RPO = e RTO = 0 (il servizio non si deve interrompere, anche se è ammessa la perdita di dati), ovvero RPO = 0 e RTO = 3 settimane (il servizio può ripartire anche dopo un tempo lungo, ma non è ammessa la perdita di alcun dato).
RTO	O “Recovery Time Objective”. Si riferisce al processo di Disaster Recovery (vedi) ed indica – per ogni singolo servizio applicativo – il tempo di ripristino massimo accettabile per quel servizio dopo il “disastro”. Viene espresso in termini temporali (tipicamente “ore” o “giorni”). Esempio: se per l‟applicazione “X” si dice che lo RTO è di 8 ore, significa la stessa deve essere di nuovo disponibile agli utenti, al massimo, entro 8 ore dopo il disastro. RTO può essere uguale a zero (il servizio non è praticamente interrompibile, ovvero, come si suole dire, è in “High Availability”) o infinito (ovvero la sua ripartenza non è definita a priori: sarà decisa, a bassa priorità, solo dopo il disastro). Attenzione: si può avere anche RPO = e RTO = 0 (il servizio non si deve interrompere, anche se è ammessa la perdita di dati), ovvero RPO = 0 e RTO = 3 settimane (il servizio può ripartire anche dopo un tempo lungo, ma non è ammessa la perdita di alcun dato).
Sistemi Centrali	L‟insieme delle infrastrutture hardware e software oggetto dei servizi richiesti dal capitolato. Tale insieme è solo parte – seppure preponderante – di tutte le infrastrutture ICT ospitate dal DC dell‟Amministrazione, che comprendono anche infrastrutture per la rete TLC e per il Fleet Management.
Software applicativo	L‟insieme del codice sviluppato “ad hoc” dall‟Amministrazione o da Imprese dalla stessa allo scopo ingaggiate, per erogare i servizi resi agli utenti interni e a quelli esterni (cittadini, imprese, altre AA.PP.). Il termine comprende anche le eventuali personalizzazioni dei parametri di funzionamento di prodotti di generale utilizzo (es.: SAP), ma non le librerie originali di distribuzione di questi prodotti, che rientrano nella categoria dei “Software di ambiente” (vedi).
Software di base, d’ambiente e di gestione	L‟insieme: ▪ dei sistemi operativi (OS2200, Windows, Linux. AIX, ecc.), ▪ dei prodotti software di gestione “tecnologica” dei sottosistemi (es.: i Data Base Management System come Oracle e DB2, i prodotti di gestione dello storage, come il Tivoli Storage Manager, ecc.), ▪ dei prodotti software per gli ambienti applicativi (es.: SAP, Websphere AS o Portal, JBOSS, ecc.).

Document Metadata

Table of Contents

Capitolato Tecnico Lotto 1

Document Metadata