CIG D CUP G50C CAPITOLATO TECNICO ALLEGATO 4 AL DISCIPLINARE DI GARA. Prot. n.2574/2015

Transcript

1 GARA A PROCEDURA APERTA PER L AFFIDAMENTO DEI SERVIZI DI MIGRAZIONE E GESTIONE DEL MODULO IT BASE - PIATTAFORMA REGIONALE PER L INTERMODALITA E LA LOGISTICA INTEGRATA CIG D CUP G50C CAPITOLATO TECNICO Prot. n.2574/2015 Società istituita ai sensi del D.M. 18T/2005 Ministero Infrastrutture e Trasporti Sede Legale: Via Francesco Crispi 115, Roma Tel.: Fax: info@uirnet.it - uirnetspa@legalmail.it C.F./P. IVA R.E.A. C.C.I.A.A. RM n Capitale sociale Euro ,00 i.v.

2 INDICE 1 PREMESSA Introduzione: brevi cenni sulla PLN e sulla PLR Contesto operativo OGGETTO E CARATTERISTICHE DELL APPALTO MIGRAZIONE DELLA PLR NEL PRIVATE CLOUD DI UIRNET GESTIONE APPLICATIVA Indicazioni qualitative per la gestione dei servizi Manutenzione Adeguativa e Correttiva (MAC) Manutenzione Evolutiva (MEV) Processo di erogazione del Servizio di MEV Incident Management (ripristino dei malfunzionamenti) Help Desk di 1 livello Help Desk di 2 Livello Tipologie di malfunzionamenti Monitoraggio e reportistica dei processi di business GESTIONE OPERATIVA E SISTEMISTICA GESTIONE DEGLI APPARATI MOBILI Installazione/disinstallazione degli Apparati Mobili Gestione ed amministrazione degli Apparati Mobili Gestione dei Malfunzionamenti degli Apparati Mobili ORGANIZZAZIONE E FIGURE PROFESSIONALI Organizzazione Figure Professionali AFFIANCAMENTO VERIFICHE DI CONFORMITA Pag 2 di 42

3 9.1 Documentazione Configuration Description Status Report Piano di Affiancamento Verifiche di Conformità sulle attività realizzative Verifiche di Conformità sulle attività di gestione CRONOPROGRAMMA DELL APPALTO DEFINIZIONE SLA E PENALI SLA a verifica immediata RSC - Rispetto delle scadenze contrattuali indicate come milestone nel Cronoprogramma dell appalto RSD - Rispetto degli standard documentali SLA a verifica periodica Ripristino del Modulo IT Base Disponibilità del Modulo IT Base Manutenzione Adeguativa e Correttiva (MAC) Manutenzione Evolutiva (MEV) Tempo medio di risposta Livello di documentazione Incident Management Tempo di presa in carico (Tpc) Incident Management Tempo di risoluzione (Tc) Gestione Apparati Mobili: On Board Unit (OBU) Service Requests Nota: Nel presente documento sono sempre usate le diciture Committente per indicare UIRNet S.p.A., Concorrente per indicare l operatore economico, in forma individuale o plurisoggettiva, che partecipa alla gara e Fornitore per riferirsi all operatore economico, in forma individuale o plurisoggettiva, che si aggiudicherà la gara. Pag 3 di 42

4 1 PREMESSA 1.1 Introduzione: brevi cenni sulla PLN e sulla PLR UIRNet S.p.A. (di seguito, per brevità, UIRNet), ai sensi art. 61-bis del D.L. 24 gennaio 2012 n. 1, convertito con modificazioni dalla Legge 24 marzo 2012 n. 27, è soggetto attuatore unico del Ministero delle Infrastrutture e dei Trasporti per la realizzazione e la gestione della Piattaforma per la gestione della rete logistica nazionale (di seguito, anche PLN ), definita nelle sue caratteristiche fondamentali dal D.M. n. 18 T del 20 giugno 2005, ed è stata istituita con l obiettivo di migliorare l efficienza e la sicurezza del trasporto merci e della logistica in Italia, favorendo l interconnessione dei Nodi di interscambio modale. In ragione di quanto sopra, ad oggi, UIRNet ha completato l implementazione dei sei macro-servizi core della piattaforma, tutti sottoposti a collaudo ministeriale con esito positivo, e contestuale verifica della capacità della PLN di soddisfare i requisiti di sicurezza e prestazionali richiesti. Per testare sul campo i servizi, è stata avviata una Fase di Sperimentazione che vede oggi circa mezzi inseriti in anagrafica PLN, suddivisi tra aziende; in detta fase, oltre alla erogazione delle funzionalità principali, sono stati configurati anche alcuni servizi specifici quali Info Logistica e Preavviso di Arrivo, quest ultimo realizzato integrando il macroservizio di prenotazione (Booking) della PLN con E-Port, il PCS (Port Community System) del Porto di Genova. Ad oggi il servizio consente ad oltre mezzi (di vari operatori) di effettuare preavvisi di carico/scarico presso i Terminal di Voltri e Sampierdarena, riducendo notevolmente i tempi di attesa. Grazie ad una strategia di copertura applicativa incrementale, sono in corso di sviluppo ulteriori moduli aggiuntivi della PLN finalizzati alla erogazione di servizi a valore aggiunto, quali ad esempio il Corridoio Controllato Doganale (di seguito CCD ) in sperimentazione con l Agenzia delle Dogane e dei Monopoli (di seguito Agenzia ) presso i porti di Genova e di La Spezia. La PLN è attualmente gestita in hosting dal Raggruppamento Temporaneo di Imprese, formato da Selex ES Spa (Mandataria), Telespazio Spa e Autostrade Tech Spa (mandanti), aggiudicatario della gara indetta da UIRNet per la progettazione e la realizzazione della PLN, e se ne prevede nel corso del 2015 la migrazione presso il CED del MIT in ambiente esercito da HP Enterprise Services Italia S.r.l. (di seguito HP ), aggiudicataria della gara indetta da UIRNet per l affidamento di servizi di gestione 2015 (Full Service), migrazione Cloud, miglioramento prestazionale e trasferimento presso il CED del MIT (di seguito, per brevità, anche il Gestore Provvisorio PLN 2015 ). I servizi erogati dalla PLN sono stati ulteriormente potenziati attraverso lo sviluppo del Modulo IT Base della Piattaforma (di seguito anche Modulo IT Base o PLR ), concepito nel rispetto degli orientamenti strategici riportati nel Quadro Strategico Nazionale , e finalizzato alla realizzazione di uno strumento di Governance, la Piattaforma Logistica Regionale, atto a garantire l integrazione fra i servizi realizzati da ITS eterogenei già esistenti (o in sviluppo) a valenza regionale. Lo scopo principale del Modulo IT Base è quello di abilitare i nodi dotati di soluzioni info-telematiche isolate alla condivisione delle informazioni in rete realizzando un modello di integrazione basato sulla condivisione di servizi. In sintesi all interno del progetto di sviluppo del suddetto modulo si sono realizzati: un Framework Applicativo, replicabile in altri contesti regionali, per l integrazione degli ITS territoriali con la Piattaforma Logistica Nazionale basato su un architettura SOA, aperta e scalabile mediante l adozione di un Enterprise Service Bus (ESB); un Modulo per la gestione del Catalogo dei Servizi che consenta agli Operatori di pubblicare e rendere fruibili i Servizi Informatici da essi esposti; Pag 4 di 42

