CAPITOLATO TECNICO - Istituto Italiano di Tecnologia · Pianificazione del progetto ......

1 CAPITOLATO TECNICO

CAPITOLATO TECNICO

Gara a procedura aperta per l’acquisizione dei servizi di implementazione, avviamento e

gestione del sistema ERP della Fondazione Istituto Italiano di Tecnologia


Sommario Glossario ....................................................................................................................................................... 4

1. Strategia di evoluzione del sistema informativo della Fondazione IIT ....................................... 6

1.1. Obiettivi generali dell’iniziativa ......................................................................................................... 6

1.2. La strategia ICT aziendale .................................................................................................................. 6

2. Descrizione della fornitura ........................................................................................................... 9

2.1. Oggetto .............................................................................................................................................. 9

2.2. Durata .............................................................................................................................................. 10

2.3. Organizzazione temporale della fornitura ....................................................................................... 10

2.4. Infrastrutture e licenze .................................................................................................................... 11

3. Requisiti non funzionali .............................................................................................................. 11

3.1. Unicità, tracciabilità e storicizzazione di dati e documenti ............................................................. 12

3.2. Sicurezza, privacy e gestione utenti ................................................................................................ 13

3.3. Integrazione, interoperabilità, aderenza agli standard ................................................................... 14

3.4. Accessibilità e usabilità .................................................................................................................... 15

4. Requisiti funzionali ..................................................................................................................... 15

5. Gestione del progetto ................................................................................................................. 16

5.1. Organizzazione del progetto ........................................................................................................... 16

5.2. Tempistiche di progetto .................................................................................................................. 20

5.3. Pianificazione del progetto .............................................................................................................. 23

5.4. Funzioni di gestione del progetto .................................................................................................... 24

5.5. Profili e risorse del progetto ............................................................................................................ 26

6. Caratteristiche dei servizi professionali richiesti per l’attivazione del sistema ERP-SAP ......... 29

6.1. Progettazione della nuova configurazione tecnologico-organizzativa ............................................ 29

6.2. Supporto alla razionalizzazione delle anagrafiche aziendali ........................................................... 30

6.3. Installazione, configurazione, implementazione, sviluppo di eventuali personalizzazioni e messa in esercizio ....................................................................................................................................................... 31

6.4. Recupero dello storico di dati e documenti .................................................................................... 32

6.5. Addestramento e training ............................................................................................................... 32

6.6. Realizzazione interfacce e interoperabilità con sistemi di terze parti............................................. 34

7. Gestione operativa del servizio .................................................................................................. 35

7.1. Manutenzione applicativa generale ................................................................................................ 36

7.2. Manutenzione evolutiva .................................................................................................................. 40


7.3. Assistenza applicativa on-site o da remoto ..................................................................................... 41

7.4. Exit Management ............................................................................................................................ 42

8. Verifica di conformità e garanzia ............................................................................................... 44

9. Documentazione tecnica da produrre in fase di gara ................................................................ 46

10. Allegati ........................................................................................................................................ 46


GLOSSARIO

Definizione Significato Descrizione

IIT o Fondazione

Fondazione Istituto Italiano di Tecnologia

La Fondazione Istituto Italiano di Tecnologia è stata istituita con il decreto-legge 30 settembre 2003, n. 269, convertito, con modificazioni, dalla legge 24 novembre 2003, n.326, con lo scopo di promuovere lo sviluppo tecnologico del paese e l’alta formazione tecnologica, favorendo così lo sviluppo del sistema produttivo nazionale.

ERP Enterprise Resource Planning

Suite di applicativi a supporto dei processi amministrativi, finanziari, contabili, di acquisto,di gestione risorse umane, delle vendite, della gestione ordini cliente e gestione delle operations, basato su tre cardini fondamentali: unicità dei dati, estensione e modularità, prescrittività.

SII Sistema Informativo Integrato

S’intende il sistema Informativo complessivo di IIT all’interno del quale dovrà collocarsi il sistema ERP-SAP

Aggiudicatario Soggetto con il quale sarà concluso il contratto per l’acquisizione dei servizi oggetto della gara

Proponente Soggetto che presenta la propria offerta nell’ambito dei servizi richiesti dalla gara, affinché venga valutata dalla commissione

Three-tier Architettura a tre livelli Architettura software che prevede la suddivisione del sistema in tre diversi moduli dedicati rispettivamente alla interfaccia utente, alla logica funzionale, e alla gestione dei dati persistenti. Ciascun modulo è indipendente dagli altri per qualsiasi modifica venga svolta sul singolo


Workaround Momentanea risoluzione di un problema al fine di ripristinare il servizio, ma non rappresenta la soluzione alla causa principale del problema

BIG BANG Definisce un tipo di modalità adottabile per il passaggio dal sistema precedente al nuovo sistema. Nello specifico prevede il passaggio alle funzioni del nuovo sistema “tutto insieme e allo stesso tempo”

GO LIVE Il go live coincide con la messa in esercizio del sistema ERP. Dal go live si avvia un periodo di osservazione sul sistema pari a 30 giorni, funzionale a monitorare la qualità della soluzione sul sistema di produzione

BPMN Business Process Modeling Notation


1. STRATEGIA DI EVOLUZIONE DEL SISTEMA INFORMATIVO DELLA FONDAZIONE IIT

1.1. Obiettivi generali dell’iniziativa

La Fondazione Istituto Italiano di Tecnologia, nel seguito, per brevità, Fondazione, ha deciso di rinnovare il proprio sistema informativo, finalizzato a favorire la gestione per processi basata sull’integrazione e la tracciabilità delle informazioni e sulla condivisione di dati ed informazioni come supporto alle decisioni strategiche e direzionali.

La Fondazione vuole, in sintesi, perseguire i seguenti obiettivi strategici: Riorganizzare i propri processi di lavoro attraverso la reingegnerizzazione dei flussi

di comunicazione al fine di attuare lo snellimento dei flussi informativi e garantire una gestione più efficiente ed efficace dei processi amministrativi e gestionali interni;

Migliorare gli strumenti di controllo e di monitoraggio a supporto dei processi decisionali sia strategici che di coordinamento operativo;

Armonizzare il patrimonio applicativo in essere, abbattendo i limiti di integrazione ed interoperabilità ad oggi presenti.

In tale prospettiva la Fondazione intende utilizzare il sistema informativo come leva di cambiamento, facendo coincidere la riprogettazione del sistema informativo con una ottimizzazione dei processi organizzativi interni. Questo permetterà al sistema informativo di diventare un supporto diretto alla strategia della Fondazione e un essenziale sostegno a tutte le altre attività e processi della catena del valore, siano esse attività di tipo primario o di supporto.

Per supportare questo percorso di sviluppo, la Fondazione intende rivedere ed estendere l’intero sistema informativo al fine di realizzare un unico Sistema Informativo Integrato (SII). A tal proposito, il primo passo è stata la scelta della soluzione tecnologica adatta a supportare adeguatamente i processi amministrativi, gestionali, direzionali della Fondazione, così come i processi primari dell’attività scientifica che caratterizza la Fondazione.

La Fondazione ha adottato la soluzione ERP-SAP, su cui i servizi oggetto del presente capitolato dovranno basarsi. Per sistema ERP-SAP Amministrativo-Gestionale integrato si intende il complesso delle componenti di dati e di quelle applicative ed infrastrutturali necessarie alla messa in esercizio dei requisiti funzionali, così come descritti all’allegato 7, e dei requisiti non funzionali meglio descritti al capitolo 3.

1.2. La strategia ICT della Fondazione

Il sistema informativo attualmente in uso presso la Fondazione risulta costituito da un insieme di applicativi acquisiti o implementati nell’ambito di iniziative gestite a livello di singola unità funzionale per soddisfare specifiche esigenze di business. Ne risulta uno scenario applicativo vasto ed eterogeneo, in cui i componenti applicativi del sistema


informativo sono cresciuti per aggiunte successive, raggiungendo una buona copertura dei processi di business, ma con “isole applicative” parzialmente integrate (“silos” applicativi), sia dal punto di vista dei dati (banche dati replicate) che dal punto di vista dei flussi di lavoro (assenza di workflow e di logiche per l’orchestrazione dei processi di business) (v. Allegato 1-Contesto della Fondazione IIT).

La Fondazione ha pertanto intrapreso un percorso finalizzato all’evoluzione dell’attuale sistema informativo verso un Sistema Informativo Integrato (nel seguito SII). La progettazione e la realizzazione del SII sono ispirate ai seguenti paradigmi di integrazione:

messa a fattor comune di dati e informazioni, eliminando ridondanze e duplicazioni;

creazione di flussi di lavoro (workflow) interfunzionali;

messa a fattor comune di funzionalità e componenti infrastrutturali per conseguire una maggior efficienza nell’evoluzione del SII e incrementarne la capacità di governance complessiva.

Per la realizzazione del SII sono stati individuati dalla Fondazione tre livelli di intervento:

Evoluzione dell’organizzazione e dei processi: è stata svolta dalla Fondazione un’attenta analisi dei processi principali che caratterizzano l’attività della Fondazione, sia primari che di supporto. L’output consiste in un documento che descrive i legami e le interazioni che occorrono tra macro aree di processo, fornendo un primo schema concettuale e di sintesi di tutta l’attività caratterizzante la Fondazione. L’analisi è stata completata con la progettazione di alcuni workflow specifici che la Fondazione intende implementare nel nuovo sistema.

Realizzazione di un cruscotto per il controllo e il monitoraggio: al fine di estendere il supporto ai processi decisionali direzionali e strategici la Fondazione ha progettato un sistema di indicatori (KPI), per le prestazioni ritenute rilevanti, per i quali sono state definite la metrica e le fonti di riferimento per la valorizzazione delle metriche (v. Allegato 3 - Lista dei KPI). La progettazione è finalizzata alla realizzazione del cruscotto direzionale all’interno del nuovo sistema.

Architettura logica di riferimento del sistema informativo: per il Sistema Informativo Integrato (SII) la Fondazione ha definito e progettato un’architettura logica applicativa, alla quale le prossime implementazioni di soluzioni dovranno riferirsi. L’architettura, di cui nel seguito si riporta una descrizione di maggiore dettaglio, è stata pensata affinché siano garantite le caratteristiche di integrazione, modularità, scalabilità ed interoperabilità nel nuovo SII.

L’architettura logica a tendere è così strutturata (v. figura 1):

Alla base vi è il patrimonio informativo integrato, che rappresenta l’insieme delle informazioni e dei dati gestiti nel SII. Il patrimonio informativo integrato è costituito e alimentato dai dati gestiti dalle diverse funzionalità del livello applicativo e si deve, a livello logico, considerare come un insieme unico di dati correlati e integrati tra loro


a disposizione dell’intero SII, con logiche di gestione del dato che ne garantiscano l’unicità.

Il livello dei servizi infrastrutturali è costituito da quei servizi trasversali necessari ad esempio per una corretta gestione degli accessi o per abilitare logiche di integrazione.

Nei servizi di piattaforma sono raggruppati servizi e funzionalità “orizzontali” necessarie al funzionamento dei servizi applicativi. Tali funzionalità, anziché essere implementate all’interno di ciascun servizio applicativo, sono messe logicamente a fattor comune nel modello per poter essere a disposizione di qualsiasi componente previsto per l’espletamento di specifiche funzioni applicative. A questo livello si collocano funzionalità di gestione documentale, sistemi di alert e notifiche, sistema di gestione dei workflow, motore di ricerca e le funzionalità di portale in modalità di Content Management System.

I servizi applicativi raggruppano tutte le funzionalità “verticali”, ossia implementano la specifica logica di business necessaria per l’esecuzione delle funzionalità che supportano la singola area di business della Fondazione.

Il livello di presentazione rappresenta lo strato di accesso da parte degli utenti finali IIT ai servizi richiamabili. L’accesso avviene tramite l’utilizzo del portale e di viste, ovvero a tale livello sono definite e gestite le modalità di accesso standard dell’utente finale alle funzionalità offerte dal SII. Anche in questo caso si tratta di interfacce web, accessibili tramite browser web, specializzate per funzionalità e per tipologia di utente attraverso le quali l’utente può interagire con le componenti applicative e/o richiamare servizi di piattaforma.

Figura 1 - Architettura logica generale


2. DESCRIZIONE DELLA FORNITURA

2.1. Oggetto

La fornitura ha come oggetto l’acquisto di servizi per la realizzazione, la messa in esercizio e la gestione operativa di un sistema ERP-SAP a supporto dei processi amministrativo – gestionali della Fondazione.

