Mobile government: quello vero deve ancora arrivare

Home Open Government Comunicazione Pubblica Mobile government: quello vero deve ancora arrivare

Ricapitolando: abbiamo la crisi, il patto di stabilità, il blocco delle assunzioni, non possiamo dare alcun incentivo ai nostri collaboratori, e i fornitori sono sempre più in difficoltà; che altro dobbiamo affrontare nell’IT della PA? Esiste almeno qualche novità minimamente divertente – oltre agli Open Data, ovviamente – che ci aspetta? Beh, in effetti qualcosa che ancora ci aspetta dietro l’angolo ci sarebbe, ed è il mobile government. Quello vero.

4 Febbraio 2013

G

Gianluca Vannuccini*

Ricapitolando: abbiamo la crisi, il patto di stabilità, il blocco delle assunzioni, non possiamo dare alcun incentivo ai nostri collaboratori, e i fornitori sono sempre più in difficoltà; che altro dobbiamo affrontare nell’IT della PA? Esiste almeno qualche novità minimamente divertente – oltre agli Open Data, ovviamente – che ci aspetta? Beh, in effetti qualcosa che ancora ci aspetta dietro l’angolo ci sarebbe, ed è il mobile government. Quello vero.

Al giorno d’oggi, chiunque ha ormai interagito in qualche modo con una applicazione per smartphone o tablet (per gli amici app), o ne ha almeno sentito parlare. E la PA che fa di fronte a tutto ciò? Come si posiziona davanti a questa esplosione tecnologica del mondo mobile?

Il termine “mobile government” risale addirittura al lontano 2003 ed era principalmente usato per connotare l’interazione cittadino-PA via cellulare che all’epoca (ormai qualche era geologica fa) si basava soprattutto su sms e semplici interazioni attraverso un trillo a qualche numero verde.

Il primo sdoganamento delle app nella PA lo abbiamo visto – e lo stiamo ancora vedendo – come effetto collaterale e benefico degli Open Data, attraverso sessioni di brainstorming collettivo (crowdsourcing) che mettono in pratica il “Many Minds Principle: the Coolest Thing To Do With Your Data Will Be Thought of By Someone Else”.

Applicato alla PA il principio diventa: che la PA pensi a produrre dati buoni e ad esporli in modo aperto e facilmente utilizzabile, senza scervellarsi troppo nell’inventarsi app fantasiose, a questo penserà qualcuno là fuori, magari con una gara pubblica (contest), con premi messi in palio dalla PA stessa.

Sono i cosiddetti civic hackathons, come ad esempio BigApps di New York City, uno dei più storici, e a casa nostra AppsforItaly nel 2012, un’esperienza a Torino nel 2011, e due in corso a Bologna  e Roma.

Un tentativo di affrontare in modo strutturato la produzione massiva di app e, più in generale, l’offerta di software “as a service” per le PA lo ha fatto il governo federale statunitense nel 2009, creando una sorta di App Store governativo, il sito “apps.gov”, poi notevolmente ridimensionato dallo scorso dicembre per vari motivi, fra cui l’essere divenuto ormai un mix ingestibile di app gratuite affiancate da applicazioni costosissime e non acquistabili da parte di una PA, come se si fosse ad un supermercato. 

A fianco di ciascun sito Open Data, le PA in genere associano una vetrina delle app sviluppate sui propri dati, anche se questo viene fatto per il momento in modo destrutturato e non regolamentato (si veda poi – nel paragrafo sui rischi – qualche considerazione in merito). In ogni caso, negli Stati Uniti si prevede per il 2013 un ingente boom nella creazione di app da parte di PA locali rispetto alle organizzazioni governative centrali.

Ma soprattutto, le app e le tecnologie per smartphone e tablet sono entrate in documenti strategici al pari dei principi “sacri” degli Open Data: il Decreto Crescita 2.0 di ottobre 2012 all’art. 8 invita allo sviluppo di servizi telematici di trasporto intelligente e di infomobilità (implicitamente basati anche su app), mentre nell’art.15 accenna alla prossima redazione di disciplinari per i pagamenti effettuati con tecnologie mobile. 

