Documento Analitico della Soluzione N SOLUZIONE 2. Comune di Pisa AMMINISTRAZIONE DI RIFERIMENTO:

Transcript

1 SOLUZIONE: N SOLUZIONE 2 PROGETTO: AMMINISTRAZIONE DI RIFERIMENTO: Ci-Tel Comune di Pisa 1

2 INDICE 1. DESCRIZIONE SINTETICA DELLA SOLUZIONE 3 2. DATI SINTETICI DELLA SOLUZIONE Obiettivi originari Elementi di contesto Parametri di riferimento Vincoli e prerequisiti Servizi 5 3. DATI ANALITICI DELLA COMPONENTE DI SERVIZIO FARE UN PAGAMENTO QUALSIASI CON BENEFICIARIO LA P.A. 6 Destinatari ed erogatori del servizio 6 Descrizione del Flusso 6 Dati per l erogazione del servizio 6 Livello di erogazione del servizio 6 Canali di erogazione del servizio PAGAMENTO CANONE LUCI VOTIVE 7 Destinatari ed erogatori del servizio 7 Descrizione del Flusso 7 Dati per l erogazione del servizio 7 Livello di erogazione del servizio 7 Canali di erogazione del servizio 7 4. DATI ANALITICI DELLA COMPONENTE TECNOLOGICA Caratteristiche sintetiche dell architettura tecnologica 8 Sistema di Riconoscimento Proprietà delle componenti Vincoli e prerequisiti tecnologici Modalità di gestione dell infrastruttura ICT Documentazione DATI ANALITICI DELLA COMPONENTE ORGANIZZATIVA (A CARICO DEL COMUNE) Il flusso organizzativo L impatto organizzativo ASPETTI DI COSTO RILEVANTI 16 2

3 7. DATI ACCESSORI DELLA SOLUZIONE Descrizione sintetica della soluzione La presente soluzione è composta da servizi che consentono alla Pubblica Amministrazione l incasso on-line dei tributi e la completa gestione delle problematiche legate a tale incasso. La soluzione è in grado di: Gestire diverse tipologie di incassi Erogare i servizi per tutti gli enti aderenti all iniziativa (Multi-ente) Essere utilizzato su canali di erogazione diversi (Multi-canale) Acquisire e perfezionare anche pagamenti richiesti da servizi operanti su altri portali L utilizzo della funzione di consultazione della propria Posizione Debitoria, per accedere ai pagamenti, necessita del riconoscimento certo e l accesso è consentito con tutte le credenziali di livello superiore, quali: - UserID e Password - C.I.E. - Carta di firma (Infocamere, Actalis) La soluzione prevede anche la funzione di visualizzazione dei Pregressi, pagamenti cioè già effettuati, sia dai canali tradizionali sia dal portale on-line. Anche per questo servizio il livello minimo di credenziali, per l accesso al servizio, è UserId- Password (rilasciate off-line), in quanto sono visualizzati i dettagli di pagamento. A livello organizzativo, l introduzione della soluzione di pagamento on-line dei tributi della P.A., richiede alcune attività propedeutiche all attivazione, quali la predisposizione degli applicativi di back-end alle fasi di carico e scarico dei dati e la definizione della modalità di trasmissione di tali flussi. In fase di esercizio invece, è necessario organizzare le fasi di contro-aggiornamento dei dati per poter mantenere sempre allineate le basi dati. E possibile anche prevedere, a livello di singola tipologia di tributi, l interazione on-line con le applicazioni di back-end; in questo caso il colloquio con il front-end avviene secondo il modello dei web services. Gli aspetti strettamente contabili legati all incasso, potranno coinvolgere sia i singoli dipartimenti interessati all incasso sia la ragioneria dell Ente, che dovrà essere allineata sulle modalità operative definite dall istituto di credito. Tali aspetti potranno essere definiti all atto della convenzione con il tesoriere, che renderà disponibile il sistema di pagamento on-line (esterno, appartenente al mondo bancario). Il riuso della soluzione è possibile utilizzando la piattaforma di servizi orizzontali (Framework di Base) che fornisce le funzioni di integrazione con il Sistema di Riconoscimento, previsto dal portale target, e con il Sistema di Pagamento stesso (esterno), BankPassWeb. 3

