UNIONE EUROPEA Ministero Sviluppo Economico REGIONE PUGLIA
POR Puglia 2014 – 2020
“Investiamo nel vostro futuro ”
Asse III Obiettivo specifico 3a Azione 3.1 (Attivi Materiali)
Asse III Obiettivo specifico 3e Azione 3.7 (E-business)
Asse I Obiettivo specifico 1a Azione 1.1 (R & S)
Asse I Obiettivo specifico 1a Azione 1.3 (Innovazione tecnologica)
PROGETTI E SOLUZIONI S.P.A.
1) Obiettivi e cronologia
Descrizione dell’obiettivo finale
Il Progetto di ricerca, proposto Progetti e Soluzioni SpA, denominato PAYCONNECT, si è posto come obiettivo la realizzazione di una nuova piattaforma informatica realizzata in tecnologia Cloud Computing e fruibile in modalità SaaS, che utilizzi un nuovo standard di collegamento informatico tra gli enti della PA e il servizio denominato “Nodo dei Pagamenti” gestito dall’Agenzia per l’Italia Digitale (AgID), che consente ai cittadini il pagamento digitale delle posizioni debitorie.
Le PA nazionali e locali ed in generale tutti gli Enti Creditori (EC) di tributi da parte di cittadini e imprese, infatti, devono uniformarsi alle direttive di “pagoPA”, un sistema di regole, standard e strumenti definiti dall’AgID in attuazione dell’art. 5 del Codice dell’Amministrazione Digitale e dal D.L. 179/2012 che regolamenta i pagamenti elettronici verso la Pubblica Amministrazione.
“pagoPA” ha ricadute importanti soprattutto per gli EC. I numerosi sistemi informativi di ogni PA (nella maggior parte dei casi come sistemi legacy) contengono i corrispettivi economici dovuti dai cittadini per tributi e per altri servizi pubblici erogati. Rispetto a quanto prescritto da AgID esiste un importante gap amministrativo, organizzativo e tecnologico per realizzare il dialogo, univoco, tra singolo EC, i cittadini e le imprese e il Nodo dei Pagamenti di pagoPA. L’iniziativa di R&S di Progetti e Soluzioni intende affrontare questo specifico problema mettendo a punto una nuova piattaforma informatica realizzata in tecnologia Cloud Computing che utilizzando metodologie, tecnologie e processi innovativi consenta di interscambiare in maniera standard ed efficiente le informazioni tra sistemi informativi legacy, e comunque eterogenei, degli EC, e il sistema informativo “Nodo dei Pagamenti”, eliminando per l’ente della PA la necessità di gestire la complessità implicata in tale interconnessione.
L’obiettivo progettuale sarà raggiunto attraverso attività di Ricerca e Sviluppo organizzate come segue:
Normativa, Modelli e Metodologie
Viene sviluppata una approfondita analisi delle diverse componenti che intervengono nel sistema dei pagamenti sotteso a “pagoPA” con specifico riferimento a:
Normative e Metodologie del sistema dei pagamenti con particolare riguardo agli aspetti di pagamento digitale, della normativa bancaria e delle tecnologie disponibili
Definizione e adozione di Metodologie e Standard in cui viene approfondita in particolare la metodologia Agile Scrum che Progetti e Soluzioni ha scelto di adottare sia all’interno della propria filiera di progettazione e sviluppo, con il coinvolgimento di fornitori e consulenti, sia nei confronti degli stakeholders di progetto nella fase di progettazione etest del sistema Progettazione e Sviluppo
Costituisce il cuore del programma di R&S in cui viene progettata e sviluppata la piattaforma Payconnect. Il progetto contempla in questo dominio la progettazione puntuale dell’architettura e delle applicazioni che la compongono.
Come anticipato per la progettazione ma soprattutto per la componente di sviluppo si utilizzerà la metodologia Agile Scrum, un framework decisionale focalizzato sugli aspetti gestionali del progetto di sviluppo attraverso un sistema iterativo di controlli in grado di consentire il rilascio rapido (2-4 settimane) di specifiche componenti del sistema e la loro verifica rispetto agli obiettivi complessivi progettuali.
Metodologia di sperimentazione e Test
Sono definiti, sin da questa fase di descrizione del progetto, i casi d’uso rispetto ai quali i singoli risultati e l’intera piattaforma andranno validati e verificati. Questo comporta il coinvolgimento dei destinatari fdinali del progetto (gli EC) sin dalla fase di progettazione. Il Comune di Lecce ha dato la propria disponibilità a svolgere la funzione di stakehoder e interverrà attraverso sue specifiche rappresentanze sia in fase di progettazione che di verifica sul campo della piattaforma. Lo stesso Comune, quindi, diverrà parte attiva nella definizione dei requisiti e delle specifiche funzioni secondo quanto previsto dalla metodologia Scrum.
2) Attività
Approccio MVP (Minimum Viable Product)
Per la loro natura, i processi di innovation hanno una componente elevata di Esploration, con esiti difficilmente prevedibili. Per questo motivo sono adatti modelli di sviluppo tipo agile, caratterizzati da numerosi cicli iterativi, incrementali, sperimentali e adattivi. Questo modello consente infatti di sperimentare prima possibile sul mercato i comportamenti degli utilizzatori dei moduli della soluzione, consentendo di correggere gli errori basati su ipotesi falsificabili definite all’inizio, sostituendole con altre ipotesi basate sui risultati della sperimentazione.
Nel progetto Payconnect abbiamo introdotto questa metodologia, scomponendo l’architettura di massima della soluzione complessiva in moduli incrementali e dando la precedenza allo sviluppo dei moduli che è possibile sperimentare con i partner che necessitano solo di queste componenti della soluzione totale. In questo modo è possibile applicare il concetto di Minimum Viable Product (MVP), ovvero identificare unità minime del prodotto che possano essere messe a disposizione dei Clienti per sperimentare e osservare il reale effetto. Infatti, tenendo presente il concetto secondo cui “There’s a huge difference between what people say and what they do”, esiste sempre un gap tra requisiti esplicitamente espressi dai Clienti e i loro reali bisogni.
Nel progetto Payconnect è stata quindi adottata questa strategia, basata su informazioni reali, che ha la capacità di modificarsi in corso d’opera. Di seguito la sequenza della attività svolte in relazione ai moduli con Approccio Minimum Viable Product (MVP).
Contestualizzazione degli obiettivi e verificabilità quantitativa
La forte spinta conferita da AgID verso la diffusione dei Pagamenti Digitali nell’ambito delle Pubblica Amministrazione per i contribuenti sta creando nuovi spazi sul mercato per player specializzati. L’obiettivo di AgID è la diffusione su larga scala dei Pagamenti Digitali disponibili per i contribuenti per il pagamento dei tributi e di altre somme dovute agli Enti della Pubblica Amministrazione. Ad esempio Servizi scolastici, TARI, Occupazione suolo pubblico, multe, ecc.
Le caratteristiche di questo nuovo mercato sono dominate da molti elementi di variabilità e non consolidati legati al contesto normativo in continua evoluzione, alla parziale conoscenza dei fattori competitivi della Piattaforma Pagamenti adeguati alla crescita aziendale, alla evoluzione tecnologica implicata nella realizzazione della Piattaforma Pagamenti.
Questo contesto ha suggerito di impostare il progetto Payconnect con una metodologia Lean, con sequenze di ipotesi verificabili da misurazioni di indicatori. Questo approccio è infatti adatto ad ambiti dove gli elementi di incertezza e variabilità superano quelli consolidati e rendono non più applicabili i processi classici di management basati su previsioni e pianificazioni a lungo termine. È invece fondamentale sperimentare e apprendere dal campo cosa abbia valore dal punto di vista del mercato.
Occorre inoltre considerare che due anni, necessari per studiare, progettare e realizzare la piattaforma, sono un lasso di tempo lungo rispetto all’evoluzione del mercato e l’evoluzione normativa.
Per questo motivo è stato adottato un approccio che ha dato importanza alla sperimentazione e alla misura dei dati sperimentali. È stato quindi fondamentale nel corso del progetto, individuare enti PA disponibili ad essere coinvolti anche nella fase pilota, durante la quale la piattaforma complessiva è stata oggetto del susseguirsi di ampliamenti e dei miglioramenti previsti dal progetto.
Particolare attenzione è stata riservata al Comune di Lecce, che fino dalla fase del progetto preliminare si è reso disponibile alla all’analisi dei processi che generano le posizioni debitorie, con l’evidenziazione del passaggio AS IS a TO BE. Tuttavia nelle fasi successive di coinvolgimento nella sperimentazione, avvicendamenti organizzativi interni al Comune, hanno rallentato l’applicazione della piattaforma sulla piattaforma. In considerazione della intrinseca portata a livello nazionale del progetto, è stato naturale allargare la sperimentazione su diversi soggetti PA del territorio italiano, grazie anche al progressivo crescere dell’attenzione sugli Enti determinata dalla pressione normativa di AgiD.
La raccolta di dati sperimentali allargata ha consentito quindi di elaborare valutazioni sui processi di pagamento, con particolare attenzione allo studio dei comportamenti e delle preferenze dei cittadini effettuato con tecniche Big Data Analytics identificate nelle attività di Ricerca Industriale. L’analisi è stata condotta su tutto il territorio italiano con più enti, dai quali ricavare dati sperimentali da utilizzare come fonte di informazioni per lo sviluppo della piattaforma coerente con le più attuali metodologie di Data Driven Strategy e Mimimum Viable Product (MVP).
| Obiettivo Realizzativi e Attività | Tipologia | |
| OR 1 – Analisi dello Stato dell’Arte – Normative Metodologie e Tecnologie del sistema dei Pagamenti | RI | |
| A1.1 – Studio, analisi e validazione delle Normative di Pagamento Digitale | ||
| A1.2 – Studio e analisi degli standard Normativi bancari italiani | ||
| A1.3 – Studio, analisi e validzaione di soluzioni e tecnologie disponibili per i pagamenti per gli Enti PA in italia | ||
| OR 2 – Definizione delle Metodologie e degli Standard | RI | |
| A2.1 – Analisi dello stato dell’arte delle Metodologie di Sviluppo | ||
| A2.2 Analisi delle Metodologie per l’ organizzazione dei processi tributari | ||
| OR 3 – Progettazione della Piattaforma Cloud e dei servizi Software | RI | |
| A3.1 – Architettura di Sistema e definizione requisiti | ||
| A3.2 – Progettazione esecutiva Midlleware API e KPI | ||
| A3.3 – Progettazione esecutiva back end | ||
| A3.4 – Progettazione esecutiva front end | ||
| OR 4 – Sviluppo dell’Infrastruttura e del Middleware | SS | |
| A4.1 – Sviluppo Housing end Netwaork IaaS | ||
| A4.2 – Sviluppo Infrastruttura Hardware IaaS | ||
| A4.3 – Sviluppo Middleware | ||
| OR 5 – Sviluppo componenti di Back end | SS | |
| A5.1 – Sviluppo del Service Monitor | ||
| A5.2 – Sviluppo Service Analytics KPI e Big Data | ||
| A5.3 – Sviluppo Customer Analytics CRM | ||
| A5.4 – Integrazione e test delle componenti di Back End | ||
| OR 6 – Sviluppo componenti di Front end | SS | |
| A6.1 – Sviluppo d Gateway | ||
| A6.2 – Sviluppo PA Configurator e PA Client Connector | ||
| A6.3 – Sviluppo Payment Interface | ||
| A6.4 – Sviluppo Service Analitycs “Open Data” | ||
| A6.5 – Integrazione e test componenti di Front End | ||
| OR 7 – Sperimentazione sul campo con utenti finali | SS | |
| A7.1 – Integrazione delle componenti e test di laboratorio | ||
| A7.2 – Sperimentazione di Pay Connect con Enti Locali | ||
| A7.3 – Sperimentazione di Pay Connect in casi d’uso | ||
| OR 8 – Project Management | RI/SS | |
| A8.1 – Project Management RI | ||
| A8.2. Project Management SS |
Prototipi software | Situazione di partenza | Situazione raggiunta con il prototipo |
| D4.3 – Prototipo del Middleware IaaS | Esistevano i server su cui era disponibile una prima versione del gateway collegata al NodoSPC tramite VPN. Obiettivo era la realizzazione del collegamento tramite le tecnologie previste dalle normative AgID. | Il collegamento del gateway e dei sistemi NodoSPC è stato realizzato tramite la tecnologie Porta di Dominio Equivalente (PDDE) che realizza il collegamento secondo il sistema Pubblico di Connettività. In relazione all’evoluzione normativa, sul prototipo sono stati realizzate anche le varianti di collegamento previste da AgID, tramite il software opensource SPCoop e la Mutua Autenticazione con certificati X.509 (MAC) |
| D5.1 – Prototipo della componente Service Monitor | L’obiettivo era rendere automaticamente accessibile alcuni valori dei parametri durante il funzionamento del gateway che estraesse i dati necessari alla diagnostica del sistema durante il suo funzionamento. | Sul prototipo è stata realizzata l’interfaccia semplificata che ricava dai log del gateway i parametri diagnostici necessari all’analisi e risoluzione di eventuali anomalie. |
| D5.2 – Prototipo della componente Service Analiytics KPI e Big Data | L’obiettivo era ricavare informazioni utili a valutare l’efficacia del sistema nei confronti dell’utenza e la resistenza nei confronti dei workload | Il prototipo realizzato estrae automaticamente alcune categorie di dati, li aggrega. Li rende disponibili ad un sistema di trasformazione dei dati in informazioni e di rappresentazione visuale dei risultati e dei trend relativi alle abitudini dei cittadini pagamenti relativamente ai comportamenti tipici e alle preferenze come orari, luoghi, strumenti di pagamento. Dalla stessa base dati e con le stesse procedure, il prototipo consente di rappresentare in modo visuale la resistenza della piattaforma ai picchi dei workload, alla conformità dei response time ai requisiti di qualità di Agid |
| D5.3 – Prototipo della componente Customer Analytics CRM | L’obiettivo era la raccolta automatica di elementi di analisi dei comportamenti di cittadini ed Enti PA | Il prototipo realizzato estrae periodicamente e in automatico alcune categorie di dati al comportamento delle PA in relazione all’adozione della piattaforma. Tali dati sono automaticamente aggregati in modo da mettere in relazione i comportamenti i comportamenti attesi da parte della PA in termini di posizioni debitorie e gli effettivi pagamenti da parte dei cittadini |
| D5.4 – Prototipo validato del Back End | L’obiettivo era rendere disponibile un sistema di procedure ed interfacce per l’inserimento delle posizioni debitorie nella base dati del gateway | Nel prototipo sono state realizzate procedure accessibili tramite un portale WEB che mettono a disposizione dell’operatore dell’ente PA le funzioni di gestione delle posizioni debitorie, sia in maniera massiva che in maniera unitaria. |
| D6.1 – Prototipo della componente Gateway | Il gateway di partenza era costituito da servizi web, web services e Query su un database relazionale disponibile sui server del datacenter SIA, ma occorreva rivedere gli automatismo interni per rendere le performance del motore transazionale conforme ai requisiti prestazionali previsti dalle normative AgID | Nel prototipo realizzato sono state modificate le sequenze delle operazioni automatiche eseguite dal gateway nel momento in qui riceve le request da parte dei sistemi IT dell’ente PA e Sistemi IT del NodoSPC. Questa riorganizzazione dei dati nel database e delle sequenze di operazioni hanno consentito di raggiungere elevati livelli di prestazioni. |
| D6.2.1 – Prototipo della componente Pa Configurator | Occorreva gestire in maniera organica i comportamenti del gateway in relazione alle personalizzazioni specifiche dei comportamenti dei singoli Enti PA o dei loro Enti Aggregatori | Il prototipo ha utilizzato il linguaggio XML come standard di comunicazione alla piattaforma dei circa 1000 parametri necessari alla personalizzazione del gateway |
| D6.2.2 – Prototipo della componente PA Client Connector | Era necessario dotare il gateway collegato al NodoSPC di AgID di opportuni metodi richiamabili da sistemi esterni per realizzare l’interoperabilità in un contesto distribuito. | Il prototipo espone un set di Web Services che consentono di utilizzare la piattaforma in modalità PaaS da parte di sistemi esterni degli Enti PA o di suoi fornitori di servizi verticali. |
| D6.3 – Prototipo della componente Payment Interface | L’obiettivo era la realizzazione il portale web di Front Office che consentisse al cittadino di effettuare i pagamenti tramite PagoPA. | Il prototipo realizzato mette a disposizione il Front Office costituito da pagine web che consentono al cittadino di dialogare direttamente con il gateway Easybridge dedicata alle posizioni debitorie preventivamente caricate sulla sua base dati dagli operatori dell’Ente PA. Il Front Office inoltre interagisce anche direttamente con il NodoSPC attraverso il metodo esposto da quest’ultimo che consente al cittadino di selezionare il PSP (Prestatore Servizi Pagamento) più adatto alle sue esigenze. |
| D6.4 – Prototipo della componente Service Analitycs “Open Data” | L’obiettivo era la realizzazione dell’esportazione automatica di un dataset per metterlo a disposizione dell’Ente PA per la pubblicazione in forma neutralizzata rispetto ai dati di natura personale ed aggregata. | Il prototipo rende disponibile il dataset che raggruppa le transazioni avvenute con una granularità massima di un’ora. Il dataset è aggiornato con frequenza giornaliera ed è quindi in continua crescita Rende disponibile i dati in forma tabellare per la pubblicazione da parte dell’ente PA. |
| D6.5 – Prototipo validato del Front End | L’obiettivo era la validazione del prototipo con il coinvolgimento diretto dell’Ente Creditore e del NodoSPC. | Il prototipo realizzato ha consentito di mettere a disposizione l’ambiente di test su entrambi i fronti , Ente Creditore e Nodo dei Pagamenti. Ha consentito di effettuare test congiunti utilizzando come riferimento la Check List prevista da AgID per la PAEC (Procedure Abilitazione Ente Creditore) |
| D7.1 – Prototipo Payconnect con test di Laboratorio | L’obiettivo era la verifica del funzionamento di Payconnect in tutte le sue componenti hardware e software prima della sperimentazione sul campo. | Il prototipo è stato validato nei sistemi di comunicazione tra i vari layer ed i componenti di ciascun layer e sono stati valutati con specifica attenzione, oltre a quanto prescritto dalle linee guida di AgID, con riferimento a: – le prestazioni dei response time – Remote data replication per disaster recovery – performance del cloud e delle partizioni in macchine virtuali i web services -i servizi di strutturazione dei Big Data -le funzioni di comunicazione e scambio dei dati con il nodo pagoPA -le performance in termini di velocità di esecuzione |
| D7.3.2 – Prototipo Payconnect | La necessità era la messa a punto del sistema sperimentale da utilizzare come banco di prova per ottenere indicazioni utili ai fini della successiva industrializzazione (in termini di tempi e costi) e dello sviluppo commerciale verso il mercato | La descrizione più dettagliata del prototipo è contenuta nel documento completo. |
Gli studi e la progettazione di Payconnect hanno portato alla realizzazione di un prototipo un sistema cloud distribuito sui due datacenter SIA e CINECA , distribuito come descritto di seguito. Come visibile dallo schema logico seguente, il prototipo è stato interfacciato con:
1. i sistemi IT degli enti creditori o dei suoi fornitori di applicativi verticali in modalità PaaS tramite Web services
2. con i sistemi Agid di pagoPA tramite Web Services
3. con i dispositivi WEB dei Cittadini e degli operatori PA in modalità PaaS
Obiettivo principale del prototipo di Payconnect realizzato consiste nel rendere disponibile agli Enti PA la possibilità di fare pagare a cittadini tramite il Nodo dei Pagamenti le posizioni debitorie generate sui sistemi gestionali del’ ente stesso. Le posizioni debitorie dovute alla PA da parte dei cittadini sono relative a tributi o al corrispettivo di servizi erogati al cittadino.
3) Sperimentazione con la PA e risultati
Sistema da realizzare e sperimentazione con le PA Il sistema PAYCONNECT è strutturato attraverso una architettura generale riportata nello schema seguente che rappresenta i singoli moduli funzionali
Approccio Data-Driven.
Il Data Driven Strategy è un ribaltamento dell’approccio tradizionale utilizzato nello sviluppo della strategia. Prima la lettura dei dati avveniva solo nella parte finale delle attività, affidando la creazione della strategia stessa a esperienze, conoscenza del settore, benchmark, mercato. Passaggi che trovavano sì la presenza di dati, ma che spesso non erano strettamente connessi al progetto in essere o alla realtà coinvolta.
L’approccio Data Driven Strategy consiste nell’analizzare i dati sin dal primo approccio alla definizione degli obiettivi, agevolando la fase di stesura della strategia e, conseguentemente, dei contenuti. La parte creativa viene arricchita dalla certezza del dato, orientandola verso direzioni più vicine ai gusti e alle necessità degli utenti. Un lavoro a monte per capire i risultati prodotti e migliorare le attività successive. Nell’approccio Data Driven Strategy i Big Data Analytics sono parte integrante della strategia e della fase di produzione dei contenuti. Il loro supporto è costante, guidandoci alle giuste correzioni già durante il progetto, evitando il rischio di sprecare tempo e risorse.
Misurazione quantitativa dei risultati attraverso KPI estratti da BIG Data Analytics
Durante la stesura del progetto esecutivo, era stato individuato un set iniziale di KPI ritenuti adatti alla verifica dei risultati. Tali KPI erano legati principalmente ai processi organizzativi degli enti PA. Dallo studio scientifico integrato sulle metodologie di analisi dei Big Data in relazione agli approcci Lean, Data Drive ed MPV è apparso tuttavia opportuno ridefinire ed estendere il set ad altri aspetti legati all’interazione tra la piattaforma Payconnect e gli utenti.
Di seguito è rappresentato il processo di trasformazione dei dati raccolti dalla piattaforma per trasformarli nei feedback necessari all’orientamento dello sviluppo della piattaforma in relazione al business che deve generare.
Processo di trasformazione dati in strategia
Nel corso del progetto sono stati messi a punto degli indicatori con lo scopo di validare i risultati della piattaforma sotto 3 punti di vista.
Le misurazioni che sono state effettuate su un campione sperimentale complessivo di 1.604.834 pagamenti effettuati dai cittadini per un valore complessivo transato di € 493.404.773, sono il prototipo del Big Data Dashboard. Tramite l’osservazione e l’analisi delle variazioni dei valori di sintesi rappresentati sul dashboard, è stato quindi possibile ricavare costantemente informazioni per orientare gli sviluppi funzionali della piattaforma e delle sue performance, per adattarla alle esigenze di business. Lo studio dell’impostazione del Dashboard e i risultati cognitivi che ne derivano sono stati utilizzati durante sperimentazione di Payconnect, ma saranno trasferibili anche nella successiva fase di produzione.
Il Big Data Dashboard riassume quindi le seguenti categorie di Analytics, estraendo misure quantitative che devono essere studiate in correlazione tra di loro:
Diversi sono i KPI identificati per ottenere informazioni dalla sperimentazione di Payconnect raccolti nel prototipo di un dashboard e da una rappresentazione grafica d’inseme.
Il comportamento dei cittadini
Particolare attenzione è stata a data alla misurazione del comportamento statistico dei cittadini in relazione ai pagamenti tramite pagoPA, finalizzato ad indentificare variabili che ne possono influenzare le preferenze. Di seguito sono rappresentati alcuni di questi.
Questo KPI mostra una sostanziale equivalenza nella scelta del cittadino tra la Modalità 1 e la Modalità 3. Nel caso del Modello 1, appare inoltre una preferenza nell’uso della carta di credito.
Distribuzione oraria del numero di transazioni per giorno della settimana.
L’andamento di questo KPI su scala settimanale presenta alcune analogie rispetto all’andamento orario, ovvero:
• una preferenza ben delineata nella parte iniziale della settimana (lunedì) seguito da un calo, e una piccola ripresa nella seconda parte della settimana (venerdì)
• Coerentemente con il KPI orario, anche quello settimanale mostra che i cittadini non gradiscono pagare durante il tempo libero (sabato e dominica)