Nello specifico la fornitura dovrà comprendere:

a) un servizio di gestione del progetto in supporto alla funzione ICT della Fondazione per tutta la durata contrattuale prevista così come indicato nel Capitolo 5;

b) servizi professionali funzionali alla realizzazione del nuovo sistema ERP:

Progettazione della nuova configurazione tecnologico-organizzativa per il sistema informativo integrato della Fondazione. Tale servizio dovrà prevedere il completamento dell’analisi dei requisiti già svolta all’interno della Fondazione nell’ambito delle logiche di funzionamento amministrativo-gestionali, che dovrà essere opportunamente rielaborata e resa idonea allo scopo, anche attraverso l’utilizzo di strumenti di BPMN. Una più estesa descrizione del servizio atteso è riportata al paragrafo 6.1.

Supporto alla razionalizzazione delle anagrafiche aziendali per quanto riguarda le entità attualmente gestiste dai differenti sistemi applicativi e che in parte saranno sostituiti dal sistema ERP, oltre che di quelle che si renderanno necessarie per il soddisfacimento dei requisiti descritti nell’Allegato 7. Le entità informative da gestire sono esemplificate nell’Allegato 2-Lista entità. L’anagrafica aziendale progettata dovrà essere strutturata anche ai fini della generazione di un cruscotto direzionale in grado di gestire informazioni aggregate di sintesi, le cui fonti possono riferirsi al sistema ERP-SAP così come a sistemi di terze parti. A tal proposito si faccia riferimento all’Allegato 3-Lista dei KPI. Una più estesa descrizione del servizio atteso è riportata nel paragrafo 6.2.

Installazione, configurazione, implementazione, sviluppo di eventuali personalizzazioni e messa in esercizio del sistema ERP-SAP in tutta la realtà della Fondazione; con ciò si intende la parametrizzazione del sistema ERP-SAP o l’eventuale adeguamento delle funzionalità standard offerte dal sistema alle caratteristiche organizzative ed alle esigenze di funzionamento della Fondazione in accordo con le risultanze dell’analisi di cui al primo punto. Una più estesa descrizione del servizio atteso è riportata al paragrafo 6.3.

Recupero dello storico di dati e documenti presenti attualmente nelle diverse applicazioni che costituiscono l’attuale sistema informativo aziendale e che saranno oggetto di sostituzione con l’implementazione del sistema ERP-SAP. Una più estesa descrizione del servizio atteso è riportata al paragrafo 6.4.


Addestramento e training, pre e post avvio in esercizio del sistema, a tutti gli utenti ERP-SAP della Fondazione per garantire la normale attività operativa. Si richiede che l’addestramento sia rivolto sia ai key user, che dovranno essere in grado a loro volta di supportare gli altri utilizzatori finali nelle prime fasi di utilizzo del sistema, sia a tutti gli utilizzatori della Fondazione e agli amministratori del sistema. I gruppi di utenti saranno da definire in sede di progetto e dovranno prevedere anche gruppi di utenti dislocati fuori dalla sede centrale della Fondazione. Una più estesa descrizione del servizio atteso è riportata al paragrafo 6.5.

Realizzazione interfacce e interoperabilità con sistemi di terze parti, già presenti ed in uso presso la Fondazione, per le quali non è prevista la sostituzione anche a seguito dell’implementazione del sistema ERP-SAP. Una più estesa descrizione del servizio atteso è riportata al paragrafo 6.6.

c) servizi professionali funzionali alla gestione operativa del nuovo sistema ERP-SAP, meglio descritti nel capitolo 7:

Manutenzione (preventiva, correttiva, adattativa ed evolutiva) Assistenza applicativa on site e da remoto

2.2. Durata

La durata contrattuale è pari a 33 mesi, di cui 27 mesi per l’esecuzione delle prestazioni relative alle Fase A, Fase B, Fase C e Fase D, come puntualmente descritte nel successivo paragrafo 5.2, e successivi 6 mesi relativi al periodo di garanzia.

2.3. Organizzazione temporale della fornitura

Per rispettare le priorità organizzative della Fondazione si richiede venga prevista la messa in esercizio di tutti i requisiti fondamentali indicati in tabella A dell’Allegato 7 (FASE A), in modalità “Big Bang”, e successivamente la messa in esercizio dei requisiti funzionali che estendono specifiche aree funzionali del sistema ERP-SAP implementato e descritti in tabella B dell’allegato 7 (FASE B) e del cruscotto direzionale descritto al capitolo 4.

Per tutti gli ambiti funzionali interessati dai requisiti di tabella A e tabella B dell’Allegato 7 sono da prevedere attività di rivisitazione dei processi e delle procedure aziendali amministrativo-direzionali, successive attività di parametrizzazione, eventuale personalizzazione, e messa in esercizio. In particolare nelle fasi di analisi sarà necessario che l’Aggiudicatario supporti la Fondazione nel riesame concertato di processi, procedure e documentazione a loro correlata, pianificando, coordinando e contribuendo all’attività di appositi tavoli di lavoro per ogni area di interesse (es. ciclo attivo, ciclo passivo, gestione ordini di acquisto, gestione assunzione, ecc.).

I servizi di gestione operativa dovranno essere attivati alla conclusione della Fase A, e dovranno essere estesi successivamente, completata la Fase B del progetto.


Per maggiori dettagli relativi alle tempistiche si faccia riferimento al paragrafo 5.2.

2.4. Infrastrutture e licenze

Non sono oggetto della fornitura, in quanto messi a disposizione dalla Fondazione (v. Allegato 1-Contesto della Fondazione IIT):

Infrastruttura hardware; Licenze software dei sistemi operativi della famiglia Microsoft Windows Server; Licenze software del sistema ERP-SAP e RDBMS; Licenze software del sistema Sap Business Objects Edge 4.0 Standard.

L’Aggiudicatario dovrà analizzare il patrimonio infrastrutturale di cui la Fondazione dispone e dimensionare adeguatamente l’infrastruttura per poter assicurare adeguati livelli prestazionali, facendo riferimento sia all’ambiente principale che all’ambiente di disaster recovery.

3. REQUISITI NON FUNZIONALI L’implementazione del sistema ERP-SAP, oggetto del presente capitolato, dovrà garantire la messa in esercizio di un sistema che risponda pienamente ai requisiti non funzionali di seguito dettagliati. Si riporta come riferimento l’architettura logica applicativa dello scenario attuativo atteso, che articola i livelli dell’architettura logica di riferimento del SII della Fondazione, in riferimento alla quale il sistema ERP-SAP dovrà essere implementato.

L’architettura del sistema ERP-SAP dovrà essere realizzata secondo il framework a tre livelli (three-tier) web, che consenta agli utenti l’accesso a qualunque componente applicativa da un qualunque PC sul quale sia disponibile un web browser. L’installazione e le successive attività di parametrizzazione ed eventuale personalizzazione devono essere svolte e attuate al fine di garantire l’implementazione di un sistema ERP-SAP che soddisfi i seguenti requisiti:

Modulare: in modo da garantire l’estensione del supporto applicativo qualora la Fondazione lo ritenga necessario. Dovrà comunque garantire l’interoperabilità e la comunicazione tra i singoli moduli, e abilitare logiche di workflow e di orchestrazione tra i processi;

Parametrizzabile: al fine di garantire l’adattamento alle esigenze della Fondazione intervenendo su parametri e non attraverso interventi di sviluppo ad hoc. Il sistema deve comunque consentire la realizzazione di stampe e procedure personalizzate per particolari necessità della Fondazione, per mezzo di strumenti standard di sviluppo;

Prescrittivo: per indirizzare procedure e logiche di lavoro già consolidate nel settore e che rappresentano best practices da poter incorporare per la rivisitazione e la riprogettazione dei propri processi di business;

Scalabile: il sistema deve essere in grado di “crescere” o “decrescere” in funzione delle necessità e delle disponibilità della Fondazione, sia in termini di supporto per servire un maggior o minore numero di utenze, sia per quanto


riguarda l’estensione del supporto applicativo di ciascun’area funzionale, senza che ciò determini impatti sul funzionamento e la fruibilità del sistema stesso.

Figura 2 – Scenario attuativo

Inoltre:

Al livello di patrimonio informativo i requisiti non funzionali richiesti riguardano unicità, tracciabilità e storicizzazione di dati e documenti;

A livello infrastrutturale i requisiti non funzionali richiesti riguardano aspetti di sicurezza, privacy e gestione delle utenze;

A livello applicativo i requisiti non funzionali richiesti riguardano aspetti di integrazione, interoperabilità e aderenza agli standard;

A livello di presentazione i requisiti non funzionali richiesti riguardano aspetti di accessibilità e usabilità.

3.1. Unicità, tracciabilità e storicizzazione di dati e documenti

L’unicità delle informazioni presenti nel sistema è un requisito imprescindibile: dati replicati e ridondati incrementano pericolosamente la possibilità di propagazione degli errori oltre a rallentare sensibilmente le attività operative. Si richiede pertanto che dal punto di vista operativo il sistema ERP-SAP sia implementato dall’Aggiudicatario in modo da garantire che il dato possa essere inserito una e una sola volta e in modo razionale e tempestivo


rispetto al processo di business nel quale il dato è catturato o generato, ed essere utilizzabile in tutti i contesti in cui se ne presenti la necessità.

Per quanto riguarda l’integrità del dato, il sistema deve essere implementato in modo da impedire l’alterazione diretta o indiretta delle informazioni, sia da parte di utenti e processi non autorizzati, che a seguito di eventi accidentali. Anche la perdita di dati (per esempio a seguito di cancellazione o danneggiamento), viene considerata come alterazione.

Dovrà essere assicurata la tracciabilità di tutte le registrazioni informatiche effettuate sulle procedure, sia per i dati e sia per i documenti, ovvero il sistema deve consentire di risalire a chi e quando ha effettuato ogni singola registrazione in ogni fase del processo amministrativo-gestionale, assicurando la sequenzialità temporale delle annotazioni/scritture (riferimento temporale). L’identificazione della data e ora di una registrazione deve essere effettuata mediante l’apposizione dell’indiazione del tempo di sistema, che deve essere opportunamente gestito dal sistema ERP-SAP secondo procedure che ne garantiscano la coerenza.

Inoltre l’applicativo deve contenere tutti i meccanismi necessari a garantire la congruenza dei dati e, qualora reso possibile dalle features dell’RDBMS, implementarli tramite di esse.

3.2. Sicurezza, privacy e gestione utenti

Il sistema ERP-SAP dovrà essere implementato dall’Aggiudicatario in modo da garantire un elevato livello di sicurezza, pertanto dovrà essere in grado di supportare adeguati meccanismi di gestione utenze e accessi, di gestione delle sessioni ed essere conforme alle buone pratiche di sicurezza per quanto riguarda la gestione delle vulnerabilità (ad es. SQL Injection, ecc.) e la comunicazione sicura tra server e client (ad es. tramite protocollo HTTPS).

Nello specifico la gestione di utenti e dei relativi accessi deve tenere conto di specifiche politiche di riservatezza e di protezione dei dati, ovvero garantire l’accesso ai dati esclusivamente ai collaboratori della Fondazione aventi tale autorizzazione.

La modifica di un risultato dovrà essere subordinata alla verifica che l'utente sia in possesso delle autorizzazioni necessarie. ln ogni caso, ogni operazione di modifica su dati o documenti dovrà essere tracciabile ed opportunamente documentata in appositi file di log.

Si richiede inoltre, per le attività dell’amministratore di sistema, la conformità a quanto indicato con il provvedimento del Garante del 27 novembre 2008 riguardante le “Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema - 27 novembre 2008 (G.U. n. 300 del 24 dicembre 2008)”.

La gestione di tali politiche deve essere supportata da un gestore utenti e un sistema di autenticazione unico e centralizzato, unico responsabile della gestione dei codici identificativi personali e dei relativi diritti.


A questo scopo la Fondazione metterà a disposizione il proprio dominio di controllo accessi (AD - LDAP), che dovrà essere alimentato dal sistema di gestione del personale come fonte preferenziale dell’anagrafe degli operatori riconosciuti dall’azienda, e dovrà alimentare la gestione degli accessi del sistema ERP, anche in termini di definizione dei ruoli e dei gruppi. Tale sistema dovrà consentire la gestione dell’intero ciclo di vita di tutti gli account utilizzatori (creazione, modifica/aggiornamento, revoca, sospensione e cancellazione).

