Governo digitale e trasformazione digitale

Perché è importante per il valore pubblico

Ogni ente pubblico gestisce oggi almeno un servizio digitale, e la maggior parte dei leader sa indicare un business case che prometteva costi più bassi, elaborazione più rapida e cittadini più soddisfatti. Troppi di quei casi hanno realizzato solo il primo dei tre. Un processo digitalizzato che instrada ancora un caso atipico attraverso cinque uffici non è trasformato; è lo stesso processo frammentato con un front end più veloce, e il cittadino sperimenta comunque la frammentazione, solo ora dietro un modulo che sembrava semplice.

La pressione a digitalizzare si è solo intensificata: i bilanci sono più stretti, meno personale elabora moduli cartacei e i cittadini che usano le banche e fanno acquisti online si aspettano ragionevolmente un'esperienza comparabile da un rinnovo di licenza o da una richiesta di prestazione. Allo stesso tempo, una reale minoranza di cittadini non può, o non vuole, effettuare transazioni online, e una strategia digital-first condotta con noncuranza converte una fila a uno sportello in una barriera permanente proprio per le persone che un servizio pubblico esiste per raggiungere.

Qui il governo digitale si interseca direttamente con la teoria del valore pubblico. Un programma di trasformazione digitale può rafforzare la capacità operativa di un servizio – il terzo vertice del triangolo strategico di Mark Moore (vedi Argomento 1.2 — Il triangolo strategico: legittimità, valore e capacità) – erodendo silenziosamente legittimità e sostegno, se i cittadini meno in grado di difendere sé stessi vengono lasciati indietro dalla riprogettazione. Il compito del leader non è scegliere fra efficienza digitale e inclusione; è progettare un servizio in cui entrambe siano vere insieme e sapere, con evidenze anziché con presupposti, se ciò stia effettivamente avvenendo.

L'Argomento 3.1 ha collocato la governance dell'era digitale in una più ampia tipologia di paradigmi amministrativi – gerarchia, mercato, rete e piattaforma – e ha sostenuto che la sua mossa definitoria è riintegrare ciò che le precedenti ondate di riforma avevano frammentato (vedi Argomento 3.1 — Sistemi e modelli di pubblica amministrazione). Questo argomento porta quel paradigma nella pratica: come un servizio sia progettato attorno al bisogno di un cittadino, a che cosa una strategia di erogazione digital-first impegni un'organizzazione e come l'infrastruttura condivisa permetta a molti servizi di smettere di reinventare ciascuno gli stessi componenti.

Concetti chiave

Il governo digitale, talvolta chiamato e-government, è l'uso della tecnologia dell'informazione per erogare servizi pubblici e per condurre transazioni fra governo, cittadini, imprese e i dipendenti stessi del governo che un tempo richiedevano un modulo cartaceo, una visita allo sportello o una telefonata. Il termine spazia da un sito informativo statico a un servizio pienamente transazionale completato dall'inizio alla fine online; questo argomento si occupa dell'estremo transazionale di quello spettro e del cambiamento organizzativo che i buoni servizi transazionali richiedono.

La progettazione dei servizi (service design) è la disciplina di progettare l'insieme di un servizio – l'interfaccia digitale, il processo di retrovia a supporto, il personale che gestisce le eccezioni e i canali fisici o telefonici accanto a quello digitale – come un'unica esperienza coerente anziché come progetti separati che non entrano in conflitto troppo gravemente. La progettazione dei servizi prende in prestito uno strumento centrale dalla gestione delle operazioni, il service blueprint, che mappa ogni passo che un cittadino compie rispetto a ogni passo che un'organizzazione compie dietro le quinte a supporto, rendendo visibili i passaggi di consegne dove avviene la maggior parte dei fallimenti digitali.

