Questo sito utilizza cookie tecnici per le sue funzionalità. Cliccando su "accetto" acconsenti all’uso dei cookie. Approfondici.

Menu

PayConnect

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.

approcciomvp

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).

Elenco Attività svolte

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

Cronologia del progetto 

cronologiaprogetto

Descrizione del prototipo

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

modalitàpassesaas

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.

Certificazioni

loghetti certificazioni2