Vai al Contenuto Raggiungi il piè di pagina
ConsorzioIT ha avuto l’opportunità di partecipare alla fase pilota della piattaforma nazionale per il contrasto agli attacchi informatici per la Pubblica Amministrazione. Agendadigitale.eu ha riportato un resoconto della nostra esperienza http://bit.ly/33pcLK8
Consorzio.IT ha finanziato un vademecum dal nome “Cambiamo Aria” che sarà distribuito in #60mila copie in tutti i comuni cremaschi, come deliberato dai sindaci dell' #AreaOmogeneaCremasca per una comune opera di sensibilizzazione e divulgazione.
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
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 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).
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à.
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.
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.
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.
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.
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 scopi quindi dell’opensource sono permettere di:
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.
Le operazioni per chi è programmatore sono semplici:
Le leggi che governano questo percorso, per chi volesse approfondire, sono:
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
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.
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:
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:
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.
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?
Ecco cosa abbiamo imparato portando la sperimentazione di IO a Ripalta Cremasca che può essere di ispirazione e aiuto per tutti i Comuni d’Italia
Il nostro interesse per IO nasce dalla visione condivisa in un post dell’ex Commissario Straordinario Diego Piacentini, che con chiarezza aveva indicato come sarebbe dovuta essere la Pubblica Amministrazione italiana dopo alcuni anni di cambiamento verso la digitalizzazione.
Letto quel post — che ci ha colpito come professionisti e colpito come cittadini che da anni si chiedevano perché ancora non esistesse un canale con cui la Pubblica Amministrazione potesse comunicare con i cittadini evitando loro la rinconcorsa di scadenze e pagamenti, — abbiamo deciso di renderci subito disponibili a partecipare alla sperimentazione dell’app destinata a ribaltare il modello di erogazione dei servizi pubblici.
Tramite una semplice email, siamo entrati in contatto con Matteo De Santi, Responsabile del progetto IO all’interno del Team per la Trasformazione Digitale e chiesto di aderire alla fase sperimentale dell’app come ConsorzioIT, in qualità di partner tecnologico del Comune di Ripalta Cremasca. Ne è scaturito uno scambio di email sui requisiti e le informazioni utili all’onboarding dell’ente su IO, così da poter dare finalmente il nostro contributo al progetto.
Riteniamo questo progetto “disruptive” sotto tanti aspetti: per come è pensato (open-source, collaborazione con gli utenti nella fase di sviluppo), per le opportunità di collaborazione che nascono in fase di sviluppo (ad esempio, nel dialogo con le software house coinvolte per l’erogazione dei servizi locali) e per l’integrazione completa alle piattaforme abilitanti (SPID e pagoPA in primis).
Sono due i temi che abbiamo cercato di risolvere inizialmente, in qualità di partner tecnologico di molti enti pubblici sul territorio cremasco: prima di tutto, abbiamo cercato di capire quanto fosse complesso salire a bordo di IO a livello tecnologico; in un secondo momento, abbiamo individuato un set di servizi del Comune di Ripalta Cremasca da integrare in IO.
Dal punto di vista tecnologico, il processo di onboarding è piuttosto semplice. Si tratta di ottenere un account di accesso al back-office di IO come ente per profilare i singoli servizi. Una volta profilato il servizio, si ottiene una chiave di accesso (API key) a IO per lo specifico servizio che viene consegnata alla software house o, più in generale, ai referenti dell’ente responsabili degli aspetti tecnici. Sono questi ultimi a utilizzare le API key per l’invio dei messaggi, dopo avere approfondito come interfacciarsi a IO (il cui codice è open-source) leggendo la relativa documentazione online.. La parte di competenza dell’ente, quindi, è molto semplice e nel caso di Ripalta Cremasca è stata da noi realizzata.
Contemporaneamente abbiamo cercato di individuare dei servizi che fosse possibile attivare su IO e che fossero interessanti per la cittadinanza: abbiamo individuato alcuni servizi associati ai pagamenti digitali in modo da permettere al cittadino non solo di ricevere un’informativa ma anche di effettuare un’operazione di pagamento utilizzando pagoPA direttamente dall’app.
Concentrandoci su una serie di servizi che fossero immediatamente fruibili nei periodi successivi al lancio della sperimentazione (avviata a inizio luglio), , così da permettere ai cittadini di utilizzare subito l’app, la scelta è ricaduta su:
- Tari (tassa rifiuti), in uscita nelle settimane successive
- Minigrest (centro estivo per l’infanzia), in attivazione nel mese successivo
- Mensa Scolastica, in attivazione dopo due mesi
- CIE, sempre attivo
Tutti i servizi sono interessati da pagamenti; questo ci ha permesso di rendere subito il cittadino parte attiva nel processo di evoluzione del progetto IO sin dalla fase di onboarding di un ente.
ll tempo a nostra disposizione per effettuare l’integrazione era di circa un mese. Avevamo tre strade possibili da perseguire:
La prima opzione ci avrebbe dato maggiore flessibilità, ma richiedeva un effort interno all’azienda.
La seconda opzione ci avrebbe potuto fornire un grande contenuto informativo: ogni software house responsabile di un servizio ha accesso a tutte le informazioni associate; significa, ad esempio, che avremmo potuto avvisare i cittadini con un mese di anticipo dell’imminente scadenza della propria carta di identità, attraverso un automatismo che controllasse il dato quotidianamente nei sistemi comunali. Tuttavia, avremmo dovuto coinvolgere più interlocutori in un breve tempo, col rischio di avere anche costi di sviluppo.
La terza opzione ci avrebbe permesso di coinvolgere un unico interlocutore, con il risultato di poter gestire un contenuto informativo ridotto — cioè solo relativo ai pagamenti — , ma il cui accesso sarebbe stato più veloce.
Abbiamo optato per utilizzare la terza strada, rivolgendoci a una software house come PMPAY che ha saputo cogliere l’opportunità e coadiuvarci nello sviluppo a costo zero, vedendolo come un investimento importante e un’integrazione valida anche per migliorare il suo prodotto. Abbiamo anche utilizzato la strada (prima) dello sviluppo interno per alcune parti informative (ad esempio il dettaglio degli immobili della Tari, partendo da un tracciato in csv gentilmente rilasciato dalla software house del verticale, APK) e per la TARI stessa in modo da poter gestire la logica della singola rata e della rata multipla.
Effettuati tutti i test del caso, mediante delle utenze-cittadino create come normali cittadini e utilizzate come ambiente di test, abbiamo pensato a come coinvolgere al meglio la cittadinanza.
In una grande città, pubblicare un annuncio chiedendo a una persona di aiutare la Pubblica Amministrazione a ottimizzare un nuovo canale digitale al servizio di tutti i cittadini prima di lanciarlo pubblicamente è sicuramente un’ottima strategia, che permette di ottenere l’attenzione e la disponibilità di centinaia di interessati. , In un piccolo Comune come Ripalta Cremasca, al contrario, questa strategia rischia di coinvolgere pochissime persone.
Avere a che fare con una realtà di poche migliaia di abitanti, ci ha permesso di seguire un approccio in due passaggi:
In un primo momento, abbiamo attivato una sorta di “porta a porta” digitale (ad esempio tramite un messaggio su Whatsapp) o una telefonata, quando si trattava di famigliari, amici, conoscenti.
In seguito, abbiamo realizzato una serata di presentazione ufficiale di IO aperta a tutti i cittadini, nella bellissima cornice di Villa San Michele a Ripalta Cremasca; un evento fortemente voluto dallo stesso Sindaco , sempre illuminato nel perseguire la trasformazione digitale a livello locale, e con presenti i vertici di Consorzio.IT, a dimostrazione dell’impegno che la nostra azienda mette nel seguire i suoi Comuni in questo periodo di grande cambiamento e trasformazione
Lo scopo della serata è stato quello di spiegare nel dettaglio cosa è IO, come funziona e cosa avrebbero potuto fare i cittadini che si fossero candidati come beta tester. In primis, gestire di lì a breve il pagamento della TARI anche su IO, in un clic. Ma non solo: l’evento è stata l’occasione per chiarire anche le modalità e finalità della sperimentazione, spiegando ai presenti l’importanza del loro contributo al progetto nel segnalare gli aspetti dell’app più apprezzati o eventuali difficoltà durante la sua fruizione. In particolare, abbiamo voluto dare supporto ai cittadini in tutti i passaggi necessari per partecipare alla fase di test: dalla compilazione del form per partecipare alla closed beta, alla necessità di avere SPID (mostrando i vantaggi di avere un’identità digitale e come fare per ottenerla) , fino al download dell’applicazione.
Per semplificare il tutto al massimo, abbiamo anche realizzato una piccola brochure (un A4 fronte/retro) da lasciare ai partecipanti con alcune indicazioni operative per “essere più digitali” e, per i cittadini interessati a partecipare alla closed beta, abbiamo predisposto delle postazioni con tablet per potersi registrare con il supporto di tecnici che li hanno guidati nella compilazione del form di iscrizione online.
Questa è una delle prime volte, anche a livello nazionale, in cui la cittadinanza viene coinvolta per contribuire a migliorare un progetto promosso dalla Pubblica Amministrazione sin dalla sua fase di sviluppo. L’interesse e l’entusiasmo mostrati dai partecipanti all’evento a Ripalta Cremasca ci hanno confermato la bontà della scelta di salire a bordo di IO dall’inizio.
Per accompagnare i cittadini nel test, oltre al canale diretto con il Team Digitale disponibile sull’app con le funzioni di Chat e Coccinella (Instabug), abbiamo aggiunto una chat dedicata sul sito istituzionale del Comune, in modo che ogni persona coinvolta potesse avere uno strumento aggiuntivo per chiedere anche ai referenti del Comune qualsiasi informazione legata alla sperimentazione di IO.
Considerato il campione di tester di Ripalta Cremasca — composto principalmente da persone senza particolari competenze tecnologiche — le prime difficoltà segnalate dagli utenti hanno riguardato l’ottenimento dell’account SPID.
La maggior parte dei cittadini ha scelto l’Identity Provider di Poste, poichè consente di effettuare la registrazione direttamente allo sportello. Il nostro supporto è stato importante nelle fasi successive, per aiutare alcuni cittadini già al momento dell’attivazione di SPID tramite il codice da inserire nell’app di Poste.
Superate queste prime complessità nella creazione dell’identità digitale, ciascun cittadino ha ricevuto il messaggio di Benvenuto nell’app IO della Presidenza del Consiglio e del Comune con la possibilità di consultare i servizi attivi erogati dal proprio ente locale e dagli enti nazionali (nel caso specifico, ACI).
È cresciuta quindi l’attesa per la ricezione della TARI, che sarebbe stato il primo servizio oggetto della sperimentazione e che è stata inviata il 10 luglio. Grazie all’app IO, i cittadini hanno pagato per la prima volta la tassa rifiuti con un semplice click direttamente dal proprio smartphone, entusiasti di aver saldato un tributo in modo semplice e comodo.
Grazie al passaparola generato da alcuni tester molto entusiasti dei vantaggi offerti dall’app, nel corso delle settimane altri cittadini hanno deciso di aderire alla sperimentazione.
Nel mese di agosto è arrivata anche la possibilità di effettuare il pagamento del MiniGrest (ovvero il Campus Estivo per i bambini della scuola d’infanzia) direttamente dall’app. Ora, con ’apertura delle scuole nel mese corrente, il cittadino avrà anche la possibilità di pagare la mensa scolastica direttamente da IO.
Come ogni anno, da ormai 4 anni a questa parte, ConsorzioIT mette a disposizione il suo supporto ospitando studenti per l’alternanza scuola lavoro.
Nel 2019, per ora, sono stati ospitati 5 ragazzi della classe 4 dell’ITIS di Crema, che hanno potuto misurarsi con il “lavorare in azienda”, dover rispettare tempi, ruoli e scadenze e poter provare alcune attività tipiche del mondo ICT.
E’ possibile consultare il profilo di Consorzio.IT presso il registro Nazionale per l’alternanza Scuola Lavoro, anche questo è “fare” per il territorio.
Grazie a questo accordo Consorzio.IT entrerà a far parte del comitato di gestione, che avrà il compito di governare le attività programmatiche, operative e di comunicazione, nelle quali si estrinsecherà operativamente la collaborazione e cooperazione oggetto del presente Accordo.
Crema, 30 Luglio 2019 - Nella Mission di Consorzio.IT, i sindaci hanno indicato la necessità di instaurare delle relazioni di collaborazione e sinergia con enti sovraterritoriali, provinciali, regionali, nazionali e accademici, creando una rete a tutti i livelli che agevoli l’evoluzione della PA, allo scopo di valorizzare le attività svolte sul territorio e promuovendone le buone pratiche e cercando di acquisirne di nuove.
In data 26 luglio, alle ore 12:30, si è svolta la riunione del Comitato di gestione tra il Team per la trasformazione digitale della Presidenza del Consiglio dei ministri e la Corte dei conti e sono state approvate le adesioni del Comune di Cremona, dell'Ente Consorzio Informatica e Territorio Spa, dell’Università degli Studi di Roma "Tor Vergata”, del Prefetto di Alessandria e degli Enti da lui rappresentati.
Gli obiettivi dell’Accordo consistono nel condividere le best practice attuate e le esperienze maturate per favorire l'aggiornamento dei sistemi informativi delle amministrazioni aderenti, privilegiando i paradigmi "cloud first" e "mobile first". Con questa collaborazione si predilige la condivisione dei dati da parte delle amministrazioni per consentire lo scambio e l'elaborazione dei dati, sia all'interno di un'organizzazione sia esternamente (open data), in modo agevole, affidabile, in piena sicurezza e rispettando la normativa sulla privacy.
<<Siamo orgogliosi di sedere al tavolo dei principali protagonisti che contribuiscono all’attuazione dell’Agenda Digitale>> ha commentato Alessandra Vaiani, Presidente di Consorzio.IT, indicando fra le aree oggetto della collaborazione quelle in cui Consorzio.IT si vuole focalizzare maggiormente, quali nello specifico: Infrastrutture digitali, Piattaforme Abilitanti, Pagamenti digitali (pagoPA), Anagrafe Nazionale Popolazione Residente (ANPR), Progetto IO - Cittadinanza digitale, Data & Analytics Framework (DAF), CyberSecurity, Opendata.
L'amministratore Delegato Franco Miceli ha aggiunto. <<E’ motivo di orgoglio che il Direttore Dott. Massimo Zanzi sia stato nominato quale membro aggiuntivo del comitato di gestione insieme al Dott. Simone Piunno (Team per la trasformazione digitale della Presidenza del Consiglio dei ministri) e il Dott. Michele Melchionda per la Corte dei conti>>
Questa sera si è riunita l’assemblea dei soci di SCRP per deliberare l’atto di indirizzo relativo alla dismissione del ramo idrico e la vendita delle quote di Biofor Energia con il relativo ramo di gestione. L’assemblea si è espressa all’unanimità dei presenti per la dismissione del ramo idrico e con l’unica astensione da parte del Comune di Trigolo relativamente alla vendita di Biofor. La conclusione di queste operazioni consente di aprire la fase finale del progetto di fusione inversa che vedrà la fusione per incorporazione di SCRP S.p.A. in Consorzio.IT S.p.A.
Anche nel Comune di Cremosano abbiamo attivato la possibilità per i cittadini di effettuare pagamenti attraverso il pos@PA. Grazie alla collaborazione con Nexi abbiamo installato un pos che permette di effettuare pagamenti verso la piattaforma pubblica dei pagamenti #pagoPA
