Considerazioni di consuntivo su alcune esperienze di progetti

Considerazioni di consuntivo su alcune esperienze di progetti di e-gov. Valutazioni sulle prospettive future con particolare riferimento ai temi dell’inter-operabilità e dell’identificazione del cittadino nell’accesso ai servizi Marco Nanni Responsabile Area Demografici e Progetti e-Government Gruppo Maggioli 1

Agenda GRUPPO MAGGIOLI 1. Il Gruppo Maggioli – Posizionamento e Mission 2. L’accesso ai servizi On. Line – esperienze ed idee per facilitare l’accesso ai cittadini 3. Il colloquio tra portale dei servizi e sistemi di back office: architettura e tecnologie a confronto 4. Accessibilità 5. Il modello di business dei progetti di e. Gov Premessa: le società del gruppo Maggioli sono state coinvolte in numerosi progetti di e-Gov. In questa sede non ci interessa fare una buona pubblicità di noi stessi. Tuttavia pensiamo di avere l’esperienza per segnalare soluzioni innovative (anche quando sono state sviluppate da altri) e l’autorevolezza per evidenziare problemi tutt’ora aperti. Ovviamente manteniamo il desiderio di continuare a supportare gli Enti nello sviluppare questi servizi. 2

Le attività del Gruppo e l’ area informatica q q q Editoria Formazione Modulistica/Gestione Documenti Informatica Servizi di riscossione Tributi e Contravvenzioni C. d. S. q Fiere e Convegni Fatturato consolidato 2007 Oltre 100 milioni Circa 1100 dipendenti GRUPPO MAGGIOLI Processo di costituzione di un Polo informatico per la PA q Maggioli Informatica. Santarcangelo (Rn) q Studio K Reggio Emilia q Sipal Savigliano (CN) q Bit Cosenza q Cedaf Forlì q Elda Soft Treviso Oltre 30 mil. di fatturato Oltre 300 persone Oltre 3800 enti con almeno una licenza SW del Gruppo 3

Sedi TECNICO/COMMERCIALI SETTORE INFORMATICA GRUPPO MAGGIOLI

Il ruolo dell’informatica nel Gruppo GRUPPO MAGGIOLI Maggioli: “Il partner per il governo locale” Le attività informatiche e la leadership nel mercato dei servizi per la PA • il mercato dei servizi alla Pubblica Amministrazione si estenderà e si consoliderà progressivamente; • in questo contesto la scelta del Gruppo Maggioli di acquisire diverse aziende informatiche e di far crescere le attività relative all’informatica è una scelta strategica, ispirata da una visione del cambiamento in atto; • il Gruppo mantiene il focus sul mercato della PA e punta ad uno sviluppo del business che faccia leva sulla capacità di offrire soluzioni informatiche e servizi connessi progettiamo e realizziamo soluzioni informatiche come offerta informatica diretta per far crescere la competitività e il valore aggiunto dei servizi (non solo informatici) che come Gruppo offriamo nei vari ambiti di attività sappiamo coniugare al livello più alto possibile conoscenza dei processi innovazione tecnologica 5

GRUPPO MAGGIOLI Le esigenze e … i prodotti SUAP Personale Polizia municipale: 1600 clienti Traffico Lavori Pubblici Ambiente Edilizia Attività Produttive Commercio SIT 6 Base Documentale e Protocollo Tributi Amministrazione Istruzione mensa, trasporti Servizi Sociali Cultura - Musei Biblioteche Teatri Sport Persona Famiglia Elettorale URP Servizi cimiteriali Collettività Territorio Portale servizi e istituzionale) Demografici – 1500 clienti Cittadino Organismi Istituzionali

Alcuni dei progetti realizzati GRUPPO MAGGIOLI Portali e Politiche di e-Government • • Progetto SUAP Cadinella. Rete Progetto Ci. Tel Progetto People Progetto POL-BAS Altri progetti in cui siamo stati coinvolti • Etna in Web • Teseo • e-Mantova • Servizi On. Line del comune di Rimini coordinatore: Comune di Carrara coordinatore: Comune di Pisa coordinatore Comune di Firenze Regione Basilicata coordinatore: Comune di Catania coordinatore: Comune di Verona coordinatore: Comune di Mantova Gestione Protocollo e Base Documentale • • • Progetto Doc. Area (ex Panta Rei) Firma Digitale Progetto Teseo Protocollo Informatico Interoperabilità Protocollo Enti Provincia di Bologna Provincia di Firenze Comune di Verona Regione Sicilia Regione Toscana Regione Emilia Romagna Area Socio-Assistenziale • • giugno 2005 Sistema Socio Assistenziale Minori Regione Emilia Romagna Progetto I Care: area Socio-Assistenziale Regione Emilia Romagna Cedaf 7

