CAPITOLATO TECNICO E D’ONERI

Servizi di sviluppo, manutenzione evolutiva, adeguativa, correttiva e relativi servizi di supporto tecnico (SICER – PATMOB – MIR – PATIMM)

6.8 Assistenza in remoto e onsite (ASS) 101

7 Modalità di esecuzione 104

7.1 Gestione del progetto 104

7.2 Piano della Qualità e Controllo 105

7.3 Gestione della configurazione 106

7.4 Prodotti delle fasi di sviluppo 107

7.5 Composizione del Gruppo di lavoro 108

7.6 Conduzione dell’appalto 115

7.7 Passaggio di consegne a fine appalto 116

8 Verifica di conformità e controlli 117

9 Clausole legali 119

9.1 Norme regolatrici e disciplina applicabile 119

9.2 Modalità e tempi di esecuzione 119

9.3 Garanzie e Assicurazioni 121

9.4 Titolarità e fruibilità dei prodotti e della documentazione 121

9.5 Obblighi di riservatezza 122

9.6 Obblighi nei confronti del personale 123

9.7 Corrispettivo e modalità di pagamento 123

9.8 Penali 126

9.9 Varianti 127

9.10 Risoluzione e recesso 128

9.11 Diritti e pretese di terzi 130

9.12 Subappalto e subcontratto 130

9.13 Cessione del contratto e dei crediti 132

9.14 Comunicazioni 132

9.15 Spese contrattuali e oneri fiscali 132

9.16 Clausole di salvaguardia 132

9.17 Controversie e Foro competente 133

1 Introduzione

Regione Lazio nel 2018 ha deciso di dotarsi di un nuovo sistema amministrativo contabile, partendo dalla soluzione acquisita a riuso da Regione Liguria denominata SICER.

Il progetto per la realizzazione degli interventi evolutivi e di customizzazione da apportare alla soluzione acquisita a riuso è stato realizzato mediante l’adesione all’accordo quadro Consip “Sistemi gestionali integrati per le pubbliche amministrazioni” – Lotto3.

Il progetto precedentemente descritto è stato avviato mediante la sottoscrizione del contratto esecutivo prot. 276 del 10/01/2019 (CIG: 73194297E2); la data di avvio del progetto è stata fissata nel giorno 10/02/2018 e la durata progettuale è di 36 mesi.

Su indicazione delle Direzioni regionali “Bilancio, governo societario, demanio e patrimonio” e Programmazione economica”, l’avvio in esercizio del nuovo sistema SICER è stato previsto per il 01/05/2020, al fine di completare tutti gli adempimenti normativi sulla annualità 2019 sul sistema legacy Siripa (eg Rendiconto di gestione).

La soluzione evoluta secondo le esigenze specifiche espresse da Regione Lazio sarà rilasciata in esercizio progressivamente secondo un piano di avvio stabilito dalle direzioni regionali Società Appaltante e beneficiaria che ha previsto i seguenti step:

• Settembre 2020: avvio in esercizio del sistema SICER per la predisposizione del bilancio di previsione 2021-2023

• Gennaio 2021: avvio in esercizio del sistema SICER in gestione e mantenimento del sistema legacy fino a conclusione di tutti gli adempimenti gestionali (riaccertamento ordinario e rendiconto) a competenza 2020, ossia 30/04/2021 per la giunta regionale e 30/06/2021 per consiglio regionale.

Il sistema informativo SICER rappresenta uno strumento a supporto dell’attività amministrativa della Regione Lazio ai fini della gestione dei seguenti ambiti operativi, in accordo con le disposizioni normative vigenti:

• Contabilità (finanziaria ed economico patrimoniale) e bilancio

• Predisposizione e workflow approvativo degli atti amministrativi

• gestione ciclo passivo

• gestione ciclo attivo

• adempimenti fiscali

• gestione sanità accentrata (ente GSA)

• controllo di gestione

• controllo strategico per la gestione degli obiettivi dei direttori regionali

• predisposizione del bollettino ufficiale (BUR)

• gestione cespiti

• gestione dell’organismo intermedio per l’erogazione dei fondi europei (Orsie)

• gestione multi-ente per la gestione degli enti attestati (giunta, consiglio regionale, enti parco, ecc..)

• integrazione con i sistemi esterni coinvolti (Sistema Pagamenti per la gestione fatturazione elettronica attiva e passiva e ordini, sistema di firma digitale remota, piattaforma di conservazione sostitutiva Parer, Sistema Microsoft Active Directory regionale, sistema bdap – banca dati amministrazioni pubbliche, piattaforma siope+, sistema del personale SIR-HR, portale opendata, portale della trasparenza, sistema per la gestione del patrimonio mobiliare PATMOB, sistema per la gestione del patrimonio immobiliare PATIMM, sistema per la gestione dei fondi strutturali SIGEM, sistema di monitoraggio degli investimenti regionali (MIR))

Il presente Capitolato Tecnico e d’Oneri descrive e disciplina le condizioni, le modalità ed i termini per l’esecuzione delle attività di personalizzazione ed evoluzione dei sistemi sopra indicati, per rispondere alle esigenze specifiche di Regione Lazio.

2 Definizioni

Nel seguito del presente Capitolato d’Oneri, con il termine:

• “Bando di gara” o “Bando”, si intende l’Avviso spedito all’Ufficio Pubblicazioni Ufficiali dell’Unione Europea e pubblicato secondo legge, allo scopo di diffondere l’intenzione di affidare, mediante gara, le attività oggetto del presente appalto;

• “Capitolato Tecnico e d’Oneri” o “Capitolato”, si intende il presente documento che contiene tutte le informazioni relative alle condizioni, alle modalità ed ai termini per l’esecuzione delle attività oggetto del presente appalto;

• “Disciplinare di gara”, si intende il documento che contiene tutte le informazioni relative alle condizioni ed alle modalità di redazione e di presentazione delle offerte, ai criteri di aggiudicazione, alle cause di esclusione e di decadenza, nonché agli obblighi dell’Aggiudicatario per la stipula del contratto di appalto;

• “Atti di gara”, si intende l’insieme dei documenti di cui sopra (Bando – Capitolato Tecnico e d’Oneri – Disciplinare di gara);

• “Informazioni complementari”, si intendono le informazioni e i chiarimenti forniti dalla Società Appaltante;

• “Società Appaltante”, si intende LAZIOcrea S.p.A.;

• “Aggiudicatario”, si intende il soggetto che, al termine della procedura di gara, è risultato Aggiudicatario del presente appalto;

• “Appaltatore”, si intende il soggetto che, essendo risultato Aggiudicatario del presente appalto, ha stipulato il contratto con la Società Appaltante;

• “R.O.E”.- “R.T.I. ”, si intende un raggruppamento di operatori economici, costituito o costituendo ai sensi dell’art. dell’art. 48 del D. Lgs. n. 50/2016, che ha presentato un’offerta per concorrere all’aggiudicazione del presente appalto;

• “Parti”, si intendono, congiuntamente, la Società Appaltante e l’Appaltatore;

• “Utente”, si intende qualsiasi soggetto utilizzatore dei sistemi informativi oggetto del presente appalto.

Nel presente documento sono utilizzati i termini chiave “DEVE”, “NON DEVE”, “OBBLIGATORIO”, con i quali si definiscono elementi, requisiti, specifiche, condizioni che devono essere obbligatoriamente implementati/soddisfatti, fermo restando quanto specificato nel Disciplinare di gara in tema di esclusione dalla procedura di gara e nel seguito del presente documento in tema di verifiche e di penali e/o di risoluzione-recesso.

3 Glossario

SICER	Sistema informativo contabile Regione Lazio
PATMOB	Sistema informativo patrimonio mobiliare Regione Lazio
MIR	Sistema informativo per il monitoraggio degli investimenti regionali
PATIMM	Sistema informativo per la gestione del patrimonio immobiliare e demanio
SIGEM	Sistema di monitoraggio della Regione Lazio per gli interventi finanziati dal PO FSE e PO FESR per la programmazione 2014/ 2020
SIRIPA	Sistema Informativo Regionale Integrato Procedimenti Amministrativi
GIP	Gestione Investimenti Pubblici
MEV	Manutenzione Evolutiva del Software
MAC	Manutenzione Correttiva e Adeguativa del Software
ASS	Assistenza applicativa
FOR	Formazione e supporto organizzativo
SDI	Sistema di interscambio per la fatturazione elettronica
BDAP	Banca dati delle amministrazioni pubbliche
SAAS	Software-as-a-Service: modello di erogazione del software a “servizio”.
SLA	Service Level Agreement

4 Oggetto, durata e luogo di esecuzione

Il presente appalto ha ad oggetto i servizi di presa in carico dei sistemi informativi SICER, PATIMM e MIR, la realizzazione del nuovo sistema per la gestione del patrimonio mobiliare PATMOB nonché i servizi di personalizzazione ed evoluzione, manutenzione correttiva, adeguativa ed evolutiva, di gestione applicativa, assistenza e supporto specialistico on site e da remoto, affiancamento, supporto organizzativo e formazione dei sistemi informativi SICER, PATMOB, PAT-IMM e MIR.

Fermo restando quanto sopra, l’Appaltatore DEVE sviluppare il sistema PATMOB ed evolvere i restanti sistemi nel rigoroso rispetto dei requisiti funzionali descritti nel presente Capitolato.

In particolare servizi che devono essere prestati dall’Appaltatore nell’ambito del presente appalto sono i seguenti:

• servizi di sviluppo da erogarsi nelle seguenti due modalità:

o servizi di sviluppo a corpo relativi a funzionalità per le quali il requisito espresso dall’amministrazione è già delineato come meglio dettagliati al par. 6, ed in particolare:

▪ dashboard indirizzata alle strutture organizzative finalizzata alla semplificazione dell’accesso alle funzionalità primarie di loro competenza (assunzione atti amministrativi con e senza movimentazioni contabili e liquidazione fatture) ed alla consultazione e monitoraggio dei dati contabili di loro competenza;

▪ rifacimento del sistema PATMOB e della relativa integrazione con il sistema contabile SICER

▪ rifacimento dei moduli di controllo di gestione e controllo strategico

▪ revisione dell’integrazione tra il sistema contabile SICER ed il sistema per la gestione del patrimonio immobiliare PATIMM

o servizi di manutenzione evolutiva (MEV) da erogarsi a consumo, attingendo ad un plafond complessivo di 4.908 giornate come esplicitato al paragrafo 0;

• servizi di manutenzione correttiva ed adeguativa;

• gestione applicativa;

• assistenza e supporto specialistico on site e da remoto;

• supporto organizzativo e formazione.

Nei paragrafi successivi vengono descritti in dettaglio i servizi che sono oggetto di acquisizione nell’ambito del presente appalto.

La durata del presente appalto decorre dalla data di avvio dell'esecuzione del contratto, ferma la facoltà, ai sensi dell’art. 32 del D. Lgs. n. 50/16, di procedere all’avvio delle prestazioni nelle more del perfezionamento di tutti gli atti amministrativi necessari, e termina dopo 36 (trentasei) mesi dall’avvenuta presa in carico con esito positivo dei sistemi SICER – MIR - PATIMM di cui alla Tabella Milestone di progetto del successivo par. 7.1 (PRA1-01).

La data di avvio dell'esecuzione del contratto sarà comunicata all’Appaltatore dal Direttore dell'esecuzione nominato dalla Società Appaltante, fermo restando che l’avvio dell’esecuzione dovrà avvenire entro e non oltre 15 (quindici) giorni naturali e consecutivi dalla data di stipula del contratto tra l’Appaltatore e la Società Appaltante, salvo diverso accordo scritto tra le Parti.

In ogni caso, il Direttore dell’Esecuzione sulla base delle disposizioni del RUP, dopo che il contratto è divenuto efficace, dà avvio all’esecuzione della prestazione, fornendo all’esecutore tutte le istruzioni e direttive necessarie e redigendo apposito verbale firmato anche dall’esecutore, di avvio dell'esecuzione del contratto, ai sensi di quanto previsto dall'art. 19 del D.M. 7 marzo 2018 n. 49 recante «Approvazione delle linee guida sulle modalità di svolgimento delle funzioni del direttore dei lavori e del direttore dell’esecuzione».

In considerazione di quanto sopra, la durata del presente appalto non potrà essere tacitamente prorogata o rinnovata. Nei tre anni successivi alla stipula del contratto e sulla base del progetto proposto dall’Appaltatore in sede di gara, la Società Appaltante si riserva la facoltà di affidare all’Appaltatore stesso la ripetizione di servizi analoghi a quelli oggetto del presente appalto, con riferimento ai servizi di manutenzione correttiva, adeguativa ed evolutiva e di assistenza, agli stessi patti e condizioni del contratto iniziale.

La durata del contratto in corso di esecuzione potrà essere modificata per il tempo necessario alla conclusione delle procedure necessarie per l’individuazione di un nuovo contraente, ai sensi dell’art. 106, comma 11 del D.Lgs. n. 50/2016. In tal caso il contraente è tenuto all’esecuzione delle prestazioni oggetto del contratto agli stessi, o più favorevoli, prezzi, patti e condizioni.

5 Il contesto

5.1 Contesto applicativo

Nel presente paragrafo vengono descritti i sistemi esistenti (SICER - PATIMM) per i quali occorre acquisire i servizi oggetto del presente appalto e meglio precisati nel prosieguo. Per quanto concerne il sistema PATMOB, invece, il sistema attualmente in esercizio, essendo obsoleto e non rispondente alle esigenze della committenza, sarà dismesso all’avvio del nuovo (la cui realizzazione è oggetto del presente appalto).

Il sistema SICER, nato dal riuso della soluzione contabile in uso presso Regione Liguria e successivamente evoluto per adeguarlo alle esigenze della Regione Lazio, si compone di diversi moduli, di seguito descritti.

• Bilancio

• Atti Amministrativi

• Ciclo Passivo

• Ciclo Attivo

• GSA

• Adempimenti Fiscali

• Integrazione con sistemi esterni

• MIR

• Controllo di gestione

• Controllo strategico

• Bollettino Ufficiale (BUR)

• Gestione Orsie

• Gestione cespiti

5.1.1 Bilancio

L’ambito “Bilancio” gestito sul sistema SICER si compone di due macro-fasi, propedeutiche tra di loro:

• fase Preventivo;

• fase Rendiconto.

Figura 1 - Le macro-fasi del bilancio

Gli assunti principali su cui si base il sistema SICER sono di seguito elencati:

• gli attori coinvolti nel processo, riportati nelle pagine a seguire, sono stati individuati e determinati sulla base dell’organizzazione in essere presso l’Amministrazione, trasposta nelle logiche di gestione attuabili attraverso il sistema SICER. Il sistema consente la possibilità, attraverso apposita profilazione, di effettuare le dovute modifiche, rispetto alle funzionalità assegnate ai diversi profili, piuttosto che alla numerosità degli stessi;

• SICER consente l’utilizzo di un approccio gestionale non limitato ad un singolo esercizio, ma come parte di un continuum temporale;

• SICER non necessita di attività tecniche di chiusura/apertura esercizio, con il relativo riporto dei saldi: tali importi vengono generati in tempo reale dal sistema, in base alle diverse esigenze che possono emergere nel corso dell’esercizio;

Relativamente alla fase “preventivo”, il workflow di processo implementato a sistema viene di seguito rappresentato:

Figura 2 - Workflow di processo del Preventivo (1/2)

12. Consolidamento del

Bilancio

13. Validazione Legge di

Bilancio

14. Approvazione bozza

Legge di Bilancio e Legge di Stabilità

15. Approvazione Legge

di Bilancio e Legge di

Stabilità

16. Approvazione

Documento Tecnico di

Accompagnamento

17. Approvazione

Bilancio gestionale

18. Aggiornamento

Bilancio Reticolare

19. Invio schemi di

bilancio alla BDAP

20. Elaborazione e invio

Piano degli Indicatori alla BDAP

21. Pubblicazione sul sito dell’Ente e sul portale dell’Amministrazione Trasparente

End

Consiglio Regionale

Giunta Regionale

Direzione Regionale Bilancio, Governo Societario, Demanio e Patrimonio

Area Bilancio

Analisi dei Processi – Xxxxxx Xxxxxxxx

Fase Preventivo (2/2)

Figura 3 - Workflow del processo del Preventivo (2/2)

Le principali funzionalità implementate a sistema rispetto all’ambito specifico – fase preventivo - sono le seguenti:

Attività

Descrizione

Informazioni aggiuntive

Definizione DEFR

Acquisizione del Documento Strategico di Programmazione (DSP) elaborato ad inizio legislatura.

Individuazione delle “Azioni Cardine”, alle quali assegnare un livello di priorità, tra i seguenti:

• alta;

• media;

Il DSP contiene le linee di indirizzo della Programmazione Regionale per l’intera durata della legislatura.

Il DEFR riclassifica le azioni di policy rispetto ai differenti destinatari (individui, famiglie, imprese).

		• bassa.
2	Riaccertamento intermedio	La fase di riaccertamento intermedio consente di poter avere l’immediata visibilità, rispetto a: • differimenti; • disimpegni.
3	Calcolo risultato di amministrazione presunto (stima residui, FPV e avanzo)	Valorizzazione al 31/12, a sistema, di: • Residui attivi presunti; • Residui passivi presunti; • Avanzo di amministrazione e FPV presunto • Saldo di cassa presunto.	Tale attività, richiesta in fase di previsione e di consuntivazione, concorre alla stima del “Risultato di Amministrazione Presunto”, sulla base del quale è possibile effettuare le stime per il bilancio di previsione in costruzione.
4	Stima delle entrate	Inserimento, a sistema, delle previsioni di entrata per il triennio di riferimento. Validazione, mediante firma digitale da parte dei Responsabili delle Direzioni, della previsione di entrata proposta.	Le entrate vengono distinte in: • Entrate vincolate; • Entrate a libera destinazione.
5	Stima delle spese ed invio Schede di Negoziazione alle Direzioni	Inserimento, a sistema, (all’interno delle schede di negoziazione) delle previsioni di spesa per il triennio di riferimento. Una volta compilate le Schede di Negoziazione da parte dell’ Area Bilancio, vengono inviate alle strutture per prendere visione e potersi esprimere (nel campo note).	Le principali informazioni contenute nelle Schede di Negoziazione sono: • Proposta di Stanziamento previsionale nel triennio di riferimento • Campo note, valorizzabile dalle strutture; • Indicazione del “Codice Azione”, che rappresenta una riclassificazione degli obiettivi di mandato Le spese ricevute, potranno avere natura discrezionale o obbligatoria (es. spese obbligatorie): • Spese di personale; • Spese per rimborso mutui e prestiti; • Fondi regionali finanziati da leggi.
6	Espressione parere sulla proposta ricevuta	Verifica, a sistema, della proposta di stanziamento contenuta nella Scheda di Negoziazione	Rispetto alla Scheda di Negoziazione ricevuta, le Direzioni possono esprimere il loro parere solo attraverso l’inserimento di una nota nell’apposito campo. In tal modo comunicano la necessità di un diverso stanziamento, da discutere poi in ambito di contraddittorio. La struttura, inoltre, associa ai singoli capitoli presenti nella Scheda di Negoziazione, la relativa legge collegata e, nel

			caso in cui tale capitolo risulterà finanziato da più leggi, inserirà, in corrispondenza di una singola legge, la quota parte dell’importo assegnato sul capitolo.
7	Eventuale trattazione tecnico-politica e reinvio proposta alle Direzioni	Contraddittorio con le singole Direzioni, all’interno del quale vengono condivise le esigenze della Direzione e, contestualmente, viene definita la nuova proposta di assegnazione. Ritrasmissione della Scheda di Negoziazione	.
8	Presa d’atto assegnazione	Previa ricezione della nuova Scheda di Negoziazione, accettazione della proposta di assegnazione condivisa in precedenza
9	Verifica equilibri e Schede di Negoziazione	Verifica, a sistema, degli equilibri generali di bilancio, sulla base delle proposte validate nelle fasi precedenti.
10	Quantificazione della variazione	Confermando le Schede di Negoziazione vengono consolidate a sistema le scritture di bilancio
11	Predisposizione Bilancio Reticolare Previsionale	Predisposizione su SICER della proposta di Bilancio Reticolare Previsionale, nel quale vengono dettagliate le entrate libere, sia di parte corrente che di parte capitale. Tali entrate, a seconda del livello di classificazione, vengono collegate al corrispondente livello di spesa da coprire.
12	Consolidamento del Bilancio	Elaborazione, a sistema, dei documenti e degli allegati alla proposta di Xxxxx di Xxxxxxxx, ed alla proposta Legge di Stabilità Regionale, da portare in approvazione in Giunta Regionale.	Il SICER prevede le funzionalità che consentono l’elaborazione degli schemi, e di tutti gli allegati al bilancio, in maniera informatizzata e perfettamente aderente alla normativa vigente.
13	Validazione proposta di Xxxxx di Bilancio	Verifica, a sistema, della documentazione prodotta.
14	Approvazione proposta di Xxxxx di Xxxxxxxx e Legge di Stabilità	Approvazione della bozza di Legge di Bilancio (degli schemi di bilancio e degli allegati) e della Legge di Stabilità.
15	Approvazione Legge di Xxxxxxxx e Legge di Stabilità	Approvazione della Legge di Bilancio (degli schemi di bilancio e degli allegati) e della Legge di Stabilità, come derivanti dall’approvazione della Giunta, più eventuali modifiche e/o emendamenti
16	Approvazione Documento Tecnico di Accompagnament o	Contestualmente all’approvazione della Legge di Bilancio, si approva il Documento Tecnico di Accompagnamento, riportante le unità di voto del bilancio in categorie e macro aggregati.	L’elaborazione degli schemi e degli allegati al Documento Tecnico di Accompagnamento sono garantiti dal sistema, al pari dei documenti ed allegati alla Legge di Xxxxxxxx.
17	Approvazione Bilancio Gestionale	Contestualmente all’approvazione del Documento Tecnico di Accompagnamento, viene approvato il Bilancio gestionale.	Con il bilancio finanziario gestionale si provvede all’assegnazione delle risorse finanziarie, stanziate nei pertinenti capitoli di spesa, ai dirigenti titolari dei centri di responsabilità amministrativa.

18	Aggiornamento Bilancio Reticolare	A fronte delle eventuali modifiche e/o emendamenti, viene aggiornato il Bilancio Reticolare, con delibera, rispetto alla versione dell’esercizio precedente
19	Invio schemi di bilancio alla BDAP	Elaborazione a sistema degli schemi di bilancio in formato .xbrl. Invio alla BDAP.
20	Elaborazione e invio Piano degli Indicatori alla BDAP	Elaborazione del Piano degli Indicatori. Estrazione del Piano in formato .xbrl. Invio alla BDAP.
21	Pubblicazione sul sito dell’Ente e sul Portale dell’Amministrazi one Trasparente	Pubblicazione degli schemi di bilancio sul sito di Regione Lazio e sul Portale dell’Amministrazione Trasparente.

Start

1. Calcolo saldi di

bilancio

2. Predisposizione

delibera ed allegati

6. Trasmissione Nota alle

Direzioni

7. Riaccertamento

ordinario dei residui

4. Quadratura dati

5. Approvazione

risultanze del Tesoriere

3. Redazione del Conto

del Tesoriere

Tutte le Direzioni

Direzione Regionale Bilancio, Governo Societario, Demanio e Patrimonio

Ente Tesoriere

Area Ragioneria ed Entrate

Area Bilancio

Analisi dei Processi – Xxxxxx Xxxxxxxx

Fase Rendiconto (1/3)

Relativamente alla fase “rendiconto”, il workflow di processo implementato a sistema viene di seguito rappresentato:

Figura 4 - Workflow del processo del Rendiconto (1/3)

8. Elaborazione Bilancio

Reticolare

9. Invio Schede di

Programmazione

10. Elaborazione

scritture Economico

Patrimoniali

11. Validazione bozza di

Riaccertamento

Ordinario

12. Approvazione

Riaccertamento

13. Ricezione delibera

14. Definizione

composizione Risultato

di Amministrazione

15. Elaborazioni per

chiusura esercizio

16. Consolidamento

schemi di Rendiconto

17. Validazione proposta

di Legge di Rendiconto Generale, schemi ed allegati

18. Approvazione

proposta Legge di

Rendiconto Generale

19. Invio Rendiconto alla

Corte dei Conti

Direzione Bilancio

Direzione Regionale

Programmazione Economica

Direzione Regionale Bilancio, Governo Societario, Demanio e Patrimonio

Giunta Regionale

Area Esecuzione Contratti,

Servizi e Forniture

Area Ragioneria ed Entrate

Analisi dei Processi – Xxxxxx Xxxxxxxx

Fase Rendiconto (2/3)