La progettazione centrata sull'utente (user-centered design) è la disciplina più ristretta, annidata dentro la progettazione dei servizi, di progettare una specifica interazione – un modulo, una pagina, una domanda – attorno ai bisogni, alle capacità e ai modelli mentali delle persone che la useranno, stabiliti attraverso ricerca diretta con loro anziché presunti dall'interno dell'organizzazione. La progettazione centrata sull'utente insiste che le persone che costruiscono un servizio sono strutturalmente le peggio collocate per giudicare se sia utilizzabile, perché sanno già che cosa faccia ogni pulsante; solo verificare con persone che non lo sanno già colma quel divario.

Il digital-first, talvolta formalizzato come digital-by-default, è una strategia di erogazione per cui il canale digitale è costruito per essere il migliore, e di solito l'unico attivamente promosso, per completare una transazione, con altri canali conservati per le persone che non possono usarlo. La strategia è un genuino compromesso, non un guadagno di efficienza gratuito: concentra l'investimento in un canale, il che può produrre un servizio nettamente migliore per la maggioranza, ma crea valore pubblico solo se l'organizzazione è altrettanto deliberata su chi il canale digitale non raggiunge.

L'esclusione digitale è la condizione di non poter completare una transazione attraverso un canale digitale, per ragioni di accesso, competenza, fiducia in sé, disabilità, lingua o circostanze, anche dove ne è offerto uno – un'istanza a livello di servizio del più ampio divario digitale, lo schema più generale di accesso ineguale alla tecnologia digitale per reddito, istruzione, geografia ed età. Il digitale assistito è la fornitura deliberata di aiuto umano – per telefono, di persona o tramite un intermediario fidato – per le persone che sperimentano l'esclusione digitale, progettata come parte di prima classe del servizio anziché come ripiego residuo per cui nessuno pianifica capacità.

Il governo come piattaforma è lo schema, nominato e sostenuto dal commentatore tecnologico Tim O'Reilly nel 2010, di costruire una volta, a un livello elevato, un piccolo numero di pezzi condivisi e riutilizzabili di infrastruttura – comunemente verifica dell'identità, pagamenti, notifiche e scambio di documenti – così che molti singoli servizi possano essere costruiti sopra di essi anziché ciascuno ricostruirne la propria versione. Lo strato di scambio dati X-Road dell'Estonia, costruito dal 2001 e da allora adottato o adattato da diversi altri paesi, è un'istanza reale molto citata dello schema a scala nazionale. Gli standard di condivisione dei dati e di interoperabilità che permettono ai componenti condivisi di scambiare informazioni in sicurezza attraverso i confini organizzativi sono un tema sostanziale a sé (vedi Argomento 5.4 — Dati, interoperabilità e dati aperti nel settore pubblico); questo argomento tratta il governo come piattaforma come schema di progettazione dei servizi e di governance, mentre le scelte ingegneristiche su come tali componenti siano costruiti, acquistati o modernizzati appartengono al lato dell'erogazione del software della materia (vedi Argomento 5.3 — Ingegneria del software e piattaforme nel settore pubblico).

L'identità digitale è un componente di piattaforma condivisa fondamentale: un modo verificato e riutilizzabile di stabilire che un utente online è chi dichiara di essere, costruito una volta così che un servizio fiscale, uno di prestazioni e uno di licenze non risolvano ciascuno indipendentemente la verifica dell'identità. Gli schemi di identità digitale vanno da numeri di identità nazionali centralizzati a sistemi federati in cui diversi verificatori indipendenti garantiscono ciascuno per un utente, e la scelta fra essi comporta conseguenze per privacy, resilienza e fiducia che una valutazione puramente tecnica mancherà.

Gli standard di servizio digitale sono insiemi codificati di principi, di solito abbinati a un varco di valutazione indipendente prima che un servizio possa essere lanciato o esteso, che un numero crescente di governi usa per tenere i gruppi di erogazione a un livello comune: partire dai bisogni degli utenti, verificare con utenti reali, costruire in modo iterativo e rendere il servizio accessibile alle persone con disabilità. Sono un meccanismo di governance tanto quanto di progettazione, perché danno a una funzione digitale centrale l'autorità di fermare il lancio di un servizio che non ha raggiunto il livello – di solito l'unica leva che rende uno standard più che aspirazionale. Il Government Digital Service (GDS) del Regno Unito, istituito nel 2011, è un originale molto studiato di un'unità centrale che tiene i ministeri a questo esatto tipo di standard pubblicato.