4 2. Dati sintetici della Soluzione 2.1. Obiettivi originari L obiettivo primario che ha indotto questa amministrazione ad implementare questa soluzione, è stato fornire alla cittadinanza e alle imprese un unica soluzione in grado di: - Gestire tutte le pendenze che il cittadino ha nei confronti dell amministrazione - Visualizzare i pagamenti già effettuati, anche da canali tradizionali - Fornire un infrastruttura abilitante al pagamento anche per servizi operanti su portali esterni La condizione che rende innovativa questa soluzione, sta proprio nell unicità del servizio. Infatti, non si è voluto implementare un semplice servizio di pagamento tributi, ma una vista globale della posizione debitoria dell utente nei confronti dell amministrazione, che permette di verificare le proprie pendenze, controllare le scadenze e pianificare i relativi pagamenti. Dal punto di vista dell amministrazione, si è voluto fornire uno strumento in grado di gestire tutte le fasi del pagamento: gestione commissioni, gestione modalità di inoltro quietanza liberatoria, gestione diverse tipologie di pagamento (Carta di Credito, RID on-line, Home Banking, ecc.), gestione flussi di rendicontazione e contabilizzazione. In tal modo si è progettata una soluzione in grado di rendere disponibile tale infrastruttura di pagamento anche a portali e/o servizi esterni Elementi di contesto La soluzione, per sua caratteristica implicita, non ha caratteristiche legate alla territorialità, pertanto si ritiene riusabile in ogni contesto territoriale e amministrativo Parametri di riferimento Durante la fase di stesura del progetto per ciascun servizio è stata realizzata un attività atta ad individuare la numerosità e la tipologia dell utenza coinvolta, vista l evidente propedeuticità rispetto le fasi successive. Soluzione Servizio telematico Categoria di utenti Numero di utenti nella categoria PAGAMENTI Fare un pagamento Al max tutti i cittadini maggiorenni luce votiva canone Al max tutti i cittadini maggiorenni Vincoli e prerequisiti Non si individuano particolari vincoli normativi all utilizzo della presente soluzione in altri contesti, in quanto la legislazione è in vigore sull intero territorio nazionale. L aspetto tecnologico presenta alcuni prerequisiti per la replicabilità della soluzione, sia di natura strettamente tecnologica sia di origine applicativa, dovuti ai seguenti elementi: - Piattaforma di middleware OSS - Integrazione sistema di pagamento (BankPassWeb) - Integrazione sistema di riconoscimento 4

5 - Interazione con le applicazioni di back-end (web services e/o flussi batch) Tali prerequisiti possono essere superati con attività di adattamento al contesto e/o personalizzazione, in particolare: - Piattaforma è possibile realizzare un porting verso altre piattaforme che supportino Java (Websphere IBM, Oracle, ecc.) - Sistema di pagamento (BankPassWeb) è possibile effettuare un attività di integrazione verso Sistemi di pagamento on-line, diversi da BankpassWeb se la tesoreria dell Ente acquisitore non dispone di tale Sistema di pagamento. - Sistema di Riconoscimento l identificazione dell utente che accede ai servizi è necessaria per poter fruire di alcune funzioni: i servizi interagiscono nativamente col sistema di riconoscimento di CiTel, componente comunque riusabile. E possibile in ogni caso realizzare una interfaccia apposita per integrare altri sistemi di riconoscimento (vedi Componente Tecnologica). - Interazione con le applicazioni di back-end è possibile riutilizzare l interfaccia di colloquio tra back-end e front-end, essendo realizzata attraverso web services e/o estrazione di flussi batch. Le applicazioni di back-end, presenti presso l amministrazione riutilizzatrice, devono supportare analoga tipologia di interfaccia e rispettare i contenuti informativi ivi previsti Servizi Nome del servizio Fare un pagamento qualsiasi con beneficiario la PA Pagamento canone luce votiva Breve descrizione Il servizio permette la gestione di diverse tipologie di incassi: spontanei, pre-calcolati, sanzioni amministrative. È prevista la funzione di visualizzazione dei pagamenti pregressi effettuati sia da canali tradizionali, che on-line È la funzione che permette il pagamento on-line del canone delle luci votive. Tabella 1: Servizi offerti dalla soluzione 5