La US Digital Strategy emessa nel maggio 2012 sancisce l’importanza – e la dirompenza nella PA – delle tecnologie mobili e richiede ad ogni agenzia governativa di scegliere almeno due servizi strategici per i cittadini, che siano attualmente offline o online poco importa, e di farne la versione mobile entro i prossimi 12 mesi (paragrafo 7). Attenzione al passaggio di approccio: non si parla tanto di creare una app pubblica basata sugli OpenData esposti dal sito di una determinata città, quanto di “convertire” al mobile dei servizi che siano utili ai cittadini.

Si sta quindi passando alla fase matura del mobile government, cercando di creare servizi telematici affidabili, sicuri, e connessi ai sistemi interni agli Enti, integrati con i database dei gestionali, e coerenti con i processi organizzativi interni, ancorché accessibili da uno smartphone o un tablet.

Ecco che una app non è più vista solo come derivazione naturale dell’apertura dei dati pubblici, ma assume la forma di canale di comunicazione formale, anche bidirezionale, con il cittadino. E non solo con il cittadino; infatti la stessa Digital Strategy pone una forte attenzione sull’uso di tecnologie mobili per i dipendenti della PA, e quindi anche sulla sicurezza di questi nuovi sistemi. 

A questo punto, volendo riprendere il confronto con l’e-government classico e la sua relativa tassonomia dei livelli di interazione fra cittadini e siti web della PA (Linee guida per i siti web della PA 2011, pag. 19), di cui si auspicherebbe una prossima estensione al mondo mobile, ci troviamo davanti ad una stragrande maggioranza di app di livello di interazione 1 o 2, ossia si ha praticamente una fruizione di contenuti informativi, raramente una minima interazione. Sono pochissimi i casi in cui una app di una PA permette di avviare una istanza online, di fare un pagamento, o di concludere addirittura l’istanza dal proprio smartphone. Scorrendo i diversi siti opendata e le relative vetrine di app, ci si accorge che questo vale non solo in Italia, ma anche altrove.

Per esempio YouTown, piattaforma per contenuti personalizzati offerta “as a service” da un privato agli enti locali statunitensi per costruire interazioni cittadino-PA anche bi-direzionali, in realtà prevede soprattutto di ricevere feedback dai cittadini, e solo in minima parte “pratiche” amministrative.

Il mobile government vero e proprio insomma è tutto ancora da venire, e potrebbero esserci interessanti opportunità per l’Italia e l’Europa, dove appunto c’è stata una forte attenzione e storia legislativa sul tema della PA digitale, o e-government che dir si voglia.

Ma veniamo a noi, a chi sta in trincea nella PA italiana: che fare di fronte a queste nuove sfide? proviamo a dare qualche pennellata all’intero quadro della situazione. 


I costi

Quanto costa fare una app? Qui si trovano alcuni spunti interessanti, anche se estranei al mondo della PA e degli opendata. Tuttavia, far fare una app di mobile gov come inteso sin qui, che trasla quindi un servizio vero e proprio su mobile, deve tenere conto delle integrazioni con i gestionali di back-office, della sicurezza, del coordinamento dei contenuti con la parte web dei servizi, e di altri aspetti al contorno che rendono il tutto più complesso. Volendo proprio dare una stima economica, per una buona app di mobile government integrata con sistemi interni all’Ente è difficile spendere meno di dieci o quindicimila euro. Chiaramente il fare una app nativa per il mondo iOS ed una per il mondo Android rischia quasi di raddoppiare tale valore, a meno di ottimizzazioni di cui si parlerà più avanti.

Da considerare anche i costi (minimi in termini economici, ma non in termini burocratici) di creazione del profilo dell’Ente presso lo Store, soprattutto per quello di Apple, mentre per Google Play il processo è rapidissimo, essendo minori le verifiche effettuate sull’organizzazione che richiede il profilo.

Torna all’indice

Il ruolo dei tecnici della PA

