Nel lontano 2012, nel momento in cui introduceva pagoPA, forse neanche AGID avrebbe pensato di porre le basi di una vera e propria rivoluzione digitale per il mondo della PA. La ragione non è certamente legata all’introduzione di nuove tecnologie: quelle erano già disponibili da tempo.
Indice degli argomenti
PagoPA, il primo passo verso la rivoluzione digitale della PA
La rivoluzione portata da pagoPA si nasconde dietro “l’innocua” facciata di pagamento digitale ovvero nell’opportunità di un nuovo possibile processo operativo digitale per la PA.
Infatti, nel preciso momento in cui i dati essenziali delle posizioni debitorie generate da un ente sono diventate digitali quegli stessi dati non sono più stati esclusivo appannaggio del singolo ufficio dell’ente che ha predisposto l’avviso di pagamento. Il pagamento è diventato un dato che poteva e può essere trasferito, cosa non da poco, in primis ai diversi uffici dell’ente stesso e successivamente anche a soggetti terzi (altre PA, aziende, cittadini).
È stato questo il grande apporto di pagoPA nella transizione digitale della PA. Ha aperto il mondo della PA ad un nuovo modo di fare le cose, un tipo di organizzazione nuova, orizzontale, che molto velocemente è diventata una galassia di piattaforme abilitanti, nuovi asset digitali collegati fra loro, che spaziano dalla comunicazione “informale” ed immediata al cittadino (APP IO), a quella a valore legale (SEND), fino a una piattaforma come quella di interoperabilità che consente a tutti i soggetti (Pubblici e privati) di comunicare dati secondo un protocollo standard (PDND). PagoPA ha introdotto anche il concetto di integrazione che apre a sua volta alla circolazione dei dati e alla comunicazione tra applicativi e fornitori diversi. Il tutto per passare dal concetto di dato, al concetto di conoscenza.
La reazione dei fornitori gestionali della PA al cambiamento
Il tema della resistenza al cambiamento vale per tutte le organizzazioni, non solo per la Pubblica Amministrazione. Non tutte le Software House hanno colto da subito la portata del cambiamento in atto. Tuttavia, soprattutto con la decisiva spinta del PNRR, molte Aziende hanno adeguato o stanno adeguando le proprie soluzioni tecnologiche. Purtroppo però a fianco alla migrazione tecnologica verso soluzioni SaaS o all’integrazione necessaria con le piattaforme abilitanti (pena, ricordiamolo, la non compliance della PA cliente o l’impossibilità ad attivarsi sul catalogo ACN) non si accompagna un altrettanto repentino cambio di “mentalità”.
Dall’autogestione dei servizi alla necessità di un approccio unificato
Nella PA fino a pochi anni fa ed in alcuni casi ancora oggi, vigeva il concetto di silos e autogestione delle singole aree. Ogni ufficio era essenzialmente un organismo autosufficiente. Lo svantaggio di questo tipo di organizzazione era senz’altro l’impossibilità di disegnare un progetto funzionale cross ufficio ed unico per l’ente, declinandolo in funzione delle diverse caratteristiche dei processi. Con il PNRR e la nuova “mentalità” introdotta dalle piattaforme abilitanti tutto, a tendere, dovrebbe mirare ad un processo operativo unico e orizzontale che va dal primo trigger (attività di protocollo) all’ultimo (reversale in contabilità) in un disegno ciclico e non più gerarchico. Va da sé che i software che si occupano della gestione dei singoli servizi restano centrali ma devono fare un passo in più, non meramente tecnico.
Gli enti non avranno più bisogno esclusivamente di un prodotto (per quanto tecnologico e all’avanguardia) ma di una soluzione.
La differenza tra un prodotto software e una soluzione software
Un prodotto è un pacchetto chiuso di funzionalità. Ha un perimetro di azione ben definito che non risponde ad obiettivi stabiliti in accordo con il Comune.
Una soluzione invece, come suggerisce l’etimologia stessa della parola, parte sempre da un obiettivo che di solito è la realizzazione di un progetto. E quindi parte rilevante della nuova domanda della PA del futuro sarà relativa a competenze di Project Management.
Facciamo un esempio pratico. Immaginiamo le prerogative di un contratto di fornitura del Gestionale per i Servizi Scolastici:
- Serve il Gestionale, ovviamente, con tutte le funzionalità più o meno avanzate per la gestione dei servizi, e fino a poco tempo fa bastava solo questo.
- Serve certamente che il pagamento delle posizioni debitorie avvenga con pagoPA, e quindi serve che tale Gestionale sia integrabile con i principali Partner Tecnologici pagoPA, oppure che la soluzione pagoPA che tale Gestionale utilizza possa interfacciarsi agevolmente con il gestionale di contabilità che il Comune utilizza.
- Serve probabilmente che il Gestionale sia in grado di associare alla posizione debitoria che emette un codice contabile indicato dal Comune.
- Serve certamente che il Gestionale metta a disposizione delle funzionalità per interagire con i genitori attraverso i servizi App IO del Comune.
- Serve certamente che se il gestionale prevede un’interfaccia online per i genitori con determinate funzionalità queste siano accessibili tramite identità Digitale (SPID, CIE, preferibilmente anche eIDAS) e conformi alle linee Guida legate all’Esperienza del Cittadino. Non solo, probabilmente potrebbe servire una qualche integrazione con la società che si occupa della gestione del Sito Istituzionale del Comune.
- Serve certamente che per le riscossioni coattive tale Gestionale sia integrato con SEND, direttamente o tramite il Partner Tecnologico SEND che ha scelto il Comune, e che il partner pagoPA utilizzato per le sue posizioni debitorie permetta l’attualizzazione dell’Importo.
Se pensiamo che fino a qualche anno fa le richieste si fermavano al punto 1 elencato sopra, è chiaro che nessun gestionale oggi può soddisfare tutti i requisiti di progetto sopra elencati. La situazione as is quindi va analizzata in fase di contratto e va immaginato il più dettagliatamente possibile il to be.
Il ruolo del project management nella fornitura di soluzioni software
Non solo: mentre prima l’Ufficio Scuola poteva scegliere indipendentemente il gestionale più adatto alle proprie esigenze, ora chiaramente non può più essere così perché nel fare la scelta deve pensare all’insieme tecnologico dell’ente e non solo al proprio bisogno.
Significa anche che una volta siglato il progetto (non solo la vendita del prodotto) e firmato il contratto il reparto Assistenza dell’Azienda che fornisce il Software dovrà interfacciarsi con diverse aree dell’Ente ed acquisire competenze e informazioni trasversali ai vari uffici. Nonché deve mettere in conto di integrarsi con software di altri fornitori. Infine, dovrà essere in grado di supportare l’Ente nell’adesione alle piattaforme abilitanti, di interfacciarsi con altri fornitori, immaginare un workflow… Un reparto di Assistenza per come è oggi inteso non è più sufficiente, va bene per un prodotto. Per una soluzione serve un’ evoluzione in reparto di Project Management.
Siamo coscienti che un cambio di mentalità tanto imponente non possa avvenire dall’oggi al domani, anche perché il mercato è fatto di domanda e offerta e se la PA non ha ancora gli strumenti sufficienti per porre la corretta domanda, l’offerta stenterà a palesarsi. Ci sembra altrettanto probabile però che questo sarà il modello futuro nel mercato della PA.
Occorrono quindi nuovi modelli di business, in cui i requisiti tecnici (che per le piattaforme abilitanti sono relativamente semplici e standardizzati) siano parte integrante dei pacchetti venduti dalle aziende, mentre andrebbero affiancati e valorizzati i nuovi requisiti di consulenza sotto forma di project management e assistenza cross piattaforma.
Verso nuovi modelli di business: l’interoperabilità come must have
L’interoperabilità fra i diversi fornitori deve diventare un valore aggiunto o forse addirittura un must have, in completa controtendenza con le attuali logiche commerciali. Ci sono fornitori che l’hanno capito e iniziano a fornire le integrazioni “incluse” come primo passo.
Questo non significa che la concorrenza fra le aziende non esisterà più e vivremo in uno scenario idilliaco in cui le aziende private non avranno più necessità di pensare al business. Semplicemente la sfida probabilmente si sposterà dal campo delle soluzioni anche al campo dei servizi di gestione del “sistema operativo di un ente” e quindi dovrà necessariamente ritararsi sia la domanda che l’offerta. Il tutto sia nell’ambito dei servizi, che aggiungeranno all’assistenza di prodotto il project management, sia nell’ambito dell’apertura delle basi di dati, con un’evoluzione di mentalità dal lock-in come valore all’open come valore.
Parafrasando il celebre verso di John Donne: nessun software è un’isola, completo in se stesso; ogni applicazione è un pezzo del workflow, una parte del tutto.
