Intanto si tratta di web service. Occorre definire delle procedure informatiche che vengono esposte da un server e possono essere richiamate da altri server per assolvere, ad esempio, a dei compiti di interrogazione di database o dati. Quando i servizi on line intervengono nell'ambito della pubblica amministrazione devono rispettare degli standard particolari che sono quelli, appunto, delle porte di dominio. I singoli enti della pubblica amministrazione vengono definiti "domini" e la comunicazione avviene attraverso web services che dialogano scambiandosi pacchetti XML. Sono standard aperti, ormai consolidati e codificati secondo la cosiddetta "busta di e-government". Quando avviene uno scambio tra web services secondo queste procedure e standard, allora si parla di porte di dominio. Il lavoro che è stato fatto è stato essenzialmente quello di costruire una architettura distribuita che è la più adeguata a questo tipo di situazioni, simulare server differenti che si parlassero attraverso web services ed in grado di scambiarsi messaggi secondo la "busta di e-government" definita dall'AIPA. L'implementazione è quella di Oracle Italia che ha sviluppato una implementazione delle porte di dominio per web services specifica per gli standard italiani. Questa architettura utilizza delle librerie Java che consentono di impacchettare i messaggi scambiati tra i sistemi secondo lo standard della "busta di e-government".

Lo standard delle porte di dominio consente di applicare dei filtri sui messaggi che viaggiano in rete. Tra questi vi sono anche dei filtri di encryption che garantiscono che il messaggio viaggi sulla rete in maniera non decifrabile se non fra i server che dialogano tra loro. Il dialogo avviene infatti secondo il protocollo http standard, e cioè il protocollo internet. Questo è il primo livello che riguarda la sicurezza delle comunicazioni che viaggiano in rete. Un ulteriore livello riguarda il tipo dati che vengono scambiati tra le pubbliche amministrazioni. Il processo avviene più o meno così: quando un server richiede dei dati ad un altro server della pubblica amministrazione, il server che risponde non invia tutti i dati di cui è in possesso ma effettua già una elaborazione in base alla richiesta. Di fatto i dati che viaggiano - seppure in maniera sicura, criptati etc. - sono soltanto i dati effettivamente di interesse del richiedente, non c'è il rischio che circolino informazioni diverse da quelle richieste. Ad esempio: se io richiedo la scheda sanitaria di un cittadino, in rete non circolano le schede sanitarie di tutti i cittadini ed è il mio browser che filtra. Il filtro è a monte dal server che riceve la richiesta per cui non c'è il rischio che circolino dati anche sensibili.

Il problema è stato superato soltanto in parte. Certamente è difficile mettere d'accordo 45 amministrazioni, sicuramente abbiamo dovuto rinunciare all'ipotesi di una integrazione diretta con in vari sistemi perché la situazione è estremamente diversificata: ci sono comuni medio grandi con sistemi informativi evoluti, ma ci sono anche piccole realtà che utilizzano il foglio di calcolo come gestionale, magari residenti su macchine non collegate ad internet e quindi impossibilitati ad accedere ai dati. La soluzione che abbiamo scelto è stata di replicare i dati delle pubbliche amministrazioni coinvolte su un server centrale. La replica avviene tutti i giorni durante la notte, i server trasferiscono i propri dati secondo un tracciato XML che abbiamo definito noi sulla base di una preventiva analisi del tipo di dati da trattare. Abbiamo preso in esame tutti i gestionali dei 45 comuni, che sono sostanzialmente una decina di prodotti diversi poiché molti comuni sono serviti da uno stesso fornitore. Abbiamo quindi chiesto a questa decina di fornitori di adottare un tracciato di esportazione dei dati compatibile in modo da avere un formato dati univoco per i dati da inserire nel server. Analogamente da parte del server c'è un tracciato di esportazione dei dati verso i comuni. Una parte dei comuni coinvolti, quelli più grandi, nel progetto si è anche fatta carico di integrare le procedure all'interno del gestionale: qui non c'è una semplice esportazione dei dati, ma una interazione diretta con i gestionali che possono dialogare con il server centrale ed interrogare direttamente i nostri database invece di andare a prendere un tracciato XML.

Dobbiamo precisare che in questo caso noi ci rivolgiamo a dei cittadini particolari che sono degli operatori professionali, dei professionisti del settore: ingegneri, architetti, progettisti, geometri e così via. I servizi hanno due livelli di accessibilità: un livello pubblico e un livello "privato". Il livello pubblico consente a chiunque di fare una ricerca delle pratiche cosiddette pubbliche, cioè un accesso in sola consultazione sugli atti relativi alle pratiche edilizie che hanno una natura "pubblica". C'è invece un accesso privato che consente a chi ha inoltrato una pratica di vedere a che punto è. Si tratta di informazioni non ancora pubbliche perché la pratica può essere in una fase cosiddetta endoprocedimentale. Su questo livello di accesso non abbiamo ancora dati consolidati poiché siamo in una fase di sperimentazione, di test.