Realizzare internamente una app di mobile government, data la mole di nuove tecnologie coinvolte rispetto al già variegato mondo del Web, risulta al momento piuttosto ardito. È fondamentale iniziare con un processo formativo, non solo orientato al mondo mobile, ma anche alle nuove tecnologie del Web (HTML5 innanzitutto, ma anche CSS3), per cercare intanto di presidiare al meglio il processo di acquisizione, sapendo di che si parla quando si richiedono offerte e si scrivono specifiche, e soprattutto quando si eseguono i collaudi. Aiuta in questo senso pensare a soluzioni che prevedano il training on the job da parte del fornitore, ed il lavorare gomito a gomito con chi sviluppa la app in prima persona.

Da non sottovalutare la questione helpdesk: aspettatevi di ricevere mail da cittadini che vi chiedono «perché sullo smartphone di marca X acquistato al supermercato da mio padre non trovo la vostra app sul Google Play, mentre su un altro di marca Y la trovo ma con una parola chiave diversa da quella da voi indicata?» (it’s not a bug, it’s a feature, viene detto qui), oppure vi chiedono il motivo di comportamenti difformi di alcune funzionalità della app, su smartphone diversi. Per quanto una app possa essere pensata e realizzata bene, c’è da aspettarsi comunque di dover affrontare temi simili.

Un ruolo forse non proprio dell’IT, ma comunque strategico, è quello di chi andrà a raccogliere le segnalazioni inviate tramite la app dai cittadini, e a rispondere loro nei diversi canali disponibili (e-mail, twitter, facebook, o con contenuti “push” iniettati nella app stessa).

Torna all’indice

I rischi

Trattandosi di terra di frontiera, i rischi sono tanti, di cui solo alcuni stimabili, per il resto occorre lanciare il cuore oltre l’ostacolo ed affrontare l’ignoto una volta partiti.

Riguardo alla sicurezza, la tecnologia mobile prevede soluzioni e forme di interazione molto diverse dall’accesso con un PC o un laptop, e di conseguenza si individuano rischi diversi.

Inoltre, molti dei vincoli che limitano la diffusione dell’uso dei servizi online della PA continueranno ad esistere anche su mobile: in particolare sarà sempre necessario rimuovere – a livello normativo nazionale, ma anche con regolamenti locali – la miriade di condizioni strutturali che fanno sì che per il cittadino o per la PA risulti poco o per nulla conveniente fare la pratica per via telematica, sia essa online, o da mobile.

E se vi capitasse uno studente che ha sviluppato, prendendo i vostri dati pubblici, una app interessante e utile per i cittadini, non potrebbe valer la pena metterla sulla vetrina delle app associata al vostro sito Open Data, fra quelle sviluppate da terzi? Nei casi in cui la PA ha fatto un civic hackathon è presente una giuria, che valida le app una tantum, ma come gestire invece una vetrina permanente di app? Come strutturare e organizzare il processo di proposizione, valutazione e messa in vetrina di app fatte da liberi cittadini e utili alla città, con una sorta di patrocinio2.0?

Infine, partendo con singole iniziative di app di mobile government, ciascuna delle quali “pesca” direttamente i dati dalla pancia di ciascun vostro gestionale (scuola, edilizia, prenotazioni esami, etc), vi troverete ben presto ad avere la classica “spaghetti-integration” dell’epoca del Web1.0, ossia tante monadi sul fronte mobile esterno integrate 1 a 1 con altrettanti gestionali interni, senza una piattaforma che integri le funzioni comuni (come l’autenticazione, i pagamenti, il monitoraggio dei dati d’uso, etc). Purtroppo è un rischio da mettere in conto: con le scarse risorse a disposizione è poco probabile che si riesca sin dalla partenza a creare una piattaforma uniforme di erogazione di servizi mobile a livello di Ente.

Torna all’indice

Da dove partire?

In primis, occorre capire quali sono i servizi utili da trasportare su mobile, e soprattutto quali e quanti potrebbero esserne gli utenti potenziali. In questo il co-design potrebbe aiutare: fatta una prima valutazione interna, potremmo rivolgerci ai cittadini, parlarne con loro, recepire i loro bisogni, e dar loro seguito riportando le decisioni prese e coinvolgendoli nei passi successivi dello sviluppo.