Autenticazione: strumenti di identificazione GRUPPO MAGGIOLI Tutte i progetti di e-gov citati in precedenza utilizzano molteplici livelli di autenticazione: Ø auto registrazione spontanea dei dati da parte del cittadino Ø username + password consegnate dall’Ente al cittadino Ø firma digitale - anche se utilizzato in modo improprio Ø CIE, CRS, CNS Normalmente, il livello di autenticazione è associato alla criticità del servizio. Ad esempio, per la sottoscrizione di un servizio di alert con SMS è sufficiente un livello di autenticazione debole. L’inoltro di una domanda di cambio di residenza richiede un livello di autenticazione forte. 8

Autenticazione: Uso della firma digitale GRUPPO MAGGIOLI Normalmente qualsiasi servizio On. Line che produce l’attivazione di un procedimento amministrativo (es: autorizzazione commerciale, richiesta di rimborso ICI, ecc. ) deve produrre un documento con validità giuridica. Questo documento, per sua natura, deve continuare ad essere valido anche al di fuori del portale in cui è stato generato. Infatti se lo stesso procedimento viene attivato in modo tradizionale, si deve produrre un documento cartaceo a cui il cittadino deve apporre la propria firma autografa. Pertanto l’utilizzo di strumenti innovativi di autenticazione (CIE, CNS, CRS) non sostituisce la firma digitale. Il progetto CITel “risparmia” l’uso della FD a chi si autentica con la CIE. Altri progetti richiedono la firma dei documenti da presentare all’Ente. Allo stesso modo anche l’utilizzo della firma digitale non potrebbe sostituire CIE, CNS, CRS. Nel progetto Cadi Nella Rete la FD viene utilizzata anche per firmare il processo di registrazione nel portale. 9

Autenticazione: vincolo della piattaforma MS Windows GRUPPO MAGGIOLI L’utilizzo di strumenti innovativi di autenticazione e firma (FD, CIE, CNS, CRS) di fatto impone l’impiego di componenti SW disponibili prevalentemente in ambiente Windows: • Crypto. API – disponibili su windows 98 o succ. • Crypto Service Provider – componente fornito dalle CA spesso solo per la piattaforma windows • Servizi di accesso alle Smart. Card - disponibile su windows 2000 o succ. Esistono alcuni tentativi interessanti per offrire soluzioni equivalenti per il mondo linux; es: Open. Signature. Tuttavia oggi è ancora un problema aperto l’utilizzo della FD all’interno di un browser su sistema linux con Smartcard rilasciata da una CA italiana. Spesso si pone molta enfasi all’utilizzo di piattaforme Open Source ma si ignorano molti limiti alla modesta disponibilità di componenti SW per queste piattaforme. 10

Autenticazione: la registrazione degli utenti GRUPPO MAGGIOLI Un cittadino, quando accede per la prima volta ad un portale di e-gov, deve registrasi. Perché ? Ad esempio, se mi presento ad uno sportello della PA per eseguire una pratica, difficilmente mi viene richiesto di compilare un questionario informativo con tutti i miei dati. Purtroppo gli strumenti innovativi di autenticazione (CIE, CRS, CNS, …) sono molto efficaci per garantire l’identificazione dell’utente, ma non dicono praticamente nulla di quest’ultimo. Infatti CIE, CRS, CNS riportano pochissimi dati sul cittadino, in posizioni non standard e mutevoli nel tempo. Addirittura le primissime CIE non riportavano neppure il codice fiscale del cittadino. 11

