Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Direttore responsabile Alessandro Longo

il quadro

Innovare la Pubblica amministrazione, che cosa significa in fondo

di Massimo Canducci, professore Innovation Management Università di Torino e responsabile Innovazione di Engineering

05 Gen 2018

5 gennaio 2018

La trasformazione digitale della PA è un meta-progetto di innovazione che deve concentrarsi sull’identificare, pianificare e governare tutti i sotto-progetti, avendo in mente che l’obiettivo vero è la semplificazione della vita del cittadino

Quando si parla di applicazione dell’Agenda Digitale, o di digitalizzazione della Pubblica Amministrazione, spesso si tende a considerare questi processi come tradizionali progetti IT, nei quali si debba in qualche modo digitalizzare l’esistente, sostituendo tecnologie obsolete con qualcosa di più moderno e pubblicando qualche dataset con licenza Open Data.

Si fa l’errore, quindi, di non considerare il contesto in cui viviamo, un contesto in cui il rapporto tra il cittadino e la pubblica amministrazione è spesso complicato, basato sulla sfiducia e sull’imposizione ed in cui un semplice elimina-code viene percepito dal cittadino come una grande innovazione perché gli consente di non passare in piedi la lunga attesa allo sportello, un’attesa magari necessaria per consegnare ad un ufficio un documento proveniente da un altro ufficio della stessa pubblica amministrazione.

È il momento di iniziare a considerare queste iniziative per quello che sono: dei veri e propri processi di innovazione che hanno poco in comune con i tradizionali processi di produzione tradizionali, seguono logiche diverse, hanno bisogno di competenze e risorse di tipo diverso e si misurano con KPI che nulla hanno a che fare con gli indicatori utilizzati tradizionalmente nei processi di produzione.

La trasformazione digitale della PA è un meta-progetto di innovazione che deve concentrarsi sull’identificare, pianificare e governare tutti i sotto-progetti, avendo in mente che l’obiettivo vero è la semplificazione della vita del cittadino, traendo vantaggio dalle tecnologie digitali, e non, come purtroppo spesso accade, una conversione al digitale di processi antiquati e lontanissimi dalle esigenze della popolazione.

 

I valori di una PA digitale

La prima cosa da fare, per andare nella direzione della trasformazione digitale della PA, è stabilire con chiarezza quali siano gli obiettivi che vogliamo raggiungere e quali i “valori” che potranno essere espressi da una futura PA in buona parte digitalizzata.

In estrema sintesi ci aspettiamo che il cittadino possa accedere in modo semplice ed immediato ai servizi di cui ha bisogno, ed a cui ha diritto, possibilmente online e senza avere mai la necessità di recarsi di persona presso un ufficio pubblico, a meno che non sia lui a richiederlo.

Per ottenere questo risultato è chiaro che eventuali inefficienze dell’amministrazione non dovranno ricadere sul cittadino che, ricordiamolo sempre, oltre ad essere il fruitore legittimo dei servizi, è anche colui che li finanzia con il suo gettito fiscale.

Un ecosistema per la PA digitale

Partendo dalla complessa situazione esistente si potrà cominciare a ragionare sulla PA di domani, facendo in modo che abbia come principi guida i valori e gli obiettivi individuati in precedenza ed all’interno di un unico ecosistema che consenta di dare uniformità e coerenza dal punto di vista metodologico, procedurale e tecnologico.

In questa fase si dovranno definire le linee guida di governo, di metodo e tecnologiche (di alto livello) per fare in modo che la trasformazione digitale, che si applicherà a tutti i sistemi che compongono la PA del futuro, possa essere attuata in modo coerente, riutilizzando metodologia e tecnologia ed avendo come riferimento best practice e standard comuni e condivisi tra tutti gli attori del cambiamento.

L’ecosistema è l’ambiente all’interno del quale dovranno essere mappate tutte le famiglie di processi e sistemi che costituiscono la PA odierna. Il censimento completo, purtroppo, sarà per lungo tempo impossibile da attuare, ecco perché sarà bene concentrarsi sulle famiglie di processi e di sistemi, sapendo che elementi appartenenti alla stessa famiglia potranno essere affrontati in modo simile o talvolta identico.

Piattaforma tecnologica unica di servizi per la PA digitale

L’ecosistema rappresenta, dal punto di vista metodologico, quello che tecnologicamente potrà essere concepito come una piattaforma tecnologica unica, dedicata alla fornitura di servizi applicativi e deputata inizialmente ad integrare tra loro le infinite applicazioni esistenti ed utilizzate nella PA a vari livelli.