5 un Modulo di Orchestrazione dei Servizi Informatici capace di integrare i singoli servizi esposti dai differenti Attori al fine di coordinare lo svolgimento di processi complessi; alcune componenti applicative verticali deputate alla gestione di specifiche esigenze, quali, ad esempio, il tracking dei veicoli, la pianificazione delle operazioni logistiche e la gestione della disponibilità delle risorse dei Nodi Logistici. Il progetto ha comportato l organizzazione e la gestione della sperimentazione pilota delle funzionalità in Puglia (una delle Regioni Obiettivo Convergenza individuate nell ambito del PON ), in modo da testare efficacemente l integrazione dei servizi offerti sul territorio pugliese dai nodi logistici (Porto di Bari, Porto di Taranto, Porto di Brindisi e Interporto di Bari). Il Modulo IT Base prevede una integrazione applicativa con i seguenti moduli della PLN: SmarTruck: strumento rivolto agli Autotrasportatori per l organizzazione ed il monitoraggio dei viaggi; Booking: strumento dedicato ai Nodi Logistici ed agli Autotrasportatori per la gestione dei processi legati alla prenotazione di un ampia gamma di servizi, dalle finestre di arrivo per il carico e lo scarico delle merci alle piazzole di sosta. La PLR è attualmente gestita in hosting (e fino al 31 dicembre 2015) da Selex ES Spa, aggiudicataria della gara indetta da UIRNet per la progettazione,la realizzazione e la sperimentazione del Modulo IT Base (di seguito anche il Gestore uscente ). Oggetto del presente appalto, come meglio dettagliato al cap. 2, è la gestione in esercizio del Modulo IT Base a far data dal 1 gennaio 2016, previa migrazione dello stesso a decorrere dal 1 novembre 2015 in opportuno ambiente Private Cloud, di proprietà di UIRNet, che sarà allestito presso il CED del MIT da HP in qualità di Gestore Provvisorio PLN Contesto operativo La PLR è un complesso sistema formato non solo da software applicativo, ma da componenti hardware centralizzati (server) e periferici (OBU - On Board Unit). Questi ultimi sono dispositivi che, opportunamente installati e configurati all interno del mezzo di trasporto, consentono di avere informazioni esaustive sullo stato del mezzo stesso (posizione, velocità ed eventuale sensoristica di bordo). La PLR, per mezzo di un modulo specifico, è in grado di recepire tali informazioni ed elaborarle, utilizzandole per l erogazione dei servizi sottoscritti dall utente. Benché non tutti i servizi erogati dalla PLR abbiano necessità delle informazioni provenienti dalle OBU, queste rappresentano una componente fondamentale del Sistema. La PLR implementa l infrastruttura tecnologica di interoperabilità volta a consentire l integrazione dei sistemi territoriali coinvolti nella gestione della filiera logistica, siano essi ITS a valenza regionale o Sistemi di Gestione di Campo (PCS, Sistemi di Gestione degli Interporti e delle Piastre Logistiche, etc). La PLR svolge, dunque, il ruolo di coordinamento applicativo tra sistemi a titolarità distribuita presenti sul territorio (sistemi delle Autorità Portuali, degli Interporti e degli enti locali nonché di soggetti privati) e sistemi centrali rilevanti per la filiera logistica (PLN, sistemi dell Agenzia e delle Capitanerie di Porto), contribuendo alla creazione di un SOA Landscape collaborativo in cui il coordinamento informativo dei differenti sistemi applicativi contribuisce all arricchimento delle informazioni operative ed alla semplificazione dei processi logistici. Il Modulo IT Base che costituisce il nucleo centrale della PLR è operativo nel territorio pugliese. Pag 5 di 42

6 2 OGGETTO E CARATTERISTICHE DELL APPALTO L appalto oggetto di affidamento ha natura realizzativa e di erogazione di servizi. Alla prima categoria si ascrive la migrazione della PLR in apposito ambiente Private Cloud di proprietà UIRNet che sarà allestito presso il CED del MIT da HP in qualità di Gestore Provvisorio PLN Alla seconda tipologia appartiene la Gestione applicativa, operativa e sistemistica della PLR per 12 (dodici) mesi. Alle suddette finalità si affianca l erogazione dei servizi di installazione, gestione, manutenzione e disinstallazione degli apparati mobili (OBU e Smartphone). Schematizzando, l oggetto dell appalto comprende pertanto: a) Migrazione della PLR nell ambiente Private Cloud di UIRNet presso il CED del MIT; b) Gestione Applicativa: 1) Manutenzione Adeguativa e Correttiva (MAC); 2) Manutenzione Evolutiva (MEV); 3) Incident Management; 4) Monitoraggio e reportistica dei processi di business; c) Gestione Operativa e Sistemistica: 1) Gestione del software operativo; 2) Security Management; 3) Batch Job Management & Monitoring; 4) Account Management; 5) Backup e ripristino dei dati. d) Gestione degli apparati mobili; e) Affiancamento. Il dettaglio delle fasi realizzative e di erogazione dei singoli servizi è riportato nei successivi capitoli del presente documento. Per la descrizione dello stato corrente della PLN e con maggior dettaglio della PLR si rinvia, rispettivamente, all Allegato A Descrizione sintetica della Piattaforma Logistica Nazionale (di seguito Allegato A ) ed all Allegato B Descrizione dettagliata del Modulo IT Base (di seguito Allegato B ). Detti Allegati illustrano, per ciascuna Piattaforma, i seguenti argomenti fondamentali: Descrizione dei Servizi o dei Processi gestiti; Organizzazione del Service Management; Architettura applicativa; Dettaglio dei Moduli Applicativi. L Allegato B, inoltre, tratta: Infrastruttura Hardware attuale. Pag 6 di 42