Occorre dire che questo è solo un primo passo verso le "pratiche on line" perché comunque sottomettere una pratica edilizia comporta la presentazione di numerosi moduli e documentazione. Noi abbiamo informatizzato e reso accessibile on line una parte, ma questo non può ancora esimere il professionista dal recarsi allo sportello. C'è infatti tutta una mole di documenti - pensiamo alle cartografie, ai progetti etc. - un metro cubo di carta che va consegnato! Noi ci occupiamo di una piccola parte di questo metro cubo. Comunque, per la parte informatizzata la cosa funziona così: il tecnico compila il modulo on line al quale viene assegnato un codice. Il modulo stampato deve essere consegnato allo sportello ma qui l'operatore può istruire la pratica richiamando la domanda con il codice, senza dover imputare di nuovo i dati. Così si evitano errori di imputazioni. Dal punto di vista dell'utente il vantaggio è che c'è una validazione a monte dei dati, pensiamo all'anagrafica delle vie etc. che viene proposta dal sistema stesso. Il professionista sceglie dall'elenco proposto la via o le vie che interessano l'intervento edilizio. Anche l'anagrafica delle imprese è già integrata nel sistema e quindi l'utente può selezionare l'impresa con tutti i dati relativi dall'elenco. Ci sono ancora tutta una serie di wizard, di procedure assistite che attraverso una serie di domande guidano l'utente all'individuazione del tipo di moduli che occorre compilare e presentare allo sportello, cosa e quanto bisogna pagare a seconda del tipo di intervento. Questa è una funzionalità che sicuramente va incontro alle esigenze del semplice cittadino piuttosto che del professionista.

Dobbiamo fare una distinzione tra i comuni che già gestiscono le pratiche in maniera informatizzata, Reggio Emilia, Correggio etc., e quelli che ancora non lo fanno. Reggio Emilia ad esempio gestisce tutto lo storico della pratica e quindi qui per l'utente è possibile ricostruire e verificare tutti i passaggi fino all'esito finale, compresi i pareri della commissione edilizia, verbali etc. Quindi una verifica dettagliata anche dei motivi per cui una pratica è stata eventualmente respinta. Per ragioni di privacy non sono consultabili le pratiche relative ad abusi edilizi. Per quelle ordinarie, invece, come abbiamo detto, la verifica dell'iter è ad accesso riservato al titolare della pratica. Ad oggi questo tipo di consultazione è possibile soltanto per i comuni che hanno informatizzato tutte le procedure del settore urbanistica/edilizia. Per le pratiche istruite presso altri comuni l'utente può comunque verificare lo stato attuale della pratica, eventualmente con i riferimenti ai pareri della commissione edilizia etc. ma non c'è la possibilità di ricostruire tutti i passaggi in maniera puntuale. Consideriamo che il percorso di una pratica edilizia può essere anche molto articolato.

Contiamo di avviare a breve in via sperimentale i servizi a valore aggiunto e cioè le famose "pratiche on line" con i limiti che abbiamo detto.

Ne parliamo con

Patrizia Alberti

Responsabile del portale Progett@re - Comune di Reggio Emilia

L'idea risale al 1999. All'epoca mi occupavo dell'URP del comune e, parlando con i dirigenti dei vari servizi per avere le informazioni necessarie ad aggiornare i database e le schede informative sui servizi del comune, è emersa l'esigenza da parte del dirigente del servizio urbanistica ed edilizia di trovare un modo per semplificare i rapporti con i professionisti del settore. Allora il settore urbanistico si lamentava del grande afflusso di utenti che intasavano letteralmente gli uffici con un andirivieni continuo per chiedere informazioni, documentazione, chiedere chiarimenti, recuperare la modulistica e così via. Stiamo parlando del 1999 quando non tutti avevano consapevolezza delle potenzialità di internet come mezzo di comunicazione, informazione e servizio. Noi avevamo già dal 1995 la rete civica e da qui la proposta di creare un luogo telematico dove mettere le informazioni - allora pensavamo ad una cosa piccola, con poche informazioni - a disposizione dei professionisti. Progett@re è nato come piccolissimo nucleo nell'ambito della rete civica per soddisfare le esigenze sia dei professionisti sia degli uffici. Successivamente abbiamo capito che oltre alle informazioni potevano essere erogati veri e propri servizi on line ma la cosa è andata in porto con l'avvio del Piano Telematico Provinciale. Abbiamo colto l'occasione per ampliare il progetto iniziale che si è trasformato nel portale provinciale rivolto a tutti i professionisti del territorio. Come comune abbiamo inserito il portale dell'edilizia nel Piano telematico provinciale insieme ad altri portali di servizio: per le scuole, per i pagamenti on line, etc. Certo inserendo il progetto nel piano telematico, insieme ad altri progetti, ha fatto allungare un po' i tempi. Ma da un altro punto di vista è stato un vantaggio poiché nel frattempo le tecnologie si sono evolute e quindi servizi impensabili ai tempi dell'idea iniziale, sono diventati fattibili. Oggi possiamo pensare ai servizi interattivi on line, che sono già pronti e saranno effettivamente fruibili tra un paio di mesi al massimo.

