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