6 3. Dati analitici della Componente di Servizio 3.1. FARE UN PAGAMENTO QUALSIASI CON BENEFICIARIO LA P.A. Destinatari ed erogatori del servizio I destinatari del servizio sono tutti i cittadini, residenti e non, e le imprese che abbiano pendenze con l amministrazione aderente all iniziativa. Il servizio è erogato integrando on-line (web services) o off-line (flusso bacth), le applicazioni di back-end con il front-end (Portale Operativo). Il riversamento dei pagamenti effettuati tramite il servizio, segue il tradizionale flusso operativo seguito dalle amministrazioni. Descrizione del Flusso La seguente figura illustra le interazioni applicative tra utente/front-end e back-end, relativamente alla funzione di pagamento. La prima immagine evidenzia le interazioni nel caso di un pagamento che non prevede integrazione con l applicazione di back-end, la seconda illustra la fase di visualizzazione della posizione debitoria (integrazione del back-end on-line e/o off-line) e la successiva fase di pagamento. Dati per l erogazione del servizio Nel primo caso, l utente, per procedere al pagamento, dovrà inserire, i dati identificativi del documento: Numero documento - Anno documento - Importo Il servizio non prevede interazione con l applicazione di back-end, consentendo l inserimento discrezionale dell importo da pagare. L applicazione consente, in modalità differita, l estrazione dei flussi contabili e di riallineamento degli archivi. Nel secondo caso, l utente, identificato tramite le credenziali in suo possesso, non dovrà inserire alcun dato, in quanto i dati relativi alla sua posizione debitoria vengono recuperati unicamente attraverso il suo codice fiscale, ricavato in fase di riconoscimento. Livello di erogazione del servizio Livello di erogazione del servizio = 4 Canali di erogazione del servizio WEB 6

7 3.2. PAGAMENTO CANONE LUCI VOTIVE Destinatari ed erogatori del servizio I destinatari del servizio sono tutti i cittadini, residenti e non residenti. Il servizio è erogato dall Ufficio Servizi Cimiteriali. L interazione fra l applicazione di back-end ed il front-end (Portale Operativo) avviene in tempo reale, tramite la tecnologia dei web services. Il riversamento dei pagamenti effettuati on-line segue il tradizionale flusso operativo seguito dalle amministrazioni. Descrizione del Flusso La seguente figura illustra le interazioni applicative tra utente/front-end e tra front-end/backend. Dati per l erogazione del servizio L utente, identificato con la tipologia di credenziali in suo possesso, se desidera effettuare il pagamento per un canone di cui è intestatario, non dovrà inserire nessuna informazione aggiuntiva. Nel caso in cui intenda effettuare un pagamento per un altro soggetto, dovrà inserire il codice fiscale del nuovo intestatario. Il servizio non prevede l inserimento discrezionale dell importo da pagare, ma visualizza quanto presente negli archivi dell amministrazione. Pertanto l utente che desidera procedere, potrà unicamente effettuare il pagamento dell intero importo del documento. Livello di erogazione del servizio Livello di erogazione del servizio = 4 Canali di erogazione del servizio WEB 7

