software-paLe Misure PNRR per il Digitale hanno evidenziato in modo alquanto chiaro una serie di criticità che affliggono i software per la Pubblica Amministrazione, sia in termini tecnici e di impostazione e soprattutto in termini di modello di business.

A livello tecnico qualcosa è stato migliorato con la revisione del processo di qualificazione dei software nel Marketplace ACN, che progressivamente dovrebbe garantire la presenza di soluzioni che si affrancano dagli attuali “ibridi” per diventare nel tempo software Cloud SaaS o PaaS,  portandone di conseguenza sul mercato gli attesi vantaggi. Dal punto di vista del modello commerciale e di strutturazione, nulla è cambiato.

Attualmente i software tendono ad essere concepiti a “silos” o dei “monoliti”, unici grandi software che coprono ogni esigenza (molto diffusi nelle piccole Amministrazioni) che male si adattano alla nuova realtà che spinge verso il mondo cloud, per la loro “chiusura by design” ad un modello di interoperabilità diffusa.

Questo ha comportato, anche per effetto della particolare impostazione degli Avvisi, all’affermazione sul mercato dell’idea (e della prassi) che ogni nuova funzione che si aggiunge ad un software sia da pagare a modulo, con un investimento ed un canone. Questo modello viene utilizzato sia che si abbia a che fare con Identità Digitale (SPID/CIE), con i pagamenti elettronici (PagoPA), con la Piattaforma Notifiche (SEND), con il Domicilio Digitale (INAD, INI-PEC) o con la Piattaforma Digitale Nazionale Dati (PDND).

Ogni nuovo collegamento ad una piattaforma (e ormai sono numerose)  è considerato un extra rispetto al software da offrire a prezzi “da epoca pnrr”.

Le software house, sebbene debbano giustamente coprire i costi, nella quasi totalità dei casi dimenticano che si tratta di integrazioni, spesso non troppo complesse, dettate da sopravvenuti obblighi normativi e che quindi, in quanto tali, dovrebbero essere incluse nei contratti di manutenzione dei software.

Come conseguenza abbiamo assistito ad una vera e propria esplosione dei costi sia di investimento (coperti dal pnrr) che dei canoni annuali che dovranno essere coperti dalla spesa dei comuni nei prossimi anni. Questo modello commerciale e questo aumento dei canoni non proporzionato allo sforzo implementativo perché basato su logiche di altri tempi e completamente non cloud (non saas) rischia di rendere gli investimenti fatti non sostenibili nel medio periodo.

L’idea di questo articolo è di tracciare una possibile evoluzione, tecnica, normativa e di modello di business dei software della PA.

Si vorrebbe dare degli spunti alla progettazione o all’aggiornamento dei software della pubblica amministrazione in modo da giungere, dopo il PNRR, ad avere strumenti moderni, efficaci e sostenibili, in grado di raggiungere gli obiettivi di efficienza, efficacia e trasparenza dell’attività amministrativa pubblica, nonché ad un reale soddisfacimento del diritto dell’uso del digitale da parte dell’utenza interna agli enti.

Che fare

Per centrare gli obiettivi sopra descritti sono necessari alcuni passaggi propedeutici, che, in sintesi si possono così riassumere.

Estendere le già ottime (ma purtroppo poco note e applicate) Linee Guida per l’Acquisizione e il riuso del Software prevedendo precise clausole obbligatorie da inserire in tutti i contratti che riguardano i software per le PA, come, ad esempio:

  • stabilire che l’integrazione ad ogni piattaforma abilitante deve essere obbligatoriamente supportata e che l’introduzione di nuove piattaforme o variazioni normative, a meno che ciò non comporti sviluppi particolarmente onerosi (es. il caso del passaggio alla contabilità armonizzata che richiese una parziale riscrittura del software contabile) deve essere coperta dal contratto di manutenzione evolutiva senza che questo comporti spese aggiuntive e automatiche variazioni dei canoni manutentivi;
  • stabilire che la proprietà dei dati è inderogabilmente della PA cliente e che la loro disponibilità deve essere garantita anche attraverso strumenti che consentano la possibilità di eseguire ricerche ed estrazioni massive e non, nonché, al termine di contratto, di ottenere, in formati aperti e ben documentati, l’intera base dati, comprensiva degli eventuali documenti (peraltro obbligo per la certificazione ACN);
  • la definizione di SLA di servizio minimi e tassativamente obbligatorie con relative penali da applicare in caso di inadempienza;