Sarebbe poi preferibile crearsi un profilo del proprio Ente sugli Store, in partenza su Apple Store e su Google Play, stando ben attenti alla End User License Agreement: ricordatevi che state sempre mettendo il naso nei dispositivi che i cittadini hanno in tasca. Proprio perché siamo in terra di frontiera, per la serie “meglio aver paura che buscarne”, potrebbe essere saggio far impegnare formalmente il fornitore a non inserire codice malevolo né nella app consegnata né nei suoi futuri aggiornamenti, e ad usare le buone pratiche di programmazione su mobile in sicurezza. Sarete voi a dare indicazioni di dettaglio al fornitore, ad esempio chiedendo di seguire al meglio, oltre alle generiche misure di sicurezza indicate nel Codice della Privacy e relativo allegato B, le linee guida per la sicurezza mobile indicate dalla relativa sezione dell’Open Web Application Security Project. Commentando e verificando insieme al fornitore la modalità di adozione di queste linee guida, potrete allo stesso tempo iniziare a formare sul campo anche i vostri tecnici sul mondo mobile.

Il lancio della vostra nuova app dovrà essere preceduto da un’adeguata campagna sui social media, definendo un hashtag su Twitter dedicato su cui comunicherete novità e aggiornamenti, e individuando ad esempio un gruppo di cittadini con cui svolgere la fase di beta-testing, facendo provare loro la app in anteprima, prima che sia sugli Store. Sarà poi importante richiamare, dal luogo fisico dello sportello dell’Ente, l’invito a scaricarsi la app, ad esempio tramite l’uso di QRcode.

Particolare attenzione va posta al tema delle prestazioni, ossia alla giusta sintonizzazione fra quanto traffico deve transitare fra smartphone e vostri server (per evitare che il cittadino stia per interi minuti ad ammirare la rotellina che gira mentre la app carica i dati), quanti dati devono risiedere in locale nello smartphone del cittadino (una app troppo pesante può risultare fastidiosa per chi ha poca memoria sul cellulare), e quante chiamate simultanee potranno arrivare ai vostri server dai dispositivi mobili (per evitare il crollo del server in caso di sovraccarico). Nelle prove che farete, state anche attenti agli effetti della intermittenza della connessione di rete, in particolare per le reti wifi presso hotspot pubblici, che possono avere un timeout specifico dopo il quale è necessario ri-autenticarsi alla rete. Quando la app richiede nuove connessioni alla rete, dopo un certo tempo di utilizzo offline, potrebbe risultare fastidiosa la necessità di digitare nuovamente le credenziali per l’accesso alla rete wifi.

Altri elementi da considerare riguardano le tecnologie e gli effetti che sono presenti solo su uno smartphone e non su un PC: il touchscreen, il giroscopio e la geo-localizzazione, che mi indicano in che posizione si trova il dispositivo e quindi cosa sta facendo il cittadino (ad esempio se è in movimento potrei comunicargli diversamente da quando è fermo).

Una delle forme più semplici e immediate di servizi di mobile government prevede la fornitura di dati al cittadino in modo “push”, cioè prendendo informazioni dalla pancia dei sistemi dell’Ente, e offrendole al cittadino magari con notifiche, evitando che si debba preoccupare di avviare la app e cercare ciò che gli serve, mentre è in mobilità. Per fare questo è essenziale curare la bontà dei dati dei vostri sistemi, altrimenti il rischio è di notificare al cittadino che gli sta scadendo il pagamento della mensa scolastica di sua figlia…quando invece non ha figli! Può comunque succedere che ci siano dati che non quadrano, per cui è buona norma inserire nella app una funzione di invio di segnalazioni sulla bontà dei dati, nonché sul gradimento della app stessa e di quanto essa veicola al cittadino.