8 4. Dati analitici della Componente Tecnologica 4.1. Caratteristiche sintetiche dell architettura tecnologica L architettura applicativa che permette l erogazione di servizi on-line è basata su di un sottosistema, detto Framework di Base, costituito da un insieme di componenti funzionali utilizzabili dai servizi applicativi e dalle applicazioni di gestione a disposizione degli operatori. I Servizi verticali realizzati, quindi, non costituiscono un software monolitico a sé stante, ma sono l insieme logico di tutti i servizi erogati, implementati ciascuno usufruendo delle funzionalità offerte dal sottosistema dei Servizi verticali. Le caratteristiche architetturali del Framework di base, assicurano ai servizi realizzati: - Integrabilità con tutte le applicazioni presenti nel Comune o in altri enti che sono coinvolte nell erogazione dei servizi. La soluzione prevede diversi meccanismi e modalità di integrazione (ML/SOAP, file transfer, ). - Adattabilità per adeguare facilmente la soluzione a diversi scenari di utilizzo ed a diversi ambienti operativi degli Enti. La piattaforma prevede nativamente l utilizzo da parte di un singolo Comune o di un centro servizi di un aggregazione di Comuni. - Multicanalità per l erogazione dei servizi agli utenti attraverso canali di accesso diversificati, in modo trasparente ai servizi stessi. La piattaforma nasce con il concetto di multicanalità presente in tutti i suoi componenti sia tecnologici sia funzionali. - Scalabilità per far fronte alla possibile crescita nel tempo del numero degli utenti, del numero dei servizi e del numero e dimensione degli Enti erogatori. La soluzione prevede sia una scalabilità applicativa, che permette di distribuire diversi componenti su macchine diverse, sia quella sistemistica che prevede di utilizzare strumenti di load balancing. Le funzioni applicative che il Framework di base fornisce supportano esigenze di carattere generale, quali: Tracciare l operatività dell utente nella fruizione dei servizi verticali Fornire ai servizi verticali funzioni standard, comuni a tutti, per la gestione dei LOG, delle operazioni di pagamento, ecc. Interfacciare, per conto dei servizi verticali ed in modo trasparente ad essi, i Sistemi di pagamento, i Sistemi di Sicurezza e Riconoscimento, i Sistemi di Protocollo, ecc. Assicurare la gestione delle configurazioni del sistema applicativo. ed esigenze dipendenti dalla tipologia di utente che accede al sistema, quali: Cittadini / Imprese: o Accedere ai dati riguardanti le proprie disposizioni e pagamenti o Accedere in modalità sicura alla visualizzazione dei propri dati riservati Operatori dell Ente o Amministrare i servizi di propria competenza Supervisori: o Amministrare i dati riguardanti i Servizi Applicativi o Amministrare i dati riguardanti il Sistema di Pagamento o Estrarre informazioni applicative, riguardanti l accesso ai servizi da parte degli utenti La seguente figura illustra l architettura tecnologica della soluzione e le interfacce tra i diversi componenti: 8

9 Le tipologie di interfacce evidenziate in figura sono di varia natura, ad esempio: Web Services (1), (2), java beans (3, 4, 5), HTTP/S (6). La piattaforma del Framework è basata su ambienti open source e tecnologie standard, sia per quanto riguarda gli ambienti di sviluppo/gestione (piattaforma J2SE/J2EE di SUN, framework Struts, AIS, interfacce standard ML/SOAP secondo il modello dei Web-Services, presentazione HTML 1.0 Transitional, conformità W3C/WAI, ecc.) sia dal punto di vista architetturale (Linux, Web server Apache, TOMCAT, DB Oracle, DB MySQL, ecc.). Le componenti architetturali del Framework di Base evidenziate, sono descritte nel seguito: Gestione Autenticazione Il componente si occupa di disaccoppiare i servizi e gli altri componenti del Framework dal Sistema di Riconoscimento specifico utilizzato, realizzando il coordinamento tra i vari componenti coinvolti durante la fase di autenticazione ed autorizzazione. Gestione Menù Il componente permette all applicazione di canale di ricavare i servizi disponibili all utente, in funzione del contesto di utilizzo. Il componente fornisce la lista dei servizi disponibili in funzione dell ente e del: livello delle credenziali presentate dall utente canale di accesso punto di accesso applicativo Gestione LOG Il componente permette la raccolta centralizzata di tutte le informazioni relative alle operazioni effettuate dagli utenti sul sistema; tali informazioni sono poi estraibili e visualizzabili secondo politiche diverse. Il componente fornisce le funzionalità per la gestione di diverse tipologie di dati: Dati generici Dati specifici del Servizio Dati di protocollo Dall'insieme dei LOG, sarà eventualmente possibile estrarre le informazioni necessarie a produrre report statistici riguardanti le attività inerenti i servizi basati sul Framework di Base del Sistema. Gestione Ordini e Disposizioni Il componente viene utilizzato dai servizi verticali ed interagisce direttamente, per i servizi che lo richiedono, con il componente Gestione Protocollo. Durante la fruizione del servizio raccoglie i dati, per i quali verrà mantenuta la congruenza, inserirendoli in una apposita struttura fino alla completa generazione della disposizione. Tali dati vengono anche riportati all interno del componente Gestione LOG per la registrazione. Gestione Pagamento 9