La funzione di accesso autorizzato, prevista per tutti gli utenti/funzioni del ERP-SAP, deve essere garantita a seguito di ogni intervento dell’Aggiudicatario ai fini della propria attività di configurazione e sviluppo software.

Per ogni modulo si dovrà attestare l’assenza di parti di codice che consentano l’accesso al sistema, ai dati e al loro trattamento senza l’impiego delle idonee credenziali per l’autenticazione o in violazione della normativa vigente sulla gestione dati.

Il Proponente dovrà indicare come intende procedere per garantire un sistema di sicurezza che preveda quanto sopra descritto e garantisca almeno le seguenti funzionalità minime ulteriori:

Controllare, revocare e modificare i diritti d’accesso agli oggetti e alle funzionalità degli applicativi;

Funzioni di sicurezza applicativa (autenticazione e autorizzazione) verso tutti gli applicativi del sistema ERP-SAP;

Secure Single Sign On (SSO), per l’accesso a contenuti e moduli applicativi da un unico punto di accesso;

Gestione dei Ruoli: definizione dei ruoli e/o gruppi e determinazione a quali applicativi e/o funzioni ciascun ruolo e/o gruppo possono accedere.

Infine, riguardo alla gestione delle sessioni si richiede che il sistema ERP-SAP sia implementato in modo da garantire opportuni meccanismi di gestione dell’inattività nella sessione utente a un periodo definito e di esecuzione del blocco della sessione utente allo scadere di tale periodo.

3.3. Integrazione, interoperabilità, aderenza agli standard

L’implementazione del sistema ERP-SAP dovrà essere attuata utilizzando protocolli e metodi standard e allo stato dell’arte rispetto all’attuale livello di innovazione tecnologica del settore.

Ciascun modulo del sistema ERP deve essere integrato quindi attraverso modalità standard, basate su un unico database condiviso ed un unico motore di workflow e gestione eventi. L’adozione di protocolli standard deve essere finalizzata anche a garantire l’interfacciamento del sistema con sistemi di parti terze laddove previsto per il soddisfacimento dei requisiti elencati al capitolo 4. Ciò deve essere possibile sia attraverso lo scambio dati su tracciati predefiniti e concordati tra le parti, sia attraverso la chiamata a webservices esposti dai sistemi che dovranno comunicare. Le interfacce di integrazione


dovranno quindi poter abilitare lo scambio dati sia sincrono che asincrono verso soluzioni applicative esterne al sistema ERP-SAP.

Da ciascun sistema applicativo, sistema ERP-SAP o sistema terzo, non dovranno pertanto essere gestite repliche locali di dati ma dovranno essere acceduti e modificati solo e direttamente i dati residenti nell’anagrafica integrata.

3.4. Accessibilità e usabilità

Si richiede che il livello di presentazione dei dati abbia caratteristiche tali da rispettare requisiti di accessibilità e usabilità. A tale scopo le interfacce di accesso al sistema che saranno realizzate dovranno prevedere l’inserimento e la consultazione agevole e leggibile delle informazioni gestite dal Sistema Informativo, attraverso un accesso configurato al sistema (sistema adattativo), anche per mezzo di aree di sintesi o evidenza.

Per garantire l’accessibilità del sistema da parte di tutti gli utenti, le informazioni devono essere facilmente reperibili, esplicitate in modo chiaro e rese di indubbia interpretazione.

Per garantire l’usabilità si richiede che il sistema sia adattativo, ovvero deve visualizzare solamente le informazioni circoscritte all’ambito operativo dell’utente (acquisti/contabilità/ecc.) e quindi limitare i dati modificabili/inseribili a seconda dei diritti dell’operatore che si autentica al sistema (collaboratore operativo vs responsabile di funzione). Si richiede inoltre, che per specifiche funzionalità da individuare in accordo con la Fondazione, l’interfaccia utente sia presentata in lingua italiana o inglese a seconda del profilo utente che accede.

Affinché lo strumento sia usabile, è importante che la grafica sia semplice e con combinazioni di colori “comode” per la vista. È inoltre importante valutare con attenzione il rispetto degli standard W3C esistenti. Ciò, unito a una strutturazione delle informazioni logica, semplice ed intuitiva, permette all’utente di prendere rapidamente dimestichezza con lo strumento e quindi di ridurre notevolmente i tempi di addestramento del personale, e di ridurre la probabilità di errori di inserimento.

4. REQUISITI FUNZIONALI I requisiti funzionali richiesti per il sistema ERP-SAP della Fondazione riferiscono verticalmente a 5 principali aree organizzative:

Contabilità; Acquisti; Magazzino; Risorse Umane; Pianificazione e controllo.

E’ inoltre richiesta la realizzazione di un cruscotto direzionale che permetta l’accesso a dati di sintesi ed aggregati per il supporto ai processi decisionali delle Direzioni della Fondazione.


Per ciascuna area organizzativa sono riportati, in Allegato 7-Requisiti funzionali, alle tabelle A e B, i requisiti di dettaglio. Nello specifico in tabella A sono elencati i requisiti funzionali del “nucleo minimo” del sistema ERP-SAP implementato, ovvero requisiti prioritari per la Fondazione, mentre in tabella B sono elencati i requisiti funzionali del “nucleo esteso” del sistema ERP-SAP implementato, ovvero che estendono il supporto funzionale per alcune aree. Relativamente al cruscotto direzionale si richiede venga realizzata un’architettura basata su tre livelli: il primo livello composto dai sistemi che producono i dati gestionali (sistemi gestionali alimentanti) e i sistemi per l’integrazione dei dati;; il secondo livello costituito dal datawarehouse BW come unica banca dati direzionale e il terzo livello caratterizzato dalle funzioni di presentazione e gestione, per la realizzazione delle viste di accesso alle informazioni di interesse per i diversi profili di utenti della Fondazione. Attraverso tale cruscotto la Fondazione dovrà poter visualizzare ed estrarre i valori degli indicatori di misura della propria attività, dei quali si riportano, a titolo esemplificativo e non esaustivo, i principali in Allegato 3-Lista dei KPI. Gli indicatori saranno compiutamente definiti ed individuati dalla Fondazione nel corso del progetto di implementazione. Sarà cura dell’Aggiudicatario verificare che, in relazione agli indicatori, esista o meno corrispondenza nei dati trattati dal software adottato, e di prevedere gli opportuni accorgimenti in termini di parametrazione o di personalizzazione. In particolare, l’Aggiudicatario dovrà indicare nella proposta di razionalizzazione delle anagrafiche quali moduli permettono l’ottenimento degli indicatori medesimi e confermare o no la provenienza da moduli esterni, da integrare opportunamente con l’ERP. 5. GESTIONE DEL PROGETTO

5.1. Organizzazione del progetto

Il percorso che porterà all’avviamento del sistema informativo oggetto del presente Capitolato è un programma complesso ed articolato che presenta caratteristiche peculiari ed elevata complessità in relazione a:

Dimensioni della Fondazione; Complessità ed estensione funzionale dell’intero sistema;; Necessità di dismissione di un sistema informativo esistente con parallela attivazione

dei nuovi servizi, senza che l’operatività del sistema complessivo sia arrestata durante il cambiamento;

Varietà delle aree di intervento e interdipendenze tra le attività nelle diverse aree di cui si compone il progetto;

Impatto organizzativo e sui processi amministrativo-gestionali della Fondazione; Innovatività dal punto di vista tecnologico e organizzativo.


La fase di analisi, programmazione, implementazione e conduzione del servizio dovrà essere pertanto caratterizzata dalla presenza di Comitati e organi di governo misti Fondazione-Aggiudicatario.

Più precisamente dopo la sottoscrizione del contratto di affidamento, verranno istituiti per la gestione operativa e strategica del progetto due Comitati misti e due Nuclei a supporto delle scelte direzionali e operative: a) il Comitato Strategico b) il Comitato Operativo c) un Nucleo Direzionale e d) un Nucleo Operativo che resteranno in carica per tutta la durata del progetto.

a) Comitato Strategico

Il Comitato Strategico è costituito dai seguenti rappresentanti delle Parti:

Fondazione: Direttore Scientifico; Direttore Generale; Responsabile ICT; Project Manager; Responsabile del contratto; Incaricato di quality assurance; Altri responsabili da definire.

Aggiudicatario Project Manager; Responsabile del contratto.

In base all’ordine del giorno, altri referenti delle Parti possono essere invitati a partecipare al Comitato Strategico in qualità di ospiti.

Il Comitato Strategico ha il compito di monitorare l’andamento del progetto e supportare la pianificazione strategica dell’evoluzione del sistema ERP-SAP della Fondazione. Il Comitato Strategico si riunisce a scadenza prefissata o su richiesta di una delle Parti.

In particolare tale Comitato ha il compito di:

Garantire la sponsorizzazione del progetto; Promuovere il processo di comunicazione per agevolare il cambiamento della

cultura organizzativa; Fornire una direzione strategica; Risolvere i problemi strategici e gli eventuali conflitti di alto livello eventualmente

coinvolgendo anche il Nucleo Direzionale; Prendere decisioni tempestive e fissare le priorità per problemi di massimo

livello; Valutare ed approvare le variazioni in corso d’opera di obiettivi ed elementi

chiave per il progetto;


Recepire le policy inerenti alla sicurezza delle informazioni e della proprietà intellettuale delle parti, conformemente a quanto concordato nel contratto in essere;

Supervisionare l’adempimento agli obblighi delle parti a fronte del contratto di servizio in essere e gestire eventuali rinnovi.

b) Comitato Operativo

Il Comitato Operativo si riunisce con cadenza prefissata o su richiesta ed è costituito dai seguenti rappresentanti delle parti:

lato Fondazione Responsabile ICT; Project Manager;

lato Aggiudicatario Project Manager; Service Manager.

In base all’ordine del giorno, altri referenti delle Parti possono essere invitati a partecipare al Comitato Operativo in qualità di ospiti o come parte attiva in funzione dell’attività in corso nel progetto (es. analisi, migrazione, testing, ecc.).

Svolge il compito di monitorare la conduzione ed erogazione delle diverse fasi di Progetto, di analizzare i risultati sulle performance. Il Comitato Operativo costituisce, inoltre, la sede di confronto e di risoluzione delle problematiche a livello operativo.

In particolare il Comitato Operativo assolverà ai seguenti compiti:

Gestire collegialmente il progetto nel suo complesso in modo da assicurare il raggiungimento degli obiettivi;

Gestire il complesso della pianificazione generale ed esecutiva, il monitoraggio del progetto, il controllo sul rispetto dei requisiti di qualità, il presidio della documentazione di progetto, il supporto segretariale al progetto;

Ratificare il Piano di Progetto e gli stati di avanzamento, riferendo al Comitato Strategico;

Prevenire, monitorare e gestire opportunamente i rischi; Coinvolgere il Nucleo Direzionale quando ritenuto necessario per la risoluzione

di conflitti; Coordinare il Nucleo Operativo.

Per le riunioni del Comitato Operativo verrà tenuto un verbale dal referente dell’Aggiudicatario, e sottoscritto da ognuno dei membri partecipanti.

c) Nucleo Direzionale Il Nucleo direzionale è costituito dai seguenti rappresentanti delle Parti: lato Fondazione:

Responsabile ICT;


Project Manager; Direttore Amministrativo; Direttore Acquisti e Approvvigionamento; Direttore Risorse Umane e Organizzazione; Direttore Pianificazione e Controllo; Referente della Direzione Scientifica; Incaricato di quality assurance.

lato Aggiudicatario: Project Manager.

Compiti del Nucleo Direzionale sono:

Supportare il Comitato Operativo e quello Strategico per la risoluzione di conflitti organizzativi;

Gestire le allocazioni delle risorse coinvolte nel Nucleo Operativo al fine di garantire continuità e presidio delle attività di progetto, secondo quanto concordato in fase di set up dei gruppi di lavoro;

Valutare eventuali variazioni rilevanti che hanno impatto sulle procedure/processi della Fondazione;

Identificare le scelte da riportare a livello di Comitato Strategico laddove queste implichino modifiche rilevanti alle procedure e alle logiche di funzionamento dei processi della Fondazione;

Approvare i documenti di analisi e di progettazione della nuova configurazione tecnologica-gestionale.

d) Nucleo Operativo

Il Nucleo Operativo è costituito dai seguenti rappresentanti delle Parti:

lato Fondazione:

Referenti delle aree funzionali;

Referente ICT;

Gruppi di Key user per ciascuna area funzionale interessata dal Progetto;

Analista di organizzazione.

lato Aggiudicatario:

Senior Consultant;