Un’altra scelta filosofica riguarda la tecnologia di partenza: se scegliere una app nativa (ossia una app fatta appositamente per iOS o per Android), oppure realizzare un servizio mobile web (navigabile da browser dello smartphone). Ecco un simpatico video che spiega la differenza e le opportunità. Molto probabilmente la vera soluzione starà nel mezzo (mobile web app), ossia arriveremo ad avere (in modo simile a quanto avviene in app famose che già avete sul vostro smartphone) dei contenitori “stupidi” che costituiscono la app da mettere sullo Store, mentre una volta attivata la app dentro lo smartphone essa prenderà tutti i contenuti e si popolerà quasi interamente dalla Rete, come se fosse un browser. Il tutto con una serie di funzioni a schermo che daranno all’utente una esperienza di utilizzo tipica di una app nativa vera e propria. In questo modo si ottiene l’elevata usabilità delle app native, insieme alla maggiore compatibilità su dispositivi e schermi diversi, tipica del mobile web.

La diffusione di tecnologie come HTML5, se usate correttamente, permetterà inoltre di realizzare contenuti una volta sola, e di veicolarli su diverse piattaforme, seguendo il cosiddetto Responsive Web Design – ossia la possibilità di creare contenuti web adattivi.

Infine, come ci insegna il Codice dell’Amministrazione Digitale agli artt. 64 e 65, occorre fare attenzione all’autenticazione il cui livello, in attesa di ulteriori precisazioni normative, dovrà sicuramente essere non inferiore a quello usato per i servizi online del vostro Ente. Inserendo nella app le credenziali già in suo possesso per i servizi online, il cittadino potrebbe inviare istanze o ricevere contenuti profilati con il suo smartphone. Su questo fronte ci sono almeno altri due inghippi, uno riguarda la capacità di memorizzazione delle credenziali di accesso ai servizi online sul proprio dispositivo. È pur vero che memorizzarle sarebbe una funzione comoda per l’utente, per evitargli di doverle ridigitare ogni volta, ma ricordiamoci del loro valore giuridico: cosa succede se lo smartphone viene perso o rubato? Infine, ormai tutti gli utenti del mobile sono abituati a interagire, da dentro le app, con i social networks: cosa succede se si fonde una app contenente dati personali del cittadino, anche sensibili, con il suo profilo Facebook, allo scopo di fargli fare ad esempio un like o una condivisione di qualche informazione ricevuta tramite la app? Al momento mi vengono in mente diverse conseguenze, nessuna di esse è positiva…per cui almeno in questa prima fase pioneristica, sarebbe forse più prudente tenere separati i due mondi, quello delle app “istituzionali” di mobile government, con cui scambio dati personali e attivo procedimenti con il mio Ente, e quello in cui sono coinvolti i miei profili dei social networks.

Quanto ai pagamenti, vista la complessità dello scenario dei micro-pagamenti basati su interazioni di prossimità (Near Field Communication), che include accordi fra soggetti interbancari, e tecnologie che ancora non sono disponibili su tutti gli smartphone, direi che in questa fase un primo approccio potrebbe essere quello di traslare su mobile la forma di pagamento che usate nel vostro Ente dal sito web, anche a costo di dover chiedere all’utente di digitare i dati della sua carta di credito sul suo cellulare, ovviamente preoccupandovi di rendere la connessione e l’interfaccia adeguatamente sicure.

Come ulteriore spunto, qui trovate sette buoni consigli per fare app utili per le amministrazioni locali (in evidenza l’invito a tenere la app semplice, a dare importanza alla localizzazione dell’utente, e a pensare da subito alla integrazione con i sistemi di back-office).

Torna all’indice

Le opportunità 