Figura 5 - Workflow del processo del Rendiconto (2/3)

Figura 6 - Workflow del processo del Rendiconto (3/3)

Le principali funzionalità implementate a sistema rispetto all’ambito specifico – fase rendiconto - sono le seguenti:

Funzione

Descrizione

Informazioni aggiuntive

Calcolo saldi di bilancio.

Elaborazione, a sistema, ai fini dell’approvazione del “rendiconto” di:

• Residui attivi presunti;

• Residui passivi presunti;

• Fondo Pluriennale Vincolato (FPV);

• Avanzo di Amministrazione;

• Entrate da mutui e prestiti [utili al ricalcolo del Debito Autorizzato e Non Contratto (DANC)].

Il sistema garantisce una gestione unica del bilancio, secondo una logica di prosecuzione dell’attività contabile “senza soluzione di continuità”.

Il calcolo dei residui e la stima dell’Avanzo di Amministrazione Presunto, rappresentano la prima fase dell’attività di rendicontazione, e viene garantito interamente a sistema.

Tali dati vengono consolidati in sede di Riaccertamento Ordinario (generalmente a marzo) perimetrato in

		Analisi, a sistema, e stima dei saldi di bilancio per elaborare il “preconsuntivo”.	corso di esercizio, precedente al Riaccertamento Ufficiale. I dati su cui vengono elaborate le stime, essendo interamente a sistema, sono sempre aggiornati alla data di stima. Tale attività è svolta ai sensi dell’art. 42, cc. 9 10 11 del D.lgs. 118/2011.
2	Predisposizione delibera ed allegati	Predisposizione, a sistema, della delibera di approvazione del bilancio “preconsuntivo”. Elaborazione, a sistema, di tutti gli allegati alla delibera di approvazione.
3	Redazione del Conto del Tesoriere	Estrazione, a sistema, report con elenco di mandati e reversali. Invio al Tesoriere per verifica della quadratura di cassa al 31/12.
4	Quadratura dati	Controllo ed eventuali modifiche, offline, a mandati o reversali per risolvere eventuali discordanze tra i dati estrapolati da SICER e quelli in possesso del Tesoriere.
5	Approvazione risultanze del Tesoriere	Sottoscrizione, a sistema, della stampa del Tesoriere. Presa d’atto delle risultanze mediante Determina Dirigenziale.
6	Trasmissione Nota alle Direzioni	Invio, mediante sistema PRO.S.A., alle singole direzioni, di una comunicazione contenente una scadenza per l’effettuazione delle operazioni di riaccertamento ordinario dei residui.
7	Riaccertamento ordinario dei residui	Visualizzazione, a sistema, dello stock di residui attivi e passivi presunti al 31/12 di propria competenza. Validazione, a sistema, tramite firma digitale e/o cartacea, delle risultanze finali della stima effettuata.	Le direzioni sono abilitate ad effettuare, a sistema, la stima dei residui presunti di propria competenza, in merito alle seguenti scelte: • Riduzione del residuo attivo/passivo; • Differimento di esigibilità del residuo; • Mantenimento a residuo.
8	Elaborazione Bilancio Reticolare	Elaborazione del Bilancio Reticolare ai fini della stima del budget per capitolo	La Direzione Bilancio, Patrimonio…… si basa su una stima degli accertamenti al 31/12 dell’anno precedente per la pianificazione delle spese da autorizzare.
9	Invio Schede di Programmazione	Invio alle strutture file all’interno del quale, per ogni capitolo esistente a sistema, vengono dettagliati gli impegni fino al 31/12	L’invio delle Schede di Programmazione, propedeutico alla stima “a finire” degli impegni (classificati anche per grado di priorità), viene effettuato in due distinti momenti dell’esercizio (solitamente marzo e luglio). La stima degli impegni deve

			risultare minore o uguale al budget di inizio esercizio. La Struttura, in questa sede, indica, per ogni impegno, il Codice Azione di riferimento. Nel caso in cui ci siano delle variazioni nella programmazione prevista, le Strutture possono inviare delle variazioni della Scheda di Programmazione, la quale, previa validazione, cancella la precedente.
10	Elaborazione scritture economico- patrimoniali	Elaborazione sul SICER, opportunamente integrato con i sistemi dell’ente di gestione del patrimonio immobiliare (ad oggi PATIMM) e mobiliare (ad oggi PATMOB), delle scritture economico patrimoniali relative al patrimonio (ammortamenti, rivalutazioni, svalutazioni ecc.). Elaborazione, sempre a sistema, di eventuali scritture economico patrimoniali di rettifica- integrazione alle singole scritture derivanti dalla contabilità finanziaria, tipicamente: • Ratei e risconti; • Fondo ferie recuperi personale dipendente; • Fondi rischi ed oneri;	Il SICER è integrato con i sistemi di gestione del patrimonio (PATIMM e PATMOB)
11	Validazione bozza di Riaccertamento Ordinario	Ricezione documentazione a sistema. Invio offline, alla Giunta Regionale, della bozza di delibera e degli allegati.
12	Approvazione Riaccertamento	Ricezione, offline, della documentazione inviata. Approvazione della delibera di riaccertamento ordinario dei residui. Invio documenti ed allegati all’Area Ragioneria ed Entrate
13	Ricezione delibera	Ricezione, offline, della Delibera approvata in Giunta Regionale con il definitivo riaccertamento ordinario dei residui. Conservazione e tenuta agli atti della documentazione ricevuta.
14	Definizione composizione Risultato di Amministrazione	Quantificazione finale della composizione del Risultato di Amministrazione (eventuale Avanzo Vincolato, destinato/accantonato/ecc.).
15	Elaborazioni per chiusura esercizio	Sulla base dei dati ottenuti, elaborazione, a sistema, di: • Fondo Crediti di Dubbia Esigibilità; • Conto Economico e Stato Patrimoniale.	Il sistema garantisce l’elaborazione di tutte le operazioni contabili, di natura finanziaria ed economico patrimoniale.

16	Consolidamento schemi di Rendiconto	Elaborazione, a sistema, di schemi e allegati al Rendiconto, come previsti dalla normativa vigente. Elaborazione, a sistema, della proposta di Legge di Rendiconto Generale. Invio, a sistema, alla Direzione Bilancio.	Gli allegati prodotti sono: • Elenco dei capitoli variati/assestati (in entrata e in uscita) per titolo/missione; • Conto analitico dei residui per anzianità del residuo stesso; • Prospetto degli indicatori.
17	Validazione proposta Legge di Rendiconto Generale, schemi ed allegati	Verifica della documentazione ricevuta, ai fini dell’emissione a sistema del parere di regolarità tecnico-contabile. Invio, offline, alla Giunta Regionale, della bozza di Legge e degli allegati.
18	Approvazione proposta legge di Rendiconto Generale	Approvazione della bozza di legge di Rendiconto Generale, degli schemi di bilancio e degli allegati. Invio, offline, documento all’Area Ragioneria ed Entrate.
19	Invio Rendiconto alla Corte dei Conti	Previa ricezione della bozza approvata dalla Giunta Regionale, invio offline del documento alla Corte dei Conti ai fini delle verifiche necessarie alla parifica definitiva.
20	Parifica Rendiconto	Attività di istruttoria sul documento di Rendiconto per la parifica definitiva. Invio Rendiconto parificato all’Area Ragioneria ed Entrate.
21	Invio Rendiconto parificato al Consiglio Regionale	Previa ricezione da parte della Corte dei Conti della parifica del rendiconto, con possibili modifiche o integrazioni da apportare, invio fuori sistema al Consiglio Regionale.	In caso di modifiche richieste dalla CDC, in sede di parifica, il sistema garantisce la correzione dei documenti, e la ripetizione di tutti i passaggi precedenti.
22	Approvazione legge di Rendiconto Generale	Approvazione in Consiglio Regionale della legge di rendiconto generale, degli schemi di bilancio e degli allegati, come derivanti dall’approvazione della Giunta, tenuto conto del parere della Commissione Consiliare competente.
23	Esecutività Rendiconto	Inserimento a sistema della definitiva esecutività della legge di rendiconto generale, degli schemi e degli allegati, dei residui e degli accertamenti/impegni reimputati.
24	Invio a BDAP dati definitivi Rendiconto	Estrazione a sistema dei file da caricare sulla Banca Dati delle Amministrazioni Pubbliche (BDAP), compresi gli indicatori del Rendiconto.

25	Elaborazione bilanci consolidati	Elaborazione degli schemi per i due bilanci consolidati dell’ente: • Consolidato Giunta-Consiglio; • Consolidato Gruppo Regione Lazio. Caricamento ed Invio, a sistema, per la validazione e l’emissione del parere di regolarità.
26	Validazione bilanci consolidati	Ricezione, a sistema, degli schemi di bilancio consolidato. Verifica documentazione ai fini dell’espressione del parere di regolarità. Invio offline, in Giunta Regionale.
27	Approvazione proposta consolidato Giunta- Consiglio	Approvazione della proposta di delibera consiliare sul bilancio consolidato Giunta- Consiglio.	Tale tipologia di bilancio consente la visione completa della consistenza finanziaria del gruppo composto da: • Regione Lazio; • Consiglio Regionale.
28	Approvazione bilancio consolidato Giunta-Consiglio	Approvazione bilancio consolidato delle due gestioni (Giunta e Consiglio)
29	Approvazione proposta consolidato Gruppo Regione Lazio	Approvazione della proposta di delibera consiliare sul bilancio consolidato della Regione Lazio.
30	Approvazione bilancio consolidato Gruppo Regione Lazio	Approvazione bilancio consolidato

5.1.2 Atti Amministrativi

Il modulo di gestione atti amministrativi consente la generazione ed il workflow approvativo di tutti gli atti amministrativi adottati dall’amministrazione. Mediante l’introduzione del nuovo sistema amministrativo-contabile SICER, è stato possibile introdurre la gestione completamente dematerializzata degli atti, mediante l’integrazione con il sistema di firma digitale in uso presso l’amministrazione, distinguendo per oggi passo di processo le casistiche in cui fosse necessario l’apposizione di una firma digitale “forte” ovvero di una firma elettronica mediante visto a sistema.

Il sistema è stato reso parametrizzabile e configurabile in modo che per ciascun profilo sia possibile in ogni momento stabilire se attivare la firma “forte” ovvero la firma “debole”.

Per tutte le tipologie di atto gestite a sistema, sono previsti i ruoli indicati nella figura seguente:

Data la premessa sopra citata in merito alla configurabilità del sistema, l’indicazione relativa alla firma forte ovvero la firma debole indicata in figura rappresenta l’obiettivo a cui tende l’amministrazione.

ove presenti Cabina di Regia**

RDP Area Ragioneria

ed Entrate

Dirigente Area Ragioneria

ed Entrate

Direttore Bilancio, Governo societario, demanio e patrimonio

Segreteria della Giunta

Segretario di Giunta Presidente Regione

Lazio

Atti del Presidente

Atti dirigenziali

Per ogni macro-tipologia di atto gestito a sistema, nella figura seguente vengono indicati gli approvatori finali degli stessi:

ove presenti Cabina di Regia*

RDP Area GSA*

Dirigente Area GSA*

Direttore Bilancio, Governo societario, demanio e patrimonio

Presidente Regione

Lazio

ove presenti Cabina di Regia*

RDP Area Ragioneria

ed Entrate

Dirigente Area Ragioneria

ed Entrate

Direttore Bilancio, Governo societario, demanio e patrimonio

Area Attività

Istituzionali

Dirigente Area Attività

istituzionali

Direttore Direzione Affari

Istituzionali, personale e S.I. Ufficio di Gabinetto

Presidente Regione

Lazio

Iter di approvazione dell’atto

*GSA = Area Monitoraggio e raccordo del bilancio con le risorse del Sistema sanitario

Cabina di Regia* RDP Area Ragioneria

ed Entrate/GSA

Dirigente Area Ragioneria

ed Entrate/GSA

Direttore Bilancio, Governo societario, demanio e patrimonio

Atti del Presidente - DCA

Atti della Giunta/Consiglio

L’attività della Cabina di Regia e della Direzione Bilancio, Governo societario, demanio e patrimonio è prevista per gli atti dirigenziali con pagina contabile (Determinazioni). Tali atti sono inoltre necessariamente prodotti per l’impegno dei fondi vincolati tramite bollinatura

Legenda

Firma tramite visto a

sistema

Firma digitale

dell’atto

Attori coinvolti nell’attività di "bollinatura" esclusivamente nel caso l’atto rechi oneri finanziari

** L’approvazione della Cabina di Regia si articola nella firma tramite visto a sistema da parte di tre attori: Segretario generale, Direttore

Bilancio, Governo societario, demanio e patrimonio, Direttore Programmazione Economica

Il monitoraggio di tutte le fasi del ciclo di vita dell’atto viene garantito attraverso l’assegnazione a ciascun attore coinvolto nel processo di uno stato approvativo dell’istanza, nonché dalla possibilità di conservare a sistema tutta la documentazione prodotta a corredo dell’atto (pareri, istruttorie tecniche, ecc…).

Il paradigma seguito nella realizzazione del modulo “Atti amministrativi” prevede la gestione di due folder associati all’atto:

• folder dedicato alla gestione documentale, tramite il quale vengono compilati tutti gli attributi qualificativi dell’atto e vengono allegati i testi prodotti extra-sistema;

• folder dedicato alla “pagina contabile”, gestito unicamente per le tipologie di atto che prevedono movimentazioni contabili. In particolare da tale folder vengono attivate le funzionalità necessarie all’inserimento delle scritture contabili previste per la particolare tipologia di atto, è possibile la consultazione delle scritture precedentemente inserite ed è possibile attuale la cancellazione delle proposte di impegno/accertamento/liquidazione non ancora esecutive.

I movimenti contabili che possono essere istanziati a partire dalla pagina contabile sono i seguenti:

• impegni e relative variazioni

• accertamenti e relative variazioni

• prenotazioni di impegni

• liquidazioni

Gli obiettivi che si è inteso raggiungere mediante l’adozione della pagina contabile associata all’atto amministrativo sono di seguito brevemente elencati:

• monitoraggio della fonte di finanziamento della spesa, mediante la gestione del concetto di componente che fornisce copertura alla spesa che si sta istanziando

• verifica per la spesa libera della disponibilità di budget (bilancio reticolare)

• gestione degli impegni pluriennali con esecutività immediate sulle annualità sulle quali vengono assunti

• creazione del fondo pluriennale vincolato (FPV) all’atto dell’inserimento di un pluriennale che trova copertura nell’anno corrente

• copertura puntuale della spesa vincolata tramite la gestione del vincolo impegno – accertamento

• gestione della prenotazione di impegno con conseguente allocazione di stanziamento

5.1.3 Ciclo passivo

Relativamente all’ambito “Ciclo passivo”, gli obiettivi che si è inteso raggiungere mediante l’introduzione del sistema SICER vengono brevemente descritti di seguito:

• il processo implementato a sistema risponde al modello organizzativo adottato dall’amministrazione e declinato rispetto alle regole contabili adottate sul sistema SICER e compliant rispetto alla normativa vigente;

• SICER introduce il concetto di documento passivo che determina la movimentazione di conti economico patrimoniali, in funzione del v livello degli impegni a copertura del documento stesso.

• SICER si interfaccia con il Sistema dei Pagamenti (sistema dell’amministrazione per la gestione della fatturazione elettronica) attraverso un’apposita area di staging, grazie alla quale vengono veicolate le fatture pervenute all’Amministrazione sulla Scrivania Virtuale del Direttore, sulla base del Codice IPA (associato sia alla Direzione che alla specifica Area) presente in fattura. Tale area è stata concettualmente ideata come “costola” di collegamento con il Sistema Pagamenti. SICER, infatti, secondo tempi e modi definiti, individuerà le fatture

elettroniche da acquisire ed importare. Contestualmente all’importazione, SICER dà la possibilità di accettazione o rifiuto delle stesse. L’eventuale rifiuto viene trasmesso al Sistema Pagamenti per la veicolazione allo SDI;

• SICER introduce il concetto di “protocollazione”, inteso come assegnazione di un Codice Identificativo Univoco, assegnato al documento contestualmente all’import dello stesso all’interno del sistema, a prescindere dal probabile rifiuto;

• SICER gestisce la possibilità di agganciare al Provvedimento di Liquidazione un documento passivo che giustifichi la causa di sostenimento della spesa in esame;

• SICER permette di portare a sistema la gestione della Cassa Economale e, in generale, la gestione dell’Area Esecuzione Contratti, Servizi e Forniture. Il sistema, infatti, prevede il supporto all’elaborazione della documentazione principalmente utilizzata/elaborata dall’Area in questione, ovvero:

o Rendiconto trimestrale: attraverso il quale, gli Economi Decentrati, con cadenza trimestrale, rendicontano all’Economo Centrale le spese sostenute, dettagliate per impegno (incluse le movimentazioni effettuate sul conto corrente bancario e le entrate/uscite di cassa);

o Rendiconto finale: attraverso il quale, l’Economo Centrale, rendiconta alla Corte dei Conti le spese sostenute, dettagliate per capitolo (incluse le movimentazioni effettuate sul conto corrente bancario e le entrate/uscite di cassa);

• SICER consente sia la storicizzazione che la mobilità dei ruoli rispetto ai cambiamenti della struttura organizzativa dell’Amministrazione, per cui qualsiasi atto esteso da un soggetto che al tempo “t” è incardinato in una certa struttura, sarà sempre identificato come tale, nonostante lo stesso soggetto, al tempo “t+1”, possa essere incardinato presso un’altra struttura.

Il processo implementato sul sistema SICER nel modulo di gestione del ciclo passivo viene rappresentato in figura seguente:

Start

Processo di gestione

degli Atti Amministrativi con Impegno di Spesa TO BE

1. Gestione Ordine

di Acquisto

2. Acquisizione

Fattura

Competenza

della propria

Struttura?

Cambio Ufficio di

destinazione

3. Assegnazione

Fattura

4. Accettazione e

B gestione fatture

assegnate

Fattura corretta? No Rifiuto Fattura

5. Generazione

documento passivo

6. Creazione Provvedimento di Liquidazione in

provvisorio

Dirigente/Direttore Struttura proponente

Estensore/Responsabile Unico del

Procedimento (RUP)

Analisi dei Processi – Ambito Ciclo Passivo

Ciclo Passivo (1/2)

Figura 7 - Workflow del processo di Ciclo Passivo (1/2)

Area Ragioneria ed Entrate

7. Firma Provvedimento di Liquidazione in

provvisorio

Dirigente/Direttore della Struttura

Proponente

Analisi dei Processi – Ambito Ciclo Passivo

Ciclo Passivo (2/2)

Figura 8 - Workflow del processo di Ciclo Passivo (2/2)

5.1.4 Ciclo Attivo

La gestione del Ciclo Attivo si compone di due macro-ambiti:

• gestione del Provvisorio di Xxxxxxx, inviato dell’Ente Tesoriere, che si conclude con l’emissione della reversale e la regolarizzazione del provvisorio;

• gestione della Fattura Attiva da parte delle Direzioni abilitate, che si conclude con la verifica dell’avvenuto pagamento da parte del soggetto debitore. Tale fattispecie è stata trattata nell’analisi degli “Adempimenti Fiscali”, poiché implica numerosi risvolti di natura fiscale.

Entrambi i casi possono scaturire dall’attività di accertamento dell’entrata.

Figura 9 - Modalità di gestione del Ciclo Attivo

Gli obiettivi principali che si è inteso raggiungere mediante l’introduzione del sistema SICER per l’ambito specifico sono i seguenti:

• il Ciclo Attivo viene gestito attraverso la creazione di Ordinativi di Incasso e Reversali in modalità provvisoria, i quali, agganciati ad un documento attivo (anch’esso generato in provvisorio) diventano definitivi, e, quindi, pronti per la regolarizzazione in Tesoreria, solo previa attività di istruttoria effettuata dell’Area Ragioneria ed Entrate;

• l’intero processo di gestione del Ciclo Attivo è stato implementato sulla base del modello organizzativo in essere presso l’amministrazione;

• le richieste di accertamento che pervengono all’Area Ragione ed Entrate dalle altre Direzioni devono essere storicizzate;

• realizzazione della piena integrazione con il Sistema di Interscambio (SDI) attraverso apposita interfaccia di comunicazione con il Sistema Pagamenti, sia per quanto attiene l’invio e la trasmissione della fattura elettronica in formato XML, sia per la gestione del flusso di ritorno (accettazione/rifiuto fattura);

• realizzazione della piena integrazione con la piattaforma SIOPE+, per l’invio delle reversali di incasso, per il tramite dell’emissione di un flusso OPI compatibile;

• gestione diversificata per ogni utente profilato, consentendo diversi livelli di autorizzazione (popolazione dati, firma digitale, invio flussi al Tesoriere, ecc.).

Il processo implementato a sistema per la gestione dei provvisori di entrata viene di seguito rappresentato:

Start

1. Ricezione Provvisori di

entrata

2. Smistamento

Provvisori di entrata

3. Visualizzazione

Provvisori assegnati

Assegnazione

corretta?

Presenza di

accertamento a sistema?

4. Inserimento

accertamento

5. Lavorazione

Provvisorio in entrata

6. Istruttoria Provvisorio

in entrata

Esito positivo?

7. Generazione

C Ordinativo di Incasso per

regolarizzazione

Provvisorio

Direzioni Responsabili dell’Entrata

Area Ragioneria ed Entrate

Analisi dei Processi – Ambito Ciclo Attivo TO BE (1/2)

Figura 10 - Workflow di processo del Ciclo Attivo - provvisori di entrata (1/2)

Figura 11 - Workflow di processo di Ciclo Attivo – provvisori di entrata (2/2)

Relativamente alla gestione della fattura attiva il processo implementato sul sistema SICER è il seguente:

5.1.5 GSA

Figura 12 - Workflow di processo di Ciclo Attivo – Fattura Attiva

La gestione contabile ed operativa della Sanità regionale è mutata radicalmente a seguito delle novità introdotte dal D. Lgs. n° 118/2011 inerente il processo di armonizzazione dei sistemi contabili e degli schemi di bilancio.

Le disposizioni contenute nel Decreto interessano tutte le Regioni:

• per la parte del bilancio regionale che riguarda il finanziamento e la spesa del relativo servizio sanitario, rilevata attraverso scritture di contabilità finanziaria;

• per la parte del finanziamento del servizio sanitario regionale direttamente gestito, rilevata attraverso scritture di contabilità economico-patrimoniale (Gestione Sanitaria Accentrata);

• per il consolidamento dei conti degli enti sanitari e, se presente, della gestione sanitaria accentrata presso la Regione.

La Regione Lazio adempie a tutti gli obblighi relativi alla gestione delle risorse sanitarie, ai sensi della normativa vigente. I capitoli afferenti il perimetro sanitario sono di esclusiva competenza della Direzione Salute e Integrazione Sociosanitaria, la quale assolve alle funzioni di programmazione del fabbisogno sanitario, elaborazione del Bilancio preventivo e consuntivo della Gestione Sanitaria Accentrata (GSA), amministrazione operativa delle risorse nonché di consolidamento dei conti delle aziende sanitarie. Inoltre, la Regione Lazio si è dotata di una struttura di Ragioneria appositamente dedicata alla gestione dei capitoli sanitari, la quale è competente nella definizione del perimetro sanitario, supporto nell’elaborazione del bilancio finanziario sanitario, monitoraggio del consumo delle risorse, gestione della cassa sanitaria.

Gli obiettivi principali che si è inteso raggiungere mediante la gestione dell’ente GSA su SICER sono di seguito brevemente descritti:

• implementazione delle funzionalità necessarie a definire il perimetro dei capitoli GSA e conseguentemente indirizzare incassi e pagamenti sul relativo conto di tesoreria;

• classificazione di ogni singolo capitolo con indicazione della propria appartenenza al perimetro GSA o alla gestione Ordinaria: ogni impegno ed accertamento sarà conseguentemente classificato come appartenente al perimetro sanitario o ordinario in funzione del capitolo su cui insiste;

• implementazione della gestione delle risorse sanitarie tramite l’implementazione a sistema dell’Azienda GSA: essa si configura come un’entità autonoma la quale costituisce l’ennesima azienda sanitaria. Essa assolve alla funzione di interfaccia tra la Regione e le Aziende Sanitarie per quanto concerne i trasferimenti diretti a quest’ultime, di gestore della quota del finanziamento accentrata, di raccordo e consolidamento dei bilanci del Servizio Sanitario Regionale (SSR);

• la movimentazione economico – patrimoniale dell’azienda GSA avviene automaticamente e contestualmente alla contabilizzazione da parte dell’Ente Giunta di impegni e accertamenti e al riscontro dei mandati e reversali relativi al perimetro GSA;

• attraverso il sistema SICER è possibile gestire:

o le operazioni gestionali in ambito sanitario;

o l’elaborazione dei prospetti di bilancio preventivo e consuntivo, SSR;

• l’azienda GSA è dotata di un proprio Piano dei Conti, uniformato a quello delle Aziende Sanitarie, al fine di tradurre le operazioni in Contabilità Finanziaria in scritture Economico – Patrimoniali (CO.EP) in partita doppia;

• il SICER è dotato delle componenti applicative atte a rilevare automaticamente le scritture in Contabilità Finanziaria del perimetro sanitario e conseguentemente provvedere alla loro declinazione in Contabilità Economico – Patrimoniale dell’Azienda GSA;

• le scritture finanziarie inerenti l’ambito sanitario vengono declinate in Contabilità Economico Patrimoniale sulla base dei capitoli dei Piano dei Conti Finanziario, in alcuni casi associati al fornitore delle aziende sanitarie;

• il conto di tesoreria della GSA è univocamente assegnato ai capitoli perimetrati GSA;

• il sistema implementa le funzionalità di “gemmazione” per la duplicazione dei capitoli di spesa facenti parte della gestione ordinaria di cui, nel corso dell’esercizio, una quota parte si rivela da destinare al perimetro sanitario;

• il sistema prevede la classificazione, attraverso il flag GSA, di tutti gli atti inerenti il perimetro sanitario, al fine di realizzare le opportune operazioni di transcodifica delle operazioni finanziarie sul Piano dei Conti GSA;

• l’emissione dei provvedimenti di liquidazione/mandati di pagamento a beneficio delle strutture sanitarie o per conto della GSA è un processo implementato a sistema;

• il sistema prevede la gestione della “bollinatura” degli atti “Decreti del Commissario ad Acta” che recano oneri finanziari;

Le principali funzionalità sviluppate rispetto all’ambito GSA sono di seguito descritte:

Fase	Attività		Descrizione
Programmazione del Fabbisogno Sanitario Regionale	Programmazion e del Fabbisogno Sanitario Regionale		Programmazione annuale del fabbisogno sanitario regionale che definisce gli importi stimati relativi alla: • la quota di finanziamento indistinto (finanziamento statale) ed i criteri di ripartizione nei confronti delle strutture sanitarie della Regione; • la quota per il finanziamento delle attività del Servizio Sanitario Regionale (SSR) in gestione accentrata regionale (GSA), svolte in nome e per conto delle Aziende Sanitarie regionali; • la quota per il finanziamento delle funzioni assistenziali (destinazione finalizzata).
Definizione del perimetro dei capitoli sanitari	Ricognizione annuale del perimetro del sistema sanitario		Visualizzazione a sistema ed analisi dell’elenco dei capitoli del bilancio regionale, in entrata ed in uscita, afferenti al perimetro sanitario (Missione 13 – tutela della salute). Ricognizione annuale su SICER del perimetro sanitario tramite inclusione di capitoli già esistenti nel bilancio regionale, attualmente non ricompresi nel suddetto perimetro.
			Eventuale aggiornamento della matrice di transcodifica che deve prevedere almeno un’istanza per ogni capitolo GSA movimentato.
	Gemmazione dei capitoli		Istituzione a sistema di nuovi capitoli afferenti al perimetro sanitario attraverso la gemmazione di quelli appartenenti alla gestione ordinaria.
			Aggiornamento delle anagrafiche dei capitoli di afferenza del perimetro sanitario su SICER.
			Inserimento nella matrice di transcodifica dell’istanza/e che mappa il capitolo generato GSA con le coppie di conti ECOPAT
	Inserimento delle Entrate del Bilancio di previsione		Visualizzazione a sistema dei capitoli in entrata del perimetro sanitario. Inserimento su SICER delle entrate per il triennio successivo, secondo la suddivisione in: • Finanziamento ordinario corrente di provenienza statale; • Finanziamento aggiuntivo corrente, da incrementali delle aliquote fiscali regione; • Finanziamento del disavanzo pregresso; • Finanziamento per investimenti. Invio automatico di una notifica all’Area Bilancio per la validazione della proposta e il consolidamento del Bilancio
	Stima Spese	delle del	Visualizzazione a sistema dei capitoli di spesa del perimetro sanitario.

	Bilancio di Previsione	Inserimento su SICER delle spese per il triennio successivo, secondo la suddivisione in: • Spesa sanitaria corrente per il finanziamento dei Livelli Essenziali di Assistenza LEA (diviso a sua volta in Indistinto, vincolato a specifici obiettivi, Aggiuntivo corrente); • Spesa sanitaria aggiuntiva per il finanziamento di livelli di assistenza sanitaria superiori ai LEA; • Spesa per finanziamento del disavanzo pregresso; • Spesa per investimenti. Invio automatico di una notifica all’Area Bilancio per la validazione della proposta e il consolidamento del Bilancio
	Elaborazione Bilancio preventivo GSA	Inserimento su Azienda GSA del bilancio preventivo economico della Gestione Sanitaria Accentrata (GSA), relativamente alla quota di finanziamento regionale gestito in modalità accentrata per conto delle strutture sanitarie. Validazione a sistema delle poste inserite. Invio automatico di una notifica all’Area Bilancio di avvenuta predisposizione del bilancio previsionale GSA.
	Assegnazione delle risorse alla Direzione Salute e Integrazione Sociosanitaria	Attribuzione da parte del Segretario generale, mediante adozione di apposita Delibera di Giunta, delle risorse afferenti l’ambito sanitario, alla Direzione Salute e Integrazione Sociosanitaria.
Gestione delle risorse sanitarie	Gestione atti di impegno/accerta mento delle risorse	Gestione annuale delle risorse del sistema sanitario, attraverso l’adozione, attraverso le funzionalità previste dal Modulo “Atti Amministrativi”, degli atti di determinazione (di accertamento/impegno di risorse) o Decreto del Commissario ad Acta (atti di indirizzo politico – amministrativo emanati dal Commissario ad Acta, in attuazione del Piano di Rientro del Disavanzo sanitario regionale). Invio automatico degli atti con pagina contabile all’Area Monitoraggio e raccordo del bilancio con le risorse del sistema sanitario, per la verifica della correttezza della stessa, secondo l’iter di approvazione dell’istanza
	Eventuale approvazione della spesa	In caso di elaborazione della determina da parte di una Direzione diversa dalla Direzione Salute e Integrazione Sociosanitaria, ricezione di una notifica di richiesta di approvazione dell’utilizzo delle risorse sanitarie. Visualizzazione su SICER della proposta di atto e dei dati anagrafici presenti a sistema. Validazione a sistema della proposta che consente alla Direzione proponente ad operare sui capitoli sanitari
	Controllo contabile degli atti	Ricezione a sistema di tutti gli atti di determinazione/decreto del Commissario ad Acta inerenti l’ambito sanitario. Controllo della pagina contabile secondo una checklist predefinita. “Bollinatura” del decreto del commissario ad acta recante oneri finanziari, al fine di vincolare l’importo ad una determinata e futura spesa, che sarà attuata con apposito atto di determina.
	Gestione delle liquidazioni e dei pagamenti	Verifica e controllo a sistema dei provvedimenti di liquidazione emessi dalle Direzioni Proponenti a favore delle SSR.

		Emissione a sistema da sistema dei mandati di pagamento a beneficio delle strutture sanitarie / per conto della GSA, attraverso il modulo di Ciclo Passivo.
	Riconciliazione periodica delle partite	Visualizzazione periodica a sistema degli incassi e pagamenti realizzati tramite la cassa sanitaria. Riconciliazione su SICER delle partite in entrata e in uscita, verificando che eventuali risorse transitate sul conto ordinario siano trasferite sul conto sanitario. Validazione dei dati aggiornati.
	Rilevazione contabile dei fatti gestionali (non in gestione accentrata)	Rilevazione contabile automatica in partita doppia delle operazioni finanziarie non gestiti in logica accentrata Gestione Sanitaria Accentrata (es. trasferimenti ricevuti ed erogati nei confronti delle strutture regionali) Tali operazioni alimentano lo Stato Patrimoniale del Bilancio GSA (Es. il trasferimento di risorse dalla Regione alle aziende determina l’estinzione del debito verso le strutture e la corrispondente uscita di cassa nello Stato Patrimoniale GSA).
	Rilevazione contabile dei fatti gestionali (in accentrata)	Operazione automatica di transcodifica in partita doppia delle operazioni finanziarie afferenti la gestione della quota di fondo sanitario regionale in logica accentrata e per conto delle strutture sanitarie
Monitoraggio della spesa sanitario e rendicontazione	Monitoraggio trimestrale della gestione delle risorse sanitarie	Elaborazione di reportistica relativa alla gestione delle risorse sanitarie, per garantire la rilevazione di: • impegni e accertamenti realizzati • incassi registrati/uscite di cassa verso gli enti SSR • residui attivi e passivi • importo totale liquidato ed incassato.
	Sollecito produzione atti di competenza	Nel caso in cui l’analisi dei dati trimestrali mostri dei disallineamenti rispetto ai valori target intermedi fissati in entrata e in uscita, invio sollecito, tramite strumenti offline, alle Direzioni regionali per l’adozione degli atti di impegno/accertamento delle risorse.
	Eventuale richiesta di aggiornamento on going del perimetro	Ricezione a sistema di una notifica di richiesta di variazione del bilancio sanitario da parte della Direzione Salute e Integrazione Sociosanitaria o dalle altre Direzioni Regionali, per variazione degli stanziamenti tra capitoli sanitari o per la costituzione per gemmazione di nuovi capitoli da includere nel perimetro sanitario. Valutazione delle richieste di variazione emesse dalle Direzioni Regionali con il supporto della Direzione Salute e Integrazione Sociosanitaria.
	Eventuale elaborazione atto di variazione del bilancio	Elaborazione a sistema: • di apposita Determina dirigenziale firmata dal Direttore della Direzione Programmazione Economica, Bilancio, Demanio e Patrimonio in caso di variazione degli stanziamenti tra capitoli sanitari esistenti. • di una Delibera di Giunta che dispone la variazione di bilancio per costituzione di nuovi capitoli per gemmazione

	Variazione a sistema del bilancio di previsione	Variazione a sistema degli stanziamenti tra i capitoli di bilancio e/o gemmazione di un nuovo capitolo da includere nel perimetro sanitario, secondo quanto disposto dalla Determina/DGR approvata dalla Giunta. Allocazione a sistema delle risorse sui nuovi capitoli costituiti.
	Monitoraggio finale stato di avanzamento degli atti	Visualizzazione a sistema dei dati annuali relativi allo stato di avanzamento degli impegni/accertamenti nonché degli importi liquidati e pagati rispetto al totale stanziato. Eventuale invio alla Direzione di competenza di un sollecito di adozione degli atti necessari al fine di assicurare l’equilibrio di esercizio (dato dall’impegno di tutte le risorse accertate)
	Verifica dei dati con il Conto del Tesoriere	Supporto all’Area Ragioneria ed Entrate nell’attività di verifica dei mandati e reversali emessi in ambito sanitario nell’esercizio di riferimento con le risultanze del conto del tesoriere.
	Riconciliazione finale delle risorse	Visualizzazione su SICER delle rilevazioni finanziarie ed economico – patrimoniali dei fatti amministrativi intercorsi nell’esercizio. Riconciliazione finale a sistema, realizzata nei primi mesi dell’anno successivo all’esercizio di riferimento, delle scritture in contabilità economico-patrimoniale degli enti SSR (ricavi da trasferimenti) con il totale del Fabbisogno Sanitario Regionale (trasferito dallo stato o di competenza regionale) nonché gli impegni e gli accertamenti effettuati nell’esercizio (Contabilità finanziaria). Adozione dell’atto di determinazione dirigenziale con cui si certifica la coerenza tra risorse ricevuta dallo Stato, i bilanci degli enti SSR e gli impegni e accertamenti iscritti nel Bilancio Regionale.
	Rendicontazion e dei risultati di gestione	Visualizzazione su SICER dei dati di fine anno necessari alla alimentazione del rendiconto (pagamenti ed incassi, situazione dei residui, impegni ed accertamenti) Produzione di opportuni report di riclassificazione delle spese sanitarie (per Macro aggregati di spesa, indicatori di monitoraggio della cassa, degli impegni, accertamenti, ecc.) sulla base della codifica dei capitoli, utilizzata per la delimitazione del perimetro. Elaborazione, tramite strumenti offline, della relazione al rendiconto per quanto concerne l’ambito sanitario, oggetto di giudizio di parifica da parte della Corte dei Conti.
Consolidamento dei bilanci sanitari	Estrazione finale delle scritture GSA	Visualizzazione delle scritture economico – patrimoniali dal modulo GSA a sistema.
	Elaborazione scritture di Assestamento	Elaborazione su SICER delle scritture di assestamento (accantonamento, ratei, risconti, ecc.), con l’obiettivo di riconciliazione (per natura della spesa e/o per creditore) dei conti GSA con il Bilancio finanziario Regionale.
	Redazione del Bilancio di esercizio GSA	Redazione a sistema del Bilancio di Esercizio della GSA.
	Consolidamento dei bilanci enti SSR	Il consolidamento dei Bilanci di Esercizio di tutte le strutture sanitarie regionali e della GSA viene gestito mediante il sistema SIGES (1). Elisione delle partite intercompany

Approvazione del Bilancio Consolidato

Validazione a sistema del consolidato SSR e invio delle risultanze all’Area Bilancio per i successivi adempimenti connessi all’approvazione del Bilancio Regionale.

5.1.6 Adempimenti Fiscali

I principali obiettivi che si è inteso di raggiungere con l’introduzione del sistema SICER rispetto all’ambito in oggetto sono i seguenti:

• possibilità di gestire l’IVA istituzionale e commerciale (Split Payment, ecc.), in maniera totalmente automatizzata e a sistema, già nella prima fase di rilevazione contabile del documento (di entrata e di uscita), mediante associazione tra “quota IVA” e documento contabile;

• contabilizzazione separata delle ritenute IVA di Consiglio e Giunta, trattandosi di enti che hanno il medesimo codice fiscale; questo per consentire alla struttura regionale competente di effettuare le quadrature con i dati dai due enti ed effettuare i versamenti in maniera corretta e completa;

• gestione del bilancio dell’IVA commerciale, consentendo l’effettuazione delle corrette scritture nei registri IVA acquisti, vendite, corrispettivi, ecc., effettuando le potenziali compensazioni con altre imposte e gestendo i recuperi dell’IVA a credito;

• gestione delle ritenute d’acconto con rilevazione in maniera automatizzata delle operazioni di pagamento dei lavoratori autonomi e dei liberi professionisti, in modo da supportare in maniera corretta la gestione delle ritenute, il loro versamento, e la certificazione dei compensi erogati

Le principali funzionalità rese disponibili dal sistema SICER per l’ambito in analisi sono le seguenti:

Fase	Funzione	Descrizione
IVA Split Payment	Liquidazione fattura passiva	Inserimento a sistema dell’atto di liquidazione.
	Pagamento fattura passiva	Emissione, a sistema, mandato di pagamento.
	Accertamento entrate IVA Split Payment- Consiglio Regionale	Accertamento tramite atti di liquidazione, a sistema, dell’IVA trattenuta ai sensi dell’art.17-ter del D.P.R. n. 633/1972.
	Accertamento entrate IVA Split Payment- Giunta Regionale	Accertamento tramite atti di liquidazione, a sistema, dell’IVA trattenuta ai sensi dell’art.17-ter del D.P.R. n. 633/1972.
	Versamento IVA Split Payment-Giunta Regionale e Consiglio Regionale	Estrazione reportistica con indicazione del totale dovuto IVA Split Payment. Versamento, extra sistema, tramite F24EP del dovuto mensile.
Ritenute Fiscali- Contributi	Effettuazione ritenute- Consiglio Regionale	Effettuazione ritenute personale dipendente, amministratori, collaboratori, extra sistema. Accertamento, a sistema, delle ritenute effettuate.

		Versamento extra sistema, tramite F24, delle ritenute effettuate
	Effettuazione ritenute- Giunta Regionale	Effettuazione ritenute personale dipendente, extra sistema. Accertamento, a sistema, delle ritenute effettuate. Versamento extra sistema, tramite F24, delle ritenute effettuate.
	Riconciliazione-quadratura dei dati	Estrazione, a sistema, dei seguenti prospetti: • Ritenute fiscali (IRPEF, addizionale comunale, addizionale regionale); • Ritenute previdenziali e assistenziali (INPS); • IRAP metodo retributivo dell’ente. Riconciliazione-quadratura, extra sistema, tra i dati presenti nei report estrapolati ed i versamenti effettivi effettuati, o da effettuare, presenti in contabilità.
	Integrazione IRAP	Controllo extra sistema, sulla piattaforma del MEF “NoiPa”, dell’Irap mensile da versare, calcolata sulla base delle retribuzioni del personale dipendente. Elaborazione report, su SICER, dell’IRAP mensile dovuta. compilazione manuale del F24 dell’IRAP totale dovuta. Versamento F24EP corretto.
Certificazioni uniche	Estrapolazione Certificazioni uniche-Consiglio Regionale	Estrazioni di supporto a sistema che consentono di produrre le certificazioni uniche annuali inerenti percipienti (liberi professionisti, ex consiglieri, amministratori ecc.). Invio, a sistema, delle certificazioni effettuate.
Certificazioni uniche	Estrapolazione Certificazioni uniche-Giunta Regionale	Estrazioni di supporto a sistema che consentono di produrre le certificazioni uniche annuali inerenti i percipienti. Invio, a sistema, delle certificazioni effettuate.
Attività commerciale	Fatturazione attiva	Emissione, a sistema, delle fatture attive commerciali
	Elaborazioni XXX	Xxxxxxxxxxxx, a sistema, delle informazioni per le dichiarazioni mensili.
	Dichiarazione IVA	Gestione, a sistema, di eventuali rettifiche da apportare nei sezionali IVA.
Dichiarazioni telematiche	Invio dichiarazioni	Invio, offline, all’ Area Affari Generali, Monitoraggio dei Debiti e Gestione della Piattaforma MEF, delle dichiarazioni di propria competenza.
Dichiarazioni telematiche	Trasmissione dichiarazioni	Previa ricezione offline, invio, mediante piattaforma dell’Agenzia delle Entrate, delle dichiarazioni fiscali mensili/annuali dell’Ente.

5.1.7 Integrazione con sistemi esterni

Il sistema SICER è integrato con altri sistemi dell’amministrazione al fine di automatizzare, laddove possibile, lo scambio di informazioni garantendo il dominio dell’informazione a ciascun sistema che ne detiene la ownership.

I sistemi con cui SICER è integrato sono i seguenti:

• Sistema pagamenti: SICER implementa uno specifico scambio informativo mediante web service con il Sistema Pagamenti, il quale a sua volta, colloquia con il Sistema di Interscambio (SDI). Il trasferimento informativo previsto tra i due sistemi (SICER-SISTEMA PAGAMENTI) è bidirezionale:

o fatture passive: SICER acquisisce le fatture oggetto di pagamento dal Sistema Pagamenti, comunicando eventuale rifiuto della stessa;

o fatture attive: SICER trasmette le fatture oggetto di incasso, ricevendo eventuale rifiuto della stessa.

• Debiti informativi con la PA centrale: I flussi informativi prodotti da SICER verso la PA centrale sono:

o trasmissione dei bilanci e dei dati contabili alla Banca Dati delle Amministrazioni Pubbliche (BDAP) tramite gli standard previsti: “eXtensible Business Reporting Language” (XBRL) “eXtensible Markup Language” (XML)

o Estrazione a supporto dell’aggiornamento della PCC - Piattaforma dei Crediti Commerciali relativo alle fatture pagate per cassa economale.

• Piattaforma PARER per la conservazione sostitutiva: tale integrazione garantisce la possibilità per tutti i documenti gestiti dal sistema SICER e firmati digitalmente (atti amministrativi dematerializzati, ordinativi di pagamento e di incasso, bur ecc..) di essere trasmessi ai fini della conservazione alla piattaforma PARER resa disponibile dalla regione Xxxxxx Xxxxxxx;

• Sistema del Personale (SIR – HR): l’integrazione con il sistema del personale garantisce l’acquisizione su SICER delle informazioni necessarie per alimentare l’anagrafica relativa alla pianta organica (sia relativamente a nuovi inserimenti che a variazioni);

• Bridge SIOPE+: l’integrazione con la piattaforma Bridge Siope+ consente al sistema SICER di implementare la comunicazione, secondo quanto previsto dalla normativa, con la piattaforma centralizzata di banca d’Italia denominata Siope+ ai fini della gestione di ordinativi di pagamento ed ordinativi di incasso;

