UNIONE EUROPEA
REGIONE CALABRIA
REPUBBLICA ITALIANA
PROGRAMMA OPERATIVO REGIONE CALABRIA FESR 2007 - 2013
Allegato 2 - Capitolato Tecnico per la “Progettazione e realizzazione del Sistema Informativo Unitario Regionale per la Programmazione, Gestione e Monitoraggio degli Investimenti Pubblici e relativi servizi di assistenza e manutenzione”
Allegato 2 Capitolato Tecnico
Indice 1 2
Premessa....................................................................................................... 4 Il contesto di riferimento .............................................................................. 5 2.1 2.2 2.3 2.4
3 4 5
Il processo di programmazione...................................................................................... 5 La struttura regionale per la gestione del nuovo ciclo di programmazione ................... 9 Situazione architetturale e applicativa esistente.......................................................... 13 I progetti in corso ......................................................................................................... 21
Motivazioni del progetto SIURP ................................................................. 24 Oggetto della fornitura ............................................................................... 28 Metodologie ed attività previste................................................................. 30 5.1 5.2 5.3
6 7
Metodologie di sviluppo ............................................................................................... 30 Documentazione del sistema....................................................................................... 30 Attività .......................................................................................................................... 31
Profili professionali richiesti ...................................................................... 35 Macro-requisiti funzionali........................................................................... 37 7.1 7.2 7.3
8
La programmazione, selezione, attuazione e monitoraggio degli investimenti pubblici ..................................................................................................................................... 37 Il supporto alla Programmazione ................................................................................. 39 Processi e piste di controllo ......................................................................................... 42
Architettura di riferimento.......................................................................... 44 8.1 8.2 8.3 8.4
9
Componenti e integrazione .......................................................................................... 44 Standard Tecnologici e specifiche tecniche................................................................. 48 Caratteristiche dei componenti .................................................................................... 50 Sicurezza ..................................................................................................................... 52
Ulteriori elementi della fornitura ................................................................ 54 9.1 9.2 9.3
10
Capacity Planning ........................................................................................................ 54 Servizi di manutenzione e supporto............................................................................. 55 Servizi di change management e formazione.............................................................. 59
Modalità di esecuzione della fornitura ...................................................... 61 10.1 10.2 10.3 10.4 10.5 10.6 10.7
Il sistema di governance del progetto .......................................................................... 61 Luogo e tempi di esecuzione ....................................................................................... 67 Proprietà delle componenti .......................................................................................... 67 Piano di attività del progetto......................................................................................... 67 Piano di qualità ............................................................................................................ 68 Collaudo delle forniture ................................................................................................ 70 Monitoraggio del contratto ........................................................................................... 71
2/73
Appendici: Appendice A – Processi di Business Appendice B – Requisiti del sistema SIURP Appendice C – Processi versione HTML Appendice D – Protocollo di colloquio IGRUE (versione corrente) Appendice E – Glossario
3/73
1 Premessa Il progetto per la realizzazione del Sistema Informativo Unitario Regionale per la Gestione e il Monitoraggio degli Investimenti Pubblici (SIURP) si inserisce nell’ambito di un insieme di interventi programmati in Regione Calabria volti al miglioramento dell’efficacia e dell’efficienza dei sistemi di gestione e controllo degli investimenti pubblici per il periodo di programmazione 2007-2013. In particolare, in coerenza con le nuove previsioni programmatiche di unificazione della politica regionale aggiuntiva per il periodo 2007 – 2013 delineate nel Quadro Strategico Nazionale, l’Amministrazione regionale ha deciso di destinare parte delle risorse per la progettazione e l’implementazione di un nuovo sistema informativo regionale per lo programmazione, la gestione e il monitoraggio degli investimenti pubblici in grado di fornire una visione integrata dell’attuazione delle politiche, al fine di valutare la valenza della strategia dell’impianto programmatico, individuare eventuali criticità e azioni correttive. La regione durante la precedente programmazione 2000-2006 ha già avuto importante esperienza attraverso
la
realizzazione
del
sistema
“Rendiconta”,
strumento
che
ha
supportato
l’Amministrazione Regionale nel processo di gestione, rendicontazione e monitoraggio. Il presente intervento rappresenta un evoluzione funzionale di quel percorso che parte dal patrimonio di esperienza realizzato con il sistema Rendiconta, estendendo le funzioni richieste a nuovi ambiti, aggiornando l’architettura e la tecnologia in un ottica di orientamento ai servizi che faciliti l’integrazione con insieme del sistema informativo regionale. Tale intervento inoltre intende conseguire i seguenti obiettivi: •
migliorare il processo di programmazione delle risorse FAS e dei Fondi Strutturali assegnate alla Calabria attraverso la definizione delle priorità settoriali, l’individuazione degli interventi e la loro attuazione mediante la definizione e la stipula di nuovi APQ o di Atti Integrativi di APQ esistenti;
•
migliorare il processo di governance e di attuazione degli investimenti, elevando il grado di cooperazione istituzionale (Governo – Regione – Enti Attuatori) e di sorveglianza degli interventi (efficienza ed efficacia della spesa), assicurando il coordinamento tra i vari livelli di attuazione.
4/73
2 Il contesto di riferimento 2.1
Il processo di programmazione
2.1.1
La programmazione 2000 – 2006
Nel processo di programmazione degli investimenti pubblici confluiscono, oltre alle risorse c.d. 1
ordinarie , le risorse c.d. aggiuntive, ovvero le risorse erogate dai Fondi Strutturali comunitari e dal 2
Fondo per le Aree Sottoutilizzate . I fondi strutturali comunitari costituiscono il principale strumento della politica di coesione dell’Unione europea e il loro utilizzo è disciplinato da specifici regolamenti applicabili a tutti gli Stati membri. In particolare, il Reg. (CE) 1260/99, recante disposizioni generali sui fondi strutturali, ha disciplinato l’utilizzo dei fondi strutturali per il periodo di programmazione 2000-2006. La programmazione di tali risorse è stata definita attraverso il “Quadro Comunitario di Sostegno”, ovvero uno strumento programmatico pluriennale (a copertura del settennio 2000-2006) approvato 3
dalla Commissione Europea d’intesa con lo stato membro che ha individuato, a livello nazionale, la strategia e le priorità d’azione per l’attuazione della politica di coesione nel territorio italiano. Tale documento è stato poi articolato in una serie di strumenti attuativi a livello nazionale e regionale
4
che hanno individuato gli interventi specifici di attuazione e le relative modalità operative di gestione. In modo parallelo, la politica regionale nazionale del periodo 2000-2006 è stata attuata attraverso lo stanziamento, con cadenza annuale e per il tramite di leggi finanziarie, di risorse a favore di interventi per lo sviluppo delle aree sottoutilizzate. Nello specifico il CIPE, sulla base del monitoraggio della spesa, degli esiti delle verifiche sullo stato di attuazione degli interventi e sulla base dei fabbisogni espressi dal mercato e dal territorio, ha determinato periodicamente e in maniera flessibile con specifiche delibere l’allocazione delle risorse stanziate nelle leggi finanziarie. La programmazione e l’utilizzo di tali risorse sono stati oggetto di decisioni condivise tra stato e regioni, in cui al livello nazionale spettava la responsabilità di indirizzo strategico, mentre al livello
1
Sono definite ordinarie le risorse in conto capitale derivate dai bilanci ordinari, di fonte statale, regionale o di altri
enti. 2
3
Cfr. Appendice E. – Glossario Il QCS 2000-2006 è stato approvato dalla Commissione europea con decisione n. C (2000) 2050.
4 Programmi Operativi Nazionali e Regionali (PON e POR), Documenti Unici di Programmazione (DOCUP), Complemento di Programmazione ecc.
5/73
regionale spettavano le decisioni programmatiche e di allocazione territoriale. Per il periodo 2000 – 2006 le Amministrazioni nazionali e regionali hanno quindi dato attuazione a processi di programmazione e gestione degli investimenti pubblici distinti rispetto alle fonti di finanziamento. L’esistenza di due distinti processi di programmazione ha comportato un disallineamento nelle procedure di monitoraggio e rendicontazione delle spese, che sono state attuate, per i fondi strutturali e le risorse addizionali nazionali, attraverso strumenti informatici diversi. In particolare, per il monitoraggio finanziario, procedurale e fisico degli interventi cofinanziati con i fondi strutturali è stato utilizzato il sistema informatico Monitweb (seconda versione di un precedente sistema 5
denominato Monit2000) , gestito dall’Ispettorato Generale per i Rapporti Finanziari con l'Unione Europea della Ragioneria Generale dello Stato – Ministero dell’Economia e delle Finanze (di seguito, IGRUE). Per il monitoraggio degli interventi finanziati con risorse FAS è stato invece realizzato, presso il Dipartimento di Sviluppo e Coesione – Servizio per le Politiche di Sviluppo Territoriale e le Intese istituzionali di programma, un sistema informativo denominato Applicativo 6
Intese . 2.1.2
La programmazione 2007 – 2013
Il Quadro Strategico Nazionale per il periodo 2007-2013 (QSN) ha modificato in modo sostanziale il contesto della programmazione nazionale e regionale degli investimenti pubblici. A differenza della precedente programmazione, il QSN istituisce una strategia di politica regionale unitaria, comunitaria e nazionale nella quale confluiscono risorse ordinarie e aggiuntive comunitarie e nazionali provenienti, rispettivamente, dal bilancio dell’Unione Europea e dal Fondo FAS. Tale cambiamento all’impostazione del quadro programmatorio impone di fatto alle Amministrazioni centrali e regionali una revisione delle tradizionali modalità di pianificazione degli investimenti pubblici, con impatto sui modelli organizzativi e procedurali esistenti e sui relativi strumenti di attuazione. In particolare, la delibera CIPE n. 166 del 2007 sull’attuazione del Quadro Strategico Nazionale 2007 – 2013 ripartisce e destina, sulla base delle priorità del QSN e sulla base di programmi a
5
L’art. 34 del Reg. (CE) 1260/99, pone in capo alle Autorità di Gestione dei fondi strutturali l’obbligo di istituire “un dispositivo di raccolta di dati finanziari e statistici affidabili sull’attuazione” e di trasmettere “tali dati secondo modalità concordate tra lo Stato membro e la Commissione, mediante il ricorso, nella misura del possibile, a sistemi informatici che consentano lo scambio di dati con la Commissione […]”. Per rispondere alle richieste della Commissione Europea, l’Italia si è dotata di un proprio sistema di monitoraggio nazionale in grado di fornire alle Amministrazioni uno strumento efficace, ed il più possibile utile, per la gestione degli Interventi. 6
Cfr. glossario.
6/73
rilevanza strategica nazionale, regionale e interregionale, risorse FAS a copertura dell’intero ciclo 2007-2013, al fine di consentire a tutte le Amministrazioni una programmazione strutturata e concorrente al conseguimento degli obiettivi strategici indicati nel QSN. A rafforzamento di tale strategia, la stessa delibera individua gli strumenti programmatici nazionali e regionali che si affiancano ed integrano, ai diversi livelli della programmazione, quelli comunitari, e che costituiscono nell’insieme il quadro di contesto delle politiche di sviluppo del periodo 2007-2013. La citata delibera inoltre, individuando anche gli strumenti attuativi e le modalità operative per l’attivazione e la gestione del nuovo ciclo di programmazione, costituisce il punto di riferimento per i processi di implementazione, monitoraggio, valutazione e verifica dell’andamento dei programmi e degli interventi afferenti la politica regionale unitaria. 2.1.2.1
Il modello unico di monitoraggio
Al fine di favorire il raccordo e la progressiva integrazione dei programmi e degli interventi finanziati con risorse comunitarie e nazionali, il monitoraggio della nuova politica regionale unitaria viene effettuato attraverso una base informativa unica. Obiettivo del nuovo modello è migliorare l’efficacia e delle attività di rilevazione connesse al monitoraggio degli interventi della nuova programmazione e l’omogeneità delle informazioni afferenti la programmazione e l’avanzamento dei progetti, riducendo i rischi di generazione di dati discordanti e gli oneri connessi a tale rilevazione da parte delle Amministrazioni. 7
Il modello unico di monitoraggio prevede la fusione dei sistemi centrali di monitoraggio esistenti in un unico sistema (Banca Dati Unificata - BDU) che sarà alimentato da informazioni a contenuto comune da parte di tutte le Amministrazioni centrali e regionali responsabili di Programmi 8
Operativi/Attuativi e titolari di strumenti attuativi . Il modello di monitoraggio è articolato in tre componenti: •
un componente di ricezione, che riceve i dati dai sistemi regionali secondo un tracciato unico (c.d. “Protocollo di colloquio”);
•
un componente di validazione e consolidamento centralizzato per la condivisione e la certificazione delle informazioni;
7
Applicativo Intese per i progetti finanziati con i Fondi per le Aree Sottoutilizzate e Monitweb per i progetti cofinanziati con i fondi strutturali, cfr. par. 2.1.
8
Si intendono i Programmi Operativi Nazionali, Regionali, Interregionali per quanto attiene i fondi strutturali e Programmi Attuativi Nazionali, Regionali e Interregionali per quanto concerne le risorse FAS stanziate con del. CIPE n. 166/2007. Tra gli strumenti attuativi ci si riferisce agli APQ regionali/interregionali e strumenti di attuazione diretta.
7/73
•
un componente conoscitivo centralizzato che, a partire dalla BDU, consente di soddisfare i fabbisogni conoscitivi delle diverse tipologie di utenza.
Figura 1 - Disegno del sistema di monitoraggio del QSN9
L’IGRUE, quale responsabile della Banca Dati Unificata (BDU), assicura il rispetto degli impegni di monitoraggio attraverso controlli di coerenza e completezza delle informazioni e diffondendo regole e procedure comuni per il corretto trasferimento dei dati. La trasmissione dei dati avverrà con periodicità da definirsi e nel rispetto di regole comuni per tutte le tipologie degli interventi. Il modulo proposto nel modello prevede un solo canale di alimentazione della BDU conforme al Protocollo di colloquio. Per informazioni sul contenuto dei dati da trasmettere al sistema centrale di monitoraggio e la descrizione delle caratteristiche e delle regole dei servizi di colloquio tra i sistemi locali ed il sistema centrale saranno fornite ulteriori specifiche all’atto della progettazione esecutiva.
9
Fonte: IGRUE.
8/73
2.2
La struttura regionale per la gestione del nuovo ciclo di programmazione
2.2.1
La struttura organizzativa della Regione Calabria
L’Amministrazione regionale ha organizzato la propria struttura interna prevedendo l’istituzione di 10
14 Dipartimenti, 50 Settori e 108 Servizi . L’articolazione regionale è rappresentata nella tabella che segue: Tabella 1 – Articolazione della struttura organizzativa regionale
ID. Dip.
Nome Dipartimento
Numero di Settori
Numero di Servizi
1
Segretariato generale
1
2
2
Presidenza
4
4
3
Programmazione Nazionale e Comunitaria
3
6
4
Bilancio e Patrimonio
3
9
5
Attività produttive
2
5
6
Agricoltura, Foreste e Forestazione
5
12
7
Organizzazione del Personale
5
10
8
Urbanistica e Governo del Territorio
3
8
9
3
13
4
8
3
5
12
Infrastrutture - Lavori Pubblici - Edilizia residenziale Lavoro, Politiche della Famiglia, Formazione Professionale, Cooperazione e Volontariato Cultura, Istruzione, Università, Ricerca, Innovazione Tecnologica, Alta formazione Turismo, Beni Culturali, Sport e Spettacolo, Politiche Giovanili
4
7
13
Tutela della Salute e Politiche Sanitarie
7
12
14
Politiche dell'Ambiente
3
7
Totale
50
108
10 11
-
La Regione attraverso il Dipartimento 3 “Dipartimento Programmazione Nazionale e Comunitaria” coordina, pianifica, monitora, verifica e controlla gli interventi regionali finanziati con risorse regionali ordinarie, risorse statali aggiuntive e comunitarie.
10
Per un maggiore dettaglio si faccia riferimento alla D.G.R. n. 258 del 14/05/2007.
9/73
Il Dipartimento è organizzato in tre settori rispettivamente incaricati della programmazione (Settore Programmazione) del coordinamento e gestione dei diversi programmi operativi (Settore coordinamento programmi e progetti) e del monitoraggio e verifica (Settore monitoraggio, verifiche e controlli dei programmi e dei progetti). Il Settore Programmazione è articolato in due servizi e si occupa della Programmazione Unitaria degli investimenti finanziati con Fondi Strutturali e FAS (con particolare riguardo alla pianificazione territoriale e pianificazione strategica). Il Settore Coordinamento dei Programmi e dei Progetti è responsabile del coordinamento dell’attuazione dei Programmi; si articola in due servizi che si occupano del coordinamento e della gestione degli interventi finanziati nell’ambito del nuovo e vecchio ciclo della programmazione comunitaria (rispettivamente ciclo 2007-2013 e 2000-2006). Tra le attività del settore è ricompresa la formulazione dei pareri di coerenza programmatica agli altri dipartimenti regionali per la definizione e la pianificazione degli interventi afferenti il ciclo di programmazione.
Figura 2 - Struttura Dipartimento Programmazione nazionale e comunitaria - Regione Calabria
Il Settore Monitoraggio, Verifiche e Controlli dei Programmi e dei Progetti è responsabile del coordinamento e del supporto delle attività di monitoraggio, verifiche e controlli dei Programmi e dei Progetti e dello svolgimento diretto del monitoraggio degli interventi di responsabilità del Dipartimento su programmi e progetti finanziati con risorse ordinarie regionali, nazionali e comunitarie. A tale settore competono le attività di controllo finalizzate al monitoraggio dei fondi strutturali, nonché il corretto funzionamento del sistema informatizzato di monitoraggio. In particolare, il servizio monitoraggio si occupa di coordinare le unità operative di monitoraggio istituite presso i dipartimenti dell’Amministrazione Regionale e di garantire la correttezza, l’affidabilità e la congruenza delle informazioni monitorate; il servizio controlli e verifiche programmi 10/73
e progetti è invece responsabile del coordinamento delle unità verifiche e controlli (cui è demandato il controllo di I livello) e quindi dei controlli di conformità dei procedimenti adottati nell’ambito degli interventi programmati rispetto alla normativa regionale, nazionale e comunitaria. 2.2.2
Il sistema regionale per la gestione e il monitoraggio del nuovo ciclo di programmazione
Sulla base delle disposizioni organizzative previste nel regolamento generale dei fondi strutturali (Reg.(CE) n.1083/2006) e nel Quadro Strategico Nazionale, i Programmi operativi FESR e FSE della Regione Calabria individuano le autorità e gli organismi cui vengono demandati la gestione, il monitoraggio e il controllo dei programmi e dei progetti afferenti il nuovo ciclo di programmazione comunitaria. In particolare, in coerenza con l’articolazione della struttura organizzativa regionale i 11
programmi operativi individuano, per ciascuna autorità e organismo istituito , i Dipartimenti/Settori competenti, demandando la definizione più puntuale del modello organizzativo ad un’apposita 12
delibera di Giunta . Inoltre, nei Programmi Operativi regionali è prevista l’istituzione, presso ciascuno dei dipartimenti dell’Amministrazione, di due unità organizzative che, operando in stretto coordinamento con il Settore Monitoraggio, Verifiche e Controlli del Dipartimento Programmazione Nazionale e Comunitaria, si occuperanno del coordinamento e della verifica delle attività di monitoraggio delle operazioni di competenza di ciascun Dipartimento (Unità Operativa Monitoraggio), e della definizione e l’aggiornamento delle piste di controllo delle operazioni di competenza di ciascun Dipartimento, nonché della realizzazione dei controlli di I livello (Unità Operativa Verifiche e 13
Controlli) . Per quanto attiene la gestione, il monitoraggio e il controllo degli interventi finanziati con fondi FAS, la delibera CIPE n.166/2007 prevede che ciascuna Amministrazione individui un organismo responsabile della programmazione e attuazione, un organismo di certificazione e un sistema di
11 Per un maggiore dettaglio sulle funzioni di ciascuna autorità/organismo istituito si vedano i par. 5.1 e 5.2 del POR FESR e POR FSE della Regione Calabria. 12
Con D.G.R. n 654 del 16/09/08 sono stati individuati, per il POR FESR 2007-2013, i responsabili degli assi prioritari, dei settori e delle linee di intervento.
13
Le Unità Operative di Monitoraggio e Verifiche e Controlli sono state istituite con D.G.R. n. 245 del 23/04/2007.
11/73
gestione e controllo. Per quanto concerne la Regione Calabria, si prevede che la gestione delle 14
risorse FAS sia effettuata in maniera allineata a quella del POR FESR 2007-2013 . Infine, per assicurare lo sviluppo di una Programmazione Unitaria della Politica Regionale di Sviluppo per il settennio 2007 – 2013 e garantire il massimo livello di coordinamento e l’unitarietà di orientamento del complesso dei Programmi Operativi e degli Accordi di Programma Quadro, è stata istituito presso la Regione un Comitato Regionale di Coordinamento della Programmazione 15
Unitaria 2007 – 2013 . Sulla base di queste premesse, il modello organizzativo assunto dalla Regione Calabria per la gestione dei Programmi afferenti il nuovo ciclo di programmazione è strutturato nel seguente 16
modo : •
Autorità di Gestione;
•
Autorità di Certificazione;
•
Autorità di Audit;
•
Strutture amministrative responsabili dell’attuazione degli Assi Prioritari, dei Settori e delle Linee di intervento;
•
Sistema Regionale di Monitoraggio, coordinato dal Dipartimento Programmazione Nazionale e Comunitaria – Settore monitoraggio, verifiche e controlli dei programmi e dei progetti e articolato in: Unità operative di Monitoraggio presso i Dipartimenti regionali; beneficiari finali e soggetti attuatori;
•
Sistema Regionale di Controllo di I° livello, coordinato dal Dipartimento Programmazione Nazionale e Comunitaria – Settore monitoraggio, verifiche e controlli dei programmi e dei progetti e articolato in: Unità operative Verifiche e Controlli presso i Dipartimenti regionali; beneficiari finali;
•
Gruppo di Lavoro “Politiche Regionali Unitarie”.
Si riporta di seguito una rappresentazione a matrice dei principali organismi interessati dal ciclo della programmazione 2007 – 2013 e dei Dipartimenti/unità regionali individuati.
14 In Regione Calabria è al momento in corso di formalizzazione una delibera che individua i soggetti responsabili dei fondi FAS. 15
Sulla composizione e il dettaglio delle attività del Comitato si faccia riferimento alla deliberazione di Giunta Regionale n. 108 del 31.01.08.
16
Per il dettaglio sulle delibere istitutive e sulle funzioni di ciascun autorità, unità istituita si rimanda al documento di descrizione dei Sistemi di gestione e Controllo della Regione Calabria.
12/73
Tabella 2 - Gli organismi e le strutture regionali coinvolte nella nuova programmazione
2.3
Situazione architetturale e applicativa esistente
Per quanto concerne i sistemi informativi di supporto alla programmazione, l’attuale panorama applicativo prevede diverse soluzioni a supporto delle aree di processo interessate e che possono essere utilizzate come base per l’analisi e la realizzazione del nuovo sistema SIURP. 2.3.1
Sistema Rendiconta
Il sistema Rendiconta è il sistema informativo di proprietà della Regione Calabria utilizzato per il monitoraggio e la rendicontazione all’Unione Europea dei progetti finanziati nell’ambito del POR 17
Calabria 2000-2006 . Rendiconta consente la registrazione di informazioni su progetti la cui responsabilità di gestione è in capo direttamente alla Regione o ad altri soggetti (Enti locali, ecc.) e la registrazione/gestione dei dati di avanzamento finanziario, fisico e procedurale sul singolo progetto. Il progetto costituisce l’unità elementare per la rilevazione delle informazioni delle diverse tipologie di avanzamento che possono essere aggregate a livello di azione, misura, asse e fondo (livelli gerarchici di
17
Attualmente gestisce anche i progetti finanziati nell’ambito di Leader Plus.
13/73
articolazione del POR Calabria 2000-2006). Il sistema consente l’esportazione dei dati sui progetti e sugli stati di avanzamento verso il sistema centrale Monitweb ai fini del monitoraggio degli interventi POR; la rendicontazione delle spese a valere sui medesimi fondi viene fatta invece manualmente.
Figura 3 – L’attuale modello architetturale regionale
A livello delle principali macro-funzioni, il sistema consente: •
la gestione di ruoli e profili utente;
•
di inserire e modificare, per i piani finanziari dei programmi regionali (POR 2000-2006, FESR 2007-2013, FSE 2007-2013) gli importi e le percentuali di ripartizione per annualità e fonte di finanziamento, fino a quattro livelli gerarchici del programma (fondo/asse/misura/azione);
•
di creare, personalizzare e associare, per ciascuna procedura di selezione/progetto, la tipologia di operazione (opere pubbliche, acquisizione di beni e servizi, ecc.), le fasi del ciclo di vita del progetto/procedura e gli indicatori (di impatto, risultato, realizzazione);
•
di creare/integrare una lista di verifiche specifica per ciascun progetto/procedura di selezione da espletare sia a livello di progetto, sia in caso di richiesta di movimentazione in contabilità finanziaria (richiesta di impegno, di liquidazione, ecc.);
•
Il sistema consente di gestire le “Check list” anche a livello di progetto e non solamente nel caso di richieste di movimentazioni in contabilità finanziaria;
•
di inserire/modificare, relativamente a singole procedure di selezione/progetti: dati di anagrafica, classificazione, localizzazione, fasi del ciclo di vita del progetto, quadro finanziario, 14/73
indicatori; gli attributi al singolo progetto/selezione costituiscono i criteri per la ricerca degli stessi; per le procedure di selezione, consente di collegare i progetti ammessi al finanziamento alla procedura di selezione che li ha originati; •
la rilevazione degli avanzamenti finanziari e procedurali delle procedure di selezione e dei progetti, degli avanzamenti fisici a livello di progetto e azione;
•
la registrazione e gestione delle sospensioni di un progetto;
•
l’elaborazione delle domande di pagamento
18
per progetto e conseguente aggregazione per
azione misura fondo. Viene inoltre gestito il flusso delle approvazioni e la storicizzazione delle informazioni. Viene inoltre gestita la visualizzazione, secondo le diverse tipologie di avanzamento
(fisico,
finanziario,
procedurale)
e
i
livelli
di
articolazione
(fondo/asse/misura/azione), del rendiconto consolidato e di periodo; •
la gestione del flusso di gestione delle irregolarità e dei controlli di secondo livello;
•
la gestione documentale di documenti associati alle fasi di: anagrafica di progetto, avanzamento procedurale, avanzamento finanziario e controlli di secondo livello (fascicolo elettronico).
Rendiconta interagisce, attraverso il componente GEMA, con il sistema informativo di contabilità finanziaria per la gestione del Bilancio regionale: ogni atto di impegno e di liquidazione a valere su di un Programma Operativo viene elaborato dal Bilancio solo in presenza di una richiesta da parte di Rendiconta, a cui restituisce gli estremi degli atti una volta registrati e archiviati nell'applicazione Decreti e delibere. Il sistema consente, attraverso un articolato sistema di autorizzazioni, la visualizzazione, l’accesso al sistema e l’imputazione/modifica dei dati ad un insieme di attori coinvolti nei processi di monitoraggio e rendicontazione. Il sistema è potenzialmente accessibile sia agli utenti regionali che ad utenti esterni, sia attraverso il collegamento alla rete Intranet regionale che attraverso la rete Internet. L’unica differenza tra le due modalità di accesso consiste nell’impossibilità di poter movimentare i dati finanziari via web, essendo il Bilancio esclusivamente accessibile dalla rete Intranet per motivi di sicurezza,.
18
Cfr. Appendice E. – Glossario
15/73
Il sistema non supporta la gestione di progetti finanziati con fondi FAS, per i quali 19
l’Amministrazione si avvale esclusivamente del sistema nazionale Applicativo Intese (AI) . Per
gli
interventi
FEOGA
il
Dipartimento
gestionale/documentale delle pratiche , il
competente
utilizza,
come
sistema
sistema denominato “Assagri” e, successivamente,
gestisce i dati di attuazione in Rendiconta; per il periodo 2007 – 2013 l’Autorità di gestione del Piano per lo Sviluppo Rurale (Dipartimento Agricoltura) si doterà di un diverso sistema gestionale e di monitoraggio locale degli interventi. Nelle more della realizzazione del Sistema Informativo Unitario (SIURP) il sistema “Rendiconta” è attualmente utilizzato anche per il monitoraggio e la rendicontazione all’Unione Europea dei progetti finanziati nell’ambito della nuova programmazione 2007-2013. A tal proposito, dovrà essere previsto, dettagliato ed effettuato uno specifica sezione del “Piano di transizione dei sistemi” per la migrazione dei dati relativi alla nuova programmazione 2007-2013 da “Rendiconta” al nuovo sistema, indicando anche la mappatura funzionale e gli accorgimenti adottati per garantire la transizione fra il vecchio ed il nuovo sistema tale piano dovrà essere presentato dal fornitore 6 mesi prima del collaudo del nuovo sistema ed approvato dall’Amministrazione Regionale. 2.3.1.1
Specifiche Tecnologiche
L’architettura tecnologica di Rendiconta è strutturata a tre livelli: •
nel primo livello, quello Client, si ha accesso alle funzioni specifiche del sistema. Le funzioni consistono di pagine HTML, attivabili tramite un comune Web Browser e sono generate dai Web Container del secondo livello;
•
Il secondo livello contiene un componente specializzato di tipo J2EE Web Container che gestisce le richieste dei client effettuate tramite il protocollo HTTP e genera dinamicamente ciò che viene visualizzato ed elaborato sul client – tipicamente nella forma delle pagine HTML. La generazione utilizza gli standard basati su Java Server Pages (JSP) e Java Servlet. Inoltre il secondo livello ospita la logica applicativa (“business logic”), che è realizzata con classi Java che accedono al database e predispongono i dati per le applicazioni client.
•
19
Il terzo livello contiene il DBMS gestore della base dati (il DBMS utilizzato è Oracle 9i).
Per un maggiore dettaglio si vedano i par. 2.1.1 e ss.
16/73
Figura 4 – Architettura tecnologica del componente Rendiconta
2.3.2
Contabilità Finanziaria
Il sistema di contabilità finanziaria è il sistema per la gestione del Bilancio Regionale e quindi per la generazione delle scritture contabili di impegno e liquidazione a valere sul bilancio regionale, Tale sistema, non oggetto di realizzazione con il presente intervento, è interfacciato con il sistema Rendiconta attraverso un componente intermedio denominato “GEMA” che viene utilizzato come mediatore per consentire il colloquio e l’allineamento, quando richiesto dalle fasi di processo, tra la gestione degli interventi, in Rendiconta, e i relativi impegni/richieste di liquidazione e conseguenti pagamenti in contabilità finanziaria. Ogni atto di impegno e di liquidazione a valere su di un Programma Operativo viene elaborato dal Bilancio solo in presenza di una richiesta da parte di Rendiconta, a cui restituisce gli estremi degli atti una volta registrati e archiviati successivamente nella gestione Decreti e Delibere. Ai fini dell’avanzamento finanziario di progetto il sistema gestisce i capitoli di spesa, gli impegni di progetto, gli impegni di selezione nonché le specifiche spese afferenti al progetto. 2.3.2.1
Specifiche Tecnologiche
Si forniscono di seguito le specifiche architetturali e tecnologiche del sotto-sistema: •
tools di sviluppo: IBM-WSAD vers. 5.1.2
•
ambiente: Z-LINUX SLES 10.1 – WEBSPHERE 5.1.1 – JDK 1.4.2 – IBM DB2 vers. 8.1
•
n. tabelle: 125. 17/73
2.3.3
SCOPRO
Il sistema SCOPRO è il Data Warehouse dell’Amministrazione regionale; esso è costituito da un’unica base dati nella quale sono riconosciute, derivate e riconciliate le informazioni provenienti da diverse sorgenti informative, ovvero sia le banche dati dei sistemi gestionali regionali sia sorgenti informative estratte da internet. Le informazioni, una volta integrate, sono rese disponibili su specifiche aree tematiche. Per gli interventi di integrazione e aggiornamento del Data Warehouse nell’ambito del della realizzazione del Sistema Informativo dell’Amministrazione Regionale (S.I.A.R.) si veda il par. 2.4. 2.3.3.1
Specifiche Tecnologiche
L’ambiente di esercizio è costituito da un ambiente di front-end e un ambiente di back-end. In particolare il server web (Application server) contenente il portale è posto nella VLAN di front-end e su tale server risiede anche la componente Universal Web Agent (UWA) del sistema di autenticazione forte, che protegge le risorse web attraverso la richiesta dei diritti di accesso alle altri componenti del sistema di autenticazione forte, poste nella VLAN di back-end. Nella VLAN di back-end risiedono due server RedHat Linux – Oracle in cluster, un server di text-mining e due postazioni di gestione. Il portale SCOPRO realizzato in PLSQL sfrutta la tecnologia Oracle. L’aggiornamento del DW è garantito da un insieme di procedure ETL che, operando le opportune selezioni ed estrazioni dei dati, consentono il caricamento degli stessi in maniera continua, salvaguardando la coerenza delle informazioni presenti. La struttura del DW si basa su un’architettura a tre livelli logici: •
sorgenti informative: sono comprese, a titolo esemplificativo, le banche dati del sistema il Bilancio Regionale, Rendiconta, Bilancio Regionale, Decreti e Delibere, ISTAT, ecc.;
•
integrazione: livello preposto all’integrazione, storicizzazione e memorizzazione, in una banca dati riconciliata, delle informazioni provenienti dalle varie sorgenti informative;
•
conoscenza: rende disponibili le informazioni del livello integrazione sui Data Mart realizzati su specifiche aree tematiche. Le diverse astrazioni consentono di aggregare i dati secondo più prospettive e più livelli di dettaglio. Tali astrazioni possono essere realizzate direttamente nelle “business areas” e in tal caso vengono attivate direttamente in fase di interrogazione dei dati, oppure possono essere “materializzate” e quindi vengono alimentate nel processo di aggiornamento del Data Warehouse. 18/73
Si forniscono di seguito le specifiche architetturali e tecnologiche di SCOPRO: •
tools di sviluppo: Oracle Discoverer Plus Administration, Oracle Warehouse Builder, ORACLE PLSQL
• 2.3.4
ambiente: RedHat Linux – Oracle in cluster Windows. Contratti
Il sotto-sistema contratti é il sistema per la gestione dei contratti assunti dall’amministrazione regionale; esso si articola nei due moduli di seguito descritti: •
il modulo “workflow contratti” gestisce il processo amministrativo a partire dalla predisposizione e inserimento del numero di repertorio delle obbligazioni contratte dai singoli Dipartimenti regionali, una volta che tutte le informazioni utili sono state registrate, il workflow si completa con la liquidazione della prima rata in scadenza;
•
per i pagamenti successivi o per la specializzazione delle obbligazioni si procede con il modulo “gestione contabile contratti”; il modulo registra tutti i dati relativi ai contratti in essere presso l’Amministrazione regionale e gestisce lo scadenziario dei pagamenti, espletando la fase di liquidazione dell’obbligazione interfacciandosi direttamente con il sottosistema contabile. Per le obbligazioni aventi come voce “acquisto servizi/consulenza” il modulo è in grado di generare tutte le voci sia di competenza che di ritenuta, contrattualmente previste.
Per gli interventi di integrazione e aggiornamento del sotto-sistema contratti va tenuta in considerazione la realizzazione del Sistema Informativo dell’Amministrazione Regionale (SIAR). 2.3.4.1
Specifiche Tecnologiche
Si forniscono di seguito le specifiche architetturali e tecnologiche del modulo “workflow contratti”: •
tools di sviluppo: IBM-WSAD vers. 5.1.2
•
ambiente: Z-LINUX SLES 10.1 – WEBSPHERE 5.1.1 – JDK 1.4.2 – IBM DB2 vers. 8.1
•
n. tabelle: 11
Le specifiche architetturali e tecnologiche del modulo “gestione contabile contratti” sono: •
tools di sviluppo: IBM-WSAD vers. 5.1.2 – Notes designer vers. 6.5
•
ambiente: Z-LINUX SLES 10.1 – Domino server vers. 6.5 – IBM DB2 vers. 8.1
•
n. tabelle: 11 19/73
2.3.5
Decreti e Delibere
E’ il sistema che gestisce il registro dei provvedimenti assunti ed è accessibile per consultazione a tutti i Dipartimenti dell’Amministrazione regionale. Gestisce le seguenti tipologie di atti: •
Delibere di Giunta
•
Decreti dirigenziali
•
Decreti del Presidente della Giunta.
Gli atti registrati vengono numerati a seconda della tipologia, a seguito della conclusione dell’iter previsto. La registrazione dei decreti e delle delibere viene effettuata dal Dipartimento n. 1. 2.3.5.1
Specifiche Tecnologiche
Si forniscono di seguito le specifiche architetturali e tecnologiche del sotto-sistema Decreti e Delibere: •
tools di sviluppo: IBM-WSAD vers. 5.1.2 – Notes designer vers. 6.5
•
ambiente: Z-LINUX SLES 10.1 – Domino server vers. 6.5 – IBM DB2 vers. 8.1
•
n. tabelle: 8.
2.3.6
Protocollo informatico
Il sistema di protocollo informatico sarà acquisito dall’Amministrazione regionale nell’ambito del S.I.A.R. in corso di realizzazione. In particolare l’amministrazione ha previsto l’implementazione di un sistema di protocollazione che consenta sia le funzioni di registrazione e classificazione previste dal D.P.R. 428/98, sia funzioni più avanzate di automazione dei flussi documentali mediante l’integrazione con il Document Management e il Workflow Management parimenti previsti nel capitolato. 2.3.7
Repository documentale
E’ il sistema che gestisce il repository dei documenti gestendo la loro archiviazione ed il versionamento. 2.3.7.1
Specifiche Tecnologiche
Si forniscono di seguito le specifiche architetturali e tecnologiche del sotto-sistema di Repository dei documenti: •
ambiente di sviluppo: .net, il sistema è inoltre nativamente accessibile tramite web service; 20/73
ambiente: Microsoft Server 2003, MS-sql Server, MS-SharePoint Services 2.0.
• 2.3.8
Anagrafica Dipendenti
Il sistema di anagrafica sarà acquisito dall’Amministrazione regionale nell’ambito del S.I.A.R. in corso di realizzazione (Sottosistema Informativo del Personale). In particolare, il nuovo sottosistema dovrà consentire la gestione economica (aspetti previdenziali, retributivi, ecc.) e giuridica (anagrafica) del personale dell’Amministrazione, nonché tutti gli aspetti legati allo sviluppo delle risorse umane (gestione carriere, formazione ecc.).
2.4
I progetti in corso
Si fornisce di seguito un elenco dei principali progetti/interventi in corso di realizzazione nella Regione Calabria e per i quali si richiede al fornitore di garantire un adeguato livello di coordinamento. 2.4.1
Il Sistema Informativo dell’Amministrazione Regionale
Il Dipartimento n. 2 della Presidenza della Regione Calabria ha avviato l’espletamento di una procedura di selezione per la progettazione, realizzazione e messa in produzione/conduzione, attraverso la fornitura dei necessari applicativi software, hardware integrativo e ulteriori servizi connessi, di un Sistema integrato informatico-telematico per la realizzazione del Sistema Informativo dell’Amministrazione regionale (SIAR). Nell’ambito di tale intervento è prevista sia la digitalizzazione dei documenti e dei principali flussi documentali e di lavoro riguardanti l’attività dell’amministrazione, sia la realizzazione della intranet e dei relativi servizi a supporto delle strutture amministrative. In particolare oggetto della fornitura è la realizzazione, entro 18 mesi dall’aggiudicazione e presso le strutture centrali e periferiche dell’Amministrazione regionale, delle seguenti attività: •
progettazione e realizzazione (anche tenendo conto delle preesistenze) del sistema tecnologico-telematico a supporto;
•
realizzazione del sistema dei servizi di base che costituiscono la intranet regionale (protocollo informatico, gestione documentale, archiviazione e conservazione dei documenti, posta elettronica certificata, firma elettronica, servizi di content/document management, workflow management, ecc.) e dei relativi servizi di completamento (interfacce con le applicazioni esistenti, recupero dati ecc.); 21/73
•
integrazione/realizzazione dei sottosistemi per la gestione del personale e di contabilità finanziaria ed economico-patrimoniale;
•
l’integrazione
e
l’evoluzione
del
DataWarehouse
dell’Amministrazione
(progetto
SCOPRO); •
conduzione e manutenzione, con attività di affiancamento e formazione al personale dell’Amministrazione, delle componenti hardware e software del sistema integrato per l’intero periodo contrattuale.
Per un maggiore dettaglio si rimanda alla documentazione di gara disponibile sul sito istituzionale della Regione. 2.4.2
La Stazione Unica Appaltante (SUA)
La Regione Calabria, in linea con le previsioni del Dgls. n. 163/2006, ha istituito, con una recente 20
legge regionale , un’autorità denominata “Stazione Unica Appaltante” avente il compito di assicurare la correttezza, la trasparenza e l’efficienza della gestione dei contratti pubblici. In base alle disposizioni della citata legge, la SUA avrà «il compito di svolgere l’attività di preparazione, indizione e di aggiudicazione delle gare concernenti lavori ed opere pubbliche, acquisizioni di beni e forniture di servizi a favore della Regione Calabria e degli Enti, Aziende, Agenzie ed Organismi da essa dipendenti, vigilati o ad essa collegati, per gli enti del servizio sanitario regionale, cui è fatto obbligo di ricorrere alla SUA nei modi e termini stabiliti dalla presente legge, nonché degli altri Enti pubblici della Calabria che intendono ricorrere alla SUA in regime di convenzione». L’attribuzione e la definizione delle funzioni di competenza della SUA, anche nel rispetto della normativa in materia di appalti e delle responsabilità affidate al Responsabile Unico di Procedimento, saranno oggetto di un regolamento che sarà adottato dal Direttore della struttura, la cui nomina è a cura del Presidente della Giunta regionale, previa designazione da parte di una commissione di valutazione appositamente costituita. Una volta istituita, alla Stazione Unica saranno affidate tutte le attività che vanno dalla definizione degli elementi essenziali del contratto e la valutazione di coerenza della tipologia di procedura prescelta in funzione delle prestazioni richieste, fino alla predisposizione della documentazione tecnica e amministrativa di gara,
20
Legge Regionale n. 26 del 7 dicembre 2007, successivamente integrato con le modifiche di cui alle L.R. 05 marzo 2008, n. 2.
22/73
all’esecuzione degli adempimenti amministrativi e procedurali connessi all’espletamento della procedura (nomina commissione, gestione delle opposizioni, comunicazioni di aggiudicazione, ecc.) e al monitoraggio infine degli stati d’avanzamento e della corretta esecuzione dei contratti. Si precisa che, una volta che la SUA sarà operativa, il modulo per la gestione delle procedure di evidenza pubblica dovrà prevedere l’interazione con tale soggetto. 2.4.3
Il progetto SAX - CNS
Il progetto SAX - Sistemi Avanzati di Connettività Sociale è un progetto finanziato con fondi FAS (delibera CIPE n. 83/2003) che si pone come obiettivo la diffusione della Società dell’informazione e l’accesso ai servizi erogati dalla Pubblica Amministrazione attraverso la concessione di contributi a famiglie e cittadini per l’acquisto di dotazioni informatiche e connettività. Parte delle risorse di tale intervento sono destinate all’acquisizione di smart card nell’ambito del Contratto Quadro CNIPA – RTI Actalis (mandataria), che definisce e disciplina l’appalto di servizi informativi e la fornitura di beni connessi alla realizzazione, distribuzione e gestione della carta nazionale dei servizi, in ragione dei corrispettivi economici fissati nel Contratto Quadro stesso. Sulla base delle disponibilità di risorse destinate a tale linea di intervento, l’Amministrazione intende dotare il personale regionale, e prioritariamente i funzionari e i dirigenti utenti del nuovo sistema SIURP, di CNS provviste del kit di firma digitale, al fine di consentire l’utilizzo delle funzionalità della firma anche all’interno dei processi di pianificazione, gestione e monitoraggio degli interventi POR e FAS.
23/73
3 Motivazioni del progetto SIURP Obiettivo del presente intervento è migliorare l’efficacia del complessivo processo di attuazione della politica regionale unitaria garantendo la rispondenza delle diverse fasi di pianificazione strategica, attuazione, monitoraggio e rendicontazione degli interventi regionali, in continuità con il precedente ciclo di programmazione 2000-2006, alle esigenze previste dal Quadro Strategico Nazionale per la programmazione 2007 – 2013 nonché al nuovo modello unico di monitoraggio. In particolare il presente intervento si pone all’interno di un percorso evolutivo definito dall’Amministrazione che, prendendo come riferimento (base di analisi) le funzionalità già implementate dall’attuale sistema informativo regionale di monitoraggio Rendiconta, consentirà la gestione di tutti gli interventi finanziati con fondi FAS e Fondi Strutturali attinenti il ciclo della nuova programmazione 2007-2013. Le motivazioni che hanno indotto l’Amministrazione ad operare in tal senso sono da un lato, il non dissipare gli investimenti fatti sul capitale umano (in termini di formazione e diffusione di una cultura all’uso del sistema informativo ai fini del monitoraggio e della rendicontazione) e su risorse e tempi spesi per mettere a punto strumenti e processi di monitoraggio e rendicontazione adeguati, e dall’altro, realizzare un modello architetturale orientato ai servizi (SOA), che permetta di raggiungere alcuni importanti benefici: •
maggiore flessibilità nel costante allineamento dei sistemi informatici ai processi informativi nelle aree della programmazione, monitoraggio, rendicontazione e reporting;
•
riduzione dei costi associati alla manutenzione ed evoluzione dei sistemi informativi regionali a supporto della programmazione;
•
disponibilità di una infrastruttura in grado accompagnare la futura evoluzione dei sistemi regionali nel corso degli anni;
•
disponibilità di un insieme di servizi infrastrutturali di base in grado di fornire servizi anche all’esterno del singolo Dipartimento Programmazione.
24/73
Figura 5
21
- Modello delle motivazioni
del SIURP
(goal, obiettivi, strategie e tattiche)
In particolare con il progetto SIURP il Dipartimento per la Programmazione Nazionale e Comunitaria della Regione Calabria intende porre in essere strumenti e procedure che, in 22
ottemperanza alle previsioni del Regolamento generale sui fondi strutturali , supportino il nuovo ciclo della programmazione 2007-2013 con il disegno e l’implementazione di un modello
21 22
Il modello segue l’OMG, Business Motivation Model (BMM) Specification, V1.0, www.omg.org Reg. (CE) n. 1083/2006 del 11.07.06.
25/73
organizzativo e dei processi relativi alla pianificazione strategica regionale allo scopo di migliorare l’efficacia nella fasi di pianificazione, realizzazione, monitoraggio e rendicontazione degli interventi che garantiscano adeguate piste di controllo nelle fasi di pianificazione, istruttoria, attuazione e rendicontazione di tutte le operazioni a valere sul nuovo ciclo della programmazione nazionale e comunitaria. Dal punto di vista degli obiettivi del progetto il sistema da realizzare dovrà essere in grado di: 1. assicurare la rispondenza con il modello unico di monitoraggio introdotto nel nuovo ciclo di programmazione e colloquiare con la Banca Dati Unificata (BDU) dell’IGRUE attraverso il c.d. Protocollo unico di colloquio e con Il protocollo del Codice Unico di Progetto (CUP) del CIPE; 2. supportare gli attori dei diversi Dipartimenti regionali nelle attività inerenti la programmazione strategica, la gestione, l’attuazione, il monitoraggio e la rendicontazione dei programmi e degli interventi finanziati con fondi strutturali e fondi FAS; 3. garantire l’integrazione con gli altri sotto-sistemi presenti in ambito regionale ed oggetto di evoluzione/integrazione nell’ambito dell’azione complessiva di ammodernamento delle strutture regionali (es. Contabilità finanziaria, ecc.); 4. supportare i Dipartimenti regionali ed in particolare un’unità organizzativa all’interno del Dipartimento della programmazione nella gestione delle procedure di evidenza pubblica. Il raggiungimento di questi obiettivi sono supportati da: •
la progettazione ed implementazione di un Sistema Informativo Unitario Regionale per la Programmazione, Gestione ed il Monitoraggio degli Investimenti Pubblici (SIURP)
23
oggetto di questo capitolato e basato su un modello architetturale orientato ai servizi 24
(SOA ) che privilegi l’integrazione e la cooperazione e che sia fondato sull’utilizzo di standard aperti e basato preferibilmente su open source. •
il supporto all’emissione di procedure di evidenza pubblica per la nuova programmazione unitaria realizzata tramite la progettazione ed avviamento di una Unità Organizzativa nell’ambito del Dipartimento di Programmazione Regionale dedicata a supportare l'intera Amministrazione nell'emissione di procedure ad
23
Service Oriented Architecture
24
Vedi: OASIS, Reference Model for Service Oriented Architecture 1.0, Oasis Standard, 12 October 2006, www.oasis-open.org
26/73
evidenza pubblica ed il loro successivo monitoraggio, e di una rete regionale dedicata alla gestione delle procedure di evidenza pubblica nell’ambito della programmazione 2007-2013.
27/73
4 Oggetto della fornitura Oggetto del presente capitolato è la fornitura dei servizi di analisi, progettazione, realizzazione, messa in esercizio e successivi servizi di assistenza e manutenzione del Sistema Informativo Unitario Regionale per la programmazione, attuazione e monitoraggio degli Interventi Pubblici (SIURP) della Regione Calabria. Tale sistema, anche prendendo come riferimento (base di analisi) gli attuali sistemi presenti in ambito regionale, in particolare il sistema Rendiconta, ed in coordinamento con il nuovo Sistema 25
Informativo dell’Amministrazione Regionale (SIAR) in fase di realizzazione , dovrà supportare l’intero ciclo della programmazione 2007-2013 in coerenza con le piste di controllo che afferiscono ai processi di pianificazione, gestione attuativa, monitoraggio e rendicontazione degli interventi regionali operando in modo indipendente dalle diverse fonti di finanziamento degli stessi (fondi FAS, fondi strutturali). Sono incluse nella presente fornitura i servizi di progettazione e realizzazione entro 12 mesi dall’aggiudicazione del sistema SIURP e di manutenzione ed assistenza per i successivi 48 mesi, 26
dei moduli/componenti, di seguito descritti , che dovranno: •
gestire i processi di programmazione/monitoraggio/rendicontazione, e il relativo flusso documentale, a valere sul ciclo 2007-2013 nonché l’allineamento al nuovo protocollo unico di colloquio predisposto dall’IGRUE per il colloquio con la Banca Dati Unificata;
•
gestire tutto il ciclo operativo delle procedure di evidenza pubblica, e il relativo flusso documentale, espletate dal Dipartimento Programmazione e dai diversi Dipartimenti presenti nelle struttura Regionale;
•
fornire a cittadini ed utenti finali, in attuazione dei principi sulla trasparenza e pubblicità, evidenza dello stato di attuazione di tutti i progetti cofinanziati con fondi comunitari e nazionali;
•
realizzare l’integrazione con gli altri sistemi/servizi coinvolti presenti in ambito regionale, non oggetto del presente intervento, elencati nel seguito del documento.
25
Cfr. par. 2.4.
26
Cfr. Par. 8.1 ed Appendice B.
28/73
Il sistema da realizzare dovrà seguire lo stile architetturale SOA (Service Oriented Architecture)
27
al fine di garantire agilità, facilità di integrazione ed allineamento ai processi dell’Amministrazione. Il supporto ai processi ed ai relativi flussi documentali dovrà essere garantito tramite l’utilizzo di un sistema di orchestrazione di processi o più propriamente di Business Process Management (BPM)
28
tale da consentire in maniera flessibile la possibilità di adeguamento del flusso di
processo alle esigenze in divenire del Dipartimento e dell’Amministrazione. Si
precisa
che
all’atto
della
formalizzazione
del
contratto,
potranno
essere
fornite
dall’Amministrazione regionale specifiche di maggiore dettaglio sia per quanto riguarda le piste di controllo del nuovo ciclo di programmazione sia per quanto riguarda gli aspetti tecnici e funzionali del sistema SIURP e le specifiche aggiornate del protocollo di colloquio IGRUE e del protocollo CUP
29
(Codice Unico di Progetto) oggetto del presente intervento.
Costituiscono altresì oggetto dell’intervento i servizi
di formazione, rivolti al personale
dell’Amministrazione regionale, all’utilizzo del sistema SIURP, ivi compresa la predisposizione dei manuali d’uso e manuali utente, come meglio di seguito specificato. La fornitura è comprensiva degli apparati HW/SW necessari allo sviluppo, testing ed esercizio del sistema e dei relativi servizi di assistenza ed estensione della garanzia a 48 mesi complessivi a partire dalla data di collaudo finale del sistema SIURP. Non è oggetto della fornitura la Porta di Dominio SPCoop
30
necessaria per lo scambio messaggi
tra Amministrazioni che sarà fornita dall’Amministrazione e che andrà integrata nel sistema SIURP. Al termine del periodo contrattuale è prevista, da parte dell’Aggiudicatario, la consegna all’Amministrazione di tutta la documentazione utile all’uso del sistema SIURP; negli ultimi sei mesi precedenti la conclusione del contratto è previsto un servizio di affiancamento all’Amministrazione o ad un soggetto terzo da questa indicato, eventualmente anche ad i fini del porting dell’ambiente e delle applicazioni su nuovi sistemi.
27 Vedi: OASIS, Reference Model for Service Oriented Architecture 1.0, Oasis Standard, 12 October 2006, www.oasis-open.org 28
Il BPM abilita, in modo agile, la gestione dei processi di lavoro combinando motori di orchestrazione di servizi e processi (es. basati su WS-BPEL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel) e linguaggi grafici di rappresentazione (basati oggi su BPMN: OMG, Business Process Modeling Notation, V1.1, www.omg.org). L’approccio model driven tipico degli strumenti BPM permette una elevata flessibilità nel management dei processi di business dell’organizzazione.
29 30
http://www.cipecomitato.it/cup/cup.asp Vedi: http://www.cnipa.gov.it
29/73
5 Metodologie ed attività previste 5.1
Metodologie di sviluppo
Un sistema complesso come il SIURP per la sua progettazione, per la gestione della transizione dei sistemi e per il governo della sua architettura SOA richiede adeguate metodologie di sviluppo e pianificazione che permettano di mantenere l’allineamento continuo dell’IT ai processi ed agli obiettivi regionali. E’ necessario quindi utilizzare appropriate metodologie e processi di sviluppo che descrivano e documentino in modo appropriato l’architettura (dei processi, informativa e tecnologica) con particolare riguardo ai servizi coinvolti comprendendo le regole, gli standard e le informazioni sul ciclo di vita dei sistemi per ottimizzare e mantenere l’ambiente operativo ed applicativo desiderato. In particolare andrà esplicitamente definito ed utilizzato un adeguato processo di sviluppo (es. UP, RUP, EUP, ICONIX, SCRUM, Model Driven Development etc). 5.2
Documentazione del sistema
La documentazione del sistema da realizzare dovrà essere predisposta secondo gli standard indicati in seguito e dovrà raccordarsi al processo di sviluppo definito. La qualità della documentazione del sistema realizzato è considerata un aspetto estremamente rilevante della fornitura. In relazione alle specifiche del sistema, la documentazione dovrà essere realizzata in forma documentale in formato .rtf e .pdf secondo template concordati ed allineati al processo di sviluppo i modelli ed i diagrammi dovranno essere conformi allo Unified Modeling Language (UML) versione 2.1
31
o sup. utilizzando il set di diagrammi adeguato per rappresentare sia gli aspetti strutturali (sia
a livello logico che di deployment) che comportamentali (behavior) del sistema complessivo e dei componenti. I modelli Interchange 2.1 o sup.)
dovranno essere rilasciati anche in formato XMI (OMG Xml Metadata 32
e tramite l’eventuale formato proprietario dello strumento di modellazione
concordato all’inizio del progetto. 33
dovranno
34
e tramite l’eventuale
Per la rappresentazione dei processi sarà utilizzato lo standard BPMN . I modelli essere rilasciati in formato XMI (OMG Xml Metadata Interchange 2.x)
31
Vedi http://www.uml.org.
32
Vedi: http://www.omg.org/spec/XMI/
33
Vedi http://www.bpmn.org
34
Vedi: http://www.omg.org/spec/XMI/
30/73
formato proprietario dello strumento di modellazione concordato all’inizio del progetto o, alternativamente, può essere utilizzato lo standard XPDL
35
I manuali utente dovranno essere predisposti, in relazione ad ogni singolo ruolo definito al paragrafo 10.1.1, con una descrizione dettagliata dei processi e delle funzionalità resi disponibili dalle soluzioni realizzate. 5.3
Attività
Per quanto riguarda il sistema nel suo complesso, le attività che devono essere svolte da parte della società aggiudicataria sono le seguenti: 1.
analisi dei processi della Regione. Tale attività comprende l’analisi dei processi regionali relativi alle attività di programmazione, gestione, monitoraggio e rendicontazione dei programmi e progetti del nuovo ciclo della programmazione nell’ambito della Regione Calabria, partendo da quanto già descritto nel presente capitolato tecnico e da quanto verrà fornito dall’Amministrazione all’atto dell’aggiudicazione, la rilevazione di ulteriori oggetti informativi esistenti ed utilizzati, la rilevazione della mappatura dei sottosistemi applicativi e delle basi dati presenti presso gli attori del sistema. L’analisi deve prevedere l’integrazione con i progetti già in fase di realizzazione e con i sistemi informativi che attualmente sono in funzione e che saranno mantenuti e la razionalizzazione dei flussi che dal territorio vengono inviati alla Regione e ai Ministeri. L’amministrazione, inoltre, a supporto della fase di analisi e dell’intero processo di sviluppo individuerà e coinvolgerà nel processo un gruppo di key user, 36
intesi come utenti tipo ed esperti del dominio del sistema da realizzare ; 2.
definizione e disegno del SIURP. Tali attività comprendono, a partire dal modello di riferimento illustrato in questo capitolato e a dettagli ulteriori forniti all’atto della contrattualizzazione, la definizione della vision complessiva del sistema, il disegno di ogni componente applicativo/di servizio del nuovo sistema informativo da realizzare ed il disegno, per ogni componente oggetto della fornitura, del modello organizzativo di riferimento e dei relativi processi, tenendo conto della necessità di integrare il nuovo sistema con i componenti già in fase di realizzazione e con i sistemi informativi che saranno mantenuti a regime. Il disegno comprende le attività di definizione delle interfacce dei servizi e le
35 36
Vedi: http://www.wfmc.org/ Cfr. per ulteriori dettagli il Par. 10.1.2 Key users e community di progetto
31/73
parallele attività di armonizzazione dei metadati e dei nomenclatori comuni utilizzati (canonical data model); 3.
progettazione del piano di governance del sistema. La definizione del piano è necessaria 37
ai fini del governo nel tempo della SOA ; 4.
progettazione ed implementazione del Piano di Sicurezza del sistema per tutta la durata contrattuale, tenuto conto delle funzioni e delle infrastrutture tecnologiche che vengono messe a disposizione dalla Regione Calabria;
5.
definizione ed attuazione del piano di transizione dei sistemi che pianifica e descrive la migrazione dai sistemi preesistenti (es. sistema Rendiconta) al sistema obiettivo a regime: l’importanza dei servizi erogati agli utenti richiede che venga dettagliato, oltre al piano generale dei rilasci, anche il piano che garantisca la continuità dei servizi prevedendo la migrazione dei dati
38
e dei servizi erogati dagli attuali sistemi informativi dell’Amministrazione
verso la soluzione proposta. L’impresa concorrente dovrà quindi prevedere uno specifico piano di transizione, con indicazione delle strategie di migrazione, tempi e metodologie. Il “piano di transizione dei sistemi” deve considerarsi impegnativo per l’Aggiudicatario e dovrà essere presentato 6 mesi prima del collaudo del nuovo sistema e sarà soggetto all’approvazione dell’Amministrazione; 6.
definizione
del
programma
di
change
management,
con
particolare
riguardo
all’elaborazione ed attuazione del piano per la formazione, che dovrà dettagliare le attività di formazione rivolte al personale dell’amministrazione e agli altri utenti esterni del sistema, in fase di avvio e messa in esercizio dello stesso, ai fini dell’utilizzo del SIURP in base alle diverse tipologie di utenza; 7.
elaborazione del Piano di progetto e del piano della qualità. Essi rappresentano strumenti indispensabili per il buon esito della fornitura di servizi complessi, e devono essere utilizzati come una guida durante i controlli e gli audit durante la vita dell’appalto. Il Piano di progetto e il piano della qualità dovranno essere presentati rispettivamente entro 30 ed entro 45 giorni dalla data di avvio delle attività. Il Piano di progetto (unitamente al piano della qualità) deve essere monitorato con una frequenza regolare e rappresenta uno strumento fondamentale per il raggiungimento degli obiettivi;
37
Service Oriented Architecture.
38
Per ciò che concerne la Nuova programmazione 2007-2013
32/73
avviamento e messa a punto del nuovo sistema informativo nel suo complesso e di ogni
8.
suo componente; 9.
messa in esercizio e conduzione del sistema in operatività;
10.
organizzazione e gestione dei servizi di help–desk operativo nei confronti sia dei key user che degli utenti finali di ciascuna applicazione prevista da ciascun componente applicativo/di servizio oggetto di fornitura;
11.
assistenza e garanzia e manutenzione correttiva, per ciascun componente oggetto della fornitura;
12.
manutenzione evolutiva e adeguativa per ciascun sotto-sistema oggetto della fornitura e delle componenti di integrazione con i sotto-sistemi non oggetto della fornitura per il periodo contrattuale;
13.
servizi di assistenza sistemistica, di assistenza applicativa, servizi di assistenza tecnica in generale per tutti i componenti applicativi/di servizio oggetto della fornitura;
14.
predisposizione del piano attraverso il quale vengono regolate le attività di affiancamento e presa in carico di quanto realizzato nel progetto al personale dei Sistemi Informativi Regionali o ai soggetti diversamente indicati dall’Amministrazione regionale.
Per quanto riguarda i componenti applicativi/di servizio del SIURP che fanno parte della fornitura delle attività che devono essere svolte (fornitura di servizi) per ciascuno di essi da parte della società aggiudicataria sono le seguenti: 1.
sviluppo/personalizzazione di ogni componente del SIURP da realizzare: lo sviluppo comprende le integrazioni di ogni nuovo componente realizzato con gli altri sottosistemi già in fase di realizzazione e con i sistemi informativi attualmente in uso e che continueranno a far parte del nuovo;
2.
progettazione del capacity planning per ogni sottosistema e per il SIURP nel suo insieme. I servizi di supporto al capacity planning devono produrre la definizione e tuning delle componenti HW/SW di base della piattaforma tecnologica di test, di sviluppo e di produzione, HW/SW di base che dovrà essere oggetto di fornitura e che dovrà essere predisposto ed operante presso la server farm della Regione Calabria. In questa attività rientra anche il dimensionamento dei sistemi middleware e dei sistemi per la gestione dei dati (RDBMS) di tutto il “SIURP” ed in generale di tutti si servizi. Nel progetto di capacity planning dovrà essere collocata la proposta per il disaster recovery; Parte del piano è 33/73
anche la definizione dei requisiti minimi HW/SW e di servizio (es. banda minima) non compresi nella fornitura ma che tuttavia sono indispensabili all’operatività del sistema. Questi aspetti in particolare dovranno essere anticipati nella fase di definizione e disegno del SIURP in modo da poter definire insieme all’amministrazione le strategie di adeguamento senza che questi aspetti possano risultare un blocco all’operatività del sistema all’inizio della fase di esercizio. 3.
Piano di collaudo del sistema nel suo complesso e di ogni suo componente;
4.
effettuazione del collaudo tecnico e funzionale delle varie componenti di ciascun sottosistema e collaudo complessivo del sistema informativo;
5.
effettuazione del collaudo di integrazione dei componenti nell’ambito del SIURP.
34/73
6 Profili professionali richiesti Il progetto è coordinato da una Direzione Lavori dell’Amministrazione Regionale. In considerazione degli obiettivi del progetto, il team di consulenza dovrà comprendere risorse di elevata seniority a cui è richiesta una provata competenza nell’ambito della progettazione ed implementazione di architetture SOA/ESB. Andranno forniti nell’offerta i tutti i curricula del team proposto. Nel progetto va prevista la copertura dei seguenti ruoli: E’ responsabile per la raccolta e l’analisi dei requisiti per i processi (nell’ambito dell’Amministrazione Regionale). Identifica le collaborazione tra gli attori, e identifica le informazioni necessarie al processo ed inizia a comprendere gli insiemi di informazioni (documenti, messaggi) che vengono trasferiti tra gli attori. Produce
Business Analyst
l’analisi dei processi e esprime i contenuti informativi tramite diagrammi UML, BPMN e Use Case Narrativi. E’ necessaria quindi la capacità di operare con standard di business modeling come UML e BPMN. E’ richiesta un’esperienza di almeno 5 anni nell’analisi di processo e di almeno due anni sulle metodologie basate su UML e BPMN.
E’ responsabile della definizione delle soluzioni tecnologie opzionali, della definizione e la revisione degli standard e del disegno e l’implementazione delle soluzioni. Supporta la strategia tecnologica complessiva e l’ingegnerizzazione dei processi. E’ responsabile per l’integrazione applicativa. Governa dal punto di vista tecnico il team
Technical Architect
di sviluppo. Sono richiesti 5 o più anni di esperienza nel ruolo ed almeno 10 anni di esperienza nella realizzazione di software e nell’information tecnology. In particolare è richiesta esperienza in architetture software di media e grande dimensione, sviluppo basato sui componenti. E’ inoltre particolarmente rilevante, date le caratteristiche del progetto, l’esperienza nell’implementazione di SOA.
Avrà il ruolo di project management, in termini strategici e operativi. Il candidato ideale
Project management e gestione del cambiamento
ha un’esperienza almeno decennale come consulente o project manager presso enti pubblici o privati o in società di consulenza nell’ambito di progetti di IT e change management.
Sono richiesti 3 o più anni di esperienza nel ruolo od equivalente ed almeno 10 anni di esperienza
Analista Programmatore
nell’Information
Tecnology.
Deve
essere
competente
programmazione OO, CDB. Design Pattern, UML modeling, E’ richiesta l’esperienza sull’implementazione di webservice e con tecnologie middleware.
35/73
nella inoltre
Supporta l’architetto nella definizione del disegno dell'architettura del sistema per ciò che concerne il dimensionamento, le funzionalità del sistema operativo e l'utilizzo di programmi di utilità per lo sviluppo delle applicazioni, le interazioni fra software e
Sistemista Esperto
hardware. Supervisiona la gestione del software di base e di sistema e tutte le interazioni con l'ambiente applicativo. E’ richiesta un’esperienza di 10 anni di cui 5 nel ruolo.
Partecipa alla pianificazione, alla definizione di fattibilità e alla valutazione dei costi per i progetti nei quali è coinvolto, riferisce periodicamente sull'avanzamento delle attività, evidenziando gli scostamenti e proponendo gli interventi ritenuti idonei per il
Assistente sistemista
mantenimento dei piani di deployment, risponde direttamente dei tempi di rilascio dei sistemi di sviluppo, testing ed esercizio e dell'ottimizzazione dell'impiego delle risorse. E’ richiesta un’esperienza di 5 anni.
Effettua l'installazione, il collaudo, la manutenzione e la riparazione dei prodotti hardware, software e di connettività curandone la messa a punto e il funzionamento presso il cliente. Schedula le manutenzioni preventive e attrezzandosi per le
Installatore/manutentore hardware, software, reti
manutenzioni straordinarie, compila, se del caso, la documentazione relativa alle prestazioni effettuate. Provvede all'installazione, al tuning e alla manutenzione dei prodotti software applicativi e per il funzionamento della rete, fornisce primo supporto all'utente su problematiche relative agli applicativi ed alla rete, E’ richiesta un’esperienza di 3 anni.
36/73
7 Macro-requisiti funzionali 7.1
La programmazione, selezione, attuazione e monitoraggio degli investimenti pubblici
L’IGRUE, in ottemperanza alle previsioni del QSN e al regolamento generale sui fondi strutturali n. 1083/2006, ha elaborato un documento di linee guida sui sistemi di gestione e controllo della 39
programmazione 2007-2013 . In continuità con il precedente ciclo di programmazione, anche per ciò che attiene la gestione della programmazione 2007-2013 la correttezza e la regolarità delle spese rendicontate nell’ambito di ciascun programma operativo può essere garantita, attraverso la definizione di appropriati strumenti organizzativi e procedurali. A livello operativo, la definizione di procedure gestionali e di controllo adeguate (c.d. “piste di controllo”) è in capo all’Autorità di 40
Gestione . La pista di controllo costituisce uno strumento organizzativo finalizzato a pianificare e gestire le attività di controllo nell’ambito del sistema di gestione dei programmi finanziati con i fondi strutturali. A seconda della tipologia di operazione che occorre implementare (realizzazione di opere pubbliche, acquisizione di beni e servizi, erogazione di finanziamenti e servizi a singoli destinatari, servizi di formazione), attraverso le piste di controllo sono individuate e descritte le principali attività (di tipo progettuale, fisico, amministrativo, finanziario e di controllo) da porre in essere nell’implementazione di gruppi omogenei di operazioni finanziate nell’ambito di ciascun Programma Operativo. Secondo una metodologia basata sull’analisi dei processi, le piste di controllo individuano e rappresentano, in un flusso di attività (processi), l’insieme delle attività da effettuare, identificando i soggetti responsabili della loro esecuzione, eventuali altri soggetti coinvolti, deliverables, tempi e tipologie di controlli ad esse associati. In sintesi, il ciclo di vita di un’operazione o progetto corrisponde a un macroprocesso astratto comprendente un insieme di processi, ma ha caratteristiche specifiche in dipendenza dalla 41
tipologia (macroprocesso IGRUE) :
39
IGRUE, Linee guida sui sistemi di gestione e controllo per la programmazione 2007 – 2013, 19-apr-2007.
40
I criteri per la definizione dell’adeguatezza di ciascuna pista di controllo sono definiti all’art. 15 del regolamento (CE) n. 1828/2006.
41
Il documento IGRUE citato individua 8 tipologie di macroprocesso.
37/73
Figura 6 – Fasi, processi e tipologie Un macroprocesso gestionale di un’operazione o progetto a prescindere dalle caratteristiche specifiche della tipologia può quindi essere scomposto nelle seguenti fasi che comprendono la 42
struttura astratta del processi : •
Programmazione: comprende tutte quelle attività preliminari che vanno dall’approvazione del programma operativo fino alla predisposizione delle procedure necessarie alla corretta attuazione delle operazioni; sono comprese in questa fase le attività volte alla definizione dei criteri di selezione delle operazioni.
•
Selezione e approvazione delle operazioni: comprende le fasi in cui vengono selezionate le operazioni e i beneficiari finali, ovvero gli attori che partecipano, in senso stretto, alla
42
L’Allegato A descrive la struttura astratta dei processi del dominio. Questi processi subiscono una specializzazione a seconda della particolare tipologia di macroprocesso IGRUE (vedi documento) che sarà dettagliato nelle Piste di Controllo. Si vuole far notare qui che i diversi macroprocessi specifici mantengono una struttura in larga parte omogenea.
38/73
realizzazione dell’obiettivo specifico/settore. Si tratta di una fase cruciale fortemente dipendente dalla tipologia di operazione/titolarità. •
Attuazione fisica e finanziaria: comprende le attività di selezione dei soggetti attuatori/soggetti appaltatori e le attività di esecuzione dei progetti ammessi al finanziamento, ivi compreso il pagamento delle spese sostenute a stati di avanzamento. Le attività corrispondenti a tale fase sono individuate a seconda della tipologia di operazione/titolarità.
•
Certificazione della spesa e circuito finanziario: si tratta delle attività periodiche di certificazione della spesa e rendicontazione all’Unione Europea, per il tramite dell’IGRUE, delle spese sostenute, ai fini della ricezione del contributo comunitario.
La rappresentazione delle piste di controllo verrà effettuata mettendo in evidenza l’articolazione del processo in attività. In particolare, i processi saranno differenziati in funzione di due criteri: •
la tipologia di operazioni: opere pubbliche, acquisizione di beni e servizi, erogazione di finanziamenti e/o servizi a singoli beneficiari, formazione;
•
la titolarità della responsabilità gestionale: operazioni a titolarità/regia dell’Amministrazione che gestisce il programma.
La definizione e l’aggiornamento delle piste di controllo è demandato all’Amministrazione regionale ed in particolare al Dipartimento della Programmazione Nazionale e Comunitaria (Autorità di Gestione) in coordinamento con i responsabili di asse/settore prioritario e ai beneficiari finali e con il supporto delle unità operative verifiche e controlli istituite presso ciascun dipartimento di competenza. Il modello dei dati minimo di riferimento per le piste di controllo è definito per la parte operativa e di 43
rendicontazione dal Protocollo Unico di Colloquio IGRUE . 7.2
Il supporto alla Programmazione
Per il supporto alla definizione della programmazione e del tracciamento di obiettivi ed azioni a partire dalle scelte strategiche nazionali e regionali dovrà essere supportato lo standard OMG, Business Motivation Model
44
(BMM) di cui la Figura 7 rappresenta una vista di alto livello.
43
Vedi: Allegato C. La versione aggiornata del Protocollo Unico di Colloquio sarà fornita all’atto della contrattualizzazione.
44
OMG, Business Motivation Model (BMM) Specification, v1.0, www.omg.org
39/73
Figura 7 – Overview di BMM45
BMM è un meta-modello
46
che consente di catturare e giustificare in modo rigoroso cosa
un’organizzazione (come una Regione) si prefigge di ottenere, come pianifica di ottenerlo e come sono valutati i risultati delle proprie azioni. Uno degli aspetti rilevanti di BMM è quindi la possibilità di distinguere in modo chiaro i diversi elementi di un piano di business come Fini, Azioni, Direttive, Influencer e Valutazioni degli impatti collegandoli ai processi ed alle unità organizzative coinvolte. La successiva Figura 8 illustra la progressione logica sottostante BMM. Lo scopo di BMM è permettere la costruzione e la tracciatura coerente dei piani e delle azioni definiti dalla regione a partire dagli obiettivi generali definiti a livello Nazionale e regionale 47
distinguendo la gerarchia degli obiettivi generali (ed in generale tutti i fini non quantificati ) e la 48
gerarchia degli obiettivi specifici (quantificati e con un time-frame definito ). I fini possono essere
45
Tratto da: OMG, Business Motivation Model (BMM) Specification,, V1.0, www.omg.org
46
Un meta-modello è un modello che descrive il linguaggio utilizzato in un modello che descrive un mondo reale.
47
“Goal” in termini BMM.
48
“Obiective” in termini BMM.
40/73
così messi in relazione con le strategie e le azioni definite e associati con le unità organizzative responsabili ed i processi/piste di controllo con la valutazione dei risultati.
Figura 8 – Processo logico sottostante il BMM49
Il poter mettere in relazione diretta gli elementi dei piani, altrimenti dispersi in un insieme di documenti nazionali e regionali, e la realizzazione delle azioni permetterà di migliorare il livello della pianificazione e la sua integrazione con i processi di realizzazione degli interventi e di monitoraggio dei risultati. L’uso di BMM permette inoltre di mappare anche alcune differenze terminologiche tra i diversi documenti strategici e piani riconducendole ad uno schema concettuale comune. Questo approccio dovrà permetterà inoltre la generazione del cuore dei documenti programmatici previsti
50
permettendo un migliore controllo della loro coerenza.
Il modello BMM insieme alle Piste di Controllo (processi) dovrà essere utilizzato come base della specifica del sistema SIURP.
49
Tratto da: OMG, Business Motivation Model (BMM) Specification,, V1.0, www.omg.org
50
Dovrà venire generata almeno tutta la struttura di Obiettivi generali, specifici ed i relativi indicatori, delle strategie ed azioni individuate.
41/73
7.3
Processi e piste di controllo
Nell’Appendice A del presente capitolato tecnico, sono rappresentati, a titolo esemplificativo e non esaustivo, i modelli astratti dei principali processi
51
che sottendono le fasi di programmazione,
gestione, monitoraggio e rendicontazione dei programmi e progetti del nuovo ciclo della programmazione nell’ambito della Regione Calabria.
Figura 9 – Fasi delle piste di controllo e processi del sistema SIURP
In particolare, nella fase di analisi preliminare, sono stati identificati e disegnati
52
a titolo non
esaustivo, una serie di processi tipo implementati dalle strutture regionali nel corso della gestione e attuazione del ciclo di programmazione. In ciascuno dei processi così definiti sono individuati gli attori coinvolti, le tipologie di attività, eventuali vincoli/condizioni all’espletamento delle stesse e gli oggetti informativi scambiati tra i diversi attori del processo. Negli stessi sono ad esempio rappresentati, anche se non identificati in un processo a se stante, i controlli di primo livello che vengono effettuati dai responsabili di misura/linea di intervento. I processi rappresentati sono stati definiti a partire dalle fasi in cui si articolano le piste di controllo. Essi costituiscono una rappresentazione, seppure ad alto livello, delle piste di controllo che
51
Vedi Figura 9.
52
Per la rappresentazione dei modelli dei processi si utilizza la notazione basata sullo standard BPMN. OMG, Business Process Modeling Notation, V1.1, www.omg.org
42/73
verranno definite dal Dipartimento della Programmazione di concerto con i Dipartimenti competenti per materia e consegnate al fornitore all’atto dell’aggiudicazione. Obiettivo della rappresentazione dei processi nell’Appendice A è di agevolare la comprensione dei requisiti funzionali del sistema SIURP. Il sistema oggetto del presente capitolato dovrà infatti essere in grado di supportare l’Amministrazione nella gestione dell’intero ciclo della programmazione 2007-2013, anche attraverso l’orchestrazione delle piste di controllo definite dall’Amministrazione. A tal proposito si precisa che con i modelli dei processi di seguito rappresentati sono ipotizzate le attività da informatizzare
e
non,
e
che
all’atto
dell’aggiudicazione
potranno
essere
fornite
dall’Amministrazione delle specifiche di maggiore dettaglio che saranno poi analizzate e ulteriormente sviluppate dall’aggiudicatario.
43/73
8 Architettura di riferimento 8.1 Il
Componenti e integrazione sistema
informativo
oggetto
del
presente
capitolato,
come
già
esplicitato,
dovrà
complessivamente essere realizzato mediante l’utilizzo di un modello architetturale orientato ai 53
servizi (SOA ) che garantisca sia il coordinamento/orchestrazione dei servizi offerti dai vari componenti oggetto di realizzazione, sia l’integrazione con i sistemi esistenti ed in corso di realizzazione in ambito regionale. La realizzazione, di conseguenza, dovrà seguire i comuni principi di disegno delle SOA, in particolare segnaliamo alcuni dei tipici elementi del paradigma della service orientation: •
Standardizzazione dei service contract. Curando il modo in cui le funzionalità sono espresse, la definizione dei datatype e del modello dei dati, e la definizione delle policy. Vi deve essere un’attenzione costante alla ottimizzazione ed alla appropriata granularità dei servizi ai fini di assicurare che i servizi siano consistenti affidabili e governabili.
•
Loose Coupling. Va garantita l’indipendenza del disegno e l’evoluzione della logica di business di ogni servizio garantendo simultaneamente l’interoperabilità con i consumer dei servizi.
•
Astrazione. Il disegno deve curare che i servizi occultino il più possibile i dettagli interni del servizio.
•
Riusabilità. I servizi devono essere progettati e realizzati in modo da favorire la loro riusabilità pensandoli come risorse dell’organizzazione il piu’ possibile agnostiche rispetto al contesto funzionale.
•
Autonomia. I servizi sia per quanto concerne la logica come per l’ambiente di implementazione devo minimizzare la loro dipendenza.
•
Service Statelesseness. Idealmente, i servizi devono rimenere stateful (gestire il proprio stato) solo quando necessario.
In tale contesto viene riportato di seguito un modello di riferimento che evidenzia dal punto di vista architetturale l’insieme dei componenti di servizio (building-block) oggetto del nuovo sistema (in
53 Vedi: OASIS, Reference Model for Service Oriented Architecture 1.0, Oasis Standard, 12 October 2006, www.oasis-open.org
44/73
giallo e con lo stereotipo <>) nonché le integrazioni con i sistemi esistenti (in avana e con lo stereotipo <>). Lo stereotipo <>, in questo contesto, vuole indicare che i componenti sono intesi come “blocchi” funzionali a livello non strettamente tecnologico e che sarà cura dell’aggiudicatario definire in fase di disegno dell’architettura SOA i componenti di servizio alla loro appropriata granularità. Rispetto al modello presentato l’aggiudicatario potrà effettuare proposte migliorative sempre però 54
tenendo presente l’orientamento architetturale indicato . Come si evince dal modello sono oggetto di realizzazione/fornitura nell’ambito del presente intervento, e fatto salvo quanto specificato nelle altre parti del presente documento, i componenti applicativi/di servizio: 1. Programmazione 2. Gestione Interventi 3. Procedure ad Evidenza pubblica 4. Sistema ESB (Enterprise Service Bus) 5. Sistema ausiliario di gestione anagrafica 6. Registry dei servizi, (se non integrato nella soluzione ESB) 7. Web Pubblico progetti 8. SIURP Front-end 9. Reporting System. Sono inoltre oggetto di realizzazione le seguenti interfacce principali (l’elenco non è necessariamente esaustivo): 10. interfacce con il modulo di gestione Decreti e Delibere 11. interfacce con il sistema di Protocollo Informatico 12. interfacce con il sistema di Contabilità Finanziaria 13. interfacce con il sistema di Gestione Contabile Contratti 14. interfacce con il sistema di Repository Documentale 54
Nel capitolato i componenti applicativi/di servizio sono disegnati a livello logico come building-block (mattoni) del sistema SIURP. L’aggiudicatario dovrà, ovviamente, disegnare l’architettura tecnica dei componenti proponendo la soluzione concreta che realizzi i componenti astratti definiti nel capitolato.
45/73
15. interfacce con il sistema di DataWareHouse 16. interfacce con il sistema cartografico 17. interfacce con il sistema Anagrafico Dipendenti 18. interfacce con l’anagrafica dei dipendenti regionali 19. interfacce con le componenti della firma digitale 20. interfacce con la Porta di Dominio SPCoop 21. interfacce con il sistema CUP 22. interfacce DEL componente di Reporting 23. interfacce DEL componente di Programmazione 24. interfacce DEL componente di Gestione degli Interventi 25. interfacce DEL componente di Procedure ad Evidenza pubblica 26. interfacce DEL componente di Service Registry (se non parte del sistema ESB) 27. interfacce DEL componente di Web Pubblico Progetti 28. interfacce DEL componente di Anagrafico Ausiliario (Anagrafica AUX). Dove funzionalmente opportuno le interfacce potranno essere realizzate, inoltre, anche in modalità 55
batch .
55
Ad esempio questo è previsto nel protocollo CUP.
46/73
Figura 10 - Architettura obiettivo 47/73
In relazione alle interfacce presentate si rende opportuno sottolineare che nel rispetto del modello architetturale indicato queste dovranno essere realizzate come segue: nel caso delle componenti oggetto di realizzazione, si dovrà prevedere, a
o
valle dell’analisi di dettaglio dei processi presentati, l’individuazione dei servizi che ciascun componente renderà disponibile agli altri e pubblicherà nel registry dei servizi; nel caso delle componenti NON oggetto di realizzazione si dovrà
o
prevedere lo sviluppo, anche mediante le funzionalità rese disponibili dal componente 56
ESB , dei necessari wrapper per permettere l’esposizione di servizi consistenti da parte di queste componenti. In relazione alle interfacce di integrazione si precisa inoltre che l’importo economico del capitolato è da intendersi comprensivo di tutti oneri economici derivanti dalle attività integrazione con le applicazioni esistenti, ivi compresi gli eventuali compensi a vantaggio dei fornitori terzi delle applicazioni presenti o in corso di realizzazione in ambito regionale. 8.2
Standard Tecnologici e specifiche tecniche
In relazione alla realizzazione del sistema il fornitore dovrà rispettare, sia in caso di sviluppo diretto che nel caso dell’utilizzo di soluzioni di terze parti per alcune delle componenti del SIURP, l’utilizzo di un insieme di standard e specifiche tecnologiche, sia nazionali che internazionali. E’ comunque 57
attentamente valutato e considerato preferenziale l’utilizzo di Open Standard . In tale ambito, anche visto l’orientamento architetturale scelto, si elencano di seguito le specifiche tecnologiche da utilizzare per singola area evidenziando in alcuni casi le possibili alternative. Si riporta il set di standard e specifiche selezionate per la realizzazione dei servizi, o comunque quelli ritenuti discriminanti per la scelta delle soluzioni da utilizzare all’interno dell’architettura del SIURP. In relazione alle specifiche presentate il fornitore può proporre soluzioni migliorative che
56
Enterprise Service Bus.
57
Riportiamo, come riferimento, la definizione di Open Standard tratta dal documento della Commissione Europea IDABC, European Interoperability Framework for Pan-European eGovernment Service, V1.0, European Commission, 2004: “The following are the minimal characteristics that a specification and its attendant documents must have in order to be considered an open standard: - The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.). - The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee. - The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty free basis.”
48/73
implementino versioni più recenti e/o versioni più robuste (in termini di implementazioni disponibili) degli standard e specifiche, equivalenti in termini di funzionalità espresse/garantite, livello di standardizzazione e supporto da parte di soluzioni commerciali o open source. N.
1
Area Modellazione del sistema e dei processi e vocabolari di serializzazione XML dei modelli
Specifica o o o o
UML v2.1.x o sup BPMN v1.1 o sup XMI v2.1.x XPDL v2.1 o sup (opz.)
Web Services :
2
Specifiche dei servizi
o o o o o o o
3
Componente – workflow/BPMscambio, esecuzione, orchestrazione processi e human workflow
1. 2. 3.
WSDL 1.1 o sup. SOAP 1.1 o sup. WS-Policy 1.5 WS-Security v1.1 SWA SOAP MTOM (opz.) WS Addressing.v1.0
WS-BPEL v2.0 BPEL4People JPDL v3.2 o sup.
Riferimento o
http://www.uml.org
o
http://www.bpmn.org/
o
www.omg.org
o
http://www.wfmc.org/
o
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
o
http://www.w3.org/TR/soap/
o
http://www.w3.org/TR/2007/REC-ws-policy20070904/
o
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss
o
http://www.w3.org/TR/SOAP-attachments
o
http://www.w3.org/TR/soap12-mtom/
o
http://www.w3.org/2002/ws/addr/
o
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsbpel
o
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=bpel4peopl e (https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/libra ry/uuid/30c6f5b5-ef02-2a10-c8b5-cc1147f4d58c)
o
4
Componente Registry
Universal Description, Discovery and Integration (UDDI) ver 3.0.2 o
5
Componente Enterprise Service Bus o
Se su tecnologia JAVA: • Service component Architecture (SCA) • Java Business Integration In tutti i casi: • LDAP
Se su tecnologie java: • JSR 16858 • JSR 28659 o In ogni
o
http://www.oasis-open.org/committees/uddispec/doc/tcspecs.htm#uddiv3
o
http://www.osoa.org/display/Main/Service+Compone nt+Architecture+Specifications
o
o 6.
Front-end SIURP
58
http://jcp.org/en/jsr/detail?id=168
59
http://jcp.org/en/jsr/detail?id=286
http://docs.jboss.com/jbpm/v3.2/userguide/
o o
http://jcp.org/en/jsr/detail?id=208
http://jcp.org/en/jsr/detail?id=301 http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsrp#te chnical
49/73
caso supporto di: • WSRP
8.2.1
Interfaccia utente
A parte quanto già elencato, SIURP dovrà essere interamente realizzato mediante l’utilizzo di front-end Web e quindi reso accessibile ai diversi utenti tramite i più diffusi browser internet (es. MS-Internet Explorer, Mozilla-Firefox, Apple-Safari) evitando di prevedere l’utilizzo di plug-in specifici da installare nei software di navigazione in particolare non è ammesso l’utilizzo di plugin dipendenti dalla piattaforma client. Inoltre, al fine di garantire migliori livelli di interazione tra l’utente e l’applicazione le interfacce utente è preferibile che siano realizzate utilizzando tecnologie AJAX (Asyncronous Javascipt and XML) realizzando la comunicazione tra i componenti di interfaccia ed i servizi di Back-End, siano essi web service o pagine dinamiche, secondo la notazione JSON
60
61
o lo standard XML . Per la
realizzazione dell’interfaccia utente dovrà essere utilizzato lo standard XHTML (preferibile XHTML1.0-Strict ) per la struttura ed il CSS
62
per il layout delle pagine. L’interfaccia utente del sistema 63
dovrà comunque conformarsi alle leggi ed i regolamenti in materia di accessibilità . 8.3
Caratteristiche dei componenti
I componenti dovranno avere le seguenti caratteristiche: •
flessibilità. I componenti dovranno essere in grado di adeguarsi ai mutamenti tecnologici ed all’interazione con altri progetti;
•
capacità di integrazione. I componenti di servizio (service component) sono il punto di partenza di un progetto ampio e complesso e dunque dovranno essere in grado di integrarsi, dal punto di vista tecnologico, con informazioni prodotte in sistemi diversi. A tal fine i componenti dovranno essere in grado di interfacciarsi con altri sistemi utilizzando standard riconosciuti;
60
http://www.json.org/
61
http://www.w3.org/XML/
62
http://www.w3.org/TR/CSS21/
63
Vedi: http://www.cnipa.gov.it/site/it-IT/Attivit%c3%a0/Accessibilit%c3%a0/
50/73
•
modularità. I componenti dovranno essere progettati, sia per quanto riguarda la parte hardware che la parte software, in maniera modulare, per garantire una loro naturale evoluzione ed integrazione con altri sistemi;
•
scalabilità. Le forniture hardware e software dovranno garantire massima scalabilità orizzontale e verticale al fine di poter espandere la potenza di elaborazione del sistema aumentando sia il numero di server che la capacità elaborativa del singolo server;
•
affidabilità, robustezza e disponibilità. Il sistema deve essere disponibile in modo continuativo H24 7x7 rispondendo agli SLA concordati; il sistema deve poter continuare a funzionare sfruttando la sua modularità anche in presenza di errori locali senza propagare i guasti a tutto il sistema e in condizioni non specificate nei requisiti;
•
manutenibilità. I componenti dovranno essere facilmente manutenibili, a tal fine il disegno progettuale dovrà essere chiaro, la documentazione completa e dovranno essere utilizzati software di base e strumenti di sviluppo ampiamente diffusi o standard de facto;
•
architettura SOA. Il sistema ed i suoi componenti dovranno essere disegnati secondo 64
i principi delle SOA (Service Oriented Architecture) ; •
front-end web-based. Tutti i componenti dovranno utilizzare schemi standard di applicativi Web. L’Amministrazione può concordare, con il fornitore, i casi in cui questa specifica non debba essere applicata;
•
semplicità d’uso. Il front-end dovrà minimizzare l’intervento umano e, in ogni caso, favorire la facilità di utilizzo, presentando un ambiente intuitivo corredato di help online anche contestuale.
Inoltre l’infrastruttura tecnologica da realizzarsi deve rispondere in maniera adeguata ai seguenti requisiti: •
possedere elevati livelli di prestazioni, sicurezza e affidabilità;
64 Vedi: OASIS, Reference Model for Service Oriented Architecture 1.0, Oasis Standard, 12 October 2006, www.oasis-open.org
51/73
•
disporre di caratteristiche di capacità, flessibilità e modularità per soddisfare le esigenze di evoluzione del sistema e per rispondere tempestivamente ed efficacemente alle esigenze di servizio;
•
adottare una tecnologia scalabile, diffusa e affidabile. In particolare è necessario utilizzare adeguati standard di sicurezza per la trasmissione e conservazione dei dati.
Per quanto riguarda la disponibilità della piattaforma e del software applicativo sviluppato, l’Amministrazione dovrà disporre dei sorgenti, adeguatamente documentati e la proprietà del software sviluppato, nonché eventuali licenze d’uso a tempo illimitato di librerie, che il software sviluppato utilizza, con la relativa documentazione anche al fine di garantire la capacità di intervento immediata sull’applicativo e l’indipendenza dell’Amministrazione dai fornitori esterni per il suo adeguamento. 8.4
Sicurezza
Per gli aspetti di sicurezza sono di riferimento: •
Comitato tecnico nazionale sulla sicurezza informatica e delle telecomunicazioni nelle pubbliche amministrazioni, Proposte concernenti le strategie in materia di sicurezza informatica e delle telecomunicazioni per la pubblica amministrazioni, 2004 (http://www.cnipa.gov.it/site/_files/sicurezza%20informatica.pdf)
•
Comitato tecnico nazionale sulla sicurezza informatica e delle telecomunicazioni nelle pubbliche amministrazioni, Linee Guida per la Sicurezza ICT delle Pubbliche Amministrazioni, 2004 (http://www.cnipa.gov.it/site/_files/Quaderno%20n%2023.pdf)
•
Decreto legislativo 30/06/2003, n. 196, Codice in materia di Protezione dei Dati Personali ed in particolare l’Allegato Tecnico B (http://www.parlamento.it/leggi/deleghe/03196dl.htm)
Per la firma elettronica si segnalano •
CNIPA, La normativa sulla firma elettronica, 2006 (Minigrafia http://www.cnipa.gov.it/site/_files/minigrafia14_FirmaElettronica_.pdf);
CNIPA,
•
CNIPA, Allegato alla deliberazione n. 34/2006 - Regole Tecniche per la definizione del profilo di busta crittografica per la firma digitale in linguaggio XML, 2006 (http://www.cnipa.gov.it/site/_files/Allegato%20Deliberazione%2034%20del%2018%20MA GGIO%202006_.pdf).
Si segnalano inoltre: •
le linee guida dell’ISCOM (http://www.isticom.it);
•
CNIPA, Sistema pubblico di cooperazione - SERVIZI DI SICUREZZA, v1.0, 2005 (http://www.cnipa.gov.it/site/_files/SPCoop-ServiziSicurezza_v1.0_20051014.pdf)
Il sistema informativo dovrà associare ed integrare il sistema di accesso che realizza le funzioni di autenticazione (sia forte che debole), il sistema che svolge le funzioni di autorizzazione e quelle di 52/73
accounting degli accessi, dando origine ad un sistema integrato (triple A = Autenticazione, Autorizzazione, Accounting). L’aggiudicatario predisporrà un documento che partendo da un’analisi dettagliata dei rischi sulla sicurezza definisca tutte le misure necessarie per realizzare un sistema adeguatamente protetto. Tale documento sarà quindi un input per la progettazione architetturale al fine di realizzare un sistema che sia garantito dal punto di vista della sicurezza. Il documento dovrà contenere almeno i seguenti aspetti: Valutazione dei rischi •
Classificazione degli asset critici del sistema.
•
Classificazione e valutazione delle minacce.
•
Classificazione e valutazione delle possibili vulnerabilità del sistema.
•
Valutazione dell’impatto dei vari rischi sul sistema.
•
Analisi dei risultati.
Gestione dei rischi •
Identificazione e classificazione dei rischi come risultati dell’analisi dei rischi.
•
Modalità di controllo dei rischi identificati.
•
Modalità di minimizzazione o rimozione dei rischi.
•
Valutazione dell’impatto sul sistema in termini di complessità d’uso.
•
Definizione delle procedure di intervento e delle azioni correttive al presentarsi dei rischi valutati.
•
Piani di auditing periodici.
•
Business Continuity Planning ( BCP) e Disaster Recovery Planning.
Politica della sicurezza applicata alla realizzazione del sistema • •
Linee guida per la progettazione del sistema: elementi necessari al fine di garantire la sicurezza del sistema. Politica per il controllo dell’accesso al sistema.
Tale documento deve essere pubblicato, approvato ed inoltrato ad ogni interessato, potrà essere inoltre modificato successivamente se si dovessero verificare esigenze differenti da parte della Regione Calabria.
53/73
9 Ulteriori elementi della fornitura 9.1
Capacity Planning
Il sistema SIURP dovrà essere utilizzato in ambito regionale da diverse tipologie di utenti rientranti in Unità organizzative/dipartimenti sia facenti capo direttamente alla Regione (es. Dipartimento Programmazione Nazionale e Comunitaria) sia facenti capo agli altri enti beneficiari dei finanziamenti ed attuatori degli interventi non di diretta attuazione regionale. Di seguito si riporta un dimensionamento indicativo del numero di utenze, evidenziando la situazione attuale ed a tendere in relazione alle nuove esigenze del ciclo di programmazione 2007-2013. Tabella 3 - Utenti del sistema attuali e previsti
Per quanto attiene l’insieme degli utenti esterni alla Regione (Province/Comuni, ecc.) si precisa che il numero attuale di utenti è pari a 300. Il sistema SIURP dovrà tuttavia consentire l’accesso a tutti gli utenti di Province, Comuni o altri Enti che sul territorio regionale potranno avere la titolarità o l’attuazione di un intervento. Gli utenti a tendere del nuovo sistema sono stimati nell’ordine di 500. 54/73
9.2
Servizi di manutenzione e supporto
9.2.1
SLA e Servizi di manutenzione
Attraverso la stipula di un Service Level Agreement l’Aggiudicatario specifica gli impegni contrattuali, i termini e i livelli di servizio che vengono garantiti. Lo SLA è un documento strutturato in maniera tale da offrire alla Regione Calabria una chiara identificazione degli impegni assunti da parte dell’Aggiudicatario. Lo SLA conterrà in particolare: •
Descrizione dettagliata dei servizi che devono essere forniti alla Regione Calabria ( la definizione dei livelli di servizio relativi agli apparati hardware, ai sistemi, ai software di base e ai criteri di monitoraggio; definizione dei livelli di servizio specifici dell'applicazione; definizione dei livelli di servizio relativi ai servizi di Help Desk e di supporto agli utenti).
•
Tempi di attivazione di ciascun servizio.
•
La definizione dei livelli di servizi.
•
I processi di escalation in caso di malfunzionamento.
•
Le procedure e i tempi di intervento e ripristino del livello standard di servizio.
•
La descrizione di eventuali servizi opzionali.
•
La descrizione della reportistica e degli strumenti offerti al cliente per monitorare e verificare la qualità del servizio.
Il documento di Service Level Agreement sarà oggetto di specifica approvazione da parte dell’Amministrazione. Vengono definiti i seguenti indicatori di efficacia atti a descrivere i livelli di qualità minimi attesi per la gestione del Sistema SIURP: Tabella 4 - Indicatori di efficacia per livelli di qualità attesi per il sistema SIURP CODICE INDICATORE
RDISP
INDICATORE
Disponibilità del sistema
VALORE DI SOGLIA
99 % su base mensile;
DESCRIZIONE
La disponibilità del sistema deve essere assicurata dal lunedì al sabato, dalle ore 6.00 alle ore 22.00, dalla data di collaudo del componente fino alla data di cessazione del contratto, al netto delle interruzioni concordate per manutenzione del sistema S.I.U.R.P. e al netto di tutte le interruzioni della disponibilità indipendenti
RILEVAZIONE
Giornaliera
55/73
CODICE INDICATORE
INDICATORE
VALORE DI SOGLIA
DESCRIZIONE
RILEVAZIONE
dal sistema S.I.U.R.P. stesso. Le interruzioni per manutenzione programmata non devono superare le 4 ore mensili. L’indicatore di disponibilità del sistema sarà così calcolato: 99,5 % su base trimestrale;
GG = numero di giorni del mese
-
TMP = ore di interruzione per manutenzione programmata
-
TIS = ore di interruzione per cause indipendenti dal sistema S.I.U.R.P.
-
DT = Disponibilità Teorica = (24*GG – TMP – TIS)
-
IT = Indisponibilità Totale (Σ ore indisponibilità non concordata del servizio)
-
RIND
Intervallo massimo di non disponibilità del sistema
≤ 1 oltre i 60 minuti su base mensile
RDISP = (DT - IT) / DT*100
Misura il numero di volte in cui il sistema non è accessibile per un periodo ≥ di 60 minuti consecutivi. L’indicatore sarà così calcolato:
≤ 2 oltre i 60 minuti su base trimestrale
Giornaliera
RIND1 = ∑ aj dove: aj= j-esimo evento di indisponibilità del portale con durata ≥ 60 min
Rileva la percentuale tra tempo di risposta effettivo alle operazioni di accesso al servizio ed il tempo previsto per i primi 6 mesi di esercizio dall’esito positivo del collaudo. RTEMP
Tempo di risposta del sistema
≥ 99,8% entro 10 secondi su base mensile
L’indicatore sarà così calcolato: RTEMP = X/Y*100
Ogni 30 minuti
dove: -
X = numero di risposte del sistema alle operazioni di accesso al servizio entro la soglia fissata
-
Y = Numero di risposte del sistema alle operazioni di accesso
56/73
CODICE INDICATORE
INDICATORE
VALORE DI SOGLIA
≥ 99,8% entro 8 secondi su base mensile
DESCRIZIONE
RILEVAZIONE
Rileva la percentuale tra tempo di risposta effettivo alle operazioni di accesso al servizio ed il tempo previsto dopo 6 mesi di esercizio dall’esito positivo del collaudo e fino al termine del contratto. L’indicatore sarà così calcolato: RTEMP = X/Y*100
≥ 99,8% entro 8 secondi su base trimestrale
Rileva la percentuale tra tempo di risposta effettivo alle operazioni di accesso al servizio ed il tempo previsto per i primi 6 mesi di esercizio dall’esito positivo del collaudo. L’indicatore sarà così calcolato: RTEMP = X/Y*100
≥ 99,8% entro 7 secondi su base trimestrale
Rileva la percentuale tra tempo di risposta effettivo alle operazioni di accesso al servizio ed il tempo previsto dopo 6 mesi di esercizio dall’esito positivo del collaudo e fino al termine del contratto. L’indicatore sarà così calcolato: RTEMP = X/Y*100
Vengono definiti i seguenti indicatori di efficacia atti a descrivere i livelli di qualità minimi attesi per il tempo di ripristino del sistema a seguito di guasti o malfunzionamenti:
57/73
Tabella 5 - Indicatori di efficacia di servizio del sistema SIURP per tempi di ripristino CODICE INDICATORE
INDICATORE
PERIODO DI RIFERIMENTO
VALORE DI SOGLIA
DESCRIZIONE
RERR1
Tempo medio di rimozione di guasti o errori bloccanti sul sistema SIURP
entro 8 ore consecutive nel 90% dei casi ed entro 16 ore consecutive nel restante 10% dei casi;
In caso di guasti o errori bloccanti viene misurato il tempo medio necessario per la individuazione, risoluzione dell’inconveniente e ripristino del servizio
Trimestrale
RERR2
Tempo medio di rimozione di guasti o errori bloccanti su front end pubblico (web site pubblico)
entro 2 ore consecutive nel 90% dei casi ed entro 4 ore consecutive nel restante 10% dei casi;
In caso di guasti o errori bloccanti viene misurato il tempo medio necessario per la individuazione, risoluzione dell’inconveniente e ripristino del servizio.
Trimestrale
Tempo medio di rimozione di guasti o errori non bloccanti
entro 24 ore consecutive nel 90% dei casi ed entro 36 ore nel restante 10% dei casi
In caso di guasti o errori non bloccanti viene misurato il tempo medio necessario per la individuazione risoluzione dell’inconveniente e ripristino del servizio.
Trimestrale
RERR3
La proposta dovrà predisporre la metodologia per rilevare gli indicatori definiti nei relativi tempi di osservazione 9.2.2 9.2.2.1
Supporto/Assistenza tecnica Affiancamento e avvio all’esercizio
La proposta dovrà prevedere un periodo di affiancamento operativo adeguato nell’ambito delle funzionalità applicative del SIURP con utenti del sistema con l’obiettivo di assicurare la partenza operativa dei vari sistemi attraverso l’affiancamento all’utilizzo del sistema. L’affiancamento dovrà garantire, altresì, le attività relative al caricamento dei dati necessari per il corretto utilizzo del sistema e lo start-up dello stesso anche importando i dati relativi alla nuova programmazione eventualmente caricati sui sistemi di monitoraggio utilizzati prima della messa in esercizio del SIURP. Si dovrà pertanto prevedere una specifica sezione nel “Piano di transizione dei sistemi” per la migrazione dei dati specificandone le metodologie adottate, la tempificazione dell'attività e le risorse impegnate. Il piano, come già definito precedentemente, andrà presentato 6 mesi
prima
del
collaudo
del
sistema
e
sarà
soggetto
ad
approvazione
da
dell’Amministrazione. 58/73
parte
9.2.2.2
Manutenzione adeguativa ed evolutiva
Il sistema proposto dovrà essere aggiornato, senza oneri aggiuntivi per la stazione appaltante, nel rispetto di tutta la normativa richiamata nei documenti di gara, acquisita in sede di analisi e delle successive modifiche e integrazioni che dovessero intervenire durante il termine di vigenza del contratto. Conseguentemente, per tutto il periodo di validità del contratto, l’aggiudicatario dovrà garantire la manutenzione evolutiva, per tener conto di variazioni di tipo normativo e regolamentare, e la manutenzione adeguativa, qualora si rendesse necessario per garantire un mantenimento delle caratteristiche prestazionali del sistema. Per la manutenzione evolutiva non legata a variazioni regolamentari o normative ma a nuove funzioni richieste dall’Amministrazione successivamente alla messa in esercizio dei componenti di servizio del SIURP, l’aggiudicatario dovrà presentare un piano dettagliato con tempi, risorse professionali allocate e stima dell’effort espresso in giornate uomo. 9.2.2.3
Manutenzione correttiva
L’aggiudicatario dovrà garantire l’assistenza su richiesta dell’amministrazione, con personale qualificato e tempi di intervento definiti dagli SLA. Dovrà essere inoltre garantita per tutto il periodo del contratto la manutenzione dei prodotti software, per ripristinarne le caratteristiche di esercizio venute meno a seguito di difetti manifestatisi dopo il rilascio o per correggere malfunzionamenti dell’applicativo o comportamenti non rispondenti alle specifiche funzionali. La responsabilità manutentiva riguarda sia quanto sviluppato dall’aggiudicatario sia i prodotti di terze parti e le estensioni e parametrizzazioni, anche ove la manutenzione dei prodotti di terze parti dipenda da un servizio reso dal produttore del software o hardware da mantenere. 9.3
Servizi di change management e formazione
Va evidenziato come nel progetto del SIURP debba essere espresso un forte riferimento agli aspetti organizzativi e di processo e quindi alle competenze di consulenza organizzativa. Le potenzialità dei sistemi informativi integrati restano inespresse nel caso in cui si adotti una impostazione che tenda a considerarne il loro successo come automaticamente discendente dalla semplice introduzione ed installazione di nuovi applicativi e nuove soluzioni informatiche. E’ necessario quindi prevedere, per le tre macrofasi tipiche dell'implementazione di un Sistema Informativo (configurazione, messa in produzione e messa a regime), un programma di change management, che ha l’obiettivo di tenere in adeguata considerazione implicazioni e ricadute di 59/73
carattere organizzativo derivanti dall’introduzione del nuovo Sistema informativo. Oltre ad un tradizionale Piano di formazione e addestramento degli utenti, il Piano di Change Management deve prevedere la progettazione di interventi sull’organizzazione unitamente a quelli sui sistemi informativi ed alle conseguenti azioni per la formazione e l’addestramento degli attori chiave e degli utenti finali. Per la formazione devono essere definiti i servizi di formazione sia degli amministratori che degli utilizzatori del sistema, nel rispetto dei requisiti tecnico-funzionali che verranno successivamente delineati nel Piano di formazione. L’intervento di formazione comprende le attività di addestramento volte a formare il personale, sia del Dipartimento Programmazione Nazionale e Comunitaria
sia della altre UO individuate
dall’amministrazione, all’utilizzo del sistema di SIURP. La formazione dovrà comprendere gli aspetti di sicurezza inerenti i rischi e le responsabilità degli utenti rispetto ai dati trattati e fornire in questo ambito leneeguida di comportamento adeguate (es. scelta delle pasword, custodia delle password, etc.) Sono inoltre oggetto dell’intervento le attività di supporto per accompagnare gli utenti durante le prime fasi di utilizzo del nuovo sistema SIURP e fino alla complessiva attività a regime. Le attività di formazione e supporto includono: 1.
la predisposizione di presentazioni specifiche e di progetto;
2.
l’addestramento degli utenti utilizzatori suddivisi per categoria e coordinati con i piani di rilascio previsti per le varie funzionalità;
3.
l’addestramento degli utenti Amministratori;
4.
la predisposizione del materiale didattico da utilizzare per l’attività di addestramento;
5.
la predisposizione di un ambiente tecnologico “di addestramento”.
60/73
10 Modalità di esecuzione della fornitura 10.1 Il sistema di governance del progetto 10.1.1 Attori/Ruoli Il Sistema Informativo Unitario Regionale sarà utilizzato dall’Amministrazione regionale per la pianificazione, la gestione e il monitoraggio degli interventi a valere sul nuovo ciclo di programmazione 2007-2013. In particolare, il sistema sarà accessibile da tutti i dipendenti, quadri e dirigenti dell’Amministrazione regionale i cui Dipartimenti/settori/servizi sono titolari di linee di intervento specifiche. Per gli interventi non attuati direttamente dalla Regione il sistema sarà messo a disposizione di tutti i beneficiari finali (Comuni, Provincie, enti di formazione, ecc.) titolari di interventi e per i quali la Regione esercita un ruolo di coordinamento (c.d. operazioni “a regia 65
regionale”) . Inoltre, si precisa che il nuovo sistema, attraverso il web site pubblico, sarà aperto all’accesso di tutti i cittadini/utenti finali che potranno utilizzarlo per effettuare interrogazioni /visualizzare lo stato di attuazione di tutti gli interventi finanziati con fondi FAS e Fondi Strutturali nel rispetto delle normative vigenti sula privacy. Nella figura che segue sono rappresentati i diversi utenti del sistema SIURP e le relative associazioni in coerenza con i ruoli/funzioni previsti all’interno del Regolamento generale dei Fondi Strutturali e dei Programmi Operativi della Regione Calabria FESR e FSE. Si fornisce di seguito un elenco (da intendersi non esaustivo e modificabile anche sulla base delle specifiche di dettaglio che saranno fornite dall’Amministrazione all’atto dell’aggiudicazione) dei principali attori coinvolti nel nuovo processo di programmazione, corredato da una descrizione 66
delle principali funzionalità per ciascun profilo : Autorità di gestione: è l’autorità deputata al coordinamento ed alla gestione dei fondi ad essa destinati. Assegna le risorse ai responsabili dei capitoli di bilancio ed effettua un controllo sulle rilevazioni effettuate dagli stessi al momento della certificazione della spesa. Responsabile del capitolo di bilancio: è il soggetto che ha potere di spesa sul capitolo di bilancio a lui assegnato e cui spetta la gestione/il coordinamento delle procedure di selezione e delle operazioni a titolarità/regia regionale che ricadono sul proprio capitolo di
65
Per la distinzione di interventi a titolarità/regia cfr. glossario.
66
Si rimanda al par. 9.1 per il relativo dimensionamento.
61/73
67
bilancio. Viene individuato tra i Dirigenti di Settore del Dipartimento di competenza . E’ responsabile della rilevazione degli avanzamenti procedurali, fisici e finanziari delle operazioni e del consolidamento dei dati di avanzamento ai fini della rendicontazione delle spese all’IGRUE. E’ abilitato alle funzioni di impegno e spesa su progetti/operazioni ed in generale a tutte le operazioni di avanzamento contabile che implicano il colloquio con i sistemi della Ragioneria regionale.
67
Ai sensi del POR FESR e FSE, i Responsabili di Settore sono individuati tra i Dirigenti di Settore dei Dipartimenti competenti per materia, e, nei casi in cui ricorrano i requisiti di esperienza e professionalità, tra i Dirigenti di Servizio. I Responsabili delle Linee di Intervento sono individuati tra i Dirigenti di Servizio dei Dipartimenti competenti per materia, e in casi eccezionali, tra i funzionari con alte professionalità. Nell’analisi il Fornitore dovrà tuttavia bilanciare le previsioni dei programmi Operativi con le previsioni in materia di ordinamento contabile regionale (L.R. n.8/2002), in virtù del quale, la titolarità dei capitoli di bilancio (e di conseguenza gli impegni di spesa sugli stessi) è in capo ai soli dirigenti di Settore.
62/73
Figura 11 – Gli attori del sistema SIURP
Beneficiario finale: è il soggetto cui spetta l’inserimento dei dati di anagrafica e degli stati di avanzamento sulle procedure di selezione e progetti/operazioni di cui ha titolarità, ivi inclusi gli adempimenti per l’assegnazione del CUP – Codice Unico di Progetto. In caso di operazioni a titolarità regionale, coincide con il responsabile del capitolo di bilancio, altrimenti, per le operazioni a regia regionale, con l’ente responsabile della committenza delle operazioni (ad es. un ente locale o un ente di formazione); in tal caso, il trasferimento dei fondi produce impatti sulla contabilità regionale ma non sull’avanzamento finanziario del programma. 63/73
Organismo intermedio: è abilitato, su delega dell’Autorità di gestione o del Responsabile del capitolo di bilancio, all’inserimento dei dati di anagrafica e di avanzamento sulle procedure di selezione e progetti/operazioni. Le eventuali ulteriori autorizzazioni di tale profilo saranno definite dall’Amministrazione sulla base delle deleghe conferite, di volta in volta, all’Organismo intermedio. Soggetto attuatore: è abilitato, su delega dell’Amministrazione, all’inserimento dei dati di anagrafica e di avanzamento sulle procedure di selezione e progetti/operazioni a titolarità regionale. Opera per conto dell’Amministrazione delegante. Autorità di certificazione: è abilitato alla gestione delle domande di pagamento per la certificazione delle spese all’IGRUE. Costituisce il terzo livello di certificazione della spesa ed è abilitato ad inoltrare periodicamente le spese da rendicontare all’IGRUE. Unità di controllo di primo livello: è abilitato al controllo di tutti i progetti/operazioni ed alla sospensione/riattivazione degli stessi con indicazione della motivazione. Esercita in particolare un controllo sulla documentazione inerente i pagamenti intermedi e a saldo verso i soggetti attuatori e un controllo formale sui controlli in capo ai Beneficiari finali (laddove diversi dalla Regione). Nelle procedure di selezione interviene prima dell’approvazione del bando e prima dell’aggiudicazione definitiva. Tali unità intervengono su tutte le fasi che comportano dei finanziamenti e sulle verifiche ex-post Ufficio controlli irregolarità: profilo abilitato alla gestione delle irregolarità e alla generazione delle schede da inviare al’Ufficio Europeo Anti-frode per la comunicazione delle irregolarità. Autorità di Audit: effettua controlli di sistema e sui progetti. I controlli sono tracciati su un apposito registro dei controlli e possono generare la rilevazione delle irregolarità. Gestisce inoltre la sospensione/riattivazione di un progetto/operazione. Sono inoltre previsti i seguenti profili: Supervisore dei dati: ha il massimo delle autorizzazioni. Amministratore: ha le funzioni di amministratore della macchina. Operatore inserimento dati: è abilitato all’inserimento di dati di avanzamento che rimangono in standby fino alla validazione da parte del responsabile del capitolo di bilancio. Visualizzatore: è abilitato alla sola visualizzazione dei dati inseriti nel sistema.
64/73
Si precisa che all’Atto dell’aggiudicazione potranno essere individuati dall’Amministrazione altre tipologie di utenti aventi profili ed autorizzazioni specifiche, tra cui, a titolo esemplificativo: Nucleo di valutazione: è abilitato alla visualizzazione/elaborazione degli indicatori di risultato/realizzazione per ciascuna procedura di selezione/operazione. Autorità ambientale: è abilitato alla visualizzazione e al controllo sugli indicatori di risultato/realizzazione. 68
Valutatore esterno : è un profilo di visualizzatore cui è possibile produrre reportistica specifica. Referente regionale per la Comunicazione: è abilitato alla visualizzazione con funzioni specifiche in tema di trasparenza e pubblicità, secondo le disposizioni del Reg (CE) 1083/2006. 10.1.2
Key users e community di progetto
Il progetto SIURP per la suo livello di articolazione e per il tempo contenuto entro cui deve essere realizzato, necessita di una Community di progetto che vedrà coinvolti diversi attori attraverso l’identificazione, da parte del Committente, degli Utenti chiave (key-users) per ogni processo prioritario, che supporteranno il fornitore durante la fase di progettazione e realizzazione. Costituisce infatti un fattore critico di successo della fase di progettazione esecutiva e definitiva, il coinvolgimento dei key users. Altrettanto importanti sono gli aspetti che riguardano la scelta di metodologie appropriate di conduzione del progetto e la disponibilità di strumenti operativi che consentono: 1. la costituzione di una community di progetto che lavora on line, e quindi con tutti gli strumenti individuali necessari (accesso alla rete, casella e-mail personale), 2. il lavoro di gruppo attraverso sistemi di comunicazione basati su e-mail, 3. l’accesso alle informazioni di progetto mediante una apposita intranet, 4. il supporto all’organizzazione logistica delle attività progettuali e la convocazione di riunioni on line,
68 I valutatori esterni sono selezionati di norma dall’Amministrazione regionale e operano per conto della Commissione europea a cui riportano.
65/73
5. lo svolgimento delle attività che si sovrappongono temporalmente, ma che richiedono coordinamento diretto e scambio di informazioni, mediante un sistema di project management accessibile dalla intranet di progetto, 6. il supporto documentale per gestire la documentazione di progetto (dai verbali delle riunioni, ai SAL, ai reports direzionali, al Piano di attività, Piano di qualità, Piano di formazione, Piano di promozione e Piano di collaudo). La community di progetto è costituita da team che vedono impegnate, quando è ritenuto opportuno, sia le risorse umane del committente che quelle del fornitore, pur mantenendo distinti i propri compiti e ruoli. Il compito dei team è quello di supportare l’analisi funzionale e l’analisi del modello dei dati che verrà svolta dagli esperti della società fornitrice, e di validare i prototipi del software applicativo. Il fornitore ha il compito della conduzione delle sessioni di lavoro con i team, di procedere alla verbalizzazione di ciascuna riunione, di registrare le presenze dei partecipanti, di pianificare e convocare le riunioni, di fornire HW e SW per la intranet della community progetto. Il committente ha l’onere di mettere a disposizione le aule di riunione, di garantire la presenza dei key-user alle riunioni, di mettere a disposizione il sistema di comunicazione (pc, rete telematica, caselle e-mail). 10.1.3
Personale impiegato dall’Aggiudicatario
In sede di offerta tecnica l’Aggiudicatario dovrà allegare il curriculum vitae del personale impiegato (project manager, architetto, business analyst, Analisti programmatori ecc.) che verranno nominati nel caso di aggiudicazione dell’appalto. L’Aggiudicatario dovrà impiegare le risorse presentate attraverso il curriculum per tutta la durata del progetto. Nel caso l’Aggiudicatario, nel corso del progetto, non potesse più impiegare le risorse presentate, queste dovranno essere sostituite con altri professionisti di equiparabile esperienza maturata su progetti analoghi a quelli della presente gara. Tale possibilità di sostituzione, che dovrà
avere
una
giustificata
motivazione,
dovrà
essere
preventivamente
valutata
dall’Amministrazione appaltante. Si rinvia a quanto previsto nel Disciplinare di gara con riguardo agli obblighi dell’Aggiudicatario nei confronti del proprio personale e nei confronti dell’Amministrazione.
66/73
10.2 Luogo e tempi di esecuzione Luogo di esecuzione della fornitura è presso la sede del Dipartimento della Programmazione Nazionale e Comunitaria della Regione Calabria e presso il CED Regionale ovvero le ulteriori sedi dell’Amministrazione nell’ambito del territorio regionale. L’individuazione dei locali atti ad ospitare le attrezzature e i software necessari per la fornitura dei servizi descritti nel presente disciplinare e la documentazione tecnica allegata sarà concordata con l’Amministrazione successivamente alla stipula del contratto. 10.3 Proprietà delle componenti Si rinvia a quanto previsto dal Disciplinare di gara in materia di diritti di proprietà e utilizzo del software. Il sistema, al termine del contratto, resterà di proprietà dell’Amministrazione nella sua interezza (hardware, componenti applicative, Licenze software, apparati, configurazioni, basi dati, loro contenuto informativo, basi di conoscenza, manualistica, ecc.). Tutta la documentazione prodotta, in formato cartaceo e/o elettronico, dovrà essere consegnata all’Amministrazione e rimarrà di proprietà della stessa. 10.4 Piano di attività del progetto La realizzazione del sistema SIURP e delle interfacce di collegamento, con messa in esercizio della soluzione complessiva, dovrà avvenire entro 12 mesi dalla data di aggiudicazione. Il fornitore dovrà inoltre garantire per un periodo non inferiore a 48 mesi successivi all’esito positivo del collaudo e messa in esercizio, il servizio di manutenzione secondo quanto definito nell’apposita sezione del presente disciplinare tecnico. Di seguito si riporta un cronogramma di massima relativo alla realizzazione e manutenzione delle diverse componenti funzionali, al fine di dare un’indicazione di priorità dell’Amministrazione. Il fornitore in sede di offerta dovrà presentare un cronogramma complessivo delle attività che evidenzi le diverse fasi di realizzazione, ivi inclusa la realizzazione dei componenti di servizio e l’integrazione con le interfacce elencate nella parte relativa all’architettura logica nonché le ulteriori interfacce che saranno individuate durante la fase di analisi, i deliverable previsti da ogni fase, il numero di giornate uomo assorbite dalla fase, espresso come percentuale del numero di giornate/uomo totali offerte dal fornitore (senza riportare indicazioni di carattere economico). Il piano dovrà essere inoltre corredato da una proposta metodologica nella quale sia evidenziato l’approccio che il fornitore intende utilizzare per la realizzazione complessiva del sistema, ripartito 67/73
tra la parte di progettazione e analisi di dettaglio dei processi di business e quella di definizione dei requisiti, realizzazione, test e messa in esercizio del SIURP. Le attività devono essere progettate, realizzate e verificate secondo le procedure modalità indicate nel Piano di Qualità.
Tabella 6 - Cronogramma di massima per la realizzazione dei componenti funzionali
10.5 Piano di qualità La qualità della fornitura dovrà essere assicurata dall’Aggiudicatario, rispettando i criteri di qualità del proprio processo, e con l’applicazione del Piano della Qualità. Il Piano della Qualità, la cui versione iniziale sarà proposta nell’Offerta Tecnica, dovrà essere concordato con i responsabili dell’Amministrazione, recependo le eventuali osservazioni. Le successive versioni o revisioni del Piano della Qualità saranno consegnate in funzione delle variazioni intervenute. L’Aggiudicatario deve assicurare la qualità dei servizi erogati, attraverso la presenza al suo interno di specifiche funzioni di verifica, validazione, riesame, assicurazione qualità sui prodotti e sui processi, che si devono basare su buone pratiche e standard riconosciuti. L’Aggiudicatario si impegna a realizzare uno specifico Sistema di Controllo della Qualità relativo al presente appalto e ad attivarlo fin dall’inizio del Contratto, registrando tutti i parametri di qualità dei servizi conformemente a quanto da lui proposto. Il Piano di Qualità proposto dovrà indicare: •
obiettivi di qualità;
•
organizzazione della fornitura; 68/73
•
metodologie a garanzia della qualità del progetto;
•
metodologie e procedure per la realizzazione e gestione del progetto;
•
metriche per la misura della qualità effettivamente fornita;
•
ciclo di sviluppo del software;
•
gestione della configurazione (configuration management);
•
identificazione dei controlli (test, review, verifiche, validazioni) che l’Aggiudicatario intende svolgere internamente per assicurare la qualità della fornitura e relativi piani;
•
specifiche responsabilità riguardo ai controlli da svolgere e riguardo alla gestione della configurazione e delle non conformità;
•
gestione dei rischi e della sicurezza (identificazione e valutazione dei fattori di rischio, gestione e monitoraggio del rischio, security management);
•
scelta e controllo dei fornitori;
•
metodologie e procedure per la gestione e valutazione della qualità;
•
Piano di formazione.
69/73
10.6 Collaudo delle forniture Tutte le componenti infrastrutturali, tecnologiche HW e SW del SIURP saranno soggette a collaudo per accertarne l’effettiva rispondenza a quanto richiesto nelle specifiche tecniche e nelle specifiche funzionali
che
verranno
preparate
dall’Aggiudicatario
e
che
verranno
convalidate
dall’Amministrazione. Sono previste tre tipologie di collaudo: • collaudo sistemistico; • collaudo funzionale e prestazionale; • collaudo di integrazione. Tutte le componenti della soluzione realizzata verranno collaudate in maniera progressiva. Sarà cura dell’Aggiudicatario predisporre un piano di collaudo e proporlo per la condivisione all’Amministrazione. Al termine del collaudo sistemistico verrà effettuato un collaudo funzionale/prestazionale, per accertare l’effettiva rispondenza ai requisiti funzionali e prestazionali. L’Aggiudicatario deve fornire e predisporre tutti gli strumenti di automazione necessari per l’esecuzione dei test e per la valutazione dei risultati. L’Aggiudicatario deve altresì garantire il presidio e l’assistenza sistemistica e applicativa necessaria all’effettuazione dei collaudi e all’analisi di eventuali anomalie riscontrate. Ciascun collaudo si considererà terminato quando tutte le prove concordate con l’Amministrazione avranno avuto esito positivo. A conclusione di ciascun collaudo deve essere redatto apposito verbale di accettazione controfirmato dalle parti nel quale verrà anche fissata la data di “pronto per l’uso” del sistema delle relative
funzionalità
collaudate.
I
verbali
di
collaudo
dovranno
essere
approvati
dall’Amministrazione. Si precisa che la fase di collaudo è subordinata alla consegna all’Amministrazione, in formato cartaceo ed elettronico, di tutti i manuali e la relativa documentazione, sia tecnica che operativa, che servirà al corretto uso del sistema in tutti i suoi aspetti, articolazioni e componenti.
70/73
10.7 Monitoraggio del contratto L’Amministrazione procederà al monitoraggio secondo i criteri e le modalità previste dalla circolare AIPA/CR/38 del 28/12/2001. L’Aggiudicatario si impegna a fornire all’Amministrazione tutti i documenti necessari all’attività di monitoraggio, a partire dalla data di inizio di esecuzione delle attività, nei formati dei file intermedi e su supporti magnetici e ottici. In particolare, il fornitore fornirà con periodicità, mensile fino all’esito positivo del collaudo del sistema SIURP, e trimestrale per i successivi 48 mesi di assistenza e manutenzione, relazioni di stato avanzamento lavori, contenenti una descrizione delle attività svolte, dei deliverable rilasciati e delle gg/uu assorbite. La funzione di monitoraggio sarà svolta dall’Amministrazione o da soggetto da essa incaricato.
71/73
Riferimenti per la realizzazione del SIURP I documenti di seguito citati devono essere di riferimenti per l’esecuzione della fornitura.
Data
Documento
Consiglio dell’Unione Europea
Regolamento (CE) n. 1083/2006 e successive rettifiche (GUCE L 210 del 11-lug-2007 31.07.2006)
http://www.dps.mef.gov.it/ normativaCE_fondistruttu OBBLIGATORIO rali.asp#A1
Commissione Europea
Regolamento (CE) N. 1828/2006 e succ. rettifiche (GUCE L 371 del 08-dic-2007 27.12.2006)
http://www.dps.mef.gov.it/ normativaCE_fondistruttu OBBLIGATORIO rali.asp#A1
Regione Calabria
POR Calabria FESR 2007 – 2013 07-dic-2007 (Decisione C(2007) 6322 7-12-2007)
http://www.regione.calabr ia.it/calabriaeuropa
OBBLIGATORIO
Regione Calabria
POR Calabria FSE 2007 – 2013 (Decisione C(2007) 6711 del 18-dic-2007 18.12.2007)
http://www.regione.calabr ia.it/calabriaeuropa
OBBLIGATORIO
CIPE
Delibera CIPE n. 166 del 21/12/2007 “Attuazione del Quadro Strategico Nazionale (QSN) 2007-2013 - 21-dic-2007 Programmazione del Fondo per le Aree Sottoutilizzate”
http://www.regione.calabr ia.it/calabriaeuropa
OBBLIGATORIO
Governo italiano
Dgls. 163/2006 “Codice dei Contratti pubblici relativi a lavori, servizi e 12-apr-2006 forniture in attuazione delle direttive 2004/17/CE e 2004/18/CE”
Gazzetta Ufficiale n. 100 del 02/05/06 – Supp. ordinario n. 107
OBBLIGATORIO
Governo italiano
Dgls. 123/1998 “Disposizioni per razionalizzazione degli interventi sostegno pubblico alle imprese, norma dell’art.4, comma 4, lett. della L. 15 marzo 1997, n.59”
Gazzetta Ufficiale n. 99 del 30 aprile 1998
OBBLIGATORIO
OASIS
Reference Model for Service Oriented 12–ott-2006 Architecture 1.0, OASIS Standard
http://www.oasisopen.org
OBBLIGATORIO
CNIPA
Sistema pubblico di Connettività e 14 ottobre Cooperazione - Requisiti e specifiche 2005 del SPCoop
http://www.cnipa.gov.it
CONSIGLIATO
IGRUE
Linee guida sui sistemi di gestione e controllo per la programmazione 2007 19-apr-2007 - 2013
http://www.regione.calabr ia.it/calabriaeuropa
CONSIGLIATO
CIPE
Codice Unico di Progetto Investimento Pubblico (CUP)
http://www.cipecomitato.it /cup/cup.asp
CONSIGLIATO
Regione Calabria
“PO Regione Calabria FESR 2007 – 2013: Procedure e criteri di selezione Aprile 2008 delle operazioni”
http://www.regione.calabr ia.it/calabriaeuropa
CONSIGLIATO
la di a 31-mar-1998 c)
di
-
Riferimento
Livelli di requisito (RFC2119)
Emesso da
72/73
Data
Riferimento
Livelli di requisito (RFC2119)
http://www.regione.calabr ia.it/calabriaeuropa
CONSIGLIATO
Emesso da
Documento
Regione Calabria
“PO Regione Calabria FSE 2007 – 2013: Procedure e criteri di selezione Aprile 2008 delle operazioni”
Regione Calabria
Legge Regionale n.26 del 7/12/2007 (e succ. integrazioni) “Istituzione dell’Autorità regionale denominata «Stazione Unica Appaltante» e 07-dic-2007 disciplina della trasparenza in materia di appalti pubblici di lavori, servizi e forniture”,
Regione Calabria
Descrizione dei sistemi di gestione e Dicembre controllo del POR Calabria FESR 2008 2007 - 2013
http://www.regione.calabr ia.it/calabriaeuropa
OBBLIGATORIO
Regione Calabria
Strategia di Audit del POR Calabria febbraio FESR e del POR Calabria FSE 2007 2009 2013
http://www.regione.calabr ia.it/calabriaeuropa
OBBLIGATORIO
BUR Calabria n. 22 del 01/12/2007, supp. straordinario n. 3 del 12/12/2007
CONSIGLIATO
73/73