10 L esecuzione di una transazione di pagamento, si compone logicamente in due parti: gestione dell'ordine, sopra descritta, ed interazione con il sistema di pagamento, nella quale sono implementati i processi di integrazione previsti dal sistema stesso. Questa seconda parte realizza il disaccoppiamento tra l'ordine di Pagamento ed il sistema di pagamento messo a disposizione dall'istituto di Credito: si occupa quindi delle problematiche relative al completamento dell operazione che può avvenire in un unica fase o in fasi distinte (per carta di credito: autorizzazione e contabilizzazione in differita). Il componente provvede ad associare alle disposizioni di pagamento un identificativo univoco (es. num.autorizzazione), in modo che sia possibile in qualsiasi momento riconciliare lo stato interno del pagamento con quello del sistema bancario. La struttura del componente prevede, come evoluzione, la possibilità di gestire più sistemi di pagamento disponibili per un determinato servizio. Ad ogni sistema di pagamento potranno corrispondere una o più tipologie di pagamento (es. carta di credito, addebito in conto, RID), mentre ad una tipologia possono corrispondere uno una o più metodi (nel caso della carta di credito (tipologia), possiamo distinguere le sottotipologie VISA, American Express, ecc.). Nel caso di anomalie, come la mancata ricezione dell esito, si occupa di interrogare il sistema di pagamento entro un certo intervallo di tempo e di notificare l esito negativo in caso di mancata risposta, preoccupandosi poi di annullare l operazione o di generare un allarme applicativo nel caso l annullamento non sia attuabile. Gestione Notifiche Il componente di Gestione Notifiche permette di generare notifiche asincrone relative al servizio, via . Il contenuto della notifica si basa su template dotati di campi variabili per ogni singola istanza; i template e le liste di indirizzi corrispondenti a ciascuna tipologia di notifica sono preconfigurati, mentre i dati specifici dell evento sono passati a run-time. Gestione Sessione Il componente mantiene su database i dati collegati alle sessioni attive in un dato momento; tali dati sono creati e distrutti ad ogni sessione. Questo consente di registrare tutte le attività svolte dall utente tra un logon ed un logoff, identificando tutte le operazioni associate ad un identificativo di sessione. Sistema di Riconoscimento Il Sistema di Riconoscimento non è un componente integrato al servizio ed interviene per permettere l accesso al servizio stesso, sulla base delle credenziali presentate dall utente all atto della richiesta di logon al sistema. Le funzionalità svolte dal sistema di riconoscimento comprendono: Funzionalità di accesso al sistema Gestione di Account applicativi Tipologie multiple di credenziali Profilazione ed autorizzazione Gestione dell'anagrafica Riservatezza delle credenziali Gestione SSO (Single-Sign-On) Funzionalità di amministrazione del Sistema Rilascio credenziali UserID/Password Gestione delle credenziali Gestione dei profili operativi Gestione dell anagrafica Gestione Log Il Sistema di Riconoscimento implementa una architettura di Server di Autenticazione, realizzando una netta divisione di competenze tra l ambiente di erogazione dei servizi e quello di sicurezza. Questo consente di inserire, nel tempo, nuovi meccanismi di autenticazione coinvolgendo solamente il Server di Autenticazione ed inoltre di integrare con il Sistema di Riconoscimento applicazioni anche su portali e piattaforme differenti. 10

