1
DISCIPLINARE TECNICO
PER L’AFFIDAMENTO DEL SERVIZIO DI APPLICATION MANAGEMENT DELLA PIATTAFORMA FILENET P8 “SISTEMI
DOCUMENTALI”
CIG N. 709275241C
2
Sommario
Premessa ... 4
1 Definizione della Fornitura ... 5
1.1 Oggetto ... 5
1.2 Ambito del servizio e Landscape di riferimento ... 5
2 Durata ... 7
3 Descrizione dei Servizi... 8
3.1 Servizi di Manutenzione Applicativa Ordinaria ... 8
3.1.1 Attività di Help Desk applicativo e manutenzione applicativa correttiva ... 8
3.1.2 Piccola manutenzione applicativa adeguativa ... 9
3.2 Servizi di Esercizio Applicativo ... 10
3.3 Service Management ... 12
3.4 Manutenzione Applicativa Evolutiva ... 12
3.5 Criteri di accettazione del software (Correttiva ed Evolutiva) ... 13
3.6 Gestione delle anomalie ... 14
4 Ruoli e responsabilità di ACEA ... 15
4.1 ICT Demand & Sviluppo ... 15
4.2 ICT Infrastructure & Operations ... 15
4.3 Utenti finali ... 16
4.4 Key Users ... 16
4.5 Process Owners ... 16
5 Ruoli e Responsabilità Team dell’Appaltatore ... 16
5.1 Responsabile del Contratto ... 17
5.2 Service Manager ... 17
5.3 Help Desk applicativo ... 18
5.4 Competence Center e Delivery Unit ... 18
6 Livelli di Servizio ed Indicatori di Qualità (KPI) ... 19
6.1 KPI per i Servizi di Manutenzione Applicativa Ordinaria ... 20
6.2 KPI per i Servizi di Esercizio Applicativo ... 21
6.3 KPI per i Servizi di Manutenzione Applicativa Evolutiva ... 22
6.4 Altri elementi di valutazione del Servizio erogato ... 23
7 Ipotesi progettuale ... 23
7.1 SCENARIO 1 – Duplice piattaforma Filenet ... 24
7.2 SCENARIO 2 – Unica Piattaforma Filenet ... 25
8 Luogo di lavoro e orario di servizio ... 26
8.1 Reperibilità ... 26
9 Termini e condizioni della fornitura ... 27
9.1 Corrispettivo del Contratto ... 27
9.2 Gestore del Contratto ... 27
9.3 Verifica di conformità delle prestazioni ... 28
3
9.4 Garanzia Definitiva ... 28
9.5 Responsabilità e Polizze Assicurative... 28
9.6 Obblighi contrattuali ... 28
9.7 Penali ... 29
9.8 Subappalto ... 31
9.9 Risoluzione e Recesso ... 31
9.10 Gestione degli Audit ... 32
9.11 Modalità di Fatturazione e Pagamento ... 32
Allegato 1 – Tipologie di Anomalie ... 33
Allegato 2 – Ambienti e interfacce ... 34
Allegato 3 – Figure professionali ... 35
4
Premessa
Acea SpA è una delle principali multiutility italiane. Quotata in Borsa nel 1999, è attiva nella gestione e nello sviluppo di reti e servizi nei business dell’acqua, dell’energia e dell’ambiente. Il Gruppo conta oltre 7.000 dipendenti.
Negli ultimi anni, Il Gruppo Acea ha lanciato un’ambiziosa iniziativa strategica, fortemente voluta dal Management, che costituisce un passo decisivo nel percorso di crescita del Gruppo, con lo scopo di affermarne il consolidamento in Italia ed in Europa.
Acea entra così nell’ottica innovativa dell’Enterprise 2.0, un nuovo modo di fare impresa che utilizza le tecnologie e gli approcci tipici del web 2.0 per stimolare un dialogo ed una collaborazione più efficiente tra persone e azienda.
Il Programma si pone l’obiettivo di rinnovare radicalmente le attuali modalità operative e di armonizzare i sistemi informativi a supporto dei principali processi di business, coinvolgendo progressivamente le diverse Società del Gruppo.
In questo contesto, l’innovazione tecnologica permetterà di conseguire:
• un miglioramento a 360° della qualità dei servizi offerti al Cliente;
• una maggiore efficienza operativa nello svolgimento delle attività;
• una maggiore valorizzazione e coinvolgimento dei dipendenti.
Per rispondere all’esigenza di garantire integrità, univocità e qualità dei dati, Acea ha scelto le soluzioni SAP – leader a livello mondiale per i sistemi gestionali per le Utilities – in continuità con le scelte già operate in passato in una logica di integrazione con i sistemi centrali di Gruppo.
Nell’ambito del programma di rinnovamento e centralizzazione dei Sistemi Informativi dell’azienda, la Direzione Information Communication Technology (di seguito ICT) ha realizzato un percorso di consolidamento delle molteplici soluzioni sulle varie utility nella piattaforma SAP ERP del Gruppo e i relativi sistemi documentali a supporto DMS Filent IBM
La Direzione ICT di ACEA S.p.A. intende affidare ad Appaltatore terzo il servizio di Application Management per la gestione ed evoluzione dei propri sistemi documentali basati su piattaforma IBM Filenet.
Il presente Disciplinare Tecnico descrive l’ambito dei sistemi, i requisiti tecnici e funzionali e le modalità di esecuzione relativi alla fornitura dei servizi in oggetto, in quantità, qualità e livelli di servizio adeguati allo sviluppo, mantenimento ed utilizzo dei sistemi documentali del Gruppo Acea (di seguito Acea) basato sulla piattaforma Filenet. A tali requisiti dovrà attenersi l’Impresa concorrente per la formulazione dell’offerta tecnica ed economica.
La Fornitura sarà a Canone per i Servizi di Manutenzione Applicativa Ordinaria, Esercizio Applicativo e Service Management, descritti nei paragrafi successivi, mentre i Servizi di Manutenzione Applicativa Evolutiva saranno remunerati “a task” con le tariffe riportate nei documenti di offerta.
Per quanto non esplicitamente regolamentato nel presente Disciplinare Tecnico fa fede il Capitolato Generale d’Appalto per Servizi - edizione maggio 2017 (di seguito “Capitolato Generale”).
Le eventuali deroghe contenute nel presente documento rispetto al Capitolato Generale sono efficaci nella sola ipotesi in cui siano enunciate espressamente, con specifico riferimento alla prescrizione derogata.
Quando non diversamente specificato, con “Disciplinare Tecnico” si intende il presente documento, con
“gara” si intende il confronto competitivo al quale l’Appaltatore partecipa sottoponendo Documentazione amministrativa, Offerta Tecnica e Offerta economica.
5
1 Definizione della Fornitura
1.1 Oggetto
L’oggetto dell’Appalto (di seguito anche “fornitura o “servizio”) è costituito dall’erogazione di servizi da effettuarsi sui sistemi documentali di Acea basati sulla piattaforma Filenet, come meglio specificato in seguito.
La fornitura si compone dei seguenti servizi:
• Servizi di Manutenzione Applicativa Ordinaria (par. 3.1)
• Servizi di Esercizio Applicativo (par. 3.2)
• Service Management (par. Errore. L'origine riferimento non è stata trovata.)
• Manutenzione applicativa evolutiva (par. 3.4)
La fornitura dovrà prevedere un modello operativo che si basi sul rispetto di Indicatori di Qualità (KPI) che indirizzano l’erogazione dei servizi verso adeguati livelli di performance. I livelli di servizio dell’Application Management dovranno essere monitorati e presentati, con reportistica ad hoc, a cadenza trimestrale.
I servizi potranno essere erogati prevalentemente da “remoto” mentre un team ristretto di Service Management e Competence Center opererà presso uno o più sedi Acea e sarà il punto di contatto tra il Cliente ed il team AM “remoto”.
Per l’erogazione del servizio l’Appaltatore dovrà utilizzare i sistemi di Gestione Ticket e di Gestione Richieste di Sviluppo in uso presso ACEA aderendo ai processi e procedure aziendali in essere.
In allegato le Procedure di Service Request Management (Allegato 4) e Sviluppo Software (Allegato 5) attualmente in uso.
ACEA si riserva, nel corso della fornitura, di modificare i propri strumenti o le procedure di Gestione Ticket e Gestione richieste di sviluppo.
I processi e le procedure aziendali forniscono le indicazioni in merito ai ruoli e responsabilità dell’ICT e delle Terze Parti nel Ciclo di Vita del Software.
L’utilizzo dei sistemi di Gestione Ticket e di Gestione Richieste di Sviluppo consentirà inoltre il monitoraggio delle attività ambito della fornitura ed un adeguato reporting volto a misurare l’effettivo rispetto dei KPI del servizio. L’Appaltatore è libero di integrare la reportistica fornendo anche indicazioni per il miglioramento dell’intero servizio.
Le attività dovranno essere erogate su tutti gli ambienti del landscape di manutenzione (Sviluppo, Quality, Pre-produzione e Produzione) e dell’eventuale landscape parallelo di progetto (Sviluppo, Quality ed Ambienti ad-hoc).
Non costituiscono oggetto della Fornitura i seguenti servizi:
• Facility Management
• Infrastrutture di comunicazione (Middleware, EAI-Tibco)
• Infrastrutture di connessione
• Architetture tecniche
• DB Administration
• System Management
1.2 Ambito del servizio e Landscape di riferimento
La fornitura si riferisce all’attuale contesto applicativo relativo a:
6 1. Componenti Filenet a supporto ambito Energia Mercato Libero (DMS E) per gestione
documentale e relativo Work Flow
2. Componenti Filenet a supporto ambito Illuminazione Pubblica – areti (DMS-E) per la gestione documentale e relativo workflow
3. Componenti Filenet a supporto ambito Idrico (IDRICO) per gestione documentale e relativo Work Flow delle Società Idriche coinvolte nel programma
4. Componenti Filenet a supporto ambito Energia Mercato Tutelato e Distribuzione Elettrica ARETI (TWINS) per gestione documentale e relativo Work Flow
Di seguito sono riportate le versioni delle componenti applicative:
Per i sistemi e le componenti citati, sono in ambito tutte le funzionalità attivate, inclusi:
• Enhancement (User-exit, Field exit, BAdI, Varianti transazioni…)
• Modifiche allo standard
• Programmi Custom per tutte le componenti
• Profili
• Interfacce e integrazioni
• Report specifici di ciascun modulo
Di seguito si rappresenta il contesto applicativo nel suo complesso nonché l’architettura di riferimento per il mondo Idrico e per il mondo Reti.
In allegato si riportano versioni e ambienti in uso presso il Gruppo e un elenco indicativo delle interfacce per l’ambito Idrico e Elettrico Mercato Tutelato
7
2 Durata
La fornitura avrà una durata di 12 mesi a partire dalla data di sottoscrizione del contratto, e prevede la presa in carico delle attività descritte nei paragrafi successivi per tutte le componenti filenet descritte nel paragrafo 1.2, non è incluso l’ambito ARES.
Al termine del periodo indicato è prevista la possibilità di rinnovare il Contratto per ulteriori 12 mesi con la facoltà per il Committente di ridurre il perimetro dei Servizi richiesti in quanto potranno non essere più oggetto di Appalto le attività di seguito indicate:
o Help-desk applicativo o Esercizio applicativo
o Manutenzione correttiva e piccola adeguativa
L'importo totale stimato posto a base d’asta, IVA esclusa, per la durata contrattuale di 12 mesi è pari ad € 830.000,00 (euro ottocentotrentamila/00) e potrà raggiungere 1.660.000,00 (euro unmilioneseicentosessantamila/00) nel caso di esercizio dell’eventuale rinnovo del Contratto per i successivi 12 mesi senza considerare l’eventuale riduzione di perimetro dei Servizi di cui al precedente punto, che potrà incidere per una quota massima pari al 50% del valore annuo dei servizi.
Il corrispettivo del contratto relativo ai primi 12 mesi che verrà stipulato con l’operatore aggiudicatario, sarà quello risultante dall’Offerta economica presentata in gara dall’operatore stesso nella fase di presentazione delle offerte.
La facoltà di avvalersi del rinnovo e le relative modalità saranno comunicate per iscritto all’Appaltatore mediante l’invio, almeno 3 (tre) mesi prima del termine del contratto, di comunicazione scritta.
Inoltre, negli ultimi 3 mesi di vigenza contrattuale o in caso di recesso da parte della Committente, dovrà essere erogato da parte dell’Appaltatore uscente il passaggio di consegne all’Appaltatore Entrante.
8
3 Descrizione dei Servizi
I servizi richiesti nella presente gara saranno i seguenti:
• Servizi di Manutenzione Applicativa Ordinaria
• Servizi di Esercizio Applicativo
• Service Management
• Servizi di Manutenzione Applicativa Evolutiva
3.1 Servizi di Manutenzione Applicativa Ordinaria
Il Servizio di Manutenzione Applicativa Ordinaria comprende:
• Help Desk applicativo
• Manutenzione applicativa correttiva
• Piccola manutenzione applicativa adeguativa
3.1.1 Attività di Help Desk applicativo e manutenzione applicativa correttiva
Il Servizio di Manutenzione Applicativa Ordinaria include tutte le attività non discrezionali necessarie per mantenere le applicazioni in ambito funzionanti. Consiste nelle attività eseguite dall’Help Desk applicativo di II livello (team AM Appaltatore) allo scopo di prendere in carico e risolvere le richieste di supporto applicativo provenienti dall’ Help Desk di Acea e di piccola manutenzione applicativa adeguativa.
1. Rilevare, Aggiornare / Dettagliare le segnalazioni pervenute dall’Help Desk di primo livello: Rilevare, aggiornare e dettagliare le informazioni essenziali per tracciare le richieste:
utente, descrizione del problema, ora ed altre informazioni ritenute essenziali. Informazioni dettagliate delle chiamate inclusi commenti ed allegati.
2. Definizione tipologia di segnalazione: Il team deve in base alle proprie competenze saper identificare il tipo di richiesta (supporto, correttiva, evolutiva,...) e l’applicazione/processo/area interessata. In via eccezionale, nel caso non riesca a classificare la richiesta, la può rimandare al richiedente per ricevere ulteriori informazioni.
3. Presa in carico: Assegna la priorità in base alla procedura di determinazione priorità. La risorsa di competenza è assegnata in base all’area applicativa impattata. Comunica la presa in carico all’utente.
4. Gestione Escalation: Nel caso di errori o malfunzionamenti gravi/ non disponibilità di funzionalità critiche, l’Appaltatore ha l’onere di dare un aggiornamento periodico al Cliente e di avviare la procedura di Escalation verso gli altri Referenti o gruppi di lavoro competenti, laddove sia necessario i coinvolgimento di altri gruppi di lavoro.
Tutte le richieste di supporto sono classificate durante l’attività di definizione della tipologia di richiesta e possono essere del seguente tipo:
Incident Resolution. L’applicazione evidenzia un malfunzionamento o evento inaspettato / non previsto che impatta o blocca l’esecuzione del processo applicativo e/o delle funzionalità che non soddisfano i criteri ed i requisiti definiti durante la fase di disegno. Le attività di “incident resolution”
includono:
• Analisi del Problema e possibile Workaround. Analisi dettagliata del problema notificata dall’utente allo scopo di identificare l’oggetto e/o il parametro che è responsabile dell’errore; tale attività deve essere svolta rapportandosi direttamente con l’utente, se necessario. Nel caso di problemi critici per il business, potrebbe essere necessario trovare una soluzione temporanea (workaround) per assicurare l’esecuzione della funzionalità. Quando la soluzione finale sarà rilasciata, il ”workaround” sarà sospeso. In quest’attività rientra anche la risoluzione degli errori tecnici dei programmi Filenet evidenziati dalle segnalazioni pervenute a seguito dell’attività di
9 monitoraggio dei job. L’attività di correzione e di workaround può essere eseguita anche in ambiente di produzione, se necessario, previa autorizzazione.
• Customizing o correzione di programmi. La correzione del codice dei programmi custom, la correzione della parametrazione di sistema, e l’installazione delle patch correttive messe a disposizione dall’Appaltatore del software (Note IBM). Le modifiche saranno sviluppate in ambiente di sviluppo e trasportate in ambiente di test per l’esecuzione degli Unit Test.
• Test, user verification, sending to production environment. Lo Unit test degli oggetti rivisti e modificati (codice, customizing,...), gli eventuali system e integration test e le verifiche degli utenti sulla correttezza delle modifiche e la soddisfazione della richiesta (se necessaria) saranno eseguite tramite gli “user acceptance tests” (collaudi utente) a cura degli utilizzatori del sistema; l’Appaltatore dovrà supportare l’utente negli UAT, anche predisponendo gli adeguati scenari di test. Durante gli user acceptance tests, i key users, basandosi sulle condizioni pre- definite dei test valideranno se lo sviluppo soddisfa il requisito. Se il risultato del test è positivo, il Key User approva la soluzione; dopodiché l’oggetto può essere trasportato in ambiente di produzione. La pianificazione di tutte le fasi di test e predisposizione dei relativi ambienti va fatta in accordo con il supporto sistemistico, attraverso l’opportuna struttura di governo dei landscape di ACEA.
• Aggiornamento documentazione Funzionale, Tecnica e Operativa. Le modifiche funzionali, tecniche saranno tracciate aggiornando la documentazione rilasciata dai progetti precedenti in fase di presa in carico.
• Interazione di terze parti per la correzione di bug.
Business process support. Le attività di supporto ai processi di business comprendono:
• Supporto applicativo a fini funzionali. Chiamate o richieste fatte dagli utenti per avere spiegazioni in merito ad una determinata e complessa funzionalità dell’applicazione o per approfondire alcuni step specifici della funzionalità per valutare se può essere utile per scopi specifici di business. Questo tipo di richieste sono in ambito AM solo se riguardano informazioni circa il funzionamento di transazioni/programmi delle applicazioni in ambito. Il supporto agli utenti potrà avvenire da remoto o in casi di necessità sarà fornito un supporto on site presso la sede degli utenti
• Data interpretation on user case. Supporto funzionale agli utenti allo scopo di aiutare l’utente a comprendere la corretta informazione del dato visualizzato a sistema.
• Supporto per l’individuazione e la verifica della soluzione a seguito della risoluzione di bug di prodotto.
3.1.2 Piccola manutenzione applicativa adeguativa
Modifiche o integrazioni applicative non direttamente riferibili alla correzione di errori, che richiedono un effort non superiore a 5 giorni/uomo per completare l’intero ciclo di sviluppo e rilascio (pianificazione, sviluppo, test, user acceptance test e rilascio in produzione). Comprende tutte le attività discrezionali richieste ed autorizzate dall’ICT, anche a seguito di esigenze espresse dai Process Owner/Key user.
Rientrano in questa tipologia le seguenti attività:
• Attività di manutenzione parametrica o adeguamenti sw di portata limitata.
• adeguamenti necessari ai fini dell'innalzamento di versioni del software di base di pacchetti sw utilizzati.
• Adeguamenti a fronte di migrazioni di piattaforma o tesi all’introduzione di nuovi prodotti o modalità di gestione del sistema.
10
• Adeguamenti tesi all’introduzione di nuovi prodotti o modalità di gestione del sistema.
• Modifiche, anche massive, non a carattere funzionale, alle applicazioni (ad esempio cambiamento di titoli sulle maschere, ecc.).
• Supporto all'analisi per attività facenti capo a sistemi che si interfacciano con il sistema oggetto della fornitura (es. SAP ecc.).
• Supporto a favore degli utenti del sistema nella definizione degli interventi di piccola manutenzione (requisito, fattibilità,…).
• Piccole evolutive.
L’Appaltatore si impegna a produrre e manutenere aggiornata la documentazione funzionale e tecnica dei sistemi in ambito (e.g. Business BluePrint). La produzione della documentazione tecnico-funzionale dei sistemi in ambito è un requisito indispensabile per l’accettazione del sw prodotto (sviluppi e configurazioni). Inoltre dovrà essere mantenuta aggiornata la documentazione a supporto degli utenti (Manuali Utente e di Esercizio).
3.2 Servizi di Esercizio Applicativo
Rientrano nei servizi di Esercizio Applicativo le attività di:
• elaborazione procedure
• monitoraggio applicativo
• provisioning delle utenze
• deployment del software
Le attività previste per l’erogazione dei Servizi di Esercizio Applicativo sono dettagliate di seguito.
Elaborazione Procedure
Questa componente del servizio consiste nel supportare l'utenza nell'operatività quotidiana e comprende:
• mantenimento della disponibilità del servizio in linea con i livelli di servizio definiti
• aggiornamenti “massivi” di informazioni presenti nel sistema
• gestione dei domini di valori presenti nel sistema
• supporto specialistico per le applicazioni in esercizio
• interventi puntuali di correzione di una banca dati (bonifiche)
• creazione di prospetti informativi usa-e-getta
• pianificazione ed esecuzione di elaborazioni di prova, con relativa ripresa di dati reali, a scopo di manutenzione preventiva, per anticipare l’esito dell’elaborazione di procedure critiche
• supporto alla individuazione di interventi procedurali o di nuovi pacchetti di mercato che rendano più efficiente l’uso dell’applicazione e la produzione dei documenti, anche realizzando eventuali forme prototipali
• controllo e fasatura dell’introduzione di nuove versioni di software di base (anche in via estemporanea e/o transitoria) nell’ambiente gestito
• aggiornamento documentazione
• presa in carico di nuove funzionalità in esercizio:
• schedulazione e pianificazione del rilascio in esercizio di nuove funzionalità
• verifica e validazione dei prodotti per la gestione: procedure, parametri e tabelle, manuale utente, manuale di gestione, definizioni relative ai dati
• intercettazione e registrazione dei problemi alla fonte, classificazione, eventuale riproduzione dell’errore e, se necessario, conseguente attivazione e governo del servizio di manutenzione correttiva (in accordo con il servizio di Help Desk)
• validazione tecnica e controllo dei risultati delle elaborazioni, al fine di assicurare l’integrità e la correttezza dei dati presenti sulla base informativa, del contenuto dei flussi
11 informativi provenienti o destinati a sistemi esterni, dei dati esposti negli elaborati del sistema.
• Attività di supporto, come start/stop dei servizi, in coordinamento con altre unità ICT di Acea per far fronte ad attività sistemistiche e architetturali programmate, anche fuori dall’orario standard di erogazione del servizio.
Monitoraggio applicativo
Questa componente del servizio consiste nel supportare l'utenza nell'operatività quotidiana e comprende:
• monitoraggio applicazioni con approccio pro-attivo (es. analisi sistematica dei dump e dei log di sistema, dello stato delle code, definizione ed esecuzione di procedure periodiche di health- check ecc…) e misura delle performance
• registrazione eventi per applicativo e stima degli impatti eventi sul servizio
• analisi eventi che superano i livelli di soglia definiti
• definizione dei workaround per il ripristino dei servizi
• gestione degli “Alert”
• gestione delle notifiche (informative e di errore) inviate all’Amministratore nel corso dell’elaborazione dei processi del sistema
• controllo dello stato dei workflow attivi nel sistema relativi ai vari processi implementati
• definizione ed elaborazione di statistiche relative all’utilizzo, alla verifica dei dati, ecc. riguardanti qualsiasi processo implementato sul sistema
• supporto alla verifica periodica dei livelli prestazionali del sistema in particolare a fronte di nuovi rilasci o dell’innalzamento del numero di utenti abilitati
• monitoraggio delle licenze utilizzate (es. user ed engine) in riferimento a quelle acquistate (anche ai fini dell’Audit del Vendor).
La modalità di gestione degli Event provenienti dalla console di monitoraggio a fronte di segnalazioni di errori o blocco applicativo dovrà seguire le procedure standard ACEA che verranno condivise in fase di avvio delle attività.
Provisioning delle Utenze
Provisioning delle utenze e dei ruoli autorizzativi (anche tramite specifiche applicazioni aziendali esterne, ove richiesto
Deployment del Software
Per il Deployment del software si richiede:
• verifica di esercibilità
• verifica monitorabilità delle soluzioni rilasciate
• verifica configurazioni strumenti di monitoraggio
• gestione dei trasporti tra gli ambienti dei landscape (anche tramite specifiche applicazioni aziendali esterne, a - Change Request Management)
• supporto alle attività di installazione software.
Le attività di Esercizio Applicativo che prevedono degli interventi programmati in orari extra rispetto a quelli standard dovranno essere garantiti nell’ambito dell’erogazione del servizio di reperibilità (vedi par.
8.1).
12
3.3 Service Management
Comprende tutte le attività di Coordinamento dei Servizi oggetto della Fornitura e di Analisi di Fattibilità delle richieste di Manutenzione Adeguativa o Evolutiva.
Coordinamento dei Servizi
Il coordinamento dei servizi in ambito contempla il censimento e la pianificazione delle attività su richiesta, la gestione del servizio nel suo complesso, l’approvvigionamento delle risorse con gli skills adeguati per le attività di competenza del team, la governance dei processi e della metodologia che dovrà guidare il “set” integrato di servizi trasversali ad Acea S.p.A. e alle sue Società Operative. Include tra le sue attività l’integrazione di processi “chiave” per il Cliente, quali la gestione delle procedure di Escalation e delle Change Request, le attività di Governance e le interrelazioni con i progetti in corso. Il responsabile dell’Appaltatore per questa attività è il Service Manager che è anche l’interfaccia unica del servizio verso il Cliente Acea.
Analisi di Fattibilità
Per ciascuna richiesta di Manutenzione Adeguativa o Evolutiva, l’Appaltatore valuterà l’impatto (es.
nuova funzionalità, nuova applicazione) sullo stato corrente dell’applicazione e provvederà a formulare una fattibilità tecnica stimando l’effort, in giorni-uomo, e l’elapsed necessario ai fini della realizzazione.
L’attività implementativa sarà avviata solo previa autorizzazione del Responsabile del Cliente che deve dare il benestare all’esecuzione approvando soluzione, tempi ed effort. Le attività saranno in ogni caso schedulate secondo il “Capacity Plan” del team dell’Appaltatore e le priorità indicate dal Cliente.
L’Analisi di Prefattibilità, con stima tempi e costi, dovrà essere resa disponibile ad Acea entro e non oltre il 5° giorno lavorativo successivo alla richiesta, accompagnata da un documento di requisiti di massima o illustrata in apposito incontro. Tale stima sarà successivamente confermata o aggiornata con evidenza della soluzione da implementare al termine dell’Analisi di Fattibilità (si veda Procedura Sviluppo Software di Acea par. 1.1).
3.4 Manutenzione Applicativa Evolutiva
La manutenzione applicativa evolutiva comprende i nuovi sviluppi applicativi riguardanti attività relative all’introduzione di nuove funzionalità o l’evoluzione di funzioni preesistenti, oppure l’ampliamento del perimetro societario, nell’ambito del parco applicativo esistente. Comprende tutte le attività discrezionali che sono richieste per implementare nuovi moduli, o ampliare/migliorare una o più funzionalità dell’applicazione già esistenti, con un effort superiore a 5 giorni per completare l’intero ciclo di sviluppo e rilascio (pianificazione, sviluppo, test, user acceptance test, rilascio in produzione e supporto post avvio).
Le richieste possono pervenire anche a seguito di esigenze espresse dai Process Owner/Key User, ma comunque autorizzate dall’ICT.
Usualmente portano alla realizzazione di:
• funzionalità volte a soddisfare esigenze utente che riguardano funzioni aggiuntive, modificate o complementari al sistema esistente;
• parti di funzioni di dimensione significativa e di cui è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze.
Le attività comprendono:
Realizzazione (analisi funzionale e tecnica, sviluppo, test e documentazione operativa)
13 I documenti saranno preparati per collezionare i requisiti funzionali (analisi funzionale) e definire le specifiche tecniche (analisi tecnica). Durante questa fase sarà necessaria l’approvazione del Cliente per le analisi funzionali allo scopo di mantenere le soluzioni rilasciate allineate esigenze di business. Gli sviluppatori realizzeranno l’oggetto secondo le specifiche dell’analisi. Il test sull’oggetto sarà eseguito secondo i test cases e/o gli “scripts” di test definiti dall’analista funzionale. Dovrà essere prodotta la documentazione operativa ed il materiale di training se richiesto, e dovrà essere aggiornata la documentazione di sistema.
User acceptance test, rilascio/trasporto in ambiente di produzione
Ogni nuovo sviluppo deve essere verificato da un test (Collaudo o “User Acceptance Test”) da parte dei key user del Cliente al fine di confermare la soddisfazione del requisito funzionale. Dopo l’esito positivo del test l’utente approva il trasporto dell’oggetto nell’ambiente di produzione e sarà disponibile agli utenti finali. Il team supporterà, qualora necessario, il Cliente nella preparazione ed esecuzione degli “User Acceptance Test”, anche predisponendo gli adeguati scenari di test.
Supporto post avvio
A valle del rilascio in produzione degli sviluppi sarà erogato il supporto post avvio le nuove soluzioni saranno monitorate insieme agli utenti finali nelle prime due settimane successive al rilascio in produzione.
L’Appaltatore si impegna a produrre e manutenere aggiornata la documentazione funzionale e tecnica dei sistemi in ambito (e.g. Business BluePrint). La produzione della documentazione tecnico-funzionale dei sistemi in ambito è un requisito indispensabile per l’accettazione del sw prodotto (sviluppi e configurazioni).
Il processo delineato rispecchia un ciclo di progetto in metodologia standard. Si richiede, comunque, la disponibilità, ad adottare la metodologia Agile laddove Acea lo richieda.
Indipendentemente dal collaudo, l’Appaltatore è tenuto a garantire che il software sia stato sviluppato in conformità alle specifiche del Committente. La garanzia ha durata di sei mesi dalla data di rilascio del software. La garanzia implica che l’Appaltatore si impegna a rimuovere a propria cura e spese ogni difetto di funzionamento o difformità di che fosse riscontrato a carico del software durante il periodo di garanzia, fatti salvi i casi di non corretto esercizio da parte della Committente.
La denuncia dei vizi e dei difetti di funzionamento da parte della Committente deve avvenire entro 30 giorni dall’avvenuto loro accertamento e la riparazione e/o sostituzione entro 8 giorni solari dalla segnalazione del difetto.
3.5 Criteri di accettazione del software (Correttiva ed Evolutiva)
Quanto realizzato dall’Appaltatore sarà sottoposto a verifica, da parte della Committente o di terzi da essa incaricati, atta ad accertare la rispondenza dei prodotti consegnati ai requisiti funzionali, non funzionali, qualitativi, tecnici e di sicurezza descritti nelle specifiche fornite.
Le prove di accettazione condotte dalla Committente dovranno accertare:
• la fornitura di tutti i deliverable richiesti (software e/o output documentali);
• la perfetta funzionalità del servizio parametrizzato e la rispondenza alle Specifiche Funzionali e/o alle Specifiche Tecniche;
• l’adeguatezza della documentazione prodotta;
• il raggiungimento del livello atteso per i requisiti.
La Committente curerà le attività di accettazione tramite l’utilizzo di risorse interne, di Centri di Competenza specifici o, con onere a suo carico, avvalendosi, eventualmente, dell’assistenza di una terza parte di propria fiducia.
14
3.6 Gestione delle anomalie
Per anomalia s'intende ogni non conformità a requisiti funzionali o non funzionali (di sicurezza, di esercibilità, prestazionali, ecc.) che provoca quindi malfunzionamento software o errore di documentazione, che necessita di una modifica per poter essere eliminata definitivamente.
Tali anomalie saranno comunicate all’Appaltatore tramite apposite “schede anomalie” tracciate sui sistemi di Service Management di ACEA.
Le anomalie possono essere causate dal software / configurazioni realizzate dall’Appaltatore o sui pacchetti sw o soluzioni Cloud adottate da ACEA.
Per le anomalie afferenti ai pacchetti SW o alle soluzioni Cloud, l’Appaltatore svolgerà le attività a sistema con il supporto, se necessario, di ACEA per l’apertura dei ticket sui sistemi dei provider SW o Cloud services. Nello specifico, è responsabilità dell’Appaltatore:
• Aprire la Service Request nei sistemi indicati dai Sw Provider o Cloud Service Provider;
• Aggiornare periodicamente la Committente relativamente allo stato delle SR aperte/chiuse;
• Discutere delle criticità sia con il Sw Provider o Cloud Service Provider sia con la Committente;
• Proporre workaround in caso di necessità dovuta a limitazioni del sistema;
Per ulteriori dettagli sulle responsabilità in capo a questi punti si fa riferimento ai contratti in essere tra Acea e i Sw Provider o Cloud Service Provider.
Le anomalie si intendono suddivise in livelli di severità (da 1 a 5), secondo la classificazione dello standard della Committente; per anomalia grave s’intende un errore che abbia livello di severità 1 o 2 (Cfr. Allegato 1).
La scheda anomalia sarà formalmente aperta solo quando sarà descritto sufficientemente il malfunzionamento, eventualmente documentato con allegati; in presenza di una descrizione incompleta od insufficiente, l’Appaltatore e la Committente dovranno operare congiuntamente per specificare nel dettaglio l’anomalia rilevata.
Le parti si incontreranno, con cadenza periodica ed in funzione delle necessità operative, al fine di esaminare la situazione delle anomalie diverse da 1 e 2 per:
• esaminare lo stato delle “schede anomalie” emesse (precedenti ed attuali);
• confermare la data di apertura delle nuove “schede anomalie”;
• cancellare le schede relative ad anomalie risolte;
• definire le priorità delle “schede anomalie”
• concordare eventuali rilasci correttivi a release successive.
Una “scheda anomalia” sarà considerata chiusa quando il malfunzionamento sarà eliminato, mediante:
• una correzione, anche sotto forma di patch/workaround, che ne elimina la causa;
• una correzione, anche sotto forma di patch/workaround, che ne elimina gli effetti, originando però l’apertura di una scheda di livello inferiore.
15
4 Ruoli e responsabilità di ACEA
Il personale individuato dall’Appaltatore, dimensionato e strutturato sulla base delle esigenze rilevate, dovrà operare in stretta collaborazione con il personale del Cliente di ACEA incaricato di seguire ed indirizzare le richieste dei Process Owner- Key User secondo le procedure già in uso.
Per Acea saranno coinvolti i seguenti ruoli:
• ICT Demand & Sviluppo
• ICT Infrastructure & Operations
• Utenti Finali
• Key Users
• Process Owners
4.1 ICT Demand & Sviluppo
Ha la responsabilità di raccogliere i requisiti che provengono dalle unità di Business di Acea e delle sue Società Operative (Key Users/Process Owners) per le nuove implementazioni. Nel processo di
“Demand”, in particolare, questo team ha la responsabilità di:
• assicurare la raccolta dei requisiti funzionali attraverso l’interazione con i Key User
• verificare la fattibilità dell’intervento tenuto conto anche delle altre iniziative progettuali, evolutive o di AM in corso
• definire la priorità degli interventi in base ai vincoli tecnici, di budget ed all’impatto sull’operatività del business.
E’ responsabile dell’intero servizio oggetto della fornitura e rappresenta anche il canale di escalation principale quando l’erogazione del servizio e le attività di sviluppo richiedono il coinvolgimento di altri fornitori e/o degli utenti di business. Le figure coinvolte nel processo sono i Responsabili dei Sistemi o Applicativi Specifici e loro collaboratori che seguono le attività sulle diverse aree applicative in qualità di
“Referenti del Sistema o dell’Applicativo”.
Questo team è preposto alla “Governance” complessiva del servizio e si avvale della collaborazione del Service Manager dell’Appaltatore con cui ha una relazione diretta per tutte le questioni afferenti il servizio e la sua organizzazione. In particolare, questo team ha la responsabilità di:
• verificare i requisiti di Business per le nuove richieste di implementazione
• validare la soluzione tecnica proposta dall’Appaltatore a copertura dei nuovi requisiti
• validare tempi e costi (effort) degli interventi proposti dall’Appaltatore
• gestire il plafond delle giornate disponibili, ai fini della massima soddisfazione delle esigenze
• indirizzare e coinvolgere gli altri fornitori e/o attori per le attività trasversali
• indirizzare le problematiche ed i rischi evidenziati dal Service Manager dell’Appaltatore.
Tutte le verifiche ed i temi da indirizzare saranno trattati in incontri periodici ACEA-Appaltatore; la cadenza di questi incontri potrebbe essere settimanale/quindicinale.
4.2 ICT Infrastructure & Operations
Ha la responsabilità di garantire l’erogazione dei servizi ICT ed il corretto ed efficace utilizzo dei Sistemi, delle Reti di Telecomunicazione e della loro Sicurezza, pertanto l’Appaltatore dovrà collaborare con tale unità ai fine della risoluzione delle anomalie che potrebbero essere imputabili a:
• Facility Management
• Infrastrutture di comunicazione (Middleware, EAI-Tibco)
• Infrastrutture di connessione
• Architetture tecniche
16
• DB Administration
• System Management.
La gestione delle anomalie in questo ambito dovrà essere richiesta tramite il supporto dell’Help Desk Sistemistico, in linea con le procedure interne ACEA.
4.3 Utenti finali
Gli utenti sono gli effettivi utilizzatori delle applicazioni in ambito. Essi contattano il 1° livello di Help Desk erogato da Acea tramite il tool di trouble ticketing in uso per le richieste di supporto o per gli errori applicativi.
4.4 Key Users
Essi sono un sottoinsieme degli utenti Acea e delle Società Operative identificati formalmente, in particolare per le attività progettuali, come referenti per i processi e applicazioni in ambito. Solitamente sono i Key User ad attivare il processo per le richieste di evolutiva secondo quanto definito nella Procedura di Sviluppo.
4.5 Process Owners
Essi sono i Responsabili delle diverse aree di business e sono coinvolti nel caso di impatti sugli attuali processi, con lo scopo di valutare le soluzioni che devono essere implementate.
5 Ruoli e Responsabilità Team dell’Appaltatore
Per l’Appaltatore dovranno essere coinvolti i seguenti ruoli:
• Responsabile del Contratto
• Service Manager/Program manager
• Help Desk applicativo
• Competence Center/Delivery Unit
Il Responsabile del Contratto e il Service Manager vengono considerate “Key Personnel” (Cfr. Capitolato Generale).
All’Appaltatore è richiesto di identificare in fase di risposta alla gara il “Core Team” che costituirà la componente fissa del team durante l’intera durata del contratto, al fine di garantire continuità del servizio e ridurre le inefficienze e limitare la curva di apprendimento degli altri componenti del team.
Il nucleo minimo del “core team” dovrà essere costituito dalle figure di seguito indicate, dotate delle certificazioni sotto riportate:
1) Service Manager (PMI/PMP e ITIL) 2) Project Manager (PMI/PMP e IBM Filenet) 3) Application Management Expert (IBM Filenet) 4) Architetto (IBM Filenet)
5) Analista senior (IBM Filenet) 6) Programmatore senior (IBM Filenet) Le certificazioni IBM Filenet ritenute valide sono:
• IBM Certified Deployment Professional – Filenet P8 V5.2.1
• IBM Certified Specialist – Filenet V5.2
• IBM Certified Specialist – Case Foundation V5.2
• IBM Certified Specialist – Case Manager V5.2
• IBM Certified Deployment Professional – Datacap V9.0
17
• IBM Certified Deployment Professional – Datacap V9.0
• IBM Certified Solution Designer – Content Navigator V2.0.2
• IBM Certified Solution Designer – Case Manager V5.2
• IBM Certified Solution Designer – IBM Content Collector (ICC)
• IBM Certified Solution Designer – IContent Collector V4.0 (Microsoft Exchange)
Nel corso della durata del contratto è consentito un turn-over massimo del core team pari al 15% su base annuale (sono escluse dal conteggio le cause di forza maggiore).
5.1 Responsabile del Contratto
L’Appaltatore si impegna a designare, a suo totale carico ed onere, un proprio Responsabile del Contratto per la gestione degli aspetti di tipo amministrativo/contabile, avente i requisiti professionali dichiarati in offerta. Tale figura provvederà, per conto dell’Appaltatore, a vigilare affinché i servizi rispondano a quanto stabilito dai documenti contrattuali e avrà le seguenti mansioni:
• supervisione e coordinamento di tutte le attività e prestazioni svolte (anche dell’operato del Service Manager)
• responsabilità del completo raggiungimento degli obiettivi di qualità.
Il Responsabile del Contratto costituirà l’unica interfaccia di ACEA per ogni incombenza amministrativo/contabile.
Per Acea il responsabile del contratto è il Gestore del Contratto.
5.2 Service Manager
L’Appaltatore si impegna a designare un proprio Responsabile del Servizio (Service Manager) per la gestione degli aspetti di tipo operativo, avente i requisiti professionali dichiarati in offerta. Tale figura provvederà, per conto dell’Appaltatore, a gestire il servizio, monitorandone lo stato di avanzamento delle attività ed intervenendo con eventuali azioni correttive e a coordinare le attività di manutenzione evolutiva, nel rispetto della qualità dei deliverable e dei tempi di progetto concordati.
Il Service Manager ha la responsabilità di garantire un unico punto di contatto ad Acea per i servizi in ambito. Inoltre, egli è responsabile della risoluzione dei problemi e deve verificare l’efficienza del team e dei servizi erogati rispetto ai Service Level Agreements (SLAs).
In particolare egli:
• coordina tutte le attività incluse nei servizi oggetto della fornitura
• assicura l’adeguamento delle attività agli standards ed alle procedure definite con Acea
• gestisce le issues con il management di Acea
• comunica i possibili problemi sul Servizio alle Unità interessate di Acea ICT
• presenta su base trimestrale i risultati del Servizio
Inoltre il Service Manager ha la responsabilità di garantire, per gli ambiti applicativi oggetto della fornitura (es. DMS Idrico, Elettrico, …), la pianificazione delle attività e la gestione del servizio.
In particolare:
• supporta i Responsabili delle Unità ACEA interessate nel censimento e pianificazione delle richieste di evolutiva e sviluppo
• interagisce con i Responsabili delle Unità ACEA interessate per monitorare i livelli di servizio e determinare le azioni da intraprendere per il loro rispetto
• gestisce le richieste di servizio ed attivano il processo di Escalation
• monitorano la pianificazione delle attività.
18 In base alle priorità, il Service Manager analizza, stima e formula le proposte tecniche; pianifica le attività autorizzate in linea con le esigenze e le priorità indicate dalle Unità ACEA interessate.
Il Service Manager è previsto operi presso le sedi Acea.
5.3 Help Desk applicativo
L’Help Desk applicativo è costituito da esperti che prendono in carico le richieste provenienti dal primo livello di contatto (SPOC – Single Point of Contact) ed analizzano i problemi applicativi garantendone la risoluzione. Essi si interfacciano, se necessario, direttamente con i Key Users ed i Referenti dell’Applicativo di Acea per una migliore comprensione dei problemi e con le “risorse” del delivery team dell’Appaltatore per individuare e sviluppare la migliore soluzione possibile.
Ove previsto, l’Help Desk monitora e controlla l’intero ciclo di vita della richiesta, verifica lo stato e dà l’opportuno feedback agli interessati, SPOC, Key Users, ICT Sviluppo, Gestione e Demand.
5.4 Competence Center e Delivery Unit
E’ composto da un team di project manager, analisti funzionali, programmatori, specialisti di prodotto e tecnici che si occupano della gestione e dello sviluppo applicativo. Il Competence Center è, idealmente, strutturato in un livello operativo e un livello di governo:
Le figure professionali necessarie al governo dell’erogazione dei servizi sono:
• Project Manager
• Architetto Senior
• Analista Senior
• Application Management Expert
mentre le figure professionali demandate alla gestione operativa del contratto sono:
• Analista
• Programmatore Senior
• Programmatore
• Tecnico di Help Desk
Le risorse coinvolte nel governo dell’esecuzioni operano presso le sedi di Acea, mentre per le figure più operative è possibile una gestione da remoto
La descrizione dei profili professionali è riportato nell’Allegato 3 – Figure professionali.
19
6 Livelli di Servizio ed Indicatori di Qualità (KPI)
I Livelli di Servizio minimi dei servizi oggetto della fornitura sono:
Servizio Indicatore ID KPI Livello di Servizio
Minimo
Servizio di Manutenzione Applicativa Ordinaria
Efficienza del Servizio di Manutenzione
Applicativa Correttiva Critica
IQ1
Tempestività di ripristino dei servizi a seguito di malfunzionamenti o anomalie
Tempo di ripristino dell’operatività del sistema (risoluzione anomalia o riclassificazione come livello C, D, E a valle di un intervento).
A – Critica (o bloccante):
entro 2 ore dalla segnalazione
B – Grave: entro 4 ore lavorative dalla segnalazione
Efficienza del Servizio di piccola
Manutenzione Applicativa Adeguativa e Correttiva non
Critica
IQ2
Puntualità nelle attività di implementazione delle richieste pianificate (include correzione anomalie di livello di gravità C-Medio, D-Basso e E-Formale secondo piano di correzione condiviso)
Rispetto della
pianificazione concordata di rilascio delle richieste
Servizio di esercizio applicativo
Efficienza del Servizio di
Esercizio applicativo
IQ3
Tempestività di
esecuzione delle richieste di servizio secondo le modalità previste dalle Procedure ACEA
Si distinguono tre tipologie di KPI, secondo la priorità di richiesta.
La priorità delle richieste sarà definita in funzione della loro tipologia, in fase di set up del servizio
Evasione delle richieste secondo le priorità indicate:
Alta: entro 4 ore lavorative dalla richiesta
Media: entro 16 ore lavorative dalla richiesta Bassa: entro 32 ore lavorative dalla richiesta
Servizio di Manutenzione Applicativa Evolutiva
Efficienza del Servizio di Manutenzione
Applicativa Evolutiva
IQ4
Puntualità nelle attività di sviluppo software per attività di effort fra 6 e 60 giorni – persona
Rispetto della
pianificazione concordata di rilascio al collaudo utente per le attività di sviluppo e progetti IQ5
Puntualità nelle attività di sviluppo software per attività di effort superiore a 60 giorni-persona
Affidabilità del Servizio di Manutenzione
Applicativa Evolutiva
IQ6 Qualità del software realizzato e sua affidabilità
Collaudo positivo nella prima sessione
In allegato sono riportate le descrizioni dei diversi livelli di criticità delle anomalie.
Di seguito la descrizione degli indicatori che saranno monitorati nel corso della fornitura e dei rispettivi valori attesi.
20
6.1 KPI per i Servizi di Manutenzione Applicativa Ordinaria
IQ1
Tipologia indicatore Efficienza Servizio di Manutenzione Applicativa Correttiva
Aspetto da valutare
Tempestività di ripristino dei servizi a seguito di malfunzionamenti o anomalie
Si distinguono due tipologie di KPI, variabili secondo il livello di criticità dell’anomalia / malfunzionamento:
- A – Critica: risoluzione entro 2 ore dalla segnalazione
- B – Grave: risoluzione entro 4 ore lavorative dalla segnalazione
Unità di misura Ore
Periodo di osservazione Trimestre precedente la misurazione
Dati elementari da rilevare
Numero totale di segnalazioni di malfunzionamento per ciascun livello di criticità chiusi entro lo SLA:
- Ntot_int_chiusi _inSLA_Criticità-Livello A - Ntot_int_chiusi _inSLA_Criticità-Livello B
rispetto al numero totale di segnalazioni di malfunzionamento nel periodo di osservazione:
- Ntot_int_segnalati_Criticità-Livello A - Ntot_int_segnalati_Criticità-Livello B
Ai fini del calcolo dei tempi di risoluzione dei malfunzionamenti sono esclusi i tempi non imputabili all’Appaltatore a causa dell'indisponibilità dell'ambiente di correzione, o per impedimenti all’operatività
dell’Appaltatore per ragioni imputabili ad Acea SpA.
Formula
IQ1 A = (Ntot_int_chiusi_inSLA-Criticità-Livello A)/(Ntot_int_segnalati- Criticità-Livello A)
IQ1 B = (Ntot_int_chiusi_inSLA-Criticità-Livello B)/(Ntot_int_segnalati- Criticità-Livello B)
Il tempo di chiusura dell’anomalie verrà calcolato come:
Tempo di Chiusura = Timestamp di Chisura – Timestamp di Apertura – Somma dei Tempi di Sospensione per cause non imputabili all’Appaltatore
Valore di soglia
IQ1 A > 95%
IQ1 B > 95%
Le risoluzioni o workaround, nei restanti 5% dei casi, non possono superare il doppio dei tempi massimi previsti nei casi A e B
Fonte dati Sistemi Help Desk
Frequenza di misurazione Trimestrale
21 IQ2
Tipologia indicatore Efficienza del Servizio di piccola Manutenzione Applicativa Adeguativa e Correttiva non Critica
Aspetto da valutare Puntualità nelle attività di implementazione delle richieste pianificate Unità di misura Giorni lavorativi
Periodo di osservazione Trimestre precedente la rilevazione
Dati elementari da rilevare
Numero di richieste / correttive implementate entro i tempi pianificati (Ntot_MAA_impl) rispetto al totale delle richieste pianificate all’interno del piano di lavoro trimestrale concordato (Ntot_MAA_pian)
Ai fini del calcolo dei tempi di implementazione delle richieste sono esclusi i tempi non imputabili all’Appaltatore a causa dell'indisponibilità di ambienti, sistemi, o per impedimenti all’operatività dell’Appaltatore per ragioni imputabili ad Acea SpA
Formula IQ2 = (Ntot_MAA_impl)/ (Ntot_MAA_pian) Valore di soglia IQ2 > 95%
Fonte dati Sistemi gestione richieste Frequenza di misurazione Trimestrale
6.2 KPI per i Servizi di Esercizio Applicativo
IQ3
Tipologia indicatore Efficienza Servizio di Esercizio Applicativo
Aspetto da valutare
Tempestività di esecuzione delle richieste di servizio, secondo le modalità previste dalle Procedure ACEA
Si distinguono tre tipologie di KPI, secondo la priorità di richiesta.
La priorità delle richieste sarà definita in funzione della loro tipologia, in fase di set up del servizio
Unità di misura Ore lavorative
Periodo di osservazione Trimestre precedente la misurazione
Dati elementari da rilevare
Numero di richieste eseguite entro i tempi previsti per ciascuna Fascia di priorità (N_rich_chiuse_4,16,32h _tipoA,M,B), rispetto al numero totale di richieste pervenute per ciascuna fascia (N_rich_tipoA,M,B)
Ai fini del calcolo dei tempi di implementazione delle richieste sono esclusi i tempi non imputabili all’Appaltatore a causa dell'indisponibilità di ambienti, sistemi, o per impedimenti all’operatività dell’Appaltatore per ragioni imputabili ad Acea SpA
Formula
IQ3 fascia A = (N_rich_chiuse_4h_tipoA)/ (N_rich_tipoA) IQ3 fascia M = (N_rich_chiuse_16h_tipoM)/ (N_rich_tipoM) IQ3 fascia B = (N_rich_chiuse_32h_tipoB)/ (N_rich_tipoB) Valore di soglia
IQ3fascia A > 98%
IQ3fascia M > 98%
IQ3fascia B > 98%
Fonte dati Sistemi Help Desk e altri sistemi gestione richieste Frequenza di misurazione Trimestrale
22
6.3 KPI per i Servizi di Manutenzione Applicativa Evolutiva
IQ4
Tipologia indicatore Efficienza del Servizio di Manutenzione applicativa Evolutiva per attività fra 6 e 60 giorni-persona
Aspetto da valutare Puntualità attività di sviluppo software Unità di misura Giorni lavorativi
Periodo di osservazione Trimestre precedente la rilevazione
Dati elementari da rilevare
Numero di sviluppi rilasciati al collaudo rispettando la pianificazione fornita (NData_coll_risp) rispetto al numero di sviluppi con collaudo pianificato nel trimestre (NData_pian_coll)
Ai fini del calcolo dell’indicatore, sono esclusi i collaudi che non hanno rispettato i tempi pianificati per cause non imputabili all’Appaltatore per l’indisponibilità di ambienti, sistemi, o per impedimenti all’operatività dell’Appaltatore per ragioni imputabili ad Acea SpA
Formula IQ4 = (NData _ coll_risp)/(NData _ pian _ coll) Valore di soglia IQ4 > 95%
Fonte dati Piano di Lavoro
Frequenza di misurazione Trimestrale
IQ5
Tipologia indicatore Efficienza del Servizio di Manutenzione applicativa Evolutiva per attività superiori a 60 giorni-persona
Aspetto da valutare Puntualità attività di sviluppo software Unità di misura Giorni lavorativi
Periodo di osservazione Trimestre precedente la rilevazione
Dati elementari da rilevare
Numero di giorni di ritardo nel rilascio al collaudo rispetto alla data pianificata. In caso di collaudo negativo il numero di giorni dalla comunicazione da parte di Acea dell’esito del collaudo e il successivo rilascio al collaudo da parte dell’Appaltatore verranno conteggiati a effetti di calcolo dello SLA.
Ai fini del calcolo dell’indicatore, sono esclusi i collaudi che non hanno rispettato i tempi pianificati per cause non imputabili all’Appaltatore per l’indisponibilità di ambienti, sistemi, o per impedimenti all’operatività dell’Appaltatore per ragioni imputabili ad Acea SpA
Formula IQ5 = Numero giorni di ritardo rispetto alla data pianificata Valore di soglia IQ5 <= 2 giorni
Fonte dati Piano di Lavoro
Frequenza di misurazione Trimestrale
23 IQ6
Tipologia indicatore Affidabilità del Servizio di Manutenzione applicativa Evolutiva (attività superiori ai 5 gg lavorativi)
Aspetto da valutare Qualità del software realizzato e sua affidabilità Unità di misura Numero collaudi eseguiti
Periodo di osservazione Trimestre precedente la rilevazione
Dati elementari da rilevare
Numero di Sviluppi collaudati con successo alla prima sessione (Ncoll_ok), rispetto al Numero di Sviluppi rilasciati al collaudo nel trimestre (Ncoll_tot) La sessione di collaudo può essere composta da più sedute, in funzione della numerosità e complessità delle funzionalità/processi da collaudare.
Ai fini del calcolo dell’indicatore, sono esclusi i collaudi non andati a buon fine per cause non imputabili all’Appaltatore per l’indisponibilità di ambienti, sistemi, o per impedimenti all’operatività dell’Appaltatore per ragioni imputabili ad Acea SpA
Formula IQ6 = Ncoll _ ok/Ncoll_tot Valore di soglia IQ6 > 90%
Fonte dati Resoconto collaudo utente Frequenza di misurazione Trimestrale
6.4 Altri elementi di valutazione del Servizio erogato
Ai fini della valutazione della fornitura, in corso d’opera nel corso degli incontri di SAL-Reporting, saranno altresì monitorati i seguenti elementi qualificanti: Approccio Metodologico, Organizzazione del Team (Service Management, Help Desk e Competence Center) e Reporting.
Il Gestore del Contratto, coadiuvato dai Responsabili dei Sistemi o Applicativi Specifici sui quali vengono erogati i servizi oggetto della fornitura, verificherà l’esecuzione dei servizi e la conformità degli stessi rispetto a quanto definito nel presente Disciplinare Tecnico.
7 Ipotesi progettuale
Nell’ambito della manutenzione evolutiva all’Appaltatore, verrà richiesto di avviare un’attività progettuale volta alla reingegnerizzazione dell’attuale architettura applicativa con i seguenti obiettivi:
• Avere una interfaccia applicativa dedicata per ogni macro stream (AE mercato libero, Twins, Idrico)
• Agevolare per quanto possibile la manutenibilità sistemistica delle diverse interfacce applicative omogeneizzando il versioning delle componenti ripetute per necessità progettuali oppure accorpando a livello applicativo l’utilizzo di singole componenti
• Semplificare gli sviluppi, i test, e i rilasci evitando potenziali conflitti tra i vari PM ICT per le attività di manutenzione correttiva ed evolutiva
• Avere un’unica release aggiornata di Filenet e relative componenti, che introduce e permette di sfruttare tutte le nuove funzionalità offerte dai diversi prodotti
• Agevolare per quanto possibile la manutenibilità sistemistica delle diverse interfacce applicative omogeneizzando il versioning delle componenti ripetute per necessità progettuali oppure accorpare
24 Acea ha già avviato un’analisi preliminare in un’ottica di rivisitazione e omogeneizzazione delle attuali piattaforme applicative e delle relative componenti Filenet installate, giungendo ad individuare due macro- scenari:
SCENARIO 1 – Duplice piattaforma Filenet
• SOLUZIONE 1.1 - In caso di nessuna criticità introdotta da upgrade Mercato libero (Citato Ares)
• SOLUZIONE 1.2 – In caso di criticità introdotta da upgrade Mercato libero (Citato Ares) SCENARIO 2 – Unica Piattaforma Filenet
Di seguito se ne riportano i dettagli.
7.1 SCENARIO 1 – Duplice piattaforma Filenet
SOLUZIONE 1.1 - In caso di nessuna criticità introdotta da upgrade Mercato libero
25 SOLUZIONE 1.2 – In caso di criticità introdotta da upgrade Mercato libero
7.2 SCENARIO 2 – Unica Piattaforma Filenet
26 Resta inteso che, qualora Acea intendesse dare seguito all’implementazione dell’attività progettuale da parte dell’Appaltatore, quest’ultimo sarà vincolato a quanto illustrato nell’Offerta Tecnica in termini di progetto e tempi.
8 Luogo di lavoro e orario di servizio
Le attività oggetto del presente contratto saranno svolte da remoto a meno del Service Management, del Client Management e del Competence Center che opereranno presso una delle sedi di ACEA. Le sedi presso le quali effettuare i servizi saranno indicate da ACEA all’avvio della fornitura ed eventuali variazioni di sede saranno comunicate di volta in volta durante il periodo di validità del contratto. Le sedi si intendono dislocate sul territorio del Comune di Roma. Gli ambienti messi a disposizione saranno disponibili nel normale orario di lavoro in linea con l’orario richiesto per i singoli servizi.
Per il Servizio di Manutenzione Applicativa Ordinaria ed Help Desk l’orario di servizio è dalle ore 8:00 alle ore 19:00 nei giorni lavorativi del calendario italiano dal Lunedì al Venerdì, festività escluse.
Per il Servizio di Esercizio applicativo l’orario di servizio è dalle ore 7:00 alle ore 20:00 nei giorni lavorativi del calendario italiano dal Lunedì al Venerdì, festività escluse. Le attività di Esercizio Applicativo che prevedono degli interventi programmati in orari extra rispetto a quelli standard dovranno essere garantiti nell’ambito dell’erogazione del servizio di reperibilità (vedi par. 8.1).
Per i Servizi di Manutenzione applicativa evolutiva e per il Service Management l’orario di servizio è richiesto dalle ore 9:00 alle ore 19:00 nei giorni lavorativi del calendario italiano dal Lunedì al Venerdì, festività escluse.
Acea si riserva di richiedere, su base programmatica o in emergenza, una copertura oraria più ampia di quella prevista o nei fine settimana per operazioni di routine o a carattere di urgenza (e.g.
rilasci sw rilevanti,…).
8.1 Reperibilità
E’ prevista Reperibilità per le Applicazioni / Moduli in ambito che interfacciano altre Applicazioni / Moduli critici fuori ambito. La Reperibilità verrà attivata in caso di anomalie bloccanti sui sistemi critici che a giudizio insindacabile del personale ACEA richiedano la presenza del personale dell’Appaltatore in quanto necessario a supporto della risoluzione dell’anomalia.
In caso di necessità l’Appaltatore si dovrà presentare nella sede ACEA di competenza entro 1 ora dall’attivazione della Reperibilità.
La Reperibilità verrà attivata mediante chiamata telefonica e successiva comunicazione e-mail. A effetti del calcolo degli SLA verrà considerato come tempo di segnalazione il timestamp della e-mail. Lo SLA verrà calcolato dal tempo di segnalazione + 1 ora.
Il servizio di reperibilità verrà altresì attivato a fronte di interventi di manutenzione programmata da effettuare extra orario di lavoro standard previsto per il servizio di Esercizio Applicativo.
La reperibilità verrà corrisposta a canone, senza ulteriori costi.
27
9 Termini e condizioni della fornitura
9.1 Corrispettivo del Contratto
Il corrispettivo per l'esecuzione delle prestazioni oggetto del contratto sarà quello offerto in gara dall’Appaltatore e sarà remunerato:
• con un canone trimestrale posticipato costante per i servizi di Manutenzione Applicativa Ordinaria, Servizi di Esercizio Applicativo e Service Management
• trimestralmente, posticipato, sulla base dei consuntivi, approvati da Acea, dei Manutenzione Applicativa Evolutiva conclusi nel trimestre di riferimento
Per i Servizi di Manutenzione Applicativa Ordinaria, Esercizio Applicativo e Service Management il canone trimestrale è fisso, omnicomprensivo e costante per l’intera durata della fornitura. Sono incluse nel canone tutte le attività svolte in regime di reperibilità.
Per i servizi di Manutenzione Applicativa Evolutiva il plafond di giornate riportato nel template di offerta economica non è impegnativo per Acea e rappresenta la stima che Acea intende impegnare nel periodo di valenza del contratto.
Il plafond potrà essere erogato nell’arco di validità del Contratto in funzione delle esigenze del business e su esplicita indicazione e autorizzazione di ICT.
I corrispettivi saranno quelli offerti in gara per figura professionale e complessivamente su base annua l’Appaltatore dovrà rispettare la proporzione di impiego delle diverse figure professionali riportate nell’Offerta economica.
Nel caso di abbandono dell’attività di sviluppo commissionata, per cause non imputabili all’Appaltatore, verrà riconosciuto allo stesso un corrispettivo in base alla seguente formula:
GG/U riconosciuti = GG/U stimati ed approvati per l’attività cancellata x % avanzamento, dove la % avanzamento da utilizzare è quella relativa all’ultima fase completata al momento della cancellazione, secondo la tabella riportata:
Fase Impegno
considerato
Avanzamento Cumulativo riconosciuto
Definizione requisiti completata 10% 10%
Documento di Analisi completato 25% 35%
Disegno tecnico completato 15% 50%
Realizzazione e unit test completati 40% 90%
System, Integration test e Collaudo Utente
completati 10% 100%
Ciò non vale nel caso in cui la cancellazione sia motivata da eccezioni da parte di Acea di mancato adempimento contrattuale da parte dell’Appaltatore.
9.2 Gestore del Contratto
Il Gestore del Contratto, nominato dal Committente per espletare tutti i compiti e le funzioni connessi alla fase di esecuzione del Contratto e al quale dovranno essere indirizzate tutte le comunicazioni relative al Contratto medesimo, è Sara Volino Coppola.