Altre figure tecniche.

Compiti del Nucleo Operativo sono:

Analizzare i processi as-is della Fondazione per la formalizzazione dei requisiti e delle logiche di funzionamento necessarie alla progettazione della configurazione organizzativa - tecnologica to-be del sistema ERP-SAP (scenario to-be);


Fornire consulenza su temi gestionali ed organizzativi rilevanti in termini di best practice e procedure, a cui riferirsi per la progettazione dello scenario to-be, chiarendo le alternative percorribili ai key user e ai referenti di funzione della Fondazione

Si riporta di seguito un’esemplificazione concettuale della struttura di governo descritta.

Figura 3-Esempio di struttura di governo di progetto

5.2. Tempistiche di progetto

Il progetto dovrà essere strutturato prevedendo quattro principali fasi di lavoro:

Fase A – E’ relativa allo svolgimento di tutte le attività preparatorie, di analisi e di realizzazione del sistema per gli ambiti funzionali amministrativo-gestionali relativi ai requisiti di tabella A, all’Allegato 7-Requisiti funzionali, e che costituiscono il nucleo minimo del sistema ERP-SAP della Fondazione. La fase deve essere avviata al momento dell’assegnazione all’Aggiudicatario e concludersi entro e non oltre il 31 Dicembre 2013 con il primo nucleo del sistema ERP-SAP in esercizio e pienamente operativo. Nello specifico la fase A deve pertanto prevedere, lo svolgimento e la conseguente conclusione, delle seguenti attività:

Progettazione della nuova configurazione tecnologico-organizzativa, così come descritta al paragrafo 6.1.

Razionalizzazione delle anagrafiche aziendali, così come descritta al paragrafo 6.2;

Installazione, implementazione e collaudo di tutti i moduli necessari a rendere operativi i requisiti funzionali indicati in tabella A, all’allegato 7-Requisiti funzionali. L’attività dovrà svolgersi nelle modalità indicate al paragrafo 6.3;

Comitato Strategico

Nucleo Direzionale

Nucleo Operativo

Comitato Operativo


Recupero dello storico dati e dei documenti, così come descritta al paragrafo 6.4;

Addestramento e training relativamente alle aree funzionali da mettere in funzione, così come descritta al paragrafo 6.5.

Realizzazione delle interfacce o dei meccanismi di scambio dati necessari alla comunicazione tra il sistema ERP-SAP e applicazioni di terze parti; l’attività dovrà essere svolta nelle modalità idonee a soddisfare i requisiti funzionali descritti nella tabella A, all’allegato 7-Requisiti funzionali, che richiedano lo scambio dati con altre applicazioni in uso presso la Fondazione. Ciascuna interfaccia e in generale i meccanismi di scambio dati dovranno essere realizzati in modo aderente a quanto specificato sul tema al paragrafo 3.3. Le applicazioni di terze parti, in uso presso la Fondazione e interessate da tale attività, sono (v. Allegato 1-Contesto della Fondazione IIT): o TEM; o Archiflow; o Selesta; o Portofino (Soluzione proprietaria della Fondazione).

Fase B – E’ relativa a tutte le attività necessarie per la messa in esercizio dei

requisiti funzionali di tabella B, all’allegato 7-Requisiti funzionali, e che costituiscono il nucleo esteso del sistema ERP-SAP della Fondazione. La fase B deve essere conclusa entro il 30 Giugno 2014. Nello specifico include le attività di:

Realizzazione del cruscotto direzionale, così come descritto all’Allegato 7-Requisiti funzionali;

Implementazione e verifica di conformità di tutti i moduli necessari a rendere operativi i requisiti funzionali indicati in tabella B, all’allegato 7-Requisiti funzionali;

Addestramento e training relativamente alle aree funzionali interessate dalla messa in esercizio del sistema ERP-SAP secondo il perimetro funzionale definito dalla tabella B, dell’allegato 7-Requisiti funzionali e quello relativo al cruscotto direzionale.

Fase C – Avvio e conduzione dei servizi di gestione operativa per il sistema ERP-SAP relativamente ai moduli e alle funzioni attivate con la conclusione di Fase A.

Fase D – Avvio e conduzione dei servizi di gestione operativa per il sistema ERP-SAP relativamente ai moduli e alle funzioni attivate con la conclusione di Fase B.

Di seguito si riporta lo schema di Gantt generale a cui il Proponente dovrà riferirsi per la strutturazione del crono-programma da presentare in offerta.


Figura 4 - Pianificazione temporale di riferimento

Le principali Milestone di progetto si riferiscono al raggiungimento di specifici risultati di progetto:

MA1 - Approvazione della configurazione tecnologico-organizzativa: conclusione delle attività di stesura, validazione e approvazione della documentazione di analisi, prodotta durante le attività di progettazione della configurazione tecnologico-organizzativa del sistema ERP-SAP implementato, così come descritta al paragrafo 6.1. L’attività dovrà concludersi entro il 30 Giugno 2013;

MA2 - Preparazione di tracciati e estrattori conclusa: conclusione delle attività per la preparazione di tracciati, estrattori ed eventuali test, necessari all’esecuzione del recupero dei dati, nelle modalità indicate al paragrafo 6.4; nello specifico si richiede che le attività preparatorie alla migrazione dati (es. predisposizione dei tracciati) siano concluse non oltre il 30 Settembre 2013.

MA3 – Verifica di conformità del nucleo minimo completato: Conclusione attività di test e verifica per tutti i moduli applicativi interessati dal nucleo minimo. Nello specifico l’attività dovrà essere conclusa non oltre il 30 Novembre 2013;

MA4 - Addestramento e Training di Fase A concluso: completamento delle attività di addestramento, secondo quanto previsto dalla descrizione al presente paragrafo, della Fase A. Per conclusione si intende il completamento di tutte le attività indicate dal piano di addestramento necessarie a rendere gli utenti autonomi nell’utilizzo del sistema ERP-SAP implementato, così come descritto nel paragrafo 6.5. L’attività dovrà essere conclusa non oltre il 15 Dicembre 2013;


MA5 - Sistema di Fase A, o nucleo minimo, in esercizio secondo quanto previsto dalla descrizione, al presente paragrafo, della Fase A. L’attività dovrà essere conclusa entro il 31 Dicembre 2013;

MB1 - Preparazione di tracciati e estrattori per la fase B conclusa: completamento delle attività per la preparazione di tracciati, estrattori ed eventuali test, necessari all’esecuzione del recupero dei dati richiesti per la messa in esercizio dei requisiti di tabella B e del cruscotto direzionale, nelle modalità indicate al paragrafo 6.4. L’attività dovrà essere conclusa entro 28 Febbraio 2014;

MB2 - Collaudo del nucleo esteso completato: Conclusione attività di test e collaudo per tutti i moduli applicativi interessati dal nucleo esteso. Nello specifico le attività di collaudo dovranno essere concluse entro il 31 Maggio 2014;

MB3 - Addestramento e Training di Fase B concluso: completamento delle attività di addestramento necessarie a rendere i collaboratori della Fondazione, autonomi nell’utilizzo del sistema ERP-SAP implementato relativamente alle funzioni estese e previste per la Fase B. Le attività di addestramento dovranno essere svolte secondo quanto indicato al paragrafo 6.5 e concludersi entro e non oltre il 15 Giugno 2014;

MB4 - Sistema di Fase B, o nucleo esteso, in esercizio secondo quanto previsto dalla descrizione al presente paragrafo, della Fase B. L’attività dovrà essere conclusa entro il 31 Giugno 2014.

MCD1 - Servizi di gestione operativa conclusi: scadenza del contratto che regolarizza il servizio di gestione operativa. Fino a tale momento il servizio dovrà essere garantito secondo le modalità previste e descritte al capitolo 7.

5.3. Pianificazione del progetto

Nel rispetto delle indicazioni generali espresse nel presente capitolato tecnico, è richiesto all’Aggiudicatario di pianificare con accuratezza il progetto complessivo, le fasi e le relative attività ad esse connesse.

Ciascuna di queste fasi dovrà essere opportunamente pianificata, tenendo conto delle specificità delle diverse aree in cui si articola il progetto e nel rispetto delle scadenze indicate dalla Fondazione nel paragrafo 5.2.

Si ricorda che la visibilità sulla pianificazione complessiva e sui singoli sottoprogetti, una volta definita, dovrà essere concessa alla Fondazione attraverso un sistema di repository documentale di progetto sul quale la Fondazione potrà consultare, in qualsiasi momento lo ritenga necessario, lo stato aggiornato dell’avanzamento delle attività, la pianificazione di eventuali incontri e la documentazione di progetto prodotta per ciascun’attività svolta. Si prediligono soluzioni di portale che prevedano la gestione delle versioni e la tracciabilità delle revisioni/modifiche ai documenti, con interfaccia usabile e disponibilità di strumenti di condivisione delle agende.


Nell’Offerta Tecnica dovrà essere descritto lo strumento adottato a tale scopo.

Il Proponente deve fornire un crono programma di progetto complessivo, che includa almeno le seguenti principali attività:

avvio e pianificazione; installazione e preparazione degli ambienti; analisi delle esigenze e progettazione del modello di funzionamento del sistema

ERP-SAP, sia a livello funzionale che a livello di anagrafiche; configurazione del sistema e sviluppo di eventuali personalizzazioni; recupero dello storico; addestramento e training; verifica di conformità supporto alla transizione;

Per ciascuna delle attività inserite nel crono programma, in fase di offerta, il Proponente deve presentare indicazione chiara e strutturata di:

principali deliverable; tempistiche previste;

Per ciascuna delle fasi (A, B, C, D) il Proponente deve indicare

posizionamento delle Milestone indicate nel paragrfo 5.2 modalità di interazione con tutti i soggetti coinvolti nel progetto, compresa la

molteplicità di entità coinvolte lato Proponente in caso di RTI ed i referenti dei sistemi attualmente in uso presso la Fondazione che dovranno essere oggetto di integrazione con il sistema o saranno coinvolti a vario titolo dal progetto;

strumenti e documentazione a supporto delle attività di project management.

5.4. Funzioni di gestione del progetto

A corredo delle attività di pianificazione e governo del progetto il Proponente dovrà indicare nell’Offerta Tecnica le modalità con cui intende procedere relativamente a due principali funzioni di gestione progetto quali:

Monitoraggio, controllo e gestione di tempi, costi e qualità; Gestione del Rischio.

Per entrambe le funzioni si fornisce di seguito una descrizione delle caratteristiche minime che devono essere garantite secondo quanto previsto e di seguito richiesto dalla Fondazione.

Monitoraggio, controllo e gestione di tempi, costi e qualità

Si intendono le attività da svolgere a corredo dell’attività di governo del progetto, per garantire l’allineamento tra quanto pianificato e gli avanzamenti dei lavori. L’Aggiudicatario deve monitorare e controllare l’avanzamento del progetto e di tutte le attività di avvio, pianificazione, esecuzione e chiusura dello stesso in modo da raggiungere gli obiettivi, in termini di prestazione, definiti nel piano di Project Management.


La programmazione delle attività e dei report sulle performance dovranno essere costantemente aggiornati e periodicamente condivisi con la Fondazione durante i momenti programmati di confronto sull’avanzamento dei lavori, illustrando i progressi fatti e le criticità in atto (per queste ultime proponendo proattivamente delle possibili soluzioni).

È richiesta la formalizzazione di meccanismi di monitoraggio delle prestazioni, atti a rilevare i benefici di efficacia ed efficienza e misurare gli eventuali scostamenti dagli obiettivi di performance definiti all’inizio del progetto. In particolare l’Aggiudicatario dovrà formalizzare e condividere con la Fondazione tecniche e strumenti di controllo e reporting su tempi, costi, qualità e aderenza alle specifiche.

In generale si richiede siano indicate e descritte le procedure che il Proponente prevede di attivare al fine di garantire un coordinamento efficace e comunicazioni trasparenti, strutturando e attivando flussi informativi e di comunicazione efficienti tra i diversi soggetti coinvolti nel progetto. Ciò deve comprende:

Procedure decisionali, di validazione, di comunicazione; Procedure di analisi, risoluzione e trasferimento delle criticità; Procedure di controllo delle modifiche e delle revisioni; Procedure di verifica e approvazione della documentazione di analisi e relativa alla

progettazione della configurazione tecnologico organizzativa; Modello di reporting.

