PagoPA è un sistema di pagamenti elettronici realizzato per rendere più semplice, sicuro e trasparente qualsiasi pagamento verso la Pubblica Amministrazione, e sta nettamente migliorando l’adozione da parte delle PA, grazie allo sforzo di Agid, del Team per la Trasformazione Digitale e al suo Responsabile dei pagamenti digitali, Giuseppe Virgone.
Era un progetto che soli 3 anni fa veniva considerato ormai parte del “cimitero dei progetti” della PA e ad oggi ha raccolto 41 milioni di transazioni, con un tasso di crescita annuale del 700%.
I feedback dei cittadini sono positivi come fruibilità (tranne per il discorso commissioni che però nel tempo, sull’online, si stanno schiacciando verso lo zero e che pagoPa rende trasparenti mentre prima erano “occulte”) e così degli esercenti (punti Sisal, Lottomatica, etc) che lo vedono sempre più come un’opportunità, sia di business diretto che collaterale (mentre una persona va a pagare magari compra un pacchetto di caramelle, compra dei prodotti del bar o del tabaccaio, etc).
Si tratta quindi di una piattaforma abilitante in fortissima crescita e con riscontri positivi, ma che può addirittura mettere le ali se solo si superassero due scogli, sicuramente importanti ed alti, ma non necessariamente complessi.
Riporto la mia esperienza, di Referente dei pagamenti del Partner Tecnologico ConsorzioIT, società in house di 50 comuni medio piccoli del cremasco e contemporaneamente Partner Tecnologico per gli stessi, in merito a questi due scogli.
Il primo scoglio è la riconciliazione. Per i non avvezzi al mondo pagoPA questa è diversa dalla rendicontazione.
La rendicontazione è il flusso informatico mandato dal Prestatore di servizi di pagamento (PSP) quando riceve il denaro dal cittadino per il pagamento effettuato attraverso pagoPA. Questo flusso dovrebbe essere mandato in 24 ore. Non è sempre così, ma abbiamo evidenza nel tempo che questa soglia si avvicina sempre di più e i casi di ritardi si stanno riducendo a pochi PSP o a casi isolati. Si parla quindi di flussi informatici di conferma.
La riconciliazione è la verifica per cui la tesoreria (ovvero la banca di appoggio dell’ente per gli incassi) abbia ricevuto il denaro dal PSP, mediante ricevuta del provvisorio da parte dell’ente. Si parla quindi di flussi finanziari, ed è questo che interessa alle ragionerie dei Comuni, che lavorano come se fosse casa loro e quindi “vogliono vedere il cammello-soldi” prima di considerarlo proprio.
Attualmente la maggior parte dei Comuni risolve la riconciliazione in due modi:
- facendo un conto per servizio, in modo da poter fare la verifica economica così detta “a chili”. Ovvero se nel gestionale del backoffice ho 150 mila euro di tari, basta controllare che sul conto della Tari ci sia il corrispondente ed il gioco è fatto;
- facendo una verifica a “grammi”, ovvero usando un unico conto su cui arrivano diversi servizi, verificando ogni provvisorio uno a uno.
Alcuni dicono che sia un problema di trust/fiducia, ovvero che le ragionerie dovrebbero fidarsi della rendicontazione e che i soldi arrivano sicuramente. Questo è vero, ma è un tema culturale per il quale verrà richiesto tempo perchè sia assorbito, e la fiducia si farà mano a mano che l’uso di pagoPA toglierà lavoro alle ragionerie rendendo tutto più automatico.
Entrambi i metodi di cui parlavamo prima (a chili e a grammi) non sono scalabili: il primo in numeri di conto (se ho 20 servizi fare 20 conti diventa articolato da gestire), il secondo perchè all’aumentare della transazioni (poniamo di averne qualche decina di migliaia), diventa impossibile in termini di tempo la riconciliazione manuale.
Qui entra in gioco l’informatica, che permette le integrazioni. L’idea è stata quella di importare l’OPI (il giornale di cassa) preso dalla tesoreria dell’ente direttamente nel software del partner tecnologico, permettendo quindi direttamente al partner tecnologico di gestire la riconciliazione. Questo permette di riconciliare i pagamenti a un livello che è uniforme (software del partner tecnologico), indipendentemente da quanti software gestionali dell’ente (multe, anagrafe, ragioneria, altro) sono integrati al software del partner tecnologico. In questo caso modo, ogni gestionale può pescare l’informazione completa direttamente dal partner tecnologico stesso. In caso contrario, bisognerebbe chiedere ad ogni software gestionale l’elaborazione dell’opi, con aggravio di costi per l’ente.
Praticamente cosa succede? L’operatore di ragioneria scarica l’OPI del giorno dalla banca e lo carica nel portale di backoffice del partner tecnologico messo a disposizione dell’ente. In questo modo il software riconcilia e l’operatore di ragioneria si trova 3 pallini verdi:
- uno per il pagamento effettuato (in realtime);
- uno per la rendicontazione (flusso informatico, solitamente entro 24 ore);
- uno per la riconciliazione (flusso finanziario, dipende anche dalla tesoreria).
Questo permette all’operatore di ragioneria addirittura di ragionare per differenza, ovvero tutto è riconciliato a meno di quello segnalato dal sistema.
Ogni volta che importo un OPI viene fatto un report che indica quanti flussi sono stati importati, quanti appartengono a un altro Partner Tecnologico, quanti sono riconciliati ma non rendicontati, quanti sono in errore, quanti non sono transitati per pagoPA. Questo tipo di report permette un’analisi completa dell’OPI.
Una volta riconciliato correttamente nel portale del Partner Tecnologico (con relativa possibilità di consultare lo storico, etc) va quindi integrato il software gestionale, in modo che possa dare le stesse informazioni e che l’operatore di ragioneria possa visualizzare la stessa informazione.
Qui si entra più nel vivo nel secondo tema, le integrazioni.
Integrare il software di backoffice dell’ente con il software del PT dovrebbe essere un’operazione abbastanza semplice, ovvero l’integrazione tra due sistemi con API.
Non è purtroppo così, perlomeno per la mia esperienza.
Prima di tutto perché ancora manca una cultura diffusa di integrazione nelle software house, che hanno il timore di “aprirsi”. Aprirsi per una software house dei gestionali della PA significa uscire dal proprio modus pensandi, nel senso che sono abituate a tenere il sistema più chiuso possibile, per “tenere il cliente”. Questo è un modo di pensare probabilmente vecchio e forse le prime software house che si apriranno verso l’esterno saranno proprio quelle che anticiperanno gli altri. Senza dimenticare che quando ci si apre con API e servizi, spesso nascono opportunità prima impensabili (opportunità che il privato conosce molto bene).
Inoltre, spesso vengono attuate logiche piuttosto chiuse, ovvero “se mi chiedi e paghi allora sviluppo”. Il mercato della Pubblica Amministrazione è un mercato che rischia di “far perdere tempo” e nel passato ha creato non pochi problemi a chi seguiva una strada di sviluppo, per poi essere smentito dal governo successivo che annullava la scelta del predecessore. Per cui è comprensibile questo approccio conservativo.
Del resto negli ultimi 2–3 anni è evidente che il mondo è cambiato e l’anno zero è passato, quindi aprirsi a soluzioni diverse, con API, servizi rest e quant’altro, potrebbe essere un buon approccio, volendo anche proattivo laddove si cerca di fare il servizio per poi venderlo. In tale modo si supererebbe anche l’approccio di far pagare al primo cliente richiedente una soluzione lo sviluppo e il rischio d’impresa in toto, facendosene in parte carico e quindi cercando di creare soluzioni che anticipino il mercato e non solo che lo seguano.
Tornando a pagoPA, le integrazioni sono un tassello fondamentale, e uno scambio di informazioni tra software di backoffice dell’ente e software del PT è fondamentale e dovrebbe essere concepito possibilmente a basso costo per le PA.
Qualcuno ci ha pensato, come ad esempio Regione Lombardia che ha stanziato dei fondi per permettere le integrazioni. Premiare il comportamento è stata una scelta saggia, anche se probabilmente era altrettanto saggio rimanere market neutral e aiutare gli enti a fare integrazione, indipendentemente dal sistema scelto. Forse sarebbe più utile anche che i finanziamenti favorissero una standardizzazione più che la sola adesione. La soluzione potrebbe quindi essere finanziare i criteri e non le soluzioni: questo approccio permetterebbe infatti di agevolare la creazione di uno standard di interfacciamento.
Riassumendo quindi, la rendicontazione e l’integrazione, potrebbero essere le due ali che permetterebbero a pagoPA di volare, superando anche le resistenze degli utenti comunali, che effettivamente a oggi fanno più fatica per erogare un servizio, il cui risultato sul cittadino è sicuramente migliorativo (“citizen first”).
Speriamo che tutti gli stakeholder che sono in campo, possano fare del loro per capire il valore di questi due aspetti, e per prendere il meglio l’uno dall’altro, con l’obiettivo di semplificare il lavoro anche alle ragionerie e ai dipendenti comunali.
A questo punto non ci sarebbero più alibi per non utilizzare pagoPA anche nei piccoli enti.