CAPITOLATO PRESTAZIONALE
CAPITOLATO PRESTAZIONALE
Servizio di manutenzione ed assistenza della server farm del Comune di Spoleto compresa la realizzazione di tre progetti IT finalizzati all’ottimizzazione dell’infrastruttura IT dell’Ente
ARTICOLO 1 - OGGETTO DEL SERVIZIO - DURATA CONTRATTUALE 2
ARTICOLO 2 - DEFINIZIONI 3
ARTICOLO 3 - IMPORTO POSTO A BASE DI GARA – MODALITA’ DI PAGAMENTO 4
ARTICOLO 4 - AMBITO DI APPLICAZIONE 4
ARTICOLO 5 - OBBLIGHI DOCUMENTALI A NORMA ISO 20000:2005 5
ARTICOLO 6 - DESCRIZIONE DEL SERVIZIO DI MANUTENZIONE E ASSISTENZA 8
ARTICOLO 7 - PROGETTI “IT” DA REALIZZARE 12
7.1. PROGETTO POS 12
7.2. PROGETTO ORSIT 13
7.3. PROGETTO DRBC 16
ARTICOLO 8 - SERVIZIO DI HELP DESK 20
ARTICOLO 9 - VERIFICA DI CONFORMITA’ DEL SERVIZIO - DIRETTORE DELL’ESECUZIONE – COLLAUDO DEI TRE PROGETTI IT 22
ARTICOLO 10 – CERTIFICATO DI VERIFICA DI CONFORMITA’ 22
ARTICOLO 11 – CONTROLLI - PENALI 22
ARTICOLO 12 - RISOLUZIONE DEL CONTRATTO 23
ARTICOLO 13 – CAUZIONE DEFINITIVA 23
ARTICOLO 14 – DIVIETO DI CESSIONE DEL CONTRATTO - SUBAPPALTO - CESSIONE DEI CREDITI 24
ARTICOLO 15 - TRACCIABILITÀ DEI FLUSSI FINANZIARI 24
ARTICOLO 16 – FORMA DI MANIFESTAZIONE DELLA VOLONTÀ 24
ARTICOLO 17 – SPESE CONTRATTUALI 24
ARTICOLO 18 – FORO COMPETENTE 24
ARTICOLO 19 – NORME DI RINVIO 24
ARTICOLO 1 - OGGETTO DEL SERVIZIO - DURATA CONTRATTUALE
1. Il presente appalto ha per oggetto il servizio di help desk, di manutenzione e assistenza “chiavi in mano”, nonché di supporto al personale dell’ufficio SITEL (Servizi Informatici e Telefonici dell’Ente), per la gestione della server-farm del Comune di Spoleto con inclusa la realizzazione di tre progetti IT finalizzati all’ottimizzazione dell’infrastruttura IT del’Ente (art. 7);
2. Tutte le attività e i progetti di cui al presente capitolato dovranno essere realizzati in conformità al Codice dell’Amministrazione Digitale (Dlgs 235/2010) nonché a quanto previsto dalla normativa vigente per le pubbliche amministrazioni in materia di:
a) privacy e trattamento dei dati (v. Dlgs 196/2003 e s.m.i nonché le disposizioni e le direttive del Garante per la Privacy);
b) sicurezza informatica;
c) gestione e monitoraggio delle risorse informatico-tecnologiche;
3. la server-farm del Comune di Spoleto è basata principalmente sulle seguenti tecnologie:
1) Microsoft (piattaforma Windows XP/Server)
2) Vmware (per la virtualizzazione delle risorse hw-sw)
3) Citrix (per la pubblicazione/distribuzione delle applicazioni in modo centralizzato)
4) Database open source e proprietari, es: MySQL (open source), SLQ Server 2005, Oracle 10g, ecc
5) Sistemi operativi e applicativi “open source” di vario tipo: es. Linux (varie versioni), browser, ecc.
4. l’ infrastruttura di rete utilizzata dal Comune di Spoleto per collegare le varie sedi comunali e/o i client alla server-farm si basa attualmente sulle seguenti tecnologie: ADSL/MPLS, Wireless (Hiperlan/WiMax/Wi-fi) e fibra ottica;
5. la server-farm è attualmente dislocata presso X.xxx Xxxxxxxx (Xxxxxx xxx Xxxxxx, x. 0 – ingresso via Saffi); eventuali cambiamenti di sede per esigenze di tipo tecnico od organizzativo dell’Ente, non daranno luogo al riconoscimento di alcun onere aggiuntivo, a qualsiasi titolo richiesto, rispetto all’importo contrattuale;
6. per ragioni di sicurezza la conoscenza approfondita dell’infrastruttura tecnologica del Comune di Spoleto (e dei relativi componenti) potrà essere acquisita dalla Ditta in sede di sopralluogo da concordare con il resp.le dell’uff. SITEL, il xxxx. Xxxx Xxxxxxx (e-mail: xxxx.xxxxxxx@xxxxxx.xxxxxxx.xx.xx; cell: 000 0000000). Durante il sopralluogo, da effettuare presso la server-farm dell’Ente, la Ditta avrà l’onere di:
a) prendere visione dei locali della server-farm verificando tutti gli aspetti tecnico-logistici connessi con il posizionamento dell’hardware oggetto della fornitura;
b) effettuare il censimento delle attrezzature infomatico-tecnologiche ivi installate e dei software utilizzati oggetto delle attività o dei progetti di cui all’ art. 7;
c) acquisire informazioni sul costo medio annuale C (e il relativo dettaglio) di gestione dell’infrastruttura IT del Comune di Spoleto, come determinato all’ art. 7.2 comma 2 punto c) e all’art. 14.3 del bando;
d) acquisire le liste del software di base e dell’hardware di base nonché quella del “software contrattualizzato” e dell’ “hardware contrattualizzato” (art. 2);
e) acquisire le lista dei “servizi essenziali” e dei “servizi strategici” (art. 2)
f) con il supporto e l’autorizzazione del SITEL effettuare test sull’infrastruttura informatico-tecnologica dell’Ente e/o rilevazioni di tipo statistico sull’ utilizzo delle risorse hw-sw della server-farm;
g) acquisire tutte le informazioni necessarie sui contratti o i termini di garanzia e/o di assistenza e/o di licensing sottoscritti dall’Ente sul materiale hw-sw oggetto del censimento;
h) acquisire tutte le informazioni sull’infrastruttura IT dell’Ente utili per la realizzazione dei progetti di cui all’art. 7
verificando l’esistenza di particolari problematiche o criticità;
i) qualsiasi altra informazione utile ai fini della definizione dell’offerta tecnico-economica di cui al presente capitolato;
7. i termini di avvio e di durate dei servizi di help desk, di manutenzione e assistenza “chiavi in mano”, nonché di supporto al personale dell’ufficio SITEL (Servizi Informatici e Telefonici dell’Ente), per la gestione della server-farm del Comune di Spoleto oggetto del presente appalto, sono specificati all’art. 6.1 del bando;
8. la tempistica di realizzazione dei tre progetti IT è specificata all’art. 6.1 del bando;
9. la data di inizio per l’implementazione dei progetti di cui all’art. 7 nonché per l’erogazione di tutte le attività e servizi indicati nel presente appalto non potrà essere antecedente al 16 febbraio 2012.
ARTICOLO 2 - DEFINIZIONI
1. Al presente capitolato si applicano le seguenti definizioni:
a) sistema IT (o “sistema”): con tale termine si intende:
• qualsiasi dispositivo hardware (server, apparati di rete attivi/passivi e di sicurezza, gruppi di continuità elettrici (UPS), sistema o apparati di climatizzazione (condizionatori, ecc), ecc) installato nella server- farm;
• qualsiasi software (firmware, applicativi di tipo gestionale o sistemistico, sistema operativo, ecc) installato nella server-farm;
• integrazione/collegamenti di sottosistemi hw-sw con specifiche funzionalità e finalità (es. sottosistema di backup);
b) equivalenza funzionale: due dispositivi hardware, due software o, più in generale, due sistemi si definiscono “funzionalmente equivalenti” se presentano le medesime caratteristiche e/o funzionalità. Ai fini della presente fornitura si considerano “funzionalmente equivalenti” anche quelle soluzioni “non equivalenti” a patto che la “non equivalenza” sia ristretta a delle funzionalità sino ad ora non utilizzate o, comunque, non di interesse per l’Ente. Tali funzionalità dovranno essere rilevate e certificate con apposito verbale in sede di sopralluogo. Si precisa che per “funzionalmente equivalenti” si intende non solo l’equivalenza a livello di specifiche e/o di caratteristiche tra due software ma anche a livello di integrazione con altri software e/o banche dati qualora questa funzionalità fosse stata implementata dall’Ente, ossia: se l’Ente utilizza un software P che si integra con le banche dati (database) A e B e con il software C, il nuovo software S dovrà anch’esso integrarsi con A, B, C;
c) software sistemistico: rientrano in questa categoria quei software necessari per il funzionamento dei software applicativi e/o comunque essenziali per garantire – a livello server - le funzionalità di virtualizzazione, di pubblicazione delle applicazioni, di rete, di salvataggio dati, di backup-recovery o di sicurezza nonché tutti quei servizi necessari per il collegamento al sistema IT dei client. Rientrano ad esempio (a titolo indicativo e non esaustivo) in questa categoria: i sistemi operativi, i database, i sistemi di backup, di virtualizzazione (es. VmWare\Vsphere, ecc) o di pubblicazione delle applicazioni (es. Citrix), i sistemi di controllo e di monitoraggio del traffico di rete, i certificati digitali per web server, i sistemi antivirus e antispam, i sistemi per la gestione dei file e delle stampe e della posta elettronica, ecc.
d) software applicativo : rientrano in questa categoria quei software progettati per dare all’utenza la possibilità di accedere a una o più banche dati (database) e di effettuare elaborazioni sui dati ivi contenuti più o meno complesse in modalità terminale o attraverso l’utilizzo di un’interfaccia grafica. Rientrano ad esempio (a titolo indicativo e non esaustivo) in questa categoria: i gestionali, i client di posta elettronica, le suite di office
automation, le utility (reader, convertitori, ecc), i sistemi di pubblicazione di banche dati audio-video e multimediali (anche in ambiente web).
e) software contrattualizzato: rientrano in questa categoria i software per cui l’Ente ha sottoscritto specifici accordi o contratti di assistenza e/o manutenzione (diversi da quelli che regolamentano l’uso delle licenze software e i relativi servizi di “subscription”) con soggetti esterni;
f) hardware contrattualizzato: rientrano in questa categoria quei dispositivi hardware per cui l’Ente ha sottoscritto specifici accordi o contratti di assistenza e/o manutenzione (diversi da quelli che regolamentano i servizi di garanzia forniti dal produttore dello specifico dispositivo) con soggetti esterni;
g) software di base: si tratta di una particolare categoria di software che comprende quelli di tipo sistemistico o, comunque, quelli “necessari” per garantire l’operatività della server-farm o di alcune sue funzioni ritenute essenziali dall’Ente;
h) hardware di base: si tratta di una particolare categoria di hardware che comprende i dispositivi hardware necessari per garantire l’operatività della server-farm o di alcune sue funzioni ritenute essenziali dall’Ente;
i) RTO – Recovery Time Objective: il tempo necessario per il pieno recupero dell’operatività di un sistema o di un processo organizzativo ossia, in sintesi, la durata massima – prevista o tollerata - dell’interruzione di servizio;
l) RPO – Recovery Point Objective: il tempo massimo che intercorre tra la produzione o generazione di un dato e la sua messa in sicurezza (ad esempio mediante backup) e fornisce, conseguentemente, una misura della massima quantità di dati che il sistema può perdere a causa di guasto improvviso;
m) Disaster Recovery (DR): in generale con tale termine si intende l’insieme di misure tecnologiche e organizzative atte a ripristinare sistemi, dati e infrastrutture necessarie all’erogazione di servizi di business a fronte di gravi emergenze. Nel presente capitolato si utilizzerà tale termine per far riferimento a quelle misure tecnologiche e organizzative o a quei sistemi atti a garantire l’integrità, la disponibilità e il ripristino dei dati in caso di incidenti o disastri. Si farà riferimento alla sua “eccezione più generale”, sopra richiamata e che pone enfasi sulla “continuità di servizio” con il termine “business continuity”;
n) Business Continuity (BC): in generale con tale termine si intende la capacità di un soggetto (Ente, Azienda, ecc) di continuare a erogare i propri servizi all’utenza anche a fronte di eventi più o meno gravi che possano colpirla. Nel presente capitolato si utilizzerà tale termine nella sua eccezione puramente “informatica” per far riferimento a quelle misure tecnologiche e organizzative o a quei sistemi atti a garantire non solo l’integrità, la disponibilità e il ripristino dei dati ma anche la continutià dei servizi a livello applicativo.
o) servizi IT essenziali: sono quei servizi IT (sia di back-office che di front-office) fondamentali per garantire l’operatività degli uffici e il rispetto di precisi adempimenti normativi e/o di legge sia a livello funzionale che applicativo. Pertanto il “downtime” (ossia il tempo di “interruzione”) per tali servizi deve sempre tendere a zero.
p) servizi IT strategici: sono quei servizi IT che, pur rivestendo un’ importanza “strategica” per l’Ente, non compromettono l’erogazione dei “servizi essenziali” . Pertanto, il “downtime” di tale tipologia di servizi:
a) dovrà tendere a zero in assenza di disastri o, comunque, di eventi critici di tipo ambientale tali da compromettere la sicurezza fisica della server-farm;
b) potrà essere anche superiore a zero, altrimenti.
ARTICOLO 3 - IMPORTO POSTO A BASE DI GARA – MODALITA’ DI PAGAMENTO
1. L’importo posto a base di gara per lo svolgimento di tutte le attività oggetto del presente appalto ammonta ad euro 140.000,00 (centoquarantamila/00) oltre IVA ai sensi di legge.
2. L’importo di cui sopra, al netto del ribasso offerto, sarà erogato con le seguenti modalità:
- il 35% dopo il collaudo con esito positivo dell’ultimo dei tre progetti realizzati.
- il 65% in quattro rate semestrali di pari importo di cui la prima rata al sesto mese dal collaudo con esito positivo dei tre progetti IT.
3. Il Comune di Spoleto si impegna a corrispondere gli importi dovuti entro 60 (trenta) giorni dalla data di ricevimento da parte del Comune di idonea fattura che potrà essere rilasciata a seguito dell’accertamento del Direttore dell’esecuzione della regolarità della prestazione effettuata.
4. Ai sensi dell’art. 4, comma 3 del DPR 207/2010, su ogni pagamento verrà operata una ritenuta dello 0,50%. Le ritenute saranno svincolate in sede di liquidazione finale, dopo l’approvazione del certificato di verifica di conformità di cui al successivo art. 10.
ARTICOLO 4 - AMBITO DI APPLICAZIONE
1. Tutte le attività descritte nel presente capitolato si applicano a tutti i sistemi componenti la server-farm; le attività di manutenzione e assistenza di cui all’art. 6 - fatto salvo dove diversamente ed esplicitamente specificato e/o regolamentato – non si applicano a:
a) “software contrattualizzati” di tipo applicativo;
b) dispositivi “hardware contrattualizzati”;
in quanto è onere dei soggetti che hanno in carico tale tipologia di hardware e/o software fornire adeguato supporto e/o assistenza all’Ente per la loro gestione e/o manutenzione. Tuttavia rimangono a carico della Ditta aggiudicataria tutte le attività, i progetti e i servizi inclusi nel presente appalto che riguardano:
a) la gestione dell’ambiente di virtualizzazione (es. Vmware\Vsphere);
b) la gestione dell’ambiente di pubblicazione delle applicazioni e/o delle banche dati in modalità centralizzata (es. Citrix);
c) la gestione dell’infrastruttura di storage e di backup\recovery dei dati;
d) la gestione degli apparati di rete (es. router, switch, ecc ) e/o di sicurezza (es. firewall);
anche qualora questi utilizzino o sia in esecuzione su “hardware contrattualizzato”. Questo implica, ad esempio, che la Ditta - se richiesto - dovrà procedere:
a) alla creazione di server virtuali;
b) alla pubblicazione di applicazioni o alla creazione di “server di pubblicazione” (es. server citrix);
c) alla creazione di lun o partizioni sugli storage;
d) alla definizione e/o applicazione di policy o configurazioni su router/switch/firewall;
anche qualora i nodi fisici o le risorse oggetto degli interventi suddetti siano afferenti ad “hardware contrattualizzato”;
2. è onere del concorrente effettuare in sede di sopralluogo il censimento dei sistemi ed acquisire la lista delle varie tipologie di hardware e software, come specificate all’ art. 2 precedente; tale lista potrà subire variazioni nel corso della durata contrattuale in caso di acquisizione di nuovo hardware e/o software da parte dell’Ente. Le eventuali nuove forniture saranno comunque inclusive almeno dei seguenti servizi:
a) installazione e configurazione del nuovo materiale acquistato dal Comune (qualora non effettuata direttamente dal personale dell’ufficio SITEL dell’Ente);
b) garanzia su tutto l’hardware per almeno 12 mesi dalla data del collaudo con esito positivo (tutti gli oneri per un eventuale rinnovo e/o proroga delle condizioni di garanzia saranno a carico dell’Ente);
3. le attività di cui al precedente comma 2 lettere a) e b) non saranno garantite qualora l’acquisizione avvenga in modo “indiretto” ossia in seguito al verificarsi delle seguenti casistiche:
a) sottoscrizione da parte dell’Ente di convenzioni Consip e/o DigitPA;
b) adesione da parte dell’Ente a progetti IT coordinati e/o finanziati da soggetti pubblici e/o privati in ambito regionale, statale o comunitario;
c) variazioni normative che impongono all’Ente l’utilizzo di specifico hardware e/o software fornito da società e/o Enti individuate dal legislatore;
d) concessione all’Ente di materiale hw-sw da parte di soggetti pubblici e/o privati in “comodato d’uso” gratuito o a titolo gratuito;
in tal caso per tali forniture varranno le condizioni degli accordi e/o convenzioni di riferimento;
4. In ogni caso la Ditta aggiudicataria dovrà garantire al fornitore del nuovo hardware e/o software il proprio supporto specialistico per il completamento delle attività sistemistiche necessarie all’ installazione e/o integrazione di quanto fornito nell’infrastruttura IT dell’Ente.
ARTICOLO 5 - OBBLIGHI DOCUMENTALI A NORMA ISO 20000:2005
1. La Ditta aggiudicataria dovrà garantire che la propria operatività avvenga in rispetto di quanto previsto dalla norma standard internazionale sulla Qualità dei Servizi IT ISO/IEC 20000-1:2005 (Gestione dei servizi IT). A tal fine verrà richiesto alla ditta aggiudicataria di dimostrare i processi, la gestione della documentazione e le modalità operative richieste dalla norma citata nei seguenti requisiti (ivi compresi i sub requisiti, ove presenti):
a) Plan service management,
b) Implement service management and provide the services,
c) Monitoring, measuring and reviewing,
d) Continual improvement (Act),
e) Planning and implementing new or changed services
f) Service level management,
g) Service reporting,
h) Service continuity and availability management,
i) Budgeting and accounting for IT services,
j) Capacity management,
k) Information security management,
l) Incident management,
m) Problem management,
n) Configuration management,
o) Change management,
p) Release process;
2. la Ditta aggiudicataria, per la dimostrazione del possesso del rispetto dei requisiti previsti dalla norma ISO 20000- 1:2005, ha due possibilità (mutuamente esclusive):
a) fornire in la documentazione di processo (es. se si dichiara di avere un sistema di help desk conforme alla norma si dovrà fornire un manuale operativo attestante ciò);
b) fornire copia del certificato del proprio Sistema di gestione di Servizi IT, secondo la norma ISO/IEC 20000- 1:2005, emesso da organismo di certificazione accreditato allo scopo;
3. in virtù di quanto specificato al comma precedente non è obbligatorio il possesso della certificazione ISO/IEC 20000- 1:2005 fermo restando il rispetto da parte della Ditta, nell’erogazione del servizio richiesto, delle procedure e dei requisiti in essa contenuti come di seguito specificato;
4. il rispetto dei requisiti sopra indicati comporterà l’onere per la Ditta, a livello operativo e gestionale, di fornire all’Ente, durante la durata contrattuale, a supporto e corredo di ogni attività di manutenzione e assistenza effettuata tutta la documentazione di help-desk (come previsto all’ art. 8) nonché quella prevista dalla norma ISO/IEC 20000-1:2005, ossia la “documentazione di sistema”, come di seguito sintetizzata:
a) Piano tecnico-operativo implementato dalla Ditta per l’attuazione delle policy di “business continuity/disaster recovery” definite dall’ Ente
b) Piano tecnico-operativo implementato dalla Ditta per l’attuazione delle policy di “backup dei dati e dei sistemi” definite dall’Ente
c) Report periodici sulle performance e la “capacity” dei sistemi
d) Report periodici sul livello di soddisfazione del cliente (ad es. mediante somministrazione di schede di valutazione o di questionari “on line”)
e) Report periodici sull’andamento dei servizi e sugli interventi effettuati
f) Piano tecnico-operativo implementato dalla Ditta per l’attuazione delle policy di “aggiornamenti dei sistemi” definite dall’Ente
g) Piano tecnico-operativo implementato dalla Ditta per l’attuazione delle policy di “sicurezza e di accesso/modifica dei sistemi” definite dall’Ente;
h) Mappatura/elenco degli asset dei sistemi (incluse le risorse virtuali) che dovrà essere effettuata con tool automatizzati specifici
i) Analisi dei rischi per ogni operazione di aggiornamento/upgrade/patch/fix dei sistemi
l) Configurazione (hw-sw) di uno o più sistemi IT sia di tipo fisico che virtuale
m) Configurazione (hw-sw) della rete informatica (e relativi collegamenti)
n) Test periodici di “penetration testing” sui sistemi IT e relativi report
o) Qualsiasi altra documentazione tecnica o reportistica utile in sede di audit ISO/IEC 20000-1:2005
5. quanto indicato nelle tredici lettere precedenti (da a) ad o) ) non si applicano:
a) ai “software contrattualizzati” di tipo applicativo;
b) ai dispositivi “hardware contrattualizzati”;
in quanto è onere dei soggetti che hanno in carico tale tipologia di hardware e/o software fornire la documentazione suddetta. In tal caso la Ditta aggiudicataria avrà il solo compito di produrre esclusivamente la documentazione tecnica inerente:
• le attività, i collegamenti e/o le configurazioni hw-sw realizzati a livello sistemistico dalla Ditta stessa per consentire l’installazione e il funzionamento nell’infrastruttura IT dell’Ente di tale software e/o dell’hardware contrattualizzato;
• le attività, i progetti e i servizi inerenti la gestione degli aspetti sistemistici di cui ai punti a),b),c),d) dell’ art. 4 comma1;
6. la documentazione suddetta dovrà essere concordata con il SITEL e mantenuta costantemente aggiornata dalla Ditta. L’Ente potrà effettuare una “richiesta di tipo documentale completo”:
• ogni qual volta si verifichino esigenze di tipo tecnico (es. per verificare eventuali problematiche riscontrate, per definire un piano di razionalizzazione od ottimizzazione delle risorse, per la definizione di nuovi progetti IT, per la realizzazione di allegati tecnici da allegare ai bandi di gara, ecc) certificate dal responsabile SITEL;
• al massimo 4 volte l’anno per soddisfare esigenze od obblighi di tipo documentale (es. per rispondere a quanto richiesto in sede di audit ISO 20000:2005).
7. Si precisa che:
a) una richiesta si definisce “di tipo documentale completo” qualora implichi, in una sola volta, la fornitura della documentazione indicata in almeno 6 dei 13 punti elencati al comma 4 precedente (punti da a) ad o) ) e “di tipo documentale parziale” altrimenti;
b) la documentazione di help-desk (art. 8) relativa a ciascun intervento effettuato dalla Ditta potrà essere richiesta in qualsiasi momento sia al fine di verificare la corretta esecuzione del servizio di help-desk, assistenza e manutenzione (nonché il rispetto degli SLA associati) sia per finalità di tipo statistico e/o di analisi;
c) la documentazione di cui al comma 4 precedente (punti da a) ad o)) dovrà essere redatta utilizzando, ove possibile, tool automatizzati di rilevazione, monitoraggio e di reportistica al fine da ridurre l’impegno di risorse umane e ottenere dei risultati quanto più possibile precisi e affidabili;
d) qualora venga effettuata dall’Ente una richiesta R di tipo la documentale su uno dei punti di cui al comma 4 precedente già oggetto di una precedente richiesta P, il tempo di evasione della nuova richiesta R dovrà essere necessariamente inferiore a quello impiegato per il soddisfacimento della richiesta P grazie al riutilizzo della documentazione già prodotta;
e) la documentazione di cui ai punti h),l),m) di cui al comma 4 deve essere verificata e aggiornata (se necessario) ogni qual volta si esegue un intervento di assistenza o manutenzione sui sistemi: la lista dei sistemi IT di cui al punto l) suddetto dovrà essere definita e concordata con l’ufficio SITEL e potrà essere modificata nel corso del tempo per esigenze tecniche o organizzative dell’Ente. Tale attività documentale costituisce parte integrante e sostanziale del servizio di assistenza e manutenzione (art. 8);
f) visto quanto specificato ai punti c), d), e) precedenti in nessun caso una richiesta di tipo documentale “completo” potrà essere verbalizzata (art. 8) dalla Ditta indicando come tempo di evasione un numero di giornate lavorative effettive superiore a 2;
g) A titolo indicativo si evidenzia che nel 2010 le richieste di tipo documentale di tipo “completo” sono state 4 mentre 6 di tipo documentale parziale e che tale quantitativo è stato mantenuto pressoché costante anche nel corso del 2011. Il completamento di tali richieste ha richiesto complessivamente 12 gg effettivi di attività. Il carico di lavoro indotto per l’evasione delle richieste di tipo documentale è legato alla complessità e al numero dei sistemi IT da gestire e, in quanto tale, è considerata direttamente proporzionale all’attività di assistenza e manutenzione effettuata di tipo “straordinario” come definita all’art. 6 comma 3 (ad esempio l’installazione di un nuovo sistema o un cambio di configurazione richiesto dall’ente comporta anche una modifica a livello documentale): pertanto, qualora il numero di richieste di tipo documentale non superi del 25% la stima suddetta, un eventuale “eccesso di onerosità” di attività documentale verrà considerato legittimo qualora venga riscontrato anche un “eccesso di onerosità” nell’espletamento dell’attività di assistenza e manutenzione come indicato all’art. 6 comma 3. Tuttavia in tal caso l’eventuale “eccessi di onerosità” dovuto all’attività documentale sarà compensato dal riconoscimento alla Ditta da parte dell’Ente del “bonus” di cui all’ art. 6 comma 3 (senza ulteriori maggiorazioni), in virtù della suddetta stretta correlazione tra l’attività documentale e quella di assistenza e manutenzione svolta.
h) la documentazione suddetta è esclusivamente, di tipo tecnico, reportistica e statistico: la Ditta, pertanto, non dovrà definire documentazione di tipo regolamentare o gestionale (es. policy, piani di gestione, ecc) che, in quanto tale, è a carico dell’Ente. I documenti tecnici o di tipo reportistico/statistico che la Ditta dovrà produrre dovranno quindi rispettare i seguenti vincoli:
- trattare quanto richiesto nel presente capitolato e descrivere, a livello tecnico, come sono state implementate le direttive per la gestione della server-farm definite dall’Ente (precedentemente citate a titolo indicativo e non esaustivo): policies, piani di gestione, di continuità dei servizi, ecc. Tuttavia, tali direttive, potranno essere concordate e condivise con la Ditta al fine e nell’ottica di definire le migliori strategie implementative. L’impossibilità oggettiva di implementare a livello tecnico quanto richiesto o quanto necessario (ad es. a livello normativo) dovrà essere opportunamente dimostrata, documentata e formalizzata dalla Ditta in quanto tale documentazione costituirà un’allegato fondamentale all’analisi dei rischi che l’Ente dovrà produrre come richiesto dal Dlgs 196/2003 (All. B).
- dimostrare con adeguati test (v. penetration testing) e reportistica periodici che le misure tecniche adottate al punto precedente e che i servizi di assistenza/manutenzione erogati rispettino gli SLA e i requisiti richiesti dall’Ente e/o definiti nel presente allegato tecnico;
- i modelli della documentazione tecnica da produrre dovranno essere condivisi dall’Ente e potranno essere modificati in corso d’opera (per esigenze tecniche, normative, organizzative);
i) la Ditta non dovrà produrre la documentazione necessaria per il mantenimento della certificazione ISO 20000:2005 dell’Ente (quindi in modo completo, autonomo e in forma organizzata) ma solo quella di supporto (ossia di tipo tecnico e statistico/reportistico) sopra descritta che potrà tuttavia essere inclusa dall’Ente (es. come allegato) in quella ufficiale da consegnare all’Ente certificatore per la dimostrazione dei requisiti di qualità definiti dalla norma.
ARTICOLO 6 - DESCRIZIONE DEL SERVIZIO DI MANUTENZIONE E ASSISTENZA
1. Il servizio di manutenzione e assistenza “chiavi in mano”, nonché di supporto al personale dell’ufficio SITEL (Servizi Informatici e Telefonici) dell’Ente per la gestione della server-farm del Comune di Spoleto, dovrà interessare tutti i sistemi IT componenti la server-farm stessa, come risultante dalla lista censita in sede di sopralluogo ed eventualmente successivamente modificata (art. 3). Il servizio potrà essere erogato da remoto o, se necessario per il ripristino della piena operatività dell’infrastruttura, in modalità “on site” (senza ulteriori oneri per l’Ente); costituiscono parte integrante e sostanziale del servizio di manutenzione e assistenza i servizi di tipo “documentale” (art. 5) e di help-desk (art. 8);
2. la durata e la decorrenza del servizio dovrà è specificata all’art. 1 comma 9; per il progetto DRBC vale quanto espresso all’art. 7.3 comma 13.
0.xx carico di lavoro richiesto dal servizio di assistenza e manutenzione potrà crescere nel corso del biennio a patto che le giornate di manutenzione e assistenza certificate (art 8 lettera f) nel corso dell’anno, non siano superiori del 25% rispetto a quelli “effettivi” effettuati sull’infrastruttura IT dell’Ente, nei primi 12 mesi di attività successivi al completamento di tutti i “progetti IT” (art. 7) specificati nel presente capitolato e al loro collaudo con esito positivo (tale condizione è fondamentale in quanto lo scopo di tali progetti è quello di ottenere una forte ottimizzazione dei sistemi e dell’infrastruttura IT dell’Ente e, conseguentemente, anche una sensibile riduzione dell’onerosità dei servizi (in particolare di quelli di assistenza e manutenzione nonché dell’attività di tipo documentale di cui all’art. 5) inclusi nel presente appalto. Nel calcolo non saranno considerate quelle giornate impiegate per l’evasione delle richieste che :
• riguardano problematiche che hanno comportato l’interruzione (anche minima) dei servizi essenziali e/o strategici della server-farm;
• riguardano guasti e/o malfunzionamenti di hardware e/o software fornito direttamente dalla Ditta nell’ambito del presente appalto o di altre forniture;
• sono riconducibili a bug e/o anomalie di hardware e/o software sistemistici riconosciuti e certificati dal produttore degli stessi;
• riguardano il completamento delle attività necessarie per l’ aggiornamento dei sistemi (comma 4 punto 4.2);
• sono state evase dalla Ditta senza rispettare i vincoli di help-desk di cui all’art. 8, comma 1, punti e) e f);
• sono relative a guasti e/o malfunzionamenti del sistema DRBC (art. 7.3) , in quanto si tratta di una fornitura inclusa nel presente capitolato ed è pertanto onere della Ditta stessa garantirne la piena efficienza ed operatività (art. 7.3 comma 9);
Inoltre nell’ ambito di una specifica richiesta non verranno conteggiati i tempi necessari per:
a) acquisire dall’utente o da altri soggetti le informazioni utili per la comprensione della problematica prima dell’effettivo intervento;
b) raggiungere la sede dell’intervento (se necessario un intervento “on site”) e quelli per il ritorno in sede;
c) l’eventuale trasporto e consegna presso la sede dell’intervento dei materiali utili per la risoluzione della problematica segnalata;
d) completare le attività necessarie per l’esecuzione del servizio di help-desk associato (art. 8);
e) ricevere riscontro dai produttori di software e/o hardware su specifiche richieste di assistenza (es. documentazione, codici di attivazione sw, ecc);;
f) ricevere riscontro da fornitori (anche dell’Ente) e/o partner tecnologici per l’acquisizione di informazioni utili alla risoluzione della problematica segnalata;
g) download di software utile per la risoluzione della problematica;
h) eventuali pause (es. per consumazione dei pasti) effettuate dai tecnici durante gli interventi on site durante l’orario di help-desk (art. 7);
in quanto le attività suddette rientrano in almeno una delle seguenti casistiche:
• attività automatizzate che non impegnano in modo costante e dedicato il tecnico (es. download di sw) di riferimento che può quindi dedicarsi ad altro in attesa del loro completamento;
• attività che implicano dei tempi di attesa (es. ricezione riscontri) non determinabili durante i quali il tecnico di riferimento può dedicarsi ad altro;
• attività di tipo logistico e/o di facchinaggio (trasporto materiali, trasferimenti, ecc) e non di tipo tecnico;
• attività propedeutiche (es. acquisizione informazioni, help-desk, ecc) per l’erogazione del servizio di assistenza e manutenzione vero e proprio;
In sostanza sarà riconosciuto alla ditta l’eccesso di onerosità della prestazione dovuto a richieste di tipo “straordinario” da parte dell’Ente, es. riconfigurazioni, personalizzazioni, nuove installazioni, ecc. o riguardanti problematiche relative a guasti e/o malfunzionamenti di hardware e/o software di terze parti non necessari per l’erogazione di servizi essenziali
e/o strategici (che, in quanto tali, dovrebbero essere oggetto di un’approfondita analisi nell’ambito dei progetti POS e ORSIT al fine da aumentarne il livello di affidabilità e di continuità operativa). La mancata valutazione delle giornate impiegate per la risoluzione di guasti e/o malfunzionamenti è dovuta al fatto che l’attuazione dei progetti POS e ORSIT, come definiti dalla Ditta, dovrebbe portare a un significativo aumento del livello di affidabilità dei sistemi (art. 7.2 comma
1) nonchè a un incremento del livello di continuità dei servizi IT riducendo al massimo la possibilità di eventuali guasti e/o malfunzionamenti: pertanto un eventuale incremento del numero di richieste relative a guasti e/o malfunzionamenti sarebbe in parte o in toto riconducibile a delle mancanze da parte della Ditta nell’attività di analisi alla base di suddetti progetti. Fermo restando tale vincolo qualora la soglia suddetta (25%) venga superata l’Ente dovrà corrispondere alla Ditta un canone annuo di assistenza e manutenzione maggiorato della medesima percentuale di incremento (“bonus”), ad esempio: se la Ditta, una volta completati i “progetti IT”, ha effettuato il primo anno 40 giornate di attività di assistenza e manutenzione (come definito in precedenza) mentre nel secondo anno ne ha effettuate 52 e quindi con un incremento percentuale del 30% rispetto all’anno precedente, l’Ente dovrà corrispondere alla Ditta per il secondo anno di assistenza e manutenzione un canone C(A) maggiorato del 30% rispetto a quello indicato in sede di offerta. Quindi in questo caso, supponendo che la Ditta abbia proposto un canone annuale C(A) per l’attività di assistenza e manutenzione pari a € 10000,00 l’Ente dovrebbe corrispondere alla Ditta un importo aggiuntivo (“bonus”) B pari a € 3000,00. L’importo B relativo a tale maggiorazione sarà corrisposto dall’Ente alla Ditta entro 60 gg dall’approvazione dell’esercizio di bilancio successivo. Ai fini del calcolo suddetto:
4. Il servizio richiesto dovrà essere erogato secondo le seguenti specifiche e linee guida nonché prevedere le attività sotto indicate:
4.1. soddisfare gli obblighi documentali di cui all’art. 5 precedente;
4.2 applicazione patch/fix e aggiornamenti (inclusi upgrade, gratuiti o a pagamento, a versioni successive dei prodotti) anche a livello di firmware di tutti i sistemi (server, dispositivi di rete, sistemi antivirus, ecc) oggetto del servizio che dovranno essere costantemente aggiornati e monitorati nel rispetto delle policy di aggiornamento sistemi come definite dall’Ente; nel caso degli upgrade forniti a pagamento dal fornitore/sviluppatore/produttore degli stessi saranno a carico dell’Ente tutti gli oneri (procedure e costi) per l’ acquisto; la Ditta dovrà effettuare una verifica periodica (almeno con cadenza semestrale) di tutti i sistemi e, una volta individuati le patch/fix e/o gli aggiornamenti da applicare, dovrà completare un’analisi delle possibili criticità che potrebbero verificarsi in seguito alla loro installazione. Il risultato di tale analisi dovrà essere sottoposto all’attenzione dell’ufficio SITEL che, dopo aver effettuato le proprie valutazioni, deciderà se concedere o meno l’autorizzazione a procedere. In caso di riscontro positivo da parte dell’ufficio SITEL la Ditta dovrà applicare e/o installare le patch/fix e/o gli aggiornamenti individuati; in ogni caso la Ditta dovrà provvedere a redarre apposito verbale sull’operazione di aggiornamento e la relativa attività di analisi propedeutica effettuata (art. 8 comma 1 punto f));
4.3. attività sistemistiche necessarie (es. creazione server virtuali) per l’ installazione/rimozione di software (di qualsiasi tipo) nonchè per la modifica della loro configurazione. Le specifiche delle attività sistemistiche da eseguire, nonchè dei sistemi (es. server) da implementare per l’ installazione/rimozione di software dovranno essere formalizzate e comunicate alla Ditta dall’Ente. Nel caso in cui l’Ente comunichi alla Ditta specifichi errate che comportino l’annullamento dell’intero lavoro appena eseguito gli oneri per l’esecuzione delle medesime attività secondo le nuove specifiche fornite saranno totalmente a carico dell’Ente (previa presentazione di preventivo e/o offerta presentata dalla Ditta). L’Ente si riserva comunque la possibilità di richiedere alla Ditta (senza ulteriori oneri):
a) attività di parametrizzazione o di tuning (es. ai fini dell’ottimizzazione) dei sistemi implementati (es. aumento delle risorse assegnate ai server virtuali, ecc) o ulteriori parametrizzazioni/configurazioni del software installato, al fine di risolvere problemi di performance e/o di sicurezza non preventivabili in fase di progettazione o comunque necessari per far fronte a nuove esigenze di tipo organizzativo (es. aumento degli utenti connessi o concorrenti);
b) la rimozione di sistemi o la disinstallazione di software nel caso in cui questo, nel corso del tempo, si renda necessario per esigenze tecniche (es. sostituzione di un software con un altro che offre migliori o diverse funzionalità con maggiore corrispondenza alle esigenze dell’Ente) od organizzative (es. definizione di nuovi accordi contrattuali con un un fornitore che impongono la rimozione o la sostituzione di una procedura informatica e/o di un software);
4.4. installazione/rimozione e configurazione (incluse operazioni di modifica) di hardware e software;
4.5. attività di backup/recovery dei dati e dei sistemi (incluse verifiche dei backup);
4.6. monitoraggio delle scadenze di tutte le licenze (hw-sw) in uso e relativa notifica al SITEL (art. 8 comma 1 punto d);
4.7 . installazione di nuove licenze software di vario tipo (sistemi operativi, software di tipo sistemistico, applicativo, gestionale, ecc) nel rispetto dei relativi contratti di fornitura e delle direttive del SITEL;
4.8. qualsiasi attività (esclusa la fornitura di hardware che comporti dei costi d’acquisto per la Ditta) dovesse rendersi necessaria per garantire la continuità dei servizi informatici e/o il ripristino della normale operatività (ad esempio in caso di rottura del proxy potrebbe essere necessario effettuare delle modifiche alla configurazione dei sistemi per garantire la connettività Internet);
4.9 . analisi e verifica delle cause di eventuali guasti/malfunzionamenti hardware e/o software inviando notifica al SITEL qualora questi siano di tipo “contrattualizzato” e quindi la risoluzione della problematica sia onere di un altro fornitore (es. guasto di un router HDSL la cui manutenzione è in carico al fornitore di connettività) in virtù di un contratto di assistenza e/o manutenzione sottoscritto dall’Ente; in questo caso gli SLA per la risoluzione dello stesso sono quelli definiti in tale contratto: restano a carico della Ditta gli oneri indicati al punto 4.16 successivo nonchè quello di verificare che gli SLA definiti con l’altro fornitore siano rispettati e, in caso contrario, segnalarlo al SITEL.
4.10. supporto al SITEL per la configurazione dei client (thin, pc fissi, portatili, dispositivi mobili, ecc) o delle periferiche (es. scanner, ecc) in dotazione all’Ente - al fine di renderne possibile il collegamento a Internet e/o alla server-farm - con realizzazione della relativa documentazione (ad esempio come configurare un nuovo modello di thin client e preparare la relativa immagine, come configurare in ambiente citrix uno scanner e renderlo utilizzabile dall’utenza, ecc);
4.11. implementazione e configurazione di ambienti di test (anche a scopo sperimentale) in server-farm che prevedono configurazioni hw-sw di qualsiasi genere;
4.12. esecuzione di qualsiasi modifica ai sistemi richiesta dal SITEL e necessaria per esigenze tecniche e/o organizzative dell’Ente (ad esempio per la definizione nel DPS di una nuova policy di sicurezza);
4.13. assistenza da remoto oppure “on site” (se necessario) per garantire la continuità dei servizi e la piena operatività della server-farm in caso di guasti/malfunzionamenti;
4.14. collegamento dei sistemi all’impianto elettrico (presa a muro) e a gruppi di continuità esterni;
4.15. la produzione di qualsiasi tipo di documentazione tecnica inerente la struttura e configurazione dei sistemi componenti la server farm (inclusi gli aspetti di “security”) nonchè il loro funzionamento;
4.16. qualsiasi attività connessa con la gestione dei rapporti con i fornitori dell’Ente (salvo diversa disposizione da parte del SITEL) per la risoluzione delle problematiche hardware e/o software riscontrate quali ad esempio: apertura dei ticket di assistenza nei confronti del fornitore, verifica dell’effettiva risoluzione della problematica, acquisizione delle informazioni inerenti l’origine della problematica e sulle attività eseguite per la sua risoluzione, ecc. Qualora la problematica riguardi il guasto e/o il malfunzionamento di apparati della server-farm coperti da garanzia ma difettosi e/o non funzionanti la Ditta dovrà farsi carico di tutti gli oneri necessari per il pieno ripristino dell’operatività degli stessi, quali ad esempio: contattare il produttore/fornitore dell’apparato; provvedere al ritiro, imballaggio e spedizione al fornitore/produttore del/gli apparato/I difettosi e non funzionanti, riconsegnare, reinstallare e riconfigurare l’apparato, ecc;
4.17. supporto al personale SITEL (mediante produzione di manuali e/o documentazione) per gestire autonomamente attività di tipo applicativo/sistemistico di qualsiasi tipo sulla server-farm utilizzando le tecnologie ivi installate, ad esempio in relazione alle seguenti tematiche (a titolo indicativo e non esaustivo):
a) creazione e configurazione di server virtuali mediante la piattaforma Vmware
b) creazione e configurazione di server Citrix
c) utilizzo della piattaforma Citrix Password Manager
d) gestione/Configurazione di Wndows Server 2003/Active Directory/Microsoft Exchange
e) definizione di policy nei sistemi che supportano tale funzionalità (Active Directory, proxy, firewall, ecc)
f) backup/recovery dei dati
g) gestione dei database
h) gestione della rete e della sicurezza
4.18. analisi di fattibilità e di compatibilità con l’infrastruttura attuale della server-farm di progetti tecnologici/informatici; resta inteso che rimane esclusa la fase di consulenza per la progettazione eccezion fatta per i progetti di cui all’ art. 7 che dovranno essere realizzati “in toto” dalla Ditta e da considerarsi parte integrante e sostanziale delle presente fornitura;
4.19. attività di modifica e/o riconfigurazione hw-sw dei sistemi IT, necessarie per soddisfare esigenze tecniche (es. ottimizzazione dell’infrastruttura IT, risoluzione problematiche, ecc) od organizzative dell’Ente, ad es: migrazione dati (es. dovute a sostituzione di software quali database), collegamento e/o riconfigurazione di nuovo hardware e/o software all’infrastruttura IT esistente, riconfigurazione dei sistemi IT per supportare eventuali nuovi assetti organizzativi dell’Ente, ecc.
4.20. attività necessarie per la manutenzione delle attrezzature della server-farm (inclusi gruppi di continuità e sistema di climatizzazione) per la verifica della piena e corretta operatività dei sistemi. La Ditta dovrà quindi allegare all’offerta tecnica un piano di manutenzione per tutta la durata del servizio di manutenzione e assistenza, che sarà oggetto di apposita valutazione e che dovrà soddisfare le seguenti specifiche minime:
a) prevedere almeno n.1 intervento l’anno di manutenzione preventiva all’impianto elettrico (incluse linee preferenziali) e ai gruppi di continuità (efficienza batterie, ecc) della server-farm;
b) prevedere almeno n.1 intervento l’anno di manutenzione preventiva all’impianto di condizionamento (inclusi condizionatori e relativi estrattori d’aria) della server-farm;
c) prevedere almeno n.1 intervento l’anno di manutenzione preventiva su tutte le attrezzature della server-
farm (pulizia apparati, test di funzionalità, ecc); Le attività di cui ai punti precedenti:
a) dovranno essere effettuate in modo tale da rispettare le condizioni di garanzia e assistenza sottoscritte dall’Ente con i produttori degli apparati e tenendo conto delle direttive imposte da quest’ultimi;
b) dovranno essere effettuate tendo conto di quanto specificato all’art. 7.2 comma 5 punto b);
Rimangono a carico dell’Ente esclusivamente gli oneri per l’acquisto del materiale di consumo necessario per il funzionamento dei dispositivi oggetto dell’attività di manutenzione mentre sono a carico della Ditta:
a) la fornitura di tutte le “parti di ricambio” qualora il produttore dello specifico dispositivo oggetto di manutenzione non le classifichi esplicitamente (es. sul manuale, sul proprio sito web, ecc) come “materiale di consumo”; qualora tale classificazione non sia evidente tali parti di ricambio non verranno considerate materiale di consumo;
b) tutti gli oneri per l’installazione sia delle parti di ricambio sia del materiale di consumo, nonché quelli per lo smaltimento a norma di legge di tutto il materiale sostituito e non più utilizzabile;
c) per gli UPS la fornitura e la sostituzione delle batterie con altre nuove originali se quelle attualmente installate hanno superato il ciclo di vita “consigliato” dal produttore (qualora quest’ultimo non specifichi per le batterie una “durata massima” di utilizzo si prenderà come riferimento per determinare tale valore il termine di 36 mesi dalla loro installazione) mentre per i condizionatori la sostituzione del gas\liquido refrigerante.
4.21. attività sistemistiche (es. creazione server virtuali, ecc) e di installazione/configurazione hardware-software necessarie per l’implementazione di progetti informatici/tecnologici o di nuove funzionalità (es. sistemi di monitoraggio dei sistemi, per l’accesso alla risorse IT; piattaforme di “cloud computing”, sistemi per il supporto di dispositivi client di tipo “mobile”, ecc);
4.22.attività di monitoraggio costante dei “servizi IT essenziali” effettuata con tool o sistemi automatizzati che prevedono funzionalità di notifica (es. via e-mail, SMS, ecc) in tempo reale;
4.23.qualsiasi attività applicativa e/o sistemistica che comporti, da parte della Ditta, la realizzazione di programmi o script particolari da installare nell’infrastruttura IT dell’Ente la Ditta dovrà:
a) provvedere a fornire al SITEL i relativi sorgenti e tutta la documentazione e/o manualistica di supporto necessaria per la loro comprensione e/o modifica e/o personalizzazione; la produzione di tale documentazione è da considerarsi parte integrante dell’attività di programmazione software di tipo “sistemistico” e, in quanto tale, non è da considerarsi “documentazione di sistema” (art. 5);
b) conservare una copia del materiale di cui al punto precedente in uno spazio disco (“repository”) remoto fornito dalla Ditta e accedibile dal personale SITEL dell’Ente da Internet tramite interfaccia Web;
4.24. l’aggiornamento della documentazione sugli asset e la configurazione della rete e dei sistemi di cui all’art. 5 comma 7 punto e) che dovrà essere effettuato e verbalizzato dopo ogni intervento di assistenza e/o manutenzione qualora questo comporti modifiche ai suddetti aspetti strutturali (art. 5 comma 7 punto e), art. 8 comma 1 punto f));
4.25 qualsiasi altra attività (sistemistica o applicativa) utile per la gestione della server-farm che non rientri nelle seguenti categorie:
a) installazione e/o configurazione “on site” di client;
b) intervento su qualsiasi impianto elettrico e di condizionamento della server-farm fatta eccezione quanto specificato al punto 4.20 precedente (manutenzione preventiva);
c) montaggio, smontaggio, imballaggio e/o trasporto di dispositivi non componenti i sistemi della server-farm (ad. es. pc client o dispositivi di storage collocati in una specifica sede con uso esclusivo da parte degli uffici di tale sede)
d) intervento su sistemi hw-sw non collocati presso la server-farm ma in altre sedi operative dell’Ente e quindi ad uso esclusivo dei relativi uffici (in quanto tale attività val al di là del campo di applicazione di tale fornitura che interessa esclusivamente la sede della server-farm del Comune di Spoleto)
5. A titolo indicativo si evidenzia che nel 2010 le richieste di assistenza sono state non superiori a 40 gg effettivi (al netto delle tempistiche ed esclusioni di cui al comma 3 precedente e del tempo necessario per l’evasione delle richieste di tipo documentale di cui all’art. 5 precedente) e che tale quantitativo è stato mantenuto in proporzione anche nel corso del 2011.
ARTICOLO 7 - PROGETTI “IT” DA REALIZZARE
1. La Ditta, nell’ambito del presente appalto dovrà realizzare i tre progetti di ottimizzazione dell’infrastruttura IT dell’Ente di seguito specificati, utilizzando le informazioni acquisite in sede di sopralluogo di cui al precedente art. 1 e facendosi carico di tutti i relativi oneri tra cui, a titolo indicativo e non esaustivo:
• costi di acquisto di hardware, di software o di servizi;
• fornitura, trasporto, installazione, collegamento e configurazione di hardware e/o software;
• attività di analisi, di progettazione e di implementazione di sistemi;
• attività di conversione e/o migrazione dati;
• attività di riconfigurazione dei sistemi in seguito alla sostituzione di hardware e/o software esistente,
• esecuzione di test;
2. i tre progetti IT da realizzare sono:
a) “Porting” dell’infrastruttura IT su soluzioni software “Open Source” (POS)
b) Ottimizzazione e Razionalizzazione dei Sistemi IT (ORSIT)
c) Soluzione di Disaster Recovery e/o Business Continuity (DRBC);
Tali progetti dovranno essere realizzati garantendo la continuità dei servizi dell’infrastruttura IT dell’Ente attualmente erogati e, ove tecnicamente possibile, far uso di soluzioni e prodotti open source.
3. Tutto l’hardware fornito nell’ambito di tali progetti dovrà essere “logisticamente compatibile” con le strutture di contenimento (armadi a rack, piani fissi o mobili di sostegno, ecc) degli apparati presenti in server-farm (es. server eventualmente da fornire di dimensioni adatte ai rack ivi installati). Qualora tali strutture di contenimento non siano sufficienti a contenere i nuovi apparati sarà onere della Ditta estenderle o integrarle in modo opportuno compatibilmente con gli spazi a disposizione nella server-farm. Le nuove strutture di contenimento (es. armadi a rack) eventualmente fornite dovranno essere quanto più possibile conformi (nella dimensioni e nell’aspetto) a quelle già presenti nella server- farm e sarà onere della Ditta procedere al loro posizionamento e alla loro corretta installazione. Le nuove “strutture di contenimento” degli apparati andranno a costituire parte integrante e sostanziale dell’hardware di base e, pertanto, anche per esse si applicano le condizioni di fornitura cui all’art. 7.2 comma 3.
4. A tutto il materiale hw /o software fornito nell’ambito dei progetti di cui al comma 2 e come di seguito definiti (art. 7.1, 7.2, 7.3) si applicano in toto le condizioni e i servizi di cui agli art. 6 (servizio di manutenzione e assistenza) e all’art. 8 (servizio di help-desk), fatto salvo se diversamente specificato;
5. La fornitura di documentazione (almeno manuale utente ed amministratore) in formato elettronico per l’utilizzo di tutti i software open source e/o proprietari (inclusi quelli di tipo sistemistico-applicativo e necessari per la gestione di hardware di base della server-farm) forniti nell’ambito dei progetti di cui comma 2 e come di seguito definiti (art. 7.1, 7.2, 7.3) sarà valutata positivamente in sede di offerta tecnica; la documentazione dovrà essere “personalizzata”, ossia far riferimento all’infrastruttura IT del Comune di Spoleto e alle relative configurazioni. L’attività di “personalizzazione” dovrà essere “perfezionata” e/o completata dopo l’implementazione dei progetti suddetti al fine di tener conto delle configurazioni e della struttura dell’infrastruttura IT dopo la fase di ottimizzazione;
6. la Ditta dovrà provvedere ad effettuare opportuna attività di formazione on site al personale SITEL sull’utilizzo di tutti i software open source e/o proprietari forniti nell’ambito dei progetti di cui comma 2 e come di seguito definiti (art. 7.1, 7.2, 7.3). La formazione dovrà avere la durata di almeno 5 gg per ciascun progetto. Eventuali giornate aggiuntive, con i relativi contenuti, dovranno essere specificate nel piano di formazione e saranno valutate positivamente in sede di valutazione dell’offerta tecnica;
7.1. PROGETTO POS
1. La finalità del progetto è quella di:
• ridurre quanto più possibile, a livello sistemistico e applicativo, l’utilizzo di software proprietari e/o soggetti al pagamento di licenze d’uso o di proprietà con lo scopo di ottenere una forte riduzione dei costi di gestione del parco software in carico all’Ente;
• rispettare le direttive imposte dal nuovo CAD - Codice dell’Amministrazione Digitale (Dlgs 235/2010) in materia di utilizzo di soluzioni software basate su codice “open source”;
2. la Ditta, pertanto, dovrà definire e implementare un “piano di porting” (PP), ossia di migrazione dell’infrastruttura software dell’Ente su soluzioni “open source” che tenga conto dei seguenti aspetti e vincoli:
a) le soluzioni software proposte dovranno essere di tipo “open source” e almeno “funzionalmente equivalenti” a quelle attualmente utilizzate dall’Ente: la Ditta dovrà farsi carico della fornitura di tutto il software “open source” proposto e della sua corretta installazione e/o configurazione;
b) qualora il PP comporti degli interventi a livello client (es. installazione\disinstallazione di software in locale) la Ditta dovrà occuparsi anche del completamento di tali attività;
c) il PP potrà riguardare anche il “software di base” della server-farm: in tal caso la Ditta dovrà garantire che l’erogazione di tutti i servizi e delle funzionalità essenziali della server-farm (correlati al software di base oggetto di porting) venga preservata e garantita senza alcun tipo di interruzione;
d) qualora l’attività di porting riguardi “software di base” essenziale per il funzionamento di altri “software contrattualizzati”, l’operatività di quest’ultimi dovrà essere preservata e garantita: pertanto saranno a carico della Ditta tutti gli oneri conseguenti (es. riconfigurazione e/o reinstallazione software contrattualizzati, modifiche alla configurazione di rete, migrazione dati, ecc).
3. è discrezionalità della Ditta decidere se sottoscrivere o meno con lo sviluppatore e/o il produttore del software open source fornito dei servizi di supporto specialistico necessari per il soddisfacimento delle condizioni di cui all’ art. 6 (servizio di manutenzione e assistenza) e all’art. 8 (servizio di help-desk) senza alcun onere aggiuntivo per l’Ente. Tali servizi saranno valutati positivamente in sede di offerta tecnica ma anche considerati come “costi di gestione” del software open source come indicato all’art. 14.3 del bando;
4. il PP dovrà essere allegato all’offerta tecnica e contenere almeno le seguenti informazioni per ogni software oggetto della fase di “porting”:
a) caratteristiche, funzionalità e vantaggi della soluzione open source proposta rispetto al software proprietario oggetto di porting;
b) attività tecniche necessarie (es. conversione dati, interventi a livello client, ecc) per il completamento del porting e relativo crono programma (evidenziandone la durata);
c) il piano di formazione proposto (art. 7 comma 6).
d) eventuali criticità connesse con l’attività di porting.
7.2. PROGETTO ORSIT
1. La finalità del progetto è quella di definire e implementare un “piano di ottimizzazione e di razionalizzazione” (POR) dei sistemi IT della server-farm al fine di raggiungere i seguenti obiettivi:
a) riduzione dei costi di gestione dei sistemi (comma 2 successivo);
b) riduzione dei consumi e del livello di utilizzo delle risorse hw (es. spazio disco, cpu, ram, spazio fisico, ecc);
c) incremento del livello di affidabilità (fault tolerance) dei sistemi;
d) incremento del livello di performance dei sistemi;
e) incremento del livello di sicurezza dei sistemi;
f) incremento del livello di espandibilità e/o scalabilità dei sistemi;
g) incremento del livello di integrazione dei sistemi;
in particolare nei seguenti ambiti infrastrutturali e/o tecnologici, sia a livello hardware che software:
• virtualizzazione delle risorse
• pubblicazione in modalità centralizzata delle applicazioni e/o dei dati (banche dati testuali, audio-video e\o multimediali, ecc)
• salvataggio (database) e backup\recovery dei dati
• networking e connettività Internet\Intranet
• server e storage
Pertanto le soluzioni hw e/o sw definite nel POR potranno prevedere la sostituzione di sistemi hw-sw esistenti (es. con altri più efficienti e/o performanti) o l’installazione di nuovi (in grado di garantire nuove funzionalità) nel rispetto dei vincoli e delle condizioni di cui al presente capitolato;
2. Il POR dovrà essere definito dalla Ditta in modo tale da rispettare le seguenti condizioni:
a) uniformare, per quanto possibile, la tipologia delle risorse hardware (es. apparati del medesimo produttore, ecc) e software (es. “unificare” il sistema di backup e antivirus per i vari sottosistemi, ecc) utilizzate;
b) preferire, per quanto possibile, l’utilizzo di soluzioni hw e/o sw di tipo “open source” nel rispetto dei medesimi vincoli posti alla base del progetto POS (fermo restando quanto previsto al comma 4 successivo per quanto riguarda l’utilizzo di software proprietario);
c) ridurre il costo annuale medio C di gestione dell’infrastruttura IT del Comune di Spoleto (rispetto ai 24 mesi di esercizio precedenti la data di cui all’art. 1 comma 9, ossia la prima data utile per l’erogazione dei servizi di cui al presente appalto), senza ridurre il numero e/o la qualità dei servizi IT attualmente erogati. Il “costo di gestione dell’infrastruttura IT” ( C ) è così definito:
C = L + G + S,
dove: L =costo totale delle licenze relative al “software di base” possedute dall’Ente (inclusive del servizio di subscription offerto dal produttore, come definito al comma 3 successivo e di eventuali servizi di supporto specialistico per i software open source (art. 7.1 comma 3));
G = costo totale di garanzia e assistenza on site sull’ “hardware di base” posseduto dall’Ente (come definito al comma 3 successivo);
S = costi totale per il servizio di help-desk, assistenza e manutenzione nonchè di supporto alla gestione della server-farm da parte di società esterne;
Pertanto la Ditta dovrà ottenere un costo annuale di gestione: C ‘ < C. Il valore di C e il relativo dettaglio potrà essere acquisito dalla Ditta in sede di sopralluogo. Pertanto la percentuale R di riduzione dei costi di gestione sarà pari a: R = [100 * (C – C’)]\C.
Qualora nel periodo di esercizio suddetto l’Ente abbia proceduto all’acquisto di licenze software “ex novo” e il POR previsto dalla Ditta preveda il loro mantenimento, ai fini del calcolo di R il valore di C sarà ridimensionato (ridotto) in modo tale prevedendo per tali licenze il costo di rinnovo inclusivo del servizio di “subscription” (art. 7.2 comma 3) con il medesimo prezzo offerto dalla Ditta in sede di “offerta economica” nell’ambito della presente appalto. Tale ridimensionamento è necessario in quanto il “costo di gestione” di che sarà sostenuto dall’Ente per il mantenimento in futuro di tale tipologia di licenze sarà quello di rinnovo e non di acquisto.
La Ditta dovrà farsi carico di tutti gli oneri connessi con la realizzazione del POR proposto, ossia della fornitura di tutto il materiale hw-sw nonché dei servizi (installazione, configurazione, ecc) necessari per la realizzazione del POR;
3. nel POR la Ditta dovrà anche includere, senza oneri aggiuntivi per l’Ente:
• la fornitura (rinnovo o acquisto) di tutte le licenze relative al “software di base”. Tali licenze dovranno essere inclusive del servizio di subscription (assistenza e supporto specialistico) con il relativo produttore;
• la fornitura (rinnovo o acquisto), con i rispettivi produttori, del servizio di garanzia e assistenza on site su tutto “ l’hardware di base”;
Si precisa che:
a) la lista del “software di base” e dell’ “hardware di base” è quella acquisita in sede di sopralluogo, come eventualmente modificata dall’implementazione del PP (art. 7.1) e del POR;
b) gli SLA associati al servizio di subscription delle licenze (software di base) e a quelli di garanzia e assistenza (hardware di base) dovranno essere “compatibili” con quelli associati al servizio di help-desk (art. 8) ossia tali da consentire alla Ditta la risoluzione delle richieste di assistenza entro i termini specificati all’art. 8 anche qualora sia necessario il supporto da parte di uno o più produttori di tecnologie e/o di hw-sw;
c) la durata delle licenze (e del relativo servizio di subscription) relative al “software di base” dovrà essere pari a 24 mesi dalla data effettiva data di inizio di implementazione del POR. La Ditta potrà quindi procedere - per un particolare ambito sistemistico e/o applicativo - all’acquisto “ex novo” di licenze o potrà adeguare alla condizione sopra specificata i contratti eventualmente già sottoscritti dall’Ente per le licenze esistenti con i rispettivi produttori. Infatti il POR proposto dalla Ditta potrebbe prevedere, per un particolare ambito sistemistico e/o applicativo, il mantenimento del software di base esistente oppure, in sua sostituzione, altro equivalente o migliorativo nel rispetto delle condizioni espresse nel presente capitolato);
d) la durata del servizio di garanzia e assistenza on site su tutto “ l’hardware di base” dovrà essere pari a
24 mesi, dalla data effettiva di inizio di implementazione del POR. La Ditta potrà quindi procedere all’acquisto “ex novo” di “hardware di base” (inclusivo del servizio di garanzia e assistenza on site del produttore) equivalente o migliorativo rispetto a quello esistente o potrà adeguare alla condizione sopra specificata i contratti di garanzia e assistenza on site eventualmente già sottoscritti dall’Ente con i rispettivi produttori dell’hardware di base già installato;
e) la Ditta dovrà monitorare costantemente la scadenze di cui ai punti c) e d) precedenti secondo quanto specificato all’art 6 comma 4.6.
f) dovranno essere allineate quanto più possibile le date di scadenza delle licenze (software di base) nonché quella dei servizi di garanzia e assistenza (hardware di base) di cui ai punti precedenti al fine da rendere più agevole le procedure di monitoraggio e di rinnovo delle stesse
g) la data di scadenza di tutte le licenze relative a software di base e afferenti al medesimo produttore (es. Citrix, Vmware, ecc) dovrà essere necessariamente unica;
h) la data di scadenza dei servizi di garanzia e assistenza on site sull’ “hardware di base” afferente al medesimo produttore (es. Sun, HP, ecc) dovrà essere necessariamente unica;
4. il POR potrà prevedere l’utilizzo di nuovo software di tipo “proprietario” qualora, per ragioni tecniche, non sia possibile utilizzare soluzioni “open source”. In tal caso il software proposto dovrà avere funzionalità equivalenti (o superiori) e costi di gestione (es. di licenza) pari o inferiori rispetto ai software attualmente utilizzato e oggetto della fase di porting;
5. il POR dovrà prevedere anche:
a) la verifica della conformità di tutte le licenze acquistate dall’Ente per il software di base rispetto a:
• i contratti di licensing sottoscritti dall’Ente;
• il software di base e all’hardware di base presente nell’infrastruttura IT;
• le risorse virtuali definite e utilizzate;
La Ditta dovrà quindi provvedere al loro eventuale adeguamento (acquisto e/o rinnovo di licenze), senza ulteriori oneri per l’Ente e tenendo conto degli interventi che saranno inclusi nel POR stesso; pertanto è onere della Ditta verificare e accertare che tutte le condizioni di licenza e/o contrattuali associate ai prodotti hardware e software “di base” utilizzati (o che verranno utilizzati nell’ambito del POR) siano rispettate e, in caso affermativo, provvedere alla loro regolarizzazione (tenendo conto in particolare di quanto indicato al comma 3 precedente) senza ulteriori oneri per l’Ente.
b) la verifica dell’impianto di continuità elettrico della server-farm (UPS) e del sistema di condizionamento è da considerarsi parte integrante dell’hardware di base per cui la Ditta dovrà fornire i relativi servizi di garanzia e assistenza, come specificato al comma 3 precedente;
c) la predisposizione di un ambiente hw-sw di test (che sarà oggetto di valutazione in sede di valutazione dell’offerta tecnica) per l’infrastruttura IT quanto più possibile equivalente (sia a livello di struttura che di configurazione anche se, ovviamente, potrà essere dimensionalmente più ridotto) a quello di produzione al fine di consentire alla Ditta o al SITEL di effettuare qualsiasi genere di test senza rischiare di creare disservizi all’utenza o di compromettere l’operatività della server-farm nonché l’integrità dei dati ivi conservati. Tale ambiente di test sarà utilizzato, ad esempio, per testare nuovi applicativi prima della loro effettiva installazione o per effettuare analisi di compatibilità di nuovi sistemi IT con l’infrastruttura IT dell’Ente prima della loro messa in esercizio;
6. il POR potrà prevedere anche interventi migliorativi a livello di connettività ossia finalizzati al potenziamento della banda della connettività Intranet o Internet per la trasmissione dati da e verso la server-farm (per il raggiungimento dell’obiettivo di cui al comma 1 punto d) per quanto riguarda la connettività Intranet\Internet): in tal caso tutti gli oneri di acquisto, di installazione e di configurazione degli apparati di rete (inclusa quella per l’integrazione con la rete comunale) nonché tutti quelli di attivazione e di traffico dati Internet (inclusivi del servizio di assistenza e manutenzione offerto dal relativo provider) saranno a totale carico della Ditta per l’intera durata del servizio di manutenzione e assistenza di cui all’art. 6 comma 2; Tali costi non dovranno essere superiori al prezzo più basso offerto dai listini DigitPA e Consip per la medesima tipologia di connettività Internet. Qualora l’offerta Consip o DigitPA non preveda a listino una connettività Internet con specifiche identiche verrà preso come riferimento il prezzo della connettività avente specifiche tecniche quanto più simili, seppur di livello inferiore, rispetto a quella offerta dalla Ditta in sede offerta economica nell’ambito del presente appalto. Per i collegamenti Intranet (ossia “sede periferica – server farm”) saranno accettate esclusivamente soluzioni a larga banda ossia fibra ottica e/o wireless punto-punto con banda statisticamente garantita pari o superiore a 20 Mbit/s e che non prevedano costi di traffico dati. Rientrano tra gli oneri della ditta anche i seguenti:
• l’esecuzione di tutti i lavori (es. eventuali scavi) necessari;
• le procedure tecnico-amministrative per il collegamento alla rete elettrica e il pagamento delle relative utenze sino a collaudo avvenuto dell’infrastruttura e, successivamente, durante il periodo di voltura delle stesse (il periodo impiegato dal gestore per il completamento della voltura non verrà consideratoai fini della determinazione del tempo di completamento del POR);
E’ invece onere dell’ Ente farsi carico di tutte le procedure necessarie per la richiesta di eventuali autorizzazioni agli organi e/o ai soggetti competenti (pubblici e/o privati) per l’installazione degli apparati (es. antenne, ecc) e/o la realizzazione dei lavori (es. eventuali scavi). Tuttavia la Ditta dovrà redarre e fornire all’Ente tutta la documentazione tecnica (es. schemi, specifiche prodotti, collegamenti, ecc) necessaria da allegare alla richiesta. Al termine del servizio di assistenza e manutenzione (art. 6 comma 2) quanto fornito nell’ambito del presente comma (connettività, apparati, ecc) per il potenziamento della banda della connettività Intranet\Internet per la trasmissione dati da e verso la server-farm rimarrà di proprietà dell’Ente con i medesimi canoni di connettività (Internet) e senza ulteriori oneri;
7. per tutto il software oggetto di fornitura (sia di tipo “open source” che proprietario, fermo restando quanto indicato al comma 4 precedente) da parte della Ditta nell’ambito del progetto ORSIT valgono le condizioni e i vincoli di cui all’art. 7.1 commi 2 e 3;
Pertanto il POR potrà essere definito in modo tale da prevedere una serie di linee di intervento – nel rispetto di quanto sopra definito – quali ad esempio (a titolo indicativo e non esaustivo):
a) fornitura di nuovo hardware di base in sostituzione o in aggiunta a quello attualmente installato con il relativo servizio di garanzia e assistenza on site (come precedentemente definito), al fine di garantire il raggiungimento degli obiettivi di cui al comma 1 precedente;
b) sostituzione del software di base con altro equivalente (o con maggiori funzionalità) e con pari o minori costi di gestione e/o di licenza;
c) riconfigurazione del software e dell’hardware di base esistente al fine di garantire il raggiungimento degli obiettivi di cui al comma 1 precedente;
d) potenziamento della connettività Intranet\Internet o dei servizi di sicurezza a livello di networking (es. filtri antivirus, antispam, ecc) della server-farm;
8. Il POR dovrà essere allegato all’offerta tecnica ed essere così strutturato:
8.1) contenere almeno le seguenti informazioni per ogni “area di intervento” (intesa come servizio, es. posta elettronica, connettività Internet\Intranet, ecc oppure come ambito sistemistico-applicativo di tipo hw e/o sw, es: infrastruttura di storage e/o di backup, infrastruttura virtuale, migrazione sistema operativo lato server, ecc):
a) criticità\problematica riscontrata;
b) soluzione proposta per la criticità\problematica suddetta e risultati attesi;
c) dettaglio della fornitura hw-sw o dei servizi (inclusi quelli di cui al comma 6 precedente) associati alla soluzione proposta;
d) attività tecniche necessarie (es. conversione dati, interventi a livello client, ecc) per l’implementazione della soluzione suddetta e relativo cronoprogramma;
e) eventuali criticità connesse con l’implementazione della soluzione suddetta;
f) evidenziare le soluzioni individuate per il raggiungimento di ciascuno degli obiettivi di cui al
comma 1 precedente.
9. La Ditta dovrà farsi carico, nell’ambito del servizio di manutenzione e assistenza di cui all’art. 6, anche dei seguenti aspetti:
a) installazione, configurazione e test;
b) risoluzione di eventuali anomalie/malfunzionamenti;
c) esecuzione di verifiche di compatibilità (con altri software o progetti di interesse per l’Ente);
d) esecuzione di qualsiasi attività tecnico-sistemistico e applicativa necessaria per il rispetto dei vincoli di cui al comma 2 precedente;
relativamente al software (“open source” o “proprietario”) e/o all’hardware fornito (fornendo anche un supporto di tipo specialistico, se necessario) e necessario per l’implementazione del POR;
7.3. PROGETTO DRBC
0.Xx finalità del progetto è quella di implementare un sistema di Disaster Recovery e/o Business Continuity (DRBC) per l’infrastruttura IT del Comune di Spoleto, come richiesto in materia dal nuovo CAD - Codice dell’Amministrazione Digitale (Dlgs 235/2010);
2. Il sistema DRBC dovrà essere implementato utilizzando uno (o più) siti remoti di replica dei dati (data center) posti ad almeno 100 Km di distanza dalla server-farm dell’Ente, a cui il personale SITEL e gli auditor di certificazione ISO 20000:2005 potranno avere accesso in qualsiasi momento. Per brevità e semplicità, di seguito, si utilizzeranno i termini “sito di replica dei dati” o “data center” esclusivamente nella loro versione singolare fermo restando che le condizioni espresse nel presente capitolato si applicano anche a quelle soluzioni di DRBC che utilizzano più siti di replica dei dati (data center). Eventuali servizi di data center aggiuntivi rispetto a quelli obbligatori previsti nel presente capitolato saranno valutati positivamente in sede di valutazione dell’offerta tecnica. Qualora la Ditta offra un servizio di “remote vaulting” (copia) su nastro questo dovrà rispettare le seguenti specifiche minime:
a) copia dei dati (almeno file utenti, posta elettronica e database) su nastro con cadenza giornaliera;
b) conservazione dei nastri su cassaforte ignifuga e specifica per la conservazione di supporti informatici;
c) la tipologia dei nastri utilizzati e il formato utilizzato per la scrittura dei dati dovranno essere compatibili con la libreria robotica e i software di backup attualmente installati presso la server-farm del Comune di Spoleto;
d) policy e modalità di backup dei dati su nastro (incrementale, differenziale, ecc) da concordare con l’Ente;
3. Il sistema dovrà essere sviluppato secondo i principi di modularità e scalabilità, affinchè sia possibile implementare agevolmente sei livelli di funzionalità. Le funzionalità “minime” di ogni livello sono di seguito indicate (ogni livello garantisce funzionalità superiori rispetto al livello precedente). Eventuali implementazioni del sistema DRBC aventi specifiche tecnico-funzionali migliorative rispetto a quelle minime previste dal livello funzionale di riferimento, saranno valutate positivamente in sede di valutazione dell’offerta tecnica. La Ditta dovrà farsi carico di tutti gli oneri necessari per l’implementazione del sistema DRBC oggetto della fornitura inclusi quelli che riguardano eventuali adeguamenti dell’infrastruttura IT del Comune di Spoleto al fine di garantire le specifiche tecniche, le funzionalità e le performance del sistema DRBC stesso (ad. esempio potrebbe essere necessario il potenziamento della connettività Intranet\Internet al fine di garantire un determinato valore di RPO: in tal caso vale quanto specificato all’art 7.2 comma 6)
a) LIVELLO 0 : Disaster Recovery - entry level (è il livello minimo implementabile)
b) LIVELLO 1 : Disaster Recovery – advanced level (virtual level backup)
c) LIVELLO 2 : Disaster Recovery – enterprise level (database direct access)
d) LIVELLO 3: Business Continuity – entry level
e) LIVELLO 4: Business Continuity – advanced level (virtual level compatibility)
f) LIVELLO 5: Business Continuity – top level (virtual level continuity)
g) LIVELLO 6: Business Continuity – enterprise level (total continuity)
LIVELLO 0: Disaster Recovery - entry level:
a) replica sul data center della seguente tipologia di dati: file system (inclusi file utenti e condivisioni), database (dump), posta elettronica;
b) RTO:<= 8 h
c) RPO: <= 24 h
d) periodicità di replica: giornaliera;
(nota: i LIVELLI 0, 1, 2 di DS implementano esclusivamente un servizio di replica dei dati su un data center: pertanto per essi l’RTO (DC) (successivamente “RTO”) è da intendersi come il tempo massimo per rendere accessibili e disponibili i dati sul data center stesso. Nei LIVELLI 3,4,5 di BC l’RTO è invece da intendersi nella sua eccezione originale (e sarà indicata con l’acronimo RTO(BC)) di cui all’ art. 2 comma 1 punto i, ossia come il tempo massimo per ripristinare la piena operatività anche a livello applicativo (quindi, per ciascun livello di BC, vale sempre la seguente condizione: RTO<=RTO(BC))
LIVELLO 1: Disaster Recovery – advanced level (virtual level backup):
a) replica sul data center della seguente tipologia di dati: file system (inclusi file utenti e condivisioni), database (dump), posta elettronica, immagini server virtuali;
b) RTO:<= 8 h
c) RPO: < =24 h
d) periodicità di replica: giornaliera (file system, database, posta elettronica), settimanale (immagini server virtuali);
LIVELLO 2: Disaster Recovery – enterprise level (database direct access):
a) replica sul data center della seguente tipologia di dati: file system (inclusi file utenti e condivisioni), database (dump), posta elettronica, immagini server virtuali;
b) RTO: < =8 h
c) RPO: < =24 h
d) periodicità di replica: giornaliera (file system, database, posta elettronica), settimanale (immagini server virtuali);
e) database server installati e attivi in data center con possibilità di accesso da remoto da parte dell’Ente per la consultazione e l’estrazione dei dati contenuti nei database oggetto di replica remota;
LIVELLO 3: Business Continuity – entry level:
a) funzionalità di DS – LIVELLO 2;
b) replica dell’infrastruttura IT ristretta ai “servizi IT essenziali” ;
c) RTO (BC): <= 8 h;
d) continuità operativa garantita a livello applicativo; (nota: il data center non offre servizi di virtualizzazione delle risorse)
LIVELLO 4: Business Continuity – advanced level (virtual level compatibility):
a) funzionalità di DS – LIVELLO 2;
b) replica dei “servizi IT essenziali” in un ambiente virtuale tecnologicamente equivalente a quello presente in server-farm (ossia vengono utilizzate le medesime tecnologie di virtualizzazione ma le configurazioni d’ambiente applicate possono essere diverse);
c) replica del dominio e del sistema di autenticazione utenti (in tal caso la struttura del file system può essere non necessariamente identica a quella originale, seppur sia garantito all’utenza e alle applicazioni l’accesso a tutti i dati oggetto di replica secondo la specifica di cui al punto a) precedente);
d) RTO (BC): < =8 h;
e) continuità operativa garantita a livello applicativo;
(nota: tale soluzione è implementata nei data center che offrono degli ambienti virtuali “condivisi” da più utenti)
LIVELLO 5: Business Continuity – top level (virtual level continuity)
a) funzionalità di DS – LIVELLO 2;
b) replica completa dell’ambiente di virtualizzazione della server-farm e di tutti i “servizi IT essenziali”
c) replica del dominio, del file system e del sistema di autenticazione utenti;
d) RTO (BC): < =8 h;
e) continuità operativa garantita a livello applicativo;
(nota: nel data center viene replicato il medesimo ambiente di virtualizzazione presente nella server-farm dell’Ente con le medesime configurazioni, si tratta quindi di un “ambiente virtuale dedicato”)
LIVELLO 6: Business Continuity – enterprise level (total continuity)
a) funzionalità di DS – LIVELLO 2;
b) replica completa della server-farm del Comune di Spoleto a livello tecnologico, strutturale e in grado di garantire i medesimi “servizi IT essenziali e strategici”;
c) RTO (BC): < =8 h;
(nota: l’equivalenza strutturale è a livello “logico-funzionale” e non fisico, ossia devono essere implementati i medesimi sottosistemi presenti nella server-farm dell’Ente al fine di garantire gli stessi “servizi IT essenziali” senza necessariamente utilizzare lo stesso “hardware di base”)
4. la lista dei “servizi essenziali” e dei “servizi strategici”, nonché tutte le informazioni sull’infrastruttura IT dell’Ente (incluse quelle relative all’occupazione delle risorse) e necessarie per l’implementazione di ognuno dei sei livelli suddetti potranno essere acquisite dalla Ditta in sede di sopralluogo;
5. la modalità di replica dei dati (sincrona, asincrona, tecnica mista) rappresenterà una scelta di progetto da parte della Ditta e sarà oggetto di valutazione in quanto avrà un impatto considerevole sulla qualità del servizio offerto (ad es. sul valore dei parametri di RTO – Recovery Time Objective e di RPO – Recovery Point Objective); il data center dovrà essere in possesso di tutte le certificazioni previste dalla normativa vigente in materia di continuità operativa, sicurezza dei dati e sicurezza fisica dei locali;
6. l’incremento annuo del numero di server-virtuali e di occupazione disco dei dati oggetto delle policy di disaster recovery e/o business continuity potrà essere al massimo pari al 25% annuo. Qualora l’incremento raggiunga la soglia del 15% per almeno una delle due risorse suddette la Ditta dovrà darne immediata notifica al SITEL affinchè lo stesso possa individuare ed adottare le soluzioni più idonee (es. revisione delle policy di disaster recovery e/o business continuità) per contenere la crescita di tali risorse all’interno del limite suddetto;
7. per la connettività vale quanto già espresso all’art. 7.2 comma 6 (quindi spetta alla Ditta determinare la banda necessaria per l’implementazione del livello di funzionalità di funzionalità del sistema DRBC garantendo al contempo dei livelli di performance e fault tolerance adeguati);
8. tutti gli oneri per la realizzazione del sistema DRBC e i relativi costi di gestione (inclusi quelli di mantenimento del data center, es. connettività, utenze elettriche, ecc) sono a carico della Ditta;
9. la Ditta dovrà garantire la piena efficienza ed operatività del sistema DRBC (e di ogni suo componente) per una durata pari a quella del servizio di manutenzione e assistenza associato alla server-farm, come specificato all’art. 6 comma 2, garantendo un servizio dedicato di assistenza e manutenzione on site su tutti i suoi
componenti hw-sw (inclusi quelli installati in data center) che preveda almeno le seguenti attività senza alcun onere aggiuntivo per l’Ente:
a) monitoraggio costante della corretta operatività e/o funzionalità di ogni componente;
b) risoluzione di qualsiasi problematica di tipo hw e/o sw che comprometta le performance, la sicurezza, l’affidabilità, l’operatività o le funzionalità del sistema o di uno dei suoi componenti
c) sostituzione e/o riparazione dell’hw guasto o non funzionante
d) applicazione di aggiornamenti (patch/fix, inclusi upgrade, gratuiti o a pagamento, a versioni successive dei prodotti) anche a livello di firmware di tutti i componenti hw e/o sw del sistema DRBC (server, dispositivi di rete, sistemi antivirus, ecc). Tale attività è obbligatoria (almeno con cadenza semestrale o con frequenza maggiore se necessario) qualora, per uno specifico componente, tali aggiornamenti:
• siano forniti gratuitamente dal produttore;
• siano forniti a pagamento dal produttore ma risolvono vulnerabilità o bug di tipo grave o critico (come certificato o documentato dal produttore stesso, ad es. sul suo sito web)
e) modifica della configurazione del sistema DRBC in seguito ad esigenze tecnico-organizzative dell’Ente (es. in seguito alla modifica delle policy di backup e/o disaster recovery e/o di business continuity dell’Ente);
f) supporto specialistico on site per la redazione (anche a livello documentale) del DRP e del BCP dell’Ente (almeno 5 gg)
g) supporto per l’esecuzione di almeno n.1 test di DRP (disaster recovery plan) e di BCP (business continuity plan) l’anno. Il supporto per il BCP dovrà essere garantito qualora il sistema DRBC presenti funzionalità almeno di LIVELLO 4;
10. tutto l’hardware e il software componente il sistema DRBC andrà a costituire parte integrante dell’hardware di base e del software di base dell’Ente e, di conseguenza, anche per esso, valgono le condizioni di fornitura cui all’art. 7.2 comma 3;
11. tutto l’hardware e il software componente il sistema DRBC potrà essere fornito dalla Ditta secondo tre modalità (in ogni caso senza ulteriori oneri per l’Ente):
a) cessione definitiva (vendita): tutto l’hardware e il software suddetto costituisce una piattaforma hw-sw dedicata al sistema DRBC che diverrà sin da subito di proprietà e ad uso esclusivo dell’Ente; in tal caso tutto l’hardware fornito (incluso quello installato in data center) dovrà essere “logisticamente compatibile” con le strutture di contenimento degli apparati presenti in server-farm (es. server di dimensioni adatte ai rack ivi installati) qualora l’Ente decidesse, in futuro, di trasferirlo e installarlo in tale sede.
b) comodato d’uso “dedicato”: tutto l’hardware e il software suddetto costituisce una piattaforma hw-sw dedicata al sistema DRBC che sarà fornita in uso esclusivo all’Ente per una durata pari a quella del servizio di manutenzione e assistenza associato alla server-farm, come specificato all’art. 6 comma 2, al termine dei quali verrà ritirato dalla Ditta che lo potrà destinare ad altri usi o assegnare ad altri soggetti, se lo riterrà opportuno;
c) comodato d’uso “condiviso”: tutto l’hardware e il software suddetto fa parte di una piattaforma hw-sw di tipo “condiviso o di servizio” e, in quanto tale, utilizzabile da più soggetti. Pertanto all’Ente sarà dedicata una porzione – opportunamente configurata - delle risorse hw-sw disponibili su tale piattaforma per l’implementazione e l’utilizzo del sistema DRBC per una durata pari a quella del servizio di manutenzione e assistenza associato alla server-farm, come specificato all’art. 5 comma 2. In tal caso tutti i servizi di cui all’art. 6.2 comma 3 dovranno essere garantiti dalla Ditta sull’intera piattaforma hw-sw o, almeno, sulle risorse hw-sw assegnate all’Ente al fine di ricevere il necessario supporto dai produttori di hw-sw in caso di guasti e/o malfunzionamenti. Tale modalità di fornitura non è applicabile per tutto quell’hardware e/o software componente il sistema DRBC che, per esigenze tecniche e/o vincoli tecnologici, debba essere necessariamente collocato e installato nella server- farm dell’Ente.
Ai fini della valutazione dell’offerta tecnica verranno preferite, nell’ordine, le seguenti soluzioni:
a) (soluzione preferita), b),
c),
senza la possibilità di utilizzare soluzioni “ibride” o “miste” (ossia che prevedono più modalità di fornitura); in ogni caso al termine del periodo di assistenza e manutenzione (comma 9 precedente) la Ditta dovrà:
a) implementare tutte le procedure tecniche e/o le configurazioni sistemistiche necessarie (dopo averle definite e concordate con l’ufficio SITEL dell’Ente) per garantire la continuità del servizio di DR/BC e/o degli altri servizi essenziali e strategici dell’Ente (che potrebbero
essere strettamente connessi e integrati con il sistema DRBC) tenendo conto del cambiamento delle condizioni tecniche (es. ritiro attrezzature da parte della Ditta nelle casistiche di cui ai punti b) e c) precedenti) e/o logistiche (es. spostamento apparati nella server-farm dell’Ente o in altra sede individuata dall’Ente qualora si rientri nella casistica di cui al punto a) precedente);
b) effettuare un backup di tutti i dati di proprietà dell’Ente conservati in data center utilizzando un supporto di memorizzazione esterno e un formato dati utilizzabili dai sistemi di backup dell’Ente; la Ditta dovrà successivamente verificare la correttezza e la leggibilità della copia di backup effettuata e consegnarla all’ufficio SITEL dell’Ente che, dopo aver effettuato tutte le verifiche tecniche interne necessarie, comunicherà formalmente alla Ditta l’autorizzazione per la cancellazione definitiva di tutti i dati dai sistemi del data center in ottemperanza a quanto disposto dal Dlgs 196/2003 e smi.
Inoltre in sede di valutazione dell’offerta tecnica saranno valutate positivamente quelle soluzioni che fanno uso esclusivamente di software open source (e quindi privo di costi di licenza);
12. il sistema DRBC dovrà prevedere soluzioni di fault tolerance per far fronte ad eventuali guasti di tipo hardware degli apparati;
13. in virtù del comma 8 precedente anche per tale fornitura, la Ditta dovrà rispettare le condizioni di cui agli articoli di seguito specificati:
a) art. 5 (obblighi documentali a norma ISO 20000:2005)
b) art. 6 (servizio di manutenzione e assistenza) per tutti i componenti del sistema DRBC installati nella server-farm dell’Ente. Per tutti gli altri componenti installati in data center si applicano in toto i commi 1, 2,3 dell’art. 6 mentre i commi 4 (e relativi sottocommi) e 5 dell’art. 6, relativi alle attività di manutenzione e assistenza, sono sostituiti dai commi 8 e 9 del presente articolo.
c) art. 7 (servizio di help-desk e SLA associati)
14. la documentazione di progetto del sistema DRBC oggetto della fornitura dovrà essere allegata all’offerta tecnica e contenere almeno le seguenti informazioni:
a) livello di funzionalità offerto dal sistema DRBC (tra quelli elencati a comma 3 precedente);
b) le caratteristiche e le certificazioni del data center utilizzato per l’implementazione del sistema DRBC e la relativa sede;
c) le caratteristiche e/o le specifiche di eventuali servizi aggiuntivi associati al sistema DRBC e/o al data center (comma 2 e comma 9 precedenti);
d) specifiche tecniche e/o caratteristiche dei singoli componenti hw-sw il sistema DRBC;
e) per ciascun componente hw-sw del sistema DRBC la relativa modalità di fornitura secondo quanto specificato al comma 11 precedente;
f) specifiche e/o caratteristiche tecnico-funzionali (con particolare riferimento a quelle interenti le performance, la sicurezza e la fault-tolerance nonché ai valori di RTO, RPO e RTO(BC) garantiti) del sistema DRBC, evidenziando quelle migliorative rispetto alle specifiche minime associate al “livello di funzionalità” che sarà oggetto di implementazione (come espresso al punto a) precedente);
g) schema dei collegamenti, dei protocolli e delle interfacce di comunicazione tra i vari componenti del sistema DRBC;
h) eventuali servizi o forniture aggiuntivi ed associati al sistema DRBC (es. giornate aggiuntive di supporto specialistico per la redazione del DRP o del BCP, come richiesto al comma 9 punto f) precedente, potenziamento della connettività Internet\Intranet secondo quanto indicato al comma 7 precedente, ecc);
i) attività tecniche necessarie (es. installazione hardware e/o software, definizione di configurazioni a livello client e/o server, ecc) per l’implementazione del sistema DRBC e relativo cronoprogramma;
j) eventuali criticità connesse con l’implementazione del sistema DRBC.
ARTICOLO 8 - SERVIZIO DI HELP DESK
1. Il servizio di help desk è associato al servizio di manutenzione e assistenza (art. 6), anche nell’ambito dei progetti di cui ai punti precedenti, e dovrà essere erogato secondo le seguenti modalità:
a) tempo di intervento in caso di guasti non superiore alle 4 ore lavorative;
b) tempo per la risoluzione del guasto non superiore alle 8 ore lavorative per guasti “non bloccanti” e di 6 ore lavorative per guasti “bloccanti”; per “guasti bloccanti” si intendono quei guasti che comportano l’interruzione di servizi essenziali o strategici;
c) tempo per il completamento di qualsiasi tipo di richiesta che non riguardi guasti e malfunzionamenti (es. redazione documentazione, pianificazione attività di manutenzione, ecc): da concordare con il SITEL ma con tempo di risposta da parte della Ditta per la validazione del piano di completamento della richiesta dell’Ente pari a 5 gg lavorativi;
d) invio della notifica della scadenza delle licenze (art. 6 comma 4 punto 4.6) con almeno 60 gg di anticipo;
e) orario di help-desk: almeno dalle 8.00 alle 14.00 e dalle 14.30 alle 19.30 dal lunedì al venerdi, e il sabato dalle 8.00 alle 14.00. Tale orario sarà utilizzato come riferimento per determinare le “ore lavorative” nell’applicazione degli SLA . Il sistema di help-desk dovrà essere unico e rispettare le seguenti specifiche:
• possibilità di invio delle richieste di assistenza tramite PEC, fax, telefono, o tramite apposito “cruscotto web” accedibile da Internet (con possibilità di monitorare lo stato di avanzamento delle richieste e la loro assegnazione al tecnico (o ai tecnici) di riferimento).
• generazione di un identificativo (ticket) relativo alla richiesta e da comunicare all’utente:
a) immediatamente, se la richiesta è effettuata telefonicamente o tramite cruscotto web;
b) obbligatoriamente entro 10 minuti, se la richiesta è effettuata tramite fax o PEC;
La mail convenzionale non potrà essere utilizzata per l’apertura dei ticket (in quanto non dà alcuna garanzia sulla data e ora di ricezione) ma solo per:
a) la trasmissione di comunicazione informali e/o necessarie per la risoluzione di un ticket già aperto;
b) la trasmissione dei verbali di intervento;
in tal caso è onere del mittente accertarsi che la comunicazione sia stata correttamente ricevuta dal destinatario.
Per la data/ora di apertura del ticket farà fede:
a) la data/ora di invio della PEC/fax;
b) la data/ora della chiamata telefonica;
c) la data/ora di inserimento della richiesta nel “cruscotto web”; a seconda della modalità utilizzata per l’invio della richiesta.
Le attività di manutenzione, aggiornamento o comunque critiche (es. migrazione dati) che comportano un blocco dei servizi essenziali (come precedentemente definito), se richiesto dal SITEL, dovranno essere pianificati per tempo (almeno 10 gg di anticipo salvo diverso accordo) ed effettuati in orario di chiusura degli uffici comunali e dei servizi al pubblico (quindi anche il sabato pomeriggio o la domenica) senza oneri aggiuntivi per l’Ente.
f) dopo ogni intervento di assistenza/manutenzione (inclusi quelli sul sistema DRBC di cui all’art. 7.3) effettuato la Ditta dovrà produrre apposito verbale di intervento specificando:
• l’identificativo del ticket;
• la data e l’orario di apertura e chiusura del ticket;
• la tipologia della richiesta, es. guasto/malfunzionamento, nuova installazione e/o configurazione, aggiornamento sistemi, ecc.
• la descrizione della problematica o, qualora non si tratti di un guasto\malfunzionamento, la motivazione o l’esigenza che ha reso necessario l’intervento;
• le attività effettuate per soddisfare la richiesta di manutenzione/assistenza e/o per ripristinare la piena operatività dei sistemi e dei servizi;
• la durata delle attività di cui al punto precedente e i nomi dei referenti (o tecnici) che le hanno prese in carico;
• i tempi di cui all’art. 6 comma 3 (punti a)b),c), d),e),f),g),h));
• la durata effettiva dell’intervento al netto dei tempi di cui all’art. 6 comma 3 (punti a)b),c), d),e),f),g),h));
• indicazione del software (script, programmi, ecc) eventualmente prodotto per la risoluzione della problematica nonché il percorso (path) di salvataggio sul repository remoto (art. 6 comma 4.23 punto b))
• dettaglio delle attività di tipo documentale effettuate ed eventualmente resasi necessarie in seguito all’intervento (art. 5 comma 7 punto e) );
tale verbale sarà validato e certificato dal responsabile SITEL (o suo delegato) che attesterà la congruità e/o l’effettiva corrispondenza delle tempistiche (rispetto al lavoro effettivamente svolto) di cui ai punti precedenti. Qualora vengano riscontrate incongruenze o anomalie all’interno del verbale (es. tempi eccessivi per l’esecuzione di talune attività sistemistiche) queste verranno comunicate dal responsabile SITEL alla Ditta che avrà l’onere di dare opportuno riscontro in merito. Se, dopo l’attività di verifica e accertamento, tali incongruità o anomalie dovessero essere confermate il responsabile SITEL potrà procedere d’ufficio alla modifica del verbale suddetto (es. modificando le tempistiche indicate ad un valore ritenuto “congruo”) adottando i provvedimenti conseguenti (inclusa l’applicazione di penali qualora se ne presentino le condizioni).
g) periodicamente, previo accordo con il SITEL, la Ditta dovrà presentare un report dettagliato sugli interventi effettuati indicando le seguenti informazioni minime (che potranno essere oggetto di modifica/integrazione da parte dell’Ente):
• Numero di interventi effettuati;
• Tipologia degli interventi effettuati;
• Numero di interventi risolti entro gli SLA (anche suddivisi per tipologia);
• Numero di interventi risolti al di fuori degli SLA (anche suddivisi per tipologia) indicando per ciascuno le motivazioni del mancato rispetto degli stessi;
• Indicazione delle maggiori criticità riscontrate e proposte migliorative
• Tempo min, medio e massimo di completamento degli interventi (anche per singola tipologia);
• Grafici, rilevazioni e statistiche utili per una migliore comprensione dell’andamento del servizio e per individuare le aree più critiche di intervento;
• Numero e durata complessiva degli interventi riconducibili a guasti e/o malfunzionamenti
• Numero e durata complessiva degli interventi non riconducibili a guasti e/o malfunzionamenti;
ARTICOLO 9 - VERIFICA DI CONFORMITA’ DEL SERVIZIO - DIRETTORE DELL’ESECUZIONE – COLLAUDO DEI TRE PROGETTI IT
1. Il direttore dell’esecuzione procederà periodicamente alla verifica della regolare esecuzione del contratto, accertando che le attività contrattuali siano eseguite in conformità ai documenti contrattuali. In particolare il Direttore dell’esecuzione accerterà che il servizio sia stato eseguita a regola d’arte sotto il profilo tecnico e funzionale, in conformità e nel rispetto delle condizioni, modalità, termini e prescrizioni del contratto e della normativa di settore in quanto applicabile.
2. Ai sensi dell’art. 318 del DPR 207/2010, al termine della durata contrattuale, il direttore dell’esecuzione darà comunicazione all’aggiudicatario del giorno della verifica di conformità definitiva, affinché questi possa intervenire. Della verifica di conformità verrà redatto apposito verbale.
3. Le operazioni necessarie alla verifica di conformità sono svolte a spese dell’appaltatore.
4. Le operazioni di collaudo dei tre progetti IT saranno effettuate dall’Ufficio SITEL del Comune con l’assistenza dell’Appaltatore entro 10 giorni lavorativi. Al termine delle operazioni di collaudo, con esito positivo, verrà rilasciato un certificato di collaudo dal quale decorrerà il termine di cui al precedente articolo 1.7 e 6.2. E’ onere della ditta aggiudicataria risolvere, a propria cura e spese, ogni eventuale problematica emersa in sede di collaudo.
ARTICOLO 10 – CERTIFICATO DI VERIFICA DI CONFORMITA’
1. Il certificato di verifica conformità viene rilasciato a seguito di positiva verifica della conformità del servizio ai sensi del precedente art. 8.
ARTICOLO 11 – CONTROLLI - PENALI
1. Il Comune di Spoleto ha la facoltà di effettuare, in qualsiasi momento, ispezioni volte a verificare il corretto svolgimento del servizio oggetto di appalto.
2. Si individuano le fattispecie soggette alle seguenti penali:
a. € 50,00 per ogni ora di ritardo rispetto al tempo di intervento di cui al precedente art. 8 comma 1 punto a);
b. € 100,00 per ogni ora di ritardo rispetto al tempo di cui al precedente art. 8 comma 1 punto b) (penale cumulabile con quella per il mancato intervento);
c. € 100,00 per ogni giorno di ritardo rispetto al termine concordato con il SITEL (art. 8 comma 1 punto c));
d. € 100,00 per ogni giorno di ritardo rispetto al termine di notifica di cui all’art. 8 comma 1 punto d)), fatto salvo eventuali danni economici tale ritardo possa causare (ad esempio la necessità di dover acquistare anziché rinnovare una determinata licenza, con maggiori costi che saranno addebitati alla Ditta);
3. In caso di inattività, qualora il Comune esegua direttamente o faccia eseguire a terzi gli adempimenti disattesi, richiede all’appaltatore il rimborso delle spese sostenute con una maggiorazione del 50% per rimborso di oneri di carattere generale.
4. La contestazione dell’addebito viene inviata tramite lettera raccomandata AR o PEC al’appaltatorel, invitando lo stesso a formulare le proprie controdeduzioni entro il termine perentorio di 5 giorni ed in casi d’urgenza entro 48 ore.
5. Qualora l’appaltatore non controdeduca nel termine assegnato oppure fornisca elementi inidonei a giustificare le inadempienze contestate, verrà applicata la relativa penale.
6. L’applicazione della penale non preclude al Comune la possibilità di mettere in atto altre forme di tutela.
7. Le penali non potranno cumulativamente e complessivamente eccedere il 10% dell’importo contrattuale. In tal caso il Comune potrà avviare le procedure previste per la risoluzione del contratto di cui al successivo articolo 12.
ARTICOLO 12 - RISOLUZIONE DEL CONTRATTO
1. Il Comune di Spoleto procederà alla risoluzione del contratto nei seguenti casi per gravi inadempimenti agli obblighi contrattuali, debitamente contestati all’Aggiudicatario; in tal caso il Responsabile del procedimento procederà alla formulazione, per iscritto, della contestazione degli addebiti all’appaltatore assegnandogli il termine di 5 (cinque) giorni naturali e consecutivi, e in caso di urgenza 48 ore, per la presentazione delle proprie controdeduzioni. Acquisite e valutate negativamente le predette controdeduzioni, ovvero scaduto il termine senza che l’Aggiudicatario abbia risposto, il Comune procederà alla risoluzione del contratto, salvo il diritto al risarcimento del danno; tale risoluzione verrà formalmente dichiarata con apposito provvedimento amministrativo motivato e comunicato all’aggiudicatario con raccomandata A/R.
2. Si procederà inoltre alla risoluzione espressa del contratto ai sensi dell’articolo 1456 del codice civile nei seguenti casi:
a) fallimento dell’Aggiudicatario;
b) mancata reintegrazione della cauzione entro i termini di cui al successivo articolo 13;
c) cessione del contratto in base a quanto precisato al successivo articolo 14;
d) nelle ipotesi previste al precedente art. 11.
e) l’effettuazione di transazioni senza avvalersi di banche o della società Poste Italiane Spa, fatto salvo quanto previsto dal comma 3 del citato art. 3 legge 13 agosto 2010, n. 136.
3. In caso di risoluzione del contratto o di fallimento dell’Aggiudicatario, il Comune di Spoleto si riserva la facoltà di interpellare progressivamente i soggetti che hanno partecipato alla presente gara, al fine di stipulare un nuovo contratto per l’affidamento delle attività oggetto di appalto. L’affidamento avviene alle medesime condizioni proposte dall’originario aggiudicatario in sede di gara.
4. La risoluzione comporterà in ogni caso l'incameramento della cauzione di cui al successivo articolo 13.
5. In caso di risoluzione del contratto ogni maggiore costo derivante dallo svolgimento di attività da parte di altre ditte, comprese le eventuali spese per atti e simili, resta a carico dell’appaltatore, salvo l’eventuale danno ulteriore.
ARTICOLO 13 – CAUZIONE DEFINITIVA
1. L’Aggiudicatario, a garanzia degli obblighi contrattuali, prima della stipulazione del contratto dovrà effettuare un deposito cauzionale pari al 10% dell’importo totale di aggiudicazione, ai sensi dell’art. 113 del D.Lgs. 163/2006.
2. La fidejussione bancaria o assicurativa dovrà prevedere espressamente la rinuncia al beneficio della preventiva escussione del debitore principale e la sua operatività entro 15 giorni a semplice richiesta scritta della stazione appaltante, nonché la rinuncia all’eccezione di cui all’art. 1957, comma 2, del codice civile.
3. Il Comune potrà compensare i crediti derivanti dall’applicazione delle penalità di cui al precedente articolo 11, con la cauzione definitiva, o comunque utilizzare quest’ultima in caso di inadempimento da parte dell’Aggiudicatario. In tal caso la cauzione dovrà essere immediatamente reintegrata entro e non oltre il termine di 10 (dieci) giorni solari a decorrere da quello della comunicazione dell’avvenuta riduzione. Il mancato reintegro della cauzione entro il termine prescritto è causa di risoluzione del contratto, sempre salvo il diritto del Comune di Spoleto al risarcimento del maggior danno.
ARTICOLO 14 – DIVIETO DI CESSIONE DEL CONTRATTO - SUBAPPALTO - CESSIONE DEI CREDITI
1. Fatto salvo quanto previsto nell’art. 116 del D.Lgs. 163/2006 è vietata la cessione del contratto sotto qualsiasi forma; ogni atto contrario è nullo di diritto.
2. Il sub-appalto è disciplinato dall’art. 118 del D.Lgs. 163/2006. E’ fatto obbligo all’appaltatore di trasmettere, entro venti giorni dalla data di ciascun pagamento effettuato nei suoi confronti, copia delle fatture quietanzate relative ai pagamenti da essi affidatari corrisposti al subappaltatore o cottimista, con l'indicazione delle ritenute di garanzia effettuate. L’appaltatore si impegna a trasmettere alla stazione appaltante tutti i contratti sottoscritti con gli eventuali sub-appaltatori e sub-contraenti nei quali dovrà essere necessariamente inserita, a pena di nullità assoluta, apposita clausola con la quale ciascuno di essi assume gli obblighi di tracciabilità dei flussi finanziari di cui alla legge 13 agosto 2010, n. 136.
3. Ai sensi del combinato disposto dell’articolo 117 del D.Lgs. 163/2006 e della legge 21 febbraio 1991, n. 52, è ammessa la cessione dei crediti derivanti dal contratto, da stipularsi mediante atto pubblico o scrittura privata autenticata, la quale deve essere notificata all’amministrazione debitrice, ed a condizione che il cessionario sia un istituto bancario o un intermediario finanziario iscritto nell’apposito Albo presso la Banca d’Italia. Le modalità procedurali, che qui si intendono tutte richiamate, sono quelle previste nel sopra citato art.117.
ARTICOLO 15 - TRACCIABILITÀ DEI FLUSSI FINANZIARI
1 L’Aggiudicatario assume l’obbligo di tracciabilità dei flussi finanziari di cui alla concessione ai sensi e per gli effetti dell’art. 3 della legge 13 agosto 2010, n. 136, impegnandosi altresì alla comunicazione di cui al comma 7 del medesimo articolo.
2. L’Aggiudicatario, il subappaltatore o il subcontraente che ha notizia dell'inadempimento della propria controparte agli obblighi di tracciabilità finanziaria di cui al presente articolo ne da' immediata comunicazione al Comune di Spoleto e alla prefettura-ufficio territoriale della Provincia di Perugia.
3. Ai fini della tracciabilità dei flussi finanziari di cui alla legge sopra richiamata, gli strumenti di pagamento devono riportare il seguente codice CIG: 3475334058.
ARTICOLO 16 – FORMA DI MANIFESTAZIONE DELLA VOLONTÀ
1. Il rapporto tra il Comune di Spoleto e l’aggiudicatario si perfeziona con la stipulazione del contratto in forma pubblico amministrativa entro sessanta giorni dall’aggiudicazione e dopo le verifiche di legge.
2. La stipula del contratto è subordinata all’avvenuta costituzione della cauzione definitiva di cui al precedente articolo 13 ed al versamento delle spese contrattuali di cui al successivo art. 17.
ARTICOLO 17 – SPESE CONTRATTUALI
1. Sono a carico dell’Aggiudicatario tutte le spese di contratto, quelle di stampa, bolli e registri relativi alla gara, nonché delle copie di contratto e di documento che gli debbono essere consegnati.
ARTICOLO 18 – FORO COMPETENTE
1. Per qualsiasi controversia nascente dall’applicazione e/o dall’interpretazione del contratto di cui alla presente procedura sarà competente il Foro di Spoleto.
ARTICOLO 19 – NORME DI RINVIO
1. Per quanto non previsto nel presente capitolato, si fa riferimento alle norme vigenti in materia e al Codice civile.