Autenticazione: la registrazione dei dati (2) GRUPPO MAGGIOLI Segnalo alcuni tentativi volti ridurre il disagio della registrazione: • Portali Multi-ente che condividono lo stesso profilo di registrazione su più Enti: Citel, Cadi nella Rete, … • Portali Federati che si scambiano le credenziali degli utenti in modo trasparente: Ci. Tel-AIDA • PEOPLE delega l’autenticazione ad una Certification Authority esterna ed introduce il concetto di Identità Federata (ora estesa dal progetto ICAR) per la condivisione delle credenziali di un utente su più istanze People. Ogni utente è identificato dall’ID: Codice. Fiscale@Comune. Registrazione • I comune di Mantova offre il Pre-polamento degli utenti prelevando dall’anagrafe i dati dei cittadini residenti. 12

Colloquio con i Back. Office: architetture a confronto GRUPPO MAGGIOLI I dati acquisiti da un Portale devono essere inviati ad un sistema di Back. Office. Esistono vari modelli di colloquio: • utilizzo di un datawarehouse di replica: Mantova, Siscotel • utilizzo di Web. Service Sincroni: People, Ci. Tel, Cadi nella Rete • utilizzo di Posta Elettronica Certificata: People, Doc. Area, … In realtà queste modalità non sono in alternativa tra loro anche se l’utilizzo di Web. Service sincroni garantisce un livello di servizio migliore. 13

Colloquio con i Back. Office: la modellazione dei dati GRUPPO MAGGIOLI In ogni caso, se si esclude l’utilizzo di Data. Ware. House, è necessario condividere degli standard di modellazione dei dati per garantire l’interoperabilità tra sistemi: • in People la modellazione è partita dall’analisi delle entità ed ha definito in modo (fin troppo) rigoroso ogni attributo, compreso gli elenchi di toponomi, province, nazioni, ecc. • in Citel e Cadi. Nella. Rete il modello ha un taglio più applicativo e si limita ai dati essenziali alla gestione delle transazioni • in Comunas le struttura XML sono ancora più semplici e sono in supporto a servizi di sola consultazione Purtroppo oggi non esiste una standardizzazione di questi modelli; ciascun progetto di e-Gov adotta il proprio conseguente proliferazione delle interfacce e dei costi di gestione. 14

Open Source vs Open Standard GRUPPO MAGGIOLI Oggi c’è il pericolo di confondere l’ Open Source con l’Open Standard. Per favorire la cooperazione tra sistemi, è necessario condividere degli standard supportati da più piattaforme. Al contrario, è possibile utilizzare la tecnologia Open Source per sviluppare componenti che non favoriscono la cooperazione tra sistemi. Ad esempio il progetto Apulie prevede l’utilizzo di Web. Service e lo scambio di documenti XML (positivo). Purtroppo i meccanismi di encryption dei messaggi impone l’utilizzo di componenti Java sviluppati dallo stesso progetto. E’ estremamente difficile implementare questi tecniche di encryption con altre piattaforme di sviluppo: PHP, . NET, ecc. Questo significa per cooperare in questo progetto siamo obbligati a utilizzare strumenti e componenti imposti dal progetto stesso. 15

Accessibilità GRUPPO MAGGIOLI La legge Stanca impone numerosi vincoli (mutuati dalle specifiche W 3 C-WAI) per lo sviluppo dei portali WEB. Purtroppo l’utilizzo della Firma Digitale e degli strumenti di autenticazione moderni (CIE, CNS, CRS) è incompatibile con le specifiche di accessibilità. Non ci sono soluzioni: • o si modifica la legge • oppure, per utilizzare la FD, si creano Portali non accessibili. 16

Il modello di business dei progetti di e-government GRUPPO MAGGIOLI Noi produttori di SW sappiamo bene che il ciclo di vita di un oggetto SW non ha mai fine. Inoltre rispondiamo direttamente dei nostri prodotti cercando di essere interlocutori seri ed affidabili. Ne va della nostra esistenza. Tanto più un SW è utilizzato dagli utenti, tanto più questo richiede energie per lo sviluppo e la manutenzione. Purtroppo il modello di business di numerosi progetti di e -gov gestiti non ha seguito queste regole. In particolare la mancanza di risorse nel medio-lungo periodo mette in difficoltà la positiva evoluzione di questi progetti. Ovviamente manteniamo il desiderio di continuare a supportare gli Enti nello sviluppo di questi progetti. 17

GRUPPO MAGGIOLI … Grazie per l’attenzione. Marco Nanni m. nanni@cedaf. it 18