Notizia

Questa mattina all’Osservatorio Agenda Digitale, nel contesto del Workshop “Switch-off dei servizi pubblici” insieme al Comune di Milano, abbiamo presentato l’app nazionale #IO utilizzata nella sperimentazione in corso nel Comune di Ripalta Cremasca.

Ampliamo il portale telematico anche sui servizi sociali e scuola 

Entro il mese di dicembre il portale telematico vedrà ampliare la possibilità di presentazione delle istanze in forma telematica. Infatti anche tutte le istanze dei servizi sociali e dei servizi scolastici verranno digitalizzate per i Comuni di Annicco, Bagnolo Cremasco, Formigara, Madignano, Offanengo, Pandino, Spino d'Adda, Ripalta Cremasca, Crema, Pianengo, Trescore Cremasco e Vaiano Cremasco.

Il Cittadino potrà scegliere se presentare la richiesta direttamente dal portale, se stamparsi in autonomia la modulistica e poi recarsi presso gli uffici per presentare la domanda o se semplicemente consultare le guide dei procedimenti messi a disposizione del cittadino.

In questi giorni sono in corso gli incontri con i funzionari degli enti coinvolti per la definizione e la standardizzazione dei procedimenti.

Abbiamo publicato il nuovo sito del comune di Dovera realizzato nel rispetto delle nuove linee guida AGID. E' possibile consultare le soluzioni di rinnovamento dei siti comunali presso questo link https://linee-guida-agid.comune-informa.it/

Mercoledì si terrà a Bologna Il secondo "Raduno nazionale dei responsabili per la transizione al digitale delle pubbliche amministrazioni", sarà un momento di confronto e approfondimento sui temi caldi dell'innovazione nelle PA.Saremo presenti al Raduno nella veste di Relatori sul tema “la trasformazione digitale della PA per il cittadino : organizzazione e tecnologie“

Qui trovate il programma e il form per le iscrizioni (gratuite) http://bit.ly/2NQAOLo

Prosegue il cammino di PagoPa verso la scadenza del 31 dicembre 2019, quando i prestatori di servizi di pagamento non potranno più eseguire pagamenti a favore di PA che non transitino per il sistema. Facciamo il punto sui problemi ancora aperti in tema di rendicontazione e come potrebbero risolversi.

Nell’ambito del sistema di pagamenti verso la pubblica amministrazione, pagoPA, la riconciliazione ha ancora questioni non risolte, a quanto risulta dalla mia esperienza.

La riconciliazione in pagoPA si traduce nella possibilità di verificare che il flusso bancario corrisponda al rendicontato, ovvero verificare che i “soldi in banca” e il dichiarato nella rendicontazione (flusso informatico del nodo dei pagamenti) corrispondano. In tale modo si risolve “il dilemma del ragioniere” che teme sempre che quanto affermato dal flusso informatico (rendicontazione) non corrisponda a quanto incassato (provvisorio), detto anche “mancanza di trust” culturale verso il nodo dei pagamenti (che nel tempo dovrebbe svanire).

Indice degli argomenti

Come viene risolto manualmente il dilemma?

Il ragioniere riceve il provvisorio per 20 euro che si riferisce al pagamento di Andrea Tironi per il rinnovo della Carta di Identità Elettronica e grazie all’Id del flusso di rendicontazione nella causale del provvisorio associa il corrispondente flusso di rendicontazione. A questo punto fa la reversale, i soldi vengono “accettati” il giro si chiude.

Come spiegato nell’articolo precedente, questo va bene per un numero mediamente basso di transazioni, diventa difficile per un numero alto di transazioni per la mole di lavoro richiesta.

Anche per numeri relativamente bassi, è chiaro che nel mondo della tecnologia e delle integrazioni, la prima cosa che viene da pensare è: come automatizzare questo meccanismo in modo da liberare tempo al ragioniere e permettergli di fare solo i controlli delle anomalie, mettere solo una spunta per l’ok senza saltare da un sito all’altro (o da un foglio excel all’altro, o da un a3 di carta all’altro) e fare cose a più alto valore aggiunto?