7 3 MIGRAZIONE DELLA PLR NEL PRIVATE CLOUD DI UIRNET Il Fornitore dovrà realizzare la migrazione del Modulo IT Base nell ambiente Private Cloud di proprietà di UIRNet ed ubicato presso il CED (Centro Elaborazione Dati) del MIT nella sede di Via Giuseppe Caraci, 36 in Roma. L ambiente Private Cloud di UIRNet sarà gestito dal punto di vista sistemistico ad HP. Il Fornitore dovrà condurre, sotto la supervisione della Committente, tutte le attività propedeutiche e necessarie alla corretta installazione e configurazione del Modulo IT Base nel predetto ambiente. La Fase di migrazione dovrà concludersi tassativamente entro il 31 dicembre 2015 in considerazione della conclusione, a tale data, del contratto di gestione del Modulo IT Base in essere. Durante le attività di migrazione della PLR sul Private Cloud, e comunque entro il 31 dicembre 2015, il Fornitore avrà accesso alla documentazione prodotta nell ambito del progetto di realizzazione del Modulo IT Base (ivi inclusi i manuali di installazione d uso dei singoli moduli), al codice sorgente ed al supporto tecnico garantito dal Gestore uscente. Il Private Cloud di UIRNet ospiterà l ambiente di produzione della PLR Puglia, mentre sarà a carico del Fornitore la realizzazione, su un infrastruttura di sua titolarità, degli altri ambienti applicativi: Sviluppo (ambiente ridotto ad uso dei programmatori in fase di sviluppo software, MAC e MEV); Collaudo/test (ambiente ridotto per la verifica di conformità delle MAC e MEV). Nell ambito dell Offerta Tecnica il Concorrente dovrà presentare la descrizione dell infrastruttura dedicata a detti ambienti, nonché il dimensionamento degli stessi. Per quanto concerne l ambiente di sviluppo applicativo, UIRNet non ritiene di dover fornire indicazioni specifiche al Fornitore, fatta salva la disponibilità di un ambiente idoneo a garantire il rispetto degli impegni contrattuali per quanto concerne i processi di gestione della Manutenzione Adeguativa, Correttiva ed Evolutiva (MAC e MEV). In considerazione del particolare assetto applicativo della PLR, si ritiene, invece, necessario che l ambiente di collaudo rappresenti tutti gli aspetti di complessità dell ambiente di produzione e, pertanto, adotti i medesimi strumenti di ridondanza e alta affidabilità di quest ultimo al fine di consentire la significatività delle attività di verifica di conformità. L attività di migrazione include, inoltre, la presa in carico applicativa da parte del Fornitore il quale, al termine della stessa, dovrà essere in grado di gestire i processi di MAC e MEV, nonché quelli di release management come descritti nel seguito. Il tempo stimato per l attività di migrazione presso il Private Cloud di UIRNet è di 45 (quarantacinque) giorni. Di seguito si riporta l elenco delle Licenze Software di tipo perpetuo in possesso della Committente che saranno messe a disposizione per il nuovo ambiente da implementare a carico del Fornitore: iet Scadenza garanzia/sottoscrizione: perpetua Di seguito si riporta l elenco delle Licenze Software di tipo temporaneo, con le relative date di scadenza, che il Fornitore è tenuto a rinnovare per l intera duratacontrattuale della fase di gestione e comuqneu a far data dalla scadenza: Pag 7 di 42

8 Alfresco Enterprise Tipo Sottoscrizione: Alfresco One Enterprise (8 core) Data Sottoscrizione: 1/11/2014 Scadenza garanzia/sottoscrizione: 31/12/2015 Mule Enterprise Tipo Sottoscrizione: Mule Enterprise Production Data Sottoscrizione: 30/06/2014 Scadenza garanzia/sottoscrizione: 31/12/2015 Naviox Tipo Sottoscrizione: OpenXava Pro Data Sottoscrizione: 01/10/2014 Scadenza garanzia/sottoscrizione: 31/12/2015 Entando Tipo Sottoscrizione: Entando Enterprise Edition and Services Premium Data Sottoscrizione: 25/09/2014 Scadenza garanzia/sottoscrizione: 31/12/2015 Tutte le licenze e le sottoscrizioni dovranno essere intestate a UIRNet S.p.A. Al termine dell attività di migrazione il Fornitore dovrà produrre idonea documentazione atta a descrivere la configurazione dell ambiente di produzione, le politiche di sicurezza degli accessi e delle comunicazioni, le politiche di backup & restore dei dati e tutta la documentazione tecnica atta a conoscere l effettiva configurazione dell ambiente e le dipendenze logiche e fisiche (Documento di Esercizio del Sistema). Il Concorrente dovrà presentare nell ambito dell Offerta Tecnica il Piano di Migrazione, completo del cronoprogramma di dettaglio delle attività, indicando propedeuticità e milestone, nonchè l elenco delle risorse impegnate. Il Concorrente dovrà inoltre illustrare nel dettaglio gli strumenti tecnici deputati al Release Management con l obiettivo di realizzare un processo di Continuos Integration; ciò al fine di garantire una rapida ed efficace implementazione delle Change e una corretta gestione del ciclo di vita del software con particolare attenzione per gli strumenti di Quality Assurance. Pag 8 di 42