Buone pratiche

1. Partite ogni riprogettazione di servizio dal bisogno del cittadino, espresso con le sue parole, non dalla mappa interna dei processi dell'agenzia. Intervistate o osservate persone che cercano davvero di completare la transazione prima di disegnare un solo wireframe; il divario fra come il personale descrive un processo e come un cittadino lo sperimenta è di solito dove sta l'opportunità di riprogettazione.
2. Fate prototipi e verificate con utenti reali prima di impegnarvi nella costruzione di produzione. Un prototipo cartaceo verificato con dieci persone della popolazione effettiva di utenti trova più problemi di usabilità, più in fretta e a minor costo, di un sistema finito verificato con nessuno fino al lancio.
3. Adottate uno standard di servizio digitale con un genuino varco di valutazione, non una lista di controllo che nessuno fa rispettare. Uno standard cambia il comportamento solo se a un servizio può essere detto di no prima del lancio; pubblicate i criteri e date all'organo valutatore l'autorità di applicarli.
4. Progettate il canale di digitale assistito come parte del servizio fin dal primo giorno, dotato di risorse e misurato come il canale digitale. Trattate la linea telefonica, l'operatore di prossimità o il terminale di biblioteca sostenuto da personale formato come un canale progettato con propri livelli di servizio, non come una valvola di emergenza improvvisata dopo l'arrivo dei reclami.
5. Misurate direttamente l'esclusione digitale per ciascun servizio, anziché presumere che si applichino le medie nazionali. La popolazione che non può completare una richiesta di prestazione online non è la stessa popolazione che non può rinnovare online una licenza commerciale; misurate gli utenti e i non utenti effettivi di ciascun servizio e aggiornate la stima man mano che il servizio e la sua popolazione cambiano.
6. Costruite una volta i componenti di piattaforma condivisa e richiedete, non solo consentite, ai servizi di riutilizzarli. Un componente condiviso di identità o di pagamenti che i gruppi sono liberi di ignorare sarà ignorato dal gruppo sotto maggiore pressione di consegna, il che vanifica lo scopo; il riutilizzo deve essere il percorso predefinito, con un processo documentato di eccezione per il raro caso in cui davvero non si adatta.
7. Date a ogni componente di piattaforma condivisa un responsabile di prodotto nominato e responsabile, con una roadmap pubblica. Un servizio condiviso senza un responsabile visibile accumula difetti non affrontati e interruzioni inspiegate che i singoli gruppi consumatori non hanno potere di correggere, il che erode la fiducia nel riutilizzo più in fretta di quasi qualsiasi altra cosa.
8. Usate gruppi di erogazione piccoli, autorizzati e interfunzionali anziché grandi programmi sequenziali per i servizi rivolti ai cittadini. Un gruppo che comprende ricerca sugli utenti, progettazione, ingegneria e competenza di politica insieme, che lavora in brevi cicli iterativi associati allo sviluppo agile del software, può correggere la rotta sulla base di evidenze dal vivo in un modo in cui un programma strutturato attorno a una specifica fissa e a una singola data di messa in produzione non può.
9. Pubblicate apertamente i dati di performance dei servizi in produzione, compresi i numeri scomodi. Metriche trasparenti su tassi di completamento, tempi di attesa e domanda di digitale assistito creano una pressione esterna a continuare a migliorare un servizio dopo il lancio, quando l'attenzione interna si è tipicamente già spostata alla priorità successiva.
10. Incorporate l'accessibilità fin dal primo prototipo, rispetto a uno standard riconosciuto, anziché adattarla all'ultimo prima del lancio. L'accessibilità adattata a posteriori è costosa, incompleta e di solito scoperta solo quando un cittadino con disabilità non può affatto completare una transazione richiesta dalla legge.
11. Mantenete aperto il canale non digitale finché le evidenze del digitale assistito, non una scadenza su un piano, mostrano che sia sicuro ritirarlo. Chiudere un canale cartaceo o di sportello a una data fissa, a prescindere da quante persone ne dipendano ancora, converte un traguardo di consegna in un evento di esclusione.
12. Trattate un servizio minimo vitale, non un prodotto minimo vitale, come unità di rilascio. Un servizio è vitale per il rilascio solo quando il suo percorso di digitale assistito, la gestione delle eccezioni e le tutele dei dati sono pronti insieme al front end digitale, non semplicemente quando le schermate del percorso felice funzionano.

