1 Considerazioni di consuntivo su alcune esperienze di progetti di e-gov. Valutazioni sulle prospettive future con particolare riferimento ai temi dell’inter-operabilità.

Presentazione sul tema: "1 Considerazioni di consuntivo su alcune esperienze di progetti di e-gov. Valutazioni sulle prospettive future con particolare riferimento ai temi dell’inter-operabilità."— Transcript della presentazione:

1 1 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

2 GRUPPO MAGGIOLI 2 Agenda 1.Il Gruppo Maggioli – Posizionamento e Mission 2.L’accesso ai servizi OnLine – 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 eGov 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.

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

4 GRUPPO MAGGIOLI Sedi TECNICO/COMMERCIALI SETTORE INFORMATICA

5 GRUPPO MAGGIOLI 5 Il ruolo dell’informatica nel Gruppo 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à 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 sappiamo coniugare al livello più alto possibile conoscenza dei processi innovazione tecnologica

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

7 GRUPPO MAGGIOLI giugno 2005Cedaf7 Alcuni dei progetti realizzati Portali e Politiche di e-Government Progetto SUAP CadinellaRetecoordinatore: Comune di Carrara Progetto CiTelcoordinatore: Comune di Pisa Progetto People coordinatore Comune di Firenze Progetto POL-BASRegione Basilicata Altri progetti in cui siamo stati coinvolti Etna in Web coordinatore: Comune di Catania Teseocoordinatore: Comune di Verona e-Mantova coordinatore: Comune di Mantova Servizi OnLine del comune di Rimini Gestione Protocollo e Base Documentale Progetto DocArea (ex  )Provincia di Bologna Firma DigitaleProvincia di Firenze Progetto TeseoComune di Verona Protocollo InformaticoRegione Sicilia Interoperabilità Protocollo EntiRegione Toscana Interoperabilità Protocollo EntiRegione Emilia Romagna Area Socio-Assistenziale Sistema Socio Assistenziale MinoriRegione Emilia Romagna Progetto I Care: area Socio-AssistenzialeRegione Emilia Romagna

8 GRUPPO MAGGIOLI 8 Autenticazione: strumenti di identificazione 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.

9 GRUPPO MAGGIOLI 9 Autenticazione: Uso della firma digitale Normalmente qualsiasi servizio OnLine 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.

10 GRUPPO MAGGIOLI 10 Autenticazione: vincolo della piattaforma MS Windows 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: CryptoAPI – disponibili su windows 98 o succ. Crypto Service Provider – componente fornito dalle CA spesso solo per la piattaforma windows Servizi di accesso alle SmartCard - disponibile su windows 2000 o succ. Esistono alcuni tentativi interessanti per offrire soluzioni equivalenti per il mondo linux; es: OpenSignature. 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.

11 GRUPPO MAGGIOLI 11 Autenticazione: la registrazione degli utenti 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.

12 GRUPPO MAGGIOLI 12 Autenticazione: la registrazione dei dati (2) 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: CiTel-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: CodiceFiscale@ComuneRegistrazione I comune di Mantova offre il Pre-polamento degli utenti prelevando dall’anagrafe i dati dei cittadini residenti.

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

14 GRUPPO MAGGIOLI 14 Colloquio con i BackOffice: la modellazione dei dati In ogni caso, se si esclude l’utilizzo di DataWareHouse, è 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 CadiNellaRete 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 con conseguente proliferazione delle interfacce e dei costi di gestione.

15 GRUPPO MAGGIOLI 15 Open Source vs Open Standard 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 WebService 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.

16 GRUPPO MAGGIOLI 16 Accessibilità La legge Stanca impone numerosi vincoli (mutuati dalle specifiche W3C-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.

17 GRUPPO MAGGIOLI 17 Il modello di business dei progetti di e-government 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.

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