Tutte le azioni, costituenti la fase di avviamento e conduzione dei servizi da parte dell’Aggiudicatario, dovranno essere comunicate formalmente e, nel caso la Fondazione ne veda l’esigenza, l’Aggiudicatario dovrà redigere un protocollo che descriva passo-passo le attività routinarie e potenzialmente non a carico del personale della Fondazione.

La Fondazione adotterà fin dalla fase di attivazione un monitoraggio periodico sul servizio (con cadenza a discrezione della Fondazione) per valutare la corretta attivazione ed erogazione dei servizi come da crono-programma di progetto ed il non degrado delle funzionalità richieste in termini di perfomance e contenuti.

Gestione del Rischio

Si intendono le attività da svolgere a corredo dell’attività di governo del progetto al fine di svolgere un’azione preventiva rispetto a possibili minacce e rischi che possano verificarsi durante lo svolgimento delle fasi di progetto.

La gestione dei rischio è un controllo importante nell’ambito di un progetto: è opportuno tenere traccia di tutti i rischi identificati, la loro analisi, le contromisure adottate e lo status. Questa gestione deve partire all’inizio del progetto e continuare fino alla sua chiusura;; i rischi devono essere revisionati periodicamente, almeno alla conclusione di ogni fase, durante le Riunioni di Avanzamento. In modo proattivo ogni aggiornamento del progetto di rischio dovrà essere sottoposto al comitato operativo unitamente alla proposta di azioni per mitigare i rischi identificati. Il Proponente deve inserire nella propria offerta una prima proposta di gestione del rischio, con particolare attenzione all’interfaccia con i referenti


aziendali ed alla progettazione di opportuni ‘escalation paths’ per la gestione delle criticità. I documenti richiesti per le attività di gestione del rischio devono prendere in esame al minimo:

Possibili rischi di natura organizzativa; Possibili rischi di natura tecnologica.

5.5. Profili e risorse del progetto

In fase di presentazione dell’offerta il Proponente dovrà riportare i profili e i relativi curriculum delle persone che intenderà impegnare nell’erogazione dei servizi richiesti nell’ambito del Capitolato.

I curricula dovranno essere redatti in formato Europeo, non dovranno superare la lunghezza di due pagine e dovranno possibilmente fare riferimento al framework e-CF (European e-Competence Framework).

Le figure che dovranno essere previste nell’offerta del Proponente includono:

Responsabile del contratto; Project Manager; Service Manager; Senior Consultant per area applicativa; Senior Consultant per aree tecniche; Senior Consultant per il servizio di addestramento e training

Si precisa che in relazione alle attività che dovranno essere svolte dalle figure di Project Manager, Senior Consultant per area applicativa, Senior Consultant per aree tecniche e Senior Consultant per il servizio di addestramento e training, si richiede che le stesse siano svolte in presenza presso la sede della Fondazione in una misura minima del 70%.

Per tutti gli altri profili, si richiede al Proponente di mettere a disposizione risorse competenti e di comprovata esperienza per ciascuna area/gruppo di lavoro.

Il Responsabile del contratto è una figura professionale di alto livello ed elevato profilo gerarchico, con forti doti di leadership e capacità manageriali, il cui ruolo è caratterizzato dalle seguenti responsabilità:

essere l’interfaccia dell’Aggiudicatario; garantire la congruità tra quanto riportato nel contratto con quanto erogato; verificare lo stato dell’erogazione dei servizi e della relazione con la Fondazione e

organizzare gli incontri di revisione previsti; proporre e giustificare, in termini di costi, benefici, tempi e rischi, le soluzioni per il

miglioramento continuo; farsi parte diligente e cooperare nella risoluzione dei conflitti o problemi che

potrebbero sorgere durante lo svolgimento del contratto; attivarsi per le approvazioni e seguire il raggiungimento degli scopi/obiettivi;


fornire informazioni accurate e tempestive per la gestione amministrativa e contabile del contratto.

Il Project Manager è una figura professionale di alto livello, responsabile dell’intero Team di Lavoro, con il quale vengono erogate tutte le attività oggetto del capitolato. E’ quindi l’interfaccia verso la Fondazione per la gestione dei rapporti e delle relazioni operative. Il suo ruolo è caratterizzato dalle seguenti responsabilità:

organizzare complessivamente le attività del progetto, in riferimento al dimensionamento delle risorse, alle modalità operative (turnazione dei tecnici o degli operatori), al mantenimento degli skill professionali delle risorse;

predisporre ed eseguire tutte le attività previste per raggiungere nei tempi stabiliti i livelli di SLA contrattuali;

integrare gli apporti di tutti i partecipanti al programma complessivo, in ottica di team;

verificare lo stato di sviluppo delle singole attività, intervenendo con gli opportuni correttivi sugli scostamenti temporali e realizzativi;

definire, per ogni processo di sviluppo, le procedure operative; ricercare l’ottimizzazione dei singoli processi, attraverso la loro integrazione;; verificare ed eventualmente attuare le modifiche e le integrazioni richieste dalla

Fondazione; predisporre la documentazione e i report periodici; recepire le esigenze di evoluzione o manutenzione di una componente applicativa

ed effettuare la prima analisi (demand management).

Il curriculum minimo richiesto per entrambe le figure, Responsabile del contratto e Project Manager, dovrà possedere almeno:

laurea vecchio ordinamento o laurea specialistica, certificazione di metodologia di gestione di progetto o per servizi (ITIL, PMI o

equivalenti), 10 anni di esperienza in progetti di implementazione ERP nel settore pubblico e/o

privato nel ruolo ricoperto, nell’ambito del Progetto di implementazione del sistema ERP-SAP della Fondazione.

Il Service Manager è una figura professionale assegnata allo svolgimento delle attività relative ai servizi di Gestione Operativa. E’ responsabile del disegno e della successiva erogazione degli specifici servizi quali ad esempio manutenzione, help desk, ecc. Si dovrà prevedere almeno una figura Senior di Service Manager, e il curriculum minimo richiesto dovrà possedere almeno:

Laurea vecchio ordinamento o laurea specialistica, 7 anni di esperienza nel ruolo proposto in progetti di carattere analogo nel settore

pubblico e/o privato.

Per quanto riguarda i referenti funzionali delle aree applicative e tecniche (referenti funzionali, tecnici professionali, system architect), il curriculum minimo richiesto è relativo


ad almeno una figura di Senior Consultant per ambito applicativo e per area tecnica, e dovrà possedere almeno:

Laurea vecchio ordinamento o laurea specialistica 5 anni di esperienza nel ruolo in progetti di carattere analogo nel settore pubblico

e/o privato.

Per quanto riguarda il Senior Consultant per il servizio di addestramento e training, il curriculum minimo richiesto è relativo ad una figura di Senior e dovrà possedere almeno:

Laurea vecchio ordinamento o laurea specialistica 5 anni di esperienza nel ruolo in attività di addestramento e training di carattere

analogo nel settore pubblico e/o privato.

L’Aggiudicatario si impegna a confermare i profili indicati in fase di offerta all’atto di sottoscrizione del contratto.

Qualora ciò non sia più possibile l’Aggiudicatario dovrà garantire la sostituzione con un profilo assolutamente equipollente fornendo il curriculum del professionista subentrante: in caso di evidente minore esperienza la Fondazione potrà chiedere la sostituzione a suo insindacabile giudizio.

La composizione del Team di progetto della Fondazione sarà comunicata all’Aggiudicatario entro l’inizio delle attività, fermo restando che per ciascuna delle diverse aree di progetto si metteranno a disposizione gli opportuni referenti, sia tecnici che amministrativo-gestionali.

In generale, per la gestione del progetto la Fondazione individuerà referenti atti a coprire i seguenti ruoli:

Responsabile del contratto; Project Manager; Referenti funzionali per le aree funzionali amministrativo-gestionali; Referente della Direzione scientifica; Referenti tecnici per l’area ICT; Key users (per ciascuna delle aree organizzative coinvolte nel progetto, in base

all’organizzazione delle attività concertata con l’Aggiudicatario); Incaricato di quality assurance.

In particolare, la Fondazione prevede che su specifiche tematiche (es. ottimizzazione dei processi, ecc.) la progettazione della configurazione finale verrà concertata in appositi tavoli di lavoro che potranno coinvolgere, a seconda dei casi, referenti dell’Aggiudicatario, referenti operativi delle singole U.O. della Fondazione, referenti della direzione, referenti di fornitori di altre soluzioni applicative implementate dalla Fondazione, consulenti esterni. E’ facoltà del Proponente, nell’ambito della proposta di organizzazione di progetto, suggerire l’attivazione di gruppi di lavoro di questo tipo per facilitare la conduzione delle attività.


6. CARATTERISTICHE DEI SERVIZI PROFESSIONALI RICHIESTI PER L’ATTIVAZIONE DEL SISTEMA ERP-SAP

6.1. Progettazione della nuova configurazione tecnologico-organizzativa

Si intendono le attività di analisi delle esigenze (as-is) della Fondazione e progettazione della configurazione tecnologico-organizzativa (to-be).

L’attività dovrà essere eseguita a partire dai risultati emersi dall’analisi dei requisiti, già svolta all’interno della Fondazione, nell’ambito delle logiche di funzionamento amministrativo-gestionali, che dovrà essere opportunamente rielaborata e resa idonea allo scopo. Tale attività prevede l’utilizzo di strumenti di BPMN.

Nell’ambito del più ampio progetto di riorganizzazione, la Fondazione ha infatti condotto e portato a compimento l’analisi dei processi interni dell’organizzazione, sia per la parte amministrativo-gestionale che per le attività afferenti all’area della produzione scientifica. Tale studio, opportunamente documentato, può essere consultato dall’Aggiudicatario in sede di analisi. Il lavoro svolto non deve rappresentare l’unico riferimento per la progettazione della nuova configurazione, bensì una base utile da cui partire, ma che dovrà essere opportunamente rielaborata e integrata, affinché le esigenze della Fondazione siano formalizzate secondo il linguaggio e le modalità necessarie all’implementazione di un sistema ERP-SAP che soddisfi tutti i requisiti funzionali indicati nel capitolo 4.

L’analisi dovrà essere orientata a:

identificare specificità e problematiche della Fondazione che possano essere risolte attraverso modelli di processo ispirati alle best practice ERP-SAP di settore;

individuare modelli di funzionamento propri della Fondazione e che dovranno essere riprodotti sul sistema ERP-SAP.

Ne deriverà un’attività di Gap Analysis che dovrà poi condurre alle attività di progettazione, parametrazione e/o personalizzazione delle soluzioni applicative proposte.

E’ elemento di valutazione l’adozione di modelli di processo predefiniti (acceleratori) per la risoluzione delle specificità della Fondazione di seguito elencate:

Gestione del codice SIOPE in base alle determinazioni previste dal DM 14/11/06 n. 135555 nei rapporti con il MEF-IGEPA (tramite Banca d’Italia) e relative riconciliazioni tra i movimenti registrati in COGE e le corrispondenti operazioni finanziarie. Fare inoltre riferimento ai requisiti delle tabelle A e B, Allegato 7-Requisiti funzionali, relativi all’area di “Contabilità” in merito ai temi di: codice SIOPE, riconciliazione istituti di credito;

Gestione dell’imposta sul valore aggiunto (IVA) che, in ambito istituzionale comporta la registrazione di un costo, salvo i casi in cui in l’applicazione dell’art. 72 DPR 633/72 applichi in misura ridotta, e in ambito commerciale comporta invece la registrazione di una partita a debito o a credito con la conseguente gestione di tutte


le dichiarazioni a natura fiscale. In entrambi i casi il sistema deve essere in grado di gestire le operazioni intracomunitarie con le caratteristiche proprie dei due differenti ambiti. Fare inoltre riferimento ai requisiti delle tabelle A e B, Allegato 7- Requisiti funzionali, relativi all’area di “Contabilità” in merito ai temi di: gestione dell’IVA;;

Flusso per la gestione delle gare. Fare riferimento ai requisiti delle tabelle A e B, Allegato 7-Requisiti funzionali ed Allegato 5, relativi all’area di “Acquisti”;;

Flusso ingressi nuovi Dipendenti/Collaboratori in IIT. Fare riferimento all’Allegato 6 per le esigenze specifiche della Fondazione;

Gestione oggetti di budget gerarchici, controllo di capienza, riferimento temporale, proiezioni e simulazioni. Fare riferimento all’allegato 4 per le specifiche esigenze della Fondazione e ai requisiti delle tabelle A e B, Allegato 7, relativi all’area di “Pianificazione e Controllo” in merito ai temi di: pianificazione del budget, controllo capienza, riferimento temporale, proiezioni e simulazione; Allegato 8- Schemi di budget