Domande da discutere con il vostro team

Sappiamo, con evidenza diretta anziché presupposti, chi non può usare il nostro servizio digitale a più alto volume e che cosa gli accada oggi? La maggior parte delle organizzazioni sa descrivere nel dettaglio la performance del proprio canale digitale e i propri utenti non digitali solo in termini generali, se mai. Usate questa domanda per scoprire se qualcuno abbia effettivamente misurato chi sia escluso da uno specifico servizio, anziché citare una statistica nazionale sul divario digitale che può non descrivere affatto la popolazione di questo servizio. Discutete quale canale usino attualmente quei cittadini esclusi, se sia adeguatamente dotato di risorse e chi sia responsabile di assicurare che resti tale. Trattate una risposta sicura senza evidenza dietro come un segnale d'allarme, non come una rassicurazione.

Quali parti del nostro patrimonio tecnologico stiamo costruendo oggi separatamente che potrebbero invece essere costruite una volta come componente di piattaforma condivisa? Verifica dell'identità, pagamenti, notifiche e caricamento dei documenti sono comunemente ricostruiti dentro singoli servizi anche dove una versione condivisa esiste già altrove nella stessa organizzazione o settore. Usate questa domanda per inventariare dove avvenga la duplicazione e per essere onesti sul perché: genuino bisogno tecnico, accidente storico o ragionevole sfiducia di un gruppo che un servizio condiviso sia abbastanza affidabile da dipenderne. Discutete che cosa servirebbe, tecnicamente e organizzativamente, per consolidare prima la duplicazione più evidente. È una questione di governance tanto quanto di ingegneria.

Abbiamo verificato questo servizio con utenti significativamente diversi dalle persone che lo hanno costruito? Un gruppo giovane, a proprio agio con la tecnologia e fluente nel gergo dell'organizzazione mancherà sistematicamente problemi in cui un utente più anziano, meno sicuro di sé o non madrelingua si imbatte subito. Usate questa domanda per controllare chi fosse effettivamente nella stanza durante la ricerca sugli utenti, non solo quante sessioni siano state svolte. Discutete se la ricerca abbia incluso persone con disabilità, persone con bassa fiducia digitale e persone che non parlano come prima lingua la lingua principale del servizio. Se la risposta onesta è che la verifica è stata comoda anziché rappresentativa, trattate le affermazioni di usabilità del servizio come non provate.

Se riprogettassimo oggi questo servizio interamente attorno al bisogno del cittadino, che cosa smetteremmo di chiedergli di fare? La maggior parte dei servizi digitali ereditati chiede ancora a un cittadino di sapere a quale ufficio rivolgersi, quale numero di riferimento citare o quale modulo corrisponda alla sua situazione – conoscenza organizzativa che un servizio ben progettato porterebbe invece a carico del cittadino. Usate questa domanda per ripercorrere i passi attuali del vostro servizio e chiedervi, per ciascuno, se esista per servire il bisogno del cittadino o la struttura interna dell'organizzazione. Discutete che cosa dovrebbe cambiare nella retrovia, non solo nel front end, per rimuovere ogni passo che non supera quella verifica.

