capitolato tecnico - Istituto Italiano di Tecnologia

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
1
CAPITOLATO TECNICO
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
2
CAPITOLATO TECNICO
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
3
CAPITOLATO TECNICO
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
4
CAPITOLATO TECNICO
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
5
CAPITOLATO TECNICO
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
6
CAPITOLATO TECNICO
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
7
CAPITOLATO TECNICO




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
8
CAPITOLATO TECNICO
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 ERPSAP. Una più estesa descrizione del servizio atteso è riportata al paragrafo 6.4.
9
CAPITOLATO TECNICO
 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.
10
CAPITOLATO TECNICO
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


11
CAPITOLATO TECNICO
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
12
CAPITOLATO TECNICO
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.
13
CAPITOLATO TECNICO
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
14
CAPITOLATO TECNICO
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.
15
CAPITOLATO TECNICO
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.
16
CAPITOLATO TECNICO
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;
17
CAPITOLATO TECNICO


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;
18
CAPITOLATO TECNICO

 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);
19
CAPITOLATO TECNICO

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.
Comitato
Strategico
Nucleo
Direzionale
Comitato
Operativo
Nucleo Operativo
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 7Requisiti funzionali. L’attività dovrà svolgersi nelle modalità indicate al
paragrafo 6.3;
20
CAPITOLATO TECNICO


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 7Requisiti 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 ERPSAP 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 ERPSAP 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.
21
CAPITOLATO TECNICO
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;
22
CAPITOLATO TECNICO






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.
23
CAPITOLATO TECNICO
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.
24
CAPITOLATO TECNICO
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 passopasso 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
25
CAPITOLATO TECNICO
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;
26
CAPITOLATO TECNICO

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
27
CAPITOLATO TECNICO
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à.
28
CAPITOLATO TECNICO
6. CARATTERISTICHE
DEI
SERVIZI
PROFESSIONALI
L’ATTIVAZIONE DEL SISTEMA ERP-SAP
RICHIESTI
PER
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 7Requisiti 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
29
CAPITOLATO TECNICO
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.
30
CAPITOLATO TECNICO
6.3. Installazione,
configurazione,
implementazione,
personalizzazioni e messa in esercizio
sviluppo
di
eventuali
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.
31
CAPITOLATO TECNICO
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.
32
CAPITOLATO TECNICO
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).

33
CAPITOLATO TECNICO
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.
34
CAPITOLATO TECNICO
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
35
CAPITOLATO TECNICO
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
Giorno
Orario
Lunedì-Venerdì non festivi
8.30 – 17.30
Sabato non festivo
8.30-12.30
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
36
CAPITOLATO TECNICO
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 email di secondo livello da parte del personale della funzione IT della Fondazione.
Sono di seguito definiti i gradi di criticità per tipologia di problema:

1
Problema con correzione1 :
Implementazione nel software che elimina un errore manifesto.
37
CAPITOLATO TECNICO
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
3 ore lavorative
48 ore lavorative o
secondo quando definito
in accordo con la
Fondazione
Lieve
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.
38
CAPITOLATO TECNICO
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 39
CAPITOLATO TECNICO
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
40
CAPITOLATO TECNICO
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.
41
CAPITOLATO TECNICO
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:
42
CAPITOLATO TECNICO





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;
43
CAPITOLATO TECNICO

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.
44
CAPITOLATO TECNICO
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 ERPSAP 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.
45
CAPITOLATO TECNICO