6.2. Supporto alla razionalizzazione delle anagrafiche aziendali

S’intende l’insieme delle attività necessarie alla progettazione e realizzazione dell’anagrafica integrata. I dati gestiti dal sistema ERP-SAP dovranno essere consistenti e non ridondati su basi dati diverse. Il sistema dovrà quindi essere basato su un’unica base dati logica e fisica al fine di ridurre la frammentazione dei dati. Il modello dati fisico del sistema dovrà essere direttamente leggibile e completamente documentato nel suo schema E-R. A tal proposito si forniscono, nell’Allegato 2, l’elenco delle principali entità informative e li relativo sistema applicativo di riferimento. L’elenco è di riferimento al Proponente per comprendere la tipologia di entità attualmente utilizzate dalla Fondazione che continueranno in parte ad essere generate e gestite da sistemi di terze parti, e dovranno quindi essere prese in esame per la progettazione dell’anagrafica integrata. Nella proposta di offerta dovrà essere indicato dal Proponente la copertura di tali entità da parte del sistema ERP-SAP e le modalità con cui si procederà alla progettazione dell’anagrafica integrata tenendo conto:

delle entità informative che saranno gestite da sistemi di terze parti;

delle metriche dei KPI che dovranno essere implementate e che caratterizzeranno il cruscotto direzionale, così come descritto al capitolo 4.

Sarà considerato elemento distintivo l’indicazione da parte del Proponente sulle possibili problematiche che ritiene possano verificarsi, con la descrizione delle modalità organizzative o degli strumenti operativi che prevede di mettere in atto per la loro gestione.


6.3. Installazione, configurazione, implementazione, sviluppo di eventuali personalizzazioni e messa in esercizio

Si intendono le attività di installazione, configurazione, parametrizzazione, sviluppo di eventuali personalizzazioni, necessarie ad adattare il prodotto ERP-SAP ai requisiti specifici di ciascun ambito applicativo, per la messa in esercizio del sistema. Previa installazione delle componenti applicative l’Aggiudicatario dovrà provvedere alla predisposizione di tutti gli ambienti necessari allo scopo tra cui: ambiente di sviluppo, ambiente di test e ambiente di produzione.

I vari ambienti saranno predisposti dall’Aggiudicatario su risorse hardware messe a disposizione dalla Fondazione, delle quali si fornisce la descrizione nell’Allegato 1 – Contesto della Fondazione IIT.

L’architettura del sistema ERP-SAP dovrà essere realizzata secondo il framework a tre livelli (three-thier) web come indicato al capitolo 3. Qualsiasi attività di configurazione o realizzazione di personalizzazioni (sviluppo ad hoc) dovrà tenere conto di quanto definito durante le fasi di analisi per la progettazione della configurazione organizzativo-tecnologica, preventivamente approvata dalla Fondazione e opportunamente testata in ambiente di test. L’ambiente di test dovrà garantire identiche condizioni dell’ambiente di produzione. Inoltre nello sviluppo applicativo dovranno essere utilizzati linguaggi di programmazione standard per l’ambiente SAP, sia per lo sviluppo della logica applicativa, sia per lo sviluppo dell’interfaccia utente. Una volta realizzate, le funzionalità dovranno essere rilasciate in ambiente di test secondo piani di rilascio concordati tra la Fondazione e l’Aggiudicatario. A livello generale procedure e sistema di gestione dei rilasci dovranno rispettare i seguenti principi: Ogni componente è identificato da una versione univoca; Ogni aggiornamento è effettuato attraverso lo strumento di supporto scelto, il cui

accesso è riservato alla Fondazione. È in questo modo possibile dare garanzia di univoca identificazione della versione di prodotto installata negli ambienti di test e di produzione;

Un documento di configurazione deve identificare la configurazione dei componenti al momento installata in ambiente di test/addestramento ed in ambiente di produzione. Nel caso di applicazioni software parametriche deve essere data specifica dettagliata dei singoli parametri ed il complesso di configurazioni e procedure di gestione delle strutture dati che contengono i parametri;

Devono essere descritte le procedure di automazione della gestione di ogni sottosistema nel suo complesso, sia in esercizio sia per operazioni di “recovery”, “backup” e “security”;;

Deve essere disponibile una referenza circa messaggi di errore e spiegazioni relative in lingua italiana.

La verifica funzionale deve essere svolta secondo le modalità indicate al capitolo 8.


L’esito positivo della verifica funzionale porta la soluzione collaudata a essere messa in esercizio (Go live) avviando il periodo di osservazione della qualità della soluzione in produzione. Tale periodo di osservazione si richiede essere pari a 30 giorni a partire dalla messa in produzione della soluzione. Il periodo di osservazione è finalizzato a rilevare eventuali difformità della soluzione applicativa in termini sia prestazionali (sotto carico) sia funzionali (correttezza delle operazioni nelle varie condizioni operative e rispondenza a tutte le casistiche gestionali).

Qualunque tipo di difformità o malfunzionamento si dovesse riscontrare rispetto alle corrette condizioni operative, sarà onere dell’Aggiudicatario intervenire per risolverle nel rispetto di quanto indicato.

6.4. Recupero dello storico di dati e documenti

Si intendono le attività di migrazione e bonifica dei dati provenienti dagli attuali sistemi della Fondazione che dovranno essere inseriti nella base dati del prodotto ERP-SAP.

Sono pertanto a carico dell’Aggiudicatario tutte le attività relative a:

realizzazione di flussi di scarico e carico dati; configurazione di prodotti di ETL; bonifica dei dati migrati e processi di quadratura necessari a verificare la

correttezza della migrazione stessa. Si riportano a titolo esemplificativo e non esaustivo le principali entità che dovranno essere migrate per il recupero dello storico, quali:

Clienti; Fornitori; Dipendenti, collaboratori e professionisti; Conti di contabilità.

Per quanto riguarda i dati e i documenti riferiti al periodo a cavallo del passaggio dal nuovo al vecchio sistema, si riportano di seguito le principali voci che il Proponente dovrà prevedere nel piano di migrazione:

Progetti in corso; Contratti attivi; Ordini di acquisto aperti; Voci di budget.

L’elenco sopra riportato non è da ritenersi esaustivo.

6.5. Addestramento e training

Si intendono l’insieme delle attività necessarie all'acquisizione da parte delle diverse tipologie di utenti delle competenze necessarie a svolgere la normale operatività secondo tempi e livelli di efficienza almeno uguali a quanto attuato prima della sostituzione del sistema gestionale.


Si richiede, in sede di offerta tecnica, l'elaborazione da parte del Proponente di un piano di addestramento di massima basato sull'integrazione di metodologie didattiche differenti (addestramento in aula, training online, comunità professionali) in funzione delle caratteristiche dei destinatari, della loro numerosità e degli obiettivi di apprendimento. Il piano formativo dovrà almeno prevedere:

La gestione di gruppi di utenti fino ad un massimo 20 persone; Ciascuna sessione di addestramento dovrà essere adeguatamente supportata da

materiale didattico che sarà poi consegnato agli utenti per successiva autonoma consultazione;

Descrizione dei moduli didattici previsti in termini di obiettivo e contenuti; Durata di ciascun modulo previsto; L’addestramento per tutti gli utilizzatori del sistema ERP-SAP; Strumenti adottati per la condivisione del materiale di supporto e per lo svolgimento

di sessioni di training da remoto.

Le sessioni di addestramento dovranno essere svolte presso la sede IIT di Genova.

Gli utenti target dell’attività di addestramento e training a cui il piano deve rivolgersi sono: I key user coinvolti nelle fasi di progettazione della soluzione e che costituiranno il

nucleo dei “power user” per supportare gli utilizzatori finali meno esperti;; tutto il personale della Fondazione in possesso di utenza per l’accesso al sistema

ERP-SAP; gli utenti gestori ed i profili tecnici della Fondazione con competenze tecnologiche

evolute che si occuperanno della gestione infrastrutturale e applicativa del sistema.

L’attività di addestramento sopracitata, in particolare per le sessioni dedicate agli amministratori e ai key user deve avere contenuti e modalità idonee a garantire la loro autonomia lavorativa per l’utilizzo di ciascun modulo applicativo di loro interesse.

L’attività di addestramento e training deve prevedere, per ogni area organizzativa interessata dal rilascio di una nuova soluzione applicativa, almeno:

La predisposizione e l’aggiornamento continuo, per tutta la durata del contratto, dei manuali di gestione e dei manuali utente che verranno usati a supporto della attività di addestramento ed in autonomia dagli utenti;

L’addestramento degli utenti utilizzatori del sistema, suddivisi per tipologia funzionale;

La presenza diretta sul campo durante il transitorio di avvio, secondo una ipotesi minima: • Di 8 ore giornaliere di affiancamento con una risorsa di adeguata preparazione

per la prima settimana solare dall’avvio (7 giorni), • Di 4 ore giornaliere di affiancamento con una risorsa di adeguata preparazione

per la seconda settimana solare dall’avvio (7 giorni).


In ogni caso in tutto il periodo di transitorio di messa in esercizio dovrà essere disponibile un nucleo di supporto rapido per fronteggiare eventuali difficoltà nell’utilizzo delle nuove soluzioni minimizzando eventuali ripercussioni negative sulla normale operatività delle funzioni organizzative. I tutor forniti dall’Aggiudicatario devono conoscere l’applicativo e la realtà dove viene applicato, essere persone comunicative, che sappiano interagire con l’utente finale rispettandone il ruolo. Nell’affiancamento dovranno rispettare i ritmi imposti dal flusso lavorativo dell’utente finale. Il tutor infine deve saper gestire le eventuali osservazioni in merito all’applicativo degli utenti finali, recepirle e condividerle in modo strutturato. La strategia di comunicazione e addestramento sarà oggetto di valutazione da parte della Fondazione che potrà avvalersi della facoltà di richiedere la sostituzione dei tutor messi a disposizione senza alcun vincolo. Si richiede siano previsti degli strumenti e dei metodi di supporto all’apprendimento che permettano al singolo dipendente o a gruppi di dipendenti di incrementare e approfondire in modo autonomo, e dalla propria postazione, le capacità di utilizzo dei moduli applicativi che formano il Sistema ERP-SAP. A tal proposito devono essere almeno attivate le funzioni di help online e suggerimenti contestuali che il sistema già offre. Il piano di addestramento, i metodi e gli strumenti previsti dal piano stesso saranno oggetto di valutazione tecnica da parte della commissione di gara. Nello specifico sarà oggetto di valutazione preferenziale l’innovazione in termini di strumenti utilizzati e modalità interattive previste per l’interlocuzione con gli utenti, quali l’adozione di piattaforme di eLearning e la documentazione a supporto dell’attività di addestramento.

6.6. Realizzazione interfacce e interoperabilità con sistemi di terze parti

Si intendono le attività di analisi e sviluppo necessarie ad integrare il prodotto ERP-SAP da implementare con i sistemi già presenti ed in uso nella Fondazione che necessitano di essere allineati. Si prevede la realizzazione di interfacce sia sincrone che asincrone per permettere le integrazioni fra i diversi sistemi. Le modalità di realizzazione per lo scambio dati devono fare riferimento a quanto indicato al paragrafo 3.3. Nello specifico le principali interfacce di integrazione richieste riguardano le seguenti soluzioni di mercato:

TEM; Archiflow; Selesta; Business Object.

Tra le soluzioni realizzate ad hoc, di cui la Fondazione è proprietaria:

Portofino.

Si faccia riferimento alle tempistiche di progetto descritte al paragrafo 5.2 per quanto riguarda la sequenzialità con cui tali interfacce devono essere realizzate.


Sono considerati elementi migliorativi l’adozione di connettori o tracciati già in possesso del Proponente; devono essere indicati eventuali limiti alla realizzazione delle interfacce richieste che possano richiedere il coinvolgimento di terze parti. In ogni caso l’Aggiudicatario si assume l’obbligo di partecipare assieme alla Fondazione alla gestione dei contatti ed alle necessarie interazioni con terze parti, finalizzate alla realizzazione delle interfacce in questione.

7. GESTIONE OPERATIVA DEL SERVIZIO

I requisiti che seguono fanno riferimento ai servizi di manutenzione e di assistenza on site e da remoto per tutte le componenti software del sistema ERP-SAP implementato, a partire dalla messa in esercizio del sistema stesso. Si faccia riferimento al paragrafo 5.2. per un maggior dettaglio sulle scadenze di messa in esercizio che il piano di progetto dovrà prevedere, e per la conseguente attivazione dei servizi di gestione operativa.