Non direi che ci sono state difficoltà insormontabili. L'entusiasmo iniziale si è mantenuto nel tempo anche se con molta fatica e molto dispendio delle nostre forze. Tenere insieme 45 comuni non è certo facile, ma insieme all'Azienda Lekton, che ha realizzato tecnicamente il portale e l'Azienda Certhidea che ci ha supportato nella gestione del progetto, abbiamo creduto sin dall'inizio alla necessità di mettere in piedi una redazione fortissima che fosse di supporto e sempre presente, che svolgesse due compiti essenziali: da una parte la ricerca documentale per l'implementazione dei contenuti informativi (banche dati, normative etc.) e, dall'altra - ed è la cosa su cui abbiamo puntato di più - la formazione. La redazione centrale ha curato la formazione dei tecnici di tutti i comuni coinvolti nel progetto affinché tutti i comuni fossero in grado di inserire autonomamente le informazioni sulle proprie procedure, modulistica etc. I tecnici devono sapere interagire con il portale per cui è stata fatta una formazione molto robusta con giornate d'aula seguite da una formazione capillare: i nostri redattori sono andati presso tutti i comuni, ad istruire ed affiancare, uno per uno, i referenti tecnici. Oggi c'è una persona sempre reperibile - un vero e proprio help desk - che interviene e va presso il comune in caso di problemi o difficoltà.
La formazione è fondamentale per tenere in vita i progetti: se non c'è una formazione continua il portale rischia di "morire".

Devo fare una premessa. Noi abbiamo coinvolto sin dall'inizio gli ordini professionali interessati: l'ordine degli ingegneri, degli architetti, dei geometri e così via. I rappresentanti degli ordini sono entrati nel gruppo di lavoro per studiare, per definire, per farci centrare perfettamente i servizi. Abbiamo adottato quella che si chiama progettazione partecipata. In pratica tutti i soggetti coinvolti hanno fatto parte di questo gruppo che rifletteva sui bisogni e decideva quali dovessero essere i contenuti del portale. Sin dall'inizio quindi abbiamo progettato servizi e contenuti che realmente rispondevano alle esigenze dei professionisti.

Per accedere ai servizi on line è necessaria una registrazione al portale. O meglio, nell'ambito del Piano telematico ci siamo orientati verso un'autenticazione unica per tutti i portali della pubblica amministrazione (single sign on) e cioè: chi si registra ad uno qualsiasi dei portali (scuole, pagamenti, biblioteche etc.) ottiene una chiave di accesso (PIN e Password) valida per tutti gli altri portali e servizi.

Oltre a quelli già fruibili sul portale, tra i servizi a valore aggiunto abbiamo: compilazione assistita e preinoltro telematico di pratiche edilizie (es: DIA, Permesso di costruire, agibilità…..) visualizzazione delle pratiche e il pagamento degli oneri. Nel portale abbiamo inserito anche una funzionalità di calcolo automatico: è sufficiente inserire alcuni parametri ed il sistema calcola l'importo dovuto che può essere pagato con carta di credito o con RID, (cioè bonifico on line). Certo, dobbiamo considerare che trattandosi di pratiche edilizie gli importi possono essere anche di una certa consistenza e non sappiamo se c'è già un sufficiente livello di fiducia nelle transazioni on line da parte degli utenti, da movimentare via internet somme di denaro ingenti. In ogni caso lo strumento c'è e funziona: pian piano gli utenti ne valuteranno l'affidabilità

La fase due è comunque concentrata sulla presentazione on line delle pratiche, un servizio previsto che però sarà solo in parte automatizzato. Per un certo periodo la pratica dovrà essere anche presentata in forma cartacea fino a quando la firma digitale non sarà capillarmente diffusa. Direi che il servizio sarà completamente automatizzato soltanto quando le applicazioni saranno fruibili a partire dalla cartografia on line.
Una ulteriore evoluzione del progetto potrebbe comportare la composizione assistita della "scheda di fabbricato", una peculiarità della Regione Emilia Romagna che richiede ai progettisti un unico documento contenente tutte le informazioni su progetto, impianti etc. Per i professionisti dover ricostruire il fascicolo a posteriori è un problema e potrebbero trarre beneficio da tale servizio on line.