In fondo si tratta di un semplice matching di codici e valori, niente altro. Le possibilità sono due.

La riconciliazione a livello di partner tecnologico

La riconciliazione viene fatta a livello di partner tecnologico, che chiama le API (servizi) della banca, legge il giornale di cassa (mediante OPI), dentro il giornale di cassa trova i provvisori, li processa dividendoli per servizio e quindi fornisce un report al ragioniere che dà come risultato:

Servizio 1: totale euro
provvisorio1 valore euro1 id rendicontazione1
provvisorio2 valore euro2 id rendicontazione2

servizio 2: totale euro
provvisorio50 valoreeuro50 id rendicontazione50
eccetera

Anomalie
elenco anomalie.
doppioni

Elenco doppioni (in caso di OPI ricaricati nuovamente)

Questo permette al ragioniere di avere un processing automatico che riassume per servizio quanto viene incassato. E quindi tutta la fase di verifica del matching tra rendicontato e banca viene fatta in automatico.

Lo svantaggio è che al ragioniere rimane la parte in cui una volta visti i totali deve inserirli nelle corrette voci del bilancio del software di ragioneria, in modo da avere il lavoro completato. E quindi fare le reversali.

Come risolvere questo: sempre con l’integrazione. Integrando il software della contabilità in modo che possa leggere le pratiche e quindi in base al fatto che il flag “riconciliato” dice “si” e al codice di riconciliazione indicato, ogni notte (o in periodicamente) inserire le voci nei giusti conti contabili.

Il vantaggio è che questo meccanismo, pure risolvendo parzialmente il problema dell’automatizzazione, vale per tutti i servizi dell’ente appoggiati al PT, anche quelli che non hanno software verticali gestionali (es.diritti di Segreteria, riscossione pagamento CIE).

La riconciliazione a livello di software di contabilità

L’altro livello a cui si può fare la riconciliazione è quello di importare gli OPI direttamente nel software di contabilità. Questo permette nel software di vedere i provvisori e quindi inserire i dati direttamente sulle corrette voci di bilancio una volta dato l’ok da parte del ragioniere.

Ci dovrà comunque essere una comunicazione/integrazione con il software del PT per la gestione delle rendicontazioni, in modo da fare il matching tra OPI e rendicontato.

Inoltre, il software del PT dovrà comunque continuare a parlare con un eventuale verticale esterno (es. software della Mensa) per ricevere le pratiche da pagare e potrebbe essere necessaria un’integrazione del verticale anche verso il software della Contabilità per uno scambio di informazioni a tutto tondo.

Niente di che, in un mondo ad alta integrazione. Qualcosa di non immediato al momento nella PA italiana, ma che un domani può diventare la normalità.

I due temi che restano aperti

Il primo: le Poste non hanno un OPI a quanto ci risulta, come riconciliare i flussi bancari dei conti postali? Anche Poste produrrà un OPI o si ricade nella seconda domanda?

Si dovrà quindi fare in modo di processare laddove c’è una banca un OPI, ma dove c’è la Posta un conto corrente? Per linee guida anche le Poste devono produrre flussi di rendicontazione a standard pagoPa, quindi vedremo come le Poste nel tempo permetteranno questa riconciliazione che è importante per automatizzare il “giro pagopa”.

Il secondo punto aperto: per gli enti pubblici non comunali (es. utilities), la banca dà un estratto conto (come quello di casa), non un OPI. Nell’estratto conto spesso l’id del flusso di rendicontazione è tagliato per motivi tecnologici (non ci sta nel campo previsto dai sistemi), quindi come si può effettuare la rendicontazione? Su questo punto nel tempo è normale che le banche si adegueranno mettendo un campo più ampio. Prima lo faranno, meglio è.