Lo sviluppo della tecnologia mobile, accompagnato dalla sempre maggiore difficoltà degli Enti a dotarsi di nuovo hardware, porta con sé anche un’altra nuova sfida, quella del mobile government inteso come “lavoro interno alla PA, che diventa mobile”, e qui si arriva ad un terreno ancora più pioneristico, se pensate che solo nel Giugno 2012 il Dipartimento della Difesa US, ha emesso il memorandum sulla Mobile Strategy che pone una serie di punti di attenzione sull’uso di tecnologie mobili sul posto di lavoro: a partire dai rischi del Bring Your Own Device, ossia il portarsi il pc o lo smartphone di casa ed usarlo come strumento di lavoro, il che fa risparmiare la PA ma pone seri rischi di sicurezza e vari altri grattacapi ai tecnici dell’IT. Si parla poi della necessità di una infrastruttura IT per la gestione, il monitoraggio, il rafforzamento delle policies dedicati ai dispositivi mobili, e anche della formazione al personale della PA, che “deve saper riconoscere la differenza fra l’utilizzo del suo dispositivo mobile o laptop da casa propria o sul posto di lavoro”. Il memorandum richiama anche l’importanza dello stabilire un framework comune di sviluppo di app, per evitare appunto la spaghetti-integration citata sopra fra i rischi possibili.

Ecco un interessante post che racchiude le principali sfide del mobile government per il 2013.

Ancora più di recente, qui è stata fatta anche una analisi di come la US Digital Strategy per il mobile government può essere attuata al meglio, per esempio riutilizzando al massimo contenuti digitali già a disposizione della PA.

Il mobile government potrebbe essere una sorta di scorciatoia per superare il digital divide fra cittadini e PA: magari quella porzione di cittadini che oggi non trova intuitivo usare il canale Web per interagire con la PA, potrebbe invece in modo più semplice utilizzare una app.

Inoltre, aspetto non secondario, una app costringe alla semplicità. Gli uffici che chiedono al proprio IT di fare un servizio online semplice e facile, fornendo ai programmatori dei disciplinari di trenta pagine che spiegano tutte le regole, regolette e regoline per poter fare quella pratica, saranno finalmente costretti a soccombere di fronte all’inevitabile: in una app non puoi chiedere al cittadino di compilarti “chili” di form, non puoi permetterti di richiedergli dieci volte dati su di lui che già hai o dovresti avere nella pancia dei tuoi sistemi. Toccherà per forza cambiare paradigma. La “pratica” diventerà ben presto un «ti va bene quanto trovi su questa schermata? Se sì, confermamelo, arrivederci e grazie». Probabilmente il documento informatico stesso collasserà in un flag di un database, dove sta scritto che, sì, al cittadino in data X quella serie di dati andava bene, e lo ha dichiarato toccando un tasto sullo schermo del suo smartphone, o addirittura avvicinando il suo cellulare ad un POS in un edificio pubblico.

Si pensi anche alla enorme trasformazione che subiranno i siti istituzionali della PA: dopo essere stata faticosamente riunita in un portale web dell’Ente in tanti lunghi anni di lavoro, l’informazione istituzionale si disgrega e prende mille rivoli, si pensi al cammino che può fare un dataset esposto sul sito Open Data di un Ente, poi ripubblicato da altri siti in forme o interfacce diverse, o un’informazione su un evento in città, che venga “captata” da tante app prodotte da fornitori diversi, o infine ad un comunicato postato sui social media e su app istituzionali.

Volendo fare qualcosa da subito nella direzione del mobile government, si potrebbe anche partire dal semplice, scimmiottando un po’ l’invito della US Digital Strategy indicata poco fa: cercare di convertire entro l’anno almeno uno o due servizi al mobile, e creare le giuste condizioni al contorno a livello nazionale e locale per rendere questa strada percorribile e sostenibile economicamente, e soprattutto per incentivare l’utilizzo dei nuovi servizi da parte dei cittadini.

Inoltre, con la tendenza marcata delle ultime azioni normative a centralizzare gli asset strategici e più consolidati dell’IT nella PA (si pensi all’anagrafe nazionale della popolazione residente, e alla presentazione online delle iscrizioni alla scuola primaria centralizzata sul Ministero), il mobile government potrebbe essere invece per i prossimi anni un terreno in cui le amministrazioni sui territori possano ideare e sperimentare nuove forme di interazione fra cittadini e PA, per poi riportarne gli esiti al livello centrale, anche al fine di diffondere le buone pratiche.


*Gianluca Vannuccini, un breve profilo dell’autore

VAI ALLA VERSIONE INGLESE DELL’ARTICOLO

 

Valuta la qualità di questo articolo

La tua opinione è importante per noi!