Tra i vari servizi messi a disposizione da questa piattaforma unica possiamo ipotizzare, in modo certamente non esaustivo:

  • una gestione completa di autenticazione ed autorizzazione certificata, unica e centralizzata per il cittadino (quello che oggi è SPID) e per l’utente della PA;
  • il completo superamento della carta: ogni volta che c’è da stampare un documento, dovrà essere esclusivamente su richiesta del cittadino, dovrà essere completamente superata la logica di scambiarsi carta tra uffici diversi o tra sportelli diversi dello stesso ufficio, l’acquisizione di firme su cartaceo dovrà essere sostituita dalla firma digitale o dall’acquisizione di firma grafometrica, conservata ed archiviata a norma di legge;
  • l’unificazione concettuale delle banche dati della PA, che dovranno diventare “la banca dati unica della PA”, resa accessibile a tutta la PA stessa, con indubbi vantaggi a favore degli utilizzatori dei dati (i dipendenti della PA) e del fruitore finale (il cittadino);
  • una gestione completa degli Open Services che il sistema metterà a disposizione a partire dai dati di tipo pubblico. Dati non più rilasciati sotto forma di Open Data, bensì di servizi pronti per essere utilizzati all’interno di applicazioni anche di terze parti, sempre aggiornati e certificati.

In una prima fase i sistemi esistenti dovranno integrarsi con la piattaforma tecnologica unica al fine di offrire alla stessa i loro dati ed i loro servizi ed in cambio riceveranno l’accesso, mediato da opportuna profilazione, a dati e servizi provenienti dagli altri sistemi e veicolati dalla piattaforma stessa.

Più avanti i nuovi sistemi dovranno essere realizzati esclusivamente seguendo le linee guida metodologiche e tecnologiche e gli standard descritti in precedenza, in modo da garantire uniformità e coerenzadei sistemi e realizzando, al contempo, efficienza economica per la macchina dello Stato.

Il contributo fondamentale del legislatore

Uno degli aspetti determinanti per la digitalizzazione dei processi e sistemi della PA, è che questi dovranno essere ovviamente e rigorosamente aderenti alle norme esistenti, anche quando le norme siano purtroppo vecchie ed inadeguate.

Sarà determinante quindi il ruolo del legislatore, per fare in modo che le norme, a parità di efficienza legislativa, non siano di ostacolo all’introduzione di processi semplificati e tecnologie abilitanti e consentano di realizzare e di utilizzare sistemi davvero orientati al cittadino.

La creazione e la valorizzazione delle competenze

Per andare nella direzione della PA digitale è necessario aumentare gli sforzi nella creazione e valorizzazione delle competenze.

Da un lato servono competenze importanti per tutti gli aspetti metodologici e tecnologici che hanno a che fare con l’ammodernamento e la semplificazione dei processi e con il loro inserimento all’interno dell’ecosistema della PA digitale.