11 4.2. Proprietà delle componenti Componente Framework di base Sistema di Riconoscimento Integrazione sistema di pagamento Soluzione Proprietaria/Non proprietaria Proprietaria Proprietaria Proprietaria Proprietaria Altre indicazioni (ad esempio, fornitore ) 4.3. Vincoli e prerequisiti tecnologici L aspetto tecnologico presenta alcuni prerequisiti per la replicabilità della soluzione, sia di natura strettamente tecnologica sia di origine applicativa, dovuti ai seguenti elementi: - Piattaforma di middleware OSS - Integrazione sistema di pagamento (BankPassWeb) - Integrazione sistema di riconoscimento - Interazione con le applicazioni di back-end (web services e/o flussi batch) Tali prerequisiti possono essere superati con attività di adattamento al contesto e/o personalizzazione, in particolare: - Piattaforma è possibile realizzare un porting verso altre piattaforme che supportino Java (Websphere IBM, Oracle, ecc.) - Sistema di pagamento (BankPassWeb) è possibile effettuare un attività di integrazione verso Sistemi di pagamento on-line, diversi da BankpassWeb se la tesoreria dell Ente acquisitore non dispone di tale Sistema di pagamento. - Sistema di Riconoscimento l identificazione dell utente che accede ai servizi è necessaria per poter fruire di alcune funzioni: i servizi interagiscono nativamente col sistema di riconoscimento di CiTel, componente comunque riusabile. E possibile in ogni caso realizzare una interfaccia apposita per integrare altri sistemi di riconoscimento (vedi Componente Tecnologica). - Interazione con le applicazioni di back-end è possibile riutilizzare l interfaccia di colloquio tra back-end e front-end, essendo realizzata attraverso web services e/o estrazione di flussi batch. Le applicazioni di back-end, presenti presso l amministrazione riutilizzatrice, devono supportare analoga tipologia di interfaccia e rispettare i contenuti informativi ivi previsti Modalità di gestione dell infrastruttura ICT Il progetto prevede l adozione e l applicazione di una metodologia specifica per la valutazione degli impatti che la realizzazione del portale, e la sua successiva disponibilità operativa, produrrà sugli Uffici ed i Servizi coinvolti. La metodologia utilizzata è di seguito brevemente descritta, nei suoi passi salienti e nella sua contestualizzazione sul progetto. La Metodologia (in sintesi) 11