Infine, c’è un terzo punto aperto, che abbiamo dalla “notte dei tempi” di pagoPA: in alcuni casi, il flusso di rendicontazione non è obbligatorio laddove la transazione è singola. In questi casi la riconciliazione va fatta a ritroso: se ho i soldi allora sicuramente ho rendicontato e quindi do per assunto che la riconciliazione è ok.

Le buone notizie

Fortunatamente anche questi casi nel tempo spariranno: più transazioni ci saranno più si annullerà la probabilità di avere PSP che rendiconteranno flussi con una singola transazione, potendo laddove ritengono di non mandare il flusso. Questo sia nelle PAL (pubbliche amministrazioni locali) che nelle PAC (pubbliche amministrazioni centrali).

Possiamo dire quindi che PagoPa prosegue il suo cammino, verso la scadenza del 31 dicembre 2019 e dopo la costituzione della nuova Pagopa s.p.a. che si occuperà anche dell’app IO e di Data & Analytics Framework (Daf).

Nella PA l’open source è ancora considerato una novità, il cui uso è già stata trattato in documenti come le Linee guida Agid su acquisizione e riuso dei software. Standardizzazione, nerworking e soluzioni condivise sono solo alcuni degli obiettivi dell’opensource: aspetti utili da approfondire.

Open source: vi sembra un concetto ormai scontato? Ricredetevi: c’è un posto al mondo in cui pronunciare queste due paroline assieme vi farà ancora apparire incredibilmente pionieristici. La PA (italiana). Alcuni persino, lì dentro, all’udire le due magiche parole vi guarderanno come personaggi di un film di fantascienza.

Già, l’open source nella PA sembra una cosa assolutamente nuova, sebbene sia una tendenza che anche in questo settore si sta sviluppando in tutta Europa.

Se ne è parlato per diversi anni fino ad arrivare al catalogo del riuso presente su Developers Italia e alle Linee Guida su acquisizione e riuso del software nella PA di Agid (che contiene già come allegati tecnici dei moduli da inserire nei bandi di gara: assoluta novità che semplifica il lavoro della PA e dei fornitori nel procurement, creando standard).

Allora, vogliamo finalmente far pace tra open source e pubblica amministrazione italiana? Non è mica fantascienza, no: impariamo come declinare questo concetto nella realtà di tutti i giorni della PA.

Opensource nella quotidianità della PA

Prima di tutto va fatta una distinzione tra acquisizione di un software e commissione di un nuovo software. Nel primo caso si acquista un software esistente, già utilizzato dalla PA, mentre nel secondo caso si commissiona un software nuovo.

L’acquisizione di software

La prima cosa da fare quando si acquisice un software, è vedere se c’è un equivalente nel catalogo del riuso. Se c’è, va verificato se ha i requisiti richiesti: se si, potrebbe essere il prodotto che fa per noi, se no, allora si può procedere all’acquisizione. A questo punto ci si domanda: devo acquisire un software open per legge? Se la risposta fosse si, questo sembrerebbe la killer-app per tutte quelle software house che fanno da fornitori e fanno business con la PA, vendendo la loro suite di gestione (anagrafe, ragioneria, tributi …). Infatti sembra che tutti debbano rendere aperto il loro codice, trasformando anni di investimenti in risorse economiche e non, in un codice aperto e che tutti possono copiare (ma a cui del resto tutti possono contribuire). La preoccupazione è lecita: se oggi rendo il mio codice open, diventa “proprietà della comunità” e quindi altri possono contribuirvi e/o copiarlo (secondo la licenza che viene specifica). In verità non è esattamente così: l’open non è la killer-app. Le software house più grandi fornitrici della PAL hanno impiegato risorse economiche e non per realizzare i loro software e negli ultimi anni sono passati dalla vendita di un prodotto (il software) alla vendita di un servizio (il software è gratuito, ma vanno comprati: installazione, avvio, manutenzione, aggiornamenti, assistenza, etc etc).