Chi possiede affidabilità, sicurezza e roadmap di ciascun componente di piattaforma condivisa da cui dipendono i nostri servizi, e ogni gruppo dipendente riconoscerebbe quel nome? L'infrastruttura condivisa senza un responsabile chiaramente nominato tende a essere mantenuta in modo reattivo, da chiunque sia meno occupato quando si rompe, il che è un cattivo fondamento per servizi che la trattano sempre più come critica. Usate questa domanda per verificare se i gruppi dipendenti sappiano effettivamente nominare chi possiede oggi il loro componente di identità, pagamenti o notifiche. Discutete che cosa accada, operativamente e in termini di responsabilità pubblica, se quel componente fallisce durante un periodo di punta come una scadenza di dichiarazione o una data di pagamento delle prestazioni.

Quando descriviamo un servizio come digitale per impostazione predefinita, intendiamo che è il canale migliore o l'unico che stiamo effettivamente dotando di risorse? Suonano identici in un documento di strategia e sono completamente diversi in pratica: il primo è una legittima scelta di progettazione del servizio abbinata a un'alternativa dotata di risorse, il secondo è una decisione di taglio dei costi con una giustificazione di progettazione del servizio. Usate questa domanda per esaminare l'ultima grande decisione di spostamento di canale che la vostra organizzazione ha preso e chiedervi onestamente quale dei due fosse davvero. Discutete quale evidenza distinguerebbe i due e se quell'evidenza sia stata raccolta prima o solo dopo la decisione.

In pratica: un esempio di valore pubblico

Un'autorità regionale dei trasporti – immaginaria, illustrativa di uno schema anziché un resoconto su un ente reale – gestiva uno schema di tessere di viaggio agevolate per residenti anziani e disabili, amministrato tramite un modulo cartaceo di domanda che doveva essere spedito per posta con i documenti di supporto ed elaborato a mano. L'elaborazione richiedeva, in media, sei settimane, i richiedenti spedivano spesso i documenti di supporto sbagliati perché le istruzioni del modulo erano scritte in un linguaggio amministrativo che nessuno fuori dall'autorità usava davvero, e un arretrato crescente generava un flusso costante di reclami ai membri eletti del consiglio.

La nuova responsabile digitale dell'autorità resistette al primo istinto ovvio, che era commissionare una versione online del modulo esistente. Il gruppo trascorse invece tre settimane a osservare i richiedenti completare il processo cartaceo, a casa e nei centri comunitari, prima di scrivere una riga di specifica digitale. Trovò che il problema maggiore del modulo cartaceo non era che fosse cartaceo; era che il modulo presupponeva conoscenze che il richiedente non aveva, elencava i documenti di supporto in una sequenza che non corrispondeva a come le persone naturalmente li raccoglievano e non dava alcun modo di controllare lo stato della domanda se non con una telefonata a un call center sovraccarico.

Il servizio riprogettato spostò la maggior parte dei richiedenti su un modulo online che chiedeva le informazioni nell'ordine in cui le persone naturalmente le avevano a portata di mano, spiegava in linguaggio semplice perché ciascun documento fosse necessario e permetteva a un richiedente di controllare lo stato in qualsiasi momento – ma il gruppo trattò il canale di digitale assistito come un problema di progettazione altrettanto serio, non un ripensamento. Si associò alla rete di centri comunitari della regione, diversi dei quali erano organizzazioni del terzo settore già fidate dai residenti anziani, formando il personale lì ad aiutare i residenti a compilare lo stesso modulo digitale su un terminale condiviso anziché tornare alla carta, e mantenne aperto un genuino canale cartaceo, dotato di risorse a un livello fissato dalla domanda misurata anziché dal presupposto che la domanda sarebbe semplicemente scomparsa.

Per la verifica dell'identità, l'autorità riutilizzò un componente di identità digitale che il governo nazionale aveva già costruito per i servizi fiscali e di prestazioni, anziché costruirne uno proprio – una scelta esplicita di governo come piattaforma che fece risparmiare mesi di sviluppo e diede ai richiedenti un'esperienza di verifica che alcuni di loro avevano già usato altrove. Diciotto mesi dopo il lancio, il tempo di elaborazione delle domande online era sceso da sei settimane a quattro giorni; le domande di digitale assistito e cartacee, ora una minoranza del totale ma ancora diverse migliaia all'anno, erano seguite con lo stesso obiettivo di livello di servizio del canale digitale, e l'autorità poteva riferire, con dati reali misurati anziché una stima, esattamente quanti residenti dipendessero ancora da ciascun canale e perché.

