PagoPA, il cambiamento va gestito: ecco l’esperienza del Comune di Besana

Prima di tutto un po’ di informazioni su Besana in Brianza. È un Comune di circa 15500 abitanti, con 15 kmq di territorio, circa 80 km di strade e 60 dipendenti. Ci troviamo nella provincia Monza e Brianza. Aggiungo una informazione per noi fondamentale: siamo certificati secondo la norma ISO 9001 dal 2004.

Quando a fine settembre dello scorso anno abbiamo cominciato ad affrontare il tema di PagoPA, il primo pensiero è stato quello di non voler ripetere l’errore fatto con la fatturazione elettronica. Non volevamo subire il cambiamento, ma provare a gestirlo.

Abbiamo utilizzato la metodologia indicata dalla norma ISO 9001 per la progettazione. Abbiamo raccolto tutte le informazioni in ingresso e definito i requisiti richiesti in uscita. Cercherò di tradurlo per chi non è avvezzo al linguaggio del “qualitese”.

Le informazioni in ingresso sono quelle che servono per partire:

1. le norme di qualsiasi origine (leggi, regolamenti…) che mi indicano dove devo arrivare e come (nel caso di PagoPa l’art. 5 del CAD e tutta la serie delle linee guida emanate da AgID)
2. le caratteristiche funzionali e prestazionali che il sistema dei pagamenti dovrà avere (cosa potranno pagare i cittadini, che strumenti devo predisporre, quali livelli di servizio devo garantire?)
3. informazioni provenienti da progetti simili (ma PagoPA è nuovo per tutti)
4. altre informazioni essenziali per la progettazione (e qui rientrano soprattutto le informazioni relative ai processi che implicano un pagamento da parte dell’utenza e come essi sono organizzati)

I requisiti in uscita, chiaramente alla luce delle informazioni in ingresso, sono:

1. soddisfare i requisiti cogenti, funzionali e prestazionali individuati
2. capire cosa mi serve per l’approvvigionamento, la produzione e l’erogazione del servizio e procedere ad acquisirlo
3. capire come, una volta a regime, tenere sotto controllo il processo e la sua conformità ai requisiti
4. individuare le modalità per garantire che il servizio venga proficuamente utilizzato dagli utenti e dall’organizzazione (ad es. comunicazione interna ed esterna).

La raccolta delle informazioni in ingresso relative ai punti 2 e 4 ha portato alla creazione di un catalogo dei pagamenti: un file di Excel inizialmente di 4 colonne (ora ha superato le venti) nel quale prima di tutto elencare tutti i servizi pagati al Comune da cittadini ed imprese. Per ognuno di essi, poi, ci siamo posti un po’ di domande, quali ad es.:

• la periodicità/frequenza del pagamento (occasionale o periodica, in tal caso se mensile, semestrale, annuale ecc.)
• come il servizio pagato è gestito (con un servizio web, con un gestionale o banalmente con Word ed Excel)
• la quantità di operazioni di pagamento per quel servizio per anno e gli importi pagati per operazione
• se il pagamento ha una scadenza e cosa deve accadere alla scadenza

La stesura di questo catalogo ha richiesto chiaramente il coinvolgimento di tutte le Aree e i Servizi della nostra struttura. Nel nostro Comune con cadenza settimanale o bisettimanale, il Segretario comunale si incontra con i Responsabili di Area (si tratta di Posizioni organizzative e non di Dirigenti) ed in queste riunioni abbiamo prima di tutto spiegato cos’era PagoPA e quali erano i tempi d’attuazione previsti. Poi abbiamo chiesto loro di collaborare alla stesura del catalogo dei pagamenti, procedendo anche attraverso interviste con i loro collaboratori.

Per stendere il catalogo in modo da non dimenticare nessuna tipologia di pagamento abbiamo completato le informazioni provenienti dagli uffici, con le informazioni desumibili dai capitoli di entrata del bilancio e le tipologie di procedimento, pubblicate sul nostro sito come previsto dall’art. 35 del D.Lgs. 33/2013.