9 4 GESTIONE APPLICATIVA La gestione del Modulo IT Base dovrà essere garantita ininterrottamente per tutta la durata dell appalto. I servizi di gestione della PLR dovranno essere erogati in conformità al framework ITIL (acronimo di Information Technology Infrastructure Library) vers. 3, quale standard internazionale per la gestione dei processi di ITSM (Information Technology Service Management) ovverosia gestione dei servizi informatici. In particolare il Fornitore dovrà garantire i servizi di seguito descritti: Manutenzione Adeguativa e Correttiva (MAC); Manutenzione Evolutiva (MEV); Incident Management; Monitoraggio e reportistica dei processi di business. 4.1 Indicazioni qualitative per la gest ione dei servizi Per quanto riguarda la gestione dei servizi con specifico riferimento alle attività descritte nei capp. 4 e 5 - è obbligatorio rispettare i requisiti del framework internazionale ITIL v. 3. Esso ha l obiettivo di descrivere come gestire il ciclo di vita dei servizi ICT, al fine di migliorare la qualità dei servizi stessi nel rispetto degli obiettivi di costo e dei vincoli per essi concordati. A tal fine, il ciclo di vita si basa sui seguenti tre concetti fondamentali: il Valore, il Servizio, la Gestione del Servizio ( Service Management ). In ITIL v. 3 il Valore si articola, a sua volta, in due componenti viste dalla prospettiva del cliente: la sua utilità, o utility, e la sua garanzia, o warranty. L utilità è quanto il cliente riceve (ad esempio l accesso ad una applicazione aziendale), mentre la garanzia esprime le caratteristiche con cui il servizio è erogato (ad esempio l orario di disponibilità). Il Servizio è una modalità di erogare valore ai clienti (interni o esterni rispetto ad una organizzazione) che si esplica facilitando l ottenimento dei risultati che questi si prefigge con la riduzione dei rischi e/o dei costi rispetto al caso in cui il Servizio stesso fosse erogato dal cliente. La Gestione del Servizio o Service Management è un insieme di capabilities (abilità di un organizzazione, persona, processo, applicazione) specializzate che consentono di generare valore per il cliente sotto forma di servizi. Il ciclo di vita descrive ed analizza tutte le fasi di gestione dei servizi ICT, articolate in strategia (Service Strategy), progettazione (Service Design), transizione (Service Transition), erogazione (Service Operation) e miglioramento continuo (Continual Service Improvement). I processi di Information Technology Service Management in ITIL sono divisi in due aree principali: Service Support Service Delivery Nell'area di Service Support si identificano i seguenti processi: Incident management Problem Management Configuration Management Change Management Release Management Pag 9 di 42

10 coadiuvati dalla funzione di Service Desk, che nella realtà della PLR è costituita dall insieme delle strutture del Contact Center UIRNet, del Back Office UIRNet (BOU) e dell Help Desk di 2 livello che sarà erogato dal Fornitore. Nell'area di Service Delivery si identificano i seguenti processi: Service Level Management Financial Management for IT services Capacity Management IT Service Continuity Management Availability Management Figura 1 Rappresentazione Aree principali ITIL L obiettivo ultimo di ITIL v. 3 è, dunque, quello di offrire le migliori pratiche, best practice, per la gestione dei Servizi ICT. Tali pratiche consistono in principi, processi, suggerimenti organizzativi, indicazioni sulle tecnologie da adottare, e sono sviluppate e proposte per tutte le fasi del ciclo di vita dei Servizi ICT. 4.2 Manutenzione Adeguativa e Correttiva (MAC) Il processo di riferimento per il servizio MAC è il Problem Management (ITIL v.3), che descrive la metodologia di gestione per la risoluzione strutturata di problematiche che causano malfunzionamenti e/o modifiche e/o limiti funzionali del perimetro del Software (comunemente conosciuti come bug ). Il Concorrente, nell Offerta Tecnica, dovrà descrivere come intende implementare il processo, tenendo conto che: il processo deve avvenire con la costante supervisione della Committente; la priorità degli interventi deve essere stabilita di comune accordo con la Committente, in base alle esigenze di business; Pag 10 di 42

11 il Fornitore dovrà tracciare tutti gli interventi, dandone evidenza immediata alla Committente oltre a raggrupparli in apposito Status Report. Lo stesso dovrà essere consegnato, in maniera formale, alla Committente, con periodicità trimestrale. Il servizio di Problem Management (MAC) include: la Manutenzione Adeguativa, che comprende l attività di manutenzione volta ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell ambiente tecnologico del sistema informativo ed al cambiamento dei requisiti (organizzativi, normativi, d ambiente); la Manutenzione Correttiva, che comprende la diagnosi e la rimozione delle cause e degli effetti delle malfunzioni strutturali delle procedure e dei programmi. Gli obiettivi del servizio MAC sono così definiti: mantenere operativa la soluzione (software) attraverso attività che assicurino in via continuativa la rimozione delle malfunzioni strutturali; assicurare il miglioramento tempestivo delle funzionalità e/o prestazioni in caso di performance inadeguate al livello di servizio richiesto; garantire l evoluzione tecnico funzionale della soluzione software (Manutenzione Adeguativa), per esempio in caso di passaggio da un architettura client-server ad un architettura web-based; assicurare l aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell affidabilità e dell efficienza dei prodotti. La Committente durante lo svolgimento delle attività proprie del servizio, oltre alle verifiche sul raggiungimento degli SLA richiesti (cap ), può svolgere in qualsiasi momento ispezioni per valutare lo stato di completamento delle correzioni richieste e l andamento generale del servizio. La Committente, nella persona del Direttore dell Esecuzione del Contratto, nonché attraverso le sue strutture operative, tra le quali il Back Office UIRNet (nel seguito BOU ) e l Area Tecnica di UIRNet, verifica direttamente con il gruppo di lavoro del Fornitore: l adeguata rispondenza ai requisiti degli interventi correttivi; l effettivo rispetto delle priorità assegnate ai vari interventi correttivi; la pianificazione dei rilasci degli interventi correttivi. 4.3 Manutenzione Evolutiva (MEV) Il servizio di Manutenzione Evolutiva comprende gli interventi volti ad arricchire la PLR di nuove funzionalità o di altre caratteristiche non funzionali (quali, ad esempio, l usabilità, le prestazioni, ecc.) o, comunque, a modificare/integrare le funzionalità del sistema (software/hardware). Tale manutenzione implica la scrittura di funzioni aggiuntive d integrazione al sistema applicativo esistente o parti di funzioni (anche in sostituzione di altre già esistenti) di dimensione significativa e di cui è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze. Il costo totale per tale servizio è così stabilito nell ambito del presente appalto: in funzione delle specifiche competenze richieste per ciascun intervento viene determinato il corrispettivo della singola attività sulla base del numero di giorni/uomo per singola figura professionale. La valorizzazione dei giorni/uomo per singola figura professionale, definite nella seguente tabella, dovranno essere indicate in sede di Offerta Economica dal Concorrente: Pag 11 di 42