Pertanto, l’Aggiudicatario dovrà produrre entro due mesi dalla firma del contratto la documentazione completa di progetto, che esplichi in maniera esaustiva le modalità di attuazione della gestione operativa del servizio presso la Fondazione dettagliando attività, tempi, risorse e procedure operative.

I servizi minimi richiesti all’Aggiudicatario sono declinabili nelle seguenti tipologie:

Manutenzione applicativa generale (correttiva-adattativa-normativa-preventiva); Manutenzione evolutiva delle soluzioni applicative fornite con l’utilizzo di giornate a

consumo; Assistenza applicativa e sistemistica e servizio di help-desk di 2°livello; Allestimento e manutenzione ambienti tecnologici a supporto del sistema

informativo richiesto; Presidio di competenze specialistiche on-site.

L’utilizzo del Framework ITIL o analogo framework di gestione di servizi, per l’erogazione dei servizi di gestione operativa, è condizione minima in base alla quale il Proponente dovrà documentare come ha adottato ed intende implementare presso la Fondazione una metodologia di lavoro strutturata.

Orari di servizio

Di seguito sono indicate le fasce orarie di servizio minimo richieste. Nell’ambito della documentazione dell’offerta il Proponente potrà estendere tali orari proponendo nuove tabelle orarie che migliorino la copertura del servizio.

I giorni di festività considerati sono quelli delle festività nazionali.

Si precisa che nel seguito per “reperibilità” si intende la possibilità di attivare telefonicamente una risorsa addetta al servizio, che prenda in carico la richiesta e la evada


mediante collegamento da remoto (RAS) e/o interagendo telefonicamente con il richiedente.

Manutenzione applicativa generale

A. Manutenzione correttiva Giorno Orario Lunedì-Venerdì non festivi 8.30 – 17.30

Sabato non festivo

Domenica e festivi

B. Manutenzione adattativa-normativa

Manutenzione evolutiva delle soluzioni fornite con l’utilizzo di giornate a consumo

Giorno Orario Lunedì-Venerdì non festivi 8.30 – 17.30

Sabato non festivo

Domenica e festivi

7.1. Manutenzione applicativa generale

L’Aggiudicatario deve garantire ed assicurare la manutenzione di tutto il software applicativo rilasciato in produzione ed oggetto della fornitura per l’intero periodo del contratto e secondo le tempistiche indicate al paragrafo 5.2.

Il servizio dovrà garantire il regolare funzionamento del sistema. A questo scopo il servizio di manutenzione deve includere il monitoraggio periodico dei sistemi volti a prevenire l’insorgenza di guasti ed interruzioni della disponibilità del sistema. La manutenzione del software deve comprendere anche le procedure eventualmente sviluppate per l’integrazione con altri sistemi applicativi della Fondazione.

Manutenzione correttiva

Per Manutenzione Correttiva s’intende l’insieme di servizi volti a rimuovere i

Giorno Orario Lunedì-Venerdì non festivi 8.30 – 17.30

Sabato non festivo 8.30-12.30

Domenica e festivi


malfunzionamenti di codifica/configurazione nei programmi riscontrati nell’esercizio delle applicazioni in ambito, o quando questo non sia possibile nell’immediato, a fornire soluzioni temporanee (da sostituire successivamente con le correzioni definitive).

In particolare il servizio di manutenzione correttiva prevede:

analisi del malfunzionamento e determinazione della causa; identificazione di soluzioni temporanee (workaround) atte a ripristinare nel più breve

tempo possibile l’operatività dell’utente;; implementazione, test ed attivazione della soluzione temporanea; comunicazione all’utente della disponibilità dell’eventuale workaround attivato;; revisione della priorità assegnata alla richiesta nel caso di attivazione di un

workaround; identificazione dell’azione correttiva definitiva;; correzione al codice dell’applicazione, o fornitura di bug fixing, o parametrazione di

configurazione dell’applicazione;; coinvolgimento di terze parti per la risoluzione dell’anomalia se non altrimenti

identificabile; correzione di errori nel software attraverso opportune patch messe a disposizione

dall’Aggiudicatario; rilascio in ambiente di test dei componenti modificati per il Test di Accettazione; supporto al test di accettazione utente, effettuato da parte del cliente con l’ausilio

degli specialisti. Tale attività consente di verificare che la funzionalità rilasciata soddisfi le esigenze utente;

aggiornamento della documentazione tecnica e funzionale relativa ad ogni oggetto corretto;

passaggio in ambiente di produzione; disattivazione del workaround al momento del completamento della soluzione

definitiva.

L’intervento di manutenzione correttiva si considera concluso solo al momento dell’accettazione da parte dell’utente che ha segnalato l’anomalia.

Qualora siano necessari interventi che richiedano modifiche alla base dati per correggere situazioni anomale, questi dovranno essere sempre e comunque autorizzati dagli organi di governo individuati nel progetto.

La presa in carico del malfunzionamento/guasto avviene tramite help desk telefonico ed e-mail di secondo livello da parte del personale della funzione IT della Fondazione.

Sono di seguito definiti i gradi di criticità per tipologia di problema:

Problema con correzione1 :

1 Implementazione nel software che elimina un errore manifesto.


o bloccante: malfunzionamento che impedisce lo svolgimento delle attività operative;

o grave: malfunzionamento che pur non impedendo lo svolgimento delle attività, ne ostacola la continuità/efficacia/efficienza/sicurezza/qualità o altri attributi significativi;

o lieve: malfunzionamento che non ostacola il regolare svolgimento delle attività.

Il servizio di Manutenzione correttiva dovrà avvenire secondo i seguenti Livelli di Servizio.

Criticità Attivazione/Presa in carico Risoluzione Bloccante 1 ora lavorativa 4 ore lavorative

Grave 2 ore lavorative 12 ore lavorative

Lieve 3 ore lavorative

48 ore lavorative o secondo quando definito in accordo con la Fondazione

Tabella 1 - Livelli di servizio per la manutenzione correttiva

In caso di problemi al sistema non risolvibili mediante il supporto telefonico, l’Aggiudicatario dovrà destinare un tecnico qualificato ad un intervento di supporto remoto effettuato dalla propria sede verso i sistemi della Fondazione. Il supporto potrà avvenire mediante collegamento telematico protetto secondo modalità standard in uso dalla Fondazione.

A partire dal rilascio in produzione del primo sistema erogato, l’Aggiudicatario si impegna a proporre e concordare con la Fondazione, almeno una volta ogni 2 mesi, interventi (regolazioni, controlli, sostituzioni) finalizzati all’ottimizzazione ed all’aggiornamento dei sistemi oggetto della fornitura; tali interventi potranno essere effettuati periodicamente al fine di consentire la perfetta funzionalità del sistema e prevenirne i malfunzionamenti anche tramite servizi di assistenza tecnica preventivi miranti a ridurre i costi di gestione dei sistemi mediante l’eliminazione delle possibili fonti di problemi.

Manutenzione adattativa-normativa

L’obiettivo del servizio è quello di assicurare il costante, efficace e tempestivo aggiornamento ed evoluzione delle funzionalità del software applicativo rispetto a:

Variazioni organizzative dei processi di lavoro che comportino interventi di modifica del software;

Variazioni normative che comportino interventi di modifica del software; Evoluzione delle versioni dei sistemi software di base (sistemi operativi, DBMS,

software di rete, linguaggi di programmazione ecc.); Adozione di nuovi sistemi software di base o di utilità che intervengano nel corso

del contratto.


Il servizio di manutenzione deve includere l’aggiornamento, ove richiesto dalla Fondazione, di tutti i software (intesi sia come sistemi operativi implementati, sia come sistemi applicativi) alle versioni licenziate più recenti rese disponibili dal produttore.

Nel servizio dovranno essere comprese tutte le attività necessarie ad assicurare gli adeguamenti normativi del software, con riferimento a tutta la normativa europea, nazionale, regionale ed i regolamenti della Fondazione.

Prima della messa in esercizio, tuttavia, ogni aggiornamento deve necessariamente essere concordato preventivamente e autorizzato dalla Fondazione. Essa, infatti, si riserva di accettare o respingere l’installazione di nuove funzionalità se ritenute non adeguate o non efficienti o non pertinenti alla propria realtà.

Manutenzione Preventiva

Per Manutenzione Preventiva si intende l’insieme delle attività effettuate con l’obiettivo di evitare futuri problemi applicativi, di migliorare la qualità, la stabilità e le performance delle applicazioni garantendone la massima affidabilità.

L’Aggiudicatario, quindi, s’impegna con la Fondazione ad effettuare interventi (regolazioni, controlli, sostituzioni) finalizzati all’ottimizzazione ed all’aggiornamento dei sistemi oggetto della richiesta.

Tra le altre attività devono almeno essere garantite le seguenti:

condivisione di soluzioni implementate su altri clienti e recuperate dal network di conoscenze accessibili all’Aggiudicatario;

monitoraggio periodico del sito, in caso di SW di terze parti, per verificare la presenza di note correttive da applicare alla corrente release del sistema ERP-SAP utilizzato;

Implementazione delle correzioni e delle maintenance release, se approvate dalla Fondazione, che prevedano un impegno non superiore ai 10 giorni uomo complessivi tra analisi di impatto, realizzazione, test e rilascio.

il monitoraggio delle attività di storicizzazione dei dati al fine di verificare che l’occupazione dello storage sia in linea con le dimensioni dei record storicizzati e da storicizzare;

la verifica dell’impegno di tempo macchina (tempo di CPU) nelle diverse fasi di elaborazione e nei momenti di picco;

l’analisi del file di log e dei messaggi di attenzione generati dal sistema anche in assenza di sintomi evidenti di malfunzionamento;

la dimensione e analisi dei log file del database ed efficacia degli indici; la verifica della correttezza e consistenza degli archivi di back up locali e remoti.

La manutenzione preventiva dovrà essere effettuata a cicli prefissati, secondo uno scadenziario stabilito, o al verificarsi di particolari avvenimenti (autodiagnosi, rilevazioni strumentali, test specifici, ecc.).

L’attività di manutenzione preventiva, qualora rilevi un malfunzionamento o indicatori che


portino l’elemento indagato vicino ai valori di soglia critica, deve comportare anche l’attività necessaria al ripristino dei valori indagati all’interno dei parametri ottimali.

7.2. Manutenzione evolutiva

Per manutenzione evolutiva si intende l’insieme delle attività di innovazione, modifica, riconfigurazione, delle soluzioni applicative proposte a valle del go-live delle stesse presso ogni singola struttura. Queste sono diverse dalle predette attività di manutenzione correttiva e/o adattiva-normativa. Similmente, rientrano nelle attività di implementazione la personalizzazione delle soluzioni ed il loro rilascio e diffusione presso tutte le strutture aziendali interessate.

Le attività di Manutenzione Evolutiva richieste devono essere portate in esecuzione come prima proposta dal personale dell’Aggiudicatario assegnato all’attività di manutenzione ordinaria in sede di pianificazione del servizio. Qualora il personale addetto alla manutenzione ordinaria non sia in grado di portare in esecuzione in toto o in parte l’attività richiesta, l’Aggiudicatario può proporre al Responsabile IT della Fondazione di integrare le risorse assegnate con personale incaricato per l’occasione.

Per gli interventi di manutenzione evolutiva deve essere previsto un massimo di 50 giorni uomo, compreso e compensato nell’importo offerto, dal quale la Fondazione potrà attingere a consumo per attività non previste nell’ambito della manutenzione ordinaria, quali ad esempio:

Adeguamenti funzionali del software su specifiche richieste della Fondazione; Assistenza specialistica per l’avviamento di nuove funzionalità realizzate ad-hoc per

la Fondazione e considerate di interesse esclusivo per lo stesso; Ulteriori attività di addestramento, training, e consulenza in aggiunta alle attività di

project management.

La procedura da attuare per l’attivazione delle singole attività di manutenzione evolutiva è qui descritta:

1. Esame congiunto, tra referenti chiave della Fondazione e dell’Aggiudicatario, della necessità di personalizzare la soluzione;

2. Richiesta di valutazione a cura del referente IT della Fondazione verso il referente di progetto dell’Aggiudicatario;

3. Valutazione economica dell’Aggiudicatario in termini di giorni uomo e tempi realizzativi;

4. Negoziazione tra le parti; 5. In caso di accettazione da parte della Fondazione, le attività devono procedere nei

tempi e con le risorse concordate; 6. Se la proposta non viene accettata vengono esaminate congiuntamente soluzioni