Potenziare ed estendere la piattaforma gov.it aggiungendovi vocabolari controllati e API standard per ogni ambito applicativo (contabilità, gestione documentale, tributi, intermediari tecnologici, pagopa, ecc.) o come minimo per ogni base dati di interesse individuata, in modo che ogni modulo software, anche di fornitori diversi, possa comunicare con gli altri in modo standardizzato, rendendone possibile l’interoperabilità. E’ forse questo l’aspetto più importante perché:

  • spezza il vendor lock-in, sottraendo gli enti al ricatto del mono-fornitore e le liberandoli dalla necessità di applicazioni monolitiche;
  • apre il mercato visto che oggi solo pochissimi player possono permettersi di costruire una suite gestionale completa, cosa che ha notevolmente impoverito il mercato e l’offerta)
  • aumenta la qualità, favorendo la specializzazione sulla funzionalità utili allo scopo e non contorno tecnico, ovvero fa tesoro delle piattaforme abilitanti che hanno risolto in maniera standard problemi che prima ogni amministrazione risolve a modo suo
  • esalta l’importanza della PDND, predisponendo ad una vera interoperabilità in caso di dati gestiti da una molteplicità di enti, che non può essere solo tecnica (ad oggi PDND fa solo questo) ma anche semantica
  • integra il processo di qualificazione ACN, con quanto descritto nei punti precedenti;
  • predispone specifici accordi quadro in modo che l’acquisto e la manutenzione abbia una base di contrattazione minima e trasparente, senza comunque escludere contratti economicamente migliorativi (Nota a margine: come armonizzare il tutto con il principio di rotazione?)

Si ritiene che quanto sopra descritto possa rappresentare una semplificazione anche per i produttori che, sollevati da questioni che oggi devono affrontare da soli, con richieste dei clienti spesso contrastanti (e a volte incongruenti e contrarie alle norme)  sono liberi di concentrarsi e di competere sugli aspetti funzionali, differenziandosi anche in base al target (non dimentichiamo che i comuni non sono tutti uguali).

Lo schema

Ogni software dovrebbe avere, indicativamente e semplificando, queste fasi dal punto di vista tecnologico che racchiudono dall’autenticazione alla dashboard di monitoraggio e che hanno come cuore l’erogazione di un servizio.  Lo schema riportato racchiude i “mattoncini” che rappresentano le piattaforme abilitanti rese disponibili negli ultimi 10 anni e quindi anche le componenti tecnologiche necessarie allo sviluppo di un’applicazione per la pubblica amministrazione.

Cosa è incluso e da togliere dai moduli?