Quindi il software open prosegue in parte questo percorso: il valore aggiunto non è più il prodotto, ma il servizio associato. Per cui rendere il proprio codice libero, rende il know how più condivisibile e forse vulnerabile, ma d’altra parte rende comunque necessarie le operazioni di installazione, manutenzione, aggiornamento…di cui si parlava sopra, che è difficile acquistare da altri fornitori. Gare Consip docet: in queste si poteva acquistare l’assistenza su dei prodotto dalla software house A riferiti al software della software house B. Sarei curioso di sapere quanti acquisti ci sono stati, per capire se il modello ha una sua fattibilità oppure no, basandomi sui dati. Per l’esperienza che ho, direi che è un modello difficilmente praticabile. Proseguendo il discorso, in ogni progetto open ci deve essere un regista che decide se la pull request (la richiesta di modifica o aggiunta funzionalità) o la issue (problema o considerazione) vanno valutati, e questa non può che essere la software house realizzativa. Infine, capire un codice aperto da 10 o 100 milioni di linee di codice, non è proprio una cosa immediata, anche se forse fattibile per alcuni colossi che volendo potrebbero affacciarsi al mondo PAL sfruttando questa occasione di apertura dei codici.

Comunque sia, riassumendo, non è l’acquisizione il target del movimento opensource nella PA e chi ha investito diverse migliaia di euro per fare una suite che il mercato ha accettato (ovvero ha diverse decine di clienti) può dormire sonni tranquilli, almeno per il momento. Questo perché tipicamente il software che fa parte dell’area “acquisizione” è un software largamente diffuso e utilizzato da alcune decine o centinaia di enti, quindi un prodotto che segue cicli di sviluppo, stabile e largamente utilizzato. Non si inventa niente di nuovo, semplicemente si prende qualcosa che il mercato ha già riconosciuto come una possibile soluzione ai suoi problemi o come strumento per erogare i suoi servizi. In un’ottica di mercato e senza sprechi economici particolari. La battaglia quindi dei fornitori che forniscono software acquisito ovvero acquistato e non commissionato, rimane sulla qualità della soluzione. Non sull’open o meno.

Commissione di un nuovo software

Qui l’open è padrone. L’obiettivo principale è “evitare di reinventare la ruota”. Mi spiego meglio: l’ente A commissiona il software S1 per la intranet all’azienda X. Dopodichè non lo mette a riuso. L’ente B allora commissiona il software S2 per la intranet all’azienda Y. E non lo mette a riuso. E così via. Alla fine quindi ci troveremo con un gran numero di software di intranet, tutti diversi (nessuna standardizzazione), tutti poco usati (da 1 ente, massimo una decina, magari gli enti vicini geograficamente all’ente che l’ha commissionato; oppure magari un centinaio se il software è commissionato da una provincia o una regione), tutti acquistati con soldi pubblici (quindi con spreco di soldi pubblici che in maniera poco efficiente vengono spesi per costruire lo stesso software e affrontare gli stessi problemi facendo gli stessi errori). Non è detto infine che le 8.000 intranet siano tutte di buona qualità.

Nel nuovo modello open, se voglio commissionare un software prima verifico se c’è a riuso (quindi l’ente B troverà il software dell’ente A), evitando duplicazioni o simili. Se poi non ha tutte le funzionalità di cui ho bisogno, dovrei prima di tutto interrogarmi del perchè ho bisogno di funzionalità che un altro ente non ha e se ne ho davvero bisogno. Se la risposta è si, allora posso motivare il non utilizzo del catalogo del riuso ad Agid e quindi procedere ad un’acquisizione che poi dovrà essere messa in riuso.

Gli obiettivi dell’opensource

Gli scopi quindi dell’opensource sono permettere di:

• Avere un catalogo dove poter cercare soluzioni condivise, senza dover reinventare la ruota. Se cerco una soluzione per il servizio Intranet, posso cercare nel catalogo del riuso. Se lo trovo, posso provare ad usare quel prodotto, facendo riferimento alla PAL che l’ha messo a riuso per chiarimenti su come l’hanno utilizzato e facendo riferimento al contractor (il fornitore) per le fasi di installazione, assistenza, manutenzione, aggiornamenti, etc etc;
• Fare rete. Mano a mano che il catalogo cresce, come PAL, potrò avere una visione completa di quanto è stato commissionato dalla PA come sviluppi, e quindi fare rete con chi usa il mio stesso prodotto, aumentando la condivisione di informazioni, i rapporti ed eventualmente portando a condivisioni di costi per nuove funzionalità o modifiche,con sinergie organizzative ed economiche.
• Standardizzare. Se ogni PAL fa la sua intranet, avremo ad esempio 8.000 intranet una per comune. Se tutti fanno riuso, ne avremo (nel caso migliore) 1 per tutti gli 8.000 enti. Questo crea una standardizzazione degli strumenti (per cui se un dipendente si sposta da un comune all’altro, trova gli stessi strumenti ovvero la stessa intranet).
• Economicità. La PA evita di commissionare più volte gli stessi prodotti. Perlomeno prima di farlo è prevista una riflessione dovuta al CAD .
• Trasparenza. Si forma un catalogo dei software commissionati, che permette anche un monitoraggio dell’operatività delle PA a tutti i livelli.
• Cultura. Inizia un percorso di condivisione di soluzioni, di competenza, di esperienze che è fondamentale si crei nella PA se la PA vuole accelerare il suo percorso di crescita digitale.
• Qualità. Visto che il prodotto diventerà open, potrà essere messo anche a pubblico “ludibrio”. Questo dovrebbe spingere a fare software di maggiore qualità, considerando anche la prospettiva di metterlo nel catalogo del riuso. Ipotizzando ad esempio che la prima intranet messa a riuso sia di bassa qualità e la seconda di alta, è chiaro che tutti sceglieranno la seconda.

Si tratta quindi di un percorso molto interessante intrapreso dalla PA, probabilmente ancora di valore solo per gli early adopter, ma dai numerosi risolvi tecnici, economici e di business che riguardano anche i fornitori.

Come mettere a riuso un software

Le operazioni per chi è programmatore sono semplici:

• si crea un account (ad esempio) github
• si crea un’organizzazione per la PAL, esempio “Comune di Rocca Cannuccia”
• si carica il codice
• si fa un README.md per dire di cosa si trattaq
• si fa un publiccode.yml in modo che i motori del catalogo del riuso possano individuare il codice e metterlo in indice (mediante l’editor messo a disposizione dal Team Digitale)
• si esegue la procedura di onboarding
• si aspetta l’email per confermare l’indicizzazione in 24–48 ore
• il codice dovrebbe essere indicizzato in 24–48 ore

Il contesto normativo

Le leggi che governano questo percorso, per chi volesse approfondire, sono:

• Articolo 68 Cad: in caso di acquisizione di un nuovo software, una PA deve prima verificare se può utilizzare del software in riuso e contemporaneamente fare una valutazione comparativa tra software in riuso (se presente) e software a mercato.
• Articolo 69 Cad: una PA che commissiona un software ha obbligo di rilasciarlo in formato opensource. Tale norma è retroattiva.

Senza una crescita non solo della PA, ma anche dei suoi fornitori, il sistema operativo del paese non può cambiare. E’ stata una intuizione dell’ex Commissario straordinario Diego Piacentini e il tema dell’incontro dal titolo “Completiamo insieme il sistema operativo del Paese”, organizzato dal Team Digitale.

Anche le software house fornitrici della PA devono fare la loro parte nel percorso di digitalizzazione e semplificazione della pubblica amministrazione, per il bene di tutti.

E’ questo uno degli spunti che ho potuto trarre dall’incontro dal titolo “Completiamo insieme il sistema operativo del Paese”, organizzato dal Team Digitale lo scorso 2 luglio a Roma, con lo scopo di coinvolgere ancora di più le software house fornitrici della PA in questo complesso ma fondamentale processo di trasformazione della pubblica amministrazione.

Indice degli argomenti

La previsione di Diego Piacentini

