Progetto Esecutivo Back office sistema di gestione pratiche Edilizia/Ambiente
Progetto Esecutivo
Back office sistema di gestione pratiche Edilizia/Ambiente
Questo documento è redatto in ottemperanza a quanto previsto agli art. 7 e 8 del Contratto Quadro Consip e costituisce la risposta al Piano dei Fabbisogni redatto dall’Ente.
Indice
1 PRESENTAZIONE DELL’OFFERENTE 3
4.1 METODOLOGIA DI CONDUZIONE DEL PROGETTO 6
4.2 L’ARCHITETTURA TECNOLOGICA DELLA SOLUZIONE 6
4.2.2 Business Process Management e il motore di regole 9
4.3 ARTICOLAZIONE DEI SERVIZI 12
4.3.1 Servizi di Sviluppo Software 12
4.3.1.1 Analisi, progettazione e realizzazione software ad hoc 12
4.3.1.2 Manutenzione evolutiva 12
4.3.1.3 Servizi di Migrazione di sistemi 13
4.3.2 Servizi di Gestione, Manutenzione e Assistenza 13
4.3.3 Servizi di Supporto Organizzativo 14
5.1 CRONOPROGRAMMA DI MASSIMA DEI SERVIZI INERENTI IL NUOVO SISTEMA 15
6 ORGANIZZAZIONE DI PROGETTO 16
6.2 MODALITÀ DI GOVERNO DEL PROGETTO 17
7 DIMENSIONAMENTO E BUDGET ECONOMICO 18
7.1 MIX DEI SERVIZI PROPOSTI E MIX DELLE FIGURE PROFESSIONALI 18
7.2 QUADRO ECONOMICO DI RIFERIMENTO 19
1 PRESENTAZIONE DELL’OFFERENTE
Il Raggruppamento Temporaneo di Imprese (RTI) composto dalle società Engineering Ingegneria Informatica (Engineering), Municipia, Engiweb Security, PricewaterhouseCoopers Advisory (PwC), NTT DATA Italia (NTT), SQS Italia (SQS) è risultato aggiudicatario del Contratto Quadro Consip avente ad oggetto “Servizi in ambito sistemi gestionali integrati per le Pubbliche Amministrazioni”, per i Lotti 2 e 3, con destinatarie tutte le pubbliche amministrazioni locali.
Il Raggruppamento è stato selezionato per rispondere nel modo più idoneo alle finalità della presente iniziativa, con riferimento sia agli obiettivi generali sia alle specifiche istanze del Comune di Firenze e in ottemperanza con quanto previsto nel perimetro del Lotto 3.
In particolare, il suddetto Raggruppamento è formato da imprese che si distinguono per le seguenti caratteristiche:
• leadership all’interno della Pubblica Amministrazione;
• omogeneità dimensionale ed elevata complementarietà di competenze e specializzazioni;
• completa comunanza di valori coerenti con le finalità dell’iniziativa;
• disponibilità di infrastrutture e competenze di supporto negli ambiti operativi di riferimento;
• presenza consolidata a livello nazionale e internazionale che consente un accesso a know how distintivo e partnership di massimo livello con gli esponenti più qualificati del settore e dell’offerta ICT.
Le aziende della compagine per la specifica iniziativa in favore del Comune di Firenze sono:
• Municipia è un’azienda di servizi di outsourcing impegnata nell’ambito dei processi delle attività strategiche degli Enti Locali e delle loro aziende partecipate tra cui gestione delle entrate, servizi di mobilità urbana, raccolta e trasporto dei rifiuti urbani, urbanistica, servizi sociali, patrimonio, sicurezza. Municipia partecipa attivamente alla vita del Paese rendendo più efficienti, trasparenti e competitive le Città e le loro forme associative di ogni dimensione e caratteristica. Municipia ha la capacità di saperci adeguare con dinamicità e flessibilità ai bisogni e alle dimensioni di ogni tipologia di Comune, dal più piccolo e fino al grande Ente, rispondendo in modo specifico alle varie caratteristiche ed esigenze che li distinguono. Uno sguardo attento è rivolto ai cittadini e alle imprese che oggi non sono solo portatori di bisogni ma anche di soluzioni e stanno contribuendo sempre di più all’allargamento dell’arena decisionale della vita comune.
• PwC, fa parte del network internazionale presente in 158 Paesi che detiene il primato mondiale nei servizi professionali di revisione e consulenza. In Italia il network PwC conta circa 3.400 dipendenti (di cui oltre 1000 in PwC Advisory), dislocati in 21 sedi presso le principali città, che sono in grado di assicurare un presidio di assistenza continuativa sull’intero territorio nazionale. PwC è uno dei partner strategici della PA italiana, dall’advisoring direzionale ai servizi specialistici di BPM/revisione dei processi e di assessment organizzativo-tecnologico. In particolare, ha maturato significative esperienze di digitalizzazione di servizi nella P.A. Locale..
2 INTRODUZIONE
Il presente documento rappresenta il Progetto esecutivo in risposta al Piano dei fabbisogni elaborato dal Comune di Firenze, trasmesso in data 18 dicembre 2017 (Rif: 2017/395064), finalizzato ad attivare i servizi previsti dal Contratto Quadro Consip – Sistemi Gestionali Integrati (SGI), Lotto 3 – per il progetto di
realizzazione del back office per la gestione delle pratiche dello sportello dell’Edilizia e Ambiente.
3 OBIETTIVI DEL PROGETTO
Lo Sportello Unico Edilizia (SUE) è lo strumento istituito D.P.R. 6 giugno 2001 n. 380 (Testo unico dell’Edilizia) che consente di presentare e gestire telematicamente - in modo semplice, veloce e sicuro - tutte le pratiche legate all'edilizia residenziale. Il SUE è l’unico punto di accesso territoriale consentito e il riferimento per architetti, ingegneri, geometri e privati cittadini: riceve e gestisce infatti tutte le domande, dichiarazioni, segnalazioni o comunicazioni inerenti Segnalazioni Certificate di Inizio Attività, Comunicazioni di Inizio Lavori, Permessi di Costruire e ogni altro atto di assenso in materia di attività edilizia.
Nell’ambito del PON Metro Asse 1 Agenda Digitale Firenze, in particolare con il progetto FI1.1.1.a Piattaforma Edilizia e Ambiente il Comune di Firenze intende promuovere un processo di dematerializzazione e semplificazione dei propri rapporti con professionisti e cittadini nell’ambito edilizia e ambiente.
In questo contesto l’oggetto dell’intervento, complementare alla fornitura della Piattaforma Edilizia e Ambiente FrontEnd, con la quale si realizzeranno servizi online e app per i professionisti, prevede la reingegnerizzazione e l’evoluzione dell’attuale sistema di gestione del back office delle pratiche edilizie gestite dalla Direzione Urbanistica e dalla Direzione Ambiente (per i procedimenti attinenti le caratteristiche energetiche e degli impianti) per il Comune di Firenze garantendo una stretta integrazione con la componente Frontend.
In risposta alle esigenze manifestate dal Comune di Firenze, con la presentazione del Progetto Esecutivo il Raggruppamento si propone di fornire all’Ente elevate professionalità che siano in grado di supportarlo verso la modernizzazione e la standardizzazione tecnologica sviluppando un sistema gestionale che sarà lo strumento di:
− Ottimizzazione dei flussi procedimentali e documentali e di comunicazione con l’utenza, connessi al
disbrigo delle diverse pratiche e istanze depositate.
− Facilitazione dei processi di verifica tecnica di legittimità urbanistico-edilizia, di riscontro su banca dati e di osservatorio e monitoraggio degli interventi edilizi e dell’attività di controllo e repressione dell’abusivismo.
− Orchestrazione dei flussi e garanzia della qualità dei dati e della loro fruibilità pubblica.
4 SOLUZIONE PROPOSTA
4.1 METODOLOGIA DI CONDUZIONE DEL PROGETTO
La metodologia proposta si basa sulle migliori pratiche internazionali (PMI, PMP, Prince2® , COBIT) ed è stata applicata con successo in contesti similari per numerosità ed eterogeneità dei servizi erogati e attività svolte. La soluzione è distintiva in termini di:
− approccio metodologico suddiviso in rigorose fasi sequenziali che prevedono una continua interazione con i processi di lavoro e con le strutture organizzative del Comune di Firenze . La pianificazione è infatti un processo iterativo che richiede una costante revisione per assecondare le esigenze identificate in sede di Demand Management;
− strumenti e tecnologie distintivi per la gestione operativa dei progetti (PMO).
La prima fase, da realizzarsi immediatamente dopo la sottoscrizione del Contratto Esecutivo, prevede la declinazione delle principali regole di conduzione dell’intera Fornitura sulla base dell’analisi di numerosi input interni (es. primi evidenze dell’attività di Demand Management). Il fornitore redigerà in particolare il Piano della Qualità per garantire uniformità di approccio, coerenza metodologica, chiarezza dei contenuti e rispetto in particolare della norma ISO 9001:2015.
La seconda fase è costituita dalla redazione del Piano di Lavoro Generale (Masterplan di progetto) mediante la scomposizione del progetto in attività di dettaglio e relativa articolazione organizzativa in WBS. Il Master Plan sarà costituito da un documento principale e da un serie di documenti allegati a supporto dell’attività di pianificazione (es. descrizione d’ambito dei singoli servizi (sviluppo software, gestione, manutenzione e assistenza e supporto organizzativo) e dei relativi sotto-servizi. Il Masterplan potrà rimandare ad ulteriori piani di dettaglio, predisposti per coprire specifiche esigenze operative (migrazione, formazione, go-live, ecc.).
Il Master Plan ed i Piani a supporto conterranno tutte le informazioni di dettaglio (dalla tipologia di servizio, alle risorse da impiegare per la realizzazione delle singole attività, fino alle singole milestone necessarie per valutare l’avanzamento fisico del programma/progetto). Tutti i documenti di questa fase saranno presentati ai referenti del comune di Firenze per approvazione. L’organizzazione strutturata dei documenti e delle informazioni in essi contenuti consentirà al RTI di definire il quadro complessivo della programmazione operativa per poi indirizzare le successive fasi di analisi, valutazione e controllo dello stato di avanzamento delle attività e degli obiettivi ad esse sottesi. Il RTI a tal riguardo prevede di realizzare periodici incontri di verifica dello stato avanzamento lavori (con cadenza mensile) nell’ambito dei quali valutare in particolare eventuali criticità e le più opportune soluzioni, monitorando attentamente il rispetto delle tempistiche predefinite e il conseguimento delle milestone concordate in sede di pianificazione.
Il RTI, di concerto con i referenti comunali, procederà alla determinazione delle regole di aggiornamento e revisione dei Piani realizzati nelle fasi precedenti (es. frequenza, modalità e responsabilità di aggiornamento, eventuali processi di escalation, ecc.) allo scopo di avere un “modus operandi” standardizzato, univoco e confrontabile. Saranno inoltre definite le dimensioni di governo (es.: standard e template documentali), nonché le modalità di controllo e rendicontazione delle attività. La definizione e la misurazione dello stato di avanzamento delle attività pianificate, sarà valutata attraverso un modello di controllo basato su l’individuazione di specifici indicatori di performance (KPI) per il governo dell’intera Fornitura.
4.2 L’ARCHITETTURA TECNOLOGICA DELLA SOLUZIONE
La soluzione tecnologica prende spunto dall’esperienza in tema di dematerializzazione dei procedimenti amministrativi. L’utente, in tutte le sue accezioni, ha conquistato un ruolo sempre più importante nei progetti IT. Le nuove generazioni dei sistemi informativi non sono più realizzate “per gli utenti” bensì “con gli utenti”. Pertanto il sistema proposto si basa sulle tecnologie più avanzate e ne coglie tutte le potenzialità per metterle al servizio della user experience.
Questo approccio si concretizza in due caratteristiche del sistema:
• la scrivania virtuale dell’operatore, che consiste in una modalità di gestione dei contenuti e di organizzazione delle attività in grado di rispondere alle individuali, specifiche e mutevoli esigenze di accesso e fruizione delle diverse sezioni previste;
• la presenza di una interfaccia di accesso al sistema univoca, individuale e personalizzabile; la modalità di presentazione e navigazione delle risorse (processi, schede e documenti) riproduce i modelli di interazione con cui gli utenti hanno maggiore familiarità e gradimento.
In un approccio di questo tipo riveste un ruolo fondamentale l’adozione di un modello di riferimento e di una
architettura di integrazione.
La convergenza di innumerevoli tecnologie di comunicazione ed informazione sta determinando l'opportunità di organizzare tali tecnologie in relazioni tra servizi configurando, di fatto, nuovi paradigmi nella progettazione dei sistemi IT. Sistemi così concepiti, se opportunamente strutturati, possono creare valore aggiunto in quanto inclusivi di entità quali processi, persone, linguaggi, leggi, regolamenti, metriche e modelli.
L’architettura del sistema è nativamente orientata ai servizi essendo costituita da un insieme di componenti che si integrano e lavorano in maniera complementare proprio attraverso l’utilizzo di web services in tecnologia RESTful/SOAP.
Il punto unico di accesso del nuovo sistema di back-office è l’Access Portal realizzato attraverso la piattaforma DXP open source Entando (xxxxx://xxx.xxxxxxx.xxx/). Questo elemento architetturale, certificato Agid - Web Toolkit, consegna all’Amministrazione anche un potente CMS basato sull’iniziativa di una community attraverso la quale beneficiare, con un semplice upgrade del sistema, di futuri rilasci con nuove funzionalità.
L’Access Portal rappresenterà la Scrivania Virtuale dell’Operatore intesa come il raccoglitore di tutte le
informazioni relative ai servizi garantiti dal nuovo sistema tra cui:
• ultime pratiche ricevute in fase di acquisizione (con accesso all’elenco completo)
• elenco dei task del workflow da svolgere (sezione Le Mie Attività)
• scadenzario (es. termini procedimento, integrazioni, conformità etc.)
• notifiche del sottosistema di BPM (es. ricezione documentazione su pratica in lavorazione)
• dashboard di monitoraggio (es. pratiche in istruttoria, da integrare, tempi di lavorazione etc.)
• Tutti i dati disponibili saranno accessibili in modalità profilo secondo il ruolo dell’utente collegato e la
struttura di appartenenza (criteri di visibilità sui dati).
Il riconoscimento dell’utente viene demandato all’Identity and Access Management (IAM) dell’Amministrazione di appartenenza.
Per questo motivo, con funzioni di bridge, verrà introdotto Keycloak che garantirà sia i servizi di autenticazione che di single sign on.
Il nuovo sistema di gestione delle pratiche telematiche, profilerà l’utente secondo le specifiche fornite in fase di progettazione tecnica. Pertanto, anche l’accesso alla console di amministrazione del sistema avverrà sempre attraverso l’Access Portal.
Il nuovo sistema di back-office viene progettato per essere multi ente ovvero fruibile da amministrazioni diverse. Ogni organizzazione potrà personalizzare alcuni elementi distintivi come ad esempio l’identità visiva con il logo dell’ente, la denominazione etc.
Sulla base della configurazione che verrà impostata, ogni ente potrà decidere quali funzionalità esporre ai propri operatori, secondo i ruoli che verranno definiti.
Il nuovo sistema GesPRA è caratterizzato da un’architettura basata su JEE a 3 livelli, implementati da tecnologie e framework open source, costituiti da: Presentation Layer, Business Layer e Data Layer.
La componente di presentation è utilizzata nell’ambito della console di amministrazione e nell’integrazione di activiti per l’esecuzione degli human task, previsti dai vari workflow, e dell’audit per i dati di lavorazione (storico lavorazione pratica).
Soddisfa il pattern MVC e intercepting filter tramite Struts 2, lo strato di VIEW è realizzato con l’utilizzo di Tiles
3.0 e JSP. Le librerie javascript, all’occorrenza utilizzate, sono: AngularJS, JQuery 2.3 e JQuery UI 1.11.
L’integrazione nativa tra Struts 2 e Spring (nella versione 4.2.6) consente di sfruttare la “dependency injection” nella creazione delle Action con le relative dipendenze (ad. Es. riferimento ai service façade del business layer).
Per tutte quelle funzionalità che prevedono la navigazione di più pagine web, i dati da conservare sono gestiti tramite una “Conversation”. Questa soluzione consente di mantenere in sessione i dati limitatamente allo svolgimento della funzionalità che li richiede. Il layout grafico è basato su Bootstrap CSS.
Principalmente realizzato mediante utilizzo di EJB 3.1 e con l’adozione dei seguenti pattern:
• Service Façade
• Application Service
• Business Object
I service façade realizzati tramite EJB 3.1 vengono esposti attraverso Delegate.
L’interfacciamento di web service (esposti da altri sistemi) avviene con l’utilizzo di JAX-WS.
La persistenza delle informazioni avviene attraverso l’implementazione JPA 2.0 fornita dal provider Hibernate
4.2. Il RDBMS implementato sarà indicato in fase iniziale di progetto dal Comune di Firenze.
4.2.2 Business Process Management e il motore di regole
Il motore di workflow, che gestisce i flussi di lavorazione delle pratiche e quelle autorizzativi per l’invio delle
comunicazioni, è realizzato mediante ACTIVITI.
Activiti mette a disposizione una web application che consente di modellare in maniera visuale i flussi di lavorazione richiamati dalle varie procedure, a cui fanno riferimento i tipi pratica gestiti nel sistema. La console, di facile utilizzo, tramite la notazione in BPMN 2 permette quindi di definire workflow con la possibilità di richiamare anche logiche applicative di business ovvero componenti custom che, ad esempio, consento l’accesso alla banca dati piuttosto che l’invocazione di web service, invii di comunicazioni con template ad hoc etc.
Di seguito un esempio delle console:
I workflow saranno instanziati dal business layer a seconda del canale di ricezione quindi potranno essere:
• procedimenti telematici acquisiti attraverso lo sportello PEA
• endoprocedimenti acquisiti attraverso l’integrazione con il SUAP (SIGEPRO)
Il motore di regole è il sotto-sistema con cui vengono gestite, tramite regole di business (business rules), le
azioni e le valutazioni da abilitare in seguito all’analisi continua della base di conoscenza. Questa è ricavata da:
• l’insieme delle informazioni dichiarate nel singolo procedimento;
• le regole normative e amministrative
Entrambi i componenti BRM e BPM possono associarsi l’uno all’altro ovvero le regole definite possono
incidere sul flusso di lavoro.
Di seguito un esempio di flusso di lavorazione automatizzato per la gestione del procedimento ordinario (regime amministrativo autorizzativo):
L’architettura del sistema proposto prevede uno layer per l’interoperabilità o cooperazione applicativa con altri sistemi sia interni che esterni. Consentirà di dialogare, a seconda del caso, secondo i principali standard tra i quali:
• SPCoop
• REST/JSON
• REST/XML
• SOAP/XML
• CMIS e API REST per Alfresco
Il bus d’integrazione servirà anche al dialogo tra la componente di back-office web ed il core del sistema.
Il nuovo sistema di back-office viene progettato per essere nativamente integrato con lo Sportello Telematico PEA che rappresenta il front-end.
Il nuovo GesPRA metterà a disposizione dello sportello PEA una serie di servizi che serviranno a fornire
all’utente tutte le informazioni necessarie circa le pratiche telematiche presentate, tra cui:
• elenco pratiche per stato (in acquisizione/in istruttoria/in integrazione/evasa etc.)
• dettaglio pratica
• elenco comunicazioni per stato (lette/non lette)
• dettaglio comunicazione con allegati
Si riporta di seguito il caso d’uso proposto per la gestione dell’integrazione con lo Sportello PEA
Verrà implementato un modulo per l’apposizione della firma digitale dei documenti gestiti all’interno dei workflow. La realizzazione consentirà di firmare i documenti attraverso l’utilizzo di un certificato di firma presente su CNS o token usb.
Inoltre, la soluzione proposta prevederà l’integrazione con modalità di firma remota attraverso l’implementazione dell’infrastruttura che l’amministrazione comunale intenderà utilizzare. Attualmente il Comune di Firenze sperimenta la soluzione basata sul sistema ARSS – Aruba Remote Signing.
4.2.4 Repository sorgenti
I codici sorgenti saranno resi disponibili e aggiornati in un'apposita area del server GIT che sarà reso disponibile del Comune di Firenze
Per la realizzazione delle attività progettuali si ritiene necessario l’attivazione dei seguenti servizi tra quelli presenti nell’Accordo Quadro Consip. Nello specifico si intendono attivare i servizi di:
4.3.1 Servizi di Sviluppo Software
4.3.1.1 Analisi, progettazione e realizzazione software ad hoc
• Disegnare e progettare nel dettaglio le singole funzionalità del sistema e/o aggiuntive, anche attraverso la produzione di prototipi;
• Utilizzare le specifiche regole di codifica, manutenzione e riusabilità del software in oggetto o, se necessario, definire dapprima le regole e poi procedere con la codifica;
• Dettagliare la lista di funzionalità standard da realizzare;
• Dettagliare i requisiti funzionali espressi dall’Amministrazione contraente;
• Dettagliare la lista di funzionalità ritenute necessarie per supportare il processo in esame;
• Sviluppare nelle logiche e regole di codifica del pacchetto stesso che ne garantiscano la migliore e più agevole manutenzione, nonché successivo riuso da parte dell’Amministrazione committente o altra Amministrazione terza;
• Garantire la compatibilità con il release/livello effettivo degli ambienti di collaudo/esercizio attivi al momento in cui il software sarà utilizzato;
• Predisporre e mantenere costantemente adeguati i propri ambienti di sviluppo e testing alle configurazioni degli ambienti dell’Amministrazione, per prevenire e minimizzare eventuali criticità derivanti da disallineamenti tra gli ambienti del RTI e quelli target;
• Effettuare il servizio di garanzia del software sviluppato, per la correzione di eventuali bug e malfunzionamenti o difformità di funzionamento rispetto a quanto espresso nei requisiti, da intendersi comprensivo dei test di non regressione rispetto alle funzionalità preesistenti lo sviluppo specifico che ha generato il bug/malfunzionamento;
• Fornire assistenza finalizzata all’avvio in esercizio delle applicazioni realizzate;
• Garantire la realizzazione e/o l’aggiornamento della baseline applicativa attraverso la produzione di
misure, materiale e documentazione;
• Produrre tutta la documentazione tecnica prevista ed utile alla manutenzione tecnico-applicativa del nuovo software rilasciato.
4.3.1.2 Manutenzione evolutiva
• Dettagliare i requisiti funzionali di evoluzione, espressi dall’Amministrazione contraente;
• Effettuare sviluppi di nuove funzionalità o workflow all’interno di processi già coperti e rilasciati agli
utenti utilizzatori;
• Modificare funzionalità e workflow già esistenti secondo nuovi requisiti necessari per supportare cambiamenti di processo e/o organizzativi e/o normativi;
• Innovare tecnologicamente le soluzioni applicative in uso attraverso gli upgrade a nuove versioni, utilizzo di nuovi sistemi di integrazione o nuove piattaforme tecnologiche, ampliamento del contenuto informativo di alcuni moduli, ecc.;
• Effettuare il servizio di garanzia del software sviluppato, per la correzione di eventuali bug e malfunzionamenti o difformità di funzionamento rispetto a quanto espresso nei requisiti, da intendersi comprensivo dei test di non regressione rispetto alle funzionalità preesistenti lo sviluppo specifico che ha generato il bug/malfunzionamento;
• Fornire assistenza finalizzata all’avvio in esercizio delle applicazioni realizzate;
• Garantire la realizzazione e/o l’aggiornamento della baseline applicativa attraverso la produzione di
materiale e documentazione;
• Produrre tutta la documentazione tecnica prevista ed utile alla manutenzione tecnico-applicativa del nuovo software rilasciato.
4.3.1.3 Servizi di Migrazione di sistemi
Il servizio di migrazione sistemi e applicazioni si propone l’import dei dati e delle informazioni gestite
attualmente dal sistema GESPRA. L’attività prevede:
• La predisposizione di un piano di migrazione
• La realizzazione di programmi di migrazione secondo le regole di sviluppo software del nuovo sistema di riferimento;
• definizione di una strategia di test ed un piano di test di non regressione;
• disegno ed esecuzione di test singoli e massivi per tutti gli scenari di business inseriti nel piano;
• esecuzione della migrazione in ambienti di prova
• il corretto funzionamento di tutti gli scenari di processo in esercizio prima della migrazione;
• il corretto popolamento e consistenza della base dati.
4.3.2 Servizi di Gestione, Manutenzione e Assistenza
• Problem determination: consiste nell’individuare la componente in errore e le cause del problema;
• Problem routing: consiste nel determinare, in funzione del tipo di problema e del componente in errore, la struttura di supporto (dell’Amministrazione o di terzi) cui compete il problema ed assegnarlo ad essa per la risoluzione;
• Problem solving: consiste nella effettuazione delle attività correttive di 2° livello;
• Problem control: consiste nel coordinamento di tutte le attività del processo ed al rispetto dei livelli di servizio richiesti;
• Problem reporting: consiste nel tracciamento del processo e nella produzione di opportuna reportistica, che illustri con cadenza mensile tutti gli interventi effettuati;
• Produzione di documentazione per i casi di errore ricorrenti (FAQ);
• Produzione di materiale formativo per gli utenti su specifiche funzionalità.
• Servizio di manutenzione adeguativa e correttiva. In particolare, le attività previste in erogazione per
l’Amministrazione sono:
• MAC (interventi di manutenzione correttiva): Interventi finalizzati ad eliminare funzionamenti errati e ad al ripristino delle funzionalità previste;
• MAD (interventi di manutenzione adeguativa): Interventi volti ad adattare le funzionalità applicative
esistenti in funzione di mutamenti dell’ambiente;
• MEV (interventi di piccola manutenzione evolutiva): Interventi finalizzati all’ottimizzazione delle applicazioni ed al perfezionamento delle procedure;
• Un punto di accesso unificato di primo livello (Help Desk di primo livello) dedicato ai sistemi volto ad assicurare la tracciabilità in termini di segnalazioni/azioni intraprese;
• Un servizio altamente specializzato in grado di valutare le segnalazioni, intervenire fornendo indicazioni per la risoluzione od effettuare l’escalation di problematiche che richiedano l’intervento di un secondo livello;
• Redazione di note tecniche e documentazione per il supporto all’esercizio;
• Creazione e manutenzione di utility per l’automazione di attività di produzione;
• Supporto al capacity planning;
• Supporto per l’ottimizzazione delle architetture e delle applicazioni;
• “Training on the job” al personale dell’Amministrazione o a terzi da essa individuati, finalizzata a trasmettere il know-how funzionale applicativo e tecnico-sistemistico necessario al corretto utilizzo del software in esercizio.
• Eseguire attività schedulate (check list periodiche);
• Assicurare il controllo sullo stato dei sistemi;
• Individuare criticità o malfunzionamenti ed intraprendere le azioni necessarie;
• Prevenire, gestire e risolvere i problemi che comportano interruzione o degrado del servizio
all’utenza;
• Ottimizzare l’utilizzo delle risorse e garantire la disponibilità, la salvaguardia e l’integrità dei dati;
• Garantire l’efficienza dei sistemi rispetto all’utilizzo delle risorse, controllare l’impatto sulla tecnologia esistente e garantire l’adeguamento degli ambienti elaborativi a fronte dell’immissione in esercizio di modifiche correttive e/o evolutive di applicazioni esistenti;
4.3.3 Servizi di Supporto Organizzativo
• Redazione del documento «Masterplan», strumento con il quale l’Amministrazione analizza e pianifica
le attività progettuali;
• Supporto tematico di soluzioni in ambito tecnologico.
• Progettazione e realizzazione di interventi di formazione, workshop, comunicazione, ecc., a seguito dei cambiamenti intervenuti con l’implementazione del nuovo sistema, con l’obiettivo di allineare le risorse rispetto ai cambiamenti introdotti.
Contratto Quadro - Servizi in ambito sistemi gestionali integrati per le pubbliche amministrazioni (SGI) - Lotto 3 | ||||
Progetto Esecutivo – Comune di Firenze | ||||
Data documento: 12-02-2018 | Versione 2.0 | Direzione Sistemi Informativi | ||
5 PIANO DI PROGETTO
5.1 CRONOPROGRAMMA DI MASSIMA DEI SERVIZI INERENTI IL NUOVO SISTEMA
La proposta delle Società offerenti per il Cronoprogramma di dettaglio delle attività è elaborata in coerenza con il framework metodologico proposto e nel rispetto della pianificazione di massima presente nel Piano dei Fabbisogni; in particolare:
• risulta articolato secondo la durata complessiva dell’affidamento di 36 mesi;
• prevede la realizzazione, migrazione dati, formazione ed avvio in esercizio del nuovo sistema al più entro 24 mesi dall’inizio dei lavori;
• permette la finalizzazione degli output di progetto previsti per ciascuna fase secondo le tempistiche stabilite dal Piano dei Fabbisogni Di seguito si presenta il piano, con evidenza degli output di fase.
Anno 1 | Anno 2 | Anno 3 | ||||||||||||||||||||||||||||||||||||
FASI E SERVIZI | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ||
Back office sistema di gestione pratiche Edilizia/Ambiente | ||||||||||||||||||||||||||||||||||||||
M0 - DI-PEA (ordine) | ||||||||||||||||||||||||||||||||||||||
M1 - KICK_OFF (verbale di inizio attività) | ||||||||||||||||||||||||||||||||||||||
M2 - DLVB_STFP (specifiche tecnico-funzionali del progetto) | ||||||||||||||||||||||||||||||||||||||
M3 - DLVB_SVILUPPO (sviluppo dei moduli funzionali del sistema) | ||||||||||||||||||||||||||||||||||||||
M4 - DLVB_MIGDATI (migrazione dei dati dal precedente sistema) | ||||||||||||||||||||||||||||||||||||||
M5 - DLVB_TEST_VERIFICA (avvio su ambiente di test) | ||||||||||||||||||||||||||||||||||||||
M5BIS - DLVB_REWORKING (reworking sviluppo dei moduli funzionali) | ||||||||||||||||||||||||||||||||||||||
M6 - DLVB_TUNING (tuning complessivo del sistema) | ||||||||||||||||||||||||||||||||||||||
M7 - DLB_FORMAZ (formazione del sistema PEA di Back office) | ||||||||||||||||||||||||||||||||||||||
M9 - DLB_CONFORMITA (verifica conformità del sistema) | ||||||||||||||||||||||||||||||||||||||
M10 - DLB_AVVIO (avvio in produzione del sistema) | ||||||||||||||||||||||||||||||||||||||
M11 - DLB_DOCUMENTAZIONE (consegna sorgenti e documentazione) | ||||||||||||||||||||||||||||||||||||||
M12 – DLB-MANUT (rapporti trimestrali di esecuzione attività) | ||||||||||||||||||||||||||||||||||||||
6 ORGANIZZAZIONE DI PROGETTO
Per la gestione del Progetto, le Società Offerenti propongono una struttura organizzativa semplice e snella, con una chiara identificazione di ruoli, responsabilità e modalità di interazione e coordinamento tra tutti i soggetti coinvolti in modo da garantire al Comune di Firenze punti di riferimento chiari e stabili. La costruzione del modello è stata quindi guidata dalla necessità di contemperare da un lato modalità di interazione rapide e agevoli dall’altro, un efficace e capillare presidio dei servizi e della qualità complessiva del Progetto. Di seguito si presenta il modello organizzativo proposto.
Il gruppo di lavoro sarà coordinato da un Capo Progetto, supportato nella direzione dell’iniziativa da uno Staff di Governo per le attività di PMO.
A tale proposito l’Amministrazione richiede l’istituzione di una struttura di coordinamento (steering committee) comprendente i responsabili di progetto delle aziende coinvolte, i DEC (direttori dell’esecuzione del contratto) del Comune e i rappresentanti dell’utenza comunale individuati dai dirigenti delle Direzioni interessate.
La gestione operativa verrà articolata in tre macro-aree (Servizi di Sviluppo Software, Servizi di Gestione, Manutenzione e Assistenza, Servizi di Supporto Organizzativo) composte da specifici Team progettuali.
Il suddetto modello prevede che i Team impiegati nei Servizi di sviluppo Software e nei Servizi di Gestione, Manutenzione e Assistenza siano costantemente supportati dal Team trasversale di Supporto organizzativo, specializzati nel supporto architetturale, supporto tematico-funzionale.
Di seguito si presenta una breve descrizione per ciascuna figura proposta nel modello organizzativo:
• Capo Progetto 🡪 È il Referente unico per il singolo Contratto Esecutivo, interfaccia primaria per tutti i soggetti dell’Amministrazione. Coordina tutte le risorse coinvolte nelle attività. Assicura unitarietà di indirizzo, rispetto degli SLA contrattuali, elevata qualità dei servizi e dei deliverable rilasciati, consuntivazione, ecc.
Inoltre, come espresso nel documento di analisi dei fabbisogni, il capo progetto supporterà anche lo steering committe che l’amministrazione comunale intende istituire quale struttura di coordinamento dell’intero progetto PON Metro
• Staff di governo PMO 🡪 È la struttura di supporto al Capo Progetto nella gestione delle attività contrattuali. Presidia i principali processi operativi (Pianificazione, Qualità, Rischi, Risorse, Conoscenza) assicurando la piena integrazione tra tutti i processi operativi all’interno del Raggruppamento e l’unitarietà di visione e di approccio.
• Responsabili Tecnici dei Servizi 🡪 Per ciascuno dei tre servizi attivati, il fornitore nomina un Responsabile Tecnico con il compito di coordinare dal punto di vista operativo tutte le attività legate ai servizi. I Responsabili tecnici dei servizi pianificano, coordinano e controllano le prestazioni dei Team di Progetto, costituiti ad hoc in funzione delle caratteristiche di ogni servizio e obiettivi e/o interventi richiesti e strutturati.
6.2 MODALITÀ DI GOVERNO DEL PROGETTO
Per garantire una ottimale gestione della governance e del gruppo di progetto, assicurando il rispetto delle tempistiche e la risoluzione tempestiva di eventuali criticità, sono previsti appositi incontri periodici.
Tipologia di incontro | Descrizione | Attori coinvolti | Frequenza |
Riunioni di coordinamento steering commette | Incontri strategici di definizione degli indirizzi complessivi e il controllo/monitoraggio sul progetto per il progetto PON Metro nel suo complesso | • Capo Progetto • Comune di Firenze • Referenti progetto Front end | una volta al mese |
Incontri di Stato Avanzamento Lavori (SAL) | Incontri finalizzato alla verifica dello stato del progetto e prendere decisioni sulle azioni di intraprendere (Strumento di controllo e strumento decisionale) | • Capo Progetto • Referente Comune di Firenze | Ogni mese |
Incontri di coordinamento progettuale | Incontri interni per garantire l’allineamento tra le decisioni strategiche prese in sede di Comitato di Progetto e la gestione operativa | • Capo Progetto • Responsabili tecnici dei servizi | In base alle esigenze di progetto |
Per il governo del progetto, le Società Offerenti si avvarranno inoltre di un insieme articolato di strumenti.
Strumenti di governo del Progetto | Descrizione |
Piano di Lavoro (PdL) | Strumento che descrive il progetto in termini di fasi e relative attività, tempi di esecuzione e risultati da conseguire, soggetti coinvolti |
Repository di Progetto | Archivio della documentazione di progetto in formato elettronico |
Tableau de Board | Strumento in grado di offrire una vista di insieme e/o di dettaglio sullo stato avanzamento complessivo del progetto, attraverso la visualizzazione dei principali indicatori di utilizzo delle risorse e di completamento delle attività |
7 DIMENSIONAMENTO E BUDGET ECONOMICO
7.1 MIX DEI SERVIZI PROPOSTI E MIX DELLE FIGURE PROFESSIONALI
Di seguito il dettaglio di mix numero di giornate uomo per tipologia di servizio.
Sviluppo software
I Servizi di Sviluppo Software, così come dettagliati nel par. 4.3.1, saranno realizzati da Xxxxxxxxx e rendicontati “a corpo”.
Si riportano di seguito i sotto servizi che saranno erogati nel corso della fornitura
Servizio | Figura Professionale | Team mix | Numero di gg/uu per il contratto specifico |
Analisi, progettazione e realizzazione SW ad hoc | Capo Progetto | 10% | 233,91 |
Analista Funzionale | 25% | 584,78 | |
Specialista di prodotto | 10% | 233,91 | |
Architetto di sistema | 15% | 350,87 | |
Analista Programmatore | 30% | 701,74 | |
Database Administrator | 10% | 233,91 | |
Totale | 2.339,12 | ||
Servizio | Figura Professionale | Team mix | Numero di gg/uu per il contratto specifico |
Migrazione sistemi e applicazioni | Capo Progetto | 5% | 6,60 |
Analista Funzionale | 20% | 26,40 | |
Specialista di prodotto | 15% | 19,80 | |
Architetto di sistema | 10% | 13,20 | |
Analista Programmatore | 40% | 52,80 | |
Database Administrator | 10% | 13,20 | |
Totale | 132,00 | ||
Servizio di gestione, manutenzione e assistenza
I servizi di gestione, manutenzione e assistenza, così come dettagliati nel par. 4.3.2, saranno realizzati da Xxxxxxxxx e rendicontati a canone
Servizio | Figura Professionale | Team mix | Numero di gg/uu per il contratto specifico |
Manutenzione Adeguativa e correttiva | Capo Progetto | 5% | 20,02 |
Analista Funzionale | 30% | 120,10 | |
Specialista di prodotto | 5% | 20,02 |
Architetto di sistema | 5% | 20,02 | |
Analista Programmatore | 50% | 200,16 | |
Database Administrator | 5% | 20,02 | |
Totale | 400,34 | ||
Supporto organizzativo
I Servizi di Supporto organizzativo, così come dettagliati nel par. 4.3.3, saranno realizzati da PwC e rendicontati “a corpo”
Servizio | Figura Professionale | Team mix | Numero di gg/uu per il contratto specifico |
Gestione applicativa e supporto utenti | Senior Advisor | 20% | 24,05 |
Capo progetto | 10% | 12,02 | |
Consulente senior | 40% | 36,07 | |
Consulente junior | 30% | 48,09 | |
Totale | 120,23 | ||
7.2 QUADRO ECONOMICO DI RIFERIMENTO
Il dimensionamento economico complessivo del progetto, nell’arco dei 36 mesi previsti, è pari a 699.995,83 €
articolati nelle tipologie di servizi e nei specifici servizi secondo lo schema di seguito riportato:
Anno 1 | Anno 2 | Anno 3 | TOTALE | |
Valore complessivo progetto | 227.210,01 € | 405.664,70 € | 67.121,12 € | 699.995,83 € |
SVILUPPO SOFTWARE | 217.310,08 € | 356.900,21 € | 0 € | 574.210,29 € |
SERVIZIO DI GESTIONE, MANUTENZIONE E ASSISTENZA | 0 € | 32.264,60 € | 53.845,31 € | 86.109,91 € |
SUPPORTO ORGANIZZATIVO | 9.899,93 € | 16.499,89 € | 13.275,81 € | 39.675,63 € |
Come ipotizzato con l’amministrazione, in accordo con le linee di intervento previste dal PON Metro Asse 1 Agenda Digitale Firenze, in particolare con il progetto FI1.1.1.a Piattaforma Edilizia e Ambiente, le milestone di fatturazione ripartite per gli anni di contratto son le seguenti:
− Anno 1: 30% del corrispettivo complessivo
− Anno 2: 50% del corrispettivo complessivo
− Anno 3: 20% del corrispettivo complessivo
8 CONTRIBUTO A CARICO DELL’ENTE
Ai sensi dell’art. 4, comma 3-quater, del D.L. 6 luglio 2012, n. 95, convertito con modificazioni in legge 7 agosto 2012, n. 135, al presente contatto si applica il contributo di cui all’art. 18, comma 3, X.Xxx. 1 dicembre 2009, n. 177, come disciplinato dal D.P.C.M. 23 giugno 2010.
L’Amministrazione Beneficiaria è tenuta a versare a Consip S.p.A., entro il termine di 30 (trenta) giorni solari
dalla data di perfezionamento del Contratto Esecutivo, il predetto contributo nella misura di € 5.599,97.