Come dicevamo ci sono una serie di aspetti che vanno considerati come “inclusi”.

  1. Se si tratta di un servizio online sicuramente l’autenticazione con SPID e CIE va considerata come inclusa. Possibilmente nel tempo ci sarà da aggiungere anche EIDAS e probabilmente verrà ridotto SPID perché a quanto pare l’intenzione è quella di uniformare l’identità digitale nazionale su CIE. Rimane che l’autenticazione con queste identità digitali nazionali non è opzionale ma è obbligatoria dal settembre 2021.
  2. Secondo la direttiva che contiene gli indirizzi operativi per l’utilizzo della Piattaforma Digitale Nazionale Dati (PDF) (PDND) diventa centrale per la base anagrafica di ogni software collegarsi ad ANPR. Quindi questa interoperabilità diventa un obbligo normativo ed ogni applicativo come base dati anagrafica deve fare riferimento ad APNR. Non ha quindi più senso chiedere un canone per l’integrazione ad ANPR (e in futuri per integrazione ad ISEE etc etc ed a tutte le basi di dati di interesse nazionale)
  3. Una volta effettuata l’autenticazione e la raccolta dati è necessaria un’elaborazione dei dati stessi e questo diventa il cuore del servizio che si vuole erogare. Questo è il differenziante su cui ogni software house dovrebbe potersi concentrare.Qui le software House dovrebbero giocarsi la parte di creatività ovvero rendere l’interfaccia personalizzata anche per l’operatore del comune. Il software potrebbe cercare di metterci quella parte di intelligenza artificiale che aiuti l’operatore nelle sue attività, che imparando come si muove l’utente metta i menù che gli interessano di più in evidenza. L’Ai potrebbe anche apprendere i processi dell’ente in base a come si comportano i diversi operatori all’interno dell’ente stesso e come si muovono fascicoli pratiche e documenti. Questi sono alcuni piccoli spunti di differenziazione ma chissà quanti altri ce ne sono.
  4. Può darsi che ad un certo punto sia necessario dall’applicazione mandare dei messaggi sull’APP IO o dei messaggi di cortesia relativamente al servizio che si è individuato. Visto che le API di app IO sono disponibili online e che il loro interfacciamento è molto semplice anche questo viene considerato come incluso all’interno di un’applicazione. Deve anche essere reso semplice ovvero si tratta ad un certo punto del processo dell’applicazione di flaggare un “invia il messaggio a IO”  e quindi l’utente viene guidato in questo percorso di invio dei messaggi con molta facilità, senza interfacce complicate da seguire.
  5. Ad un certo punto può essere che sia necessario un pagamento nell’ambito del servizio che si sta analizzando. L’integrazione con pagopa, a meno dei limiti normativi di utilizzo che ancora ci sono come ad esempio per gli F24, è la piattaforma per i pagamenti. L’integrazione con pagoPA richiede un’integrazione con il partner tecnologico di riferimento. Se il partner tecnologico pagoPA è la stessa software house del prodotto che ha bisogno di fare il pagamento, l’integrazione è abbastanza semplice e naturale. Se non lo è, purtroppo ad oggi ci sono ancora oneri di sviluppo di un’integrazione ad hoc visto che non esiste, incredibilmente, una standardizzazione per l’interfacciamento a tutti i partner tecnologici. Questo comporta uno sforzo ad hoc per ente e quindi al momento questa parte potrebbe anche essere fatta pagare, con un investimento e un canone, ben lontani però dai valori che si vedono nel mercato. Alcune software house adottano un modello molto intelligente di crowdfunding. Ovvero raccolgono l’esigenza da 5-10 clienti che coprono la spesa iniziale e che poi godono dei vantaggi di essere stati i primi a investire sull’integrazione con degli sconti aggiuntivi rispetto a chi arriva dopo quando la soluzione è a regime. Il modello è molto diverso dall’attuale che di solito prevede che il primo che arriva si sobbarca tutto il costo e quelli dopo invece ne traggono i vantaggi.
  6. Arrivati alla fine dell’erogazione del servizio o del lavoro applicativo, si sono acquisiti, elaborati e prodotti dei dati. Questi dati possono essere resi disponibili con API (PDND) o con opendata se opportunamente anonimizzati. In entrambi i casi si tratta anche qui di moduli, con investimento e canone. Alcune API in particolare sono obbligatorie per la certificazione ACN, oltre al fatto che dovrebbero essere by default registrate dal fornitore in PDND.
  7. Infine sarebbe interessante prevedere una piattaforma di monitoring che permetta di verificare quante carte d’identità vengono rilasciate, quante delibere e determine vengono realizzate, quante tari sono state emesse, etc etc. Il tutto in  modo da rendere più semplice tutta la gestione applicativa e permettere all’ente di rendersi conto dell’effettivo utilizzo di un’applicazione (o di un servizio se verso i cittadini). Questi dati di monitoraggio interni (applicazione) o esterni (servizi) potrebbero essere tranquillamente messi a disposizione in opendata.
  8. Ultimo ma non per importanza la gestione documentale, il cuore dell’attività amministrativa dell’Ente in cui ogni documento prodotto/ricevuto converge ed è gestito. Ogni software dovrebbe essere interfacciato al documentale in modo che ogni documento da questo prodotto possa confluire nel corrispondente fascicolo di pertinenza e, viceversa, da questo lo si possa consultare. Questo permetterebbe di controllare la formazione e la gestione di tutti i documenti dell’Ente fino al corretto conferimento al sistema di Conservazione, che potrebbe avvenire in modo totalmente automatizzato. Il tutto completamente guidato e con spiegazione dei vantaggi di seguire un percorso del genere per un “utente comunale al centro” e una “utente comunale user experience” ottimale. Al livello della gestione documentale si possono poi integrare diversi servizi: dalla firma, anche remota o firma con app IO, ad un gestore (workflow) dei procedimenti (previsto dalla norma) fino ad arrivare a SEND, che troverebbe qui un naturale quanto ovvio punto di integrazione per le notifiche a valore legale.

