Appendice B Requisiti del sistema

UNIONE EUROPEA
REGIONE CALABRIA
REPUBBLICA ITALIANA
PROGRAMMA OPERATIVO REGIONE CALABRIA
FESR 2007 - 2013
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”
Appendice B
Requisiti del sistema SIURP
Indice
1
Premessa ........................................................................................................................3
2
Requisiti generali del sistema.......................................................................................4
3
Il componente Programmazione...................................................................................6
4
Il componente Procedure ad evidenza pubblica.........................................................8
5
Il componente Gestione Interventi .............................................................................11
5.1
Il processo di registrazione di una procedura di selezione.........................................11
5.2
Il processo di avanzamento delle operazioni..............................................................11
5.3
Il processo di gestione delle irregolarità e dei recuperi/revoche.................................14
5.4
Il processo di certificazione della spesa e la generazione delle Domande di
pagamento ..................................................................................................................15
5.5
Il processo di audit ......................................................................................................16
6
Il sistema di anagrafica ausiliario (AUX)....................................................................17
7
Il web site pubblico ......................................................................................................18
8
Il Sistema ESB (Enterprise Service Bus) ...................................................................20
9
Il Registry dei servizi ...................................................................................................21
10
Il Reporting System .....................................................................................................22
11
SIURP Front-end...........................................................................................................23
2
1 Premessa
Il presente documento ha come obiettivo quello di presentare e descrivere, a titolo esemplificativo e non
esaustivo, i requisiti di massima del Sistema Informativo Unitario Regionale per la Gestione e il
Monitoraggio degli Investimenti Pubblici (di seguito SIURP), oggetto di realizzazione del presente
capitolato.
Obiettivi specifici del documento sono:
contribuire a presentare il contesto all'interno del quale il Sistema si colloca e ad individuare gli
obiettivi che ci si prefigge con la sua realizzazione;
illustrare le caratteristiche principali del sistema formalizzando i requisiti;
fornire elementi utili a determinare modalità e costi di gestione e sviluppo.
1
Il documento, unitamente alla descrizione dei processi di business descritti nell’Appendice A , facilita la
comprensione delle caratteristiche salienti del progetto, della sua complessità funzionale e tecnica ed
fornisce alcuni degli elementi per una stima dell'impegno necessario per il raggiungimento degli obiettivi.
Il presente documento, collocandosi in una fase preliminare al processo di sviluppo del
sistema, non pretende di essere esaustivo nella definizione dei requisiti che sono quindi da
intendersi come requisiti di massima, che tuttavia sono di guida, nella loro generalità, per le
successive fasi del progetto e per la definizione della vision e del disegno architetturale. Sarà
compito del fornitore completare ed approfondire l’analisi.
1
Pur se, come ricordato, a titolo esemplificativo e non sostitutivi della fase di cattura dei requisiti.
3
2 Requisiti generali del sistema
Si elencano di seguito, i principali requisiti generali del Sistema SIURP:
•
Requisito #005: il sistema deve consentire, con un unico profilo di accesso, la gestione dell’intero
ciclo dei progetti/operazioni a valere sui finanziamenti comunitari e nazionali (POR e FAS).
•
Requisito #010: il sistema deve, per ciascun progetto/operazione afferente il ciclo della
programmazione 2007-2013, supportare le “piste di controllo” della Regione Calabria relative alle
fasi di programmazione, selezione, attuazione e certificazione, con riferimento alle tipologie dei
macro-processi definiti dall’IGRUE e implementando anche i controlli su tempi e soggetti correlati
alle verifiche.
•
Requisito #015: il sistema deve colloquiare con la Banca Dati Unificata consentendo la
trasmissione dei dati di monitoraggio e rendicontazione in conformità al Protocollo di Colloquio e il
Protocollo Applicativo, nelle versioni aggiornate rilasciate dall’IGRUE.
•
Requisito #020: il sistema deve consentire l’inserimento/ modifica/ aggiornamento dei dati di
avanzamento dei progetti/operazioni tramite accesso web al sistema.
•
Requisiti #025: il sistema deve gestire il flusso di lavoro tra attori del sistema e attori (umani o
sistemi) esterni al sistema.
•
Requisito #030: la gestione dei flussi di lavoro deve essere indipendente dalla logica di business
del sistema tramite un componente di workflow engine.
•
Requisito #035: il sistema deve consentire l’aggiornamento/modifica/ eliminazione dei dati solo agli
utenti specificamente abilitati.
•
Requisito #040: il sistema deve tenere traccia di tutte le operazioni che vengono effettuate su di
esso, identificandole in maniera univoca. Le operazioni e i dati ad essa connesse sono archiviate in
appositi registri accessibili dai singoli componenti, in funzione dell’operazione o del processo
specifico (Dossier dell’operazione, registro delle sospensioni, registro delle revoche, registro delle
irregolarità ecc.).
•
Requisito #045: parte delle attività relative ai processi di business di cui all’ “Appendice A” devono
essere supportate da specifiche check-list che, in particolare, devono prevedere: il controllo sui
documenti a supporto delle verifiche, il controllo sui tempi associati alle verifiche, il controllo sui
soggetti correlati alle verifiche, la propedeuticità/obbligatorietà delle verifiche. Le check-list dovranno
essere personalizzate in base alla titolarità e tipologia dell’operazione (regia/titolarità; opere
pubbliche/ acquisizione di beni e servizi/ erogazione di contributi/ formazione), ed in base all’attività
che deve essere espletata.
•
Requisito #050: nel caso in cui ad un’attività sia associata un check-list, il sistema non deve
consentire l’espletamento della fase in assenza della compilazione della check-list.
4
•
Requisito #055: il sistema deve consentire l’allineamento, automatico (con periodicità stabilita o in
funzione di eventi predefiniti) o a richiesta, con il sistema della contabilità regionale.
•
Requisito #060: il sistema deve colloquiare con il sistema di protocollo Informatico regionale per la
protocollazione di tutti i documenti in uscita/entrata da/verso l’Amministrazione regionale.
•
Requisito #065: il sistema deve colloquiare con il sistema per l’assegnazione del numero di
repertorio dell’Amministrazione per tutti gli atti/ documenti che vengono trasmessi all’interno
dell’Amministrazione Regionale tra diversi Dipartimenti/ Settori/ Servizi.
•
Requisito #070: il sistema deve prevedere l’interazione con i sistemi di firma digitale utilizzati
dall’Amministrazione in tutti i casi in cui sia prevista la trasmissione di documenti tra i diversi utenti
del sistema salvo indicazione in senso contrario da parte dell’Amministrazione.
•
Requisito #075: il sistema deve sempre effettuare un controllo formale sui dati inseriti.
5
3 Il componente Programmazione
Si elencano di seguito, i requisiti di massima del componente di supporto alla programmazione. Il
processo di programmazione costituisce condizione preliminare per avviare qualsiasi operazione
afferente la programmazione in oggetto, siano esse richieste di impegno/pagamento relative a
procedure di selezione o singoli progetti/operazioni o inserimenti di dati di anagrafica sui progetti.
Il componente supporta l’Amministrazione nell’analisi dei piani settoriali e programmatici e nelle verifiche
di coerenza di tali piani con gli obiettivi generali e specifici dei programmi operativi e dei piani strategici
regionali. Il particolare:
•
Requisito #100: il sistema deve consentire, per ciascun piano finanziario/fonte di finanziamento, il
caricamento, articolato su diversi livelli gerarchici e per annualità, degli importi e delle quote di
ripartizione assegnate;
•
Requisito #105: il sistema deve consentire l’allineamento con il sistema di contabilità regionale
degli importi e delle quote di ripartizione per ciascun piano finanziario/fonte di finanziamento,
articolato su diversi livelli gerarchici e per annualità, e con riferimento allo stato di previsione
dell’entrata e della spesa del bilancio regionale annuale e pluriennale;
•
Requisito #110: il sistema deve consentire a tutti gli utenti la ricerca e la visualizzazione, ai diversi
livelli di aggregazione, degli importi e delle quote di ripartizione delle fonti finanziarie attinenti uno
specifico periodo di programmazione e piano finanziario;
2
•
Requisito #115: il sistema deve conformarsi all’OMG - Business Motivation Model ;
•
Requisito #120: il sistema deve consentire il caricamento dei diversi elementi dei documenti
strategici (programmi operativi, documenti strategici regionali), programmatici e dei piani settoriali e
la relativa strutturazione in: Fini, Azioni, Direttive, Influencer, ecc. Conformemente all’OMG 3
Business Motivation Model ;
•
Requisito #125: il sistema deve consentire di mettere in relazione gli stessi elementi dei piani e di
distinguere le gerarchie di elementi non quantificati da quelli quantificati conformemente all’OMG Business Motivation Model;
•
Requisito #130: il sistema deve consentire l’elaborazione della struttura, a livello di obiettivi
generali, specifici e dei relativi indicatori, dei documenti programmatici;
•
Requisito #135: il sistema deve consentire di caricare e tracciare, a seconda della tipologia
dell’operazione, i criteri per l’elaborazione dei criteri di selezione delle operazioni;
2
OMG, Business Motivation Model (BMM) Specification, v1.0, www.omg.org
3
OMG, Business Motivation Model (BMM) Specification, v1.0, www.omg.org
6
•
Requisito #140: il sistema, in previsione della scadenza dei termini per la consegna del Rapporto
4
Annuale di Esecuzione , deve consentire l’interazione con i componenti di gestione delle procedure
di evidenza pubblica e gestione interventi al fine di recuperare i dati necessari all’elaborazione degli
elementi essenziali del Rapporto, tra cui, ad esempio: numero di procedure di selezione avviate/in
corso, numero di operazioni individuate per tipologia e linea di intervento/ settore/ fondo di
appartenenza, ammontare delle spese dichiarate/certificate per operazione e ammontare dei
pagamenti ricevuti, numero di controlli effettuati ed esiti ecc.
4
Il Regolamento generale sui Fondi Strutturali (CE) n. 1083/2006 prevede che entro il 30 giugno di ogni anno
l’Autorità di Gestione trasmetta alla Commissione un “Rapporto annuale di esecuzione” contenente informazioni
sulle attività relative all’anno solare precedente. In particolare il documento dovrà contenere informazioni relative a:
- stato di avanzamento del PO e degli assi prioritari rispetto ai loro obiettivi specifici (numero e tipologia di
modifiche apportate e validate nel PO; numero e tipologia di indicatori ed obiettivi modificati; numero bandi
pubblicati ed assegnati);
- spese sostenute dai beneficiari finali a livello di operazione/linea di intervento/ fondo e relativo contributo
pubblico erogato;
- impiego dei fondi comunitari svincolati e ricorso all’assistenza tecnica;
- numero e tipologia di criticità/irregolarità riscontrate durante l’esecuzione del PO e percentuale delle
criticità risolte adottate
- qualità delle azioni di sorveglianza effettuate, anche concernenti la valutazione sulle modalità di raccolta
dei dati per assicurare la qualità e l’efficacia di esecuzione del PO;
- stato di avanzamento e di finanziamento dei grandi progetti;
- numero e tipologia di azioni adottate per pubblicizzare il PO.
7
4 Il componente Procedure ad evidenza pubblica
Il componente per la Gestione delle procedure di evidenza pubblica supporta l’Amministrazione
regionale nella gestione di tutte le procedure di selezione a valere sui fondi della nuova
programmazione 2007-2013.
In particolare, deve consentire di gestire l’intero workflow a supporto del processo di gestione delle
procedure di evidenza pubblica, e attraverso il costante controllo dello stato della procedura, deve
essere in grado di segnalare all’Amministrazione eventuali criticità nella predisposizione della
documentazione tecnico-amministrativa e nell’espletamento della procedura stessa.
Il componente è utilizzato dagli utenti interni all’Amministrazione per la gestione delle operazioni a
titolarità regionale e si interfaccia con gli altri componenti del SIURP tra cui modulo gestione interventi,
contabilità finanziaria, protocollo informatico ecc.
Si riporta di seguito un elenco dei principali requisiti del componente:
•
Requisito #200: il sistema deve consentire l’inserimento dei dati e delle informazioni distintive della
procedura e che avviano il processo di espletamento della stessa. Ovvero: il fondo/ settore/linea di
intervento della procedura (verifica di coerenza), l’oggetto della fornitura e gli elementi essenziali del
contratto (importo, durata, tipologia di procedura alla quale si intende ricorrere, ecc.);
•
Requisito #202: il sistema non deve consentire di avviare l’elaborazione della documentazione
tecnico-amministrativa prima che sia stata verificata la disponibilità delle risorse sul capitolo di
bilancio;
•
Requisito #204: il sistema deve consentire l’inserimento di vincoli e scadenze temporali sulla
procedura, al fine di monitorare lo stato di lavorazione della stessa (work in progress) e segnalare
eventuali ritardi rispetto ai tempi programmati;
•
Requisito #206: il sistema deve consentire l’elaborazione della documentazione tecnico5
amministrativa di gara a partire dai template definiti dall’Amministrazione;
•
Requisito #208: il sistema deve consentire la creazione di un’area di lavoro condivisa per
l’elaborazione della documentazione tecnico-amministrativa di gara;
•
Requisito #210: il sistema deve consentire la possibilità di selezionare il percorso o iter procedurale
da associare alle operazioni che saranno selezionate a valle della procedura di selezione in oggetto;
5
A supporto del processo di gestione delle procedure di evidenza pubblica l’Amministrazione intende definire dei
template di documentazione tecnica (capitolato/disciplinare tecnico) e amministrativa (disciplinare di gara, fac-simile
dichiarazioni, offerta economica ecc.) personalizzati in base alla tipologia dell’operazione (opere pubbliche, fornitura
di beni e servizi, erogazione aiuti ecc.) e della tipologia di procedura di selezione, che saranno resi disponibili dal
Sistema.
8
•
Requisito #212: il sistema deve consentire ai profili abilitati l’elaborazione dei criteri di selezione
specifici per singola procedura a partire dai macro-criteri definiti per linea di intervento/tipologia di
operazione;
•
Requisito #214: il sistema deve consentire il controllo di primo livello (controllo sul procedimento
seguito e la conformità alla normativa regionale, nazionale e comunitaria) solo dopo l’approvazione
della documentazione tecnico-amministrativa di gara da parte dei soggetti abilitati;
•
Requisito #216: il sistema non deve consentire l’elaborazione del decreto di approvazione in
assenza di controllo o con esito del controllo negativo;
•
Requisito #218: il sistema non deve consentire l’elaborazione del decreto di approvazione in
assenza del visto di conformità proveniente dalla ragioneria regionale;
•
Requisito #220: il sistema deve consentire ai profili abilitati di inserire i riferimenti relativi alla
pubblicazione e le date di scadenza per la presentazione delle offerte;
•
Requisito #222: il sistema deve consentire l’acquisizione e la protocollazione delle domande/offerte
ricevute attraverso l’interazione con il sistema di protocollo informatico regionale;
•
Requisito #224: il sistema deve consentire la raccolta e l’archiviazione delle domande/offerte
ricevute per la valutazione da parte della commissione di valutazione;
•
Requisito #226: il sistema non deve consentire l’individuazione dei componenti della commissione
di valutazione se non è scaduto il termine per la ricezione delle offerte;
•
Requisito #228: il sistema deve segnalare ai profili abilitati di avviare il processo valutazione delle
offerte (fra cui la designazione/nomina della commissione di valutazione) allo scadere del termine di
ricezione delle offerte;
•
Requisito #230: il sistema deve consentire, su richiesta, l’estrapolazione automatica dei
componenti della commissione a partire da una short-list di esperti individuati dall’Amministrazione;
•
Requisito #232: il sistema non deve consentire la nomina della commissione di valutazione in
assenza dell’atto di designazione dei componenti;
•
Requisito #234: il sistema deve consentire l’invio di un avviso di convocazione ai membri della
commissione dopo l’elaborazione del provvedimento di nomina;
•
Requisito #236: il sistema deve consentire le comunicazioni relative all’aggiudicazione provvisoria
solo dopo la conclusione del processo di valutazione da parte della commissione;
•
Requisito #238: il sistema non deve consentire la registrazione del decreto di aggiudicazione
definitiva in assenza di controllo o con controllo con esito negativo;
•
Requisito #240: il sistema deve consentire l’inserimento di dati e informazioni inerenti la
valutazione, la graduatoria e l’aggiudicazione provvisoria/definitiva e tutta la documentazione
connessa al a tali fasi (ad es. offerte pervenute/accettate/anomale, verbali di commissione, punteggi
9
attribuiti, nominativi dei beneficiari/soggetti aggiudicatari, comunicazioni di aggiudicazione,
documenti presentati per la fase di verifica del rispetto dei requisiti, ecc.);
•
Requisito #241. il sistema deve consentire la gestione delle procedure di ricorso da parte di
concorrenti/offerenti terzi a seguito della comunicazione di aggiudicazione, sia per quanto riguarda
la gestione delle procedure e eventuale gestione/aggiornamento/tracciatura delle graduatorie ecc.;
•
Requisito #242: il sistema deve consentire l’elaborazione di una bozza di contratto a partire dai
template definiti e sulla base delle specificità emerse dall’esito della procedura;
•
Requisito #244: il sistema deve guidare gli utenti abilitati nel processo di sottoscrizione del
contratto, segnalando tempestivamente eventuali criticità nelle verifiche dei requisiti e le scadenze
dei termini/ i vincoli di approvazione/sottoscrizione;
•
Requisito #246: il sistema deve tenere traccia di tutte le operazioni individuate a valle delle
procedure di selezione, classificandole per tipologia e fondo/settore/linea di intervento;
•
Requisito #248: il sistema deve consentire l’invio automatico di un messaggio all’Autorità di
gestione quando il numero delle operazioni individuate a valere su una linea di intervento/settore
copre l’intero ammontare delle risorse a copertura di quel settore/linea di intervento;
•
Requisito #248: il sistema, nelle fasi di avvio della procedura, predisposizione della
documentazione tecnico-amministrativa, pubblicazione, aggiudicazione e stipula contratto, deve
trasmettere i dati al sistema di gestione degli interventi per l’alimentazione e l’aggiornamento dei
dati di anagrafica e iter procedurale della procedura di selezione;
•
Requisito #250: il sistema deve consentire l’inserimento del numero di repertorio su tutti gli
atti/documenti interni all’Amministrazione.
10
5 Il componente Gestione Interventi
Il componente di Gestione degli interventi supporta l’Amministrazione in tutte le fasi connesse
all’attuazione, gestione, monitoraggio e rendicontazione di tutti gli interventi a valere sul nuovo ciclo
della programmazione 2007-2013. I requisiti di tale componente, descritti di seguito, sono rappresentati
in modo allineato ai processi di business descritti nell’Appendice A.
5.1
Il processo di registrazione di una procedura di selezione
Le funzioni di registrazione delle procedure di selezione sono consentite a tutti gli utenti titolari di
operazioni (responsabili di capitolo di bilancio, beneficiari finali). Tuttavia, nel caso di operazioni a
titolarità regionale, il componente di gestione degli interventi si interfaccia con il componente di gestione
delle procedure di evidenza pubblica per recuperare tutti i dati di anagrafica e dati di avanzamento
necessari al monitoraggio della procedura ed al colloquio con la Banca Dati Unificata dell’IGRUE.
Nel caso di operazioni a regia regionale, il sistema consente l’inserimento dei dati atti a caratterizzare in
modo univoco la procedura di selezione. In particolare:
Requisito #300: il sistema deve consentire la registrazione dei dati di anagrafica (ad es.
•
settore/linea di intervento di appartenenza, tipologia di operazione, tipologia della selezione,
importo, ecc.);
Requisito #305: il sistema deve consentire la selezione di un percorso o iter procedurale predefinito
•
6
e/o la personalizzazione dello stesso a partire dai modelli predefiniti ;
Requisito #310: il sistema deve tenere traccia delle movimentazioni contabili relative al
•
trasferimento di fondi dalla Regione ai Beneficiari finali e della relativa documentazione giustificativa
a supporto.;
Requisito #315: il sistema deve consentire la possibilità di selezionare il percorso o iter procedurale
•
da associare alle operazioni che saranno selezionate a valle della procedura di selezione in oggetto;
5.2
Il processo di avanzamento delle operazioni
Il processo di avanzamento delle operazioni concerne tutte le attività che vanno dalla individuazione del
progetto (e quindi la sua registrazione) alla implementazione dello stesso, incluse le attività di
monitoraggio e rendicontazione della spesa. Si elencano di seguito, a titolo meramente esemplificativo,
alcuni dei principali requisiti del componente di gestione degli interventi, suddivisi sulla base dei processi
di business precedentemente descritti.
5.2.1
•
Processo di registrazione di un’operazione
Requisito #320: il sistema deve consentire la registrazione dei progetti solo se associati ad una
procedura di selezione conclusa;
6
Trattasi dei c.d. iter procedurali definiti nel glossario.
11
•
Requisito #325: il sistema deve consentire la registrazione dei dati di anagrafica dei
progetti/operazioni (ad es. tipologia di progetto, descrizione, importo, indicatori, localizzazione,
georeferenziazione, ecc.) e la selezione di un iter procedurale predefinito;
•
Requisito #330: il sistema deve consentire la personalizzazione degli iter procedurali e delle checklist a partire da quelli predefiniti e la selezione degli indicatori di risultato/realizzazione associati allo
specifico progetto/operazione;
•
Requisito #335: il sistema deve consentire di ereditare, per il progetto/ operazione, la categoria
definita a livello di procedura di selezione, e se selezionato, l’iter procedurale definito a livello di
procedura di selezione;
•
Requisito #340: il sistema deve consentire ad alcuni profili, previa autorizzazione da parte
dell’Autorità di gestione e abilitazione dell’amministratore del sistema, di modificare l’ereditarietà
della categoria del progetto/operazione definita a livello di procedura di selezione;
•
Requisito #345: il sistema deve guidare, attraverso apposita check-list, l’utente autorizzato verso il
collegamento
dell’importo
delle
risorse
destinate
del
progetto/operazione
alle
risorse
assegnate/impegnate alla procedura di selezione associata;
•
Requisito #350: il sistema deve consentire il collegamento dell’impegno di spesa del
progetto/operazione solo dopo aver verificato la disponibilità di risorse nell’ambito della procedura di
selezione e, se vi sono risorse disponibili, deve consentire la registrazione dell’impegno e la
7
successiva archiviazione ;
•
Requisito #355: il sistema deve restituire gli estremi dell’operazione di collegamento.
•
Requisito #360: nel caso di progetti/operazioni a regia regionale il sistema deve consentire la
richiesta di anticipo per il trasferimento fondi al beneficiario finale.
5.2.2
•
Il processo di avanzamento di operazioni a titolarità/regia regionale
Requisito #400: il sistema deve consentire di modificare/integrare le informazioni di anagrafica e
relative all’iter procedurale di ciascun progetto/operazione in assenza di avanzamento economico;
•
Requisito #405: il sistema deve consentire, ai profili abilitati, di inserire/modificare i dati relativi
all’avanzamento procedurale, fisico e finanziario di ciascun progetto/operazione;
•
Requisito #410: il sistema deve consentire la visualizzazione dei dati inseriti al fine di effettuare i
controlli di primo livello;
7
Al momento della selezione di progetti/operazioni a conclusione di una procedura di selezione l’Amministrazione
regionale avvia il c.d. processo di “rideterminazione dell’impegno”, volto a vincolare le risorse effettivamente
impegnate sull’insieme dei progetti/operazioni selezionati. Nel caso in cui tale importo sia inferiore all’importo a
base d’asta della procedura di selezione, il processo di rideterminazione dell’impegno implica la liberazione delle
risorse derivanti dalle c.d. “economie”.
12
•
Requisito #415: il sistema non deve consentire la validazione dei dati inserti in assenza di controllo
o con esito del controllo negativo;
•
Requisito #420: il sistema deve consentire di avviare le attività di impegno e liquidazione solo dopo
la validazione dei dati inseriti da parte del profilo abilitato;
•
Requisito #425: il sistema deve supportare le attività di impegno e liquidazione collegate ad ogni
evento finanziario attraverso apposite check-list;
•
Requisito #430: il sistema non deve consentire di avviare le richieste di impegno e di liquidazione in
assenza del Documento Unico di Regolarità Contributiva;
•
Requisito #435: il sistema non deve consentire la prenotazione dell’impegno in assenza dell’esito
delle verifiche sulle cartelle esattoriali a carico del fornitore/beneficiario;
•
Requisito #440: il sistema deve consentire la verifica della presenza di cartelle esattoriali a carico
del fornitore/beneficiario presso la Società Equitalia;
•
Requisito #445: il sistema, in caso di presenza di cartelle esattoriali a carico del
fornitore/beneficiario, deve gestire eventuali decurtazioni, rideterminazioni e reintegrazioni degli
importi dovuti secondo le modalità che saranno definite dall’Amministrazione;
•
Requisito #450: in caso di evento finanziario (erogazione anticipo, erogazione intermedia o saldo),
il sistema dovrà consentire agli utenti specificamente abilitati di inviare la richiesta di
prenotazione/liquidazione di una quota di risorse a valere sull’importo totale del progetto/operazione
verso il sistema della contabilità regionale;
•
Requisito #455: il sistema deve elaborare la richiesta solo dopo aver verificato la disponibilità di
risorse nell’ambito dell’importo totale del progetto/operazione, e se vi sono risorse disponibili, deve
consentire la registrazione dell’impegno/liquidazione;
•
Requisito #460: il sistema deve restituire gli estremi dell’operazione effettuata (estremi
dell’impegno/mandato di pagamento);
•
Requisito #465: il sistema deve consentire l’acquisizione e l’archiviazione, nel “dossier
dell’operazione”, di tutti i documenti e giustificativi relativi al ciclo di avanzamento.
I requisiti relativi al processo di avanzamento di un’operazione a regia regionale sono riconducibili ai
requisiti che attengono al processo di avanzamento delle operazioni a titolarità regionale. L’unica
differenza è che, essendo la titolarità gestionale dell’intervento delegata ad un soggetto esterno alla
regione, gli uffici regionali competenti per i controlli di primo livello eseguiranno un mero controllo
formale sulla correttezza dei controlli spettanti al Beneficiario finale. Anche nel caso di operazioni a regia
regionale, l’interazione con il sistema di contabilità regionale è demandato ai soli utenti interni alla
Regione.
13
5.3
Il processo di gestione delle irregolarità e dei recuperi/revoche
Il processo di gestione delle irregolarità attiene strettamente alle fasi ordinarie di monitoraggio e
controllo (primo livello) per ciascun progetto/operazione. Sono indicati di seguito, a livello di massima, i
principali requisiti di tale processo:
•
Requisito #500: il sistema deve consentire la rilevazione delle irregolarità sui singoli progetti agli
utenti specificamente abilitati (Responsabile di linea di intervento/settore, Autorità di gestione,
soggetti esterni);
•
Requisito #505: in caso di rilevazione dell’irregolarità, il sistema deve consentire la sospensione del
progetto/operazione, e deve inviare in automatico un messaggio ai profili abilitati all’elaborazione
della pratica;
•
Requisito #510: il sistema deve tenere traccia di tutte le operazioni riscontrate irregolari,
classificandole ad esempio per tipologia dell’operazione, motivo dell’irregolarità, utenti che hanno
effettuato la segnalazione ecc. attraverso un apposito registro delle irregolarità;
•
Requisito #515: il sistema deve supportare il workflow nel flusso di verifica delle irregolarità,
consentendo la comunicazione delle irregolarità per progressivi livelli di responsabilità e tenendo
traccia delle scelte operate nella successione; non deve consentire la modifica dei dati inseriti una
volta che la verifica è stata conclusa e la relativa documentazione trasmessa al profilo successivo;
non deve consentire operazioni sulle pratiche in elaborazione dal profilo di livello inferiore;
•
Requisito #520: il sistema, in caso di accertamento delle irregolarità, deve inviare in automatico un
messaggio al profilo abilitato al fine di consentire l’avvio del processo di recupero/revoca;
•
Requisito #525: il sistema, in caso di segnalazione OLAF, deve consentire agli utenti abilitati la
compilazione della scheda OLAF e la sua registrazione nel registro OLAF;
•
Requisito #530: il sistema, in caso di avvio del processo di recupero/revoca, deve consentire la
registrazione di tutti i dati di anagrafica (operazione di appartenenza, importo, soggetto beneficiario,
ecc.) e l’acquisizione dei documenti a supporto nell’apposito registro delle revoche;
•
Requisito #535: il sistema deve supportare il flusso di gestione delle revoche consentendo la
trasmissione di messaggi e dei documenti elaborati/acquisiti ai vari soggetti coinvolti;
•
Requisito #540: il sistema deve consentire il colloquio con il sistema della contabilità regionale per
richiedere le relative scritture contabili;
•
Requisito #545: il sistema deve supportare la gestione delle pratiche, tenendo traccia nel registro
tra quelle pendenti/concluse e quindi segnalando ritardi nel recupero delle somme irregolari o
inviando un messaggio in automatico al soggetto abilitato una volta che è stata registrata la
restituzione delle somme;
•
Requisito #550: il sistema non deve consentire la chiusura della pratica in assenza della
registrazione degli estremi dell’atto di restituzione delle somme.
14
5.4
Il processo di certificazione della spesa e la generazione delle Domande di pagamento
8
Il processo di generazione delle domande di pagamento avviene attraverso due sottoprocessi distinti,
di cui il primo strettamente legato alla gestione dei recuperi/revoche (precedentemente descritto) e il
secondo connesso al processo di validazione e certificazione della spesa vero e proprio.
Si elencano, a titolo indicativo, alcuni requisiti di massima relativi al processo di certificazione della
9
spesa :
•
Requisito #600: il sistema deve consentire a tutti gli utenti abilitati, le attività di validazione delle
spese di propria competenza, indipendentemente dall’apertura o meno di una domanda di
pagamento;
•
Requisito #605: il sistema deve consentire, agli utenti abilitati per le spese di propria competenza
(operazione/ linea di intervento/ settore/ asse), l’inserimento/esclusione di movimenti contabili e la
trasmissione delle attestazioni di spesa;
•
Requisito #610: il sistema deve supportare l’acquisizione, l’elaborazione e la trasmissione di
eventuali documenti a supporto delle attestazioni;
•
Requisito #615: il sistema deve supportare la gerarchia nel flusso di certificazione, consentendo la
validazione dei dati certificati per progressivi livelli di certificazione; non deve consentire operazioni
sui dati una volta che sono stati validati e trasmessi al profilo gerarchicamente superiore; non deve
consentire operazioni sui dati in elaborazione dal profilo di livello inferiore e che quindi non sono
ancora stati validati;
•
Requisito #620: il sistema deve tracciare tutte le operazioni di inclusione/esclusione di movimenti
contabili effettuate dai diversi profili ai vari livelli gerarchici;
•
Requisito #625: il sistema deve registrare tutte le attestazioni a livello di linea di
intervento/settore/asse in un apposito libro delle dichiarazioni di spesa.;
•
Requisito #630: il sistema deve segnalare l’apertura della Domanda di pagamento in occorrenza
delle scadenze prefissate;
•
Requisito #635: il sistema deve consentire, all’apertura della domanda di pagamento, di
visualizzare i recuperi conclusi che devono essere inseriti nella stessa;
•
Requisito #640: il sistema deve consentire l’elaborazione della Domanda di pagamento a partire
dai recuperi conclusi e dalle attestazioni di spesa ricevute;
•
Requisito #645: il sistema deve consentire l’inoltro della Domanda di pagamento alla Banca Dati
Unificata in conformità con il protocollo di colloquio e applicativo definiti dall’IGRUE;
8
9
Cfr. glossario.
Cfr. glossario.
15
•
Requisito #650: il sistema, dopo l’inoltro della Domanda di pagamento, deve inviare
automaticamente un avviso ai soggetti responsabili delle attestazioni e generare un file campione
per i controlli di secondo livello.
5.5
Il processo di audit
Per quanto attiene il processo di controllo di secondo livello, sono indicati di seguito alcuni dei requisiti di
massima:
•
Requisito #700: il sistema deve tenere traccia di tutti i controlli effettuati, classificandoli e
acquisendo la relativa documentazione, attraverso un apposito registro dei controlli;
•
Requisito #705: il sistema deve permettere l’inserimento/ aggiornamento delle informazioni relative
al controllo effettuato (quali ad esempio: data di effettuazione del controllo, autore del controllo,
tipologia e oggetto, esito del controllo) e l’elaborazione/acquisizione della documentazione a
supporto;
•
Requisito #710: il sistema deve consentire l’interazione tra l’Autorità di Audit e i soggetti controllati
nelle fasi di richiesta e recepimento di integrazioni/deduzioni;
•
Requisito #715: il sistema deve permettere la gestione del processo di controllo segnalando ritardi
sui tempi o vincoli al processo derivanti da adempimenti di eventuali soggetti correlati;
•
Requisito #720: il sistema, in caso di esito positivo del controllo deve permetterne la chiusura e la
registrazione nel registro dei controlli; in caso di esito negativo, deve inviare in automatico
segnalazioni agli altri utenti interessati per permettere l’avvio di azioni correttive/recuperi.
16
6 Il sistema di anagrafica ausiliario (AUX)
Il sistema di Anagrafica ausiliario ha lo scopo di gestire gli utenti del SIURP sia per quanto riguarda i
componenti di supporto alla programmazione sia per la parte relativa alla gestione delle procedure ad
evidenza pubblica e gestione degli interventi. Esso si interfaccerà con le anagrafiche utilizzate
dall’Amministrazione, sopperendo la gestione delle anagrafiche degli utenti non censiti all’interno delle
anagrafiche esistenti. In una fase transitoria il componete AUX potrà sopperire all’anagrafica dei
dipendenti nel caso che questa non fosse immediatamente disponibile. In particolare il componente:
•
Requisito #800: deve gestire permessi e regole di accesso alle risorse ed alle funzionalità
applicative per tutte le tipologie di utenti, sia interni all’Amministrazione (dipendenti regionali), sia
esterni, ovvero rientranti nel dominio dei diversi enti attuatori degli interventi finanziati in ambito
regionale;
•
Requisito #810: per la gestione delle anagrafiche dei dipendenti regionali e altre anagrafiche (ad
es. dei beneficiari dei contributi e dei fornitori), deve interfacciarsi con i sistemi di anagrafica
dell’Amministrazione, mantenendo il necessario allineamento ai fini del censimento, autorizzazione
e revoca delle diverse utenze;
•
Requisito #820: deve rappresentare il punto unico per la creazione dei profili utente del SIURP e
per la gestione dell’autenticazione e dell’autorizzazione di accesso per l’accesso alle risorse.
17
7 Il web site pubblico
Al fine di rispettare i principi di trasparenza e pubblicità nella diffusione delle informazioni connesse
all’attuazione degli interventi finanziati con risorse pubbliche, l’Amministrazione regionale, per il tramite
10
dell’Autorità di Gestione , deve prevedere procedure idonee per assicurare che le informazioni relative
ai Programmi cofinanziati e alle operazioni realizzate arrivino correttamente ai potenziali Beneficiari
nonché all’opinione pubblica, evidenziando il ruolo dell’Unione Europea e garantendo la trasparenza
nell’utilizzo dei Fondi. Inoltre, nel rispetto delle disposizioni in materia di trasparenza delle attività della
Pubblica Amministrazione (Legge 241/90 e s.m.i.), deve assicurare l’accesso ai documenti
amministrativi, ai provvedimenti e alle fonti, garantendo in tal modo la possibilità di partecipare al
procedimento.
A tal fine l’Amministrazione Regionale renderà disponibili ad utenti e beneficiari finali, attraverso un web
site pubblico, i dati relativi ai programmi ed ai progetti in carico alla Regione, fornendo informazioni
aggiornate in merito allo stato di avanzamento di ciascuno di essi. Attraverso il medesimo portale,
inoltre, sarà data evidenza ai bandi e agli avvisi emessi dall’Amministrazione regionale e gli esiti degli
stessi, al fine di garantire trasparenza e pari opportunità di accesso alle informazioni da parte dei
potenziali beneficiari.
In particolare il portale:
•
Requisito #900: dovrà consentire, a tutti i cittadini e utenti finali del sistema, la ricerca di
operazioni/bandi sulla base di diverse tipologie di ricerca (fonte di finanziamento, linea di
intervento/settore, tipologia, localizzazione, ricerca avanzata);
•
Requisito #905: dovrà consentire di produrre, delle schede sintetiche su schermo e stampabili,
nella forma di:
o
sintesi su singola operazione/bando: anagrafica, avanzamento, ecc.;
o
sintesi su N operazioni/bandi: dato un numero di operazioni/bandi selezionate in base ad
alcuni criteri, è un report complessivo del campione, es: numero di interventi nel campione,
avanzamento finanziario complessivo, ripartizione delle fonti di finanziamento complessiva,
ecc.
•
Requisito #910: dovrà colloquiare con i componenti di gestione procedure ad evidenza pubblica e
gestione interventi per l’estrapolazione dei dati necessari alla presentazione delle schede e i report
richiesti;
•
Requisito #915: in funzione della necessità, dovrà garantire piena trasparenza e accesso agli atti
amministrativi e alle procedure emesse dall’Amministrazione. Il fornitore dovrà garantire la messa
on-line 24 ore su 24, 7 giorni su 7, della sezione dedicata ai bandi e le procedure;
10
L’Autorità di Gestione è responsabile di redigere e attuare un piano di comunicazione ai sensi della sezione 1 del
Regolamento 1828/2006 nonché di verificare la sua concreta attuazione.
18
•
Requisito #920: sarà collegato al sito istituzionale della Regione Calabria e da un punto di vista
grafico dovrà rispettare gli standard W3C e nazionali sull’accessibilità e l’ottimizzazione della grafica
per il web, conformandosi al layout standard della comunicazione istituzionale della Regione
Calabria.
19
8 Il Sistema ESB (Enterprise Service Bus)
Un Enterprise Service Bus (ESB) è un'infrastruttura software che fornisce servizi di supporto ad
architetture SOA Enterprise.
Un ESB integra sistemi disparati che possono essere interconnessi con tecnologie eterogenee, e
fornisce in maniera consistente servizi di orchestrazione, sicurezza, messaggistica, routing intelligente e
trasformazioni, agendo come una dorsale attraverso la quale viaggiano servizi software e componenti
applicativi.
Un ESB crea un layer di astrazione al disopra dell’implementazione di un sistema di messagistica
enterprise che permette di implementare un sistema di messaggistica senza scrivere codice.
Al contrario dell’approccio delle classica Enterprise Application Integration (EAI) basata su uno stack
monolitico “hub and spoke” alla base dell’ESB c’è un approccio modulare basato su componenti ed un
depoyment distribuito dove necessario.
Si sottolinea che l’ESB, di per sé, non implementa una SOA, ma provvede le caratteristiche ed i servizi
di base per poterla implementare. L’ESB dovrebbe essere basata su standard e flessibile potendo
supportare diversi medium di trasporto utilizzando in modo pragmatico sia pattern SOA che, dove
necessario, EAI tentando così di rimuovere l’accoppiamento tra servizi richiesti e medium di trasporto.
•
Requisito #1000: il sistema dovrà essere flessibile e scalabile consentendo l’estensione futura
all’integrazione di ulteriori componenti in modo semplice e con minimi problemi di scalabilità;
•
Requisito #1005: il sistema dovrà gestire l’orchestrazione dei processi tra i diversi componenti ed
essere quindi dotato di un motore di orchestrazione;
•
Requisito #1010: il sistema dovrà gestire gli aspetti di sicurezza ed autenticazione (SSO)
utilizzando i dati presenti nelle anagrafiche dipendenti e AUX;
•
Requisito #1015: la configurazione dovrà essere basata su interfacce grafiche minimizzando gli
interventi su codice;
•
Requisito #1020: il sistema dovrà essere il più possibile basato su standard;
•
Requisito #1015: il sub componente di orchestrazione deve essere supportato da strumenti grafici
basati su BPMN
11
che generino, in modalità Model Driven (guidata dai modelli), la configurazione
dell’orchestrazione (processi).
11
OMG, Business Process Modeling Notation, V1.1, www.omg.org
20
9 Il Registry dei servizi
In ambito SOA, un registry è lo strumento software che raccoglie ed espone metadati sui servizi
disponibili in un'organizzazione. I dati sono accessibili tanto durante la progettazione (design-time)
quanto durante l'esecuzione (run-time). Il registry disaccoppia l'utente e il provider dei web services,
facilitando la ricerca ed il riuso dei web service e contribuendo ad eliminare le ridondanze.
Il registry potrà essere indipendente o integrato nel sistema ESB.
•
Requisito #1100: il registry dovrà essere basato sullo standard UDDI 3;
•
Requisito #1105: il sistema dovrà essere utilizzato sia a design-time che a run-time;
•
Requisito #1110: il sistema dovrà contenere le specifiche complete (contratti) di tutti i servizi
coinvolti in SIURP.
21
10 Il Reporting System
Il sistema di Reporting deve permettere di generare report che supportino il controllo operativo dei dati
da parte degli utenti del SIURP. Si differenzia in questo dal reporting del sistema esterno di
DataWareHouse più orientato al supporto, alla pianificazione ed al reporting strategico.
•
Requisito #1200: il sistema di reporting deve produrre report sia in formato documentale (es. .doc,
.rtf, .odt, .pdf) sia permettere esportazioni su foglio elettronico (es. .xls, .csv, .ods);
•
Requisito #1205: il sistema deve consentire oltre ad avere una serie di template per i report di
maggiore uso, nel Front-end SIURP, l’impostazione di nuove tipologie di report con un interfaccia
utente user friendly adeguata ad utenti senza particolari competenze informatiche, senza la
necessità di interventi al livello di codice del componente;
•
Requisito #1210: il sistema in particolare supporta una specifica area dedicata alla verifica e al
controllo della qualità dei dati, mirata al rispetto dei vincoli e delle propedeuticità che derivano
dall’utilizzo del Protocollo IGRUE per la BDU e che vengono applicati in occasione dell’operazione
di invio dei dati. Supportando in questo modo:
il consolidamento periodico dei rendiconti;
la generazione dei file di gestione del protocollo di colloquio;
l’impacchettamento ed invio al sistema IGRUE attraverso la porta di dominio;
la verifica dei risultati e degli eventuali scarti.
22
11 SIURP Front-end
Il Front-end SIURP inizia e controlla tutte le attività del sistema, interagendo con gli utenti e con lo strato
dei servizi sia di orchestrazione che stateless. Riceve le risposte e le presenta all’utente.
•
Requisito #1300: il Front-end deve essere web based ed accessibile tramite i più diffusi browser
web (es. MS-Internet Explorer, Mozilla-Firefox, Apple-Safari);
•
Requisito #1305: il Front-end dovrebbe evitare di prevedere l’utilizzo di plug-in da installare nei
software di navigazione, ad ogni modo non è ammesso l’utilizzo di plug-in dipendenti dalla
piattaforma client;
•
Requisito #1310: al fine di garantire migliori livelli di interazione tra l’utente e l’applicazione, le
interfacce utente devono essere 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
•
12
13
o lo standard XML ;
Requisito #1315: il Front-end, se sviluppato su piattaforma Java, dovrà utilizzare le specifiche JSR
14
168/286, in ogni caso dovrà supportare lo standard WSRP (Web Services for Remote Portlets) ;
•
Requisito #1320: il Front-end per l’interfaccia utente dovrà essere utilizzato lo standard XHTML
(preferibile XHTML-1.0-Strict ) per la struttura ed il CSS
•
15
per il layout delle pagine;
Requisito #1325: l’interfaccia utente del sistema dovrà comunque conformarsi alle leggi ed i
16
regolamenti nazionali in materia di accessibilità .
12
http://www.json.org/
http://www.w3.org/XML/
14
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
15
http://www.w3.org/TR/CSS21/
16
Vedi: http://www.cnipa.gov.it/site/it-IT/Attivit%c3%a0/Accessibilit%c3%a0/
13
23