Quattro prospettive settoriali

Amministrazione locale

Gli enti locali erogano i servizi a più alto volume e più faccia a faccia dell'amministrazione – prestazioni, abitazione, rifiuti, biblioteche, assistenza sociale – il che li rende il livello in cui l'esclusione digitale è più visibile e più costosa da sbagliare, perché la popolazione con più probabilità di aver bisogno di persona di un servizio locale è spesso quella con meno probabilità di sentirsi a proprio agio online. Il vantaggio dell'amministrazione locale è la prossimità: centri comunitari, biblioteche e organizzazioni locali di volontariato esistono già come rete fidata di digitale assistito, se l'ente progetta servizi che lavorino con loro anziché attorno a loro. Il suo svantaggio è la scala: un singolo ente ha raramente il bilancio o la capacità ingegneristica per costruire da solo componenti di piattaforma condivisa, per cui la sua capacità di riutilizzare un servizio regionale o nazionale di identità, pagamenti o notifiche, anziché costruire un equivalente locale più debole, determina in gran parte ciò che può erogare.

Amministrazione nazionale

Le amministrazioni nazionali sono di solito l'unico livello di governo con la scala per giustificare la costruzione di un'infrastruttura di piattaforma genuinamente condivisa – identità, pagamenti, notifiche – e l'autorità, in linea di principio, di imporne il riutilizzo fra i ministeri. In pratica, quell'autorità è spesso contestata: il mandato di un'unità digitale centrale di richiedere il riutilizzo si scontra regolarmente con l'autorità di bilancio di un ministero, la sua scadenza di consegna e il ragionevole scetticismo sul dipendere da un'infrastruttura che non controlla, facendo eco alla più ampia tensione tra gerarchia e coordinamento di piattaforma nella tipologia dei paradigmi (vedi Argomento 3.1 — Sistemi e modelli di pubblica amministrazione). I paesi che sostengono una funzione digitale centrale con reale autorità su standard e riutilizzo di piattaforme – uno schema che il Digital Government Index dell'OCSE segue fra paesi membri e partner – tendono a mostrare meno sistemi duplicati e una qualità di servizio più coerente fra i ministeri, anche se l'indice mostra anche che questa autorità è costruita in modo disomogeneo anche fra governi ben dotati di risorse.

Terzo settore e non profit

Le organizzazioni non profit e comunitarie occupano due ruoli distinti nel governo digitale, e confonderli causa danno reale: sono spesso il canale di digitale assistito di ultima istanza per i cittadini esclusi da un servizio governativo, assorbendo un costo e un dovere di cura che non sono mai stati formalmente commissionati né finanziati, e ci si aspetta sempre più che costruiscano propri servizi digitali a uno standard plasmato dalle stesse aspettative degli utenti, con una frazione del bilancio di ingegneria di un ministero. Un'organizzazione del terzo settore su cui un'agenzia governativa è silenziosamente arrivata a fare affidamento per il supporto di digitale assistito merita un rapporto esplicito, e idealmente finanziato, anziché il presupposto che buona volontà e allineamento di missione assorbano la domanda indefinitamente.

Livello multilaterale e internazionale

