Contract
AFFIDAMENTO IN CONCESSIONE DELLA PROGETTAZIONE, REALIZZAZIONE E GESTIONE DI UNA INFRASTRUTTURA TECNOLOGICA PER L’ENTE E LA CITTADINANZA E DEI SERVIZI DI GESTIONE DELLE ENTRATE TRIBUTARIE ED EXTRATRIBUTARIE DEL COMUNE DI NAPOLI PROJECT FINANCING SU INIZIATIVA DEL PROPONENTE, AI SENSI DEGLI ART. 164 E SEGUENTI NONCHE’ DEGLI ARTT. 179, COMMA 3, E 183, COMMA 15 DEL DECRETO LEGISLATIVO 18 APRILE 2016, N.50 | |||||
CIG: 9399303635 | |||||
TITOLO: CAPITOLATO TECNICO DEI SISTEMI INFORMATIVI | |||||
Sommario
Area Entrate
Capitolato Tecnico dei Sistemi Informativi
Capitolato tecnico dei sistemi informativi 3
2. Attività connesse all’avvio della concessione 3
5. Monitoraggio e presidio del sistema informativo 6
6. Qualificazione della suite 6
7. Funzionalità degli applicativi 7
7.1 Funzionalità trasversali 7
Accesso e profilatura degli utenti interni 7
Tracciamento degli accessi e delle operazioni 8
Amministrazione della piattaforma 9
7.2 Funzionalità degli applicativi di Contabilità e Bilancio 10
7.3 Funzionalità degli applicativi per i Servizi demografici e statistici 16
7.4 Funzionalità degli applicativi per i Servizi tributari 20
8. SLA (Service Level Agreement) richiesti per la fornitura di servizi cloud 22
10. Attività connesse alla fine della concessione 24
Capitolato tecnico dei sistemi informativi
La disciplina delle proposte di Partenariato Pubblico Privato su iniziativa del proponente, contenuta nell’art. 183 comma 15 del D. Lgs. N. 50/2016, prevede esplicitamente che: “[…] Il progetto di fattibilità approvato è posto a base di gara, alla quale è invitato il proponente. Nel bando l'amministrazione aggiudicatrice può chiedere ai concorrenti, compreso il proponente, la presentazione di eventuali varianti al progetto. [...]”.
Il presente documento si muove nel solco di questa previsione normativa. La sua finalità non è quella di introdurre una “variante” in senso tecnico, bensì quella di specificare le funzionalità minime che dovranno essere garantite dai sistemi informativi forniti dal concessionario, nonché gli obblighi di quest’ultimo sia nella fase di avvio del contratto, sia alla scadenza della concessione.
Inoltre, congiuntamente al documento “Caratteristiche del servizio e della gestione” predisposto dal soggetto proponente, il presente documento costituisce il “Capitolato di gara”, in linea con la definizione contenuta nello “Schema di contratto”.
I contenuti del documento “Capitolato tecnico dei sistemi informativi” vanno a completare ed integrare i documenti “Progetto di fattibilità”, “Schema di contratto” e “Caratteristiche del servizio e della gestione”, e rappresentano, in termini di funzionalità e di livelli di servizio, indicazioni minime vincolanti per tutti i concorrenti.
Pertanto, nella valutazione dell’offerta tecnica, l’attribuzione dei punteggi corrispondenti ai subcriteri relativi al sistema informatico verrà effettuata considerando gli incrementi che ciascuna offerta presenterà rispetto alle funzionalità e ai livelli di servizio descritti nei documenti di cui al paragrafo precedente. Non potranno essere valutate offerte che presentino funzionalità e livelli di servizio inferiori rispetto alle indicazioni minime vincolanti.
Qualora dovessero esserci delle differenze o dei dubbi interpretativi, le indicazioni contenute nel presente documento prevalgono su quelle contenute nei documenti predisposti dal proponente (“Progetto di fattibilità”, “Caratteristiche del servizio e della gestione”, “Schema di contratto”).
2. Attività connesse all’avvio della concessione
Gli applicativi attualmente in uso presso la Ragioneria, i Servizi Anagrafici ed i Servizi Tributari sono di proprietà del Comune di Napoli (acquisiti in proprietà alla scadenza dell’appalto precedente); l’Ente si avvale di un affidamento esterno per garantire la manutenzione e la continuità operativa dei software.
Le attività connesse alla presa in carico del sistema da parte del concessionario sono descritte nel Capitolo 5
del documento “Caratteristiche del servizio e della gestione”.
È opportuno specificare che il Comune di Napoli si farà carico di garantire la manutenzione e la continuità operativa degli applicativi per sei mesi dall’aggiudicazione della concessione (a decorrere dalla data di sottoscrizione del contratto). Qualora i tempi di switch off tra il vecchio e il nuovo sistema dovessero essere più lunghi, il concessionario si farà carico dei costi di manutenzione del vecchio sistema, scomputandoli dalle fatture o eventualmente subentrando al Comune nell’affidamento di cui al primo paragrafo. Tali costi sono quantificabili in circa € 50.000,00 (oltre IVA) su base mensile. Sono a carico del concessionario tutte le attività di migrazione al nuovo sistema.
Il capitolo 4 del documento “Caratteristiche del servizio e della gestione” descrive le attività di manutenzione
dei sistemi informatici realizzati e/o forniti dal concessionario.
La manutenzione è raggruppabile in base alla natura e alle finalità in quattro distinti filoni: manutenzione correttiva, manutenzione evolutiva, manutenzione adeguativa e manutenzione migliorativa.
Nell’ambito della manutenzione evolutiva è introdotta un’ulteriore specificazione: la manutenzione evolutiva aggiuntiva, consistente negli interventi di interconnessione tra gli applicativi forniti dal concessionario con i sistemi informativi del Comune già previsti, anche se non ancora realizzati, alla data dell'affidamento della concessione.
Rientrano invece nella manutenzione migliorativa gli interventi richiesti dall’Ente concedente che non abbiano un impatto significativo sull’incremento dell’efficienza e dell’efficacia dei processi di riscossione, e gli sviluppi da realizzare per l’eventuale interconnessione con applicativi acquistati o realizzati dall’Amministrazione nel corso della durata della concessione.
Manutenzione correttiva, adeguativa ed evolutiva sono a totale carico del concessionario, mentre la manutenzione evolutiva aggiuntiva e la manutenzione migliorativa sono a carico del committente.
In particolare, sono a carico del concessionario le seguenti attività:
• manutenzione periodica finalizzata a gestire problemi di sicurezza e vulnerabilità;
• miglioramento dei requisiti di scalabilità dell’infrastruttura;
• miglioramento dell’efficienza e della usabilità dei sistemi applicativi a beneficio degli utenti interni
ed esterni;
• interventi finalizzati ad incrementare l’efficacia del cruscotto di monitoraggio.
Con riferimento alle suddette attività, il concessionario è tenuto a recepire le richieste del committente e ad implementare un’azione di verifica periodica, al fine di mantenere il livello delle prestazioni anche in presenza di significativi mutamenti delle condizioni di utilizzo del sistema. A mero titolo esemplificativo, un incremento degli utenti esterni che accedono ai servizi deve comportare sia un incremento del numero massimo di connessioni simultanee sia del numero di input o insieme di input correlati tra di loro (transazione) che possono essere processati in ciascuna unità di tempo dal servizio (SLI5 e SLI6 definiti nella Circolare AgiD n.3 del 9 Aprile 2018).
Ciascun concorrente deve indicare, nella propria offerta tecnica (subcriterio E.3), il numero di giornate/uomo di assistenza tecnica per le attività di supporto agli uffici. Tra esse rientrano le giornate-uomo messe a disposizione gratuitamente per la realizzazione di interventi di manutenzione evolutiva aggiuntiva e di interventi di manutenzione migliorativa. Qualora i due plafond fossero indicati separatamente, l’Ente ha comunque la facoltà di utilizzarli indifferentemente per le due tipologie di interventi. In caso di superamento del numero di giornate/uomo offerto, il Comune potrà richiedere il servizio alle condizioni previste dal contratto (art. 24 comma 8 dello schema di contratto).
Nel progetto del promotore posto a base di gara (Progetto di Fattibilità - Paragrafo 5.6.8. INTEGRAZIONE CON I SISTEMI INFORMATICI DEL COMUNE) è indicato un plafond di 500 giornate/uomo per la manutenzione evolutiva aggiuntiva destinate all’integrazione dei sistemi informatici realizzati nell’ambito della concessione con il POrtale TElematico dei Servizi della Città Metropolitana di Napoli (POTESs). Tale previsione rappresenta un elemento minimo vincolante per tutte le offerte. Considerato il possibile disallineamento temporale tra la realizzazione del progetto POTESs e l’implementazione dei sistemi informatici nell’ambito della concessione, il suddetto plafond può essere utilizzato, su richiesta della Stazione Appaltante, per eventuali ulteriori interventi di manutenzione evolutiva aggiuntiva, manutenzione migliorativa e supporto informatico all’attività degli uffici.
Pertanto, il numero di giornate/uomo indicate nell’offerta tecnica in corrispondenza del subcriterio E.3 deve intendersi come numero di giornate aggiuntive rispetto al plafond di cui al Paragrafo 5.6.8.
La piattaforma oggetto dell’offerta sarà preferibilmente realizzata secondo una logica orientata ai servizi (SOA) ed un’architettura basata su eventi (Event Driven Architecture), esponendo a favore di sistemi applicativi trusted ed autenticati servizi utilizzabili secondo interfacce REST e SOAP.
La piattaforma oggetto dell’offerta dovrà inoltre essere in grado di interoperare, tramite interfacce SOAP e REST, con sistemi applicativi verticali ed infrastrutturali del Comune di Napoli.
Gli applicativi dovranno essere totalmente integrati con il protocollo informatico del Comune di Napoli. Tutte le comunicazioni da e verso l’utente finale, acquisite o effettuate tramite gli applicativi (ad esempio quelle effettuate mediante il Portale del Contribuente) dovranno essere automaticamente protocollate.
L’Ente si riserva comunque la possibilità di modificare il Sistema Informativo di Protocollo Informatico; in tal caso il concessionario dovrà prevedere le attività di nuova integrazione nell’ambito dei servizi di manutenzione adeguativa.
Nell’ambito del processo di gestione di avvisatura per il pagamento di tributi, contributi, tasse e sanzioni nonché per la gestione dei pagamenti previsti per la fruizione di servizi a domanda individuale, sarà prevista l’integrazione interoperabile con le interfacce di cooperazione applicativa rese disponibili dalla piattaforma dei pagamenti del Comune di Napoli denominata “PartenoPay” conforme allo schema nazionale PagoPA.
L’integrazione tra i diversi moduli forniti dal concessionario dovrà essere realizzata in modo da semplificare
e ridurre gli adempimenti a carico dell’utente finale e l’intervento degli operatori di backoffice. A mero titolo
esemplificativo, un’istanza di cambio di residenza lavorata mediante il modulo dei servizi demografici dovrà generare, una volta autorizzata, l’aggiornamento automatico dei dati tributari, così come il pagamento di un tributo dovrà automaticamente generare le relative registrazioni contabili nel modulo dei servizi finanziari.
Saranno oggetto di valutazione dell’offerta tecnica le modalità di integrazione con gli altri sistemi interni ed esterni al Comune di Napoli (SUAP, SUE, Agenzia delle Entrate, Infocamere, Piattaforma Notifiche Digitali, etc.)
5. Monitoraggio e presidio del sistema informativo
La composizione e l’organizzazione del Gruppo di Lavoro, oggetto di valutazione dell’Offerta Tecnica (subcriterio A.1), dovranno essere tali da assicurare un costante monitoraggio dell'intero sistema informatico, un adeguato tuning delle risorse computazionali e un presidio permanente a garanzia della continuità operativa, della sicurezza dei dati e del mantenimento dei livelli di servizio (SLA elencati al paragrafo 4.2.4 del documento “Caratteristiche del servizio e della gestione”, con le relative penali).
Saranno valutate le competenze delle risorse indicate, i miglioramenti (in termini di incremento dei Service Level Agreements) rispetto a quelli contenuti nella proposta a base di gara, nonché le modalità di interfacciamento sia con gli utenti di backoffice che con gli utenti finali (ad esempio le modalità di segnalazione dei malfunzionamenti).
Nelle more dell’entrata in vigore dei decreti del Presidente del Consiglio dei Ministri di cui all’art. 17, c. 5, del decreto-legge 14 giugno 2021, n. 82, convertito, con modificazioni in legge n. 109 del 4 agosto 2021 e sino a quando l’Agenzia per la Cybersicurezza Nazionale (ACN) non avrà predisposto le modalità di presentazione delle domande di qualificazione, ai sensi degli artt.12 e 13 del Regolamento AgID sul “Cloud della PA” [REGOLAMENTO RECANTE I LIVELLI MINIMI DI SICUREZZA, CAPACITÀ ELABORATIVA, RISPARMIO ENERGETICO E AFFIDABILITÀ DELLE INFRASTRUTTURE DIGITALI PER LA PA E LE CARATTERISTICHE DI QUALITÀ, SICUREZZA, PERFORMANCE E SCALABILITÀ, PORTABILITÀ DEI SERVIZI CLOUD PER LA PUBBLICA AMMINISTRAZIONE, LE MODALITÀ DI MIGRAZIONE NONCHÉ LE MODALITÀ DI QUALIFICAZIONE DEI SERVIZI CLOUD PER LA PUBBLICA
AMMINISTRAZIONE (articolo 33-septies, comma 4, del decreto-legge 18 ottobre 2012, n. 179, convertito, con modificazioni, dalla legge 17 dicembre 2012, n. 221)], la suite dovrà essere qualificata su marketplace AgID nella categoria SaaS per i software di gestione dei servizi demografici, finanziari e tributari, integrati in un unico sistema, ai sensi delle Circolari AgID n.2 e n.3 del 2018.
All’entrata in vigore dei suddetti decreti e regolamenti, i servizi garantiti dalla suite dovranno ottenere la qualificazione cloud per la pubblica amministrazione di livello 2 (QC2) (cfr. art. 11 del Regolamento AgID sul “Cloud della PA”), in quanto dovrà essere erogato un servizio digitale classificato come critico ai sensi dell’art.3 del Regolamento AgID sul “Cloud della PA”, nel caso del servizio “DEMOGRAFICI ANAGRAFE” (Tenuta degli atti e dei registri anagrafici della popolazione residente in Italia e dei cittadini italiani residenti all'estero compresi: acquisizione manifestazioni di consenso al trapianto di organi e rilascio di certificati e documenti di identità personale), mentre gli altri servizi erogati sono classificati come ordinari.
Inoltre, la suite dovrà garantire il rispetto dei requisiti di accessibilità previste nelle linee guida WCAG 2.1, così come prescritto da AgID.
La piattaforma dovrà essere realizzata rispettando i criteri definiti da AgID per la realizzazione dei siti e dei portali della PA; in particolare la suite dovrà soddisfare i criteri di User-centered design nonché realizzata in accordo ai kit di Designer Italia.
7. Funzionalità degli applicativi
Per quanto concerne le funzionalità degli applicativi, il documento “Caratteristiche del servizio e della gestione” fa un esplicito richiamo al documento “Progetto di fattibilità”, nel quale il proponente descrive le caratteristiche tecnico-funzionali della suite integrata che intende fornire al fine di garantire la realizzazione dei servizi previsti dallo schema di contratto.
Evidentemente le soluzioni tecniche indicate dal proponente non possono rappresentare un vincolo per gli altri concorrenti; tuttavia, coerentemente con quanto indicato in premessa, le funzionalità descritte ai paragrafi 5.6.2, 5.6.3, 5.6.4, 5.6.5 e 5.6.6 del documento “Progetto di fattibilità” rappresentano il benchmark di riferimento, rispetto al quale tutti i concorrenti (compreso il proponente) sono chiamati a formulare le proprie proposte migliorative.
Si ribadisce, in questa sede, che gli applicativi per i servizi demografici, finanziari e tributari dovranno essere nativamente integrati in un'unica suite (non sono accettate soluzioni che prevedano scambi di dati asincroni tra gli applicativi).
7.1 Funzionalità trasversali Accesso e profilatura degli utenti interni
Gli accessi alla procedura informatica dovranno avvenire tramite l’utilizzo di credenziali di autenticazione
conformi all’art. 64 del Dlgs 7 marzo 2005, n.82 (CAD).
Nell’ambito dell’accesso alla piattaforma per quanto attiene alle componenti di Front-Office l’utenza esterna
dovrà esclusivamente utilizzare i suddetti metodi di autenticazione, conformi alla direttiva eIDAS.
L’accesso ai moduli di back-office dovrà poter avvenire tramite i suddetti meccanismi alle quali sarà affiancato un ulteriore meccanismo di autenticazione “custom” basato su logica di utilizzo di doppio fattore (two factor authentication).
Dovrà essere inoltre garantita una logica di autenticazione unificata per tutti gli utenti interni ed esterni che
accedono alla suite applicativa, secondo la modalità “single sign on”.
In relazione ai meccanismi autorizzatori, ogni utente che accede alla piattaforma dovrà poter utilizzare le funzionalità applicative rese disponibili o sulla base di logiche di ownership o di delega. Tali aspetti afferiscono in particolare ai ruoli implicitamente assegnati dalla Piattaforma agli utenti fruitori dei servizi (utenti esterni).
Riguardo ai meccanismi autorizzatori previsti per gli utenti interni, essi dovranno poter accedere alle funzionalità di back-office sulla base di una opportuna profilatura che è correlata al ruolo svolto all’utente nell’ambito della Organizzazione a cui appartiene. Questo processo di profilatura deve consentire l'assegnazione delle abilitazioni differenziate a livello di singola funzione e, per ciascuna di esse, per singola operazione.
In questo modo si progetta una griglia di abilitazioni con utenze distribuite sulla base di ruoli che identificano fasi del processo produttivo in base alle prerogative organizzative e procedurali assegnate dalla organizzazione.
Questi ruoli permettono l'utilizzazione del software in maniera differenziata (ad es., consentendo operazioni di sola consultazione, di gestione di alcune funzioni, etc.). Queste funzioni devono essere facilmente gestite e monitorate dagli utenti dotati di ruolo di Amministratore di sistema.
Ogni utente, nell'ambito di ciascuna applicazione, dovrà essere posto in grado di operare tramite uno o più "ruoli funzionali".
Parimenti, rispetto ai dati, ogni utente, nell’ambito di ciascuna applicazione, deve poter operare solo sulle informazioni di propria competenza, ovvero "segmenti del database" corrispondenti a processi produttivi assegnati ad unità organizzative o altre aggregazioni organizzative, a cui l'utente appartiene ed è stato formalmente abilitato.
La gestione degli identificativi degli utenti, dei ruoli funzionali, dei gruppi di lavoro, dei profili di autorizzazione e delle informazioni di competenza dovrà essere gestita tramite apposite transazioni di servizio rilasciate da uno o più utenti identificati organizzativamente quali amministratori della suite applicativa.
Le disposizioni dell'amministratore del sistema in merito all'organizzazione dei profili utente sono salvaguardate e dovranno restare valide fino a quando non si decida di modificarle; il sistema dovrà essere comunque corredato da un insieme di profili utente predisposti per le più usuali organizzazioni operative adottate dalla Pubblica Amministrazione nell'ambito di ciascuna applicazione.
Dovrà essere consentito di profilare come utenti interni sia personale dipendente dell’Ente che soggetti esterni debitamente autorizzati (dipendenti delle società partecipate, consulenti, professionisti, etc.)
Tracciamento degli accessi e delle operazioni
La piattaforma dovrà prevedere funzionalità deputate ad assicurare adeguati meccanismi di logging ai fini di audit ed allo scopo di supportate il requisito di accountability delle operazioni effettuate dagli utenti attraverso la stessa.
A mero titolo esemplificativo, il sistema dovrà essere configurato affinché vengano registrati tutti gli eventi generati dalla piattaforma, in primis gli eventi di accessi degli utenti interni ed esterni alle diverse applicazioni; dovranno essere inoltre registrati gli eventi di accesso ed utilizzo delle funzionalità utilizzate nell'ambito di ciascuna applicazione. Dovrà necessariamente essere registrato, per ogni singolo utente, il numero di transazioni di aggiornamento alla base dati effettuate.
Ciò illustrato, a mezzo di un servizio generalizzato e configurabile a livello dell'utente amministratore della suite applicativa, dovranno essere tracciate tutte le azioni riferite a:
• aggiornamenti effettuati su tutta o parte della base dati
• consultazioni di queste informazioni con apposite transazioni di servizio rilasciate all'amministratore del sistema
Il sistema di tracciamento dovrà fornire, per ciascuna operazione effettuata, almeno le seguenti informazioni:
• tipo di operazione;
• data e ora dell’operazione;
• identificativo dell’utente che ha eseguito l’operazione;
• tipologia di utente;
• modulo e funzionalità interessata;
• dettaglio delle eventuali variazioni apportate;
• postazione dalla quale è stata effettuata l’operazione.
Il sistema di logging usato ai fini di audit ed accountability delle operazioni dovrà al minimo sosddisfare requisiti di:
• pseudonimizzazione delle informazioni tracciate;
• non modificabilità dei dati e delle informazioni tracciate.
Amministrazione della piattaforma
La suite applicativa dovrà prevedere un modulo gestionale tramite il quale gli utenti individuati come Amministratori responsabili dell'Amministrazione generale dell'Ente e/o dell'intera suite applicativa provvederanno ad una serie di funzioni per la definizione e gestione:
• degli identificativi degli utenti,
• dei ruoli funzionali,
• dei gruppi di lavoro,
• dei profili di autorizzazione
• dello stato degli utenti (es. bloccato, sospeso, attivo)
Le informazioni di competenza saranno gestite tramite apposite transazioni di servizio rilasciate all'amministratore del sistema.
Le autorizzazioni dovranno poter essere associate a livello di singolo utente, di ruolo o di gruppo.
I livelli di autorizzazione dovranno avere una granularità associata alla singola micro-funzionalità del sistema ed ai relativi attributi rilevanti.
A titolo meramente esemplificativo, un utente appartenente o meno ad un gruppo, dovrà poter essere
profilato ai fini dell’accesso a funzionalità tramite GUI, non solo per poter visualizzare o meno un’intera
pagina ma anche un singolo controllo ivi presente. Inoltre, in base alla tipologia di controllo, lo stesso potrà essere abilitato, disabilitato, reso visibile o meno, selezionabile o editabile.
In tal modo sarà assicurato il rispetto di una logica autorizzativa role-based a livello di microservizio.
• Possibilità di effettuare operazioni di ricerca e di interrogazione sugli archivi partendo da una o più informazioni facenti parte del database stesso;
• Possibilità di effettuare stampe di utilità con ampia possibilità di intervento da parte dell'utente nella determinazione dei campi da stampare, degli ordinamenti, delle totalizzazioni parziali, etc. (stampe parametriche);
• Possibilità di poter codificare in forma tabellare le informazioni ricorrenti.
Inoltre, il software dovrà disporre di un modulo comune a tutto il sistema informativo che consenta la creazione e l'estrazione di tabulati e schede di dati in grado di:
• Eseguire appropriate selezioni attraverso l'utilizzo di uno o più campi appartenenti a qualsiasi archivio gestito;
• Utilizzare per le selezioni qualsiasi campo tra quelli gestiti dalla procedura;
• Permettere ordinamenti in base ad uno o più campi;
Di seguito si riporta un elenco delle funzionalità minime degli applicativi (suddivisi per Area).
7.2 Funzionalità degli applicativi di Contabilità e Xxxxxxxx
• contabilità finanziaria;
• gestione ordinativi;
• contabilità generale economico patrimoniale;
• contabilità analitica;
• gestione mutui;
• cassa economo;
• fatturazione attiva;
• fatturazione passiva;
• bilancio consolidato.
• dichiarazioni fiscali;
• IVA – Prima nota;
Per i seguenti applicativi, che non rientrano nella sfera di responsabilità del Dipartimento Ragioneria, il sistema informativo fornito dal concessionario deve garantire l’interconnessione:
• Inventario Beni;
• Economato;
• Elenco e programma dei LLPP e dei beni/servizi (per DUP);
• Trattamento economico del personale.
Puntualizziamo, di seguito, alcune funzioni indispensabili, che l'applicativo deve necessariamente garantire:
• Possibilità di aggiungere, modificare e cancellare informazioni sugli archivi interessati attraverso programmi supportati da adeguati controlli interattivi;
Proprietà dei dati
Dovrà essere garantito l'accesso alla base informativa, ciò al fine di consentire al nucleo di operatori appartenenti al Servizi del Dipartimento Ragioneria l'estrapolazione -in maniera puntuale e autonoma -delle informazioni necessarie per effettuare analisi dei dati contabili attraverso la costruzione di "reportistica" specifica e costruita in loco, su input delle diverse necessità dell'Ente.
Relativamente all'interscambio di informazioni con procedure esterne, dovrà essere garantito il WebServices e i protocolli di comunicazione standard (tipicamente XML) al fine dell’integrazione di alcune funzionalità del prodotto all'interno di iter procedurali (Workflow).
La procedura di aggiornamento del software applicativo dovrà esser molto semplice, studiata per essere utilizzata anche da personale non tecnico. La suite applicativa dovrà gestire e supportare la modalità multi- ente senza alcuna limitazione né tecnologica, né commerciale.
Caratteristiche generali
Continuità Gestionale
Devono essere presenti -a pena di esclusione -in linea (consultabili dagli utenti registrati) gli esercizi dal 1996 ad oggi, e si deve garantire il mantenimento in linea degli esercizi precedenti a quello in corso di gestione, con accessi e modalità operative differenziate per gli utenti abilitati affinché si possano effettuare operazioni di gestione sull'esercizio in corso e su quello precedente (fino all'approvazione del consuntivo). Le operazioni di interrogazione possono essere effettuabili su qualsiasi esercizio archiviato.
Integrazione
Un requisito indispensabile è l'integrazione totale con il modulo di gestione finanziario che deve consentire l'acquisizione automatica di documenti contabili provenienti da altre procedure esterne, attraverso opportuni file di scambio o altre modalità. In particolare, la procedura deve consentire le seguenti operazioni:
• contabilità finanziaria autorizzatoria;
• contabilità economico patrimoniale, tenuta in partita doppia, con la produzione del conto economico e del conto del patrimonio;
• contabilità analitica per centro di costo.
Ovviamente i documenti programmatici ed il rendiconto devono colloquiare con il sistema ministeriale BDAP,
secondo la normativa vigente e l’eventuale sua evoluzione.
Integrazione e compatibilità con gli strumenti di Microsoft Office che permettono di esportare i report e le ricerche effettuate, in formati quali excel, word, html, pdf, xml, etc.
In questo modo, l'integrazione dei moduli (anagrafe dei debitori e creditori, capitoli, conti, centri di costo, fattori produttivi, classificazioni), consentirà all'Ente di evitare inutili ripetizioni nell' inserimento dei dati e allo stesso tempo consentirà la condivisione dei dati nello stesso archivio. Integrazione col sistema del patrimonio e degli approvvigionamenti (ordini, acquisti, consegne, riscontri, liquidazioni) per il controllo della disponibilità ad ordinare sugli impegni e la liquidazione dei beni o servizi forniti, con la gestione economica del personale (imputazione contabile delle voci di competenza e delle ritenute, produzione automatica dei mandati di pagamento), con la gestione di delibere e determinazioni, per la registrazione automatica di impegni e liquidazioni e con i sistemi di firma elettronica dei mandati e delle reversali.
Contabilità Economica e Analitica e Configurabilità del piano dei conti della contabilità finanziaria e della contabilità economica ed analitica
1. Il sistema deve gestire il piano dei conti e di tutte le attività connesse alla contabilità economica ed analitica;
2. Generazione automatica delle registrazioni di contabilità economico-patrimoniale ed analitica a partire dalle transazioni finanziarie, in particolare secondo il seguente schema di massima:
a. Possibilità di inserire il conto dare ed avere: 1) nell' anagrafica del capitolo/articolo 2) nell' impegno/accertamento 3) nei documenti contabili attestanti l'entrata o spesa (es. fattura)
b. Possibilità di scelta di creazione automatica delle scritture di contabilità economico- patrimoniale ed analitica da: 1) movimenti finanziari di impegno e accertamento; 2) movimenti finanziari di liquidazione; 3) movimenti finanziari di emissione mandato di pagamento e ordinativo d'incasso; 4) documenti contabili (es. fattura)
3. Nell'anagrafica del capitolo/articolo di previsione deve essere possibile indicare il conto di rilevazione del costo (o ricavo) o di variazione patrimoniale;
4. Nelle transazioni di registrazione accertamenti/impegni e documenti contabili (fatture o altri documenti attestanti entrate o spese) deve potersi indicare il periodo di competenza economica;
5. La gestione dei movimenti economico-patrimoniali, indipendentemente dalla creazione (automatica da movimenti finanziario con registrazione manuale dell'operatore), deve poter essere resa autonoma dalla contabilità finanziaria e gestita in modo libero dall'ufficio di controllo di gestione;
Ai capitoli ed ai conti devono essere liberamente attribuibili codici di classificazione per rappresentarne le più diverse caratteristiche, anche non definibili preliminarmente (natura, commessa, programma, rigidità della spesa, etc.). I codici devono poter essere liberamente utilizzati secondo i criteri tipici dell'analisi multidimensionale: creazione di gerarchie fra di essi, interrogazione su schermo ed in stampa secondo le diverse gerarchie create.
Un requisito indispensabile del sistema deve essere la configurabilità della struttura organizzativa su due o più livelli gerarchici (attualmente abbiamo Livello 1: Aree-Dipartimenti e Livello 2: /Servizi identificativi dei Centri di Responsabilità). Possibilità di generare automaticamente la movimentazione della Contabilità economica ed analitica contestualmente alle transazioni della Finanziaria. Le scritture di partita doppia così generate devono essere configurabili parametricamente in base alle esigenze dell'Ente.
La contabilità analitica deve essere intesa come disaggregazione degli eventi contabili di natura economico-- patrimoniale ma anche finanziaria (impegni, liquidazioni e mandati), per attivare un processo di lettura gestionale degli stessi, dalla rilevazione dell'incidenza dei singoli centri di responsabilità, alla valorizzazione delle prestazioni e dei servizi erogati; Decentrare ai Settori esterni funzioni di consultazione (possibilità di analisi dei dati contabili con diverse modalità di visualizzazione e di lettura e con la possibilità di accedere ai
soli dati di propria pertinenza) ma anche di immissione dati (ad es. la liquidazione tecnica), a tal proposito l'amministratore di sistema deve avere la possibilità di parametrizzare le abilitazioni degli operatori non solo per funzione e operazione, ma anche in funzione dei Centri di Responsabilità di riferimento, in modo che le funzioni decentrate utilizzate dai funzionari amministrativi dei vari Settori dell'Ente operino solo sui dati di competenza (Peg Contabile per Cdc).
Bilancio e Consuntivo
Predisposizione in varie modalità dei bilanci di previsione tramite ribaltamento delle previsioni definitive del bilancio in corso (al momento in cui si genera la bozza del bilancio di previsione), tramite ribaltamento dal bilancio pluriennale, ovvero attraverso input da parte dei singoli servizi che dovranno accedere in una partizione ai loro capitoli tramite i codici di classificazione e dopo una attenta verifica da parte del servizio Programmazione e Rendicontazione verranno ribaltati in contabilità.
Realizzazione delle stampe ufficiali del documento contabile di programmazione in ossequio alla normativa vigente. Inoltre la procedura deve consentire di effettuare rilevazioni contabili di tipologia diversa dalle elaborazioni ufficiali, ma funzionali alle esigenze di conoscenza dei fenomeni contabili dell’Ente, attraverso l’ausilio della costruzione di specifiche classificazioni che, attraverso codifiche particolari, creano raggruppamenti mirati di dati contabili per successive estrapolazioni; l’interrogazione mirata del database, che quindi non può prescindere dall’essere di natura relazionale (es. Oracle) magari attraverso la costruzione di proiezioni/viste virtuali sul medesimo, senza intervenire in alcun modo sul dato contabile contenuto, deve poter consentire l’analisi puntuale della situazione contabile reale, distinta per centro di responsabilità, ai fini di una più coerente programmazione soprattutto della spesa rispetto alle risorse effettive.
La codifica armonizzata del bilancio in tutti i suoi aspetti elementari o meno deve poter essere mezzo di rilevazione immediata dei fenomeni e la parallela ricodifica dei dati contabili, laddove se ne ravvede la necessità, in classificazioni specifiche con una architettura rispondente gerarchicamente alla struttura organizzativa dell’Ente, deve inoltre poter consentire agli Amministratori in primis ed ai responsabili dei servizi comunali di avere in tempo reale il quadro dell’azione svolta.
La naturale conseguenza è la possibilità di ottenere tutti i report del bilancio in diversi formati, formato stampa (pdf), in formato testo (word), html, e per il monitoraggio della previsione e della gestione in formato elettronico (excel).
Nella predisposizione del bilancio sarebbe opportuno gestire l’acquisizione dei dati contabili derivanti dalle richieste dei servizi in maniera automatica, riservandosi l’Ente poi della compatibilità degli stanziamenti proposti rispetto alle risorse disponibili ed agli equilibri di bilancio.
È necessario uno stretto collegamento con il piano delle opere pubbliche già nella fase di iscrizione in bilancio, senza dover tenere un doppio archivio non comunicante, in modo che se viene inserito un investimento immediatamente confluisce nel DUP nei casi in cui è previsto, ed ogni eventuale variazione si rileva contestualmente.
Nella fase di predisposizione del bilancio, la gestione dell’esercizio provvisorio deve colloquiare in termini di avvertimento della presenza di accertamenti già in corso e/o impegni e prenotazioni, considerando altresì l’ipotesi di variazioni prima dell’approvazione definitiva del medesimo secondo la normativa vigente.
Particolare attenzione va fatta alla gestione della cassa vincolata, derivante da finanziamenti di legge che deve essere gestibile in modo da rilevare e far confluire immediatamente le movimentazioni relative in modo da impedire regolarizzazione diverse da quanto consentito dalla norma, allo scopo di fornire in tempi brevissimi la copertura delle rilevazioni contabili riferibili. A tal riguardo si ritiene indispensabile la rilevazione dal codice di bilancio, attraverso flag specifici, della codifica di quelle spese ricomprese tra i servizi indispensabili e quelle derivanti da finanziamenti di legge in modo da gestire nella fase di liquidazione la priorità dei pagamenti.
GESTIONE CAPITOLI DI ENTRATA E SPESA VINCOLATI:
Estrazione di file che consentono, attraverso un codice identificativo del finanziamento, il confronto tra capitolo di entrata vincolata, con dati di previsione e accertamenti e correlati ai capitoli di spesa, con previsione a competenza, impegnato, previsione reimputata e impegni relativi da FPV;
Estrazione di file che consentono il confronto tra capitolo di entrata vincolata, con dati di previsione e accertamenti e correlati capitoli di spesa, con previsioni di spesa, impegni a risorse, impegni reimputati FPV e previsioni;
Gestione dei residui conservati: estrazione di dati relativi ai residui attivi e passivi, raggruppati per anno di provenienza dei residui, per titolo, capitolo e codice di bilancio;
FCDE:
Gestione calcolo FCDE nel bilancio di previsione e nel rendiconto: possibilità di inserimento di calcolo del FCDE per classe di entrata (cluster), sulla base di una classificazione inserita dall'utente;
ALLEGATI A RENDICONTO: possibilità di importare file excel nella procedura.
Codifica gestionale
Per quanto attiene la codifica gestionale, sviluppata obbligatoriamente nella parte dei movimenti contabili, il sistema deve dare la facoltà di agganciare codici SIOPE sulle voci di bilancio in maniera tale da veicolare un meccanismo (aggiornabile e forzabile) di ereditarietà ai livelli inferiori (accertamenti/impegni ed in seguito reversali/mandati). Inoltre, si devono ottenere stampe di verifica e controllo connesse alle codifiche gestionali sia in Bilancio che sui Movimenti Contabili.
Equilibri di bilancio
Il sistema deve generare le stampe ufficiali, che verificano gli equilibri principali del Bilancio previsti sia in fase di programmazione, sia di assestamento, sia di rendiconto; inoltre deve essere prevista l'impostazione di Quadri al Bilancio per realizzare diversi sistemi di equilibrio e monitoraggio sull'andamento del Bilancio, sia in fase di budget e programmazione, che soprattutto, in fase di consuntivazione, abbracciando oltre agli stanziamenti attuali, le movimentazioni effettive del mastro.
Gestione Accertamenti, Impegni e prenotazioni
Gestione delle prenotazioni d'impegno in maniera analoga agli impegni, essendo oggetto, in taluni casi specifici, quali quelli dei finanziati, di trasferibilità per esigibilità con l’utilizzo dello strumento Fondo Pluriennale Vincolato; ovviamente devono essere garantite le variazioni di accertamenti, prenotazioni e impegni collegate ad atti formali autorizzativi, mantenendo l'evidenza storica delle variazioni effettuate; fondamentale è la gestione dei vincoli sugli impegni ed accertamenti per ciò che concerne le partite vincolate (finanziati) e le partite di giro secondo automatismi imposti dall'utente.
Fatturazione
La gestione delle fatture attive deve rispecchiare la suddivisione per servizi e sezionali all’interno della macrostruttura e quindi con codici identificativi univoci rilasciati dall’IPA (indice pubbliche amministrazioni)
Nell’ambito della fatturazione passiva fondamentale è la data di scadenza della fattura che all’atto dell’importazione nelle scritture contabili dell’Ente deve essere riportata in automatico per consentire il calcolo ed il rispetto dei termini di pagamento previsti dalla norma.
Nell’importazione delle fatture nell’applicativo deve essere incluso il fuori campo iva o esente Iva e così pure nella registrazione di una fattura con ritenuta d’acconto o fuori campo IVA il sistema deve verificare in automatico la coincidenza del totale voci con il totale fattura.
Avvalendosi allo stato il sistema contabile dell’Ente di una Società intermediaria nella veicolazione delle fatture sia attive che passive e della loro archiviazione, la nuova architettura dovrà necessariamente interfacciarsi con tale applicativo predisponendo quanto necessario per un eventuale subentro.
Liquidazione della spesa
Fermo restando le tecniche abituali di registrazione delle liquidazioni, con tutti i suoi principi e modalità, e riallacciandosi a quanto segnalato nella sezione BILANCIO, il sistema deve avere la possibilità di elaborare l’elenco delle liquidazioni non ancora pagate nel senso delle distinzioni tra servizi indispensabili e non e finanziati in modo da stabilire le relative priorità.
Mandato di pagamento.
Importanza fondamentale nell’emissione dei mandati è il collegamento, laddove il caso, con la cassa vincolata in modo da veicolarne direttamente l’erogazione, senza l’intervento manuale dell’operatore, al fine di evitare frequenti e successive regolarizzazioni diverse da quelle consentite e previste dalla norma.
La gestione della trasmissione dei mandati in tesoreria attualmente avviene tramite la tesoreria di Banca
Intesa con l’ausilio dell’applicativo Unimoney della Società Unimatica.
Sistema delle riclassificazioni della contabilità
Un requisito indispensabile del sistema è quello di gestire per tutti i suoi moduli (bilancio, movimenti contabili, IVA, mutui, cassa economale, ...), un sistema molto evoluto di riclassificazioni che consente di impostare l'evidenza di fenomeni contabili per i quali non sono previste specifiche funzioni.
In particolare, ad ogni entità del modello può essere data una riclassificazione ad hoc, l'amministratore di sistema deve avere la possibilità di:
• definire una codifica di riclassificazione (tipo di riclassificazione e codici ad esso attribuiti) e legare la medesima ad una o più entità (es. definisco la riclassificazione per "tipo spesa", formo il suo piano di codifica in termini di codice e di descrizione e collego la riclassificazione alle entità documenti, impegni, liquidazioni, mandati, accertamenti, reversali)
• rilevare i codici di riclassificazione opportuni alla ricorrenza dell'entità a cui il tipo è stato attribuito (es. in gestione impegni e in gestione liquidazioni e in gestione mandati posso rilevare il codice dei tipi spesa attinenti al movimento corrente)
• ottenere dal sistema l'evidenza (analitica e sintetica), come interrogazione a video e come stampa, delle entità riclassificate e dei totali per ogni riclassificazione.
7.3 Funzionalità degli applicativi per i Servizi demografici e statistici
Il sistema destinato alla gestione dei servizi demografici e statistici dovrà garantire l’aderenza alle normative
vigenti, a partire dalla fase di start-up e per tutta la durata dell’affidamento.
Le tecnologie utilizzate dovranno garantire, dal punto di vista delle prestazioni, tempi di elaborazione ragionevoli e tempi di risposta rapidi, che rendano l’esperienza dell’utente (user-experience) fluida e soddisfacente, rispettando, tra gli altri, i requisiti di:
- Immediatezza;
- Facilità d’uso, grazie ad interfacce chiare e corredate da aiuti in linea (tooltip, guide in linea, alert,
faq);
- Consistenza;
- Affidabilità;
- Accessibilità, che prevede la fruibilità, senza discriminazioni, anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o configurazioni particolari1.
Il sistema informativo demografico-statistico, in particolare, dovrà rendere disponibile il dato agli endpoint interessati e recepire, ove previsto, le informazioni provenienti da fonti esterne che andranno ad arricchire il dato anagrafico.
L’accesso puntuale ai dati anagrafici da parte di servizi esterni al contesto applicativo in essere deve avvenire sempre mediante interrogazione di servizi web. Differenti scelte architetturali saranno valutate negativamente e accettate solo a fronte di una specifica esigenza funzionale che preveda un accesso massivo o un contenuto informativo tale da ritenere la comunicazione mediante web-service limitante, ovvero peggiorativa.
Gli ambiti di intervento possono essere raggruppati nelle seguenti macroaree:
- Anagrafe;
- Stato civile;
- Elettorale;
- Toponomastica;
- Statistica;
- Adempimenti collegati (leva militare, colloquio con le forze dell’ordine, trasmissione elenchi alla
ASL, ecc.).
L’utente finale si distingue in due categorie principali:
1 Alla data di pubblicazione del presente documento si fa riferimento alle Web Content Accessibility Guidelines 2.1
- Operatore di backoffice: tipicamente un dipendente dell’Ente preposto ad attività di istruttoria
(inserimento dati), consultazione ed elaborazione;
- Utente internet: tipicamente un fruitore dei servizi destinati al cittadino, quali:
o Consultazione;
o Certificazione;
o Interazione con l’Ente che consente di sottoporre istanze personali (richiesta di cambio di
residenza, rettifica dei propri dati e tutto quanto previsto dalla normativa vigente che
consente l’invio di istanze telematiche).
Nell’ambito di ciascuna classe di utenza dovrà essere prevista una specializzazione, grazie all’attivazione di profili ad hoc che abbiano più o meno privilegi, a seconda della funzione e della mansione svolta. In particolare, per gli operatori di backoffice, dovrà essere prevista la figura dell’amministratore di sistema: un utente appartenente all’ente che avrà la responsabilità di creare profili, differenziati in base alle funzionalità accessibili, abilitare operatori e, a sua volta, nominare altri amministratori che possano coadiuvarlo.
Per la creazione degli utenti e l’implementazione dei rispettivi profili occorrerà prevedere un’integrazione
con la banca dati dei dipendenti comunali, che preveda la possibilità di recepire informazioni quali:
- Generalità, ivi compreso l’indirizzo di posta elettronica istituzionale;
- Matricola;
- Qualifica;
- Dipartimento/Area e Servizio di assegnazione;
- Data cessazione del rapporto di lavoro.
In alternativa, l’attivazione dell’accesso al sistema demografico erediterà le informazioni di cui sopra dal sistema di SSO centralizzato, andando a popolare la scheda informativa dell’utente, propedeutica alla gestione dei profili e delle funzionalità interne.
Vista la natura delle attività nelle quali gli operatori saranno impegnati, si ritiene opportuno prevedere, quantomeno a valle dell’accesso in SSO, un ulteriore livello di sicurezza, da implementare mediante erogazione di smart-card personalizzata o OTP (a cura degli amministratori di sistema incaricati dall’Ente). Le funzionalità minime da garantire sono di seguito elencate:
⮚ ANAGRAFE
o Certificazione: emissione, configurazione parametri e dizionari;
o Carta di identità: rilascio, gestione ostative, parametri di stampa, gestione carichi, elenchi e riepiloghi, gestione avvisi di scadenza, gestione nulla osta, SIT – comunicazione donazione organi, consultazione e gestione cartellini;
o Istruttorie: Iscrizioni APR, Cancellazioni APR, Cambio abitazione, Unione/Scissione Famiglie, Scadenzario, Foglio di via, Divieto di emigrazione, Convivenze di fatto, Ricomparsa in altro comune, Registro popolazione temporanea;
o Gestione AIRE: Iscrizione, Cancellazione, Variazione recapito;
o Gestione temporanei: Iscrizione, Cancellazione, Verifica dimora temporanea;
o Variazioni anagrafiche: Atti da stato civile, Iscrizione per nascita, Cancellazione per decesso, Matrimonio, Divorzio, Unione civile, Scioglimento unione civile, Cittadinanza, Generalità, Parentela, Titolo di studio, Professione, Documenti vari (C.I., Patente, Passaporto, Pensioni), Documenti comunitari (Attestazione iscrizione anagrafica, Attestazione soggiorno permanente, Gestione allegati), Documenti extracomunitari (Permesso di soggiorno, Permesso di soggiorno di lungo periodo, Carta sogg. Fam. Citt. UE, Carta sogg. Fam. Citt. UE permanente), Situazione extracomunitari e avvisi, Variazione indirizzi massiva, Gestione comunicazione variazioni anagrafiche;
o Tutte le attività correlate alla gestione della scheda del cittadino, da intendersi come il fascicolo anagrafico che comprende:
▪ Generalità;
▪ Famiglia;
▪ Residenza
▪ Documenti di riconoscimento e di altro genere (eventualmente acquisiti digitalmente);
▪ Storico Movimenti (variazioni intercorse all’interno della scheda);
▪ Storico Residenze-famiglie;
▪ Visura ANPR;
▪ Titolo di studio;
▪ Recapiti e domicilio digitale;
▪ Atti di stato civile collegati;
▪ Collegamento con parentela diretta, anche se non appartenente allo stesso nucleo familiare (genitori e figli eventuali).
o Adempimenti collegati alla leva militare e ruoli matricolari;
o Tutte le attività correlate alla gestione delle comunicazioni da e verso ANPR, compresa la gestione delle notifiche provenienti da altri comuni.
⮚ STATO CIVILE
o Certificazione: diritti;
o Nascita: gestione atti, sintetici e annotazioni e relative stampe di elenchi e comunicazioni;
o Pubblicazioni di Matrimonio e Atti di Matrimonio: gestione degli adempimenti preliminari, redazione atti, verbali di pubblicazione, sintetici e annotazioni, registrazione annotazioni divorzi, relative stampe (elenchi e comunicazioni, deleghe matrimonio, avviso celebrato matrimonio concordatario, registro annotazioni divorzio);
o Morte: gestione atti, sintetici e annotazioni, relative stampe di elenchi e comunicazioni, gestione degli adempimenti funerari e della comunicazione decessi casellario;
o Cittadinanza: atto, attestazioni/accertamenti, sintetici e annotazioni, attributi cittadinanza, stampe di elenchi e comunicazioni (anche relative ai cittadini stranieri);
o Unioni civili: gestione del registro provvisorio e delle richieste, stampe elenchi annotazioni e comunicazioni;
o Disposizioni Anticipate di Trattamento DAT: adempimenti preliminari, registro DAT, documentazione successiva;
o Indici: nascita e morte, pubblicazioni di matrimonio e matrimonio, unioni civili, cittadinanza, atti memorizzati;
o Sezione dedicata alle statistiche comprensiva di Modelli Istat.
⮚ ELETTORALE
o Consultazione scheda elettorale;
o Gestione delle liste;
o Elenco variazioni delle liste;
o Gestione dei fascicoli (stampa, azzeramento, ricompilazione);
o Tutte le attività relative alla gestione delle revisioni che comprendono:
▪ Gestione revisioni semestrali e relativi modelli;
▪ Gestione revisioni dinamiche e relativi modelli;
▪ Gestione revisioni straordinarie (Depennati minore età, Elettori solo camera, Depennati Req. Residenziale L.A., Elettori Aire vota estero, Iscrizioni per motivi diversi, Blocco liste);
▪ Gestione fasi preparatorie delle revisioni (Controlli pre-revisioni, Preparazione revisioni, Controlli su iscrivendi/cancellandi, Altri comuni al voto, Importazione 3/D XML, Domande liste aggiunte);
▪ Multielezioni (Apertura multielezioni, Depennati minore età, Elettori solo camera, Elettori Aire vota estero, Iscrizioni per motivi diversi, Chiusura) ;
▪ Penale (Inserimento interdizioni, Scadenzario penale, Richieste penali);
o Tutte le attività riguardanti le consultazioni elettorali che comprendono:
▪ Dati generali consultazioni;
▪ Sottoscrittori di lista;
▪ Rilevazione elettori;
▪ Nomina dei componenti dei seggi (Presidenti, Scrutatori, Xxxxxxxxx, Scrutatori speciali (Sicilia), Scrutatori sezioni estere);
▪ Stampe/Pubblicazioni (Convocazione comizi elettorali, Trasporto su chiamata, avvisi agli elettori)
▪ Richieste elenchi elettori;
▪ Certificato massivo iscrizioni liste;
▪ Gestione omessi;
▪ Voto extracomunitari (Domande, Sezioni e liste, Revisioni elettorali);
▪ Sottoscrittori (Partiti e liste, Pacchi, plichi e fogli, Candidati, Sottoscrittori, Monitoraggi);
o Le attività correlate alla gestione delle tessere che comprendono:
▪ Situazione tessere (Stampa di controllo, Elettori privi di tessere, Controllo AVD);
▪ Stampe (Notifiche, Comunicazione al cittadino, Tagliandi di convalida, Registro tessere);
▪ Assegnazione e gestione tessere;
▪ Xxxxxxx xxxxxxx;
▪ Controllo anomalie tessere;
o Gestione degli albi:
▪ Albo scrutatori (Gestione domande, Revisione e stampa albo);
▪ Albo Pres. di seggio (Gestione domande, Cancellazione, Iscrizione, Stampa albo);
▪ Albo Giudici Popolari (Gestione domande, Revisione e stampa albo);
▪ Albo speciale scrutatori (Sicilia): (Gestione domande, Revisione e stampa albo).
Sono inoltre da considerare quali requisiti minimi le seguenti feature trasversali agli adempimenti nei rispettivi ambiti di applicazione:
• Cruscotto di monitoraggio per le comunicazioni ANPR, con elaborazione di statistiche per tipo di comunicazione sull’esito e sulla natura delle stesse, con possibilità di intervenire puntualmente e massivamente su queste per rielaborarle, anche mediante trasmissioni programmate;
• Cruscotto di statistiche predefinite sulla scorta dei dati rilevanti per ISTAT e sulla scorta delle informazioni necessarie al monitoraggio della produttività per ciascuna sede/municipalità (secondo template predefiniti):
o Istruttorie Anagrafiche;
o Certificati rilasciati;
o Atti di stato civile suddivisi per tipologia;
o Carte d’identità emesse;
o Tessere elettorali rilasciate;
o Tempi medi procedimentali per ciascuna tipologia di istruttoria.
• Possibilità di implementare report custom utilizzando query dirette/cubi multidimensionali/indicatori;
• Integrazione nativa con protocollo e sistema Office 365, possibilità di invio e ricezione PEC per movimentazioni anagrafe (compresi invii 3/D XML);
• Gestione scheda anagrafica integrata con ANPR e con altre fonti di dati per confronto/integrazione (catasto, motorizzazione, AE – anche per il tramite di ANPR – questura);
• Integrazione con sistema gestionale dei tributi che renda sempre disponibile la lettura del dato anagrafico e della storicità delle variazioni occorse;
• Funzionalità di elaborazione e trasmissione periodica (customizzabile) dei dati sulle carte di identità
e sui decessi ai soggetti interessati (questura e forze dell’ordine);
• Prevedere una funzionalità di matching tra le CIE registrate nel sistema e il database del Ministero
dell’Interno, fornendo un riscontro sia puntuale che basato su un quantum;
• Gestione delle comunicazioni a Prefettura e Ministero dell’Interno relativamente agli adempimenti elettorali; implementazione della pubblicazione su portale comunale di partiti e liste, compresi i simboli, per le elezioni amministrative.
Mediante un front-end esposto via internet (servizi demografici verso l’esterno) dovranno essere fruibili i
seguenti servizi:
• Implementazione di interfaccia internet per accesso a dati anagrafici limitati da parte di soggetti terzi agli uffici demografici comunali: altri servizi interni al comune, forze dell’ordine, avvocati e soggetti convenzionati (es: edicolanti o tabaccai).
• Implementazione di interfaccia per cittadino per prenotazione appuntamenti agli sportelli (principalmente rivolto alle CIE), integrata con PagoPA;
• Accesso telematico per i soggetti autorizzati all’invio della documentazione necessaria per le
denunce di morte, con gestione del workflow da parte dell’operatore di stato civile;
• Implementazione di un’interfaccia destinata alle dichiarazioni di nascita, sia da parte degli attori istituzionali che del singolo cittadino, con gestione del workflow da parte dell’operatore di stato civile;
• Gestione dei cambi di residenza online sottomessi tramite ANPR con conseguente smistamento per
municipalità di competenza all’interno del sistema intranet;
Notevole rilievo, inoltre, assume l’esposizione dei servizi su Mobile (Android, iOS):
- Integrazione con App IO, mediante l’invio di notifiche al cittadino e/o ai contribuenti, sulla scorta dei
servizi già implementati;
- Adattamento dei servizi esposti via internet alle piattaforme Mobile, preferibilmente implementando un’app dedicata o integrando i servizi in una app dell’Ente che possa fungere da wrapper (contenitore).
7.4 Funzionalità degli applicativi per i Servizi tributari
• Gestione della tassa di smaltimento dei rifiuti;
• Gestione Imposta Municipale Propria;
• Gestione Canone Occupazione Suolo ed Aree Pubbliche e sua evoluzione normativa;
• Analisi e controllo della riscossione mediante ruoli;
• Interrogazioni Catastali;
• Sportello Telematico;
• Gestione contenzioso;
• Gestione MUI;
• Imposta di soggiorno;
• Indagini Fiscali;
• Imposta affissioni e pubblicità e sua evoluzione normativa.
Con riferimento alle funzionalità sopra elencate, si considerano requisiti minimi degli applicativi quelli analiticamente descritti nei paragrafi 5.6.3 e 5.6.4 del documento “Progetto di fattibilità” predisposto dal proponente, con le seguenti puntualizzazioni:
a) il cosiddetto “Portale del contribuente” dovrà rappresentare il principale canale di interlocuzione tra il soggetto esterno, cittadino o impresa, e gli uffici tributari dell’Ente. Esso dovrà consentire la presentazione di tutte le tipologie di istanze indirizzate ai servizi tributari, che unitamente agli atti ed ai provvedimenti prodotti dagli uffici, andranno ad alimentare il “Fascicolo digitale del contribuente”.
Il “Fascicolo digitale del contribuente” deve essere basato su un motore documentale in grado di:
● definire, per ogni procedura, l’iter che l’istanza deve seguire, unitamente agli uffici e agli utenti
abilitati ad operare;
● assegnare a ciascun utente un “livello di autorità” e le conseguenti autorizzazioni. Ciò implica, tra l’altro, la necessità di definire i diritti di accesso degli utenti agli archivi, limitandoli ai documenti di loro competenza;
● monitorare, in ogni istante, i documenti e il loro stato di avanzamento, attraverso interrogazioni parametrabili (per assegnatario, per tipologia, per data, etc.);
● organizzare i documenti in modo autonomo, comodo, flessibile ed efficiente, con la possibilità di definire a piacere contenitori logici dei dati archiviati (i "volumi virtuali"), a cui associare i documenti (o loro sottoinsiemi) contenuti in uno o più volumi fisici dell'archivio. Ciascun utente potrà disporre della propria "vista personalizzata" sugli archivi.
b) Il software per la gestione del contenzioso tributario dovrà garantire la piena integrazione sia con il sistema SIGIT per la gestione del Processo Tributario Telematico che con gli altri applicativi verticali forniti dal concessionario. L’applicativo dovrà prevedere l’aggiornamento in tempo reale del “Fascicolo digitale del contribuente” e la gestione delle spese di giudizio.
c) L’applicativo per la gestione della riscossione coattiva (tributaria ed extratributaria) deve consentire l’estrazione puntuale e massiva delle “informazioni di ritorno” (pagamenti, istanze, sgravi, contenzioso e stato di evoluzione, azioni esecutive e stato progressivo, stato della riscossione ecc.). Anche questi dati devono essere riportati nel “Fascicolo digitale del contribuente”.
d) Per l’accesso al “Portale del contribuente” dovrà essere prevista la possibilità di un accesso multiutente, che consenta ad un soggetto (ad esempio un professionista), munito di adeguate deleghe ed autorizzazioni, di operare per conto di più contribuenti.
e) L’applicativo per la gestione dell’Imposta di soggiorno dovrà prevedere la possibilità che le dichiarazioni vengano effettuate anche da soggetti intermediari (ad esempio Xxxxxxx.xxx o AirBNB), nel rispetto di quanto previsto dalla normativa e dalle convenzioni stipulate dall’Ente con i soggetti intermediari.
f) Il sistema dovrà prevedere che gli operatori di backoffice, oltre alla possibilità di effettuare stampe ed estrazioni di dati in maniera semplificata e parametrizzabile, abbiano la possibilità di accedere al database tributario per interrogazioni ed aggiornamenti massivi dei dati. Gli utenti dovranno essere preventivamente autorizzati e le operazioni adeguatamente tracciate.
g) Il “Portale del contribuente” e gli applicativi per la gestione del Canone Unico Patrimoniale e del Canone Mercatale dovranno prevedere che le istanze possano essere acquisite attraverso il Portale e lavorate direttamente dagli uffici concessori, competenti al rilascio del provvedimento amministrativo.
h) La presentazione delle istanze attraverso il “Portale del contribuente” dovrà consentire la generazione di un flusso di dati in grado di alimentare in maniera automatica il database tributario. L’effettivo aggiornamento del database potrà avvenire previa autorizzazione puntuale dell’operatore di backoffice e/o mediante una verifica (automatizzata e parametrizzabile) relativa alla congruità dei dati inseriti.
8. SLA (Service Level Agreement) richiesti per la fornitura di servizi cloud
La suite, come servizi qualificati da AgID, dovrà rispondere a tutta una serie di requisiti e SLA, così come definito nella Circolare AgiD n.3 del 9 aprile 2018.
Di seguito viene data quantificazione degli indicatori minimi di performance, affidabilità, risultato (SLI) che, durante tutto il ciclo di vita, la soluzione dovrà garantire:
Codice SLI | Indicatore | Descrizione | |
SLI1 | Availability | La percentuale di tempo in un dato periodo di riferimento in cui il servizio risulta essere accessibile e usabile. Quale periodo di riferimento si assume convenzionalmente il mese. Il tempo totale del periodo di riferimento, che funge da base di calcolo del dato percentuale, può tenere conto dei fermi programmati del servizio (in tal caso il CSP deve esplicitare questa circostanza). | 99,8 % uptime |
SLI2 | Support hours | L’orario in cui il servizio di supporto tecnico è operativo (eventualmente differenziato per “support plan” sottoscrivibile). | Lun / Ven 9:00 - 18:00 |
SLI3 | Maximum First Support Response Time | Il tempo massimo che intercorre tra la segnalazione di un inconveniente da parte del cliente e la risposta iniziale alla segnalazione da parte del CSP. | 3 minuti |
SLI4 | Cloud Service Bandwidth | La quantità di dati che può essere trasferita in un determinato periodo di tempo. Da intendersi rispetto all’interfaccia Client (laddove applicabile) oppure nell’ambito della virtual network. | 500 Mb/s |
SLI5 | Limit of Simultaneous Cloud Service Connections | Numero massimo di connessioni simultanee supportate dal servizio. | 5000 |
SLI6 | Cloud Service Throughput | Il numero di input o insieme di input correlati tra di loro (transazione) che possono essere processati in ciascuna unità di tempo dal servizio. | 1000/sec |
SLI8 | Maximum Time to Service Recovery | Il massimo tempo che intercorre tra l’indisponibilità del servizio dovuta a malfunzionamento di una delle sue componenti e il ripristino della sua normale operatività. | 3 h |
SLI9 | Backup Interval | Il tempo che intercorre tra un backup e l’altro. | 1 h |
SLI10 | Retention period of backup data | Il periodo di tempo in cui vengono mantenuti i backup da parte del CSP. | 24 mesi |
SLI11 | Backup restoration testing | Il numero di test di restore (a partire dai dati di backup) eseguiti durante un determinato periodo di tempo. | 12 |
SLI12 | Recovery Time Objective (RTO) | Il tempo massimo necessario a ripristinare completamente il servizio dopo un’interruzione dovuta ad un “evento catastrofico” che ha innescato l’attivazione di un ambiente di erogazione secondario (disaster recovery). | 6 h |
SLI13 | Recovery Point Objective (RPO) | L’intervallo massimo di tempo che precede un “evento catastrofico” rispetto al quale si può verificare la perdita delle modifiche ai dati come conseguenza delle attività di ripristino del servizio (disaster recovery). | 1 h |
SLI14 | Data retention period | Il periodo di tempo in cui i dati del cliente vengono mantenuti dal CSP dopo la notifica di cessazione del servizio. | 36 mesi |
SLI15 | Log retention period | Il periodo di tempo in cui i file di log relativi al servizio vengono conservati dopo la notifica di cessazione del servizio. | 12 mesi |
Come previsto dalla Circolare AgID n.3 del 9 aprile 2018, all’atto della sottoscrizione del contratto verranno definiti gli accordi relativi ai livelli di servizio garantiti (SLA) mediante la quantificazione di un insieme di valori obiettivo (SLO) o intervalli di valori riferibili in relazione ai suddetti (SLI). Nella sezione del contratto di fornitura relativa ai livelli di servizio garantiti saranno incluse le penali compensative che il Fornitore SaaS corrisponde all’Amministrazione in caso di mancato rispetto di uno o più valori obiettivo (SLO).
Si precisa, ad ogni modo, che i livelli di servizio sopra riportati vanno comunque contemperati con l’ambito di business trattato e la base di utenza prevista, interna ed esterna, tenendo conto della base demografica dell’Ente (identificato quale riferimento per la numerosità dell’utenza che utilizza la piattaforma).
A titolo esemplificativo, nel caso in cui attraverso la piattaforma dovesse essere pubblicato un servizio applicativo in ambito tributario che coinvolge un numero potenzialmente pari al 30% della base demografica con una decorrenza di 30 giorni, occorrerà assicurare una disponibilità di servizi tenendo conto di tali vincoli in riferimento alla base demografica dell’Ente.
Analogamente, la definizione puntuale dei RPO ed RTO rispetto alle frequenze di generazione dei backup deve conseguire ad una attività di Business Impact Analysis che determinerà, per ciascun ambito applicativo, i valori attesi.
In altri termini, i valori degli indicatori di cui alla tabella precedente dovranno essere continuamente monitorati e ridefiniti, nel corso della durata della concessione, per garantire la piena continuità operativa e adeguati livelli di performance, affidabilità e risultato, anche in presenza di significativi mutamenti delle condizioni di utilizzo del sistema.
La fornitura prevederà una sezione del portale online ovvero un portale dedicato alla esposizione degli Open Data prodotti dai diversi ambiti procedimentali; i dati soggetti a pubblicazione dovranno seguire il profilo nazionale di metadatazione DCAT-AP-IT.
I dati aperti dovranno essere pubblicati attraverso sistema di DMS basato su CKAN sia in formato web che in formato API.
10. Attività connesse alla fine della concessione
Si fa riferimento ai requisiti di interoperabilità e portabilità definite nella Circolare AgID n.3 del 9 aprile 2018.
Ai sensi della Circolare AgiD n.3 del 9 aprile 2018 il fornitore SaaS deve assicurare che la suite è conforme agli obblighi e agli adempimenti previsti dalla normativa europea e italiana in materia di protezione dei dati personali sotto tutti gli aspetti.
Il fornitore deve inoltre assicurare che la localizzazione dei data center propri e dell’infrastruttura Cloud utilizzata per erogare anche parzialmente il servizio e/o all’interno dei quali transitano anche temporaneamente i dati gestiti dal servizio (ivi compresi i siti di disaster recovery e di backup) è all'interno del territorio nazionale.
Ai sensi della Circolare AgiD n.3 del 9 aprile 2018 il fornitore XxxX deve assicurare che le componenti che costituiscono il servizio SaaS sono state sottoposte ai test OWASP con esito positivo.
A fronte di ogni rilascio, o comunque con adeguata periodicità, dovranno essere assicurate attività preventive e sistematiche di analisi di vulnerabilità e di penetration testing (VA/PT) eseguiti in conformità ad un framework di sicurezza riconosciuto a livello nazionale o europeo e comunque basato sul cybersecurity framework NIST.
La piattaforma deve essere realizzata assicurando i principi di Data Protection by Design e Data Protection by Default.
Il sistema informativo oggetto della fornitura deve assicurare il pieno rispetto dei dettami previsti dal GDPR
- Regolamento 2016/679 in termini di trattamento dei dati, di valutazione di impatto della protezione dei dati (DPIA), di cifratura dei dati e documenti e pseudonimizzazione dei dati e delle informazioni personali.
Il fornitore deve inoltre assicurare di essere in possesso della certificazione secondo lo standard ISO/IEC 27001 estesa con i controlli degli standard ISO/IEC 27017 e ISO/IEC 27018.
Sottoscritto digitalmente dal
Dirigente Responsabile dell’Area Entrate Dirigente del Servizio Gestione TARI Dott.ssa Xxxxx Xxxxxxx
La firma in formato digitale è stata apposta sull’originale del presente atto ai sensi dell’art. 24 del d.lgs. 7/3/2005 n. 82 e s.m.i. (CAD). La presente disposizione è conservata in originale negli archivi informatici del Comune di Napoli ai sensi dell’art. 22 del D.lgs. 82/2005.