12 Figure professionali Analista funzionale Programmatore senior Programmatore junior Amministratore di data base Sistemista senior La Manutenzione Evolutiva è un servizio a consumo del quale UIRNet usufruirà nella misura in cui lo riterrà opportuno, senza alcun minimo garantito. I prezzi indicati in sede di Offerta Economica rimarranno invariati per l intera durata del contratto. L importo complessivo previsto per la MEV non potrà comunque essere superiore rispetto a quanto indicato nel Disciplinare di Gara Processo di erogazione del Servizio di MEV La realizzazione di un intervento di manutenzione evolutiva dovrà essere articolata nelle attività di seguito descritte. Analisi e stima dell intervento: richiesta di una modifica migliorativa o adeguamento ad un nuovo requisito del Sistema da parte di UIRNet; analisi da parte del Fornitore della fattibilità della richiesta; preventivo per la realizzazione dell intervento in termini di giorni/uomo per figura professionale e redazione della Scheda di Sintesi della MEV e della documentazione tecnica allegata a carico del Fornitore entro 10 (dieci) giorni lavorativi dalla richiesta da parte di UIRNet; approvazione dell attività da parte di UIRNet. Esecuzione dell intervento: realizzazione delle modifiche migliorative nei tempi previsti nella Scheda di Sintesi fermi restando i tempi indicati in Offerta Tecnica. Test di accettazione: verifica del funzionamento delle modifiche migliorative aggiuntive al sistema da parte di UIRNet. A valle dell analisi e stima dell intervento il Fornitore dovrà consegnare: Scheda di Sintesi della MEV: documento che descrive sinteticamente l intervento, gli effort richiesti e le tempistiche ipotizzate. Documentazione tecnica: documenti che descrivono il dettaglio dell intervento. Alla conclusione dell attività il Fornitore dovrà consegnare: Pag 12 di 42

13 Rendiconto Attività: documento che, in forma testuale, dovrà essere prodotto al termine di ogni intervento di manutenzione evolutiva e dovrà indicare: l elenco del personale impiegato con l indicazione del ruolo ricoperto; il dettaglio dei giorni impiegati da ciascuna risorsa per ogni attività svolta; Piano dei Test: documento che illustra i test di accettazione proposti dal Fornitore e i risultati dei test da esso effettuati; Aggiornamento della documentazione di Sistema da modificarsi in seguito all intervento. Per tutto quanto sviluppato in esecuzione delle sopradescritte attività di manutenzione il Fornitore garantisce la piena integrazione e la completa compatibilità tecnico funzionale con il software preesistente. Tutte le attività di manutenzione devono essere precedute, prima del rilascio in produzione, salvo espressa autorizzazione di UIRNet, da test di accettazione avvalendosi di apposito ambiente di test fornito dal Fornitore. Il Fornitore si impegna a mantenere l ambiente di test costantemente aggiornato rispetto all ambiente di produzione, in modo da consentire attendibili verifiche sulle attività espletate prima del loro rilascio in produzione. Le modifiche implementate saranno soggette a test di accettazione formale da parte della Committente, pertanto: a conclusione degli sviluppi il Fornitore dovrà trasmettere opportuna comunicazione a mezzo PEC della disponibilità ad effettuare i test di accettazione da parte della Committente, includendo una proposta per la norma di test e le relative schede, nonché la documentazione prevista alla conclusione dell attività; i test dovranno essere condotti in contradditorio tra il Fornitore e la Committente entro e non oltre 20 giorni lavorativi dal rilascio, tassativamente nell ambiente di Collaudo/Test; in caso di esito negativo dei test, il Fornitore avrà a disposizione 5 giorni lavorativi per risolvere le non conformità, superato tale termine saranno applicate le penali relative al mancato rispetto dei tempi di consegna (par ); in caso di esito positivo dei test, il Fornitore concorderà con la Committente le modalità di rilascio in produzione dei nuovi sviluppi. 4.4 Incident Management (rip ristino dei malfunzionamenti) Il Processo di Incident Management dovrà essere erogato dal Fornitore in osservanza di quanto definito nel framework ITIL v.3. Per malfunzionamento si intende (ITIL v.3) qualsiasi evento che non è parte del funzionamento standard di un servizio e che provoca, o può causare, un'interruzione o una riduzione della qualità del servizio. Tale evento nel framework ITIL v.3 prende il nome di Incident ed è gestito mediante la funzione di Service Desk, assolta da due distinte strutture: l Help Desk di 1 Livello, operato direttamente da UIRNet tramite il suo Contact Center. l Help Desk di 2 Livello, oggetto del presente servizio e operato dal Fornitore mediante un gruppo di lavoro dedicato. Il Concorrente, nell Offerta Tecnica, dovrà descrivere dettagliatamente come intende implementare il processo, tenendo conto che: l applicazione da utilizzare per il tracciamento dei malfunzionamenti è IeT Solutions Workcenter; tutti i malfunzionamenti devono essere qualificati attribuendo loro la criticità del caso, in base alla classificazione riportata nel par ; L apertura di un Incident coincide con la segnalazione del malfunzionamento (da parte a titolo meramente esemplificativo e non esaustivo del Fornitore, di UIRNet o dell utente), attraverso la creazione di un ticket Pag 13 di 42

14 nell applicazione di Trouble Ticketing IeT Solutions Workcenter, e si chiude al ripristino della funzionalità, ovverosia con la chiusura del ticket relativo. Solo qualora l applicativo IeT Solutions Workcenter sia afflitto da malfunzionamento si ha l apertura formale di un Incident senza corrispondente apertura del Ticket; in questo caso farà fede l invio di una da parte di UIRNet al Fornitore con comunicazione del suddetto malfunzionamento. Il Fornitore, alla risoluzione del malfunzionamento, si limiterà a porre il Ticket in stato sospeso ; UIRNet verificherà entro 2 giorni lavorativi quanto dichiarato e chiuderà o riassegnerà il Ticket in base alle evidenze del controllo. Qualora UIRNet non proceda alla verifica entro tale termine il ticket verrà considerato risolto e laddove si riscontrasse in seguito il suo perdurare verrà aperta una nuova segnalazione. In caso di verifica negativa (malfunzionamento non risolto), i tempi intercorsi dalla sospensione alla verifica verranno presi in considerazione ai fini del calcolo delle penali (cap ). Per consentire il corretto monitoraggio delle attività di ripristino in seguito alla segnalazione di un Incident il Fornitore è tenuto a registrare tempestivamente tutte le operazioni svolte per la sua risoluzione tramite lo strumento di Trouble Ticketing. Il Concorrrente dovrà indicare in sede di Offerta Tecnica la sua proposta per quanto concerne i tempi di presa in carico delle segnalazioni di Incident in funzione della tipologia di malfunzionamento (cap ). La presa in carico dell Incident dovrà essere attestata mediante registrazione sul sistema di gestione dei Ticket o, laddove questo stesso sia oggetto della segnalazione, mediante opportuna mail. La presa in carico non può essere espletata mediante strumenti automatici. Il Tempo di presa in carico dei malfunzionamenti deve essere compatibile con i tempi di risoluzione degli Incident indicati nel presente Capitolato Help Desk di 1 livello Il servizio di Help Desk di 1 livello, atto a fornire supporto agli utenti della PLR (di seguito Utente/i ), sarà erogato direttamente dal Contact Center di UIRNet. Tale struttura è preposta a: fornire assistenza e supporto operativo agli Utenti nello svolgimento delle attività inerenti quest ultima; ricevere segnalazioni di malfunzionamenti, gestendo con l Utente l acquisizione di tutte quelle informazioni utili alla Problem Determination ed, eventualmente, procedendo all attivazione di procedure guidate di ripristino sulla base delle specifiche fornite dall Help Desk di 2 livello nel caso di Incident presenti nella Knowledge Base o riconducibili a Problem già noti; attivare le funzioni dell Help Desk di 2 livello attraverso gli strumenti di Ticket Management a sua disposizione per consentire la risoluzione degli Incident segnalati non riconducibili a procedure guidate note; gestire le comunicazioni con gli Utenti a seguito della segnalazione degli Incident Help Desk di 2 Livello L Help Desk di 2 livello è erogato da un gruppo di lavoro del Fornitore cui viene assegnata la gestione dei malfunzionamenti tecnici del Modulo IT Base relativi alle segnalazioni che l Help Desk di 1 livello non è in grado di risolvere direttamente. L Help Desk di 2 livello dovrà essere erogato dalle ore 9:00 alle ore 18:00 dal Lunedì al Venerdì, esclusi i festivi. Compiti specifici dell Help Desk di 2 livello sono: gestione dei malfunzionamenti del software operativo (web ed application server, servizi di networking DNS, mail, etc); Pag 14 di 42

