1 / 18

Agenda

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

dior
Download Presentation

Agenda

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. Agenda Il Gruppo Maggioli – Posizionamento e Mission L’accesso ai servizi OnLine – esperienze ed idee per facilitare l’accesso ai cittadini Il colloquio tra portale dei servizi e sistemi di back office: architettura e tecnologie a confronto Accessibilità 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. Le attività del Gruppo e l’ area informatica Processo di costituzione di un Polo informatico per la PA • Maggioli InformaticaSantarcangelo (Rn) • Studio K Reggio Emilia • Sipal Savigliano (CN) • Bit Cosenza • Cedaf Forlì • Elda Soft Treviso Oltre 30 mil. di fatturato Oltre 300 persone Oltre 3800 enti con almeno una licenza SW del Gruppo • 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

  4. Sedi TECNICO/COMMERCIALI SETTORE INFORMATICA

  5. Il ruolo dell’informatica nel Gruppo 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 coniugareal livello più alto possibile innovazionetecnologica conoscenza dei processi

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

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

  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Grazie per l’attenzione. Marco Nanni m.nanni@cedaf.it

More Related