12 Preliminarmente all attività di analisi Costi/Benefici vengono identificati gli obiettivi dell intervento e gli Indicatori di Performance. Se ad esempio l obiettivo individuato sarà Aumentare l efficienza dovrà essere identificato l indicatore/i di performance collegato/i; in questo caso potrebbe essere: diminuzione del tempo di gestione di un dato tipo pratica e aumento del numero medio di pratiche gestite in un dato periodo temporale. La metodologia prevede l esecuzione di attività strutturate in fasi: La fase di Rilevazione della situazione esistente. La fase di gap analysis. La fase di disegno e simulazione. Particolare attenzione è stata posta all adeguamento dei parametri delle varie fasi alla realtà della Pubblica Amministrazione: ad esempio la valutazione dell output di una attività, non essendo misurabile direttamente in termini economici, dovrà tenere conto di altre caratteristiche in termini di efficienza/efficacia dell attività medesima (tempi di compimento delle attività, quantità/qualità delle risorse umane e tecnologiche coinvolte nel processo, volumi di output dell attività, ecc.). E stato poi elaborato un modello di business case che sintetizza i risultati in termini di efficienza che sono conseguenza dell intervento. La misurazione dei benefici attraverso questo modello può essere applicata particolarmente in realtà non business oriented, quali la PA. In questo caso i parametri di valutazione caratterizzanti sono: Il volume di output dell iniziativa in esame. Il volume di input, che è misurato dal numero di giorni uomo necessari a realizzare il volume di attività previsto per l iniziativa considerata. Il valore del capitale investito. Il costo del giorno uomo, che nel caso di iniziative legate al mondo PA può essere visto come il tempo di completamento della singola pratica. Il numero di giorni (in termini di elapsed) necessari a completare il singolo output dell iniziativa Nella situazione successiva all intervento, grazie all aumento di produttività derivante dall intervento stesso, le grandezze prima evidenziate che caratterizzano la situazione, assumono valori differenti. In via esemplificativa sono stati disegnati due differenti scenari: nel primo è stata variata la produttività dell ora di manodopera mantenendo costante il volume di output. nel secondo è stato cambiato il volume di output. Il modello è in grado pertanto di evidenziare in termini economici il cambiamento della situazione indicando: la variazione del volume di risorse impiegate e pertanto il relativo costo; la riduzione del capitale investito per ogni output e pertanto il relativo costo in termini di oneri finanziari. Il progetto è tuttora nella sua fase iniziale e l applicazione della metodologia non ha ancora prodotto risultati definitivi. I parametri principali ai quali si è deciso di assegnare la priorità più alta sono la Customer Satisfaction ed il miglioramento dei servizi. In ogni caso la realizzazione del progetto prevede effetti quali: Minore afflusso dei cittadini agli sportelli, Maggiore supporto informativo contestuale ai servizi, Minore quantità di documenti cartacei da gestire direttamente, Utilizzo preesistenti connessioni in larga banda per la gestione di linee sicure, Utilizzo di un solo sistema con software open source per ciascun Ente, Spostamento di tutte le funzioni trasversali ( riconoscimento, pagamenti generalizzati, file di log ) sul sistema di front office, 12

13 Spunte automatiche dei pagamenti, ecc. Quindi, per quanto riguarda l aspetto Riduzione dei costi i benefici attesi, su scala annuale, sono dei seguenti ordini di grandezza: Costi del personale -15% Costi del materiale (moduli, timbri, ecc.) -20% Costi apparecchiature hardware 10% Costi per software applicativi 20% Costi locali ed attrezzature (sportelli) 20% Connessioni in rete (accesso back-office remoti degli Enti tramite VPN ipsec) -20% 4.5. Documentazione Elencare la documentazione e manualistica messa a disposizione utilizzando la tabella seguente. Titolo documento DT_IncassiGeneralizzati.doc Tipologia documento Disegno tecnico Use case del servizio Breve descrizione Descrive il flusso del servizio Incassi Generalizzati, riportando le azioni che compie l utente per usufruire del servizio e le azioni che compie il sistema per erogare il servizio richiesto SR_IncassiGeneralizzati.doc Specifiche dei requisiti Analizza le funzioni previste dal servizio Incassi Generalizzati CheckList_IncassiGeneralizzati.doc Test case Check List dei test funzionali del servizio di Incassi Generalizzati PortaleCitel_IncassiGeneralizzati.ppt User interface Descrive l interfaccia utente del servizio 13

14 5. Dati analitici della Componente Organizzativa (a carico del comune) 5.1. Il flusso organizzativo Il processo di pagamento completato tramite il portale prevede un interazione sia con ambienti tecnico-organizzativi interni alla struttura comunale, sia con ambienti esterni, quali l istituto bancario che mette a disposizione il sistema di pagamento on-line. Il seguente diagramma di flusso sintetizza le interazioni tra l utente, che rappresenta il cittadino che utilizza il portale, il sistema, che comprende la struttura applicativa coinvolta nella richiesta, e il sistema di pagamento, ambiente esterno al portale, su cui viene effettuata la transazione di pagamento L impatto organizzativo L introduzione del progetto presso gli Enti aderenti ha richiesto una serie di confronti tra i vari Comuni, in cui sono stati coinvolti i livelli dirigenziale e operativo. Nel corso di tali riunioni sono stati illustrate le nuove tecnologie introdotte dal progetto e l impatto organizzativo che le producono. Tali incontri con un più elevato tasso tecnico sono stati organizzati sia con i responsabili degli Enti che partecipano all analisi sia quelli che partecipano al riuso del progetto. Nel Comune di Pisa, in parallelo, sono stati inoltre organizzati numerosi incontri formativi rivolti soprattutto ai cambiamenti organizzativi necessari come ad esempio decine di corsi sull introduzione del flusso documentale e della firma digitale, attività propedeutiche alla realizzazione del progetto CiTel. Il completamento dell analisi delle diverse soluzioni ha visto coinvolti, per ciascuno dei sette Comuni della rete Civica Unitaria di Pisa, i responsabili dei servizi previsti. In pratica sono stati coinvolti tutti i referenti dei Servizi/Uffici: Tributi, sistemi informativi, Ufficio Relazione con il Pubblico, Istruzione, Edilizia Privata, Polizia Municipale, Edilizia Pubblica e Privata e altri trasversali al progetto. 14