Conclusioni

Se vogliamo davvero fare un passo avanti nell’ambito dei fondi che i comuni hanno ottenuto per il PNRR e che l’Italia sta spendendo a debito in buon parte e che pagheranno le prossime generazioni, è necessario considerare questo salto di modello tecnologico e normativo  per le applicazioni della pubblica amministrazione.

Se non lo faremo continueremo ad avere silos applicativi che si interfacciano alle piattaforme centrali ma che non parlano tra di loro.  Verranno quindi presentati dei costi per la trasformazione digitale sempre più elevati per i canoni di funzionamento che aumenteranno a “modulo di adeguamento per ogni piattaforma o normativa nuova”.

Fino a diventare insostenibili.

Nelle forme più light quello che si chiede ai fornitori non è di stravolgere immediatamente il loro modello commerciale ma perlomeno di renderlo più realistico e tendere a renderlo un modello per utente per mese, come si confà a un vero software SAAS.

Se prima, nel mondo on premise e abbastanza statico della PA, il modello a modulo poteva avere un senso perché un modulo erano l’anagrafe o i tributi o la ragioneria, lo stesso modello con i componenti e le tecnologie che stanno aumentando esponenzialmente non ha più ragione di esistere o sostenibilità economica. Infatti a seguito delle numerose integrazioni che sono necessarie per collegarsi alle piattaforme centrali e per rendere disponibile open data o API il livello dei canoni sta seguendo una traiettoria preoccupante.

Quanti enti hanno calcolato come aumenteranno i loro canoni appena finita l’onda PNRR?

Anche le software house hanno interesse a non portare all’harakiri da canoni i comuni e volendo possono iniziare per bene pur mantenendo il modello attuale con il ragionamento che segue.

Far pagare ad esempio un canone di 500 euro per la gestione delle API di appIO  a 2000 comuni, vuol dire richiedere al mercato 1 milione di euro di canone l’anno. Ma è davvero necessario per il collegamento di una serie di messaggi ad app IO visto la semplicità delle API. Accontentarsi potrebbe portare ad un canone di 50-100 euro, sostenibile per gli enti, ma comunque che copra i costi che progressivamente potrebbe confluire nel canone applicativo e non essere quindi più visti come un modulo a parte.

Questo è solo un esempio per capire come si possa tenere vivo un ecosistema digitale che grazie ai fondi PNRR sta crescendo oltre le migliori aspettative, ma che deve prevedere un cambiamento di modello tecnico ed economico di medio periodo permettendo ai comuni di non dover decidere nei prossimi anni nel post pnrr, se continuare ad erogare ad esempio servizi alla persona o servizi informatici. Anche perché sappiamo che la scelta sarà ovvia.

Infine, l’articolo non vuole essere esaustivo (il tema è ampio e complesso)né pretende di avere la soluzione facile da attuare, si è solo cercato da un lato di introdurre l’argomento dall’altro di presentare difficoltà e possibili soluzioni per iniziare a tracciare un percorso evolutivo sul tema.

 

 

Fonte: articolo di Andrea Tironi (Project Manager Trasformazione Digitale) e Sergio Sette (Consulente informatico per la Pubblica amministrazione specializzato in digital transformation)