• Portale OpenData: il sistema SICER è integrato con il portale OpenData di Regione Lazio, fornendo i dati disponibili nella sezione OpenSpesa (: xxxx://xxxxxxxxx.xxxxx.xx/):

In particolare, la sezione OpenSpesa consente di evidenziare per esercizio:

• Il totale pagato per soggetto;

• I singoli pagamenti per soggetto

I dati salienti che SICER fornisce sono i dati relativi a:

o Mandati di pagamento per soggetto ed anno;

o Anagrafica soggetti (ragione sociale / cognome/ nome).

• Portale della Trasparenza: il sistema SICER è integrato con il portale della trasparenza di Regione Lazio (xxxx://xxx.xxxxxxx.xxxxx.xx/xx_xxxxxxxxxxxxxxx_xxxxxxxxxxx), al fine di fornire i dati disponibili nelle sezioni Provvedimenti e Bilancio

• Sistema di Firma digitale remota: l’integrazione con il sistema di firma remota in uso presso l’amministrazione è finalizzato ad implementare la possibilità di firmare in forma singola ovvero massiva e in modalità remota i documenti gestiti dal sistema SICER ed in particolare:

o Atti amministrativi (laddove previsto);

o OPI da inviare a SIOPE+

o Fatture attive da inviare a SDI

• Sistema PATMOB: l’integrazione attualmente in essere tra il sistema SICER ed il sistema PATMOB prevede che l’alimentazione del sistema PATMOB con la scheda bene avvenga contestualmente alla creazione della scheda cespite su SICER. In particolare, la scheda cespite (e quindi la scheda bene) viene creata da SICER contestualmente alla rilevazione contabile (registrazione documento passivo) quando il conto intercettato dal V livello dell’impegno che fornisce copertura al documento è un conto patrimoniale relativo a beni mobili e non un conto di costo; in dettaglio SICER crea contestualmente entrambe le schede (cespite + bene) e trasmette tramite un apposito servizio la scheda bene su PATMOB. Tale integrazione dovrà essere oggetto di revisione nel presente intervento a seguito della realizzazione del nuovo sistema PATMOB.

• Sistema PATIMM: l’integrazione di SICER con il sistema esterno PATIMM, mediante il quale viene gestito il patrimonio immobiliare di Regione Lazio, è stata realizzata al fine di acquisire su SICER le informazioni che consentono di popolare la scheda di ammortamento per l’anno oggetto di acquisizione. Inoltre, se non esiste la scheda cespite corrispondente, l’integrazione con il sistema PATIMM (mediante di acquisizione di un file denominato rendiconto) produce la generazione della scheda cespite, il tutto in modo tale che SICER sia in grado di eseguire le scritture di ammortamento di fine esercizio relative ai beni immobili.

• Sistema SIGEM: tale integrazione con il sistema SIGEM che gestisce i fondi europei (FESR – FSE) consente di istanziare le scritture contabili relative ad interventi gestiti sulla piattaforma SIGEM sul sistema contabile ed acquisire di ritorno gli esiti delle operazioni contabili inizializzate. Tale integrazione è realizzata mediante l’uso di web services e di un orchestratore denominato “wrapper”; l’obiettivo che si è inteso raggiungere mediante tale architettura è garantire la separazione delle basi informative, implementando la comunicazione tra i vari sistemi mediante web services, evitando quindi duplicazioni di dati ed infine orchestrando i diversi processi che vengono invocati secondo il workflow previsto.

5.1.8 MIR

• Il sotto sistema MIR rappresenta un sotto sistema a disposizione della amministrazione regionale di ausilio e supporto a tutte le attività necessarie per l’identificazione, la gestione, il monitoraggio degli investimenti regionali.

Il sotto sistema MIR rappresenta un sotto sistema di ausilio e supporto a tutte le attività necessarie per l’identificazione, la gestione, il monitoraggio degli investimenti regionali. Il sotto sistema gestisce i seguenti attori, in base alle specifiche necessità di gestione delle informazioni e al ruolo di ciascun utente:

o Responsabile della programmazione regionale (Direttore della Direzione Regionale Programmazione Economica)

o Responsabile della gestione del bilancio regionale (Direttore della Direzione Regionale Bilancio, Governo Societario, Demanio e Patrimonio)

o Responsabili regionali degli investimenti (Direzioni Regionali competenti)

o Responsabili della gestione delle procedure di investimento (Dirigenti o Funzionari facenti funzione)

o Responsabili del procedimento

o Estensori per l’inserimento dei dati iniziali e dei successivi aggiornamenti

o Organismi intermedi e/o società regionali delegate a gestire le procedure di investimento

o Personale regionale

Il sotto sistema MIR realizza tutte le funzioni necessarie all’ acquisizione dei dati alfanumerici relativi agli investimenti della Regione Lazio ed in particolare:

• Anagrafica dell’intervento nella quale vengono caricati i dati più significativi dell’investimento;

• Previsionale, che contiene il cronoprogramma relativo alle fasi di avanzamento fisico e a quelle di liquidazione delle risorse finanziarie.

Rispetto all’anagrafica del sistema sono gestiti:

• Dati di programmazione finanziaria:

o capitoli di bilancio da utilizzare per il finanziamento dell’intervento;

o somma da impegnare, ovvero, nel caso di più capitoli, per ognuno il relativo importo che concorre al finanziamento e la somma complessiva (senza la suddivisione per annualità);

o programma di finanziamento correlato al capitolo di bilancio/ai capitoli;

o azioni di mandato, tra quelle approvate nel Documento Strategico di Programmazione (DSP), correlate al capitolo di bilancio/capitoli selezionati.

• Dati di natura tecnico-amministrativa:

o denominazione dell’intervento: campo libero contenente il titolo dell’intervento da finanziare che dovrà essere identico a quanto sarà riportato nella determinazione di impegno;

o Codice Unico Progetto (CUP): in questa fase può anche essere omesso, ma diventa obbligatorio prima di procedere alla liquidazione. Nel caso di Regione Lazio come Stazione Appaltante, il CUP deve essere inserito già in questa fase;

o tipologia dell’investimento: si seleziona una delle tipologie possibili (“Lavori Pubblici”, “Acquisizione di Beni”, “Acquisizione di Servizi”); per gli interventi con più tipologie viene indicata la “tipologia prevalente”

• Dati di governance:

o responsabile del procedimento

o soggetto beneficiario:

o dati localizzativi di tipo testuale:

Il MIR prevede il cosiddetto “Previsionale” ossia il cronoprogramma relativo alle fasi di avanzamento fisico e di liquidazione delle risorse finanziarie:

• definizione del contenuto;

• definizione del piano di avanzamento fisico e del piano della spesa (provvedimenti di liquidazione)

Inoltre il MIR consente, a seguito della validazione dell’intervento, di associare allo stesso un “Codice Investimento” che rappresenta una chiave univoca di identificazione dello stesso e di riconciliazione nelle varie fasi di erogazione effettuate dal bilancio regionale. Il Codice Investimento viene ereditato negli atti e nelle relative pagine contabili predisposti sul sistema SICER a valere su quell’investimento; quando la determinazione viene resa esecutiva, l’Intervento entra nella fase di “Gestione” e il cronoprogramma relativo alle fasi di avanzamento fisico e di liquidazione delle risorse finanziarie si amplia riportando anche i dati reali gestiti dal bilancio.

Il MIR consente, dopo la fase di identificazione, una fase di gestione che garantisce il controllo dell’avanzamento fisico dell’intervento e il rispetto della tempistica prevista per i relativi provvedimenti di liquidazione, per le singole fasi definite durante l’inserimento del cronoprogramma.

Infine il sistema rende disponibile funzioni di monitoraggio per effettuare:

• una rilevazione puntuale dell’intervento in cui vengono monitorati tutti i parametri di un singolo investimento (monitoraggio puntuale)

• una rilevazione complessiva degli investimenti regionali in cui vengono monitorati parametri generali di classi di interventi relativi agli investimenti regionali caratterizzati da elementi comuni (Monitoraggio esteso).

5.1.9 Controllo di gestione

I processi che sono supportati dal modulo controllo di gestione di Sicer sono i seguenti:

Dirigente apicale (Direzione/Age

Start

1. Visualizzazione

delle anagrafiche di competenza

2. Definizione bud

quadrimest success

Dirigente di II livello (Area/Ufficio di

staff)

Workflow di processo TO BE – Ambito Controllo di Gestione

Pianificazione operativa

o Pianificazione operativa:

o valutazione quadrimestrale delle performance

Start

1. Acquisizione dati

personale

2. Acquisizione dati

dirigenziali

3. Associazione dei

costi del personale di

Area

4. Allocazione risorse

umane

5. Aggiornamento

schede utente

6. Aggiornamento

Note di dettaglio-

Attività-Prodotti

7. Aggiornamento

Note di dettaglio- Attività-Prodotti

8. Aggiornamento

Note di dettaglio- Attività-Prodotti

9. Visualizzazione

schede utenti

10. Quantificazione

output realizzati

11. Rilevazione

automatica prodotti

realizzati

12. Calcolo Indicatore

di Efficacia programmato

13. Attribuzione e

calcolo Indicatore di Efficacia Richiesto

14. Verifica

correttezza delle rilevazioni

15. Validazione

rilevazione quadrimestrale

16. Validazione

rilevazione

quadrimestrale

End

Dirigente apicale (Direzione/Agenzia)

Dirigente di II livello (Area/Ufficio di staff)

Area Controllo di Gestione, Organizzazione e

Formazione

Analisi dei Processi – Ambito Processo Controllo di Gestione

Valutazione quadrimestrale della performance

o analisi degli scostamenti e rendicontazione:

Start

1. Consultazione

reportistica gestionale

2. Analisi dei report

3. Valutazione

proposte di azioni correttive

4. Trasmissione

reportistica

5. Pubblicazione

report

End

Dirigente apicale (Direzione/Agenzia)

Dirigente di II livello (Area/Ufficio di staff)

Analisi dei Processi – Ambito Processo Controllo di Gestione

Analisi degli scostamenti e rendicontazione

Si precisa che il modulo “controllo di gestione” sarà oggetto di revisione nell’ambito del presente intervento.

5.1.10Controllo strategico

• il modulo di “controllo strategico” gestisce le seguenti principali funzionalità:

o sistema di controllo integrato: tale sistema è stato realizzato su SICER tramite funzioni per la gestione di tutte le anagrafiche di sistema e delle relazioni tra le stesse oltre che l’alimentazione delle stesse, il tutto propedeutico alla realizzazione del controllo strategico. Per quanto riguarda l’integrazione con il bilancio, la copertura viene garantita:

▪ dall’associazione delle risorse finanziarie agli obiettivi (missione – programma per gli obiettivi strategici, capitolo per gli obiettivi organizzativi ed individuali) con verifica della disponibilità della risorsa finanziaria sulla base dello stanziato a bilancio (previsionale);

▪ dall’evidenza nelle schede di monitoraggio dei dati contabili a consuntivo (Stanziato, Impegnato, Liquidato).

o Per quanto riguarda per le modifiche organizzative e di personale, il modulo attinge i dati dalla stessa fonte utilizzata per il controllo di gestione (SIR-HR / NOIPA), raggruppando gli stessi per direzione e categoria giuridica. In dettaglio:

anagrafiche di base:

▪ Piano annuale

▪ Obiettivi strategici

▪ Obiettivi organizzativi

▪ Obiettivi individuali

▪ Personale

▪ Indicatori

▪ Fasi relazioni previste:

o direzione

▪ obiettivi strategici per direzione per esercizio e piano

o obiettivo strategico - direzione

▪ indicatori per esercizio e piano

▪ obiettivi organizzativi per esercizio e piano

▪ risorse umane per esercizio e piano

▪ risorse finanziarie per esercizio e piano (missione programma)

▪ obiettivi individuali per esercizio e piano

o obiettivo organizzativo - obiettivo strategico - direzione

▪ indicatori per esercizio e piano

▪ risorse umane per esercizio e piano

▪ risorse finanziarie per esercizio e piano (capitolo)

▪ fasi per esercizio e piano

o obiettivi individuali per obiettivo strategico per direzione

▪ indicatori per direzione per obiettivo strategico per esercizio e piano

▪ risorse umane per esercizio e piano

▪ risorse finanziarie (missione programma) per esercizio e piano

▪ fasi per obiettivo strategico per esercizio e piano

o compilazione e gestione schede obiettivi di tipo strategico operativo: in particolare il sistema prevede la compilazione di schede di programmazione (piano delle performance che rappresentano in dettaglio gli obiettivi strategici triennali e gli obiettivi operativi annuali (sia organizzativi che individuali) assegnati ai dirigenti apicali, unitamente agli indicatori ed ai risultati attesi (valori target) che sono utilizzati per svolgere la verifica annuale sul loro grado di realizzazione) e schede di obiettivi individuali (riferiti ad una direzione).

o gestione monitoraggio delle performance

o gestione della valutazione e rendicontazione

Si precisa che il modulo “controllo strategico” sarà oggetto di revisione nell’ambito del presente intervento.

5.1.11Bollettino Ufficiale (BUR)

• il sistema SICER prevede un modulo ad hoc per la generazione del bollettino ufficiale della Regione LAZIO; tale bollettino viene composto sia mediante acquisizione degli atti amministrativi già gestiti a sistema dall’apposito modulo (laddove ne sia prevista la pubblicazione), sia mediante acquisizione delle richieste di inserzione presentate sul portale esterno da parte degli inserzionisti. I processi gestiti dal modulo sono i seguenti:

Start

Gestione Atti

Amministrativi TO BE con indicazione di pubblicazione sul BUR

1. Visualizzazione

atti esecutivi

2. Selezione atti da

importare

3. Istruttoria formale

Richiesta

Atto corretto? No autorizzazione

pubblicazione dati

sensibili

4. Istruttoria

giuridica

5. Creazione

Bollettino

6. Finalizzazione

Bollettino

7. Firma e

pubblicazione Bollettino

End

Direttore Ufficio Redazione

Responsabile Ufficio Redazione

Ufficio Redazione

Analisi dei Processi – Ambito BUR – Bollettino Ufficiale Regione TO BE

Atti interni

Processo per la pubblicazione di atti esterni:

Start

Gestione Atti

Amministrativi TO BE con indicazione di pubblicazione sul BUR

1. Visualizzazione

atti esecutivi

2. Selezione atti da

importare

3. Istruttoria formale

Richiesta

Atto corretto? No autorizzazione

pubblicazione dati

sensibili

4. Istruttoria

giuridica

5. Creazione

Bollettino

6. Finalizzazione

Bollettino

7. Firma e

pubblicazione Bollettino

End

Direttore Ufficio Redazione

Responsabile Ufficio Redazione

Ufficio Redazione

Analisi dei Processi – Ambito BUR – Bollettino Ufficiale Regione TO BE

Atti interni

5.1.12Gestione Orsie

• Il sistema SICER garantisce l’attività di gestione finanziaria, controllo e rendicontazione dei progetti finanziati con investimenti pubblici (siano essi regionali, statali o europei) che l’Organismo Internazionale per gli Interventi Europei è chiamato a svolgere attraverso il sistema esterno SIGEM. Tali attività sono infatti possibili grazie all’utilizzo di apposite interfacce, attraverso le quali, SICER rende disponibili dati di natura contabile, legati alle movimentazioni economico-finanziarie dei capitoli associati ai singoli progetti. SICER, pertanto, consente, mediante parametrizzazione dell’anagrafica del capitolo, di poter “associare” l’importo stanziato sullo stesso (o quota parte) ad un determinato progetto. Nell’ambito della comunicazione bidirezionale, SICER:

o acquisisce dal sistema esterno (SIGEM) le informazioni relative alle anagrafiche dei progetti censiti, codificandole ad hoc. Le informazioni gestite sono:

o Codice Progetto;

o Descrizione Progetto;

o Anagrafica Progetto;

o Data inizio validità Progetto;

• rende disponibili, a SIGEM, le informazioni contabili relative ai soli capitoli censiti come appartenenti al perimetro OrSIE;

• consente la possibilità di estrazione della reportistica utile alla rendicontazione progettuale.

• consente la possibilità che un atto amministrativo appartenente al perimetro OrSIE possa essere gestito attraverso l’utilizzo del modulo SICER-Atti. In tal caso, possono essere utilizzati i capitoli che appartengono al perimetro OrSIE.

• SICER, infine, consente l’estrazione di una serie di report utili alla rendicontazione dei diversi stream progettuali (analisi specifiche per Asse), nonché all’approvazione del bilancio della Giunta Regionale, in ordine al principio di armonizzazione dei sistemi contabili e degli schemi di bilancio delle Regioni stabilito dal D. Lgs. 18/2011.

5.2 Contesto Applicativo – Sistema PATIMM

Attualmente presso l’Amministrazione Regionale è in uso un sistema informativo per la gestione del Patrimonio Immobiliare e Demanio che consente la gestione integrata dei processi e la condivisione delle informazioni basata sul principio dell'integrità del dato. Tale sistema ha permesso di semplificare e automatizzare i processi gestiti dalle aree “Gestione dei beni patrimoniali” e “Politiche di valorizzazione dei beni demaniali e patrimoniali” e rendere più tempestiva e completa la fruizione delle informazioni trattate. Ad oggi l’Amministrazione regionale gestisce, attraverso il sistema, i dati di circa 13.000 beni di proprietà, tra Unità Immobiliari (ad uso abitativo e diverso) e terreni.

Il software in particolare consente, inoltre, non solo di acquisire, aggiornare e consultare in tempo reale le informazioni relative al patrimonio immobiliare e demaniale della Regione Lazio, ma anche di gestire la contabilità, i contratti e i pagamenti.

Dal punto di vista del contesto è possibile individuare diverse aree tematiche di riferimento:

• Inventario

• Gestione amministrativo contabile

• Report e caricamenti

• Gis

Il sistema consente l’accesso ad ogni area interessata limitatamente alle informazioni di pertinenza della funzione caratteristica: sono infatti abilitate funzionalità differenti secondo l’area di appartenenza dell’utente. Le operazioni consentite ai diversi utenti sulle informazioni condivise saranno inoltre definite in funzione dell’area di appartenenza e del ruolo operativo dell’utente specifico.

Inventario

Il patrimonio immobiliare della Regione Lazio consiste nell’insieme dei cespiti immobili, terreni e beni demaniali: tutti insieme questi vanno a formare l’inventario regionale, la cui produzione è disciplinata dal regolamento regionale.

Per quanto riguarda i cespiti ognuno di questi può essere considerato come un’unità gerarchica: in particolare un complesso può essere costituito da uno o più fabbricati, ognuno dei quali può avere uno o più unità immobiliari e ognuna di queste può essere scomposta in uno o più locali (unità abitative, negozi, garage, posti auto, cantine). Ogni unità immobiliare è dunque l’elemento base su cui opera il sistema: questa può essere oggetto di locazione attiva, passiva o locazione passiva con sublocazione attiva. Ad ogni unità immobiliare si possono ricondurre dati catastali e tecnici; in particolare le principali informazioni gestite riguardano Ubicazione, Denominazione, Stima, Rendita, Provenienza, Reddito, Valore, Destinazione d’uso.

Le macro funzionalità per gestire i beni sono le seguenti:

• Inserimento di un’unità immobiliare

• Aggiornamento delle informazioni associate ad un’unità immobiliare

• Caricamento della documentazione caratteristica dell’unità immobiliare (planimetrie, dati catastali, dati del Genio Civile, concessioni edilizie, piantine in formato vettoriale, disegni, ecc.)

• Gestione di variazioni sugli immobili: ad esempio, frazionamenti ed accorpamenti, variazioni di consistenza e riclassamenti, ecc.

Per quanto riguarda terreni e beni demaniali, l’unità cardine è il terreno stesso, il quale può essere frazionato in particelle. Le principali informazioni gestite riguardano Luogo, Denominazione, Stima, Rendita, Provenienza, Reddito, Valore, Destinazione d’uso, presenza di fabbricati.

Le principali funzionalità per la gestione dei dati anagrafici relativi ai terreni sono le seguenti:

• Gestione dell’inserimento / aggiornamento dei dati alfanumerici e grafometrici del terreno

• Gestione del frazionamento e dell’accorpamento di particelle di terreno

• Eventuale completamento delle informazioni sulla particella e dei fabbricati ubicati su di essa mediante foto di campo

• Variazione di destinazione di una particella

• Gestione delle misure con funzioni di suddivisione ed aggregazione in tipologie di misure

• Collegamento al terreno di disegni, planimetrie

• Stampe personalizzate delle schede dei terreni

Gestione amministrativo contabile

Il sistema permette di supportare le attività concernenti la gestione amministrativa e contabile mediante funzionalità specifiche che concernono sia il ciclo attivo sia il ciclo passivo da una parte, sia la gestione delle concessioni sui terreni dall’altra.

Per quanto riguarda la gestione delle locazioni attive le principali funzionalità sono le seguenti:

• Gestione anagrafica

• Gestione anagrafiche contratti

• Gestione anagrafiche inquilini

• Gestione contabile

• Gestione contratti

• Determinazione canoni

• Gestione bollettazione (avviso di pagamento) e/o fatturazione

• Gestione comunicazioni

• Gestione interessi di mora

• Gestione preventivi di spesa

• Stabili gestiti dalla proprietà

• Stabili gestiti da amministratori esterni

• Gestione consuntivi di spesa

• Fasi di contabilizzazione

• Gestione fiscale

Ogni contratto di locazione attiva può avere ad oggetto una o più unità immobiliari o una frazione di essa e potrà avere uno o più conduttori (inquilini) con relativa percentuale di imputazione delle spese.

Per la gestione locazioni passive d’altra parte il contratto di locazione, analogamente a quello attivo, può avere ad oggetto una o più unità immobiliare o una frazione di essa e può avere uno o più proprietari con relativa percentuale di imputazione delle competenze.

Le principali funzionalità riguardanti la gestione delle locazioni passive sono le seguenti:

• Gestione anagrafica locazioni

• Anagrafica proprietari

• Anagrafica contratti

• Anagrafica inquilini (per gestione subaffitti)

• Gestione contabile

• Gestione contratti

• Determinazione canoni

• Gestione emissione mandati di pagamento

• Gestione comunicazioni varie (tra cui comunicazione lavori)

• Voci o causali di accredito/addebito e storno

• Gestione anticipi spese

• Gestione depositi cauzionali e interessi sui depositi cauzionali (restituzione annuale o capitalizzazione per restituzione a fine locazione)

• Gestione registrazione contratti (Entratel)

• Gestione dei rinnovi e delle disdette

• Stampa elenco XXX xxxxxxx

• Lettera libera ai proprietari

• Stampa elenco variazioni ISTAT

• Stampa elenco contratti

• Stampa confronto lista pagamenti emessi

• Stampa elenco pagamenti

• Stampa elenco movimenti mensili

Nell’inventario della Regione Lazio, accanto al patrimonio immobiliare, rivestono fondamentale importanza i terreni demaniali.

Ogni terreno può essere accatastato o meno e può essere scomposto in una o più particelle. Ogni terreno, può essere oggetto di concessione che potrà avere ad oggetto uno o più terreni o una frazione dello stesso e uno o più concessionari con relativa percentuale di imputazione delle spese.

Ogni terreno può essere rappresentato mediante dati alfanumerici, dati di georiferimento sul territorio e dati e documenti descrittivi sia tecnici che amministrativi (documenti, immagini, disegni tecnici, ecc.); il sistema permette tramite l’utilizzo delle funzioni grafiche e grazie alla presenza dei diversi strati informativi una gestione più efficiente dei terreni, permettendo ad esempio il tracciamento delle aree, frazionamenti, accorpamenti e variazioni.

Le principali funzionalità riguardanti la gestione dei terreni sono le seguenti:

• Gestione anagrafica

• Gestione anagrafiche concessioni

• Gestione anagrafiche concessionari o utilizzatori

• Gestione contabile

• Gestione concessione

• Determinazione canoni concessori

• Gestione bollettazione (avviso di pagamento) e/o fatturazione

• Gestione comunicazioni

• Gestione interessi di mora

• Gestione preventivi di spesa

• Stabili gestiti dalla proprietà

• Stabili gestiti da amministratori esterni

• Gestione consuntivi di spesa

• Fasi di contabilizzazione

• Gestione fiscale

Report e caricamenti

Il sistema consente una vista aggregata dei dati contenuti nell'archivio permettendo agli utenti abilitati di avere una vista complessiva delle attività. In particolare è disponibile un sistema di reportistica che permette la produzione di report standard che le aree interessate devono emettere sia verso altre aree della Regione Lazio sia verso altre Amministrazioni.

Tra questi, a titolo semplificativo ma non esaustivo, vi sono:

• Rendiconto finanziario annuale

• Inventario annuale

• Riepilogo IMU

• Report per CONSIP

• Report per l’area Ragioneria ed Entrate

• Report Fondiario

5.3 Contesto tecnologico

Nel seguito viene riassunta l’architettura secondo una vista applicativa che evidenzia i singoli moduli funzionali del sistema SICER e i sistemi esterni che si interfacciano con il sistema SICER.

Sono previste interazioni con altri sistemi in uso alla Regione Lazio attraverso meccanismi volti alla condivisione dei servizi esposti attraverso soluzioni standardizzate e consolidate.

La figura che segue schematizza il nuovo sistema contabile della Regione Lazio indicando i moduli funzionali (in verde) che lo compongono e le interazioni tra questo e i sistemi esterni coinvolti.

Figura 13. Il nuovo sistema contabile della Regione Lazio ed i sistemi esterni

I moduli funzionali del nuovo sistema contabile della Regione Lazio sono raggruppati sotto più moduli applicativi. La tabella che segue elenca i moduli applicativi del sistema e i relativi moduli funzionali che vi fanno parte:

Modulo applicativo	Modulo funzionale
Modulo Sicer	Bilancio

Modulo applicativo	Modulo funzionale
	GSA
	Anagrafiche e parametri
	Adempimenti fiscali
	Ciclo passivo
	Ciclo attivo
	Gestione Cespiti e Mag.
Modulo Atti	Atti Amministrativi
Modulo Servizi di Atti	Cooperazione sistemi di pagamento e fatturazione
	Gestione Menù verso il Sicer
	Anagrafiche e parametri
Modulo Autenticazione	CAS
Modulo Controllo	Controllo di gestione
Modulo Controllo	Controllo strategico
Modulo BI	BI
Modulo Fatture	WF Fatture

La figura che segue rappresenta i moduli applicativi del nuovo sistema contabile della Regione Lazio e le interazioni che sussistono tra questi. I riquadri in verde costituiscono i moduli funzionali componenti i vari moduli applicativi.

Modulo Atti

Atti

Modulo Sicer

GSA

Modulo BI

amministrativi

Bilancio

Modulo Autenticazione

CAS

Modulo Controllo

Controllo di gestione

Controllo strategico

Anagrafiche e parametri

Adempimenti fiscali

Ciclo passivo

Ciclo attivo

Gestione Cespiti e Mag.

Modulo Fatture

WF Fatture

Figura 14. I moduli applicativi e funzionali che costituiscono il nuovo sistema contabile della Regione Lazio

Nel dettaglio il Modulo Atti è realizzato in due componenti applicative indipendenti in modo da garantire una migliore manutenibilità e scalabilità del prodotto complessivo. Il Modulo “Atti” è preposto alla gestione applicativa dell’iter vero e proprio, mentre il Modulo “Servizi di Atti” conterrà tutte le funzionalità necessarie alla gestione dei servizi accessori e trasversali alla completa gestione degli Atti.

Figura 15. I moduli applicativi e funzionali che costituiscono il modulo Atti

5.3.1 Interazione tra utenti e sistema

Al fine di garantire la raggiungibilità delle funzionalità esposte dal nuovo sistema contabile della Regione Lazio da parte dell’utenza distribuita sul territorio con postazioni aventi caratteristiche differenti tra di loro, è stata adottata una classica soluzione web based centralizzata per cui un utente che necessita di usufruire delle funzionalità esposte dal

sistema non deve installare nessun prodotto ad hoc, non deve avere macchine particolarmente prestanti e non deve avere particolari connessioni o effettuare complicate configurazioni.

Il sistema è accessibile tramite un browser web (tra quelli più diffusi: Chrome dalla versione: 50.0.2661 Internet Explorer dalla versione: 11, Firefox dalla versione: 58). Di fatto le applicazioni girano lato server e le eventuali funzionalità espletate lato client sono quelle tipiche in caso di fruizione di contenuti web e comprendono, ad esempio, l’esecuzione di codice Javascript.

Il browser web asserve alla presentazione del dato mentre lato server ci sono le funzionalità di elaborazione del dato, di interazione tra i differenti sistemi e di accesso ai repository dati.

5.3.2 Interazioni tra i differenti sistemi e moduli

Le classi di interazione individuate nella realizzazione del sistema tra moduli diversi seguono due filoni principali:

1. attraverso servizi: ovvero accesso a, o esposizione di, servizi di business che sono di dominio di uno specifico sistema o modulo (servizi RESTful / servizi SOAP);

2. attraverso rimando a pagine web di altro modulo/sistema; ovvero la fruizione delle funzionalità attraverso la GUI propria di uno specifico modulo o sistema terzo.

Nella Figura 15 è evidenziato inoltre il modulo wrapper “orchestratore”, attualmente in via di realizzazione, che prevede tre macrofunzionalità:

1. Predisposizione di scritture ed atti in funzione delle richieste SIGEM

2. Inoltro evidenze contabili relative ai progetti a SIGEM

3. Aggiornamento stato progetti SIGEM in funzione WF Atti

Il wrapper prevede la gestione delle comunicazioni tramite servizi fra:

• SIGEM per la ricezione dei dati del progetto e richieste di rilevazioni contabili

• SICER (modulo Atti Amministrativi) per la predisposizione automatica dell’atto amministrativo

• SICER (Bilancio) per l’inserimento automatico delle scritture contabili sulla base dei dati del progetto ottenuti da SIGEM

Figura 16– Wrapper di comunicazione

5.3.3 Vista logica

La figura che segue schematizza in breve gli elementi che afferiscono il nuovo sistema contabile della Regione Lazio.

È previsto un presentation tier in cui trova collocazione il reverse proxy che disaccoppia lo strato applicativo dai client che fruiscono del sistema.

Il logic tier è composto dai moduli applicativi che compongono il nuovo sistema contabile della Regione Lazio e forniscono le funzionalità che caratterizzano il sistema.

Il data tier si compone di quegli elementi che costituiscono i dati utilizzati dal sistema. Si articolano nei dati necessari all’autenticazione e profilazione di cui quota parte è collocata su LDAP e quota parte su RDBMS, e i dati necessari alle elaborazioni proprie del sistema disponibili su DB.

Logic tier

MODULO FATTURE

MODULO CONTROLLO

MODULO ATTI

MODULO SICER

MODULO AUTENTICAZIONE

Presentation tier

SERVER HTTP / REVERSE PROXY

Data tier

RDBMS

LDAP

Figura 17. Vista logica nuovo sistema contabile della Regione Lazio

Di seguito sono dettagliati i layer e le interazioni previste. Per ognuno dei livelli vengono evidenziati i nodi che vi afferiscono e le connessioni che devono essere garantite.

5.3.4 Presentation tier

Il livello di presentazione prevede almeno un server Apache http in configurazione reverse proxy/load balancer che funge come strato di disaccoppiamento tra il livello di presentazione e quello applicativo.

I server http, in questa configurazione, non generano di per sé dati. Il contenuto è ottenuto dai server di back end che non hanno una connessione diretta con la rete esterna. Quando un http server riceve una richiesta da un client, la richiesta è inoltrata ad uno di questi server che la elabora e ritorna al server http la risposta. Questi, poi, si occupa di restituirla al client.

L’utilizzo di questa configurazione consente di aumentare il grado di sicurezza, il grado di affidabilità e di bilanciamento del carico.

Al fine di garantire meccanismi di load balancing è previsto un reverse proxy http che fornisca i meccanismi di session affinity o persistence.

La figura che segue prospetta gli elementi che afferiscono il livello di presentazione:

Presentation tier

Logic tier

* HTTP(S)/AJP

Firewall

HTTP(S)/AJP

Http Server -* Reverse proxy

HTTP/HTTPS

Firewall

HTTP/HTTPS

Client

Internet / Intranet

5.3.5 Logic tier

La figura che segue schematizza gli elementi che compongono il livello applicazione

Presentation tier

Firewall

HTTPS

Logic tier

11111

HTTP/HTTPS

AJP

AJP AJP

AJP

SIGEM

Fondi

PAT-IMM

PCC

1 Sistemi esterni

Noi-PA

Modulo BI

Modulo controllo

LACRSIOPE+

HTTPS

Firma CoSign

SIOPE+

Sistema pagamenti

SDI

PAT-MOB

Modulo Autenticazione

Modulo Fatture

Modulo Atti

Modulo Sicer

PROSA

Portale OpenData

SIR-HR

BUR

BDA

Portale della trasparenz a

LDAP/LDAPS

TCP/IP

Data tier

Figura 18. Interazioni a livello di logic tier.

Il livello applicativo prevede una serie di nodi su cui trovano allocazione le componenti applicative del nuovo sistema contabile della Regione Lazio. Il livello contempla i seguenti nodi:

• Modulo Sicer;

• Modulo Controllo;

• Modulo Fatture;

• Modulo BI;

• Modulo Autenticazione;

• Modulo Atti;

La rappresentazione riportata in figura è di tipo concettuale. Ognuno dei nodi identifica un modulo applicativo del nuovo sistema contabile della Regione Lazio. I restanti nodi riportati in figura identificano i sistemi esterni con cui il nuovo sistema contabile della Regione Lazio interagisce.

5.3.6 Organizzazione concettuale modulo autenticazione

Il Modulo Autenticazione è costituito da un server CAS. Il server CAS è di base un servlet Java costruito su Spring Framework la cui responsabilità principale è di autenticare gli utenti e concedere l'accesso ai servizi abilitati al CAS, comunemente chiamati client CAS, mediante l'emissione e la convalida dei ticket. Una sessione SSO viene creata quando il server emette un ticket “ticket-granting ticket” (TGT) per l'utente dopo il login riuscito. Un ticket “service ticket” (ST) viene emesso per un servizio su richiesta dell'utente tramite reindirizzamenti del browser utilizzando il TGT come token. Il ST viene successivamente convalidato sul server CAS tramite comunicazione back-channel.

Il CAS utilizza molti aspetti del Framework di Spring, in particolare: Spring MVC e Spring Webflow. Spring fornisce un framework completo ed estensibile per il core del CAS.

Il CAS server è assimilabile ad una applicazione web Java pacchettizzata in un file “war” da rilasciare su un servlet container quale Tomcat.

Viene inoltre utilizzato il modulo di autenticazione LDAP (MS Active Directory) per garantire la verifica delle credenziali a fronte di un servizio di Directory aziendale preesistente.

La figura che segue schematizza l’architettura del CAS.

CAS Client

Java CAS Client

Java Web App

CAS Protocol

Modulo Autenticazione (CAS Server)

LDAP

Authentication Handler

Authentication

Ticketing

Spring MVC/Webflow

LDAPS

LDAP Server

Figura 19. Architettura modulo Autenticazione

5.3.7 Organizzazione concettuale Modulo Atti

L’architettura applicativa del modulo Atti e del Modulo dei Servizi di Atti è stata realizzata secondo l’approccio a tre livelli (3-tier) e fondata sulle seguenti tecnologie:

• JEE – HTML – JS – AJAX su Glassfish 3.1.2.2 per la gestione del presentation layer e della logica di interazione con l’utente al livello applicativo;

• EJB – Eclipselink e JDBC con SQL per la gestione della logica di business del livello applicativo e per l’interazione con il livello dati;

• Oracle 11g Enterprise Edition che gestisce il livello dati La figura seguente mostra l’architettura prevista per il sistema.

E di seguito viene evidenziato uno schema più dettagliato dei vari componenti

5.3.8 Data Tier

Il data tier è quello strato dell’architettura che raccoglie i repository su cui sono ospitati le differenti tipologie di dati che sono utilizzate nell’ambito del nuovo sistema contabile della Regione Lazio.

In particolare il data tier è caratterizzato da due categorie di nodi:

• LDAP, che conserva i dati necessari per l’autenticazione delle utenze che accedono al sistema;

• Oracle RDBMS, che conserva i dati di profilazione e tutti i dati di carattere funzionale e non che sono necessari al corretto funzionamento dei moduli applicativi. La versione prevista è la 11g.

La figura evidenzia, oltre i suddetti nodi, anche le relazioni che ci sono tra questi e i moduli che ricadono nel logic tier.

Logic tier

Modulo BI

Modulo controllo

Sistemi esterni

Modulo Autenticazione

Modulo Fatture

Modulo Atti

Modulo Sicer

LACRSIOPE+

L1DAP/LDAPS

TCP/IP

Data tier

TCP/IP

LDAP

Oracle RDBMS

Figura 20. Interazioni verso il data tier.

5.4 Contesto tecnologico – PATIMM

Il Sistema attualmente in esercizio è composto da:

• una componente di database, basata su Oracle 11g con estensione Locator, atta a descrivere il modello rappresentativo storicizzato degli elementi gestiti dal Progetto, costituita di tabelle, viste, relazioni e procedure (compresa la parte relativa alle rappresentazioni geografiche degli oggetti);

• uno strato logico di base (“business logic”), interamente scritto in Java (che include le componenti servlet di DbMAP ASJ per l’accesso ai dati spaziali e cartografici raster) eseguibile in un container J2EE compatibile quale JBoss su sistema operativo Windows;

• uno strato applicativo JSP e applets java CAD/GIS (DbMAP) di gestione dell’interfaccia utente, utilizzabili con qualunque browser internet;

• una componente Client, che accede via http alla base dati del Progetto, preposta all’editing GIS guidato e controllato ed utile per lavorazioni massive in back office;

• componenti di pubblicazione standard WMS per l’erogazione dei progetti cartografici GIS secondo tale protocollo (WMS).

• componenti Client, che accedono tramite ODBC alla base dati del Progetto, per la gestione massiva delle operazioni relative alla “bollettazione” degli affitti attivi e delle concessioni, all’emissione dei mandati di pagamento degli affitti passivi e alla gestione delle alienazioni.

Di seguito una schematizzazione architetturale della soluzione in essere:

Il software attualmente in produzione, che risponde all’architettura descritta, si basa su una serie di componenti tra loro interconnesse con tecnologie varie: open source e proprietarie.

6 Descrizione dell’Appalto

Fermo restando quanto previsto in altri capitoli del presente documento, l’Appaltatore DEVE, prestare i necessari servizi professionali per:

• garantire la completa presa in carico dei sistemi informativi rientranti nel presente appalto (SICER – PATIMM e MIR), i cui codici sorgenti saranno forniti all’Appaltatore dalla Società Appaltante corredati dalla relativa documentazione tecnica;

• realizzare il nuovo sistema per la gestione del patrimonio mobiliare PATMOB;

• realizzare gli interventi evolutivi sul sistema SICER da implementare in modalità a corpo e descritti nei paragrafi successivi;

• prendere in carico, evolvere e manutenere SICER- MIR-PATIMM; sviluppare, evolvere e manutenere PATMOB al fine di adeguarli tempestivamente, in base alle specifiche esigenze espresse dall’Amministrazione regionale, alle normative regionali, nazionali e comunitarie di interesse. Al riguardo, l’Appaltatore DEVE inoltre effettuare un’attività di monitoraggio di tutta la normativa relativa alle materie di pertinenza dei sistemi in analisi, indicando alla Società Appaltante le eventuali nuove regole che fossero introdotte e quindi, su indicazione della Società stessa, procedere al relativo adeguamento del software;

• prestare i servizi di manutenzione evolutiva attingendo ad un plafond definito al successivo art. 0 di giornate/uomo;

• prestare i servizi di Manutenzione Correttiva e Adeguativa;

• prestare i servizi di assistenza e supporto specialistico da erogare in modalità onsite e da remoto; tale attività di assistenza comprende tutte le attività a supporto dell’operatività dell’utente in termini di analisi dei dati, produzione della reportistica, sistemi di connessione/trasmissione dei flussi dati, problem solving;

• garantire tutte le attività di adeguamento del software preso in carico rispetto agli standard interni di sicurezza della Società Appaltante. Si precisa che la piattaforma infrastrutturale di base, intesa come apparecchiature e software di base, è messa a disposizione dalla Società Appaltante;

• progettare ed erogare sessioni formative finalizzate all’addestramento al corretto utilizzo dei sistemi da parte di tutti i profili utente previsti.

Tutti i servizi sopra elencati DEVONO essere erogati secondo le modalità definite nel seguito del presente Capitolato.

6.1 Vincoli

Fermo restando quanto richiesto in altre parti del presente Capitolato, l’Appaltatore DEVE implementare le nuove funzionalità, oggetto del presente appalto, utilizzando un’architettura a tre Layers: Presentation, Application Logic e Database, implementando un sistema di tipo WEB.

In considerazione dell’elevato livello d’interoperabilità con sistemi, l’Appaltatore DEVE realizzare le funzionalità di integrazione richieste utilizzando un’architettura basata sia sull’implementazione di un’architettura a servizi, sia basata sull’implementazione di un’architettura ad eventi (SOA/EDA).

Tutti i software che costituiscono e generano i moduli funzionali del Sistema ivi inclusi quelli risultanti dalle attività di MEV, DEVONO essere consegnati alla Società Appaltante unitamente ai relativi codici sorgente ed alla relativa documentazione tecnica di supporto, secondo le indicazioni del Direttore dell’esecuzione nominato dalla Società stessa. L’Appaltatore DEVE inoltre garantire che il sistema risulti pienamente compatibile con l’infrastruttura fornita dalla Società Appaltante sulla quale i sistemi sono ospitati ed in particolare, con i seguenti requisiti tecnici:

• Sistema installabile su macchine virtuali;

• Sistema operativo: Red Hat 6.5 o successive; windows 2016

• Application Server: Tomcat 7.x o successive e GlassFish 3.1.2.2 o successive

• Software di base: Versione Jdk 1.7 e Java 1.7 o successive; Office 2016

• DBMS: Oracle 11 o superiori;

• Suite di BI: SpagoBI-Server 4.2

Si precisa che la versione del prodotto, dove specificata, è da considerarsi indicativa. La Società Appaltante, a suo insindacabile giudizio e senza alcun onere aggiuntivo a carico della Società stessa rispetto al corrispettivo di cui oltre, si riserva infatti la facoltà di variare, nel corso dell’esecuzione dell’appalto, la versione del prodotto (sia major, che minor release).

La Società Appaltante metterà a disposizione dell’Appaltatore nr. 3 (tre) ambienti:

1. un ambiente di collaudo, in cui è installata una versione software del Sistema in fase di test;

2. un ambiente di preproduzione, in cui è installata la versione software copia dell’ambiente di produzione;

3. un ambiente di produzione, è l’ambiente utilizzato dagli utenti del sistema (giunta regionale, parchi e consiglio regionale) in cui è installata la versione software che gli utenti dovranno utilizzare.

Si specifica che tutti i software che costituiscono e generano i moduli funzionali del Sistema ivi inclusi quelli risultanti dalle attività di MEV devono essere installati e periodicamente aggiornati dall’Appaltatore sui tre ambienti messi a disposizione dalla Società Appaltante.

L’Appaltatore DEVE assicurare l’aderenza della soluzione proposta ai vincoli tecnologici indicati nel presente paragrafo e, qualora scelga di utilizzare versioni ENTERPRISE di prodotti OpenSource, l’Appaltatore DEVE garantire le medesime funzionalità anche in modalità degradata con le versioni Community.

L’Appaltatore DEVE realizzare una soluzione in alta affidabilità prevedendo la possibilità di ridondare i diversi layer in configurazioni cluster per assicurare la continuità del servizio anche a fronte del possibile malfunzionamento di un nodo. Il Sistema DEVE essere completamente virtualizzabile, eventualmente ad esclusione della componente di Database, per potersi calare sull’infrastruttura di Business Continuity messa a disposizione dalla Società Appaltante. Detta infrastruttura, che non rientra nell’oggetto del presente appalto, si basa sulla seguente architettura generale schematizzata in figura.

CED Primario

CED Secondario

Fruitori dei servizi in continuità operativa

network

ced2ced backbone

Primary servers

systems

Recovery servers

sync/async

data

Primary SAN

Recovery SAN

Primary Backup

Remote Backup

Figura 21 – Diagramma logico della soluzione di Business continuity

Relativamente alla replicazione dei servizi del Database si assicura al minimo la configurazione di due nodi sui due siti in configurazione Active/Passive.

Il Sistema DEVE inoltre risultare scalabile, sia in termini verticali che orizzontali:

• la scalabilità verticale è intesa come la capacità del sistema di ‘rispondere’ positivamente all’incremento della potenza elaborativa di un singolo sistema hardware;

• la scalabilità orizzontale è intesa come la capacità del sistema di ‘rispondere’ positivamente all’incremento del numero dei sistemi hardware su cui è installato.

Per l’implementazione dei web service, l’Appaltatore DEVE tener conto delle specifiche definite dalla Web Services Interoperability Organization (WS-I). In particolare, l’Appaltatore DEVE rispettare i seguenti standard:

• WSDL 1.1 o 2.0 per la descrizione delle interfacce;

• XSD per la descrizione dei tipi dati codificati in XML;

• XSL per il mapping dei messaggi;

• SOAP 1.1 protocollo di comunicazione per l’invocazione delle interfacce, REST;

• WS-Security 1.1 per la gestione della sicurezza.

Si precisa che per l’implementazione dei web service, saranno rispettate le specifiche definite dalle Linee Guida Modello Interoperabilità promosso da AgID. In particolare, dovranno essere rispettati i seguenti standard:

• API RESTful - Resource Oriented Architecture

• JSON - strutture dati e messaggi;

• OpenAPI - per la descrizione, produzione e consumnig delle interfacce

• OAuth/OpenID - gestione della sicurezza.

Resta inteso che l’Appaltatore, in caso di variazione dei predetti standard nel corso di esecuzione del contratto DEVE adeguare il Sistema fino a quel momento rilasciato e rispettare i nuovi standard, senza oneri aggiuntivi rispetto ai corrispettivi di cui oltre.

Tutte le chiamate devono essere inoltrate esclusivamente attraverso l’API Gateway messo a disposizione dalla Società Appaltante secondo la procedura di “Linee guida di sviluppo sicuro” che verrà messa a disposizione dalla Società Appaltante. L’API Gateway:

• è il responsabile dell'autenticazione e dell'autorizzazione delle richieste API effettuate da chiamanti esterni.

• esegue il routing delle richieste API che provengono da client esterni ai rispettivi microservizi, fungendo come un punto di ingresso per tutti i relativi microservizi.

L’Appaltatore DEVE inoltre consegnare il software realizzato sia in forma di codice binario sia in forma di codice sorgente, fornendo anche il dettaglio delle varie modifiche effettuate tramite l’adozione di software di controllo di versione la cui replica potrà essere richiesta in qualsiasi momento dalla Società Appaltante, garantendo altresì, la possibilità per la Società Appaltante di compilare e ottenere il medesimo codice binario con strumenti di build automatici sui propri sistemi.

L’Appaltatore DEVE unitamente alle nuove funzionalità e al software rilasciato, fornire una suite di test funzionali automatici (Unit Test) per esercitare le funzionalità richieste, consentirne la verifica funzionale ed escludere l’introduzione di nuovi bug. L’Appaltatore DEVE inoltre introdurre nuovi e specifici test qualora questi non siano ritenuti sufficienti dalla Società Appaltante.

6.2 Framework per il ciclo di sviluppo sicuro del software

L’approccio metodologico allo sviluppo sicuro definisce, per ogni fase del ciclo di vita dello sviluppo software, gli interventi di sicurezza specifici che se integrati nel tradizionale SDLC (System Development Life Cycle) consentono di ottenere un Secure-SDLC.

L’Appaltatore DEVE integrare efficacemente la sicurezza in ogni fase del ciclo di vita dell’applicazione software sviluppata con la finalità di avere un software più sicuro, identificando e risolvendo le vulnerabilità in anticipo.

Le fasi del ciclo di vita del software in cui l’Appaltatore DEVE applicare la metodologia di sviluppo sicuro sono:

1. Risk assessment

Il Risk Assessment è uno strumento di analisi, semplice e accurato, che studia i rischi dell’organizzazione (operativi, strategici, finanziari ed esterni) al fine d’individuare successivamente le soluzioni e le misure più adeguate.

Strumento

Descrizione

Cyber Risk Management

xxx.xxxxxxxxxxx.xxx.xx

Cyber Risk Management di AgID è lo strumento nazionale per la valutazione e il trattamento del rischio cyber. Per la protezione dei dati in formato digitale, a garanzia della loro riservatezza, integrità e disponibilità, il tool AgID di Cyber Risk Management identifica le situazioni e i vari ambiti nei quali le informazioni possono venirsi a trovare, consentendo di valutare i rischi per la loro sicurezza.

Il tool AGID è gratuito ed a completa disposizione di tutte le Pubbliche Amministrazioni.

Tabella 1 - Risk Assessment: strumenti a supporto

2. Requirements

In un Secure-SDLC i requisiti di sicurezza devono essere sviluppati accanto ai requisiti funzionali. Questo principio, noto come “Security by Design and by Default” dispone che qualsiasi sistema informatico debba prevedere la valutazione del rischio fin dalle prime fasi della sua realizzazione.

Fase di analisi dei requisiti

Descrizione

Identificazione di requisiti di sicurezza appropriati per il contesto specifico del software ‘sicuro’ da sviluppare. Focus:

• Requisiti per la protezione dei servizi e dei dati ‘core’ dell’applicazione;

• Requisiti per la compliance normativa;

• Nel caso di sviluppo in outsourcing, requisiti da indirizzare ai fornitori che partecipano al contesto di sviluppo dell’applicazione.

Input

Documentazione, e tutte le informazioni utili, del contesto progettuale per il quale vanno identificati i requisiti di sicurezza (esigenze e obiettivi, policy e normative, scenari di rischio, standard e best practices).

Output

Profilo di rischio dell’applicazione.

Requisiti di sicurezza e privacy categorizzati e prioritizzati.

Eventuale nota tecnica con il disegno generale del sistema in cui vengono evidenziati gli elementi di criticità.

Tabella 2 - Fase di “Analisi Requisiti”

3. Design

Nel rispetto delle linee guida ed istruzioni operative adottate nei sistemi di gestione aziendale e per la componente applicativa rilasciate dall’Appaltatore, obiettivo di questa fase è la definizione di un’architettura sicura:

• L’architettura del software recepisce i requisiti di sicurezza definiti nella fase precedente.

• Vengono definiti i punti d’ingresso/uscita e la logica di business nelle interazioni con i diversi strati del software.

FASE DI PROGETTAZIONE E DISEGNO

Descrizione

In questa fase si esamina il sistema in divenire con l’ausilio di tecniche di analisi e modellazione delle minacce, producendo requisiti di sicurezza di dettaglio che si aggiungono a quelli prodotti nella fase precedente.

Input

Principi e Best Practices di Security Design. Techiche e modelli di Threat Modeling.

Requisiti funzionali ed eventuali requisiti di sicurezza preesistenti per la realizzazione del software. Architettura o HLD se disponibili.

Output

Documento di modellazione delle potenziali minacce a cui è esposta l’applicazione.

Requisiti di sicurezza da implementare per mitigare i rischi legati alle minacce individuate e per indirizzare le contromisure.

(*) L’output di questa fase deve essere validato da una struttura preposta, al fine di validare la corretta interpretazione e applicazione della normativa vigente e delle policy interne.

Tabella 3 - Fase di “Progettazione e disegno”

4. Implementazione

L’Appaltatore tramite l’applicativo SONARQUBE (xxxxx://xxx.xxxxxxxxx.xxx/) messo a disposizione dalla Società Appaltante DEVE evidenziare le problematiche legate alla qualità del codice di differenti linguaggi di programmazione.

L’applicativo prevede una rappresentazione grafica delle vulnerabilità e soprattutto la grande flessibilità, dovuta alla presenza sulla rete di numerosi plugin, che ne estendono le capacità.

La Società Appaltante metterà a disposizione dell’Appaltatore una soluzione automatizzata completa per la gestione completa del codice sorgente, inclusa la verifica, validazione ed il deploy che prevede l’impiego del prodotto SonarQube conformemente a quanto già previsto dalla IST.01.01 – Verifica e validazione dei codici sorgenti delle applicazioni (Istruzione operativa che verrà messa a disposizione dell’Appaltatore).

5. Testing

Obiettivo: verifica e validazione dei requisiti e delle condizioni identificate durante la fase di progettazione.

FASE DI “TEST APPLICATIVO DINAMICO E DI PENETRAZIONE”

Descrizione

Analisi della web application, previo attacco controllato, per verificare le vulnerabilità esposte mentre è in esecuzione su web server.

Input

URL della web application da analizzare e credenziali per l’accesso

Output

Report del tool automatico.

Report analitico di ciascuna segnalazione rilevata, accompagnata dalla relativa remediation.

Report di verifica della effettiva implementazione delle bonifiche al codice.

Tabella 4 - Fase di “Test Applicativo Dinamico e di Penetrazione”

6. Deploy

L’attività è finalizzata a rendere operative le soluzioni predisposte negli step precedenti attraverso: start-up infrastruttura tecnologica, installazione e avviamento della soluzione applicativa.

FASE DI “PRODUZIONE E POST-PRODUZIONE”
Descrizione	Monitoraggio dell’applicazione in esercizio ed eventuale manutenzione evolutiva per migliorare gli aspetti di sicurezza.
Input	Log applicativi e di sistema codice sorgente e binario
Output	Report statistici che rilevano l’operatività dell’applicazione Report di analisi statica e dinamica dell’applicazione

Tabella 5 - Fase di “Produzione e Post-Produzione”

6.3 Sviluppo e MEV di software ad hoc

L’Appaltatore DEVE, a seguito della presa in carico di SICER, MIR, PATIMM personalizzare gli stessi realizzando i seguenti interventi a corpo, oltre che realizzare il nuovo sistema per la gestione del patrimonio mobiliare PATMOB:

• dashboard per i centri di spesa (SICER);

• revisione moduli di controllo di gestione e controllo strategico su SICER.

• evoluzione del sistema PATIMM

6.3.1 Dashboard per i centri di spesa (SICER)

L’Appaltatore DEVE personalizzare il sistema SICER in modo da introdurre una dashboard direzionale a disposizione dei dirigenti/direttori e Responsabili del Procedimento in cui siano evidenti le attività pending che necessitano di un’azione/lavorazione. A titolo esemplificativo ma non esaustivo la dashboard può contenere:

• Fatture passive con numerosità, stato e azione necessaria (passaggio di stato, cambio struttura, arricchimento dati come CIG, CUP, etc)

• Fatture attive con numerosità, stato e azione necessaria (da firmare, da verificare)

• Atti con lo stato e azione necessaria e assegnatario

• Provvedimenti di liquidazione

• Mandati di pagamento

Tramite un collegamento rapido, l’Appaltatore DEVE sviluppare il sistema SICER in modo da permettere la navigazione da singolo elemento della dashboard (per esempio: Fatture passive) alla funzionalità SICER che ne permette la lavorazione, in modo da velocizzare la lavorazione e avere in un unico cruscotto le attività in carico che devono essere lavorate.

Inoltre a partire da tale dashboard gli utenti DEVONO avere accesso anche ai servizi di firma digitale, consentendo in modo rapido ed intuitivo la presa in carico di un documento assegnato e l’avanzamento dello stesso secondo il workflow implementato a sistema.

La dashboard DEVE permettere di ottenere una visione chiara ed immediata dei dati in carico ad un utente o Area/Direzione e attraverso l’integrazione del sistema SICER con la propria piattaforma di reportistica e/o con sorgenti dati esterne sarà possibile estrarre report riassuntivi con anche l’inserimento di misurazioni tramite KPI. L’analisi dei dati contenuti nella dashboard DEVE permettere all’amministrazione di comprendere i propri dati per migliorare i processi decisionali e produttivi permettendo un monitoraggio puntuale dei carichi di lavoro dell’amministrazione.

A partire dalla dashboard, ciascun dirigente di un centro di spesa DEVE monitorare i capitoli assegnati alla propria struttura per verificare l’avanzamento della spesa, gli atti perfezionati ed in itinere che insistono sui propri capitoli, i residui etc.

La dashboard permette di ottenere i seguenti vantaggi competitivi:

• comprendere i propri dati e monitorare in modo puntuale i processi amministrativi

• ottimizzare le decisioni strategiche, e attività di controllo ed i processi

• analizzare le performance amministrative

6.3.2 Manutenzione ed evoluzione del sistema per la gestione del patrimonio immobiliare (PATIMM)

L’Appaltatore DEVE prestare i servizi per la manutenzione e l’evoluzione del sistema PATIMM sia in ambito di gestione del patrimonio immobiliare che del demanio.

Nei paragrafi successivi si riporta una descrizione sintetica delle funzionalità necessarie del sistema sulla base delle esigenze espresse dall’Amministrazione Regionale, sia quelle in essere che quelle da evolvere e sviluppare ex novo.

Si specifica che tutti gli interventi evolutivi realizzati nell’ambito del presente intervento DEVONO:

• soddisfare pienamente tutti i requisiti dettati dalla normativa vigente;

• essere scalabili e modulari, per potere pienamente supportare future esigenze di evoluzione dei processi di gestione del patrimonio dell’ente;

• includere meccanismi che assicurino elevata sicurezza e disponibilità dei dati, nonché essere totalmente compliant con la normativa di riferimento in materia di privacy e accessibilità.

6.3.2.1 Sviluppi a corpo – sistema PATIMM

Con l’obiettivo di rendere l’utilizzo del sistema quanto più funzionale alle esigenze operative degli utenti nell’espletamento delle attività amministrative di competenza l’Appaltatore DEVE effettuare alcune evoluzioni dell’attuale sistema, da erogarsi in modalità a corpo.

Di seguito si indicano gli sviluppi che l’Appaltatore DEVE effettuare a partire dal sistema preso in carico

Integrazione catasto on line

Nel sistema attuale la gestione dei dati catastali avviene in maniera manuale; in esecuzione del presente appalto, l’Appaltatore DEVE realizzare un aggiornamento automatico di tali dati dalla fonte ufficiale.

In particolare, l’Appaltatore DEVE realizzare una funzionalità che permetta di aggiornare in automatico i dati catastali presenti a sistema con i dati che saranno scaricati dal MEF (ex AdE) in caso di frazionamenti, accorpamenti, rimunerazioni, cambio di rendita, nuove acquisizioni. Successivamente DEVE essere possibile esportare e verificare tutte le variazioni avvenute in modo che l’utente possa confermare o meno quanto riportato.

Reportistica avanzata

Allo scopo di agevolare l’operatività degli utenti del sistema l’Appaltatore DEVE estendere la reportistica attualmente disponile. È infatti necessario che gli utenti siano in grado di produrre i report necessari sia per la gestione ordinaria del patrimonio e demanio, sia per rispondere agli adempimenti verso le altre amministrazioni.

A titolo esemplificativo uno dei report che l’Appaltatore DEVE implementare è il report Banca della Terra, ovvero un report che estragga le informazioni necessarie da inviare alla ISMEA.

Realizzazione integrazione con i sistemi interni di Regione Lazio

L’Appaltatore DEVE evolvere il sistema PATIMM realizzando le necessarie integrazioni con i sistemi informativi di Regione Lazio ed in particolare:

- XXX.XX: sistema informativo per la gestione Protocollo e Atti amministrativi

- SICER: sistema informativo contabile

- BILTCO: sistema informativo dei tributi

- PORTALE DEL CONTRIBUENTE

- PAGAONLINE

- OPEN DATA

- PORTALE TRASPARENZA

Nel seguito del paragrafo vengono brevemente descritti i succitati sistemi e le modalità di integrazione che l’Appaltatore DEVE realizzare.

SISTEMA XXX.XX:

Il sistema costituisce la piattaforma tecnologica regionale per la semplificazione amministrativa e il protocollo informatico. L’Appaltatore DEVE prevedere nella gestione della documentazione l’integrazione con XXX.XX per la sola protocollazione centralizzata dei documenti. La protocollazione dei documenti DEVE essere realizzata sia per i documenti in entrata al sistema (ad esempio comunicazioni dei locatori passivi) che per i documenti in uscita prodotti dal sistema (ad esempio avvisi di pagamento, lettere agli inquilini, etc).

Tale integrazione DEVE prevedere l’acquisizione del numero di protocollo dal sistema Prosa; inoltre per i documenti protocollati per i quali è previsto, nell’ambito del presente appalto DEVE essere implementato il servizio di integrazione con la piattaforma PARER resa disponibile dalla regione Xxxxxx Xxxxxxx con la quale Regione Lazio ha stipulato un accordo di servizio.

SISTEMA SICER:

Nell’ambito del presente appalto è a carico dell’Appaltatore l’evoluzione dei sistemi SICER e PATIMM finalizzata al miglioramento dell’integrazione tra il sistema esterno PATIMM ed il SICER.

La modalità di integrazione tra PATIMM e SICER DEVE essere automatizzata tramite web services riguardo le conciliazioni inerenti i beni immobili (aspetto gestionale / aspetto contabile).

L‘owner della gestione dei beni immobili continuerà ad essere PATIMM, il quale comunicherà al SICER le variazioni di patrimonio immobiliare, che in dettaglio sono:

1. Cambio Categoria merceologica

2. Dismissioni

3. Manutenzioni Straordinarie

4. Valorizzazioni

Di seguito vengono riportate le evoluzioni dell’integrazione PAT – IMM SICER per singola variazione patrimoniale:

1. Cambio Categoria merceologica

La variazione di categoria merceologica relativamente ad una scheda cespite verrà effettuata in PATIMM. Tale sistema esterno, DEVE rendere disponibile a SICER, tipicamente prima delle scritture di rettifica economico patrimoniale di fine esercizio, le schede cespite.

La funzionalità di acquisizione DEVE quindi:

1. Inserire eventuali cespiti non presenti;

2. Per i cespiti presenti:

a. Memorizzare la categoria degli stessi relativamente all’annualità oggetto di elaborazione;

b. Aggiornare la data di vendita eventuale, relativamente a quelle registrate in PATIMM

Dopo l’acquisizione, il SICER DEVE evidenziare l’elenco dei cespiti per i quali la categoria merceologica dell’anno n, oggetto di acquisizione differisce da quella relativa all’anno n-1 e, per ciascuno, evidenziare il conto di immobilizzazione, fondo e quota. Tale estrazione sarà utilizzata da Regione Lazio per eventuali rettifiche da inserire manualmente a sistema.

A fronte della categoria DEVE essere determinata la quota da ammortizzare dell’anno, partendo dal valore contabile del bene.

2. Dismissioni

La gestione dei documenti attivi, qualora movimenti un conto di immobilizzazione, non andrà a gestire né il calcolo dell’eventuale minus / plusvalenza e né il collegamento del documento attivo con la scheda cespite oggetto di vendita.

A livello di matrice di correlazione, nel caso di alienazioni / dismissioni verrà utilizzato un unico conto “transitorio” di contabilizzazione a partire dal quale, prima delle scritture di rettifica, verranno individuate tutte le eventuali movimentazioni contabili che necessitano di opportuna definizione. Tali rettifiche verranno eseguite manualmente da Regione Lazio.

3. Manutenzioni straordinarie

Le manutenzioni straordinarie determinano la rimodulazione del piano di ammortamento relativo al cespite a cui si riferiscono. Le manutenzioni straordinarie a cui sono soggetti, sono un numero molto esiguo, tramite l’integrazione con PAT- IMM potrà essere effettuato l’aggiornamento automatico del valore contabile del bene ed il ricalcolo dell’ammortamento.

Infatti, poiché XXX XXX comunica l’importo delle manutenzioni straordinarie, in sede di acquisizione e determinazione dell’ammortamento dell’anno, SICER acquisisce già il valore contabile aggiornato e automaticamente è pertanto in grado di generare l’ammortamento dell’annualità corretto.

4. Valorizzazioni

Trattasi della casistica di variazione patrimoniale riconducibile alla valorizzazione di un cespite, che precedentemente aveva valore contabile 0, a seguito di una perizia.

Tali casistiche possono essere intercettate da PATIMM e quindi, in sede di acquisizione, vengono elaborate opportunamente tramite la registrazione plus valenza.

SISTEMA BILTCO:

Il sistema BILTCO permette la gestione informativa dei tributi della Regione Lazio, compresa la gestione degli atti di accertamento e iscrizione a ruolo del debito. In questo ambito il sistema PATIMM DEVE interfacciarsi con BILTCO in modo che quest’ultimo provveda alla generazione e all’eventuale trasmissione via pec degli atti, e successivamente alla generazione dei ruoli verso Agenzia delle Entrate Riscossione.

PORTALE DEL CONTRIBUENTE:

Il portale del contribuente è un portale realizzato come estensione del sistema informativo BILTCO per la gestione dei tributi e permette al contribuente la consultazione del proprio fascicolo tributario.

L’autenticazione dell’utente viene gestita tramite due modalità:

• autenticazione tramite SPID;

• autenticazione tramite credenziali fornite a seguito di una registrazione al portale da parte dello stesso utente e successiva istruttoria interna all’amministrazione.

L’Appaltatore DEVE realizzare un’integrazione affinché i locatari di immobili di proprietà della Regione Lazio possano accedere al portale e verificare la propria posizione. In particolare il locatario potrà verificare i dati del suo contratto di locazione, ivi compresi i versamenti effettuati e provvedere al pagamento degli importi dovuti attraverso Piattaforma di Pagamenti pagoPA.

PAGAONLINE:

Il sistema PATIMM dovrà inoltre integrarsi con la piattaforma di monetazione elettronica della Regione Lazio, ovvero con il portale dei pagamenti pagaOnline. pagaOnline è un’infrastruttura di pagamento della Regione Lazio, integrata con il Sistema dei pagamenti pagoPA dell’Agenzia per l’Italia Digitale (AgID), che consente ai diversi soggetti interessati di effettuare pagamenti elettronici verso la Pubblica Amministrazione, relativi a servizi erogati direttamente dalla Regione Lazio o da sue Società/Enti controllate/partecipate, o relativi a servizi erogati da altre Pubbliche Amministrazioni che scelgono di avvalersi della Regione Lazio come intermediario tecnologico verso il Sistema pagoPA (complessivamente detti Enti creditori). pagaOnline consente di eseguire pagamenti in modalità standardizzata per mezzo dei servizi offerti dai Prestatori di Servizi di Pagamento (PSP) aderenti al Sistema pagoPA.

L’integrazione DEVE avvenire tramite i Web Services esposti dalla piattaforma di monetazione elettronica, le cui specifiche verranno fornite all’avvio del progetto.

OPEN DATA:

Nell’ambito del presente appalto DEVONO essere realizzate le necessarie interfacce ed i meccanismi di alimentazione tra il sistema di gestione del patrimonio ed il sistema “OpenData” della Regione Lazio.

Le principali attività da svolgere riguardano:

• supporto alla identificazione del dominio di informazioni, proprio del Sistema, pubblicabili come dati aperti, anche con riferimento alla normativa in materia di privacy e riservatezza delle informazioni;

• supporto alla identificazione delle possibili tassonomie adottabili per la realizzazione dei lod (linked open data);

• analisi ed implementazione delle interfacce del Sistema per alimentare il sistema xxxx.xxxxx.xx, prevedendo la definizione di ‘Viste’ accessibili dal componente ETL (Kettle) del sistema “OpenData” della Regione Lazio;

• Supporto per l’automazione delle estrazioni periodiche da tali viste.

PORTALE TRASPARENZA:

Con il Decreto legislativo n. 33 del 14 marzo 2013, tutte le pubbliche amministrazioni devono rendere ancora più trasparente la loro attività. In questo ambito la Regione Lazio deve dare tempestiva comunicazione su alcune specifiche attività, di cui alcune riguardanti il patrimonio immobiliare e demanio. DEVE quindi essere realizzata, nell’ambito del presente appalto, un’interfaccia che permetta l’integrazione con il portale della Regione Lazio in modo da garantire gli adempimenti e fornire i dati necessari.

In particolare DEVONO essere trasmessi i dati riguardanti l’inventario annuale, i canoni di locazione e i canoni percepiti annuali. Le specifiche di interfacciamento verranno rilasciate in fase di avvio del progetto.

6.3.3 Realizzazione del nuovo sistema per la gestione del patrimonio mobiliare (PATMOB)

La gestione dell’inventario è un’operazione fondamentale e necessaria per qualsiasi Amministrazione pubblica; l’inventario dei beni mobili in particolare rappresenta un documento contabile di fondamentale importanza poiché consente di conoscere l’esatto ammontare del patrimonio per quantità, qualità e valore.

Il sistema da realizzarsi nell’ambito del presente appalto è rivolto all’area “Esecuzione contratti, Servizi e Forniture” e DEVE permettere la gestione del Patrimonio Mobiliare, nonché la gestione della logistica dei dipendenti regionali e la gestione del magazzino relativo al materiale di consumo.

È necessario infatti consentire la gestione dell’inventario per tutte le sedi regionali e tutte le stanze all’interno di esse, con la catalogazione dei beni (categoria inventariale, valore di acquisto, valore ammortizzato, fotografia) contenuti in ciascuna stanza. La localizzazione dei dipendenti all’interno delle sedi regionali acquista maggiore valore nella misura in cui il dipendente sia inserito all’interno di una stanza censita mediante un identificativo univoco all’interno della sede regionale, alla quale siano associati tutti i beni censiti in fase di rilevazione inventariale nella stanza in oggetto. D’altra parte la gestione del materiale di consumo può essere ricondotta alla gestione del Patrimonio Mobiliare; è possibile infatti sviluppare delle procedure operative che rendano uniforme e coerente il processo di gestione acquisti per entrambi i magazzini e pertanto utilizzare il medesimo applicativo, pur con le peculiarità proprie di ciascun ambito, per la gestione delle giacenze e delle assegnazioni alle unità organizzative e ai dipendenti dell’ente.

Tutte le funzionalità DEVONO essere accessibili via web agli utenti coinvolti dalla Intranet regionale tramite un’area dedicata e mediante validazione tramite LDAP corporate.

Inoltre questo sistema DEVE essere integrato col sistema SICER, affinché avvenga l’inserimento automatico dei beni a fronte dell’inserimento delle fatture di acquisto.

6.3.3.1 Gestione Inventario

Tutti i beni mobili costituenti il patrimonio della regione Lazio DEVONO essere classificati, descritti, valutati, identificati e amministrati. I beni vengono distinti in inventariabili e non inventariabili, a seconda della loro importanza, durata, valore e consistenza e amministrati di conseguenza.

Il sistema in oggetto DEVE quindi garantire la gestione end to end del ciclo di vita di un bene mobile; per fare questo DEVE gestire tutte le informazioni relative, quali, a titolo esemplificativo e non esaustivo:

• Codice univoco inventario

• Ubicazione del bene

• Dati rilevazione (data rilevazione e operatore)

• Centro di Costo

• Categoria e sottocategorie Inventariale

• Informazioni Contabili (valore iniziale, valore attuale, dati relativi all’ammortamento)

• Stato del bene: Nuovo, Mancante, Dismesso, Venduto

• Eventuali attributi del bene

• Inventariabile /non inventariabile

Tutti i beni mobili vengono dati in consegna ai responsabili denominati Consegnatari: per ogni struttura regionale viene nominato un consegnatario e un suo vice, esiste inoltre un Consegnatario centrale che ha le funzioni di coordinamento di tutti i consegnatari regionali ed è responsabile dell’inventario. I consegnatari sono soggetti alle disposizioni elencate nel Manuale di inventariazione (Allegato AA al Regolamento regionale 6 settembre 2002, n. 1 recante: “Regolamento di organizzazione degli uffici e dei servizi della Giunta regionale”) che riporta anche i compiti, le responsabilità ed i controlli dei consegnatari.

L’Appaltatore DEVE garantire la realizzazione delle seguenti funzionalità destinate ai consegnatari per la gestione dei beni:

• acquisizione di beni mediante buoni di carico totali e parziali: devono poter essere gestite tutte le diverse modalità di acquisizione quali:

- Acquisizione a titolo oneroso

- Donazione o acquisizione a titolo gratuito

- Acquisizione per forza di legge

- Beni di terzi

• dismissione di beni mediante buoni di scarico totali e parziali: devono poter essere gestite tutte le diverse modalità di dismissione quali:

- permuta;

- cessione gratuita;

- vendita;

- logoramento, guasto, obsolescenza tecnica;

- distruzione per cause di forza maggiore;

- furto o smarrimento.

• Catalogazione di ogni bene, mediante assegnazione della categoria inventariale, della foto, del capitolo di spesa, del centro di costo al quale è stato imputato

• Gestione delle ubicazioni e assegnazione dei beni ad una ubicazione (edificio / piano / stanza)

• Gestione dello spostamento dei beni tra le stanze e della dismissione dei beni fuori uso

• Gestione contabile dei beni, mediante calcolo del valore ammortizzato:

• Produzione del conto del consegnatario, del registro inventario e del registro dei beni ammortizzabili

Si precisa che l’inventariazione dei beni sarà fatta autonomamente dall’amministrazione e non rientra pertanto nell’oggetto del presente appalto.

L’Appaltatore DEVE realizzare apposite funzionalità che permettano di poter estrarre i report e i dati necessari alla gestione amministrativa del patrimonio, quali ad esempio:

• elenco dei beni per ubicazione: per ogni stanza o locale deve essere redatta una scheda descrittiva dei beni mobili contenuti, corredati del loro numero di inventario;

• elenco dei beni per categoria;

• elenco dei beni per sede.

Il dettaglio dei report da realizzare sarà concordato in una fase di analisi di dettaglio con i referenti di ciascuna area funzionale indicati dall’ente.

6.3.3.2 Gestione Magazzino di consumo

NON DEVONO essere inclusi nell’inventario i beni di consumo, cioè quei materiali ed oggetti che, per l’uso continuo, sono destinati ad esaurirsi od a deteriorarsi rapidamente, tuttavia il sistema DEVE permetterne comunque la gestione dell’intero processo.

Vengono di seguito riportate le principali funzionalità che l’Appaltatore DEVE rendere disponibili sul sistema per la gestione del magazzino relativo al materiale di consumo.

- Gestione degli Ordini: il sistema DEVE consentire la gestione degli ordini del materiale di consumo da parte degli addetti deputati a tale attività;

- Gestione Bolle: il sistema DEVE consentire la gestione delle bolle associate al materiale consegnato;

- Gestione Anagrafiche: l’amministratore del sistema attraverso quest’area DEVE poter visualizzare, modificare o inserire le anagrafiche presenti a sistema, quali articoli, fornitori, trasportatori, etc

- Gestione Articoli: il sistema DEVE consentire la gestione degli articoli della merce ricevuta in magazzino; in particolare, gli articoli saranno contraddistinti da una macro tipologia ('PENNA', 'TONER', 'FAX', ecc…), da un modello e da un produttore. Questo meccanismo di identificazione consentirà la ricerca e la classificazione dei beni in termini dei macro-parametri.

Le funzionalità che DEVONO essere rese disponibili all’utente per tale area sono:

• Creazione\Cancellazione\Modifica di un prodotto

• Scheda articolo

Inoltre, per ciascun articolo, DEVE essere possibile gestire una serie di varianti, che potranno avere una relazione 1:n con gli articoli di pertinenza. Nell’ambito della gestione articoli rientra anche la gestione del materiale di consumo associato alle macchine per ufficio (e.g, stampanti, fotocopiatrici, ecc..). Tali macchine per ufficio rientrano nella gestione dei beni mobili, mentre il materiale di consumo necessario al loro funzionamento viene acquistato separatamente e movimentato nell’ambito del magazzino relativo al materiale di consumo.

- Gestione dei magazzini/depositi

Il magazzino merce DEVE gestire tutti i prodotti in ingresso; occorre prevedere inoltre la gestione di un magazzino centrale e di eventuali magazzini localizzati nelle sedi decentrate, laddove vengano effettuati acquisti separati.

Le principali funzionalità che DEVONO essere gestite dal sistema sono le seguenti:

• Carico merce

• Scarico merce

• Gestione degli spostamenti all’interno del magazzino

• Gestione scorta minima e sotto-scorta

La sezione della reportistica DEVE consentire una vista aggregata dei dati contenuti nell'archivio permettendo, unicamente agli utenti abilitati, di avere una vista complessiva delle attività.

A titolo di esempio, si propongono i seguenti report:

• elenco xxxxxxx xxxxxxxxx (dal/al);

• elenco utenti;

• elenco prodotti in magazzino e relativa disponibilità.

6.3.3.3 Gestione Logistica del personale

Poter disporre di un censimento dei beni mobili e dell’assegnazione dei beni alle stanze, costituisce una base di partenza fondamentale per la gestione della logistica delle risorse umane. Ciò consentirà non solo di avere contezza dell’effettiva distribuzione delle persone nelle diverse sedi e ubicazione, ma anche di avere una mappatura in tempo reale e sempre aggiornata dell’ubicazione dei dipendenti e di tracciare e monitorare gli spostamenti del personale all’interno dei vari edifici o sedi aziendali, spostando automaticamente i beni assegnati al personale nella nuova destinazione.

L’Appaltatore DEVE quindi realizzare le seguenti funzionalità:

- gestione edifici: deve essere resa possibile la gestione di tutti i dati relativi agli edifici dell’Amministrazione, quali dati tecnici, allegati, foto, planimetrie e strutture;

- importazione automatica dei dati anagrafici del personale dagli altri sistemi informativi (es. sistema di gestione del personale) già presenti in Regione Lazio;

- assegnazione di un dipendente ad una stanza di una specifica sede regionale;

- gestione postazioni di lavoro, ovvero l’assegnazione al dipendente di una serie di beni mobili che insieme al legame con l’ubicazione vanno ad indentificare la postazione;

- gestione topografica delle sedi: è necessario consentire di localizzare le stanze in formato web, visualizzando la piantina della stanza e la dislocazione delle postazioni di lavoro all’interno della stanza. Tale strumento rappresenta un supporto ai responsabili della logistica per individuare eventuali stanze non adeguatamente sfruttate ed altre stanze nelle quali la disposizione dei dipendenti risulta non ottimale.

Il modulo DEVE permettere di poter estrarre i report e i dati necessari alla gestione amministrativa del patrimonio quali ad esempio:

- Situazione aggiornata delle stanze e delle risorse assegnate a ciascun stanza

- Elenco dei dipendenti cessati (da una certa data in poi) aventi una postazione assegnata

- Elenco del personale non dipendente avente una postazione assegnata presso una sede regionale

Il dettaglio dei report da realizzare sarà concordato in una fase di analisi di dettaglio con i referenti di ciascuna area funzionale indicati dall’ente.

6.3.3.4 APP PATMOB

Nell’ambito del presente appalto è a carico dell’appaltatore la presa in carico di un’APP per smartphone e tablet di supporto ai consegnatari e per la rilevazione e gestione dei beni mobili all’interno di tutte le sedi della Regione Lazio.

L’app DEVE essere integrata col sistema in modo da poter aggiornare in tempo reale il database centrale con i dati acquisiti nel corso della ricognizione, snellendo il lavoro di raccolta ed inserimento delle informazioni, che viene così effettuato in un unico momento.

La caratteristica principale dell’APP è la “lettura” e “scrittura” dei codici a barre o QR-Code, presenti nelle etichette e la registrazione delle stesse all’interno dell’inventario, ma permette anche di fotografare i beni, gestionali, geolocalizzare le sedi, inserire i dati tramite funzione di riconoscimento vocale.

Tale APP deve essere evoluta, in particolare le funzionalità che DEVE supportare sono le seguenti:

• Ricognizione ubicazione: avvia la gestione della etichettatura dei beni inventariali presenti in una nuova stanza (non censita);

• Spostamenti: avvia la gestione dello spostamento dei beni da un’ubicazione ad un’altra;

• Codifica Ubicazioni: permette di codificare le etichette per la catalogazione delle ubicazioni (stanze, corridoi);

• Inventario: interfaccia con l’inventario (accesso, inserimento/modifica/eliminazione bene);

• Fuori uso: gestisce il fuori uso di un bene.

6.3.3.5 Integrazione con Xxxxx

L’Appaltatore DEVE integrare il sistema PATMOB con il nuovo sistema contabile SICER, affinché non vi siano disallineamenti fra i due sistemi. In particolare, contestualmente alla rilevazione contabile ovvero alla registrazione del documento passivo, il sistema SICER DEVE creare al suo interno la scheda cespite e la scheda del bene e trasmettere tramite un apposito servizio i dati della scheda bene al sistema PATMOB, insieme al codice inventario che verrà generato al momento della registrazione del documento.

Tra le informazioni che DEVONO essere trasferite vi sono le seguenti:

• Categoria e sotto categoria inventariale

• Centro di consegna: magazzino definito di default;

• Provenienza: provenienza del bene (es. di proprietà, noleggio, donazione, leasing etc.);

• Fornitore: fornitore del bene;

• Etichetta: numero inventario del bene dato dal sistema

• Stato Bene

• Valore di Xxxxxx Xxxx: valore originario del bene;

• Quantità di Carico Bene: la quantità registrata;

• Data registrazione: data in cui avviene la registrazione;

• Data aggiornamento: data relativa alla dismissione/vendita.

Il bene quindi in questo modo è stato inserito nell’inventario e ubicato in un magazzino di default fittizio con le informazioni provenienti dai documenti contabili; è necessario quindi che ogni bene inserito in tale modalità venga lavorato dal consegnatario di riferimento, aggiungendo le informazioni mancanti, quali l’ubicazione o provvedere alla sua eliminazione logica, nel caso il bene fosse già presente a sistema.

6.3.4 Revisione modulo controllo di gestione e controllo strategico

L’Appaltatore DEVE personalizzare il sistema SICER per reingegnerizzare ed evolvere le attuali funzionalità di controllo di gestione e controllo strategico nella direzione di seguito indicata.

Il controllo di gestione assume una caratterizzazione significativa solo se a monte la struttura è organizzata secondo criteri di programmazione e pianificazione strategica. La condizione per un efficace controllo di gestione è l’attività di pianificazione strategica. Il controllo di gestione serve a verificare l’andamento della gestione in termini di risultati attesi – conseguiti e di economicità. La sua efficace applicazione non può prescindere, pertanto, da una revisione completa della gestione delle attività che dovrebbero essere condotte secondo criteri basati sui principi della pianificazione strategica.

Attraverso i processi di pianificazione strategica l’attenzione dell’amministrazione è focalizzata sugli obiettivi dell’organizzazione, sui relativi cambiamenti, sulle risorse umane e finanziarie che vengono utilizzate per perseguire gli stessi, innescando un circolo virtuoso tra pianificazione – gestione – valutazione – controllo. Il fulcro della pianificazione strategica è la determinazione degli obiettivi che saranno, successivamente, oggetto di valutazione in itinere e finale.

Perché il controllo di gestione possa assolvere alla sua funzione di guida è necessario che siano rispettate specifiche fasi operative e siano utilizzati determinati strumenti conoscitivi e di analisi. Le fasi operative sono le seguenti:

1. verifica e conoscenza della struttura

2. pianificazione dell’attività e individuazione degli obiettivi di medio/lungo e breve periodo

3. misurazione dei risultati, verifica degli scostamenti tra obiettivi e risultati e introduzione di azioni correttive

4. attività di reporting.

Il Controllo strategico valuta l’adeguatezza delle scelte compiute in sede di attuazione del programma regionale di sviluppo in termini di congruenza tra risultati conseguiti e obiettivi predefiniti con particolare attenzione a quelli prioritari, rendendone una lettura sintetica e strategica con lo scopo di redigere e aggiornare i documenti di programmazione. Assicura il conseguimento dei risultati attesi stabiliti in sede di pianificazione operativa, rilevando, mediante la misurazione di appositi indicatori, lo scostamento tra azioni pianificate e risultati conseguiti.

Il Controllo di gestione verifica l’efficacia, l’efficienza e l’economicità dell’azione amministrativa in una prospettiva multidimensionale al fine di ottimizzare, anche mediante tempestivi interventi di correzione, il rapporto tra costi e risultati.

I sistemi di controllo comprendono un complesso di elementi organizzativi: la pianificazione strategica, il processo budgetario, la misurazione e valutazione delle performance, il sistema di incentivazione, etc. Essi sono quindi sistemi compositi e strutturati che combinano tecniche assai differenti tra loro: descrizioni di ruoli e funzioni, descrizioni del lavoro e dei compiti, standardizzazione di procedure, budget, misurazioni contabili e non contabili, valutazione delle performance. Inoltre, nel caso specifico, il sistema del controllo deve basarsi sul presupposto fondamentale che la sua vera ragion d’essere consiste nel supportare l’organizzazione regionale al raggiungimento dei suoi fini e dei suoi scopi, ovvero dei suoi obiettivi a medio, lungo ed a breve termine.

L’iter completo del processo è dunque il seguente:

1. pianificazione e progettazione;

2. organizzazione delle risorse e definizione dei budget;

3. realizzazione delle attività ed erogazione dei servizi;

4. raggiungimento dei risultati.

A questo processo complesso occorre integrare tre momenti di controllo e supporto utili per l’adozione delle decisioni al fine di applicare correttamente il sistema premiante.

1. Pianificazione e progettazione

2. Organizzazione delle risorse e definizione dei budget

3. Il sistema di misurazione

4. Controllo interno e valutazione delle performance

5. Sistema di incentivazione

Dal sistema SICER DEVONO scaturire informazioni di carattere economico patrimoniale declinate in maniera analitica con precisa indicazione dei costi effettivamente sostenuti (valore delle risorse impiegate) da parte delle singole parti in cui è suddivisa la struttura dell’amministrazione regionale (centri di responsabilità) secondo il criterio della “destinazione” dei fattori produttivi impiegati. Esso quindi DEVE permettere di rilevare sia i risultati riguardanti l’amministrazione nella sua globalità, sia quelli riferiti alle sue parti specifiche (centri di costo), consentendo, anche per singola unità, il confronto tra dati di budget e di consuntivo. In altre parole, questo nuovo sistema di contabilità consentirà di classificare per ciascuna struttura organizzativa il profilo economico, vale a dire il costo di gestione, secondo la rispettiva natura e destinazione e di verificare le condizioni d’impiego delle risorse.

6.4 Progettazione e implementazioni di software applicativo sicuro

6.4.1 Requisiti di sicurezza

L’Appaltatore DEVE effettuare la progettazione e lo sviluppo di sistemi software seguendo le best practice relative alla sicurezza informatica in conformità alle “Linee guida per lo sviluppo del software sicuro” pubblicate su xxxxx://xxx.xxxx.xxx.xx/xx/xxxxxxxxx/xxxx-xx/xxxxx-xxxxx-xxxxxxxx-xxx-xxxxxxxx-xxxxxx .

L’Appaltatore DEVE garantire che il software applicativo ammesso all’esercizio sia immune almeno per i Top Ten Risk di OWASP correnti, SANS Top 25. Il software deve essere sottoposto ad opportune verifiche di sicurezza dopo ogni modifica significativa e comunque prima dell’entrata in esercizio di ciascuna versione. Lo stesso deve essere progettato e sviluppato in conformità allo standard aggiornato OWASP ASVS 4.0 di livello 2. Dal risultato di suddetta analisi si deve chiaramente evincere l’immunità del sistema prodotto (in ogni sua parte) ai Top Ten Risk di OWASP correnti, la conformità allo standard di sicurezza OWASP ASVS 4.0 di livello 2 e SANS Top 25. Inoltre, già in fase di progettazione deve essere predisposto un documento contenente tutti i software di base utilizzati dal sistema e le loro configurazioni previste. Tutte le configurazioni devono essere configurate in conformità a quanto disposto dall’allegato

3 delle linee guida AgiD per lo sviluppo del software sicuro. Il disegno di progetto deve contenere tutti gli eventuali accorgimenti di sicurezza che si rendessero necessari per connettere i diversi componenti del sistema in conformità a quanto disposto dall’allegato 4 delle linee guida AgiD per lo sviluppo del software sicuro. Nel caso di utilizzo di tool per l’esecuzione delle attività di cui al presente paragrafo, tali strumenti devono essere preventivamente comunicati ed approvati dalla Società Appaltante. A tale scopo dovranno essere svolte le seguenti attività:

• stesura dei requisiti di sicurezza, dei casi di abuso tramite opportuna rappresentazione;

• esecuzione dei test di sicurezza durante le fasi di sviluppo e di rilascio per la verifica delle compliance con i requisiti forniti;

• analisi di sicurezza del codice sorgente e del sistema realizzato prima dell’entrata in esercizio dello stesso al fine di certificare l’aderenza ai requisiti di sicurezza previsti;

• analisi e test di cui al punto precedente per rilasciare una evidenza attestante sia la conformità almeno al livello 2 dell’OWASP ASVS 4.0 che l’immunità ad almeno i Top Ten Risk OWASP correnti.

L’evidenza di cui sopra, costituisce elemento necessario ai fini dell’ammissione del sistema alla fase di collaudo. Nel caso in cui il sistema prodotto non soddisfi i requisiti di sicurezza prescritti o che non raggiunga la conformità al livello 2 dell’OWASP ASVS 4.0 o non raggiunga l’immunità ad almeno i Top Ten Risk di OWASP correnti e SANS Top 25, il sistema non potrà essere ammesso al collaudo. La certificazione di cui sopra deve essere rilasciata almeno ogni 12 mesi o comunque su richiesta della Società Appaltante, in caso di incident sul sistema. L’analisi del codice sorgente e delle URL esposte dalle applicazioni web, deve essere effettuata almeno ogni tre mesi oppure non meno di due volte nel corso della fase implementativa, scegliendo l’opzione che corrisponde al minor lasso di tempo tra due verifiche successive. Quanto precede, per garantire in maniera continuativa uno sviluppo sicuro ed efficiente del software. In base alle indicazioni presenti nel Data Processing Agreement (DPA) dovrà essere redatto, un apposito documento contenente tutte le informazioni elementari che saranno trattate, la loro tipologia e le modalità con cui si implementeranno le misure indicate (per la conformità con il GDPR), con riferimento alle tecniche eventualmente richieste, quali, ad esempio, mascheramento, pseudonimizzazione, cifratura, ecc.

Per ciascuna informazione elementare sulla base del DPA dovrà essere chiaramente espresso il periodo di permanenza del dato nel sistema, le modalità previste per la relativa rettifica/cancellazione nonché le finalità del trattamento del dato stesso. Sarà cura della Società Appaltante prevedere la realizzazione di una base di dati di test contenente informazioni fittizie, ai fini delle verifiche iniziali e in esercizio. Per quanto concerne la normativa in vigore in materia di “Misure minime di sicurezza ICT per le Pubbliche Amministrazioni” di cui alla circolare 18 aprile 2017 n° 2/2017, dovranno essere messi in atto tutti gli accorgimenti, procedurali e tecnologici, al fine di realizzare le regole ABSC 4 e ABSC 13.1, in modo da ottenere il livello standard di dette misure, nonché implementare anche le regole ABSC 5, riguardanti l’utilizzo di utenze non privilegiate per l’esecuzione dei servizi/processi necessari al funzionamento del software applicativo, e l’attuazione dell’ABSC 10, limitatamente agli aspetti relativi al backup. L’esecuzione dovrà avvenire di concerto con gli uffici di competenza preposti dalla Società Appaltante. Ogni problematica riscontrata nell’ambito delle citate verifiche dovrà essere corretta al fine di consentire alla Società Appaltante di superare le eventuali verifiche dell’AgID.

6.4.2 Requisiti di affidabilità

Riguardo la continuità operativa della soluzione, l’Appaltatore DEVE progettare e realizzare dei meccanismi, in funzione della disponibilità dell’infrastruttura ICT messa a disposizione della Società Appaltante, capaci di garantire la continuità dei servizi erogati nel rispetto degli SLA sottoelencati. L’architettura proposta dovrà rispettare i valori di RTO e RPO di seguito specificati (valori standard che dovranno essere personalizzati in funzione della soluzione oggetto di attività e del relativo contesto di riferimento):

EVENTI	RTO	RPO
Priorità alta	8 ore lavorative (nel 100% dei casi)	24 ore solari (nel 100% dei casi)
Priorità media	8 ore lavorative (nel 100% dei casi)
Priorità bassa	12 ore lavorative (nel 100% dei casi)

Conformemente ai valori di RPO richiesti, dovrà essere progettato e implementato un processo automatizzato di backup del sistema integrato con il sistema di backup della Società Appaltante avendo cura inoltre, di definire puntualmente ciascun elemento da proteggere e l’ordine per un eventuale ripristino. Inoltre, caso di cifratura dei dati, dovrà essere implementato un adeguato sistema di gestione delle chiavi di cifratura. Infine, dovranno essere predisposte opportune guide e script per la messa in produzione del sistema a seguito di disastro; tali guide dovranno consentire anche ad utenti non esperti la configurazione del database e l’importazione degli ultimi dati utili.

6.4.3 Requisiti di usabilità ed accessibilità

L’Appaltatore DEVE garantire che i sistemi SICER MIR PAT XXX XXX MOB rispettino le norme relative alla qualità in termini di accessibilità, trasparenza, usabilità secondo le indicazioni contenute nel sito di Designers Italia (xxxx://xxxxxxxxx.xxxxxx.xx). Nel rispetto di quanto previsto dalla normativa in materia di tutela e protezione dei dati personali e, in particolare, dal Regolamento UE 2016/679, i sistemi SICER MIR PAT XXX XXX MOB DEVONO garantire che, per impostazione predefinita, i dati personali eventualmente trattati tramite il Sistema non siano resi accessibili a un numero indefinito o a soggetti non autorizzati. Inoltre, il Sistema dovrà rispettare gli standard WCAG

2.1 livello A e Livello AA e, laddove più restrittivi, i requisiti tecnici della legge Stanca descritti nell’allegato A aggiornato con il DM 20 Marzo 2013. Tale conformità dovrà essere dimostrata mediante la predisposizione di un report iniziale da aggiornare a seguito di eventuali modifiche che impattano sull’accessibilità del sistema. La verifica della conformità allo standard deve essere effettuata per la preventiva approvazione da parte della Società Appaltante. Nel caso di applicazioni Web, l’accesso al sistema dovrà avvenire via pagine HTML (HTML5, sono da escludersi Java, Silverlight e Flash) e dovrà essere garantita la compatibilità con la maggioranza dei browser attualmente in commercio ed almeno quelli che coprono l’85% del market share worldwide.

6.4.4 Requisiti architetturali

Nel caso di applicazioni Web, i sistemi SICER, MIR, XXX XXX, PAT MOB DOVRANNO essere fruibili utilizzando il protocollo HTTPS, dovrà essere scalabile, modulare, orientato ai servizi e sarà ospitato su ambiente virtuale. Dovrà essere fornito nell’ambito del progetto un documento nel quale siano indicati i requisiti di carattere infrastrutturale. In particolare:

• le risorse computazionali stimate richieste in termini di vCPU (considerando un rapporto di oversubscription di pCpu:vCpu 1:2), vRAM, spazio disco (utile) ivi comprensivo della parte relativa ai backup.

• il numero nonché la tipologia delle macchine virtuali di cui dovrà comporsi il sistema di produzione e quello di test/collaudo. Il sistema non dovrà avere alcuna dipendenza da hypervisor specifici. Ciascun componente architetturale del sistema dovrà essere progettato in modo da poter lavorare in alta affidabilità e che un singolo failure non comporti un’interruzione del servizio. Ogni operazione effettuata da qualsiasi utente attraverso l’interfaccia grafica dovrà essere opportunamente registrata nei modi e formati preventivamente stabiliti di concerto con l’Amministrazione.

I log così creati, nelle more dell’acquisizione di un sistema centralizzato di logging, dovranno essere mantenuti per almeno 6 mesi e solo successivamente cancellati in modo automatizzato. Ad acquisizione avvenuta del sistema centralizzato di logging, sarà cura del fornitore supportare la Società Appaltante nella raccolta dei log in formato standard con eventuali regole di correlazione/alerting. Dovrà essere presente un diagramma di deployment di massima, con un mapping tra le VM (e/o eventuali container) e i diversi componenti, ed inoltre dovranno essere elencati tutti i servizi/componenti del sistema e le loro interazioni. La configurazione di base delle macchine virtuali sarà curata degli uffici competenti nella gestione e manutenzione dei sistemi di LAZIOcrea, mentre le configurazioni/personalizzazioni di tutte le altre componenti applicative del sistema saranno a cura del gruppo di progetto che provvederà anche a predisporre opportune guide ed a rilasciare copia di tutte le configurazioni effettuate. Nel rispetto della normativa in materia di tutela e protezione dei dati personali e, in particolare, del Regolamento UE 2016/679, in ogni fase di sviluppo, progettazione e release del sistema dovrà essere garantito che, per impostazione predefinita, siano trattati solo i dati necessari per l’esecuzione del servizio da erogare tramite il sistema. Il documento previsto, contenente l’architettura del sistema dovrà essere sottoposto alRUP e DEC se previsto per la successiva approvazione, prima dell’avvio della fase di sviluppo e modificato sulla base delle eventuali osservazioni di quest’ultima.

6.4.5 Requisiti software di base

I sistemi SICER MIR PAT XXX XXX MOBDOVRANNO essere realizzati o evoluti utilizzando preferibilmente software Open Source. La Società Appaltante si riserva di richiedere eventuali modifiche ai suddetti software. Tutto il codice sorgente, commentato in maniera dettagliata e conforme alla best practice degli specifici linguaggi utilizzati, dovrà essere consegnato ai referenti di progetto corredato dai documenti di progetto ad esso riferibili; tale documentazione dovrà essere consegnata anche in formato HTML, qualora gli strumenti utilizzati ne consentano la generazione automatica. Con la consegna del codice sorgente, ne sarà altresì contestualmente trasferita la proprietà in capo alla Società Appaltante.

6.4.6 Requisiti per i Container

I container sono ambienti operativi delimitati all’interno di un sistema operativo all’interno dei quali è possibile effettuare il deploy delle applicazioni (app), sotto forma di file immagini. In pratica, il container fa da mediatore fra l’app e le risorse fornite dal sistema operativo. L’isolamento di un’app è una garanzia per il suo corretto funzionamento, ed anche perché il sistema operativo possa correttamente bilanciare le sue risorse fra le varie app concorrenti. In questi casi il deploy viene effettuato trasferendo delle immagini che racchiudono l’intera applicazione. L’immagine dunque deve essere configurata con il minimo dei privilegi, eliminando utenze di default e impostazioni di debug, al fine di limitare la superficie d’attacco. Dovrà essere verificata l’assenza di malware e di password o stringhe di connessione in chiaro. Dovrà essere verificata inoltre la provenienza delle immagini, che saranno censite e catalogate, prima di essere installate. La connessione di un utente a un registry, cioè il repository delle immagini, per trasmettere un’immagine, dovrà essere crittografata. L’accesso dovrà essere sottoposto ad autenticazione e autorizzazione; tutte le operazioni sul registry dovranno essere monitorate attraverso operazioni di logging. Nel registry le versioni delle immagini più obsolete, particolarmente quelle rivelatisi meno sicure, dovranno essere costantemente archiviate e poi eliminate. Alcuni rischi sono connessi all’orchestrator, il componente che coordina gli scambi fra i vari container (nodi). Anche l’accesso a un orchestrator deve essere soggetto ad autenticazione e autorizzazione differenziati. Un Orchestrator dovrà gestire app con livelli di riservatezza e carichi di traffico analoghi; se un’App va in errore, l’Orchestrator deve poter garantire il funzionamento delle altre (resilienza). Dovrà essere impedito l’accesso diretto da parte dell’utente ai container. Dovrà essere accedere sempre sfruttando l’orchestrator. Il runtime del container dovrà essere costantemente aggiornato, in modo che nessuna vulnerabilità possa essere sfruttata per attaccare le App deployate al suo interno o il sistema operativo ospite. Non dovrà essere possibile per i container montare directory sensibili del sistema operativo e l’accesso a directory diverse dovrà essere possibile con il minimo dei privilegi. Una minaccia seria è costituita dalla possibilità che il sistema operativo ospite possa essere vulnerabile a possibili attacchi da parte di malintenzionati. Preferibilmente, sullo stesso sistema operativo non dovranno essere installate App containerizzate insieme con App non- containerizzate. Alcuni sistemi operativi sono realizzati in modo da ospitare solo container. Se il sistema operativo scelto non è fra questi, occorrerà procedere con una rigorosa hardenizzazione dell’host.

6.4.7 Requisiti per le Applicazioni “Mobile”

Le applicazioni rilasciate in ambito “mobile”, comunemente denominate app, e le relative controparti di back end, dovranno garantire la compliance ai requisiti di sicurezza OWASP per il comparto “mobile” e quindi l’immunità rispetto alle vulnerabilità contemplate dalla Mobile Top 10 corrente. In particolare, per lo sviluppo delle App occorre attenersi a best practices esistenti e studiate appositamente per ciascun sistema operativo mobile.

Requisiti per Android

L’aggiornamento costante e l’uso di librerie esenti da vulnerabilità è prerequisito indispensabile. Le App dovranno utilizzare lo storage interno all’app per memorizzare i dati, avendo cura di proteggere quelli particolarmente sensibili con una crittografia forte. Poiché il sistema operativo isola le app le une dalle altre, le risorse alle quali un’App potrà attingere dovranno essere strettamente regolamentate dai permessi. La configurazione di un’applicazione mobile sarà la più severa possibile. Dovranno essere richiesti solo i permessi strettamente necessari al funzionamento dell’app.

Dovrà essere implementata una rigorosa verifica dell’input, sia che si tratti di input utente, file presenti in storage esterni, delle risposte di web services o di dati restituiti da altre app invocate tramite IPC (inter-process communication). Per quanto riguarda quest’ultima modalità di comunicazione, non dovranno essere utilizzati i socket di Linux, né dei file condivisi; occorrerà avvalersi di oggetti Android come Intent, Services, Binder e Messenger, sui quali dovranno essere configurati permessi specifici. L’input proveniente da SMS dovrà essere sempre filtrato e verificato, poiché si tratta di testo in chiaro non sottoposto a verifiche. La comunicazione dovrà avvenire sempre su canali sicuri (SSL/TLS) e dovranno essere accettati solo i certificati rilasciati da una CA autorevole e universalmente riconosciuta. Deve essere limitato l’uso dell’oggetto WebView, per la visualizzazione di contenuti remoti, imponendo restrizioni di configurazione che limitino o impediscano del tutto l’esecuzione di Javascript, al fine di evitare attacchi di Cross Site Scripting. Un’app non dovrà proporre il login più di una volta, né dovrà memorizzare in locale le credenziali; dovrà utilizzare un token per gestire l’autenticazione dell’utente, ogni qual volta se ne abbia la necessità. Un’app non deve caricare dinamicamente del codice eseguibile, poiché il rischio di un attacco di code injection sarebbe molto elevato, persino se si adottassero misure di mitigazione idonee.

Requisiti per iOS

Anche nel caso dei dispositivi che montano iOS, l’App dovrà stabilire l'identità di un utente (autenticazione) e quindi concedere in modo selettivo l'accesso alle risorse (autorizzazione). L’autenticazione dovrà essere effettuata con una password lunga e complessa; preferibilmente l’accesso avverrà attraverso credenziali multifattoriali (avvalendosi anche di dati biometrici, certificati, ecc). Deve essere garantita la protezione dei dati, dal momento in cui sono memorizzati in uno storage fisico al momento in cui viaggino attraverso una connessione di rete. Nel caso di trattamento di dati sensibili dovrà essere implementata la crittografia con un algoritmo “forte”. Il codice prodotto dovrà essere firmato digitalmente, attraverso la tecnologia Code Signing di macOS; in tal modo ogni rilascio sarà inequivocabilmente riconosciuto come genuino. Ciò impedirà il tampering dell’App da parte di attaccanti esterni. L’App potrà essere anche registrata presso Apple (notarization). Per garantire la stabilità dell’app sviluppata, quest’ultima dovrà superare il test arm64. L'architettura arm64 introduce i codici di autenticazione del puntatore (PAC) per rilevare e prevenire modifiche inaspettate ai puntatori in memoria. L’App dovrà implementare App Sandbox, una tecnologia di controllo degli accessi fornita in macOS, applicata a livello di kernel. In tal modo è possibile contenere danni al sistema e ai dati dell'utente nel caso di compromissione dell’App. L’App dovrà essere sviluppata con l’opzione “Hardened Runtime Entitlements”, che consente all'applicazione di eseguire ulteriori protezioni di sicurezza e restrizioni sull'accesso alle risorse.

6.4.8 Deliverable da consegnare

Prima dell’inizio dello sviluppo

Relativamente agli aspetti di Cyber Security, prima dell’inizio delle attività di sviluppo dovranno essere disponibili le seguenti informazioni:

• qualora applicabile, la definizione delle attività affidate a terzi con l’indicazione sintetica del quadro giuridico o contrattuale (nonché organizzativo e tecnico) in cui tale affidamento si inserisce, in riferimento agli impegni assunti, anche all’esterno, per garantire la sicurezza della soluzione stesso.

• il personale coinvolto nel trattamento dei dati, per i quali DOVRANNO essere descritti compiti e responsabilità di competenza:

▪ gli amministratori di sistema ai sensi del Provvedimento del Garante per la protezione dei dati personali del 27 novembre 2008 e s.m.i.;

▪ il responsabile del trattamento ai sensi dell’art. 28 del Reg. UE 2016/679;

▪ gli incaricati interni e esterni.

• la definizione delle linee guida progettuali per la determinazione delle misure di sicurezza minime e idonee per la protezione dei dati informatici e dei relativi flussi;

• i principali eventi potenzialmente dannosi per la sicurezza dei dati (analisi dei rischi) con le relative valutazioni delle possibili conseguenze, della gravità in relazione al contesto fisico– ambientale di riferimento, gli strumenti elettronici utilizzati (comportamenti anomali da parte degli operatori al servizio, malfunzionamento degli strumenti utilizzati, virus, ecc.) e i relativi casi di test;

• documento contenente l’indicazione degli accorgimenti a livello di progettazione atti a mitigare i rischi, definiti nel precedente punto, al fine di soddisfare quanto previsto dal DPA;

• il piano degli interventi formativi previsto sia per gli incaricati al trattamento dati, sia per tutte le risorse identificate come addetti alla sicurezza ed alla gestione della soluzione oggetto del presente appalto;

• recepimento ed accettazione del documento dei requisiti di sicurezza del sistema da parte del fornitore (qualora previsti).

Prima dell’entrata in esercizio

Di seguito, si elencano le informazioni e i documenti, relativi alla sicurezza informatica, che dovranno essere disponibili contestualmente all’approntamento al collaudo finale:

• le Banche Dati messe a disposizione della Stazione Appaltante e/o dell’Amministrazione (ovvero il data base o l’archivio informatico), con le relative applicazioni, in cui sono contenuti i dati. Uno stesso trattamento può richiedere l’utilizzo di dati che risiedono in più di una banca dati. In tal caso le banche dati dovranno essere elencate;

• la descrizione della gestione dell’interazione della soluzione oggetto dell’appalto con eventuali altri sistema e del personale dell’Appaltatore con le persone coinvolte nella gestione dei Data Center con riferimento a:

▪ il luogo in cui risiedono fisicamente i dati, ovvero dove si trovano gli elaboratori sui cui dischi sono memorizzati i dati (in quale sede, centrale o periferica, o presso quale Fornitore di servizi, ecc.), i luoghi di conservazione dei supporti magnetici utilizzati per le copie di sicurezza (nastri, CD, ecc.) ed ogni altro supporto rimovibile;

▪ la tipologia di dispositivi di accesso, cioè l’elenco e la relazione sintetica degli strumenti utilizzati dai Responsabili e dagli Incaricati per effettuare il trattamento: pc, terminale non intelligente, dispositivo mobile, ecc.;

▪ la tipologia di interconnessione, cioè la descrizione sintetica e qualitativa della rete che collega i dispositivi d’accesso ai dati utilizzati dagli incaricati: rete locale, geografica, Internet, ecc.;

▪ i criteri e le procedure adottati per il ripristino dei dati in caso di loro danneggiamento o di inaffidabilità della base dati. L’importanza di queste attività deriva dall’eccezionalità delle situazioni in cui il ripristino ha luogo: è essenziale che quando sono necessarie, le copie dei dati siano disponibili e che le procedure di reinstallazione siano efficaci. Pertanto, è opportuno descrivere sinteticamente anche i criteri e le procedure adottate per il salvataggio dei dati al fine di una corretta esecuzione del loro ripristino;

• piano di backup contenente, tra l’altro, tutte le informazioni di dettaglio sulle parti applicative su cui effettuare il backup;

• documento contenente i singoli passaggi per installare da zero o per ripristinare la funzionalità del sistema a partire da un backup a seguito di eventi di disastro;

• certificazione riguardante la sicurezza informatica di cui al paragrafo 4.4.1;

• report attestante gli accorgimenti adottati in base alle indicazioni presenti nel DPA ivi compreso l’elenco completo delle informazioni elementari con indicazione, per ciascuna, del periodo di permanenza del dato nel sistema e delle modalità previste e messe a disposizione del proprietario del dato per la rettifica/cancellazione delle stesse;

• ove necessario, la valutazione di impatto sulla protezione dei dati personali svolta, ai sensi dell’art. 35 del Regolamento UE 2016/679, dal titolare del trattamento anche con l’ausilio della Società Appaltante;

• tutta la documentazione e le procedure per la gestione tecnico-operativa dei sistemi conformi al modello adottato;

• il codice sorgente opportunamente commentato, tutti i file di configurazione degli applicativi/Framework/Stack adottati e ogni altro artefatto necessario al funzionamento del sistema nella sua interezza.

La gestione del codice sorgente eventualmente acquisito o sviluppato appositamente non deve contenere vulnerabilità di sicurezza; inoltre, deve essere garantita sia la conformità del codice in parola alle normative vigenti (p.e. Linee guida AgID), sia la rispondenza tra sorgente ed eseguibile per tramite di un processo di “build” ingegnerizzato.

6.5 Manutenzione evolutiva (MEV)

Oltre allo sviluppo “a corpo” delle componenti precedentemente elencate e descritte, è inclusa nel presente appalto l’erogazione, a richiesta, di un servizio di MEV che preveda la fornitura di 4.908 (quattromilanovecentootto) giornate/persona da erogarsi a consumo nell’arco dell’intero appalto, per la realizzazione di nuovi sviluppi e/o interventi di manutenzione evolutiva sui sistemi e sotto sistemi coinvolti nell’ambito del presente appalto (SICER – PATMOB – PATIMM – MIR).

In particolare, l’Appaltatore DEVE garantire l’erogazione del servizio di MEV, ove richiesto, attraverso le seguenti figure professionali, per le corrispondenti giornate/persona minime:

FIGURA PROFESSIONALE	GG/UU minimi
Capoprogetto	60
Specialista di Tematica	210
Analista Funzionale	799
Analista Programmatore	1.544
Programmatore	2.295
TOTALE	4.908

A seguito di una richiesta formulata dalla Società Appaltante di implementazione di ulteriori requisiti rispetto a quelli descritti e dettagliati in precedenza, l’Appaltatore DEVE presentare un apposito Piano delle attività evolutive, che deve essere approvato formalmente dalla Società Appaltante. In ciascun Piano delle attività evolutive, l’Appaltatore DEVE indicare:

• il numero delle risorse da utilizzare, suddivise per profilo professionale;

• il numero di giornate/persona da impiegare, per ciascuna risorsa da utilizzare;

• la descrizione delle attività da realizzare;

• le tempistiche di realizzazione e gli output previsti;

• il piano dei test e collaudo.

Con riferimento alle attività pianificate ed approvate dalla Società Appaltante, al termine dell’esecuzione dell’attività richiesta, l’Appaltatore DEVE presentare un rapporto di riepilogo delle attività effettivamente erogate, che verranno valutate dalla Società Appaltante attraverso uno o più dei seguenti indicatori di qualità:

• l’efficienza temporale;

• l’utilizzo delle risorse;

• l’accuratezza dei documenti prodotti;

• correttezza del applicativo sviluppato;

• il rispetto degli standard;

• la soddisfazione dell’utente;

• la comprensibilità del prodotto.

Si precisa che la scelta degli indicatori impiegati ed i relativi obiettivi (valori soglia) da soddisfare, saranno definiti puntualmente ad ogni richiesta d’intervento. Qualora, in circostanze particolari, l’effort effettivamente erogato dall’Appaltatore dovesse subire uno scostamento rispetto a quanto stimato nel Piano delle attività evolutive approvato dalla Società Appaltante, quest’ultima valuterà, mediante l’utilizzo dei predetti indicatori di qualità, se tale scostamento sia o meno giustificato.

Resta inteso che, in ogni caso, la Società Appaltante riconoscerà e autorizzerà il pagamento delle sole attività effettivamente svolte in esecuzione di quanto preventivato nel Piano delle attività.

Nel caso in cui la valutazione delle attività evolutive non soddisfi gli obiettivi richiesti, l’attività oggetto della valutazione non può essere considerata conclusa e l’Appaltatore DEVE mettere in atto tutte le possibili azioni correttive al fine di ottenere il raggiungimento degli obiettivi richiesti e quindi la conclusione dell’attività.

La Società Appaltante procederà al pagamento ed allo scorporo (dal monte di giornate/persona destinate al servizio) delle sole giornate/persona indicate nei Piani delle attività preventivamente approvati dalla Società stessa.

Fermo restando quanto sopra la Società Appaltante si riserva l’insindacabile facoltà di utilizzare in tutto o in parte le giornate/persona messe a disposizione dall’Appaltatore e nessun compenso sarà riconosciuto/dovuto all’Appaltatore per le giornate/persona eventualmente non utilizzate.

Si precisa che l’Appaltatore DEVE progettare, realizzare, testare, rilasciare in esercizio e documentare tutti gli sviluppi effettuali in piena coerenza con quanto previsto dagli standard architetturali e dalle norme di qualità adottate da LAZIOcrea S.p.A.

6.6 Manutenzione adeguativa e correttiva (MAD e MAC)

L’Appaltatore DEVE prestare un servizio di manutenzione adeguativa e correttiva sui sistemi oggetto del presente appalto (SICER – PATMOB – PATIMM e MIR) e su tutte le funzionalità realizzate in virtù del presente Appalto a decorrere dalla presa in carico dei sistemi SICER-PATIMM-MIR e dall’avvio in esercizio del nuovo sistema PATMOB, sviluppato in esecuzione del presente appalto, e per tutta la durata dell’Appalto.

Si precisa che:

• la manutenzione correttiva comprende la diagnosi e la rimozione delle cause e degli effetti dei malfunzionamenti delle procedure e dei programmi, sia preesistenti (ossia presenti sui sistemi da evolvere nell’ambito del presente appalto), sia realizzati nell’ambito del presente appalto;

• la manutenzione adeguativa comprende due tipologie di manutenzione ed in particolare:

▪ attività di manutenzione volta ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell’ambiente tecnologico del Sistema informativo ed al cambiamento dei requisiti (d’ambiente, di sicurezza). A titolo esemplificativo e non esaustivo si citano le seguenti tipologie di intervento: adeguamenti necessari per l’aggiornamento di versioni del software di base e per l’aggiornamento delle versioni del sistema realizzato nell’ambito del presente progetto, adeguamenti necessari per preservare l’efficienza degli applicativi al variare delle condizioni e dei carichi di lavoro, ad esempio per migliorie di performance, per aumento delle dimensioni delle basi dati, ecc.). Gli interventi di manutenzione adeguativa che rientrano in tale tipologia, qualora la stima per la realizzazione effettuata dall’Appaltatore ed approvata dalla Società Appaltante superi i 45 gg/uu, saranno classificati come interventi di manutenzione adeguativa per il numero di giorni fino alla soglia indicata, mentre i giorni eccedenti tale soglia saranno gestiti e rendicontati come giorni di MEV;

▪ Attività di manutenzione volte ad assicurare la costante aderenza delle procedure e dei programmi all’evoluzione della normativa, ai cambianti organizzativi ed alle mutate esigenze dell’ente. Gli interventi di manutenzione adeguativa che rientrano in tale tipologia, qualora la stima per la realizzazione effettuata dall’Appaltatore ed approvata dalla Società Appaltante superi i 45 gg/uu, saranno classificati come interventi di manutenzione adeguativa per il numero di giorni fino alla soglia indicata, mentre i giorni eccedenti tale soglia saranno gestiti e rendicontati come giorni di MEV;

In particolare, per problemi tecnici che dovessero determinare il malfunzionamento del sistema, l’Appaltatore DEVE garantire, a seconda della tipologia di problema determinata ad insindacabile giudizio della Società Appaltante, la completa risoluzione del problema stesso nei termini indicati di seguito:

• soluzione entro 8 (otto) ore naturali successive alla segnalazione, per malfunzionamento che blocca l’attività sull’intero Sistema;

• soluzione entro 16 (sedici) ore naturali successive alla segnalazione, per malfunzionamento anche grave che tuttavia non blocca l’attività sull’intero Sistema;

• soluzione entro 7 (sette) giorni naturali successive alla segnalazione, per altre tipologie di malfunzionamenti.

Al riguardo, si precisa che:

• per segnalazione del guasto/malfunzionamento s’intende la data e l’orario dell’effettuazione della chiamata telefonica e/o dell’invio di un messaggio di posta elettronica e/o dell’invio di un fax da parte della Società Appaltante verso l’Appaltatore.

• per orario minimo di prestazione del servizio s’intende dal lunedì al venerdì, dalle 8.00 alle 20.00 ed il sabato dalle

8.00 alle 13.00, fermo restando che la Società Appaltante si riserva l’insindacabile facoltà di richiedere in alcune situazioni particolarmente critiche la prestazione del servizio anche al di fuori del predetto orario;

• è interamente a carico dell’Appaltatore la determinazione della causa del problema, l’individuazione del guasto ed il ripristino della piena funzionalità del Sistema malfunzionante.

• l’Appaltatore DEVE inoltre garantire la manutenzione di tutte le componenti delle soluzioni realizzate e DEVE provvedere alla risoluzione dei malfunzionamenti, intervenendo anche on-site ove necessario.

Per quanto riguarda gli interventi di manutenzione adeguativa, l’Appaltatore, a seguito di una segnalazione da parte della Società Appaltante, deve presentare un piano di intervento entro e non oltre 24 (ventiquattro) ore lavorative dalla richiesta, salvo un diverso termine stabilito dalla Società Appaltante. Tale piano DEVE contenere le modalità e le tempistiche di esecuzione dell’intervento e sarà soggetto all’approvazione da parte della Società Appaltante. In caso di interventi dovuti ad adeguamenti normativi, l’intervento DEVE comunque essere effettuato nel rispetto degli eventuali termini ivi previsti.

Rientra nel servizio di MAC e MAD, anche il servizio di gestione applicativa che assicura tutte le attività utili alla gestione del ciclo di vita del software applicativo in esercizio, in particolare:

• Gestione e risoluzione di tutti i problemi quotidiani relativi a malfunzionamenti/errori (Incident) rilevati e relativi al funzionamento della piattaforma applicativa. Nello specifico, a seguito di anomalie che impattano la fruizione della piattaforma applicativa nell’ambito del presente servizio l’Appaltatore DEVE diagnosticarne le cause, attuare primi interventi di risoluzione laddove non implichino la modifica del codice sorgente bensì modifica ai parametri di sistema piuttosto che l’applicazione di work-around, effettuare escalation verso le strutture di manutenzione software qualora sia necessario intervento sul codice sorgente della piattaforma.

• Gestione e risoluzione dei problemi (Problem) rilevati sulla piattaforma applicativa e da cui possono occorrere situazioni di errore. Nello specifico, in caso di Problem nell’ambito del presente servizio l’Appaltatore DEVE assicurare le fasi di identificazione, analisi e successiva verifica della soluzione implementata.

• Gestione rilasci applicativi. Tale attività consta nell’aggiornamento degli ambienti di test, pre-produzione e produzione su cui sarà posta in esecuzione la piattaforma applicativa rispetto alle nuove release e patch software

rilasciate nell’ambito dei servizi di manutenzione e di sviluppo software. In particolare, in occasione dei passaggi in produzione di nuove componenti funzionali o patch è responsabilità dell’Appaltatore assicurare la corretta esecuzione di tutte le attività dalla presa in carico del rilascio sino al rispettivo deploy.

6.7 Formazione (FOR)

Sulla base del calendario concordato con la Società Appaltante, l’Appaltatore DEVE prestare il servizio di formazione al fine di dotare il personale dell’Amministrazione regionale e il personale LAZIOcrea S.p.A. che gestisce i sistemi coinvolti nell’ambito del presente appalto di adeguate competenze per il pieno e corretto utilizzo di quanto realizzato. In particolare, il servizio di formazione DEVE prevedere specifiche sessioni aventi ad oggetto i moduli e le funzionalità dei sistemi in ambito.

L’Appaltatore, nell’ambito del presente appalto DEVE erogare un servizio di supporto organizzativo mediante la realizzazione dei seguenti interventi:

• Demand Management: l’intero progetto richiede un’attenta analisi delle esigenze degli attori coinvolti e la definizione dei requisiti funzionali e di business propedeutici all’implementazione della soluzione. Con la prestazione di questo servizio l’Appaltatore DEVE in particolare garantire:

o Supporto alla predisposizione di comunicazioni e documenti richiesti dalle diverse autorità:

o Supporto alla predisposizione dei manuali rivolti alle varie tipologie di utenti;

o Supporto nelle fasi di test e go live attraverso la realizzazione di opportuni casi d’uso, tarati sulle esigenze dei vari soggetti coinvolti.

• Change management: il successo di un progetto così complesso presuppone la diffusione di nuove logiche operative e di nuovi strumenti, nonché un elevato coinvolgimento di tutte le strutture coinvolte. Questo deve avvenire secondo un approccio metodologico generale che, consentendo di governare il percorso di cambiamento facendo convergere in un processo unitario modalità operative e applicazioni preesistenti con le modalità di gestione del sistema SICER e dei sistemi correlati.

In particolare le attività di change management in fase di utilizzo di ulteriori attori della piattaforma SICER sono finalizzate a:

o illustrare e favorire la conoscenza dei nuovi processi di controllo di gestione e controllo strategico al fine di facilitarne l’applicazione attraverso l’uso della piattaforma

o promuovere conoscenze allargate e approfondite su temi di rilevanza quali privacy, sicurezza dei dati, ruoli e responsabilità del processo di utilizzo della dashboard direzionale;

o favorire processi interni di omogeneizzazione dei sistemi di integrati SICER e PAT – IMM, PATMOB e MIR

Gli obiettivi principali sopra menzionati riguardano il trasferimento delle competenze funzionali all’utilizzo della piattaforma – in tutte le sue funzionalità, sia di gestione, che di datawarehouse e dematerializzazione dei documenti. Le attività di change management DEVONO essere prevalentemente incentrate su:

o Formazione in aula sull’utilizzo della piattaforma rivolto a tutti i soggetti coinvolti nel suo utilizzo;

o Affiancamento operativo in fase di go-live di nuove funzionalità nell’utilizzo della piattaforma a tutti i soggetti coinvolti nel suo utilizzo.

o Produzione di corsi multimediali a distanza in formato SCORM che dovranno essere pubblicati sulla piattaforma di e-learning Moodle messa a disposizione dalla Società Appaltante;

Nell’ambito del progetto sono previste complessivamente 290 giornate che DEVONO essere erogate da figure professionali aventi adeguato profilo come indicato nei paragrafi successivi.

La Società Appaltante si riserva la facoltà di suddividere durante la durata dell’appalto il numero complessivo di ore pari a 290 fra le tre tipologie di formazione (aula, corsi multimediali, affiancamento on site).

Rispetto al plafond complessivo di giornate, si stima che 250 di queste DEVONO essere erogate a richiesta della Società Appaltante su uno dei sistemi SICER – MIR – PATMOB, mentre 40 giornate formative DEVONO essere dedicate al sistema PATIMM. salvo diversa indicazione della Società Appaltante.

Il servizio di formazione, per quel che riguarda l’organizzazione e la tempistica, prevede:

• la pianificazione dei corsi (calendario comprensivo di durata ed argomenti dettagliato per le diverse figure interessate);

• la realizzazione del materiale didattico, sia in formato elettronico, sia cartaceo, per docenti, eventuali assistenti e partecipanti;

• l’organizzazione delle sessioni, in base alla disponibilità logistica dell’Amministrazione Regionale;

• l’erogazione della docenza presso le sedi messe a disposizione dalla Società Appaltante ovvero nelle Sedi regionali e provinciali.

La documentazione utente, oltre alla manualistica esplicativa del Sistema, DEVE essere disponibile on-line sul Portale Regionale e tenuta costantemente aggiornata dall’Appaltatore. La documentazione prodotta dall’Appaltatore DEVE comprendere oltre alla manualistica anche la predisposizione di contenuti multimediali che possano essere resi disponibili da sistema e che illustrino sinteticamente le funzionalità più utilizzate dell’applicativo con la finalità di dotare l’utente di uno strumento immediato ed efficace per risolvere dubbi operativi sulle funzionalità del sistema.

Tutto il materiale didattico DEVE essere preventivamente visionato ed approvato dalla Società Appaltante e/o dalla Regione Lazio. In concomitanza di ogni sessione formativa DEVE essere predisposto un modulo di raccolta feedback ed, a conclusione di ogni ciclo, prodotto un documento sintetico riportante, anche in modo quantitativo, le indicazioni emerse. Tale documento verrà analizzato nell’ambito dei SAL periodici svolti con la Stazione Appaltante.

Si precisa che l’Appaltatore prima dell’avvio di ciascun intervento formativo deve sottoporre all’approvazione della Società Appaltante la programmazione delle giornate di formazione da erogare e le risorse impiegate per l’erogazione del servizio in corrispondenza di ciascun sessione. Nei SAL periodici con la Società Appaltante, è in carico all’Appaltatore fornire un rapporto di riepilogo delle attività formative (denominato piano delle attività formative) effettivamente erogate, che verranno valutate dalla Società Appaltante attraverso uno o più dei seguenti indicatori di qualità:

• l’efficienza temporale;

• l’utilizzo delle risorse;

• l’accuratezza dei documenti prodotti;

• il rispetto degli standard;

• la soddisfazione dell’utente;

Document Metadata

Table of Contents

CAPITOLATO TECNICO E D’ONERI

Document Metadata

CAPITOLATO TECNICO E D’ONERI

CAPITOLATO TECNICO E D’ONERI

Servizi di sviluppo, manutenzione evolutiva, adeguativa, correttiva e relativi servizi di supporto tecnico (SICER – PATMOB – MIR – PATIMM)

Indice

5.1 Contesto applicativo

Document Metadata