alternative.

Se la richiesta riguarda “attività ulteriori” (es. addestramento, affiancamento) è sufficiente la pianificazione congiunta tra referente IT della Fondazione e il referente di progetto


dell’Aggiudicatario. In questi casi, ed in tutti i casi esterni alla descrizione ed alla quantificazione di quanto previsto al presente capitolato tecnico, l’Aggiudicatario dovrà assicurare il rilascio di regolare e dettagliato rapporto di lavoro giornaliero su modulo dell’azienda entro 1 giorno lavorativo successivo all'attività svolta controfirmata dalle parti (i rapporti non pervenuti entro tale termine non saranno considerati validi ai fini amministrativi e quindi non rimborsati).

Alla conclusione di ogni nuova realizzazione l’Aggiudicatario dovrà collaudare la nuova configurazione del sistema, con la supervisione di almeno un referente della Fondazione e stendere il verbale di accettazione.

Per tali attività di collaudo, ai fini della validazione e dello svolgimento del testing, devono prevedere un’installazione preliminare nell’ambiente di test, ambiente a totale carico dell’Aggiudicatario. La successiva installazione nell’ambiente di produzione sarà concordata con la Fondazione con adeguato anticipo allo scopo di minimizzare l’impatto sull’operatività dell’utenza.

I tempi di esecuzione della Manutenzione evolutiva sono quelli maggiormente influenzati dalla durata e dalla complessità delle attività che le compongono.

I tempi degli interventi di Manutenzione evolutiva, suddivisi nei momenti principali di svolgimento, non dovranno essere superiori ai seguenti valori:

Momenti giornate lavorative Max

Presa in Carico da parte dell’Aggiudicatario ella richiesta di Manutenzione evolutiva espressa dalla Fondazione

3

Proposta di soluzione tecnica di Manutenzione evolutiva da sottoporre all’approvazione della Fondazione

10

Realizzazione della soluzione tecnica di Manutenzione evolutiva approvata dalla Fondazione comprensiva dei tempi di installazione, e messa in esercizio.

27

Totale 40

Tabella 2 - Tempi di esecuzione della Manutenzione evolutiva

7.3. Assistenza applicativa on-site o da remoto

Si intende il servizio di Service Desk applicativo di secondo livello per il sistema ERP-SAP implementato. Il servizio di service desk applicativo di secondo livello si deve fare carico della risoluzione delle problematiche riguardanti i requisiti funzionali e non funzionali richiesti all’interno del presente capitolato. Il service desk di primo livello sarà gestito direttamente dalla Fondazione e si occuperà della presa in carico della richiesta per la sola registrazione della problematica segnalata.


L’Aggiudicatario dovrà dotarsi degli eventuali strumenti di gestione (hardware e software) aggiuntivi necessari per garantire la perfetta conduzione dei servizi richiesti in fornitura e la produzione della relativa reportistica. Per garantire la massima tempestività e capacità di monitoraggio ed assistenza da remoto devono essere previsti strumenti che consentano la teleassistenza per quegli interventi che non richiedano la presenza on-site del personale tecnico specializzato dedicato. Per l’assistenza da remoto deve essere prevista la presa in carico delle richieste e successiva risoluzione secondo quanto previsto dagli SLA della manutenzione correttiva conformemente alla tipologia di richiesta - bloccante, grave o lieve.

7.4. Exit Management

Nel presente paragrafo vengono descritte le attività e le procedure che saranno richieste al Fornitore nella fase finale del rapporto contrattuale per il rilascio del servizio, per il passaggio delle consegne al subentrante designato (Fornitore Entrante) dalla Fondazione e per il trasferimento al relativo personale di tutte le conoscenze necessarie a garantire la fluida transizione nell’erogazione e la continuità operativa per l’utenza dei servizi in fornitura della Fondazione. Alla scadenza del contratto l’Aggiudicatario presterà l’assistenza necessaria a trasferire la gestione dei servizi alla Fondazione o al Fornitore Entrante per un periodo pari agli ultimi due mesi di contratto.

La fase di Exit management, oltre a quanto detto, contempla i seguenti aspetti:

fornitura del servizio e delle modalità di garanzia di continuità nella fase di trasferimento;

gestione del processo di trasferimento: ruoli, responsabilità, autorizzazioni e risorse da assegnare;

diritti di proprietà intellettuale: accordi necessari, licenze, etc.; due diligence: definizione della documentazione e dei contenuti da trasferire al

fornitore che subentra, nonché la definizione degli altri obblighi e penalità previste; contratti e licenze; sicurezza; piano di comunicazione.

Di seguito si riporta una traccia dei contenuti e delle caratteristiche qualificanti dell’attività di Exit, che saranno gestite relativamente a:

oggetto della transizione, attività e relative modalità di esecuzione; compiti e responsabilità di ciascuna delle parti.

Le caratteristiche qualificanti si riconoscono nei seguenti aspetti:

Piano di Transizione:


o le attività di affiancamento e rilascio sono specificate e governate da uno specifico Piano di Transizione, in cui saranno riportate tutte le attività previste in termini di tempi, risorse impiegate, punti di verifica e controllo dei risultati attesi, criteri di accettazione, i rischi, la cadenza degli incontri per la verifica dello stato di avanzamento delle attività;

Responsabilità: o durante il periodo di affiancamento e migrazione al termine del Contratto, la

responsabilità dei Servizi viene mantenuta dall’Aggiudicatario fino al termine previsto contrattualmente;

Governo del processo: o L’Aggiudicatario assicura tutte le attività finalizzate a coordinare e verificare

la corretta ed efficace esecuzione delle attività di Affiancamento e Rilascio nel rispetto dei termini concordati nonché la coerenza con i requisiti, i vincoli ed i termini stabiliti nei documenti contrattuali; a tale scopo viene individuata nel Project Manager la figura unica dell’Aggiudicatario

o che coordinerà tutte le attività e che si interfaccerà con la Fondazione ovvero con l’eventuale Fornitore terzo subentrante;;

Continuità dei servizi: o al fine di garantire alla Fondazione il mantenimento dei richiesti livelli di

servizio da parte del subentrante, nel Piano di Transizione sono previste fasi di verifica e validazione sia del trasferimento di know-how che del rilascio della documentazione; altresì, contestualmente al trasferimento delle conoscenze, si prevede un adeguato periodo di affiancamento delle risorse del subentrante nella operatività del Fornitore uscente;

Risorse professionali: o un gruppo di risorse del Fornitore appositamente designato affiancherà le

risorse della Fondazione e/o del Fornitore subentrante per il trasferimento delle conoscenze sui servizi e sulle relative attività di gestione; il team (minimo 2 persone) sarà composto da personale già impegnato nell’erogazione dei servizi;;

Customer Care: o al fine di minimizzare l’impatto del passaggio di consegne dal vecchio al

nuovo gestore dei servizi nei riguardi degli utenti del Sistema.

In particolare il Fornitore si deve impegnare a soddisfare i seguenti requisiti generali: durante la fase finale, fino al termine del periodo contrattuale, non vi saranno

impatti o interruzioni del servizio causate specificamente dalle attività di passaggio di consegne;

analogamente, in tale periodo, non vi saranno decadimenti dei livelli di servizio, specificamente imputabili al passaggio delle consegne e all'affiancamento del personale del Fornitore uscente con quello del Fornitore subentrante;


nel medesimo periodo, dal punto di vista dell’utente finale, non vi saranno significativi cambiamenti, specificamente imputabili al passaggio delle consegne, che possano inficiare le attività operative.

Per quanto riguarda la presa in carico del servizio da parte del subentrante, il Fornitore si impegna a mettere a disposizione, nelle modalità di seguito indicate, tutto il proprio personale responsabile e preposto ai servizi contrattualmente previsti, ad attività quali le seguenti:

addestramento del personale subentrante, prevalentemente con affiancamento e in modalità on the job, finalizzato alla rapida acquisizione da parte di quest'ultimo delle conoscenze specifiche dei sistemi informativi e dei servizi oggetto del contratto;

illustrazione della gestione del servizio e delle relative procedure di servizio in essere alla data e messa a disposizione di tutta la relativa documentazione.

La fase finale del periodo contrattuale sarà finalizzata da una parte alla prosecuzione dei servizi contrattualmente previsti, con il mantenimento dei livelli di servizio consolidati, dall'altra a mettere in grado il personale tecnico indicato dalla Fondazione ad un efficace subentro nei servizi in questione. Per tale ragione il Fornitore si deve impegnare nei confronti del subentrante ad un completo passaggio delle consegne ed alla fornitura di tutta la documentazione e il supporto necessari a consentire un agevole avvio del nuovo ciclo di servizio.

Gli obiettivi di cui sopra saranno raggiunti organizzando le attività nelle seguenti fasi: fase di programmazione del passaggio di consegne:

o predisposizione e raccolta della documentazione per il passaggio di consegne (procedure, report, strumenti, …);;

o riunione preparatoria con la Fondazione; o pianificazione incontri di passaggio delle consegne;

fase di affiancamento: o consegna della documentazione per il passaggio di consegne; o effettuazione degli incontri finalizzati al passaggio delle consegne; o training on the job (affiancamento) del personale subentrante per consentire

la prosecuzione dei servizi senza significativi decadimenti di qualità.

8. VERIFICA DI CONFORMITÀ E GARANZIA Ai sensi dell’art. 120 del D.Lgs. 163/06 e s.m.i. e dell’art. 312 e ss. del D.P.R. 207/10 si precisa che tutti i servizi, le prestazioni, le attività ed i risultati attesi, come sopra richiesti dal presente Capitolato Tecnico, saranno soggetti a verifica di conformità al fine di accertarne la regolare esecuzione nonché la completa e perfetta aderenza della prestazione resa dall’Aggiudicatario, sotto il profilo tecnico e funzionale, sia alle richieste di cui al presente Capitolato Tecnico, sia a quanto dichiarato dall’Aggiudicatario nella propria offerta tecnica qualora vi siano elementi migliorativi.


La Fondazione evidenzia che, fatta salva la verifica di conformità al termine delle attività contrattuali, la stessa procederà alla verifica di conformità anche in corso di esecuzione, al fine di accertare la piena e corretta esecuzione delle prestazioni contrattuali per un accertamento progressivo della regolare esecuzione delle prestazioni.

Le operazioni necessarie alla verifica di conformità sono svolte in contraddittorio con l’Aggiudicatario e a sue spese.

Al fine di definire le suddette operazioni necessarie per l’attività di verifica di conformità, viene stabilito che costituirà preciso obbligo contrattuale dell’Aggiudicatario la redazione di un documento denominato “Piano di Verifica”, il quale deve includere almeno i seguenti contenuti minimi:

Piano di test (definisce tutte le prove dinamiche che devono essere eseguite per accertare essenzialmente la corretta funzionalità dell’applicazione):

o Definizione della strategia di test;

o Elenco dei casi di test;

o Risultato dell’esecuzione dei casi di test;;

o Allegati che certificano i risultati.

Piano delle verifiche (include le altre attività di verifica, basate sia su ispezioni sia su prove dinamiche, che devono essere eseguite per accertare l’aderenza ai requisiti non funzionali, la completezza della fornitura del software, la completezza e la qualità della documentazione):

o Elenco delle verifiche;

o Risultato dell’esecuzione delle verifiche;;

o Allegati che certificano i risultati.

Predisposizione della necessaria modulistica.

Qualora la verifica fornisse risultati negativi, dovranno essere attuate le azioni correttive necessarie per riportare gli oggetti da verificare alle caratteristiche progettate. Le operazioni di verifica saranno ripetute secondo le modalità definite sino al conseguimento di risultati pienamente positivi.

In particolare si evidenzia che la verifica di conformità delle funzionalità dovrà essere sia “verticale” nel caso di procedure/funzionalità afferenti ad un stesso modulo, sia “orizzontale” nel caso di procedure/funzionalità la cui esecuzione riferisce a più di un modulo applicativo o eventualmente ad applicazioni terze, verso le quali il sistema ERP-SAP deve integrarsi, così come descritto al paragrafo 6.6.

La verifica di conformità deve verificare non solo l’aderenza alla logica funzionale definita ma anche la correttezza dei dati migrati. Tale verifica di conformità deve pertanto essere eseguita già su dati reali e validi dell’attività della Fondazione.

CAPITOLATO TECNICO - Istituto Italiano di Tecnologia · Pianificazione del progetto ......

Documents

Transcript of CAPITOLATO TECNICO - Istituto Italiano di Tecnologia · Pianificazione del progetto ......