D’altro canto sono fondamentali gli aspetti di alfabetizzazione digitale verso la popolazione, per fare in modo che sempre più cittadini siano in grado di accedere in modo nuovo ai servizi di una PA sempre più vicina ai loro bisogni.

  • Dati non più rilasciati come open data ma come open services?
    ?
    ?

  • grazie della risposta

    non condivido l’affermazione “…Dati non più rilasciati sotto forma di Open Data…”.
    Non più rilasciati sotto forma di open data significa ignorare tutto il lavoro “culturale” fatto fino ad oggi da diverse PA, dall’AGID, e da mezzo pianeta, da una vasta comunità di soggetti nei territori, di diffusione dell’importanza della disponibilità dei dati grezzi, proprio per la possibilità di creare “servizi” nuovi.

    Una cosa è dire che le PA devono erogare web services e open data, contemporaneamente. E sono d’accordissimo.
    Altra cosa è affermare: le PA da oggi erogano sevizi attraverso l’uso dei loro dati custoditi nei db degli applicativi gestionali, ma non pubblicano open data, nè tramite API nè tramite quei vecchi CSV che si trovano in molti uffici. Su questo secondo scenario non sono d’accordo. I dati – anche grezzi – della PA sono un “Patrimonio Informativo Pubblico” come dice l’Europa (PSI, Public Sector Information) e come dice l’AGID con le linee guida nazionali in ultima versione definite dal Team Trasformazione Digitale dell’AGID.

    Servizi e dati grezzi, va bene.
    Solo servizi senza dati grezzi, spero solo sia una sua personale rispettabilissima opinione, e non una nuova corrente di pensiero. Chissà ,…. scopriamo che la Società, le Aziende con i dati grezzi della PA ci fanno servizi che nemmeno la stessa PA si sogna di erogare coi suoi stessi dati 😉

    saluti cordiali

    • Massimo Canducci

      Credo che l’obiettivo finale sia fare in modo che i dati pubblici possano essere utilizzati per fornire servizi al cittadino attraverso la collaborazione di soggetti terzi che li “consumino” attraverso applicazioni di vario tipo.
      Se l’ente rilascia il semplice CSV (quando va bene), la gestione integrale del dato, la sua memorizzazione in db applicativi ed i costi infrastrutturali saranno a totale carico dello sviluppatore esterno, con inoltre lo svantaggio di doversi occupare manualmente della sincronizzazione con eventuali versioni nuove del dataset. Questo scenario non facilita certo chi abbia voglia di utilizzare quei dati per farci qualcosa di utile.
      Se invece l’ente rilasciasse esclusivamente i servizi, cioè API e web services in grado di accedere applicativamente al dato, allora lo sviluppatore avrebbe a disposizione API e servizi già pronti e forniti dalla pubblica amministrazione, avendo la garanzia che tali dati siano sempre aggiornati e senza doversi preoccupare degli aspetti tecnologici ed architetturali per gestire in autonomia un database con dati provenienti da diversi dataset.
      Se poi si volesse rilasciare il CVS, che in alcuni remoti casi potrebbe essere utile, si potrebbe semplicemente realizzare l’API giusta che consenta di scaricare tutto il dataset o parte di esso nel formato selezionato dall’utente. Il dato grezzo sarà quindi sempre disponibile al download, non come file fisico però, ma come chiamata ad un servizio che produrrà il file fisico (sempre aggiornato) sul pc dell’utente.
      Un approccio di questo genere consentirebbe anche all’ente di controllare chi utilizza i dati e per farci cosa.
      Badi bene che queste piattaforme di disintermediazione esistono già (OpenRecordz per esempio) e sono già oggi utilizzate da sviluppatori che non vogliono più relazionarsi con i CSV dell’ente, quindi li prendono, li caricano in queste piattaforme ed utilizzano le API da esse esposte.
      Per evitare costi di gestione degli open services l’ente potrebbe tranquillamente fare un accordo con una di queste piattaforme, semplicemente, caricare su di essa tutti i suoi dataset, realizzando unicamente la procedura di aggiornamento. I servizi sono già pronti e disponibili.
      Infine è bene non confondere gli aspetti culturali con gli aspetti tecnici, i primi determinano la volontà dell’ente di rilasciare informazioni pubbliche in formato aperto, i secondi determinano la metodologia tecnica più efficiente per ottenere il risultato desiderato: offrire servizi migliori al cittadino.
      Un saluto (e grazie per il confronto 🙂 )

    • Massimo Canducci

      Credo che l’obiettivo finale sia fare in modo che i dati pubblici possano essere utilizzati per fornire servizi al cittadino attraverso la collaborazione di soggetti terzi che li “consumino” attraverso applicazioni di vario tipo.
      Se l’ente rilascia il semplice CSV (quando va bene), la gestione integrale del dato, la sua memorizzazione in db applicativi ed i costi infrastrutturali saranno a totale carico dello sviluppatore esterno, con inoltre lo svantaggio di doversi occupare manualmente della sincronizzazione con eventuali versioni nuove del dataset. Questo scenario non facilita certo chi abbia voglia di utilizzare quei dati per farci qualcosa di utile.
      Se invece l’ente rilasciasse esclusivamente i servizi, cioè API e web services in grado di accedere applicativamente al dato, allora lo sviluppatore avrebbe a disposizione API e servizi già pronti e forniti dalla pubblica amministrazione, avendo la garanzia che tali dati siano sempre aggiornati e senza doversi preoccupare degli aspetti tecnologici ed architetturali per gestire in autonomia un database con dati provenienti da diversi dataset.
      Se poi si volesse rilasciare il CVS, che in alcuni remoti casi potrebbe essere utile, si potrebbe semplicemente realizzare l’API giusta che consenta di scaricare tutto il dataset o parte di esso nel formato selezionato dall’utente. Il dato grezzo sarà quindi sempre disponibile al download, non come file fisico però, ma come chiamata ad un servizio che produrrà il file fisico (sempre aggiornato) sul pc dell’utente.
      Un approccio di questo genere consentirebbe anche all’ente di controllare chi utilizza i dati e per farci cosa.
      Badi bene che queste piattaforme di disintermediazione esistono già (OpenRecordz per esempio) e sono già oggi utilizzate da sviluppatori che non vogliono più relazionarsi con i CSV dell’ente, quindi li prendono, li caricano in queste piattaforme ed utilizzano le API da esse esposte.
      Per evitare costi di gestione degli open services l’ente potrebbe tranquillamente fare un accordo con una di queste piattaforme, semplicemente, caricare su di essa tutti i suoi dataset, realizzando unicamente la procedura di aggiornamento. I servizi sono già pronti e disponibili.
      Infine è bene non confondere gli aspetti culturali con gli aspetti tecnici, i primi determinano la volontà dell’ente di rilasciare informazioni pubbliche in formato aperto, i secondi determinano la metodologia tecnica più efficiente per ottenere il risultato desiderato: offrire servizi migliori al cittadino.
      Un saluto (e grazie per il confronto 🙂 )

    • Massimo Canducci

      Credo che l’obiettivo finale sia fare in modo che i dati pubblici possano essere utilizzati per fornire servizi al cittadino attraverso la collaborazione di soggetti terzi che li “consumino” attraverso applicazioni di vario tipo.
      Se l’ente rilascia il semplice CSV (quando va bene), la gestione integrale del dato, la sua memorizzazione in db applicativi ed i costi infrastrutturali saranno a totale carico dello sviluppatore esterno, con inoltre lo svantaggio di doversi occupare manualmente della sincronizzazione con eventuali versioni nuove del dataset. Questo scenario non facilita certo chi abbia voglia di utilizzare quei dati per farci qualcosa di utile.
      Se invece l’ente rilasciasse esclusivamente i servizi, cioè API e web services in grado di accedere applicativamente al dato, allora lo sviluppatore avrebbe a disposizione API e servizi già pronti e forniti dalla pubblica amministrazione, avendo la garanzia che tali dati siano sempre aggiornati e senza doversi preoccupare degli aspetti tecnologici ed architetturali per gestire in autonomia un database con dati provenienti da diversi dataset.
      Se poi si volesse rilasciare il CVS, che in alcuni remoti casi potrebbe essere utile, si potrebbe semplicemente realizzare l’API giusta che consenta di scaricare tutto il dataset o parte di esso nel formato selezionato dall’utente. Il dato grezzo sarà quindi sempre disponibile al download, non come file fisico però, ma come chiamata ad un servizio che produrrà il file fisico (sempre aggiornato) sul pc dell’utente.
      Un approccio di questo genere consentirebbe anche all’ente di controllare chi utilizza i dati e per farci cosa.
      Badi bene che queste piattaforme di disintermediazione esistono già (OpenRecordz per esempio) e sono già oggi utilizzate da sviluppatori che non vogliono più relazionarsi con i CSV dell’ente, quindi li prendono, li caricano in queste piattaforme ed utilizzano le API da esse esposte.
      Per evitare costi di gestione degli open services l’ente potrebbe tranquillamente fare un accordo con una di queste piattaforme, semplicemente, caricare su di essa tutti i suoi dataset, realizzando unicamente la procedura di aggiornamento. I servizi sono già pronti e disponibili.
      Infine è bene non confondere gli aspetti culturali con gli aspetti tecnici, i primi determinano la volontà dell’ente di rilasciare informazioni pubbliche in formato aperto, i secondi determinano la metodologia tecnica più efficiente per ottenere il risultato desiderato: offrire servizi migliori al cittadino.
      Un saluto (e grazie per il confronto 🙂 )

  • Francesco Frangioja

    Sono assolutamente d’accordo con Massimo Canducci. Avere a disposizione API e Web Services anzichè solo i dati grezzi permetterebbe a chi sviluppa di concentrarsi solo sul “cosa” si sviluppa e non dei dati in sè. Avere solo il dato grezza significa doverlo “stoccare” in un DB e preoccuparsi di tenerlo aggiornato, complicando quindi “inutilmente” la propria applicazione. “Chiedere” un dato vis API o WS significa/significherebbe poter “dare per scontato” il fatto che quello stesso dato sia aggiornato alla data della richiesta, senza doverlo stoccare e confrontare in un DB prima di usarlo. Ovviamente ci sono moltissime applicazioni per le quali un dato grezzo (e statico) vanno più che bene, ma ce ne sono altrettante che con API e WS a disposizione sarebbero/saranno/potrebbero essere molto più performanti.

  • avere – per la società, le aziende – il dato della PA via Application Programming Interface è la situazione ideale. Su questo non ci piove.
    Purtroppo la maggior parte dei dati che escono dalla PA nei portali open data non derivano da API agganciate agli applicativi gestionali usati in tantissime PA, sia per la vetusta cultura di non dare il dato all’esterno, sia per il fatto che molti gestionali sono obsoleti e nessuno mette mano a modificarli per permettere di pubblicare dati via API.

    Ad oggi, quindi, i CSV rappresentano una forma ampiamente diffusa di pubblicazione dei dati della PA, perchè molti uffici o hanno l’applicativo che l’unico export che gli consente di default è proprio il CSV, oppure non hanno applicativi d hoc e gestiscono grosse moli di dati con Excel, io ci vivo dentro una grande PA territoriale e lo so bene.

    Molte PA devono transitare:
    – dall’excel al nuovo applicativo gestionale che è stato progettato con API di serie;
    – dal vecchio applicativo gestionale senza API (solo con export CSV) al nuovo applicativo gestionale che è stato progettato con API di serie.

    • Massimo Canducci

      Certo lo so bee, è per questo che sconsiglio di realizzare infrastrutture ad hoc e di appoggiarsi a soluzioni già esistenti.
      Nel momento in cui le piattaforme obsolete verranno aggiornate si potrà pensare anche alle modalità di erogazione di API e servizi.

      • @massimocanducci
        certo, le soluzioni esistenti (con API di serie) possono essere quelle delle PA più virtuose che le danno in riuso gratuito alle altre PA bisognose ai sensi dell’art. 68 del CAD.
        Quindi stimoliamo il popolamento (AGID deve stare sul pezzo) di un catalogo del riuso applicativo nella PA
        🙂

  • elena

    Mi pare che manchi un tassello importantissimo: si parla sempre molto delle inefficienze e delle colpe della PA, che sono certamente molte e non le voglio minimizzare. Ma delle colpe delle software house, vogliamo parlare?
    Se i sw sono obsoleti spesso è anche colpa loro, che davanti a una PA priva di competenze creano piattaforme destinate ad essere obsolete dopo un anno per lucrare sugli aggiornamenti, invece di accompagnare la PA a una soluzione veramente allo stato dell’arte; che non fanno un testing serio delle loro soluzioni; che fanno del vendor lock-in la loro ragione di vita; che quando finalmente la PA aggiudica una piattaforma importante a un loro concorrente, mettono in mezzo avvocati e tecnici per rendere il più possibile doloroso e costoso migrare i dati (ho sentito di ditte che han lottato con ogni mezzo per impedire a una PA di estrarre dal programma l’xml del protocollo perchè il vecchissimo contratto di licenza prevedeva l’esportazione solo in pdf); che anche quando la loro soluzione è eccellente rendono complicato (e comunque mai a costo zero!!) l’interfacciamento con la soluzione di un’altra sw house anche solo dedicata a un altro settore; che hanno boicottato la direttiva Stanca e il riuso con ogni mezzo; che invocano il diritto d’autore sul sw anche quando non dovrebbero, e così via.
    La PA certamente spende male le sue risorse, ma le sw house hanno molte colpe se la situazione in cui ci troviamo è quella sotto gli occhi di tutti. Sarà un paragone scemo, ma è come essere un giovanotto grosso e svelto alle prese con una vecchietta che lascia il portafoglio gonfio di soldi e aperto, e alleggerirglielo dicendo “oh, se non lo chiude e non sa fare i conti non è mica colpa mia!”. O essere un venditore di cucine che al momento del montaggio ti chiede soldi in più per ogni vite che fissa perchè nel contratto non era scritto esattamente che dovevano essere fissate.
    Un esame di coscienza e un cambio di rotta non sarebbe male. Certo se la PA comincia a mettere LEI i paletti (con API ecc.) invece di farli mettere dai fornitori, è il primo passo nella giusta direzione.

    • Federico

      Sempre su questo tema, che condivido, evidenzio la mancata applicazione, se non per ev. uso interno delle SH stesse (o “system integrator”, se prefericono un titolo più nobile), delle metodiche di program/project management.

      Quanto indicato dall’autore è in effetti un meta-programma di progetti: ma se la PA e/o gli stessi fornitori coinvolti non esplicitano publicamente con quali tempi/costi/qualità si dovranno raggiungere i risultati attesi, è “navigare a vista”!

      Inoltre, sarebbbe fondamentale venisse reso noto con quali metriche si vogliono misurare i benefici attesi/realizzati per i cittadini, principali stakeholder degli investimenti pubblici…

Articoli correlati