15 gestione dei malfunzionamenti del software applicativo come elencato nell Allegato B; gestione dei processi di Knowledge Management; monitoraggio sistemistico e applicativo. Il Concorrente dovrà descrivere nell Offerta Tecnica le modalità operative con cui vuole organizzare il servizio di Help Desk di 2 livello, nel rispetto delle specifiche e dei requisiti minimi indicati nel presente Capitolato, indicando, in particolare, i tempi di presa in carico delle chiamate da parte dello stesso, le dotazioni hardware-software messe a disposizione degli operatori e soluzioni applicative deputate alla rilevazione ed alla gestione della reportistica relativa all andamento del servizio. In tale sede il Concorrente dovrà descrivere opportunamente: i gruppi di lavoro con dettaglio delle competenze e ruolo di ogni componente; eventuali ingaggi dei gruppi di lavoro in attività differenti (ad esempio MAC e/o MEV); le politiche atte a garantire l intercambiabilità delle persone appartenenti ai gruppi di lavoro, promuovendo sessioni di formazione sia intragruppo che con UIRNet; le politiche atte a minimizzare il turn over delle risorse. Le modalità di interazione del gruppo di lavoro di Help desk di 2 livello con la Committente, con priorità eventualmente ridefinite dal Service Manager di UIRNet in funzione degli obiettivi di business, dovranno tenere conto della descrizione dei processi ricadenti nel Service Management per come definiti nell ambito del framework ITIL v Tipologie di malfunzionamenti Si definiscono tre tipologie di malfunzionamenti a criticità decrescente, C1, C2 e C3, con C1 pari, quindi, alla criticità più elevata. La classificazione suddetta si applica in funzione delle possibili combinazioni tra impatto sull operatività e impatto sul business specifici di ciascun malfunzionamento, come di seguito descritto. Preliminarmente, in merito all impatto sull operatività, il singolo malfunzionamento si distingue in: Bloccante: evento che comporta un grave deterioramento nelle funzionalità del Software/Hardware, tale da non permettere agli utenti di proseguire nella loro attività. Grave: Lieve: evento che comporta un serio deterioramento nelle funzionalità, ma consente comunque di proseguire le operazioni. evento che non necessita di intervento urgente in quanto causa un degrado di prestazioni tollerabile per periodi limitati. In merito all impatto sul business, il singolo malfunzionamento si distingue in: Alto: Medio: Basso: il malfunzionamento riguarda i servizi a valore aggiunto (funzionalità mission critical, v. Allegato B, cap. 2.2) o determina un deterioramento funzionale e/o prestazionale dell intero Modulo IT Base. il malfunzionamento riguarda l operatività di sistemi o componenti che non precludono, sebbene limitino, le funzionalità mission critical. il malfunzionamento non ricade nella casistica con impatto di business alto o medio. Dai possibili incroci delle precedenti tassonomie, si ottengono i valori di criticità, come riportato nella tabella seguente: Tabella 1 Classifica criticità dei malfunzionamenti Pag 15 di 42

16 Business Operatività Bloccante Grave Lieve Alto C1 C1 C2 Medio C2 C2 C3 Basso C2 C3 C3 In funzione del valore di criticità di ciascun malfunzionamento, sono definiti i corrispondenti SLA che il Fornitore deve garantire e le relative penali (cap ). 4.5 Monitoraggio e reportistica dei processi di business Il sistema Modulo IT Base è dotato di un set di funzionalità e relative interfacce-utente atte ad effettuare un monitoraggio continuo e automatico sui processi di business, al fine di controllare ed assicurare l'usabilità e la disponibilità del sistema stesso. Tramite le suddette funzionalità è possibile identificare automaticamente condizioni di failure nell'utilizzo di un qualsiasi sottoprocesso e/o servizio e/o infrastruttura di sistema al fine di generare un allarme e/o una azione correttiva di contingency che consenta di limitare al massimo l'indisponibilità del processo complessivo. Le funzionalità di reportistica sono volte ad ottenere parametri, opportunamente definiti e calcolati, in grado di supportare scelte strategiche relative all aggregazione ed alla composizione dell offerta dei servizi disponibili. Per la descrizione dettagliata del sistema Modulo IT Base, come riportato nel precedente paragrafo 2, si dovrà far riferimento all Allegato B Descrizione dettagliata del modulo IT Base. Detto Allegato illustra i seguenti argomenti fondamentali: Descrizione dei Servizi Applicativi erogati; Descrizione dei Processi e struttura del Service Management; Dettaglio dei Moduli Applicativi. Le modalità ed i parametri indicanti l utilizzo sono preventivamente concordati da UIRNet con il provider di servizi, e saranno in ogni caso riferiti esclusivamente a dati ed informazioni di carattere operativo. Il monitoraggio avverrà mediante l analisi di varie grandezze di sistema a partire dalle quali verranno poi calcolati gli indicatori. Le principali funzionalità di monitoraggio e reportistica sono elencate come segue: Capacità di interrogazione del Workflow registry per l'acquisizione dei dati inerenti i servizi: tali dati potranno essere utilizzati a scopo statistico, di ricerca e di analisi; Funzionalità per il monitoraggio dell utilizzo di sistema, in termini di transazioni registrate da ESB e di risorse, secondo le seguenti distinzioni: a. servizi offerti dai diversi moduli; b. servizi offerti da sistemi esterni; c. servizi offerti ad utenti/enti utilizzatori finali; Funzionalità per la definizione, a livello di configurazione, nonché per l estrazione run-time di indicatori relativi a: a. utilizzo del sistema e dei servizi; Pag 16 di 42