15 Tale coinvolgimento è stato indispensabile per la fase di analisi che in questo modo è stata effettuata da tutti gli Enti coinvolti. Diverso è l impatto in nuovi Enti dove è necessario solo effettuare le verifiche e le personalizzazioni in conformità a diversi front office nel caso di particolari specificità. Nella tabella seguente sono riportate le principali criticità espresse in quattro livelli di problematicità (nessuno, basso, medio, elevato). Nodo critico Sostegno politico al progetto Livello di problematicità Nessuno Basso Medio Elevato Definizione degli obiettivi del progetto Definizione delle responsabilità Coordinamento tra le unità organizzative Coordinamento con i consulenti Coordinamento con altre amministrazioni pubbliche Incentivi legati agli obiettivi del progetto Problemi nella fase di progettazione Conflittualità interna Specifiche competenze interne Risorse logistiche e tecniche Risorse economico-finanziarie Coinvolgimento del personale Circolazione di dati ed informazioni I cambiamenti Le variazioni principali cui l ente è stato indotto dall introduzione del progetto sono, sinteticamente i seguenti: Competenze specialistiche del personale Diverso modello di organizzazione del lavoro La razionalizzazione/semplificazione di procedure amministrative Un diverso clima organizzativo /una modifica della cultura dominante Nuovi modelli di rapporti di collaborazione con altre amministrazioni e/o con soggetti privati 15

16 6. Aspetti di costo rilevanti I costi sostenuti dall amministrazione per la realizzazione della presente soluzione sono i seguenti: Software Consulenza Esercizio Costi interni Per un costo complessivo pari a La soluzione, come precedentemente esposto, si basa su una piattaforma orizzontale comune a tutti i servizi applicativi e utilizza un sistema di riconoscimento, il cui costo globale per tutto il progetto è rispettivamente: FRAMEWORK Software di base Software Consulenza Costi interni Per un costo complessivo pari a SISTEMA DI RICONOSCIMENTO Software Consulenza Costi interni Per un costo complessivo pari a I valori indicati rappresentano i costi globali per lo sviluppo della soluzione sostenuti dall amministrazione, comprensivi quindi dell analisi organizzativa e funzionale. Il costo del progetto di riuso verrà valutato sulla base delle attività di adeguamento e messa in opera, e dipenderà dalle caratteristiche e dimensioni dell ambiente obiettivo dell intervento di riuso. 16

17 7. Dati accessori della soluzione Titolo documento AS_Architettura.doc Tipologia e breve descrizione del documento Analisi funzionale dell architettura tecnologica Fase del processo di sviluppo 1 ANALISI Architettura_Applicativa.doc Architettura applicativa ANALISI Architettura_Fisica.ppt Architettura fisica (HW e SW) PROGETTAZIONE DT_Framework_di_Base.doc Disegno tecnico PROGETTAZIONE SR_UserInterface_ doc Linee guida User Interface Per accessibilità e usabilità (W3C-WAI) PROGETTAZIONE 1 Indicare a quale fase del ciclo di sviluppo della soluzione si riferisce il documento: ANALISI, PROGETTAZIONE, SVILUPPO, ESERCIZIO 17