Gli organismi multilaterali di sviluppo trattano il governo digitale in misura sostanziale come una questione di sviluppo e di gestione delle finanze pubbliche: il programma GovTech della Banca Mondiale, per esempio, inquadra la riforma dell'amministrazione pubblica abilitata dalla tecnologia come centrale per l'efficacia del governo nei paesi a reddito basso e medio, non come un lusso riservato a quelli più ricchi. L'identità digitale è spesso la punta di lancia di questo lavoro, perché una piattaforma di identità affidabile e inclusiva è una precondizione per erogare quasi qualsiasi altro servizio digitale su larga scala, e le sue scelte di progetto – centralizzata o federata, biometrica o basata su credenziali – comportano conseguenze per l'inclusione finanziaria e le libertà civili che i partner di sviluppo pesano accanto alla pura efficienza di erogazione. Il sistema di identità biometrica Aadhaar dell'India, il maggiore schema del suo genere, illustra sia la portata che una tale piattaforma può raggiungere sia i contestati compromessi di privacy ed esclusione che solleva a scala nazionale. L'interoperabilità transfrontaliera resta il problema più difficile irrisolto a questa scala: l'identità digitale di un cittadino, una volta verificata, raramente si trasferisce in modo pulito attraverso un confine nazionale, il che limita quanto lo schema di piattaforma possa attualmente estendersi oltre una singola giurisdizione.

Modalità di fallimento comuni

Erogazione solo digitale che esclude in silenzio. Un'organizzazione riprogetta un servizio come digital-first, ne misura il successo in base al volume di spostamento di canale e scopre solo dopo il lancio quanti cittadini non potessero affatto completare la transazione. Il lancio di Healthcare.gov del 2013 negli Stati Uniti è un caso pubblico ben documentato di questo schema: un processo obbligatorio di iscrizione online fallì sotto carico e sotto reale verifica di usabilità nel momento in cui i cittadini ne avevano più bisogno, e la correzione richiese una mobilitazione di emergenza di talenti tecnici esterni. Il costo non sono solo i cittadini direttamente esclusi; è l'erosione di legittimità che segue quando un programma digitale di punta delude visibilmente le persone che doveva servire.

La piattaforma che nessuno è tenuto a usare. Una funzione centrale costruisce un componente condiviso genuinamente buono di identità, pagamenti o notifiche, ma l'adozione resta facoltativa, così i gruppi sotto maggiore pressione di consegna costruiscono un proprio equivalente più debole anziché integrarsi con un'infrastruttura che non controllano e non possono influenzare. Il costo si compone negli anni nel panorama duplicato e incoerente che la piattaforma era stata costruita per prevenire, mentre il componente condiviso stesso muore di fame di utilizzo e di investimento che ne avrebbero giustificato il bilancio.

Progettazione del servizio che si ferma all'interfaccia. Un gruppo applica una genuina competenza di progettazione centrata sull'utente alle schermate di un modulo lasciando completamente invariato il processo frammentato di retrovia dietro di esso, producendo un'esperienza rivolta al cittadino che appare coerente fino al punto in cui un caso lascia il percorso felice – lo stesso schema di facciata digitale descritto più in generale nella tipologia dei paradigmi (vedi Argomento 3.1 — Sistemi e modelli di pubblica amministrazione). Il costo è un servizio che si comporta bene in una dimostrazione e fallisce proprio dove i cittadini con i bisogni più complessi, e spesso più urgenti, lo incontrano davvero.

Il digitale assistito trattato come arrotondamento. Un business case digital-first modella nel dettaglio il costo del canale digitale e assegna una voce di bilancio simbolica e sottodotata agli "altri canali", presumendo che la domanda di digitale assistito sarà piccola e temporanea. Il costo emerge come code ai call center, organizzazioni comunitarie che assorbono domanda non finanziata e una persistente popolazione esclusa che i dati stessi dell'organizzazione non erano mai stati progettati per vedere abbastanza chiaramente da correggere.

Accessibilità adattata alla fine. L'accessibilità è trattata come un controllo di conformità eseguito poco prima del lancio anziché come un vincolo di progetto presente dal primo prototipo, per cui i problemi sono trovati tardi, sono costosi da correggere e talvolta non sono corretti affatto prima del lancio. Il costo ricade in modo sproporzionato sui cittadini con disabilità che tentano una transazione richiesta dalla legge e finisce spesso in una costosa riprogettazione, in un reclamo regolatorio o in entrambi.

Modello di maturità

Lista di controllo