Contemporaneamente abbiamo da subito affrontato il problema dell’approvvigionamento dei servizi di cui avremmo avuto bisogno, non solo per aderire al nodo, ma anche per creare un portale dei pagamenti dove i nostri cittadini potessero accedere. Occorre precisare che il nostro ente ad oggi non eroga servizi on line, tranne che per i servizi scolastici.

Quando abbiamo cominciato a sondare il mercato (ottobre 2015) erano poche le società che avevano già affrontato l’argomento in maniera strutturata, complici anche le ulteriori e imminenti scadenze (una in particolare: l’avvento della nuova contabilità per gli enti locali). Per questo abbiamo scelto un fornitore che avesse specifiche competenze nello sviluppo di sistemi transazionali in ambito bancario, avesse già partecipato a incontri con AgID su PagoPA e quindi potesse sin da subito affiancarci per costruire ciò di cui avevamo bisogno. Inoltre il fornitore scelto ci dava garanzie sia per la sicurezza delle informazioni che per la continuità operativa, in quanto oltre alla certificazione ISO 9001, è in possesso delle certificazioni ISO 27001 e ISO 22301.

Abbiamo iniziato a lavorare con il fornitore immaginando insieme il nostro portale dei pagamenti sia lato dell’utente, sia lato operatori del Comune. È stato durante questa fase di analisi che il catalogo dei pagamenti si è arricchito di “colonne”, cioè di informazioni specifiche sui singoli pagamenti. Ci siamo domandati per ogni tipo di pagamento se ammettevamo la rateizzazione, se prevedevamo la funzione di storno (possibile ad es. con i pagamenti con carta di credito), se i debitori erano sempre noti a priori o meno, con quale modalità acquisire le informazioni di rendicontazione ecc.

Questo lavoro ci ha consentito anche di stabilire quali servizi attivare per primi e quali lasciare per ultimi. Incredibilmente alla scadenza prevista ci siamo trovati pronti per trasmettere la nostra adesione ad AgID con un dignitoso piano dei servizi.

Ma il catalogo dei pagamenti è un lavoro in progress, basti pensare che ultimamente durante una revisione della modulistica abbiamo realizzato che alcune voci del catalogo (i diritti di segreteria sulle pratiche del SUE [1]) andranno ulteriormente “spacchettate” per poter gestire al meglio i codici IUV [2] e consentire una rendicontazione puntuale.

Rimangono tanti aspetti che ancora dobbiamo chiarire. Uno su tutti il processo di riconciliazione ovvero come si chiuderà il processo di incasso. Non riusciamo tuttora a capire quali informazioni arriveranno dalla tesoreria e come integrarle con quelle che torneranno indietro dal Nodo. Ma sicuramente l’organizzazione sa che costa sta avvenendo, sa anche su cosa ci sono le idee chiare e dove non abbiamo ancora risposte. È comunque un passo avanti.

Da qualche mese poi abbiamo aperto un tavolo di lavoro sul tema dei pagamenti elettronici all’interno del Centro Competenze Digitali Brianza (Comune di Monza capofila) . Stiamo condividendo competenze, strumenti e buone pratiche: particolarmente utile è lo scambio di informazioni sulle soluzioni tecniche e/o organizzative adottate ed anche sugli “intoppi” nei quali ci siamo imbattuti ad es. con le tesorerie o con i fornitori software (in qualche caso comuni).

Negli ultimi 15 anni tutte le volte che si presentava una novità connotata dall’aggettivo informatico o elettronico sembrava di essere ad una partita di palla avvelenata: tutti si scansavano per non essere colpiti.

Il protocollo informatico diventa così un problema del servizio informatico, al massimo un problema del servizio protocollo, e non di gestione del procedimento e di organizzazione dei documenti. Stessa cosa con la fattura elettronica: se non è un problema informatico, la parola fattura fa pensare ad un problema del servizio ragioneria, dimenticando che la liquidazione è quella fase del procedimento di spesa che compete all’ufficio che ha dato esecuzione all’impegno di spesa [3] e ogni settore ha i suoi procedimenti di spesa.

Così anche i pagamenti elettronici dei cittadini verso il Comune rischiavano di cadere in un limbo tra ragioneria, servizio informatico e i vari settori. Abbiamo provato a non cadere nello stesso errore.