Contract
La Presidenza del Consiglio dei Ministri – in persona del Commissario Straordinario per l’attuazione dell’Agenda digitale, Xxx. Xxxx XXXXXX, con sede in Xxxx, xxxxxx Xxxxxxx, x. 000, codice fiscale 80188230587, nel seguito “Commissario” o “Amministrazione”;
E
la PagoPA S.p.A., con sede legale in Roma, Piazza Colonna, n. 370, iscritta al registro delle imprese di Roma al n. 15376371009, coincidente con il numero di codice fiscale e partita IVA, legalmente rappresentata dall’Amministratore Unico Xxxxxxxx Xxxxxxx per la stipula del presente Atto, nel seguito “Società” e, congiuntamente con il Commissario, “Parti”;
PRECISATO CHE
salva diversa esplicita indicazione, ai termini riportati in ordine alfabetico è attribuito, ai fini del presente Atto, il significato di cui in appresso:
● “Allegati Tecnici”: indica i documenti allegati al presente Atto che contengono la descrizione delle attività oggetto del presente Atto e delle sue modalità di esecuzione e, nello specifico: 1) progetto PDND, 2) progetto IO, 3) Livelli di servizio e obiettivi del progetto PDND, 4) Livelli di servizio e obiettivi del progetto IO;
● “Attività”: indica le attività svolte dalla Società in esecuzione del presente Atto;
● “Atto”: indica il presente Atto stipulato tra le Parti;
● “Commissario”: indica il Commissario straordinario per l’attuazione dell’Agenda Digitale istituito dall’art. 63, decreto legislativo 26/ agosto 2016, n. 179, e nominato con decreto del Presidente del Consiglio dei ministri del 25 ottobre 2018, integrato con successivo decreto del Presidente del Consiglio dei ministri del 27 maggio 2019;
● “PagoPA S.p.A.”: indica la Società di cui all’art. 8, comma 2, del decreto-legge 14 dicembre 2018, n. 135, convertito in legge, con modificazioni, dalla legge 11 febbraio 2019, n. 12, costituita con atto notarile del 24 luglio 2019 - rep. n. 84032 - registrato all’Agenzia delle entrate in data 25 luglio 2019 n. 21779;
● “Parti”: indica congiuntamente il Commissario e la Società;
● “PDND”: indica la piattaforma digitale nazionale dati di cui all’articolo 50-ter del decreto legislativo n. 82 del 2005;
● “IO”: indica il punto di accesso telematico di cui all’articolo 64-bis del decreto legislativo n. 82 del 2005;
● “Team per la Trasformazione Digitale”: team di esperti che fanno parte della Struttura di supporto al Commissario straordinario;
PREMESSO CHE
● l’articolo 8, comma 1-bis, del decreto-legge 14 dicembre 2018, n. 135, convertito, con modificazioni, dalla legge 11 febbraio 2019, n. 12, prevede che “Il mandato del Commissario straordinario per l’attuazione dell'Agenda digitale, nominato con decreto del Presidente del
Consiglio dei ministri 25 ottobre 2018, ai sensi dell'articolo 63 del decreto legislativo 26 agosto 2016, n. 179, nonché l'operatività della relativa struttura di supporto, sono prorogati al 31 dicembre 2019”;
● il comma 1-ter del menzionato art. 8 dispone che “A decorrere dal 1° gennaio 2020, al fine
di garantire l'attuazione degli obiettivi dell'Agenda digitale italiana, anche in coerenza con l'Agenda digitale europea, le funzioni, i compiti e i poteri conferiti al Commissario straordinario per l'attuazione dell'Agenda digitale dall'articolo 63 del decreto legislativo 26 agosto 2016, n. 179, sono attribuiti al Presidente del Consiglio dei ministri o al Ministro delegato che li esercita per il tramite delle strutture della Presidenza del Consiglio dei ministri dallo stesso individuate, di concerto con il Ministero dell'economia e delle finanze per le materie di sua competenza”;
● l’articolo 8, comma 2, del suddetto decreto-legge 14 dicembre 2018, n. 135, prevede che
“Entro 120 giorni dalla data di entrata in vigore del presente decreto, per lo svolgimento delle attività di cui al comma 1, sulla base degli obiettivi indicati con direttiva adottata dal Presidente
del Consiglio dei ministri, è costituita una società per azioni interamente partecipata dallo Stato, ai sensi dell’articolo 9 del decreto legislativo 19 agosto 2016, n. 175, secondo criteri e modalità
individuati con decreto del Presidente del Consiglio dei ministri ...”;
● l’articolo 8, comma 3, del menzionato decreto-legge 14 dicembre 2018, n. 135, prevede che “Al Presidente del Consiglio dei ministri sono attribuite le funzioni di indirizzo, coordinamento e supporto tecnico delle pubbliche amministrazioni, anche utilizzando le
competenze e le strutture della società di cui al comma 2, per assicurare la capillare diffusione del sistema di pagamento elettronico attraverso la piattaforma di cui all’articolo 5, comma 2, del decreto legislativo n. 82 del 2005, nonché lo sviluppo e l’implementazione del punto di
accesso telematico di cui all’articolo 64-bis del decreto legislativo n. 82 del 2005 e della piattaforma di cui all’articolo 50-ter del medesimo decreto legislativo n. 82 del 2005 (…);
● la Direttiva del Presidente del Consiglio dei ministri del 30 aprile 2019, registrata alla Corte
dei Conti in data 21 maggio 2019, Reg.ne-Succ. n. 962, individua tra gli obiettivi strategici che la Società di cui al predetto articolo dovrà conseguire, tra gli atri, “incentivare lo sviluppo e l’implementazione del punto di accesso telematico di cui all’articolo 64-bis del decreto
legislativo n. 82 del 2005, nonché svolgere attività propedeutiche e funzionali allo sviluppo della
piattaforma di cui all’articolo 50-ter del decreto legislativo n. 82 del 2005;
● il decreto del Presidente del Consiglio dei ministri 19 giugno 2019, registrato alla Corte dei Conti in data 23 luglio 2019, Reg.ne-Succ. n. 1540, con il quale è stata autorizzata la costituzione della Società di cui al comma 2 del sopra citato articolo 8, denominata “PagoPA S.p.A.”, e sono stati individuati i criteri e le modalità per la costituzione della medesima, all’art. 1, comma 4 prevede che la Società ha per oggetto sociale lo svolgimento delle attività di cui ai commi 1 e 3 dell’art. 8 del citato decreto-legge;
● lo Statuto della Società all’art. 4, comma 1, lett. l) dispone che la Società ha per oggetto lo
sviluppo e l’implementazione, nonché la successiva gestione e diffusione del punto di accesso
telematico di cui all’articolo 64-bis del decreto legislativo n. 82 del 2005 e della piattaforma di cui all’articolo 50-ter del medesimo decreto legislativo n. 82 del 2005;
● con atto notarile del 24 luglio 2019 - rep. n. 84032 - registrato all’Agenzia delle entrate in
data 25 luglio 2019 n. 21779 è stata costituita la società PagoPA S.p.A.;
● con decreto del Presidente del Consiglio dei ministri 19 giugno 2019, registrato alla Corte dei Conti in data 29 luglio 2019, Reg.ne-Succ. n. 1580, è stato istituito il Dipartimento per la trasformazione digitale quale struttura generale della Presidenza del Consiglio dei ministri;
● con decreto del Segretario generale 24 luglio 2019, registrato alla Corte dei conti in data 8 agosto 2019, Reg.ne-Succ. n. 1659, è stata definita l’organizzazione interna del suddetto Dipartimento per la trasformazione digitale;
Considerato che:
● in virtù dell’art. 8, comma 1-ter citato, a decorrere dal 1° gennaio 2020, le funzioni, i compiti e i poteri conferiti al Commissario straordinario saranno attribuiti al Presidente del Consiglio o al Ministro delegato che li eserciterà per il tramite delle strutture della Presidenza del Consiglio dei ministri, di concerto con il Ministero dell’economia e delle finanze per le materie di sua competenza;
● per quanto sopra, i progetti PDND e IO, attualmente affidati al Commissario straordinario, transiteranno, in coerenza con quanto previsto dal citato articolo 8, nelle competenze del neo costituito Dipartimento per la trasformazione digitale;
● al fine di assicurare la capillare diffusione del sistema di pagamento elettronico attraverso la piattaforma PagoPa nonché lo sviluppo e l’implementazione dei progetti IO e PDND, il Presidente del Consiglio dei ministri, in virtù dell’art. 8, comma 3 sopra menzionato può esercitare le funzioni attribuitegli dalla norma in argomento, oltre che per il tramite delle strutture della Presidenza del Consiglio dei ministri, anche avvalendosi delle competenze e delle strutture della società PagoPA,
● lo sviluppo e l’implementazione di IO e PDND sono attività strettamente connesse alla realizzazione e all’evoluzione della Piattaforma PagoPA;
● per quanto sopra, la gestione unitaria delle attività di sviluppo ed implementazione della piattaforma PagoPa e dei progetti in argomento si rende necessaria al fine ultimo di rendere servizi digitali innovativi in favore di cittadini ed imprese nonché per assicurare la capillare diffusione del sistema di pagamento elettronico attraverso la piattaforma medesima;
Tutto quanto sopra precisato, premesso e considerato, le Parti convengono e stipulano quanto segue:
ART. 1
(Premesse e allegati)
1. Le definizioni e le premesse che precedono e gli Allegati Tecnici relativi alla descrizione delle attività del progetto PDND, del progetto IO e quelli relativi ai Livelli di servizio e obiettivi del progetto PDND e del progetto IO formano parte integrante del presente Atto.
2. L’esecuzione del presente Atto è inoltre regolata:
a. dal presente Atto e dai relativi allegati (n. 4 allegati);
b. dalle vigenti disposizioni di legge per l’Amministrazione del Patrimonio e della Contabilità generale dello Stato e del regolamento di esecuzione ed attuazione;
c. dalle vigenti disposizioni di legge e regolamentari in materia di amministrazione digitale;
d. dal codice civile.
ART. 2
(Oggetto e durata)
1. Il presente Atto ha ad oggetto l’affidamento alla Società - in coerenza con quanto disposto dall’art. 8, comma 3, citato in premessa - delle attività di seguito indicate, come dettagliate negli Allegati Tecnici:
- attività di sviluppo e di implementazione nonché di successiva gestione e diffusione della PDND;
- attività di sviluppo e di implementazione nonché di successiva gestione e diffusione del progetto IO.
La Società si impegna ad eseguire le attività previste negli Allegati Tecnici secondo le modalità definite nei medesimi, nei limiti dell’importo di cui all’articolo 4 del presente Atto.
Per la realizzazione del progetto IO, la Società subentra nei rapporti già instaurati dal Commissario con gli Enti che hanno aderito alla sperimentazione “closed beta” dell’applicazione mobile IO.
2. Il presente Atto ha durata fino al 31 dicembre 2020 ed è vincolante per la Società a decorrere dalla data di sottoscrizione, mentre per il Commissario sarà vincolante solo dopo l’approvazione e la registrazione del relativo decreto di approvazione e di impegno della spesa, ai sensi delle vigenti disposizioni di contabilità di Stato.
3. Esclusa la possibilità di rinnovo tacito, il presente Xxxx potrà essere prorogato prima della sua scadenza per comune volontà delle Parti.
ART. 3
(Responsabili)
1. Le Parti indicano quali responsabili del presente Atto:
- Xxxxx xx Xxxx, esperto del Team per la trasformazione digitale, per l’Amministrazione;
- Xxxxxxxx Xxxxxxx, in qualità di Amministratore Unico, per la Società.
ART. 4
(Importi massimali)
1. Per le attività di cui all’art. 2, come dettagliate negli Allegati tecnici, l’importo da corrispondere alla Società è determinato in Euro 4.098.360,66 (quattromilioninovantottomilatrecentosessanta/66), oltre IVA, di cui € 2.049.180,33 oltre Iva per il progetto PDND ed € 2.049.180,33 oltre IVA per il progetto IO.
2. Considerata la natura sperimentale delle attività oggetto del presente Atto, le Parti, in corso di esecuzione contrattuale, possono concordare, nell’ambito di ciascun progetto, variazioni compensative delle voci di costo riportate nei rispettivi piani economici, fermo restando l’importo complessivo riferito al singolo progetto.
3. Le variazioni di cui al precedente comma 2, devono essere preventivamente concordate tra le Parti per iscritto mediante scambio di note firmate digitalmente e trasmesse a mezzo pec.
ART. 5
(Prestazioni esterne)
1. Fermo restando quanto previsto dall’art. 4 e dal successivo art. 9, per l’esecuzione delle attività previste dal presente Atto, la Società potrà anche avvalersi, rimanendone pienamente responsabile, di propri fornitori (imprese terze, esperti e professionisti in possesso di adeguata qualificazione).
2. A tale riguardo, la Società si impegna a sollevare e tenere indenne l’Amministrazione da ogni obbligo, onere retributivo e responsabilità derivante dallo svolgimento delle attività eventualmente eseguite da soggetti terzi.
3. La Società non potrà cedere in nessun caso il presente Atto e/o qualsiasi diritto od obbligo ivi previsto a terze parti; qualsiasi cessione sarà considerata nulla.
ART. 6
(Riuso e accessibilità)
1. La Società procederà a realizzare le applicazioni software necessarie all’esecuzione del presente Atto quando non sia possibile – sulla base di valutazioni condivise con il
Commissario - attuare il riuso delle applicazioni software di proprietà di altre Pubbliche Amministrazioni in conformità a quanto previsto dal d.lgs. n. 82/2005 ovvero quando le stesse non siano reperibili sul mercato.
2. Nella realizzazione di nuove applicazioni software, la Società dovrà attenersi alle direttive volte a favorire l’accessibilità dei soggetti disabili agli strumenti informatici.
ART. 7
(Fatturazione e pagamento)
1. L’importo di cui all’art. 4 sarà erogato secondo le seguenti modalità:
- il 20% a titolo di anticipazione del prezzo, a seguito della registrazione del decreto di approvazione del presente Atto da parte dei competenti Uffici di controllo e previa presentazione di fattura elettronica;
- il restante 80% in rate bimestrali posticipate di uguale importo, previa presentazione di fattura elettronica.
I pagamenti verranno effettuati entro 60 (sessanta) giorni dalla data di ricezione della fattura elettronica, che dovrà essere emessa a seguito dell’attestazione di regolare esecuzione da parte del Responsabile del procedimento (RUP).
2. In particolare, ai fini dell’emissione delle fatture successive all’anticipazione, la Società dovrà inviare all’indirizzo pec dell’Amministrazione una relazione descrittiva delle attività effettuate nel bimestre di riferimento. Ai fini dell’emissione dell’ultima fattura la Società dovrà inviare una relazione descrittiva di tutte le attività svolte nell’ambito del presente Atto, in conformità a quanto previsto negli Allegati Tecnici.
3. Il Responsabile del procedimento verificherà la completezza e correttezza delle attività espletate dalla Società, procedendo a comunicare alla medesima il nulla osta alla fatturazione. Solo a seguito di tale comunicazione la Società potrà emettere fattura elettronica.
4. L'Amministrazione applica le norme in materia di scissione dei pagamenti (art. 17 ter del DPR del 26 ottobre 1972 n. 633 introdotto dall'art.1, comma 629 lettera b) e comma 632, secondo periodo della legge 23 dicembre 2014, n.190, in materia di modalità di versamento dell’imposta di valore aggiunto per le cessioni di beni e prestazioni di servizi effettuate nei confronti di talune pubbliche amministrazioni).
5. Il pagamento sarà effettuato a mezzo bonifico bancario sul conto corrente indicato dalla Società e dedicato, anche in via non esclusiva, alle commesse pubbliche, ai sensi Legge 13 agosto 2010, n. 136.
6. La Società si impegna all’osservanza di tutti gli obblighi in materia di tracciabilità dei flussi finanziari ai sensi Legge 13 agosto 2010, n. 136 e, in particolare, utilizzerà il conto corrente
indicato, per tutte le proprie transazioni relative alle commesse pubbliche comprese le transazioni verso i propri subcontraenti, impegnandosi a comunicare all’Amministrazione, entro 7 giorni, ogni modifica relativa ai dati trasmessi.
7. L’inosservanza degli obblighi derivanti dalla citata Legge 136/2010 comporta, a carico del soggetto inadempiente, l’applicazione delle sanzioni previste all’art. 6 della legge medesima.
ART. 8
(Livelli di servizio)
1. I valori, gli obiettivi e le metodologie di calcolo indicati negli allegati 3 e 4 sono oggetto di sperimentazione al fine di definire, successivamente ed entro la scadenza del presente Atto, i livelli di servizio delle attività.
2. A tal fine, con cadenza trimestrale, le Parti procederanno alla rilevazione degli esiti della sperimentazione e, di comune accordo, potranno rivedere valori, obiettivi e metodologie di calcolo di cui ai predetti allegati.
ART. 9
(Proprietà intellettuale e industriale)
1. Tutti i diritti di proprietà intellettuale sui software sviluppati dal Commissario fino alla data di stipula del presente Xxxx in relazione ai progetti PDND e IO restano in capo al Commissario. Il Commissario concede alla società una licenza d’uso gratuita sui predetti diritti per tutti i fini necessari all’esecuzione del presente Atto e per tutta la durata dello stesso.
2. Tutti i diritti di utilizzazione economica sui software oggetto di sviluppo da parte della Società nonché su tutte le librerie sviluppate dalla Società necessarie all’esecuzione del presente Atto sorgono direttamente in capo al Commissario, il quale li concede in licenza d’uso gratuita alla Società per tutti i fini necessari all’esecuzione del presente Atto e per tutta la durata dello stesso.
3. Resta inteso che i software utilizzati dal Commissario sono resi pubblici in conformità alle Linee guida sul riuso di software per le pubbliche amministrazioni adottate ex art. 71 del Codice dell’Amministrazione digitale e che la Società dovrà rendere pubblici, in conformità alle predette Linee guida, i codici sorgente relativi ai software sviluppati in esecuzione del presente Atto.
4. Resta esclusa qualsiasi responsabilità del Commissario nel caso la Società usi, per l’esecuzione del presente Atto, dispositivi e soluzioni di cui altri siano titolari di diritti di privativa.
5. La Società, conseguentemente, manleverà e terrà indenne il Commissario da ogni pretesa e dagli oneri relativi ad azioni per violazione di qualsivoglia diritto di proprietà industriale o intellettuale relativo alle opere oggetto del contratto.
6. Nel caso in cui, nell’esecuzione del presente Atto, la Società utilizzi tecnologie oggetto di proprietà intellettuale o industriale di titolarità della Società stessa, alla scadenza del presente Atto, la Società si impegna a concedere una licenza d’uso gratuita al Commissario. Tale licenza è limitata agli utilizzi funzionali ai progetti PDND e IO.
ART. 10
(Sicurezza del sistema)
1. La Società è tenuta ad assicurare i livelli di sicurezza previsti dalle disposizioni di legge e normative.
2. A tale scopo, tenuto conto dei livelli di qualità dei servizi richiesti, la Società dovrà operare attraverso l’adozione di idonee misure organizzative, tecniche ed operative, per la protezione dei dati e delle informazioni gestite, delle apparecchiature e dei sistemi di elaborazione utilizzati, nonché delle reti di comunicazione.
3. La protezione di cui sopra dovrà essere assicurata riguardo sia alle apparecchiature e alle reti interne alla Società, utilizzate per l’espletamento del suo incarico, sia alla trasmissione di dati attraverso reti esterne.
4. La Società si obbliga espressamente a manlevare e tenere indenne l’Amministrazione da tutte le conseguenze derivanti dalla eventuale inosservanza delle norme e prescrizioni tecniche vigenti in materia di sicurezza.
ART. 11
(Tutela dei dati personali e riservatezza)
1. La Società, nell’esecuzione delle prestazioni oggetto del presente Atto, e in particolare nello sviluppo, implementazione, gestione e diffusione della PDND e del progetto IO, tratterà informazioni qualificabili come dati personali ai sensi del Regolamento Europeo n. 2016/679. La Società si impegna a trattare tali dati personali, in qualità di titolare del trattamento ovvero in qualità di responsabile del trattamento (se nominato tale dai soggetti che utilizzano i servizi offerti per il tramite della PDND e del progetto IO), nel pieno rispetto della normativa vigente in materia di protezione dei dati personali, ivi inclusi gli aspetti relativi alla sicurezza.
ART. 12 (RISOLUZIONE)
1. L’Amministrazione si riserva ampia ed insindacabile facoltà di risolvere in qualsiasi
momento il presente Atto, qualora la Società si renda inadempiente ai sensi dell’art. 1453 e seguenti del c.c., anche ad uno solo degli obblighi contrattuali.
2. Nel caso di risoluzione, la Società ha diritto soltanto al pagamento delle prestazioni regolarmente eseguite alla data di risoluzione del presente Atto.
ART. 13
(FORO COMPETENTE)
1. Per qualsiasi controversia derivante dall’interpretazione e/o esecuzione del presente contratto, il Foro competente è esclusivamente quello di Roma.
Il Commissario Straordinario per l’attuazione dell’Agenda digitale
L’Amministratore Unico della Società PagoPA S.p.A.
Xxxx XXXXXX
(x.xx digitalmente)
Firmato digitalmente da XXXXXX XXXX
C=IT
O=PRESIDENZA CONSIGLIO DEI MINISTRI
Xxxxxxxx XXXXXXX
Firmato digitalmente da:XXXXXXXX XXXXXXX Xxxxx:AMMINISTRATORE UNICO
Organizzazione:PAGOPA S.P.A./15376371009 Data:24/10/2019 17:10:16
(x.xx digitalmente)
All.1 Documento Tecnico-Operativo - Piattaforma Digitale Nazionale Dati
Sommario
Introduzione 11
La Piattaforma Digitale Nazionale Dati ( PDND ) 11
Scopo 14
Descrizione dell’integrazione tra pagoPA, IO e PDND 15
Acquisizione automatica dei dati di PagoPA 16
Esempio : 18
Visualizzazione dei dati di pagoPA attraverso Cruscotti e Data Applications 20
Piano di sviluppo 22
Identity Management 22
Data Governance Framework 22
Data Ingestion / ETL 23
Data Science / Analytics Platform 23
Business Intelligence & Data Visualization 23
Piattaforma creazione Data Stories 23
Sviluppo API Pubbliche e Private 24
UI UX User Interface and User Experience Enhancements 24
Interfaccia Mobile - Integrazione con piattaforma IO 25
Open Data as a Service ( DaaS ) 25
TimeSeries Data Integration, IoT 25
Infrastruttura Cloud 25
Configurazioni Sistemistiche 25
Monitoraggio 26
Resa dell’infrastruttura ridondante (multi-regione) 26
Supporto e Manutenzione della piattaforma 26
Implementazione di strumenti a supporto della gestione e conduzione 26
Consolidamento del flusso di on-boarding delle PA 26
Definizione di una procedura di supporto clienti di primo livello 27
Struttura organizzativa 27
Piano economico 28
La Piattaforma Digitale Nazionale Dati ( PDND )
Nell’ambito dei compiti assegnati per dare attuazione all’Agenda digitale italiana, anche in coerenza con gli obiettivi dell’Agenda digitale europea e in conformità con quanto previsto nel Piano Triennale per l’informatica nella Pubblica Amministrazione 2017–2019 e successivamente 2019 - 2021, la struttura del Commissario Straordinario per l’attuazione dell’Agenda Digitale - Presidenza del Consiglio dei Ministri propone un progetto per la realizzazione di una piattaforma software denominata Piattaforma Digitale Nazionale Dati (PDND) che faciliti la valorizzazione del patrimonio informativo degli enti pubblici, in coerenza con quanto previsto con la direttiva europea PSI 2019 e con gli articoli 50, 52 e 50-ter del Codice dell'Amministrazione Digitale (Legge 7 marzo 2005 n.82).
Il software sarà centrale nell’espletamento di alcune funzioni chiave come:
● procedure di data quality sui dati pubblici della PA;
● metadatazione conforme ai requisiti DCAT_AP_IT;
● processi guidati per la compliance con GDPR nel rilascio open data;
● processi guidati per la compliance con GDPR nella condivisione dati tra PA;
● accesso attraverso REST API ai dataset;
● realizzazione di cruscotti analitici per la realizzazione di politiche data-driven;
● pubblicazione "data stories" per promuovere l'accesso civico ai dati;
● sviluppo modelli di AI/ML attraverso Notebooks integrati nella piattaforma di Analytics, con possibilità di eseguirli con pianificazione temporale o innescati da eventi
La PDND è inoltre una delle piattaforme abilitanti previste nel Piano Triennale per l’informatica nelle Pubbliche Amministrazioni realizzata per rendere più semplice, sicuro e trasparente lo scambio e la pubblicazione dei dati dalla Pubblica Amministrazione abilitando la conformità con le normative GDPR.
La PDND è attualmente in fase prototipale e sono circa 15 le Pubbliche Amministrazioni che la stanno sperimentando. La possibilità di fornire la pubblicazione open data come un servizio chiavi in mano risulta particolarmente utile per le piccole amministrazioni locali che avrebbero difficoltà nella gestione di una piattaforma dedicata locale.
La proposta di sviluppare e integrare la piattaforma PDND contribuisce direttamente ad affrontare le sfide poste dal Tema Unificante di Omogeneità e qualità dei servizi. I vantaggi derivanti dall’adozione della PDND sono molteplici sia per le PA sia per i cittadini; nello specifico PDND permette alla Pubblica Amministrazione:
● di adottare un modello standardizzato nella governance dei dati pubblici;
● di adottare processi di compliance GDPR uniformi nella PA;
● di mettere a sistema i dati presenti facilitando la condivisione sicura tra le PA;
● di fornire una mappatura consistente sull utilizzo dei dati, che permetta un facile monitoraggio da parte delle autorità di protezione dei dati personali;
● di creare pattern nell'analisi e nella produzione di report o modelli predittivi con i dati;
● di ridurre i costi di gestione nelle PA.
e al cittadino:
● di ottenere in maniera consistente un accesso ai dati pubblici, corredato di informazioni puntuali sul significato di questi dati e casi esemplificativi sulle tipologie di analisi che sono possibili;
● di poter eseguire facilmente attività di civic hacking o data journalism;
● di ottenere dati di qualità utili per la realizzazione di servizi a valore aggiunto.
Mettere a disposizione di tutti gli Enti Pubblici una piattaforma che renda più semplice ed efficace l'uso dei dati pubblici può portare considerevoli benefici al sistema paese. Il progetto PDND avrà impatto sull’intero territorio italiano, consentendo un miglioramento dell’interazione dei cittadini con la Pubblica Amministrazione e favorendo l’omogeneità dei dati sul tutto il territorio nazionale.
Questo intervento migliorerà la qualità dei servizi per i cittadini e contribuirà ad uno sviluppo positivo dei servizi pubblici digitali.
La piattaforma PagoPA
pagoPA è il nodo di pagamento della Pubblica Amministrazione. È una piattaforma che connette tra loro cittadini, Pubblica Amministrazione e i Prestatori di Servizi di Pagamento (PSP) per effettuare pagamenti verso la Pubblica Amministrazione in sicurezza e con semplicità.
Integrare pagoPA rappresenta un grosso vantaggio per le Pubbliche Amministrazioni perché i pagamenti vengono accreditati in tempo reale, vengono correttamente rendicontati e di conseguenza può immediatamente essere rilasciato al cittadino la quietanza con valore legale.
Per un cittadino, pagoPA permette di scegliere il metodo di pagamento tra i diversi a disposizione, a seconda delle comodità e del livello di digitalizzazione. È possibile pagare tramite:
● carta di credito
● addebito in conto
● bollettino postale o altri avvisi cartacei
● forme innovative di pagamenti presenti sul mercato
Il sistema si evolve in una ottica di mercato integrando canali di pagamento innovativi ed evolvendo l’interfaccia utente e le funzionalità del sistema verso gli standard consolidati sul mercato.
La piattaforma pagoPA si avvale come interfaccia utente di IO , mobile application disegnata per fornire ai cittadini un unico punto di ingresso ai servizi della Pubblica Amministrazione.
Nel piano di sviluppo della PDND c’è l’integrazione con IO in modo da sfruttare questa mobile application per fornire ai cittadini le informazioni contenute nell’archivio nazionale degli Open Data all’interno della PDND stessa.
Lo scopo di questo documento è descrivere l’uso della piattaforma PDND come strumento strategico integrato di Analytics per la piattaforma pagoPA, e la possibilità di integrarsi con l’app IO per la visualizzazione dei dati su piattaforma Mobile
Descrizione dell’integrazione tra pagoPA, IO e PDND
La piattaforma PagoPA necessita fortemente di un sistema a supporto che ne faciliti la gestione, controllo e comunicazione trasparente dei dati relativi alle transazioni, oltre che fornire degli strumenti di analitica avanzata che sono fondamentali per una corretta analisi dei dati per consentire una crescita e miglioramento del servizio .
Dalla parte opposta, la PDND necessita di una App Mobile che può consentire al cittadino di ricevere su richiesta informazioni di proprio interesse presenti all’interno della piattaforma stessa , come quelli archiviati in formato aperto ( Open Data ) di diverse categorie.
In supporto alle necessità di pagoPA sopra riportate , viene in aiuto uno dei pilastri portanti della nuova piattaforma PDND, ovvero la funzionalità di analitica avanzata sui dati , per consentire l’implementazione di modelli di controllo su integrità, efficacia e nel contempo distribuire a clienti e fornitori tutte le informazioni/dati richiesti in conformità con le regolamentazioni GDPR .
La PDND, ad oggi in fase sperimentale, è già in grado di soddisfare in modo basilare queste necessità, essendo dotata al suo interno di tools per poter svolgere questi tre compiti:
1) Motore di Ingestion ed ETL integrato per poter acquisire, preparare ( in termini di controllo qualità e GDPR ) e trasformare i dati provenienti dalla piattaforma PagoPA, come anche distribuirli in modo sicuro e controllato.
2) Motore di Analytics integrato per consentire a Data Scientists di sviluppare modelli di analisi dei dati
3) Tools di Visualizzazione Dati integrato per consentire la pubblicazione di cruscotti informativi
Nei seguenti capitoli vengono descritti in dettaglio questi i tre componenti atti a svolgere i compiti sopra citati.
1. Acquisizione automatica dei dati di PagoPA
In questa fase di sperimentazione tutti i dati inviati alla PDND sono privi di contenuti sensibili e personali.
Il servizio di “Ingestion/ETL” della PDND è Azure Data Factory , in grado di acquisire i dati da diverse fonti in maniera sicura ed efficace
Lo schema di acquisizione dati attuale per la piattaforma PagoPA si descrive sommariamente nel seguente diagramma :
I dati statistici vengono al momento inviati alla piattaforma PDND via protocollo sFTP , ed archiviati nello storage comprimendoli e trasformandoli nel formato necessario.
Nel piano di sviluppo della piattaforma viene inclusa una evoluzione di questa interfaccia in modo da avere solo i dati incrementali in modo da ottimizzare il processo.
Durante l’ingestion vengono eseguiti dei controlli sui dati ed infine aggiornate le tabelle del DataLake dove i dati saranno accessibili da tutti i tools integrati di analisi e visualizzazione, ma solo dagli utenti a cui sarà dato esplicito accesso al gruppo di dati.
In Data Factory ( il servizio di ingestion della PDND ) lo schema precedente si semplifica notevolmente grazie alle attività di “Copy Data”, “Notebook Integration” e la possibilità di richiamare delle pipeline dedicate per la gestione degli errori / dati non conformi agli schemi predefiniti
Pipeline di ingestion dei dati di PagoPA contenente l’attività di Copy Data , un Notebook disegnato per analizzare i dati in arrivo ed aggiornare le tabelle di destinazione, ed infine una Pipeline Execution per gestire gli errori
Sicurezza per l’accesso ai dati di pagoPA
La sicurezza dei dati è garantita da dal sistema di autenticazione e gestione di identità di Azure Active Directory :
● il quale identifica ed assegna ad ogni utente l’elenco dei gruppi di accesso che regolano la visione dei dati oltre che a ruoli specifici che ne determinano le modalità operative.
● consente di assegnare un gruppo di controllo accessi specifico ai dati già durante il processo di ingestion, semplicemente trasferendo i dataset nelle cartelle dell’archivio “Data Lake Storage” dell’organizzazione
● consente di attribuire agli utenti determinati Ruoli che ne determinano le azioni possibili verso i dati a cui si ha accesso ( Viewer , Editor, Admin )
All’organizzazione PagoPA viene definito un gruppo univoco di accesso privato pdnd_pagopa ed una root folder ( cartella principale ) omonima per l’archivio dei suoi dataset. L’accesso a questa cartella sarà permesso ai soli utenti a cui verrà associato il gruppo pdnd_pagopa.
Vengono definiti gli utenti di base “Viewer” per l’accesso ai dati, gli “Editor” che possono definire attraverso una “Ingestion Form” delle pipeline di acquisizione dati semplici, ed infine due “Admin” ( primario e backup ) che sono i responsabili all’interno dell’organizzazione per l’autorizzazione all’ingresso di altro personale o la creazione di sottogruppi .
Servizio di creazione modelli di Analisi dati di pagoPA
Nella piattaforma PDND iI modelli di analisi dei dati di pagoPA possono essere sviluppati attraverso Azure DataBricks sotto forma di “Notebooks”
I notebooks di Databricks possono generare dataset derivati oppure compilati ed essere riutilizzati nel servizio di Ingestion, scatenati da Eventi, oppure pianificarne l’esecuzione su base temporale.
Il linguaggio di programmazione che può essere utilizzato per sviluppare i modelli è Python, sql, R ed infine Scala.
Notebook per l’analisi dei dati di PagoPA
I modelli possono essere pubblicati sia per motivi di trasparenza che per collaborazione con gli altri enti pubblici.
2. Visualizzazione dei dati di pagoPA attraverso Cruscotti e Data Applications
In generale come strumento di creazione cruscotti di visualizzazione dati viene utilizzato Microsoft PowerBI per poi essere pubblicati attraverso il servizio “PowerBI Embedded”, che espone i cruscotti via API che possono quindi essere inseriti in Web Applications dedicate ( che chiameremo “Data Applications” ) all’interno della PDND.
Alcune “Data Applications” possono essere sviluppate Ad-Hoc da web designers per caricare dati aperti ( Open Data ) disponibili sulla piattaforma PDND
La Data Application ufficiale per fornitura statistiche di utilizzo PagoPA
La Data Application ufficiale per la visualizzazione delle statistiche di utilizzo PagoPA è inserita nella seguente pagina :
xxxxx://xxxxxxxxxxxx.xxxxxxx.xx/xx/xxxxxxxx/xxxxxxxxx-xxxxxxxx.xxx
Anche i notebooks citati al paragrafo 2 possono essere usati per generare cruscotti di informazioni contenenti sia dati numerici e testuali, che anche grafici e mappe.
Essi possono essere pubblicati solo in caso i dati siano di tipo “Open Data/Dati Aperti” e quindi completamente privi di informazioni personali o di proprietà della pubblica amministrazione, e dotati di una licenza che ne regoli la visualizzazione ed il riutilizzo.
Alcune delle funzionalità principali da evolvere o sviluppare previste per il triennio 2020- 2022 per la Piattaforma Digitale Nazionale Dati a supporto della piattaforma pagoPA sono state descritte tecnicamente nei paragrafi precedenti . Essendo la piattaforma ancora in fase sperimentale le sopracitate funzionalità e quelle seguenti fanno parte del piano di sviluppo.
Implementazione del nuovo sistema di Identity Management della piattaforma Azure per quanto riguarda le utenze della Pubblica Amministrazione, il quale si integra nativamente con i tools e servizi utilizzati dalla nuova piattaforma
Studio dell’integrazione con un sistema di Identity Management aperto per consentire ai cittadini di registrarsi alle applicazioni che trattano i soli Dati Aperti.
Questo studio potrebbe portare all’utilizzo del sistema di autenticazione già in adottato dalla piattaforma IO.
Integrazione con sistema di autenticazione via SPID
● PDND Auditing Framework : Auditing dei dati / Tracciabilità delle modifiche / Generazione Eventi / Monitoring e Visualizzazione
● IA a supporto dell'adempimento alle regole sulla gestione e protezione dei dati ( GDPR )
○ - Diritto all'oblio
○ - Anonimizzazione e Differential Privacy
○ - Condivisione dei Dati controllata
○ - Implementazione DPIA su Ingestione dei Dati
○ - Rilevamento delle Anomalie
La possibilità di eseguire l’ingestion di dati di qualsiasi formato consente di archiviare nella PDND informazioni più generali di quelle aventi uno schema predefinito, come gli shape data per la creazione di geomappe, formati documentali per una analisi dei documenti etc..
Data Science / Analytics Platform
L’evoluzione della piattaforma di Analytics è fondamentale per l’evoluzione della stessa piattaforma pagoPA.
E’ necessario il consolidamento della nuova piattaforma integrata “Azure DataBricks” per lo sviluppo ed implementazione controllata di modelli AI sempre più precisi e dettagliati.
Business Intelligence & Data Visualization
Consolidamento dei nuovi tools di BI e Visualizzazione per consentire a fornitori ed utilizzatori del servizio pagoPA di accedere ai dati aperti relativi a transazioni in modalità self-service
Piattaforma creazione Data Stories
Tool per la creazione di “Storie sui Dati” , nuova integrazione con Azure DataBricks e PoweBI Embedded sia per la presentazione e condivisione dei modelli di analisi dati, che presentazione dei dati in un contesto giornalistico
Sviluppo API Pubbliche e Private
Possibilità di sviluppare API ad-hoc su richiesta di organizzazioni pubbliche e private per rendere più efficiente la comunicazione dei dati ed eventualmente integrarla con sistemi di terze parti, sempre in rispetto delle regolamentazioni GDPR e del trattamento dei dati della Pubblica Amministrazione
Implementazione della gestione e controllo delle quote di utilizzo delle API
UI UX User Interface and User Experience Enhancements
Evoluzione della nuova interfaccia Web/FrontEnd della PDND “PDND UI”
Creazione di un portale di “Onboarding” per le pubbliche amministrazioni che vogliono aderire al progetto
Evoluzione del nuovo portale PDND ( PDND UI ) per sfruttare le funzionalità del Cloud
Utilizzo di un motore BPM ( Business Process Management ) per l’orchestrazione di processi umani , ad esempio processo di inserimento DPIA per GDPR durante la definizione di un flusso di ingestion dati.
Interfaccia Mobile - Integrazione con piattaforma IO
Integrazione con la piattaforma IO per permettere la sottoscrizione a canali di pubblicazione dati aperti di principale interesse per l’utente
Può essere la stessa piattaforma PDND ad erogare servizi attraverso IO, in termini di informazioni derivate dai dati pubblici e aperti presenti nella piattaforma che possono essere di interesse al singolo cittadino o all’utente della pubblica amministrazione
Open Data as a Service ( DaaS )
Sviluppo nuovo portale “Open Data” as a Service , che consentirà le piccole Pubbliche Amministrazioni di configurare un proprio portale Open Data sulla base di quello fornito dalla PDND , ma dove i contenuti sono di esclusivo interesse della Pubblica Amministrazione che lo ha generato.
TimeSeries Data Integration, IoT
L’implementazione dell’ ingestion di dati in tempo reale è un requisito fondamentale per completare le tipologie di dati di interesse per la Pubblica Amministrazione ed i cittadini.
Mentre le singole Pubbliche Amministrazioni possono collezionare dati real-time con un dettaglio molto elevato, la PDND può funzionare da collettore per ricevere ed archiviare informazioni di più alto livello, utili per i modelli di aggregazione con dati già presenti .
Configurazione degli ambienti di staging, consolidamento della configurazione terraform ed evoluzione per gestire ambienti multipli, gestione dei secrets in modo sicuro. L’obiettivo di queste attività è quello di gestire la disponibilità, le prestazioni, il monitoraggio e la risposta agli incidenti delle piattaforme e dei servizi della PDND
Review delle metriche da monitorare a livello applicativo e infrastrutturale, configurazione di dashboard di monitoraggio e relativi alert.
L’obiettivo è di monitorare le metriche possibili all'interno della PDND in modo da avere una comprensione precisa della salute del sistema in tutti i suoi servizi ed in ogni momento, incluso il controllo dei costi e loro proiezione.
Una pratica comune è quella di monitorare le metriche specifiche, impostare le soglie e attivare gli avvisi in base a tali soglie.
Resa dell’infrastruttura ridondante (multi-regione)
Adeguamento dell’infrastruttura verso la ridondanza multi-regione per la gestione del disaster recovery e il servizio ad alta disponibilità.
Supporto e Manutenzione della piattaforma
Implementazione di strumenti a supporto della gestione e conduzione
● Implementazione di applicazioni web a supporto della gestione, amministrazione e supporto dei servizi offerti dalla PDND a Pubbliche Amministrazioni e Cittadini.
● In pratica si tratterà di creare un portale di back-office di amministrazione con una dashboard per:
○ Monitoraggio delle attività sulla piattaforma ed i suoi servizi
○ Monitoraggio sulla qualità dei dati archiviati
○ Monitoraggio dei costi
○ Monitoraggio dei delle quote di utilizzo delle API.
Consolidamento del flusso di on-boarding delle PA
Creazione di un portale di on-boarding delle PA descrivendo la piattaforma, i servizi, i contenuti, ed il flusso di on-boarding predefinito.
Definizione di una procedura di supporto clienti di primo livello
Definizione di una procedura che regoli le modalità di erogazione di un supporto di primo livello differenziato tra agli utenti delle Pubbliche Amministrazioni ed i Cittadini, via call- center e/o servizio integrato nella web application ( i.e. online-chat o error-event submission via email )
Dimensionamento dell’ helpdesk per un massimo di 100 chiamate giornaliere per la PA. Per le PA centrali , Regioni e Città Metropolitane vanno definiti dei “key-users” / “focal- point” interni a supporto della piattaforma
La gestione e lo sviluppo del progetto PDND , dovrà gradualmente utilizzare risorse umane dedicate, attraverso una struttura organizzativa in grado di garantire il raggiungimento degli obiettivi di prodotto, di crescita, di manutenzione e supporto secondo i più alti standard di efficienza e sicurezza.
Per raggiungere questi obiettivi, la struttura organizzativa dedicata al progetto deve dotarsi delle seguenti figure professionali:
● Chief Data Officer & Product Manager (1)
● Data Scientist (2)
● Semantic Web Engineer (1)
● Big Data Engineer (1)
● Data Integration Specialist (2)
● Web Development Lead (1)
● Senior Web Developer (1)
● Backend Development Lead (1)
In aggiunta , le seguenti figure sono necessarie ma possono essere in sharing con altri progetti grazie all’architettura utilizzata ed al loro contributo necessario parzialmente sulla piattaforma :
● Data Protection Officer (1)
● Chief Security Officer (1)
● DevOps/SRE Lead (1)
● UX/UI Designer Lead (1)
Approvvigionamento risorse esterne
Per raggiungere gli obiettivi di sviluppo di prodotto e di crescita, la struttura organizzativa dedicata al progetto dovrà dotarsi di una serie di figure professionali acquisite tramite i meccanismi di approvvigionamento CONSIP.
Ruolo | FTE |
Software Developer | 8 |
Support Specialist | 5 |
Di seguito si riportano le previsioni di spesa per il raggiungimento degli obiettivi del progetto PDND ( ex DAF ).
Voce | importo netto IVA | IVA | importo lordo IVA |
Infrastruttura Cloud e Licenze servizi integrati Azure | € 655.737,70 | €144.262 | € 800.000 |
Licenze Software | € 24.590,16 | € 5.410 | € 30.000 |
Security ( Tools e Presidio ) | € 73.770,49 | € 16.230 | € 90.000 |
Servizi di sviluppo | € 1.580.000 | € 284.918 | € 1.580.000 |
Totale | € 2.049.180,33 | €450.820 | €2.500.000 |
All.2 Documento Tecnico Progetto IO
Sommario
Introduzione 31
Il ruolo strategico di IO nella crescita di pagoPA 32
IO è l’interfaccia verso pagoPA 32
L’app IO: l’interfaccia verso pagoPA per il cittadino 32
Le API IO: l’interfaccia verso pagoPA per gli Enti 32
IO è il driver di crescita di pagoPA 32
IO è il driver per innovare pagoPA 33
Il progetto “IO” in sintesi 33
L’app IO per il cittadino 33
Messaggi e avvisi di pagamento 33
Portafoglio 34
Preferenze 34
Profilo 35
Le API IO per gli Enti Erogatori 35
API per la lettura delle Preferenze 35
API per l’invio di Messaggi e Avvisi di Pagamento 36
API per l’integrazione con pagoPA 36
Avvisi di pagamento digitali 36
Avvisi di pagamento cartaceo 36
Verifica e attualizzazione 37
Transazione 37
Ricevuta di pagamento 37
Storico delle transazioni 37
Piano evolutivo 38
Obiettivi di prodotto 38
Evoluzione ecosistema pagoPA 38
Meccanismo di inoltro degli avvisi digitali di pagamento ai PSP 38
Meccanismo di accesso agli avvisi digitali di pagamento ai fini del supporto utente38 Registro centralizzato delle posizioni debitorie 38
Micropagamenti 38
Borsellino privativo e crediti 38
Evoluzione app e API IO 39
Arricchimento dell’integrazione con pagoPA 39
Arricchimento della funzionalità Preferenze 39
Implementazione della funzionalità Documenti 39
Implementazione della funzionalità Profilo 40
Cifratura dei Messaggi 40
Implementazione dell’integrazione con ANPR 40
Sviluppo del portale self-care web 40
Integrazione della tracking strategy 41
Telemetria 41
Sviluppo di test 41
Implementazione meccanismi di gestione delle quote di utilizzo delle API 41
Evoluzione dei meccanismi di autenticazione delle API 41
Invio di messaggi batch 41
Messaggi broadcast geofenced 42
Infrastruttura cloud 42
Configurazioni sistemistiche 42
Monitoraggio 42
Resa dell’infrastruttura ridondante (multi-regione) 42
Conduzione e customer care 42
Implementazione di strumenti a supporto della gestione e conduzione 42
Consolidamento del flusso di on-boarding delle PA 42
Supporto di primo livello 43
Struttura organizzativa 43
Approvvigionamento risorse esterne 43
Piano economico 43
La Presidenza del Consiglio dei Ministri, ha progettato e sviluppato il progetto “IO”, un sistema applicativo che si presenta come il punto di accesso ai servizi delle pubbliche amministrazioni e degli altri soggetti pubblici indicati all’articolo 2, comma 2, del CAD (di seguito, “Enti Erogatori”), quali appunto le società a controllo pubblico, non quotate, e i gestori di pubblici servizi.
IO è fruibile da parte dei cittadini attraverso la relativa applicazione mobile (“app IO”), scaricabile gratuitamente dagli store Android e iOS. Alcune funzionalità legate alla gestione dell’account, della privacy e della sicurezza saranno disponibili anche tramite applicazione web oltre che tramite applicazione mobile.
IO mette a disposizione degli Enti Erogatori una piattaforma accessibile tramite API (“API IO”) che permette l’integrazione dei propri sistemi e servizi con il progetto IO.
L’applicazione IO rappresenta un canale complementare ai digitali già utilizzati dagli Enti Erogatori, attraverso cui gli enti stessi metteranno a disposizione dell’utente le funzioni descritte in seguito e relative ai propri servizi.
Infine IO si integra all’interno dell’ecosistema pagoPA, diventando a tutti gli effetti l’interfaccia principale di accesso alla piattaforma dei pagamenti e lo strumento principale per la sua diffusione.
IO attraverso un’unica piattaforma applicativa integrata, consente al cittadino di interagire con le amministrazioni italiane, centrali, locali e con tutti gli Enti Erogatori di servizi digitali.
IO assume pertanto un duplice valore: da un lato abilita i soggetti pubblici a utilizzare una serie di funzioni comuni a tutti i servizi digitali, dall’altro offre agli utenti cittadini uno strumento unico per fruire di queste stesse funzioni.
IO, nella sua funzione di punto di accesso, permette all’utente di accedere facilmente e in modalità aggregata alle proprie informazioni e ai servizi digitali che lo riguardano, indipendentemente da quali siano gli Enti Erogatori di suo specifico interesse.
IO non si sostituisce in alcun modo agli Enti Erogatori che rimangono pertanto titolari dei dati in loro possesso, dei relativi trattamenti di dati personali e dell’erogazione dei relativi servizi, che restano nella loro disponibilità esclusiva. Per questo IO si configura semplicemente come un canale supplementare che permette agli utenti di raggiungere - più facilmente e in modalità più razionalizzata - le informazioni e i servizi degli Enti Erogatori.
Ferma ogni possibile implementazione nel tempo da parte della Presidenza del Consiglio dei Ministri di altre funzionalità, allo stato attuale l’applicazione IO si compone di quattro sezioni principali che corrispondono alle funzioni base comuni a molti servizi digitali: Messaggi, Portafoglio, Servizi e Profilo.
L’utente, previo l’opportuno download dell’applicazione in un dispositivo compatibile, potrà accedere ad IO tramite identità digitale SPID o tramite Carta d’Identità Elettronica. Disporre di un account SPID valido o di una CIE sarà quindi condizione necessaria e sufficiente per utilizzare IO.
Il ruolo strategico di IO nella crescita di pagoPA
Il progetto IO assume un ruolo fondamentale per la strategia di crescita e diffusione della piattaforma dei pagamenti pagoPA.
IO è infatti l’interfaccia principale con cui cittadini ed Enti Erogatori interagiscono con la piattaforma dei pagamenti pagoPA, diventando l’attore principale nell’ecosistema pagoPA.
IO è l’interfaccia verso pagoPA
L’app IO: l’interfaccia verso pagoPA per il cittadino
Tramite l’app IO, il cittadino può ricevere in tempo reale avvisi di pagamento digitali dagli Enti e ha la possibilità di effettuare immediatamente il pagamento in pochi “click” e senza mai uscire dall’applicazione.
La semplicità d’uso e la velocità con cui possono essere completate le operazioni di pagamento sono familiari per il cittadino e possono essere considerate alla pari dell’esperienza utente che il cittadino vive all’interno dei più moderni siti di e-commerce.
Le API IO: l’interfaccia verso pagoPA per gli Enti
Tramite le API1 di IO gli enti hanno a disposizione una moderna interfaccia per inviare avvisi di pagamento digitali ai cittadini, con efficacia e semplicità pari alle moderne piattaforme di instant message.
Inoltre tramite le stesse API, l’Ente avrà il pieno controllo dello stato delle posizioni debitorie associate ad ogni cittadino, garantendo che il pagamento corrisponda in ogni momento all’ammontare dovuto.
Questa logica di delega della gestione delle posizioni debitorie solleva gli Enti da complessità e costi di gestione e integrazione dei dati, che vengono forniti direttamente dall’integrazione di IO e pagoPA.
IO è il driver di crescita di pagoPA
Il progetto IO ha come obiettivo una crescita nel triennio 2020-2022 che porterà il bacino di utenza a 5 milioni di utenti attivi per un totale di 150 milioni di avvisi digitali informativi e di pagamento inviati mensilmente dagli Enti Erogatori.
La crescita del bacino di utenza di IO e del volume di avvisi digitali sarà quindi il driver principale per la diffusione e all’utilizzo di pagoPA come principale strumento di pagamento dei tributi da parte del cittadino.
1 Application Programming Interface
IO è il driver per innovare pagoPA
Il progetto IO si pone ambiziosi obiettivi di crescita che possono essere raggiunti attraverso una costante innovazione del prodotto e dell’esperienza utente. Questo forte impulso all’innovazione contribuisce costantemente all’evoluzione della piattaforma dei pagamenti pagoPA.
Alcuni degli obiettivi di prodotto del progetto IO che contribuiranno ad estendere e migliorare le funzionalità di pagoPA (descritti più in dettaglio in seguito, nel piano triennale evolutivo):
● Meccanismo di inoltro degli avvisi digitali di pagamento ai PSP
● Meccanismo di accesso agli avvisi digitali di pagamento ai fini del supporto utente
● Registro centralizzato delle posizioni debitorie
● Micropagamenti
● Borsellino privativo e crediti
Si descrivono di seguito le sezioni principali di cui si compone l’app IO, che corrispondono ad altrettante funzioni disponibili agli Enti Erogatori attraverso le API IO.
Messaggi e avvisi di pagamento
La sezione messaggi consente all’utente di ricevere le comunicazioni a lui indirizzate da parte degli Enti Erogatori che utilizzano le API messe a disposizione dalla piattaforma IO.
Le comunicazioni che l’utente può ricevere comprendono sia messaggi di carattere puramente informativo che messaggi con annessa una richiesta di pagamento (es. un tributo).
L’utente può ordinare e/o filtrare i messaggi ricevuti sulla base di distinti parametri, quali, ad esempio, la data di invio del messaggio, l’identificativo del servizio mittente del messaggio,
l’oggetto indicato nel messaggio, etc. Altri metadati ed altre funzioni di ricerca/ordinamento potranno essere integrate nelle successive versioni dell’applicazione IO.
L’utente, se lo desidera, può beneficiare di ulteriori funzionalità collegate, quali la possibilità di gestire le preferenze di recapito per uno specifico servizio, condividere con terzi il messaggio, ricevere degli avvisi in merito alla scadenza legata al messaggio (nel caso, per esempio, di avvisi di pagamento), etc.
Per gli Enti Erogatori che aderiscono alla piattaforma IO è possibile interrogare un servizio per sapere se uno specifico cittadino si è iscritto ad IO accettando i termini d’uso e se ha espresso delle preferenze relative all’ente stesso (per esempio nel caso in cui il cittadino non voglia più ricevere messaggi dall’ente).
La sezione “portafoglio” dell’app IO è l’interfaccia principale con la quale il cittadino accede ai servizi di pagamento offerti da pagoPA. La sezione portafoglio consente di gestire le transazioni economiche fra il cittadino e lo stato, gestire i propri metodi di pagamento preferiti e di avere a disposizione la lista delle transazioni già eseguite, al pari delle più comuni applicazioni per i servizi di home banking.
Le funzioni di pagamento consentono di eseguire le transazione economiche anche all’interno della stessa applicazione IO.
L’utente potrà trovare nell’applicazione lO storico delle transazioni effettuate tramite pagoPA precedentemente all’iscrizione ad IO.
L’utente può salvare e gestire i metodi di pagamento previsti dal sistema pagoPA.
Tutti i dati relativi ai metodi di pagamento e alle transazioni e operazioni di pagamento effettuate vengono mantenuti all'interno del sistema pagoPA.
La sezione preferenze consente all’utente di impostare quelle scelte di carattere generale che risultano trasversali all’erogazione dei servizi da parte della pubblica amministrazione e verranno usate da IO per personalizzare il servizio erogato al cittadino.
Alcune di queste informazioni, una volta inserite dall’utente potranno essere interrogate e utilizzate in tempo reale dagli Enti Erogatori che aderiscono a IO in modo da poter fornire al cittadino un'esperienza personalizzata anche all’interno dei servizi erogati direttamente dall’Ente. Per esempio la lingua con cui l’Ente comunica con il cittadino può essere impostata automaticamente leggendo la relativa preferenza che il cittadino ha espresso all’interno dell’app IO.
Di seguito, si riportano a titolo di esempio alcune preferenze che potranno essere definite dell’utente:
● Lingua preferita;
● email personale dell’utente;
● telefono personale dell’utente;
● elenco dei servizi che l’utente ha disattivato2;
A ciascun Ente Erogatore sarà chiesto di fornire un insieme base di informazioni che comporranno una scheda ente e un equivalente insieme di informazioni base per ciascuno dei servizi che usano le funzioni di IO. Queste informazioni potranno essere esposte in IO all’interno di una sezione dedicata a ciascun ente/servizio, collegata alle preferenze di quel servizio stesso.
La sezione Profilo, consente all’utente di avere un riepilogo delle informazioni più tipicamente legate alla propria identità SPID e CIE. In questa sezione, infatti, l’utente potrà accedere e verificare i dati anagrafici acquisiti da IO tramite l'accesso effettuato con SPID o CIE.
Nella sezione Profilo l’utente può gestire eventuali strumenti complementari di identificazione e sicurezza quali PIN o, se abilitati dall’utente sul proprio dispositivo, strumenti di identificazione biometrica.
L'utente potrà inoltre visualizzare uno storico degli accessi ed interrompere la sessione attualmente attiva sull’applicazione.
Infine, nella sezione profilo l’utente potrà:
● verificare i termini e condizioni d’uso del servizio in vigore;
● consultare le informative sul trattamento dei dati personali degli Enti Erogatori e un'informativa relativa ai servizi offerti direttamente da IO;
● chiedere la sospensione dell’account o la completa cancellazione dello stesso.
Le API IO per gli Enti Erogatori
API per la lettura delle Preferenze
Questa funzionalità permette ad un Ente Erogatore la lettura di un gruppo limitato di preferenze espresse dal cittadino all'interno di IO.
Le preferenze condivise con gli Enti non contengono informazioni personali o sensibili ma sono assimilabili a semplici indicazioni che il cittadino vuole condividere con gli Enti per essere usate come base per la personalizzazione dei servizi digitali.
Un servizio digitale fornito dall'Ente al cittadino può interrogare le preferenze condivise del cittadino sulla base del codice fiscale dello stesso e usare le informazioni ottenute per fornire un servizio personalizzato, ad esempio traducendo l'interfaccia utente del servizio fornito al cittadino sulla base della preferenza di lingua.
La funzione Preferenze può inoltre essere utilizzata dal servizio dell'ente per sapere se il cittadino non intende ricevere comunicazioni dal servizio (opt-out). Questa verifica è
2 Un Ente può accedere a questa informazione solo limitatamente ai servizi che gli competono
richiesta all'ente, prima dell'invio di una comunicazione al cittadino attraverso la funzione
Messaggi.
API per l’invio di Messaggi e Avvisi di Pagamento
La funzionalità Messaggi permette agli Enti Erogatori di inviare comunicazioni di cortesia e avvisi di pagamento ai cittadini.
Le comunicazioni di cortesia sono sempre inviate ad uno specifico cittadino (identificato tramite codice fiscale) e scaturiscono da una pregressa relazione individuale tra l'Ente e il cittadino. Da queste comunicazioni sono quindi escluse comunicazioni non personali (ovvero la stessa comunicazione inviata a più di un cittadino).
API per l’integrazione con pagoPA
La funzionalità Portafoglio fornisce la possibilità di pagare quanto dovuto tramite gli strumenti di pagamento forniti da pagoPA. L'applicazione comunica direttamente con i sistemi di pagoPA sia per quando riguarda operazioni di pagamento sia per quanto riguarda l'interazione con il profilo utente in cui viene registrato lo storico delle transazioni.
Grazie al processo di riconciliazione del profilo descritto di seguito, se un cittadino, che già possiede un'utenza pagoPA, accede all'app di IO, ritroverà nell'app i metodi di pagamento e le transazioni effettuate fino a quel momento.
Le preferenze di pagamento gestite dal Wallet di pagoPA vengono associate ad un indirizzo email, si richiede quindi un meccanismo di riconciliazione tra i profili dei cittadini registrati sul Wallet di pagoPA e i cittadini che accedono all'app IO.
Questo meccanismo di riconciliazione si basa sulla comparazione dell'indirizzo email fornito dal cittadino.
Nel caso sia presente nel Wallet, un profilo associato all'email del cittadino, le interazioni con il Wallet attraverso l'app verranno registrate esattamente come se avvenissero da una qualsiasi app che integra l'SDK di pagoPA.
Questo meccanismo permette al cittadino di riutilizzare il suo profilo pagoPA dall'app IO in modo totalmente trasparente.
Nel caso non sia presente nel Wallet, un profilo associato all'email del cittadino, il Wallet pagoPA provvederà a creare un nuovo profilo all'inserimento del primo metodo di pagamento.
Per l'invio di un avviso di pagamento digitale ad un cittadino da parte di un servizio, viene usato il meccanismo dell'invio di un messaggio tramite l'API di IO.
Per quanto riguarda il pagamento di avvisi di pagamento cartacei, il cittadino potrà effettuare il pagamento leggendo il codice QR stampato sull'avviso o inserendo manualmente il Numero Avviso stampato anch'esso sull'avviso.
Il flusso di verifica ed attualizzazione dell'avviso di pagamento viene iniziato dall'app IO ogni volta che viene presentato l'ammontare attualizzato corrispondente all'avviso di pagamento (tipicamente questo avviene come primo passo del flusso di pagamento di un avviso).
Il flusso di pagamento viene iniziato dall'app IO ed è composto da due fasi distinte:
● L'app IO interagisce con il nodo pagoPA attraverso la piattaforma IO per ottenere l'identificativo di pagamento associato all'avviso di pagamento.
● l'app IO interagisce con il Wallet pagoPA per eseguire la transazione di pagamento a partire dall'identificativo di pagamento ottenuto al passo precedente.
Dopo che la transazione di pagamento dell'avviso viene ricevuta dal Wallet pagoPA, l'app IO interagisce nuovamente con il Wallet per recuperare lo storico delle transazioni. Lo storico conterrà l'esito della transazione appena eseguita, sotto forma di ricevuta di pagamento da presentare al cittadino.
L'app IO permette al cittadino di visualizzare lo storico delle transazioni effettuate tramite pagoPA. Tramite il codice univoco pagamento l'app IO può riconciliare la transazione con il relativo avviso digitale di pagamento (nel caso in cui la transazione sia scaturita da un messaggio indirizzato al cittadino).
Meccanismo di inoltro degli avvisi digitali di pagamento ai PSP
Le API di IO permettono agli enti di inviare messaggi informativi ai cittadini che hanno installato l’app IO. I messaggi informativi possono, opzionalmente, contenere informazioni relative ad un pagamento pagoPA.
Si intende evolvere questo meccanismo per permettere ad un PSP di recuperare gli avvisi di pagamento inviati dagli Enti Creditori ad IO e indirizzati agli utenti che abbiano sottoscritto il servizio.
Meccanismo di accesso agli avvisi digitali di pagamento ai fini del supporto utente
Gli avvisi digitali di pagamento inviati dagli Enti Creditori attraverso le API di IO saranno disponibili per il servizio assistenza pagoPA per tracciare le operazioni di pagamento e risolvere eventuali anomalie.
Registro centralizzato delle posizioni debitorie
Nel contesto dell’evoluzione di pagoPA, viene proposto di evolvere il modello pull in cui il nodo pagoPA va a recuperare i dati della posizione debitoria necessari al pagamento dai sistemi dell’Ente Creditore verso un modello in cui l’Ente Creditore invia preventivamente le informazioni necessarie al pagamento ad un registro centralizzato delle posizioni debitorie, gestito dal nodo pagoPA (modello push).
In questo nuovo scenario, l’ente creditore (ente creditore delegato) ha la responsabilità di mantenere aggiornate le informazioni relative a ogni posizione debitoria di sua pertinenza all’interno del registro delle posizioni debitorie.
Durante il flusso di pagamento, il nodo pagoPA andrà a interpellare il registro per recuperare le informazioni necessarie al perfezionamento del pagamento.
È in previsione l’analisi di fattibilità ed eventuale evoluzione dei modelli di pagamento pagoPA per fornire un nuovo modello che permetta micropagamenti nel contesto del Trasporto Pubblico Locale, Parcheggi, etc…
Borsellino privativo e crediti
È in previsione l’analisi di fattibilità ed eventuale implementazione di un meccanismo che permetta agli Enti Erogatori che si occupano di welfare di distribuire crediti ai cittadini, utilizzabili a determinate condizioni (per es. 18app, carta del docente, bonus mamma) o convertibili in moneta corrente.
Arricchimento dell’integrazione con pagoPA
Integrazione di Bancomat Pay, Paypal, Satispay tutti gli altri metodi di pagamento presenti oggi o in futuro in pagoPA che consentano una ottimale esperienza mobile.
Meccanismi per tracciare i pagamenti avvenuti, così da marcare i relativi messaggi come pagati.
Meccanismi di condivisione delle ricevute.
Arricchimento della funzionalità Preferenze
Integrazione dei campi IBAN, l’indirizzo email con relativo flusso di validazione, etc. La funzionalità va resa il più possibile astratta in modo da rendere flessibile l’aggiunta di nuove preferenze.
Dovranno essere analizzate e valutate le seguenti possibilità:
● permettere agli enti di inserire in alcuni messaggi delle call-to-action per chiedere all’utente di impostare determinate preferenze;
● prevedere un meccanismo che consenta di notificare all’ente nel momento in cui un utente ha impostato una preferenza.
● prevedere un meccanismo che notifichi al cittadini l’avvenuta interrogazione di una delle sue preferenze da parte di un ente, che gli consenta di conoscerne il motivo o di inibirne l’accesso.
Vanno previsti flussi dedicati al cambio del numero di telefono e dell’email, con relative verifiche.
Implementazione della funzionalità Documenti
Supporto all’analisi della funzionalità che consente agli enti di condividere, inviare ed esporre documenti ai cittadini.
Implementazione di due modelli di storage del documento:
● Push: il documento, come fosse l’allegato ad un messaggio, viene inviato al back- end di IO e finisce nell’archivio
● Pull: il documento è presente nell’archivio solo sotto forma di titolo e metadati, ma il documento vero e proprio viene richiesto dall’app al sistema della PA in cui risiede nel momento in cui il cittadino lo richiede esplicitamente.
I documenti avranno dei metadati che ne facilitino l’indicizzazione (la tipologia, la scadenza, il link al documento originale presso il servizio che l’ha generato). Al documento potrebbe essere associate una anteprima generata dalla app.
È necessario prevedere la possibilità per gli enti di mettere a disposizione automaticamente ai cittadini che hanno installato l’app dei documenti che li riguardano.
Alcuni documenti potranno essere richiesti direttamente dal cittadino in base allo specifico ciclo di vita dei documenti (ad esempio: quali documenti devono rimanere online e per quanto tempo, se e quando e in che formato il documento va archiviato, quali sono le procedure per portare online un documento archiviato, se e quando i documenti archiviati possono essere cancellati).
Implementazione della funzionalità Profilo
La sezione Profilo deve consentire gli adempimenti da GDPR: esportazione dei dati, cancellazione dell’account. Inoltre vanno gestite le opzioni di sicurezza (cambio pass-code, attivazione/disattivazione biometrico), storico delle sessioni.
Nel modello iniziale, la piattaforma di messaggistica è stata progettata per mantenere un archivio in chiaro dei messaggi ricevuti da un cittadino da parte delle pubbliche amministrazioni, con l’intento di rendere i messaggi accessibili sia da device mobili che da applicazioni web.
Mantenere il contenuto dei messaggi in chiaro ha un impatto sulla sicurezza e la privacy dei cittadini. Per alcune tipologie di messaggi (es. sanità) dovrà essere analizzata e valutata l’implementazione di uno schema di crittografia dei messaggi per permettere, tra le altre cose, di evitare di tenere il contenuto dei messaggi in chiaro sui server di IO.
Dovranno essere esplorate soluzioni tecniche già utilizzate da altri sistemi di messaggistica (es. Whatsapp, iMessage, Telegram) per l’implementazione di un meccanismo di criptazione dei messaggi end-to-end per annullare o minimizzare i rischi di privacy dei cittadini.
Implementazione dell’integrazione con ANPR
Integrazione con ANPR. Visura dei dati anagrafici, che andrebbero esposti nella sezione profilo. Richiesta, pagamento e generazione di certificati anagrafici dalla sezione documenti.
I certificati potrebbero essere a pagamento (bolli o costi di segreteria) e potrebbero dover essere configurati (in semplice wizard di configurazione) prima di essere pagati/generati.
La generazione e richiesta di certificati dovrebbe essere il più possibile generalizzata.
Sviluppo del portale self-care web
Sviluppo del portale di self-care, accessibile via browser web, rivolto ai cittadini registrati per lo svolgimento di alcune specifiche funzionalità. Le attività si rivolgono sia allo sviluppo, che al supporto funzionale e architetturale.
Nell’area dedicata ai cittadini, che andrà pubblicata su xxxxx://xx.xxxxxx.xx, il cittadino deve poter svolgere le seguenti funzioni:
● Entrare con SPID;
● Verificare lo storico degli accessi;
● Verificare i dispositivi in cui sia stato usato il proprio account;
● Far cadere l’eventuale sessione attiva sul dispositivo;
● Esportare i dati relativi al proprio account in formato aperto;
● Vedere termini e condizioni d’uso e privacy policy;
● Cancellare il proprio account;
● Accedere all’assistenza dell’app;
● Uscire dal self-care.
Integrazione della tracking strategy
Tutte le funzionalità sviluppate devono essere integrate con il tool scelto per la tracking strategy (Mixpanel). Devono essere generati eventi per ogni step significativo dell’esperienza utente.
Implementare meccanismi di telemetria dell’infrastruttura applicativa (utilizzo, performance, sicurezza).
Implementazione dei processi per lo svolgimento di system test, integration test (app mobile: vanno predisposti test automatizzati dell’app su device virtuali; back-end: vanno implementati dei test di integrazione ed end-to-end tra le varie componenti dell’infrastruttura applicativa) e user acceptance test.
Implementazione meccanismi di gestione delle quote di utilizzo delle API
Progettazione, definizione e analisi per l’implementazione di meccanismi e logiche di gestione delle quote e dei limiti per servizio (legati al monitoraggio e gestibili via admin) e del relativo enforcement.
Evoluzione dei meccanismi di autenticazione delle API
Attività legate alla sicurezza, integrità e non ripudiabilità delle comunicazioni (Es.: mutua autenticazione via certificati, firma HMAC).
Gestione dei token autorizzativi (Es.: modalità di attivazione dei servizi via token, manutenzione dei token, dove sono archiviati, chi li genera, chi li può utilizzare).
Le API di IO vengono chiamate dai servizi erogati dagli enti attraverso delle chiamate HTTPS autenticate tramite chiave API, fornita dal servizio ad ogni richiesta sotto forma di autenticazione bearer.
Per incrementare la sicurezza, si propone di implementare uno schema di firma delle chiamate API di IO tramite HMAC.
Alcuni enti invieranno grandi volumi di messaggi (milioni al giorno), anche in singoli batch. Il modello implementato dalle API attuali è strutturato per l’invio di un singolo messaggio a chiamata. È quindi necessario implementare dei meccanismi di invio batch per ottimizzare gli scenari di invio massivo.
È in previsione l’analisi di fattibilità ed eventuale implementazione di un meccanismo che permetta agli Enti Erogatori che si occupano di sicurezza pubblica di inviare messaggi a gruppi di cittadini basati sulla presenza o l'ingresso in un una determinata area geografica.
Configurazione degli ambienti di staging, consolidamento della configurazione terraform ed evoluzione per gestire ambienti multipli, gestione dei secrets in modo sicuro. L’obiettivo di queste attività è quello di gestire la disponibilità, le prestazioni, il monitoraggio e la risposta agli incidenti delle piattaforme e dei servizi di IO.
Review delle metriche da monitorare a livello applicativo e infrastrutturale, configurazione di dashboard di monitoraggio e relativi alert.
L’obiettivo è di monitorare le metriche possibili all'interno di IO in modo da avere una comprensione precisa della salute del sistema in ogni momento. Una pratica comune è quella di monitorare le metriche specifiche, impostare le soglie e attivare gli avvisi in base a tali soglie.
Resa dell’infrastruttura ridondante (multi-regione)
Adeguamento dell’infrastruttura verso la ridondanza multi-regione per la gestione del disaster recovery e il servizio ad alta disponibilità.
Implementazione di strumenti a supporto della gestione e conduzione
Implementazione di applicazioni web a supporto della gestione, amministrazione e conduzione dei servizi offerti da IO agli Enti Erogatori. In pratica si tratterà di creare un portale di back-office di amministrazione con una dashboard per:
● Monitoraggio delle attività sull’app;
● Monitoraggio dei volumi dei messaggi inviati e delle quote di utilizzo delle API.
Consolidamento del flusso di on-boarding delle PA
Consolidare il flusso di on-boarding delle PA tramite un portale di self-care per gli Enti Erogatori che offra le seguenti funzionalità:
● La registrazione dei servizi;
● La modifica di un servizio registrato (logo, descrizione);
● La messa in pausa o disattivazione di un servizio.
Attività di supporto di primo livello agli utenti via call-center e servizio integrato nell’app (chat) per un numero di circa 300 interazioni al giorno in media.
La gestione e lo sviluppo del progetto IO, dovrà gradualmente utilizzare risorse umane dedicate, attraverso una struttura organizzativa in grado di garantire il raggiungimento degli obiettivi di prodotto e di crescita, nonché la conduzione del servizio secondo i più alti standard di efficienza e sicurezza.
Per raggiungere questi obiettivi, la struttura organizzativa dedicata al progetto deve dotarsi delle seguenti figure professionali:
● Chief Operation Officer
● Mobile Development Lead
● Web Development Lead
● Backend Development Lead
● DevOps/SRE Lead
● Service Design/User Research Lead
● UX/UI Designer Lead
Approvvigionamento risorse esterne
Per raggiungere gli obiettivi di sviluppo di prodotto e di crescita, la struttura organizzativa dedicata al progetto dovrà dotarsi di una serie di figure professionali acquisite tramite i meccanismi di approvvigionamento CONSIP.
Tipologia di figura FTE
Software developer 18
Designer 3
Addetto al customer care 5
Di seguito si riportano le previsioni di spesa per il raggiungimento degli obiettivi del progetto IO.
Voce | Importo netto IVA | IVA | Importo lordo IVA |
Infrastruttura cloud | € 245.901,64 | €54.098 | € 300.000 |
Licenze software | € 49.180,33 | €10.820 | € 60.000 |
Servizi di sviluppo | € 1.754.098,36 | € 385.902 | €2.140.000 |
Totale | € 2.049.180,33 | €450.820 | € 2.500.000 |
All.3 Livelli di servizio e Obiettivi - progetto PDND
Livelli di Servizio e Obiettivi
Livelli di servizio
Servizio | Valore di Soglie (obiettivo) | Metodologia di Calcolo | Unità temporale di calcolo | |
1 | Tempo di risposta API pubbliche | 95% delle richieste (su campione orario) viene soddisfatto correttamente (HTTP codes 200-400) entro 1.5 secondi | Il numero viene calcolato, attraverso appositi strumenti di monitoraggio disponibili in pagoPA, che consentano di rilevare i tempi di risposta delle API pubbliche | Giornaliera |
Funzionalità Applicative | ||||
2 | Errori nell’interfaccia delle API | Numero medio di errori applicativi inferiori a 0,001 su richieste. | tra le richieste gestite in modo conforme alle specifiche delle API e le richieste totali calcolato su range giornaliero | giorno |
3 | Disponibilità della funzionalità di caricamento dataset. | La disponibilità del servizio sarà del 99,9% su base mensile | La disponibilità del sistema verrà misurata mediante una sonda posta all’esterno in un punto terzo. | mensile |
4 | Disponibilità della funzionalità di lettura dei dataset. | La disponibilità del servizio sarà del 99,9% su base mensile | La disponibilità del sistema verrà misurata mediante una sonda posta all’esterno in un punto terzo. | mensile |
Gestione del ciclo di vita del software | ||||
5 | Mitigazione compromissione del sistema o leak di dati personali | Presa in carico e mitigazione entro le 24 H | Per presa in carico e mitigazione si intende: ● redazione di un incident report ● chiusura e blocco accessi compromessi ● chiusura utenze affette e analisi degli eventuali data leak Queste comunicazioni dovranno essere inviate al Dipartimento | mensile |
Affidabilità sistemi | ||||
6 | Estrazioni e statistiche su utilizzo di API e Applicazione per il Dipartimento | Entro 2 giorni lavorativi | Mese | |
7 | Tempo di mitigazione di un bug bloccante | entro 1 giorno lavorativo | Si intende bug bloccante quello che impedisce il corretto utilizzo del servizio; Per mitigazione si intende il rilascio di un hot fix che consenta di non bloccare l’utilizzo del servizio | mese |
8 | Tempo di rilascio di un bug fix per bug bloccante | entro 2 giorni lavorativi | Si intende bug bloccante quello che impedisce il corretto utilizzo del servizio; Può essere concordato tra le parti un intervallo superiore per interventi la cui soluzione richiede modifiche strutturali | mese |
9 | Disponibilità degli esiti delle elaborazioni di operazioni asincrone (batch) | Elaborazione entro le 24 ore dalla richiesta | mese | |
10 | Tempo di triage github - tempo perché pagoPA legga un ticket, assegni un livello | Entro 1 giorno lavorativo nel 99% dei casi. | Data di assegnazione o data di commento o data di chiusura del ticket inferiore ad un giorno lavorativo. Il servizio si intende garantito dal lunedì al | mese |
di priorità ed una persona in grado di rispondere e/o risolvere il problema. | venerdì dalle 9.30 alle 17.30. | |||
11 | Tempo di risoluzione di ticket di priorità media (non bloccante) | 2 giorni lavorativi nel 99% casi | Tempo di chiusura ticket o di commento con soluzione indicata Il servizio si intende garantito dal lunedì al venerdì dalle 9.30 alle 17.30. Chiudere il ticket perché duplicato, già risolto, impropriamente inviato, etc. costituisce risoluzione del ticket. | mese |
12 | Tempo di risoluzione di ticket di priorità bassa (non bloccante) | 5 giorni lavorativi nel 99% casi | Tempo di chiusura del ticket rispetto alla sua apertura Il servizio si intende garantito dal lunedì al venerdì dalle 9.30 alle 17.30. | mese |
Obiettivi di sviluppo
Obiettivo | Descrizione | |
Evoluzione applicativa | ||
1 | Identity Management | Implementazione del nuovo sistema di Identity Management della piattaforma Azure per quanto riguarda le utenze della Pubblica Amministrazione, il quale si integra nativamente con i tools e servizi utilizzati dalla nuova piattaforma. Studio dell’integrazione con un sistema di Identity Management aperto per consentire ai cittadini di registrarsi alle applicazioni che trattano i soli Dati Aperti. Questo studio potrebbe portare all’utilizzo del sistema di autenticazione già in adottato dalla piattaforma IO. Integrazione con sistema di autenticazione via SPID ( da sfruttare gli sviluppi che Microsoft ha già fatto con altre PA ) |
2 | Data Governance Framework | ● PDND Auditing Framework : Auditing dei dati / Tracciabilità delle modifiche / Generazione Eventi / Monitoring e Visualizzazione ● IA a supporto dell'adempimento alle regole sulla gestione e protezione dei dati ( GDPR ) ○ Diritto all'oblio ○ Anonimizzazione e Differential Privacy ○ Condivisione dei Dati controllata ○ Implementazione DPIA su Ingestione dei Dati ○ Rilevamento delle Anomalie |
3 | Data Ingestion / ETL | Consolidare la piattaforma di Ingestion ed Export di Dati per consentire alle PA una procedura “Self-Service” per l’ingestion e condivisione di dati di qualsiasi formato supportati da una piattaforma BPM ( Business Process Management ) che ne guida i vari step includendo tutte le fasi di Impact Assessment per la GDPR |
4 | Data Science / Analytics Platform | E’ necessario il consolidamento della nuova piattaforma integrata “Azure DataBricks” per lo sviluppo ed implementazione controllata di modelli AI sempre più precisi e dettagliati. |
5 | Business Intelligence & Data Visualization | Consolidamento dei nuovi tools di BI e Visualizzazione per consentire a fornitori ed utilizzatori del servizio pagoPA di accedere ai dati aperti relativi a transazioni in modalità self-service |
6 | Piattaforma creazione Data Stories | Tool per la creazione di “Storie sui Dati” , nuova integrazione con Azure DataBricks e PoweBI Embedded sia per la presentazione e condivisione dei modelli di analisi dati, che presentazione dei dati in un contesto giornalistico |
7 | Sviluppo API Pubbliche e Private | Possibilità di sviluppare API ad-hoc su richiesta di organizzazioni pubbliche e private per rendere più efficiente la comunicazione dei dati ed eventualmente integrarla con sistemi di terze parti, sempre in rispetto delle regolamentazioni GDPR e del trattamento dei dati della Pubblica Amministrazione Implementazione della gestione e controllo delle quote di utilizzo delle API |
8 | UI UX User Interface and User Experience Enhancements | Evoluzione della nuova interfaccia Web/FrontEnd della PDND “PDND UI” Creazione di un portale di “Onboarding” per le pubbliche amministrazioni che vogliono aderire al progetto Evoluzione del nuovo portale PDND ( PDND UI ) per sfruttare le funzionalità del Cloud |
9 | Interfaccia Mobile - Integrazione con piattaforma IO | Integrazione con la piattaforma IO per permettere la sottoscrizione a canali di pubblicazione dati aperti di principale interesse per l’utente Può essere la stessa piattaforma PDND ad erogare servizi attraverso IO, in termini di informazioni derivate dai dati pubblici e aperti presenti nella piattaforma che possono essere di interesse al singolo cittadino o all’utente della pubblica amministrazione |
10 | Open Data as a Service | Sviluppo nuovo portale “Open Data” as a Service , che consentirà le piccole Pubbliche Amministrazioni di configurare un proprio portale Open Data sulla base di quello fornito dalla PDND , ma dove i contenuti sono di esclusivo interesse della Pubblica Amministrazione che lo ha generato. |
11 | TimeSeries Data Integration, IoT | L’implementazione dell’ ingestion di dati in tempo reale è un requisito fondamentale per completare le tipologie di dati di interesse per la Pubblica Amministrazione ed i cittadini. Mentre le singole Pubbliche Amministrazioni possono collezionare dati real-time con un dettaglio molto elevato, la PDND può funzionare da collettore per ricevere ed archiviare informazioni di più alto livello, utili per i modelli di aggregazione con dati già presenti . |
Infrastruttura cloud | ||
17 | Configurazioni sistemistiche | Configurazione degli ambienti di staging, consolidamento della configurazione terraform ed evoluzione per gestire ambienti multipli, gestione dei secrets in modo sicuro. L’obiettivo di queste attività è quello di gestire la disponibilità, le prestazioni, il monitoraggio e la risposta agli incidenti delle piattaforme e dei servizi di PDND. |
18 | Monitoraggio | Review delle metriche da monitorare a livello applicativo e infrastrutturale, configurazione di dashboard di monitoraggio e relativi alert. L’obiettivo è di monitorare le metriche possibili all'interno di PDND in modo da avere una comprensione precisa della salute del sistema in ogni momento. Una pratica comune è quella di monitorare le metriche specifiche, impostare le soglie e attivare gli avvisi in base a tali soglie. |
19 | Resa dell’infrastruttura ridondante (multi-regione) | Adeguamento dell’infrastruttura verso la ridondanza multi-regione per la gestione del disaster recovery e il servizio ad alta disponibilità. |
All.4 Livelli di servizio e Obiettivi - progetto IO
Livelli di Servizio e Obiettivi
Livelli di servizio
Servizio | Valore di Soglie (obiettivo) | Metodologia di Calcolo | Unità temporale di calcolo | |
1 | Tempo di risposta API pubbliche | 95% delle richieste (su campione orario) viene soddisfatto correttamente (HTTP codes 200-400) entro 1.5 secondi | Il numero viene calcolato, attraverso appositi strumenti di monitoraggio disponibili in pagoPA, che consentano di rilevare i tempi di risposta delle API pubbliche | Giornaliera |
Funzionalità Applicative | ||||
2 | Errori delle API | Numero medio di errori applicativi inferiori a 0,001 su richieste. | tra le richieste gestite in modo conforme alle specifiche delle API e le richieste totali calcolato su range giornaliero | giorno |
3 | Disponibilità della funzionalità di presa in carico dei messaggi. | La disponibilità del servizio sarà del 99,9% su base mensile | La disponibilità del sistema verrà misurata mediante una sonda posta all’esterno in un punto terzo. | mensile |
4 | Disponibilità della funzionalità di lettura dei messaggi. | La disponibilità del servizio sarà del 99,9% su base mensile | La disponibilità del sistema verrà misurata mediante una sonda posta all’esterno in un punto terzo. | mensile |
Gestione del ciclo di vita del software | ||||
5 | Mitigazione compromissione del sistema o leak di dati personali | Presa in carico e mitigazione entro le 24 H | Per presa in carico e mitigazione si intende: ● redazione di un incident report ● chiusura e blocco accessi compromessi ● chiusura utenze affette e analisi degli eventuali data leak Queste comunicazioni dovranno essere inviate al Dipartimento | mensile |
Affidabilità sistemi | ||||
6 | Estrazioni e statistiche su utilizzo di API e Applicazione per il Dipartimento | Entro 2 giorni lavorativi | Mese | |
7 | Tempo di mitigazione di un bug bloccante | entro 1 giorno lavorativo | Si intende bug bloccante quello che impedisce il corretto utilizzo del servizio; Per mitigazione si intende il rilascio di un hot fix che consenta di non bloccare l’utilizzo del servizio | mese |
8 | Tempo di rilascio di un bug fix per bug bloccante | entro 2 giorni lavorativi | Si intende bug bloccante quello che impedisce il corretto utilizzo del servizio; Può essere concordato tra le parti un intervallo superiore per interventi la cui soluzione richiede modifiche strutturali | mese |
9 | Disponibilità degli esiti delle elaborazioni di operazioni asincrone (batch) | Elaborazione entro le 24 ore dalla richiesta | mese | |
Tempo di triage | Entro 1 giorno lavorativo | Data di assegnazione o data di | mese | |
10 | Instabug - tempo perché pagoPA legga un ticket, assegni un livello di priorità ed una persona in grado di rispondere e/o risolvere il problema. | nel 99% dei casi. | commento o data di chiusura del ticket inferiore ad un giorno lavorativo. Il servizio si intende garantito dal lunedì al venerdì dalle 9.30 alle 17.30. | |
11 | Tempo di risoluzione di ticket di priorità media (non bloccante) | 2 giorni lavorativi nel 99% casi | Tempo di chiusura ticket o di commento con soluzione indicata Il servizio si intende garantito dal lunedì al venerdì dalle 9.30 alle 17.30. Chiudere il ticket perché duplicato, già risolto, impropriamente inviato, etc. costituisce risoluzione del ticket. | mese |
12 | Tempo di risoluzione di ticket di priorità bassa (non bloccante) | 5 giorni lavorativi nel 99% casi | Tempo di chiusura del ticket rispetto alla sua apertura Il servizio si intende garantito dal lunedì al venerdì dalle 9.30 alle 17.30. | mese |
Obiettivi di sviluppo
Obiettivo | Descrizione | |
Evoluzione ecosistema pagoPA | ||
1 | Meccanismo di inoltro degli avvisi digitali di pagamento ai PSP | Le API di IO permettono agli enti di inviare messaggi informativi ai cittadini che hanno installato l’app IO. I messaggi informativi possono, opzionalmente, contenere informazioni relative ad un pagamento pagoPA. Si intende evolvere questo meccanismo per permettere ad un PSP di recuperare gli avvisi di pagamento inviati dagli Enti Creditori ad IO e indirizzati agli utenti che abbiano sottoscritto il servizio. |
2 | Meccanismo di accesso agli avvisi digitali di pagamento ai fini del supporto utente | Gli avvisi digitali di pagamento inviati dagli Enti Creditori attraverso le API di IO saranno disponibili per il servizio assistenza pagoPA per tracciare le operazioni di pagamento e risolvere eventuali anomalie. |
3 | Registro centralizzato delle posizioni debitorie | Nel contesto dell’evoluzione di pagoPA, viene proposto di evolvere il modello pull in cui il nodo pagoPA va a recuperare i dati della posizione debitoria necessari al pagamento dai sistemi dell’Ente Creditore verso un modello in cui l’Ente Creditore invia preventivamente le informazioni necessarie al pagamento ad un registro centralizzato delle posizioni debitorie, gestito dal nodo pagoPA (modello push). In questo nuovo scenario, l’ente creditore (ente creditore delegato) ha la responsabilità di mantenere aggiornate le informazioni relative a ogni posizione debitoria di sua pertinenza all’interno del registro delle posizioni debitorie. Durante il flusso di pagamento, il nodo pagoPA andrà a interpellare il registro per recuperare le informazioni necessarie al perfezionamento del pagamento. |
4 | Micropagamenti | È in previsione l’analisi di fattibilità ed eventuale evoluzione dei modelli di pagamento pagoPA per fornire un nuovo modello che permetta micropagamenti nel contesto del Trasporto Pubblico Locale, Parcheggi, etc… |
5 | Borsellino privativo e crediti | È in previsione l’analisi di fattibilità ed eventuale implementazione di un meccanismo che permetta agli Enti Erogatori che si occupano di welfare di distribuire crediti ai cittadini, utilizzabili a determinate condizioni (per es. 18app, carta del docente, bonus mamma) o convertibili in moneta corrente. |
Evoluzione app e API IO | ||
6 | Arricchimento dell’integrazione con pagoPA | Integrazione di Bancomat Pay. Meccanismi per tracciare i pagamenti avvenuti, così da marcare i relativi messaggi come pagati. |
7 | Arricchimento della funzionalità Preferenze | Integrazione dei campi IBAN, l’indirizzo email con relativo flusso di validazione, etc. La funzionalità va resa il più possibile astratta in modo da rendere flessibile l’aggiunta di |
nuove preferenze. Vanno previsti flussi dedicati al cambio del numero di telefono e dell’email, con relative verifiche. | ||
8 | Implementazione della funzionalità Documenti | Supporto all’analisi della funzionalità che consente agli enti di condividere, inviare ed esporre documenti ai cittadini. Valutazione di due modelli di storage del documento: ● Push: il documento, come fosse l’allegato ad un messaggio, viene inviato al back-end di IO e finisce nell’archivio ● Pull: il documento è presente nell’archivio solo sotto forma di titolo e metadati, ma il documento vero e proprio viene richiesto dall’app al sistema della PA in cui risiede nel momento in cui il cittadino lo richiede esplicitamente. I documenti avranno dei metadati che ne facilitino l’indicizzazione (la tipologia, la scadenza, il link al documento originale presso il servizio che l’ha generato). Al documento potrebbe essere associate una anteprima generata dalla app. È necessario prevedere la possibilità per gli enti di mettere a disposizione automaticamente ai cittadini che hanno installato l’app dei documenti che li riguardano. Alcuni documenti potranno essere richiesti direttamente dal cittadino in base allo specifico ciclo di vita dei documenti (ad esempio: quali documenti devono rimanere online e per quanto tempo, se e quando e in che formato il documento va archiviato, quali sono le procedure per portare online un documento archiviato, se e quando i documenti archiviati possono essere cancellati). |
9 | Implementazione della funzionalità Profilo | La sezione Profilo deve consentire gli adempimenti da GDPR: esportazione dei dati, cancellazione dell’account. Inoltre vanno gestite le opzioni di sicurezza (cambio pass- code, attivazione/disattivazione biometrico), storico delle sessioni. |
10 | Cifratura dei Messaggi | Nel modello iniziale, la piattaforma di messaggistica è stata progettata per mantenere un archivio in chiaro dei messaggi ricevuti da un cittadino da parte delle pubbliche amministrazioni, con l’intento di rendere i messaggi accessibili sia da device mobili che da applicazioni web. Mantenere il contenuto dei messaggi in chiaro ha un impatto sulla sicurezza e la privacy dei cittadini. Per alcune tipologie di messaggi (es. sanità) dovrà essere analizzata e valutata l’implementazione di uno schema di crittografia dei messaggi per permettere, tra le altre cose, di evitare di tenere il contenuto dei messaggi in chiaro sui server di IO. Dovranno essere esplorate soluzioni tecniche già utilizzate da altri sistemi di messaggistica (es. Whatsapp, iMessage, Telegram) per l’implementazione di un meccanismo di criptazione dei messaggi end-to-end per annullare o minimizzare i rischi di privacy dei cittadini. |
11 | Implementazione dell’integrazione con ANPR | Integrazione con ANPR. Visura dei dati anagrafici, che andrebbero esposti nella sezione profilo. Richiesta, pagamento e generazione di certificati anagrafici dalla sezione documenti. I certificati potrebbero essere a pagamento (bolli o costi di segreteria) e potrebbero dover essere configurati (in semplice wizard di configurazione) prima di essere pagati/generati. La generazione e richiesta di certificati dovrebbe essere il più possibile generalizzata. |
12 | Sviluppo del portale self-care web | Sviluppo del portale di self-care, accessibile via browser web, rivolto ai cittadini registrati per lo svolgimento di alcune specifiche funzionalità. Le attività si rivolgono sia allo sviluppo, che al supporto funzionale e architetturale. Nell’area dedicata ai cittadini, che andrà pubblicata su xxxxx://xx.xxxxxx.xx, il cittadino deve poter svolgere le seguenti funzioni: ● Entrare con SPID; ● Verificare lo storico degli accessi; ● Verificare i dispositivi in cui sia stato usato il proprio account; ● Far cadere l’eventuale sessione attiva sul dispositivo; ● Esportare i dati relativi al proprio account in formato aperto; ● Vedere termini e condizioni d’uso e privacy policy; ● Cancellare il proprio account; ● Accedere all’assistenza dell’app; ● Uscire dal self-care. |
13 | Integrazione della tracking strategy | Tutte le funzionalità sviluppate devono essere integrate con il tool scelto per la tracking strategy (Mixpanel). Devono essere generati eventi per ogni step significativo dell’esperienza utente. |
14 | Telemetria | Implementare meccanismi di telemetria dell’infrastruttura applicativa (utilizzo, performance, sicurezza). |
15 | Sviluppo di test automatizzati | Implementazione dei processi per lo svolgimento di system test, integration test (app mobile: vanno predisposti test automatizzati dell’app su device virtuali; back-end: vanno |
implementati dei test di integrazione ed end-to-end tra le varie componenti dell’infrastruttura applicativa) e user acceptance test. | ||
16 | Implementazione meccanismi di gestione delle quote di utilizzo delle API | Progettazione, definizione e analisi per l’implementazione di meccanismi e logiche di gestione delle quote e dei limiti per servizio (legati al monitoraggio e gestibili via admin) e del relativo enforcement. |
17 | Evoluzione dei meccanismi di autenticazione delle API | Attività legate alla sicurezza, integrità e non ripudiabilità delle comunicazioni (Es.: mutua autenticazione via certificati, firma HMAC). Gestione dei token autorizzativi (Es.: modalità di attivazione dei servizi via token, manutenzione dei token, dove sono archiviati, chi li genera, chi li può utilizzare). Le API di IO vengono chiamate dai servizi erogati dagli enti attraverso delle chiamate HTTPS autenticate tramite chiave API, fornita dal servizio ad ogni richiesta sotto forma di autenticazione bearer. Per incrementare la sicurezza, si propone di implementare uno schema di firma delle chiamate API di IO tramite HMAC. |
18 | Invio di messaggi batch | Alcuni enti invieranno grandi volumi di messaggi (milioni al giorno), anche in singoli batch. Il modello implementato dalle API attuali è strutturato per l’invio di un singolo messaggio a chiamata. È quindi necessario implementare dei meccanismi di invio batch per ottimizzare gli scenari di invio massivo. |
19 | Messaggi broadcast geofenced | È in previsione l’analisi di fattibilità ed eventuale implementazione di un meccanismo che permetta agli Enti Erogatori che si occupano di sicurezza pubblica di inviare messaggi a gruppi di cittadini basati sulla presenza o l'ingresso in un una determinata area geografica. |
Infrastruttura cloud | ||
20 | Configurazioni sistemistiche | Configurazione degli ambienti di staging, consolidamento della configurazione terraform ed evoluzione per gestire ambienti multipli, gestione dei secrets in modo sicuro. L’obiettivo di queste attività è quello di gestire la disponibilità, le prestazioni, il monitoraggio e la risposta agli incidenti delle piattaforme e dei servizi di IO. |
21 | Monitoraggio | Review delle metriche da monitorare a livello applicativo e infrastrutturale, configurazione di dashboard di monitoraggio e relativi alert. L’obiettivo è di monitorare le metriche possibili all'interno di IO in modo da avere una comprensione precisa della salute del sistema in ogni momento. Una pratica comune è quella di monitorare le metriche specifiche, impostare le soglie e attivare gli avvisi in base a tali soglie. |
22 | Resa dell’infrastruttura ridondante (multi-regione) | Adeguamento dell’infrastruttura verso la ridondanza multi-regione per la gestione del disaster recovery e il servizio ad alta disponibilità. |
Conduzione e customer care | ||
23 | Implementazione di strumenti a supporto della gestione e conduzione | Implementazione di applicazioni web a supporto della gestione, amministrazione e conduzione dei servizi offerti da IO agli Enti Erogatori. In pratica si tratterà di creare un portale di back-office di amministrazione con una dashboard per: ● Monitoraggio delle attività sull’app; ● Monitoraggio dei volumi dei messaggi inviati e delle quote di utilizzo delle API. |
24 | Consolidamento del flusso di on-boarding delle PA | Consolidare il flusso di on-boarding delle PA tramite un portale di self-care per gli Enti Erogatori che offra le seguenti funzionalità: ● La registrazione dei servizi; ● La modifica di un servizio registrato (logo, descrizione); ● La messa in pausa o disattivazione di un servizio. |
25 | Supporto di primo livello | Attività di supporto di primo livello agli utenti via call-center e servizio integrato nell’app (chat) per un numero di circa 300 interazioni al giorno in media. |