L’incontro mirava anche a dare un seguito al primo incontro di questo tipo avvenuto nel 2017, sempre nello stesso periodo e voluto dall’allora Commissario Straordinario Diego Piacentini.

Piacentini aveva capito a pochi mesi dal suo investimento, che senza una crescita non solo della PA, ma anche dei suoi fornitori, il sistema operativo del paese non poteva cambiare.

L’incontro avvenuto il 2 Luglio ha permesso al Team Digitale di fare un punto della situazione su ogni progetti in corso e di portare alcuni “case studies” o “PA” che hanno collaborato ad alcuni progetti, a presentare il proprio punto di vista, nell’ottica di ascoltare le esigenze dell’utente finale.

Il percorso delle PA verso il cloud

Come ConsorzioIT, insieme a Cristian Lusardi, abbiamo potuto avere un piccolo spazio per segnalare due challenge con call to action e una challenge con opportunity che speriamo possano essere colte dai fornitori della PA, per aiutare le PA stesse a iniziare il percorso di migrazione al cloud, ormai avviato dopo la pubblicazione del Cloud Enablement Kit.

Challenge 1 — Supporto alla compilazione del Kit e al cloud enablement

Serve supporto da parte dei fornitori di soluzioni software della PA per permettere ai comuni la completa comprensione del funzionamento delle loro applicazioni e dell’utilizzo effettivo.

Call to action 1

I fornitori software per aiutare la PA potrebbero/dovrebbero:

• Preparare una documentazione tecnica adeguata alla compilazione del kit e alla comprensione dello stack tecnologico da parte degli enti, in modo da poterla consegnare agli enti o ai futuri centri di competenza su richiesta. In tale modo questi ultimi potrebbero avere comprensione dell’intero stack tecnologico delle applicazioni che vogliono migrare al cloud
• Fornire strumenti per la comprensione del reale utilizzo delle soluzioni come parte integrante delle soluzioni (monitorazzio dell’utilizzo effettivo first). La PA compra soluzioni che poi nel tempo vengono più o meno utilizzare. Sarebbe importante dentro le applicazioni avere delle dashboard che misurino l’utilizzo effettivo, in modo da capire quali applicazioni davvero vengono utilizzate e quanto. In tale modo, si capirebbe quali sono le applicazioni “core”, quali applicazioni potrebbero essere dismesse eventualmente perchè poco utilizzate e quindi poter disporre di soldi per investirli in servizi più efficaci. Anche in ottica riusco questo è importante, perchè si potrebbe fare riuso laddove si abbiano anche metriche di utilizzo: ha poco senso fare riusco di un’applicazione non utilizzata.
• Essere aperte nello sviluppo ai vari strumenti utilizzabili nel cloud, tenendo conto delle logiche del cloud. Ad esempio un’applicazione che funziona solo sotto windows nel cloud è limitante, perchè non permette la scelta anche di linux, che su alcuni cloud provider permette risparmi anche del 50%.
• Iniziare a creare al proprio interno dei team di devops, superando la ormai vecchia logica del programmatore e del sistema. Ormai con i devops o gli full stack developer, si parla non più di orizzontalità di competenze, ma di verticalità di competenze. La Pa avrebbe bisogno quindi di trovare competenze che siano superiori nei fornitori, che spesso usano l’obsolescenza della PA come alibi per non migliorare e innovare il mercato.
• Sarebbe interessante una volta create community devops interne alle software house, fare una grande community esterna, tra devops dei fornitori software della PA, ma forse questo è un po’ futurista.

Challenge 2 — API e Integrazioni

Necessità di aprire i software con api, permettendo integrazioni di informazioni, in ottica di interoperabilità, open data e così via.

Call to action 2

I fornitori software per aiutare la PA potrebbero/dovrebbero:

• Passare i software da monoliti chiusi a integrati e integrabili. Spesso ai fornitori della PA piace il lockin, perché sentono di tenere il cliente sotto il loro controllo. Questo purtroppo rallenta sia loro che i clienti, che nella PA sono già abbastanza lenti di loro. Il lock in inoltre comporta necessità di integrazioni solo all’interno della propria software house, semplificando le interazioni. L’ipotesi sarebbe quella (che peraltro ipotesi poco è visto che Anpr e pagopa tanto per dirne due hanno già creato necessità di collegamento tra sistemi), abbandonare il vecchio metodo dell’integrazione basata su tracciati e csv, e passare al mondo delle API, dei servizi Rest, delle integrazioni in real time senza batch. Questo comporta uno sforzo di integrazione iniziale superiore, ma un’aggiunta di valore finale notevole. Il valore è indicato dal tempo (realtime) in cui avvengono le comunicazioni e dal fatto che la PA non deve occuparsi dell’integrazione come fa oggi, facendo da intermediario tra due fornitori, ma li deve solo mettere in contatto e spiegare l’obiettivo, saranno poi i fornitori a comunicare dando la soluzione.
• Rendere l’integrazione la normalità e non un’eccezione, pensare che essere interoperabili, aperti e pronti all’integrazione è un’opportunità di rendere il mercato più mobile, più fluido e soprattutto di costruire servizi che oggi nemmeno ci sono, in una logica di Composizione inter-PA: in questo caso un insieme di applicazioni comunicano, anche in maniera bidirezionale, al fine di comporre una nuova logica applicativa ottenuta dalla loro interazione, ed erogare questa a sua volta come servizio a valore aggiunto.

Challenge 3

L’esigenza delle nostre aziende e dei nostri enti è di poterci concentrare sull’erogazione dei servizi. Abbiamo quindi bisogno di soluzioni già cloud-compliant che ci permettano di semplificare la parte di ingegnerizzazione dando l’opportunità di scelta fra i vari servizi cloud.

Opportunity

Qui ci sono due grosse opportunità da valutare, di crescita culturale.

La prima prevede il passare da sviluppare le applicazioni per il solo “adempimento normativo” del CAD, della legge, o della circolare Agid, a sviluppare anche tendendo conto dell’Innovazione Tecnologica presente nel piano triennale e nel mondo tecnologico.. Questo permette di portare vero valore aggiunto nella PA. Quindi saltare dalla logica del “minimo sforzo massimo risultato” a “giusto sforzo eccellente risultato” in modo da aiutare (ricordiamo lo scopo dell’evento del 2 Luglio) Agid e Team a cambiare davvero la PA.

Partire dalle reali esigenze degli utenti

Oltre a tenere conto dell’innovazione tecnologica, è importante iniziare a partire dagli user needs (le esigenze reali degli utenti). Probabilmente essendo il pubblico formato per oltre il 70% de personale sopra i 50 anni, lo user needs attualmente più richiesto sarà “quando andrò in pensione?”. Del resto la PA dovrà progressivamente essere rinnovata e una serie di mentalità da dinosauri tecnologici verranno soppiantate dall’arrivo di millenials che avranno un sacco di idee su come semplificarsi e semplificare la vita e il lavoro. Questa ondata di aria fresca va intercettata per innovare davvero la PA.

Da parte nostra stiamo già facendo esperimenti in tal senso, coinvolgendo i cittadini come supporto locale, alla beta di IO; abbiamo creato un tavolo di lavoro tra ragionerie (7) per raccogliere i requisiti per attivare e rendere migliore possibile la riconciliazione in pagoPA. Sicuramente piccoli passi, ma passi importanti e situazioni che solo qualche anno fa era impossibile anche solo pensare.

Sperando di aver dato qualche spunto di riflessione, chiudo con una frase che mi ha molto colpito, presente nelle slide dell’evento e che ha fatto un po’, per me, da slogan dell’esperienza di Roma:

La digitalizzazione dei servizi della PA mira a semplificare i doveri e avvicinare i diritti.

Anche le software house fornitrici della PA, a mio avviso, devono fare la loro parte in questo percorso, per il bene di tutti noi italiani. Dipende come vogliono vedere la PA: una mucca da mungere o un partner con cui crescere insieme?