17 b. livelli di servizio offerti (disponibilità dei servizi); c. qualità. La Committente e/o gli Utenti, previamente autorizzati dalla Committente medesima, potranno richiedere attività a carattere di urgenza, quali - a titolo di esempio non esaustivo - l elaborazione di report straordinari, che non verranno prese in considerazione per quanto attiene al calcolo degli SLA; la tempistica di esecuzione di tali attività sarà condivisa con il Responsabile del servizio lato Fornitore, e comunque tali richieste non potranno essere maggiori di 5 (cinque) nella giornata lavorativa e potranno essere eseguite solo tramite l utilizzo di procedure certificate ed accettate. Ai fini della verifica e misurazione della qualità del servizio offerto, per la definizione degli SLA da rispettare in merito al monitoraggio sui processi di business al fine di controllare ed assicurare l'usabilità e la disponibilità del sistema si rimanda al par con riferimento alla Disponibilità del Modulo IT Base ; in merito alle richieste di dati, informazioni, indicatori e report si rimanda al paragrafo SLA E PENALI, par. SLA a Verifica Periodica con riferimento allo SLA SREQ (par ). Pag 17 di 42

18 5 GESTIONE OPERATIVA E SISTEMISTICA La gestione dell infrastruttura ospitante è a carico di HP in qualità di Gestore Provvisorio PLN Su tale base le attività di configurazione e gestione del Networking e delle macchine virtuali, inclusi i sistemi operativi, è competenza di HP con cui il Fornitore dovrà interfacciarsi per la definizione delle procedure operative e di gestione. Per l intera durata dell appalto il Fornitore deve garantire le seguenti attività: Gestione del software operativo: aggiornamento e amministrazione del software generalmente di terzi, deputato all operatività della Piattaforma (Web Server, Application Server, Data Base, ecc.), con l esclusione dei sistemi operativi di base, garantendo l aderenza alle specifiche descritte dal produttore, la corretta configurazione e l ottimizzazione in relazione alle particolarità del Modulo IT Base, nonché la corretta gestione di tutti gli aspetti inerenti la sicurezza, quali - a mero titolo di esempio non esaustivo - l applicazione delle patch, la definizione e l adozione delle policy, ecc. Security Management: procedure di sicurezza atte a prevenire accessi non autorizzati, sia volontari che accidentali, sia ai programmi che ai dati, al fine di assicurare i seguenti requisiti: o o o o o identificazione ed autenticazione: verifica dell identità allo scopo di prevenire accessi non autorizzati al sistema e alle risorse di rete: autorizzazione: controlla quale sistema, informazione e applicazione può essere data ad un utente; integrità: assicura sia che i dati presenti negli archivi sia quelli che transitano sulla rete non vengano cambiati o compromessi da manipolazioni non autorizzate; riservatezza: intesa come prevenzione dell utilizzo indebito delle informazioni. Tale requisito presuppone che l accesso alle informazioni venga controllato attraverso adeguate misure di protezione; protezione della privacy previene la lettura di dati privati da parte di utenti non autorizzati. Batch Job Management & Monitoring: gestione dei processi pianificati (inserimento, modifica, sospensione e riattivazione, nonché cancellazione degli stessi) e controllo dei servizi batch e di trattamento dell output, assicurando il rispetto della pianificazione e delle procedure di gestione dei sistemi e di l allineamento dei dati: le procedure di allineamento massivo dei dati dovranno essere realizzate a valle di una richiesta formale da parte della Committente, secondo la procedura prevista per la MEV, e essere poste in esercizio a valle di tutti i test previsti; Account Management: creazione, gestione e manutenzione degli account relativi ai server con controllo delle politiche di accesso ad essi collegati e la loro organizzazione e strutturazione in gruppi e contesti. Backup e ripristino dei dati: implementazione e gestione delle procedure di backup e ripristino dei dati che si intende attuare per raggiungere un tempo previsto per il ripristino delle funzionalità interrotte e la quantità di lavoro e dati persi. Tali attività saranno materialmente svolte dal Gestore Provvisorio PLN 2015, secondo le modalità definite dal Concorrente nell ambito dell Offerta Tecnica. Il Concorrente dovrà indicare in dettaglio in sede di Offerta Tecnica i processi di gestione del Software Operativo con particolare attenzione ai tempi di rilascio in produzione di patch ed enhancement, i flussi di comunicazione con le strutture UIRNet ed i tempi di presa in carico relativi alla gestione degli incident correlati con la Gestione Operativa e Sistemistica, le procedure di sicurezza adottate e le procedure di salvataggio e ripristino dei dati. Pag 18 di 42

19 Ai fini della valutazione delle attività sopra indicate il Concorrente dovrà tenere in considerazione l attuale implementazione della PLR come descritta nell Allegato B. La Committente e/o gli Utenti, previamente autorizzati dalla Committente medesima, potranno richiedere attività a carattere di urgenza, quali - a titolo di esempio non esaustivo - l export, l import e la trasformazione di dati, che non verranno prese in considerazione per quanto attiene al calcolo degli SLA; la tempistica di esecuzione di tali attività sarà condivisa con il Responsabile del servizio lato Fornitore, e comunque tali richieste non potranno essere maggiori di 5 (cinque) nella giornata lavorativa, e potranno essere eseguite solo tramite l utilizzo di procedure certificate ed accettate. Ai fini della verifica e misurazione della qualità del servizio offerto, per gli SLA da rispettare in merito alle richieste di attività (service requests), si rimanda al paragrafo SLA E PENALI, SLA a Verifica Periodica (par ) con riferimento rispettivamente ai seguenti SLA: SREQ-JS; SREQ-JC; SREQ-AM. Per le specifiche dei tempi di ripristino e della quantità di dati si rimanda al paragrafo SLA E PENALI, SLA a Verifica Periodica (par ) con riferimento al Ripristino del Modulo IT Base. Pag 19 di 42