• Osservate o intervistate utenti reali che completano il processo attuale prima di specificare una riprogettazione.
• Fate prototipi e verificate con utenti rappresentativi dell'intera popolazione, comprese persone con bassa fiducia digitale e con disabilità.
• Adottate uno standard di servizio digitale con un varco di valutazione indipendente prima del lancio.
• Progettate e dotate di risorse il canale di digitale assistito accanto al canale digitale, non dopo di esso.
• Misurate l'esclusione digitale per questo specifico servizio, non solo rispetto a una stima nazionale generale.
• Individuate quali componenti di piattaforma (identità, pagamenti, notifiche, scambio di documenti) esistano già per il riutilizzo prima di costruirne di nuovi.
• Nominate un responsabile e pubblicate una roadmap per ogni componente di piattaforma condivisa da cui il servizio dipende.
• Costruite e verificate l'accessibilità dal primo prototipo rispetto a uno standard riconosciuto.
• Pubblicate i dati di performance dei servizi in produzione, compresi i tassi di completamento e la domanda di digitale assistito.
• Fissate il ritiro di un canale non digitale sulla base di evidenze di livelli di domanda sicuri, non di una data di calendario fissa.
• Confermate che il processo di retrovia sia stato riprogettato, non solo l'interfaccia rivolta al cittadino.
• Verificate chi, dentro e fuori l'organizzazione, stia attualmente assorbendo domanda non finanziata di digitale assistito.

Fonti chiave

• Tim O'Reilly, "Government as a Platform", Innovations: Technology, Governance, Globalization (MIT Press, 2011) — l'argomento originario per un'infrastruttura di governo condivisa e riutilizzabile.
• Patrick Dunleavy, Helen Margetts, Simon Bastow e Jane Tinkler sulla governance dell'era digitale (vedi Argomento 3.1 — Sistemi e modelli di pubblica amministrazione per la citazione completa) — il paradigma entro cui sta la pratica di questo argomento.
• OCSE, 2023 Digital Government Index — benchmarking comparativo dei fondamenti del governo digitale fra paesi membri, in adesione e partner.
• Banca Mondiale, GovTech Global Partnership — riforma del settore pubblico abilitata dalla tecnologia a vari livelli di reddito.
• UK Government Digital Service, Government Design Principles — un esempio pubblicato dei principi di progettazione di uno standard nazionale di servizio digitale.
• Ricerca del Nielsen Norman Group sul service blueprinting e sul lancio di Healthcare.gov del 2013 — metodologia applicata di progettazione dei servizi e di usabilità e un caso di fallimento documentato.

Riferimenti

1. E-government — Wikipedia — https://en.wikipedia.org/wiki/E-government
2. Service design — Wikipedia — https://en.wikipedia.org/wiki/Service_design
3. User-centered design — Wikipedia — https://en.wikipedia.org/wiki/User-centered_design
4. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
5. Digital identity — Wikipedia — https://en.wikipedia.org/wiki/Digital_identity
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. X-Road — Wikipedia — https://en.wikipedia.org/wiki/X-Road
8. Aadhaar — Wikipedia — https://en.wikipedia.org/wiki/Aadhaar
9. Digital era governance — Wikipedia — https://en.wikipedia.org/wiki/Digital_era_governance
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Tim O'Reilly, "Government as a Platform" — Innovations: Technology, Governance, Globalization / MIT Press — https://direct.mit.edu/itgg/article/6/1/13/9649/Government-as-a-Platform
12. 2023 OECD Digital Government Index — OECD — https://www.oecd.org/en/publications/2023-oecd-digital-government-index_1a89ed5e-en.html
13. GovTech: Putting People First — World Bank — https://www.worldbank.org/en/programs/govtech
14. Government Design Principles — GOV.UK / UK Government Digital Service — https://www.gov.uk/guidance/government-design-principles
15. Service Blueprinting in Practice: Who, When, What — Nielsen Norman Group — https://www.nngroup.com/articles/service-blueprinting-practice/
16. HealthCare.gov's Account Setup: 10 Broken Usability Guidelines — Nielsen Norman Group — https://www.nngroup.com/articles/affordable_care_act_usability_issues/