20 6 GESTIONE DEGLI APPARATI MOBILI Il servizio ha per oggetto le attività di immagazzinamento, gestione e manutenzione dei seguenti apparati mobili: On Board Unit (OBU): dispositivi di tracciamento Teltonik 5300 (250 unità complessive); Smartphone: cellulari Android Huawey Ascend P7 (50 unità complessive); le cui caratteristiche tecniche sono riportate nell Allegato B. Il servizio, per quanto riguarda le OBU, comprende: la gestione e la manutenzione delle circa 25 OBU installate alla data di pubblicazione del Bando di gara ed in uso presso gli Utenti; l installazione delle OBU nella disponibilità di UIRNet fino ad un massimo di 250 unità complessive; la disinstallazione ed il decommissioning delle OBU fino ad un massimo di 250 unità complessive. Per quanto concerne gli Smartphone, il servizio prevede: la gestione e la manutenzione dei circa 9 Smartphone in dotazione agli Utenti alla data di pubblicazione del Bando di gara; la configurazione e la consegna degli Smartphone nella disponibilità di UIRNet fino ad un massimo di 50 unità complessive; il ritiro ed il decommissioning degli Smartphone fino ad un massimo di 50 unità complessive. La gestione include tutti gli aspetti amministrativi, logistici e tecnici, compresa l organizzazione delle attività di installazione con l Utente e la gestione dei malfunzionamenti. Tutte le attività verranno richieste attraverso l apertura di apposito ticket sul sistema di Trouble Ticketing presente nella PLR. Nell Offerta Economica il Concorrente dovrà indicare i costi delle attività di installazione e disinstallazione per ciascuna tipologia di apparato mobile che saranno da intendersi come attività a consumo, mentre le attività di gestione ed amministrazione degli apparati mobili, nonché di manutenzione, andranno valorizzate nella forma di un canone mensile per ciascun dispositivo attivo. I massimali per ciascuna attività sono indicati nel Disciplinare di Gara Installazione/disinstallazione degli Apparati Mobili L attività viene avviata da UIRNet su richiesta degli Utenti per attivare i servizi di tracciamento ed i servizi evoluti al conducente. Il servizio dovrà essere svolto sull intero territorio pugliese dal lunedì al sabato. Nell Offerta Tecnica il Concorrente dovrà descrivere come intende organizzare le attività, tenendo conto delle seguenti indicazioni sia per quanto concerne le OBU che gli Smartphone: le installazioni delle OBU devono avvenire entro e non oltre 10 (dieci) giorni lavorativi dalla richiesta effettuata da UIRNet (a meno di indisponibilità dei mezzi da tracciare); Pag 20 di 42

21 la preparazione e l invio degli Smartphone devono avvenire entro e non oltre 10 (dieci) giorni lavorativi dalla richiesta effettuata da UIRNet; le disinstallazioni ed il ritiro delle OBU e degli Smartphone deve avvenire entro e non oltre 20 (venti) giorni lavorativi dalla richiesta effettuata da UIRNet; il Fornitore deve organizzarsi con strutture idonee allo stoccaggio delle OBU e degli Smartphone che gli verranno consegnati da UIRNet; il Fornitore deve mettere a disposizione strumenti che diano evidenza a UIRNet delle giacenze di magazzino in tempo reale; la OBU e lo Smartphone si intendeno installati quando ne sia stato testato il funzionamento, ovverosia il corretto invio delle posizioni del mezzo alla PLR; il Fornitore deve produrre attestazione relativamente all intervento effettuato entro e non oltre 3 (tre) giorni lavorativi dallo stesso. Il Concorrente potrà formulare in sede di Offerta Tecnica proposte migliorative con riferimento ai tempi sopra indicati. Il Fornitore dovrà indicare in sede di Offerta Tecnica la quantità massima di interventi contemporanei erogabili, la capillarità delle officine tecniche sul territorio pugliese e le finestre di operatività del servizio Gestione ed amministrazione degli Apparati Mobili Il Fornitore deve garantire l amministrazione, ovverosia il cambio dei parametri di configurazione delle OBU o degli Smartphone e la gestione del software ivi installato, effettuando gli aggiornamenti secondo i rilasci del Produttore del dispositivo. Tale attività dovrà essere svolta in remoto in modalità trasparente per l utente finale e, quindi, senza interruzioni del servizio Gestione dei Malfunzionamenti degli Apparati Mobili Qualora una OBU o uno Smartphone fosse soggetta a malfunzionamenti, il Fornitore sarà chiamato a provvedere alla riparazione del dispositivo e ove non fosse possibile - alla sostituzione dello stesso, ovverosia alla disinstallazione dell apparto mobile guasto e alla installazione del nuovo apparato mobile, la cui fornitura resta a carico della Committente. La risoluzione dei malfunzionamenti deve avvenire nel tempo limite di 10 (dieci) giorni lavorativi dall apertura della segnalazione di guasto, certificata dall inserimento del ticket nel sistema di Trouble Ticketing. Qualora non fosse possibile ripristinare il dispositivo, questo dovrà essere sostituito entro e non oltre ulteriori 5 (cinque) giorni lavorativi. Pag 21 di 42

22 7 ORGANIZZAZIONE E FIGURE PROFESSIONALI 7.1 Organizzazione La data di inizio delle attività coinciderà con la sottoscrizione del verbale di avvio dell esecuzione del contratto. UIRNet nominerà un Direttore dell Esecuzione del Contratto ed istituirà un eventuale tavolo di Steering Committee per supportare la corretta esecuzione del Project Management, in presenza di snodi strategici e/o critici relativi alla gestione del presente appalto. Il Fornitore ha la responsabilità dell intero appalto e nominerà un Project Manager (che sarà anche il Responsabile del Contratto per il Fornitore), un Service Manager per l erogazione dei servizi richiesti ed un Esperto di processi e architetture telematiche nell ambito di trasporti e logistica (capp. 3, 4, 5 e 6). È facoltà del Fornitore concentrare i ruoli di Project Manager e di Service Manager in un unica risorsa purché sia indicato nell Offerta Tecnica e nel rispetto dei requisiti minimi di esperienza e competenza di seguito indicati (cap. 7.2). Per la gestione dell intero appalto sarà costituita una struttura di coordinamento secondo lo schema riportato di seguito: Figura 2 Struttura di coordinamento Pag 22 di 42