ALLEGATO F) Allegato tecnico

ALLEGATO TECNICO
Indice generale
Descrizione del software oggetto della fornitura.................................................2
Il sistema informativo attuale....................................................................... 3
Requisiti generali...................................................................................... 3
Requisiti infrastrutturali e tecnologici............................................................. 4
Requisiti funzionali....................................................................................5
Layout grafici minimi...................................................................10
Iter.........................................................................................15
Ricerche e Reportistica.................................................................17
Gestione scadenziario e alert..........................................................18
Requisiti non funzionali..............................................................................18
Requisiti Accessibilità..............................................................................19
Descrizione del software oggetto della fornitura
L’oggetto della fornitura è lo sviluppo di un software sotto forma di web application per la gestione
delle chiamate/segnalazioni al Comune di Reggio Emilia: per chiamate/segnalazioni si intendono
quelle relative alle segnalazioni ricevute dal Call Center Manutenzioni e/o pervenute all'URP o ad
un altro ufficio.
Le segnalazioni ricevute e classificate come di competenza del “Call Center Manutenzioni”
generalmente identificano una esigenza manutentiva che può dar luogo a sopralluoghi, ordini di
lavoro esterni e gestione costi di chiamata o contabilità lavori.
Le segnalazioni generiche (URP o altro ufficio) possono:
 non avere un iter procedurale collegato ma censire e classificare solo il contatto cittadinoamministrazione;
 aver associato un iter di passaggi ad altro/altri uffici
 devono garantire la risposta all'utente.
Scopo del presente documento è la definizione dell'analisi funzionale relativa alla realizzazione di
una applicazione software che rispetti le specifiche del presente allegato tecnico e del capitolato,
rimandando all'analisi di dettaglio del fornitore la definizione specifica dei requisiti qui descritti.
Il Comune di Reggio Emilia tramite l'identificazione di referenti organizzativi, si impegna a fornire
esaurienti indicazioni al fornitore del servizio e a quest’ultimo è richiesto un approccio proattivo
all'analisi di dettaglio, alla progettazione ed alla realizzazione del software, in grado, sulla base
della propria esperienza, di integrare quanto proposto dal primo.
L’articolazione temporale delle attività previste è la seguente:
 Initial release del software: entro 45 giorni dall'aggiudicazione della fornitura;
 Final release del portale: entro 90 giorni dall'aggiudicazione della fornitura;
 Manutenzione ordinaria e garanzia, a partire dalla final release (data verbale di collaudo),
per n. 12 mesi;
I requisiti che definiscono i vincoli della soluzione applicativa proposta e realizzata e saranno
oggetto di valutazione qualitativa dell'offerta presentata, sono i seguenti:
• requisiti generali;
• requisiti infrastrutturali e tecnologici;
• requisiti funzionali;
• requisiti non funzionali;
• requisiti accessibilità;
Il sistema informativo attuale
Si fornisce di seguito, una breve descrizione del contesto applicativo e tecnologico dell’attuale
infrastruttura del Sistema Informativo del Call Center Manutenzioni e Segnalazioni URP.
Il software attualmente in uso per la gestione delle chiamate al Call Center Manutenzione è un
applicativo sviluppato in Microsoft Access 2000 che garantisce l'espletamento dell'intero iter e
ciclo di vita della segnalazione: a partire dall'apertura della chiamata, fino alla fatturazione e
pagamento.
Il sistema è ormai tecnologicamente obsoleto e non garantisce le necessarie aperture verso i
paradigmi della programmazione a livelli, interoperabilità e web-based.
Il software che raccoglie le chiamate e le segnalazioni dell'URP invece è un applicativo, anch'esso
ormai datato e non più soddisfacente alle necessità del Servizio, realizzato in Lotus Notes e non
integrato con alcuna banca dati relazionale dell'Ente.
Requisiti generali
Tutto il software applicativo realizzato durante l’esecuzione della presente fornitura:
 dovrà essere corredato della documentazione tecnica di analisi, progettazione,
realizzazione, test, manuale utente, in conformità con le specifiche funzionali e non,
indicate nel presente allegato tecnico;
 viene concesso in licenza d'uso al Comune di Reggio Emilia, senza limitazione sul numero di
utenti che accedono al sistema;
 deve essere comprensivo di un periodo di garanzia in cui viene assicurata la manutenzione
ordinaria per almeno per 12 mesi a partire dalla data indicata nel verbale di collaudo del
sistema.
Nella realizzazione del software dovrà essere garantita:
 interoperabilità ed integrazione con gli altri sistemi già in dotazione dell’Amministrazione,
(in particolare quindi in relazione all'integrazione banche dati esistenti quali ad esempio
toponomastica, centri di costo, edifici e protocollo, ai sensi del Testo Unico sulla
documentazione amministrativa DPR 445/2000 "Disposizioni legislative in materia di
documentazione amministrativa"- Capo IV “Sistema di gestione informatica dei
documenti”);
 coerenza e conformità con l'immagine coordinata del Comune e del Sito istituzionale
relativamente agli aspetti di comunicazione e grafici, sia per l'applicativo web, sia per le
eventuali applicazioni mobile;
 coerenza e conformità con le piattaforme hardware e software già in dotazione
dell'Amministrazione;
 migrazione nel nuovo software delle chiamate e delle commesse relative all'anno 2015;
 layout “responsive design” ovvero adattamento grafico automatico al dispositivo sul quale
verrà visualizzato (computer con diverse risoluzioni, tablet, smartphone, etc.);
 modellazione della base dati al fine di rispondere ai dettami dell’open data: il sistema dovrà
essere strutturalmente predisposto per facilitare la distribuzione dei dati a livello “3 stelle”
o superiori (Linked open data LOD);
 possibilità di definire oggetti, maschere ed iter personalizzabili dal Committente.
L’offerta deve comprendere la formazione adeguata del personale. Nella relazione tecnica la ditta
offerente dovrà indicare il numero di giorni di formazione inclusi nella fornitura e una proposta di
suddivisione dei corsi di formazione in base agli utenti a cui sono destinati: personale URP,
personale Servizio Manutenzione e personale tecnico CED (n. di persone max da formare 30).
I corsi dovranno essere tenuti presso la sede del Comune, in date e con modalità da concordare
con referente di progetto del Comune di Reggio Emilia e dovranno tener conto dell’inderogabile
esigenza, per l’Ente, di garantire la continuità di tutti i servizi e uffici del Comune.
Requisiti infrastrutturali e tecnologici
L'applicativo web dovrà avere architettura a tre livelli eventualmente distribuibili su macchine
fisicamente diverse.
Preferibilmente i componenti dovranno poter essere installati su:

RDBMS Oracle v. 11.2.0.3

JBoss 7.1.1 (versione JDK 1.7); IIS vers. 7.5

Apache 2.2

l'interfaccia utente dovrà essere di tipo web (non client) e non dovrà utilizzare/scaricare
applet o componenti software che richiedono una installazione lato client.
Il software dovrà essere sviluppato con software che non richieda al Committente l'acquisto di
licenze aggiuntive o componenti proprietarie.
Tutti i moduli applicativi devono funzionare su canali TCP che siano possibilmente singoli, non
negoziati durante le comunicazioni, dichiarati e ben documentati; diversamente deve essere
specificato il livello ed il canale di comunicazione utilizzato.
Il software rilasciato dovrà inoltre garantire:
 rispetto dei requisiti di accessibilità (vedi paragrafo Requisiti Funzionalità);
 rispetto della normativa sulla privacy;
 aderenza alle raccomandazioni del World Wide Web Consortium (W3C) [HTTP 1.1, HTML
4.0.1 strict;
 XHTML 1.0 strict o XHTML 1.1, CSS 2.0 e xForms (eXtended Forms), HTML 4 e superiori;
 compatibilità con i browser: Internet Explorer 9.x e superiori, Safari 3.0 e superiori, Firefox
2.0 e superiori; Opera 6.0/7.0 e superiori; Google Chrome 3.0 e superiori;
 utilizzo su PC con sistema operativo Windows 7 o Windows XP;
 accesso sicuro a pagine web secondo gli standard SSL/TLS (se necessario).
Nell’offerta tecnica deve essere descritta e sarà valutata la piattaforma hardware e software
proposta dal fornitore: sistemi operativi, database, application/web server, software di base,
componenti necessarie al corretto funzionamento dell'applicazione.
Tutte le tabelle, la loro strutturazione e le relazioni fra esse devono essere adeguatamente
documentate e devono essere consultabili tramite usuali strumenti di visualizzazione; in
particolare devono essere ben documentati i singoli campi delle tabelle ed il loro significato. Deve
essere quindi ben chiara la relazione tra i campi del database e i campi forniti con l'analisi.
Tutti i dati contenuti negli archivi devono poter essere accessibili direttamente dall’Amministratore
che si impegna, in accordo con il fornitore del software, a svolgere tutte le operazioni di gestione
ordinaria per una corretta manutenzione.
Il Comune di Reggio Emilia si riserva di eseguire audit mirati alla verifica del rispetto degli standard
architetturali e di sicurezza.
In caso di non conformità il fornitore sarà tenuto, senza alcun onere per l’Amministrazione, ad
adeguare le applicazioni agli standard di cui sopra.
La ditta aggiudicataria dovrà garantire l'analisi di dettaglio condotta in collaborazione con il
personale dei Servizi interessati e del Servizio Tecnologie e Sistemi Informativi del Comune,
nonché le eventuali messe a punto del software che si rendessero necessarie a seguito di tale
attività.
Nell'offerta tecnica dovranno essere quantificate e specificate le ore/giornate che la ditta riserverà
all'analisi di dettaglio.
In fase di avviamento e durante il periodo di garanzia dei programmi oggetto della fornitura,
l’Impresa è tenuta a fornire i servizi di assistenza sistemistica e tecnica necessari ad assicurare il
corretto funzionamento del software fornito. In particolare, durante l’orario di apertura degli uffici
del Comune, deve garantire l’assistenza telefonica e telematica all’utilizzo del software applicativo.
Dovranno altresì essere assicurati:
 le consulenze ed il supporto per un miglior uso dei programmi;
 la collaborazione alla soluzione di problemi pratici;
 gli interventi entro 12 ore dalla chiamata;
 la rimozione di anomalie e/o malfunzionamenti.
Le modalità e le eventuali condizioni e clausole relative alla corresponsione di tali servizi nel
periodo sopra indicato dovranno essere esplicitate nell’offerta tecnica e saranno oggetto di
valutazione.
Requisiti funzionali
Si riportano di seguito i requisiti funzionali del software che la soluzione software deve soddisfare.
REQUISITO FUNZIONALE
INDICE REQUISITO
RF1
Maschere personalizzabili
Il software deve poter gestire “modelli” di segnalazioni differenti a seconda dell'esigenza:
segnalazione strade, segnalazione edifici, segnalazione aree verdi, segnalazione generica,
contatto generico etc.
A tali modelli potranno corrispondere maschere con layout differenti (cfr. paragrafi
“Layout grafici minimi”).
In aggiunta ai modelli previsti, l'Amministratore del software (ovvero il Committente)
deve, in autonomia, poterne creare dei nuovi e personalizzare il layout grafico delle
maschere aggiungendo o modificando i campi.
RF2
Gestione anagrafiche oggetti
Le segnalazioni devono potersi riferire ad oggetti: edifici, strade, aree verdi etc. o loro
pertinenze (es. alberi, giochi pubblici, pali, ponti etc.)
In aggiunta agli oggetti definiti in fase di analisi di dettaglio, l'Amministratore del
software (ovvero il Committente) deve, in autonomia, poterne creare dei nuovi e
personalizzare i campi associati.
Laddove tali oggetti si riferiscano a banche dati ufficiali dell'Ente, come ad esempio:
 toponomastica (vie e civici)
 edifici comunali
 aree verdi
 centri di costo (collegati a toponomastica ed edifici)
 ...
deve essere garantito collegamento con tale banca dati.
RF3
Iter personalizzabili
A ciascun “modello” creato deve essere possibile associare un “iter” personalizzabile (cfr.
paragrafo “Iter”). Le azioni e le attività devono essere analizzate in dettaglio con il
Committente.
In aggiunta agli iter previsti, l'Amministratore del software (ovvero il Committente) deve
poter, in autonomia, poterne creare dei nuovi e deve poter personalizzare quelli
esistenti, aggiungendo o modificando attività o azioni definite.
RF4
Stati della pratica
Una segnalazione può assumere diversi stati, a seconda del modello di appartenenza.
Per stati della pratica si intende una fase dell'iter caratterizzata da un momento di inizio e
di conclusione.
Deve essere possibile tener traccia della data di inzio/fine stato e del tempo intercorso
fra le date e su queste tempistiche determinare statistiche, conteggi e report.
E' facoltà dell'Amministratore del software definire se un determinato cambio di stato
deve poter inviare al mittente della segnalazione una “Risposta di cortesia”.
RF5
Durata della pratica e gestione alert (cfr. paragrafo “Gestione scadenziario e alert”).
Una segnalazione deve poter avere un tempo massimo di espletamento, a seconda del
modello di appartenenza.
Deve essere presente una funzionalità che consenta la gestione di alert e allarmi
configurabile sulla base delle soglie definite: deve essere possibile inviare mail o alert
predefinite a gruppi di utenti specifici all'avvicinarsi della scadenza, dopo la scadenza, o
ai cambiamenti di stato “rilevanti”.
Tale configurazione deve poter essere effettuata dall'Amministratore del software
(Committente) tramite apposito pannello di configurazione.
RF6
Supporto geolocalizzazione
Il software dovrà disporre di un sistema di visualizzazione sul web della cartografia del
territorio comunale, utilizzata per garantire la localizzazione degli interventi sul territorio,
laddove tali interventi sono collegati a specifico oggetto georeferenziato.
Gli interventi devono poter essere identificati graficamente in modalità differenti sulla
base del loro stato. Attraverso la cartografia dovrà essere possibile inserire richieste di
intervento o accedere alle schede collegate.
RF7
Gestione richiesta di intervento/chiamata/segnalazione per URP o Ufficio Generico (cfr.
paragrafo “Iter”)
Per quanto riguarda le azioni da poter inserire nell'iter delle segnalazioni relative ai
Suggerimenti/Reclami ed Accesso agli atti raccolte da URP (o Ufficio Generico), il
software di back office deve garantire:
 compilazione da parte di un utente del sistema interno al Comune della
form relativa;
 ricezione
della
segnalazione
da
altre
fonti
esterne
e
completamento/validazione campi da parte dell'operatore URP;
 gestione delle “Risposte di Cortesia” per informarlo sui vari cambi di stato
della pratica;
 inoltro (multiplo) della richiesta pervenuta ad un Servizio/Ufficio del
Comune, censito nella struttura organizzativa;
 presa in carico richiesta da parte dell'Ufficio assegnato;
 gestione documentazione allegata alla richiesta;
 chiusura della richiesta con possibilità di invio Risposta al cittadino.
RF8
Gestione Segnalazioni Manutenzione (cfr. paragrafo “Iter”)
Per quanto riguarda le azioni da poter inserire nell'iter delle richieste di intervento del
Call Center Manutenzioni, il software di back office deve garantire:
 apertura di una segnalazione da parte di un operatore;
 apertura di un ordine di lavoro con ditta esecutrice: funzionalità che deve
consentire di definire il fornitore che eseguirà l'intervento, i tempi di esecuzione,
la commessa associata, il tipo di intervento (a canone, a misura e/o straordinario),
il grado di urgenza, la descrizione dell’intervento e altre informazioni che il
Committente riterrà utile indicare e che saranno identificate nella fase di analisi di
dettaglio;
 in alternativa, apertura di un ordine di lavoro interno: funzionalità che deve
consentire di definire il tecnico/operatore del Comune di Reggio Emilia che
eseguirà il lavoro, i tempi di esecuzione, il grado di urgenza, la descrizione
dell’intervento e altre informazioni che il Committente riterrà utile indicare e che
saranno identificate nella fase di analisi di dettaglio;
 gestione della commessa: funzionalità che permetta di associare ad un ordine di
lavoro una o più commesse (o contratto). La commessa deve essere a sua volta
associabile ad un fornitore ed avere un proprio set di dati definiti: numero
impegno, tipologia commessa (parte corrente, conto capitale), importo iniziale,
impegnato, saldo;

gestione del preventivo: funzionalità che deve consentire alla ditta esecutrice a
cui viene associata la commessa di specificare il dettaglio economico
dell’intervento, sulla base di un elenco prezzi (caricato dalla stessa ditta
esecutrice) o di una quantificazione puntuale;

gestione del sopralluogo: funzionalità che consenta di gestire tutte le informazioni
utili fra cui data sopralluogo, personale che lo ha eseguito, descrizione, note,


RF9
materiale documentale (foto, planimetrie, ecc.);
gestione dei rapporti di lavoro: funzionalità che consenta alla ditta esecutrice
della commessa di specificare i dati di resoconto dell’intervento eseguito ossia:
data di inizio lavori, data di fine lavori, esecutori, descrizione dell’intervento,
materiale documentale (foto, documenti vari), rendiconto economico;
gestione contabilità interventi manutentivi: funzionalità che deve consentire la
rendicontazione economica degli interventi a misura e/o straordinari attraverso la
compilazione di opportune sezioni analitiche di contabilizzazione.

gestione acconti: funzionalità che consente, una volta approvata la
rendicontazione economica dell'ordine di lavoro di gestire i pagamenti tramite
registri di contabilità, SAL e Certificati di Pagamento. Devono essere garantite la
funzionalità di attribuzione fattura ad un determinato SAL e di pagamento di
gruppi di fattura che appartengono allo stesso SAL.

gestione sospensioni e chiusura: funzionalità che deve consentire la sospensione
dell'iter e la chiusura della segnalazione, specificando l'esito finale.

chiusura della segnalazione con possibilità di invio Risposta al cittadino.
Gestione anagrafiche correlate: Enti, tecnici, fornitori, struttura organizzativa, ambiti etc.
Il sistema deve gestire le seguenti anagrafiche e le deve integrare nell'iter di lavorazione
della segnalazione:
 Anagrafica Enti: il software deve essere multi-Ente ovvero poter gestire
segnalazioni di competenza del Comune di Reggio Emilia e/o di altri Enti (es.
partecipate);
 Anagrafica validatori, tecnici e operatori: l'iter di lavorazione di una segnalazione
può prevedere la validazione di una fase da parte di un tecnico o di un diverso
responsabile;
 Anagrafica delle imprese esecutrici dei lavori: l'iter di lavorazione di una
segnalazione può prevedere l'assegnazione ad una ditta esterna: questa
anagrafica deve gestire l'archivio delle ditte responsabili del processo
manutentivo;
 Anagrafica aree, servizi, dirigenti: il software deve poter gestire le anagrafiche
della struttura organizzativa del Comune di Reggio Emilia; in alternativa deve
poter essere integrato a tabelle di altri sistemi informativi pre-esistenti che
gestiscono la suddivisione dell'Ente in Aree, Servizi,Sedi e Dirigenti, in modo da
poter garantire il work-flow della pratica;
 Anagrafica Categorie/Sottocategorie e Argomenti: tabelle che servono per
categorizzare le segnalazioni;
 Anagrafica Tipi Contatto, Tipi domanda, Esiti: tabelle che servono per gestire le
informazioni a corredo delle segnalazioni.
 …
L'Amministratore del software (ovvero il Committente) deve poter in autonomia gestire
ed alimentare le tabelle correlate in modo da garantire aggiornamento continuo.
RF10
Gestione manutenzione programmata
Il software deve consentire la manutenzione programmata su alcune tipologie di oggetti
di competenza.
Per manutenzione programmata si intendono due tipologie di lavorazione:
 definizione di calendari programmati di interventi riferiti ad un oggetto (strada,
edificio, area verde etc.), con la generazione automatica del relativo ordine di
manutenzione;
 inserimento di un ordine di lavoro, associato ad un modello, su cui è indicata una
data prevista di realizzazione.
RF11
Censimento e georeferenziazione di oggetti
Il software deve garantire la funzionalità che consente di censire oggetti sul territorio
anche tramite applicazioni mobile in modalità off-line e trasferire informazioni (dati
alfanumerici e materiale allegato) sul sistema centrale (esempio: buche, ponti, lampioni
etc).
Il censimento deve garantire la compilazione di una anagrafica di minima.
Il sistema deve garantire il funzionamento mediante App anche senza il collegamento ad
internet (modalità off-line): il modulo deve prevedere una modalità di lavoro sincrona
con il sistema centrale o asincrona in modo da garantire le funzionalità anche in assenza
di connessione dati.
Tale modalità operativa deve poter essere adottata anche nella gestione delle
funzionalità relative all'iter di una richiesta di lavoro.
RF12
Backoffice amministrativo con modalità unificata di inserimento dei contenuti da parte
dei diversi uffici
Indipendentemente dal numero di oggetti, modelli e iter previsti, le funzionalità di base,
la gestione e la profilazione degli utenti, gli scadenziari e le tabelle di trascodifica (cfr.
RF9) devono essere gestiti unitariamente nel software e nella medesima banca dati.
RF13
Gestione utenti
Deve essere possibile integrare il software con il dominio Active Directory dell'Ente. Per
gli utenti esterni al dominio (es. fornitori o partecipate) dovrà poter essere garantita una
gestione dell'autenticazione mista (Active Directory e/o nativa su software).
RF14
Profilazione utenti e gruppi
Devono essere garantiti accessi differenziati all'applicazione in relazione al profilo
aziendale degli utenti.
Deve essere possibile tramite gruppi, ruoli e/o cartelle gestire la struttura organizzativa
dell'Ente ovvero creare suddivisioni rappresentanti i singoli Servizi/Uffici.
Ciascun utente può appartenere a uno o più gruppi.
Ciascun utente e/o gruppo deve poter essere associato ad uno o più modelli di
segnalazioni.
Ciascun utente e/o gruppo deve poter essere associato ad uno o più nodi della struttura
organizzativa.
A ciascun utente e/o gruppo devono essere associate funzionalità o azioni
personalizzabili.
A ciascun utente e/o gruppo deve poter essere assegnato un ruolo.
Ciascun utente e/o gruppo devono poter avere visibilità e privilegi in base alla
combinazione dei punti precedenti.
Il software deve mettere a disposizione all'Amministratore della procedura (ovvero al
Committente) un pannello di configurazione delle abilitazioni utente e delle relative
profilazioni.
Esempi:
 utente o gruppo appartenente a Ente o a altro soggetto (es. fornitore,
partecipate);
 utente o gruppo in sola visualizzazione su un nodo della struttura organizzativa
dell'Ente;
 utente o gruppo in modifica su un nodo della struttura organizzativa dell'Ente, in
visualizzazione su un altro;
 utente o gruppo abilitato in modifica solo ad alcuni modelli di segnalazione;
 utente o gruppo abilitato in modifica solo ad alcuni modelli di segnalazione, in
visualizzazione su altri;
 utente o gruppo abilitato in modifica solo ad alcuni modelli di segnalazione, in
visualizzazione su altri, di un solo nodo della struttura;
 …
RF16
Ricerche e Reportistica
Il software deve mettere a disposizione report di dettagli o di sintesi, filtrabili su un arco
temporale o su altre chiavi di ricerca definite dall'utente (cfr. paragrafo “Ricerche e
Reportistica”), in base alla sua profilazione.
I report devono essere resi disponibili in formato pdf, csv o testo.
RF17
Web service
Devono essere messi a disposizione dei Web Services per l'invio e la ricezione delle
informazioni sugli interventi/segnalazioni da e verso altri sistemi;
deve essere garantita l'integrazione con il Web Service del protocollo dell'Ente.
RF18
Inserimento Segnalazione tramite Web service
Deve essere possibile, tramite web services inserire delle segnalazioni che dovranno
andare ad alimentare un elenco di “Richieste da Validare” da parte di un operatore
abilitato al sistema.
FR19
Gestione Solleciti
Ad una segnalazione deve essere possibile associare ed inserire n solleciti per tener
traccia degli eventuali solleciti sopraggiunti.
Layout grafici minimi
Il software deve poter gestire diversi “modelli” di segnalazioni differenti a seconda dell'esigenza:
segnalazione strade, segnalazione edifici, segnalazione aree verdi, segnalazione generica, contatto
generico, accesso agli atti etc.
A tali modelli possono corrispondere maschere con layout differenti: di seguito si elencano alcuni
modelli a titolo esemplificativo che devono essere gestiti ed i campi che, in linea di massima, tali
layout devono contenere: l'analisi di dettaglio dovrà essere condotta con la ditta aggiudicataria e i
referenti dell'Ente.
I campi devono essere identificati da descrizioni significative (“Etichetta del campo”) e devono
essere corredati in modo opportuno (cioè in modo che la visualizzazione risulti chiara ed efficace)
da note esplicative opzionali a corredo.
L’elenco dettagliato dei campi e la loro obbligatorietà nonché le specifiche di dettaglio della
presente analisi dovranno essere definiti con precisione insieme alla ditta aggiudicataria in fase di
analisi di dettaglio del progetto: sarà facoltà del Committente richiedere di modificare o di rivedere
le maschere, le sezioni, le etichette di campo, le note esplicative inserite, la sequenza dei campi, la
loro obbligatorietà e gli eventuali controlli associati.
In aggiunta ai modelli previsti di seguito, l'Amministratore del software (ovvero il Committente)
deve poter, in autonomia e tramite pannello di configurazione, poterne creare dei nuovi,
personalizzare il layout grafico delle maschere aggiungendo o modificando i campi ed associare un
iter ai modelli creati.
L'inserimento di una nuova richiesta deve essere possibile anche da una maschera che permetta la
ricerca per chiavi (centro di costo, indirizzo, programma, ….): tale ricerca deve restituire tutti le
chiavi che contengono la descrizione impostata e le chiamate/segnalazioni collegate.
Da questa maschera devono essere possibili le seguenti funzionalità: visualizza segnalazioni chiuse
(sola lettura), visualizza segnalazioni ancora aperte, inserimento nuove segnalazione.
Contatto – URP o Ufficio Generico
I campi da prevedere sono:
 Identificatore (progressivo annuale) [campo in sola visualizzazione]
 Data e ora inizio contatto
 Data e ora fine contatto
 Operatore ricevente [collegato a tabella utenti/operatori procedura]
 Servizio ricevente [collegato a tabella struttura procedura]
 Tipo contatto [collegato a tabella di trascodifica dei tipi di contatti]
 Tipo domanda [collegato a tabella di trascodifica dei tipi di domanda]
 Argomenti [collegato a tabella di trascodifica degli Argomenti]
 Sedi [collegato a tabella di trascodifica delle Sedi]
 Chiuso SI/NO
 Esito risposta [collegato a tabella di trascodifica degli Esiti]
 Note
Suggerimento/Reclamo – URP o Ufficio Generico
I campi da prevedere sono:
 Identificatore (progressivo annuale) [campo in sola visualizzazione]
 Nome e Cognome del richiedente [OBBLIGATORIO]
 Via e civico [collegati a tabella toponomastica per residente a RE, libero per residenti fuori
RE]
 Comune e Provincia[collegati a tabelle Comuni e Provincia fornite da Comune di Re]
 Mail o Cellulare [OBBLIGATORI in alternativa]
 Ambito [collegato a tabella di trascodifica degli Ambiti] [OBBLIGATORIO]
 Tipo di contatto [collegato a tabella di trascodifica dei tipi di contatti]
 Protocollo [n. di protocollo generale del Comune di RE ottenuto tramite Web Service – se
necessario]
 Titolo/Oggetto [OBBLIGATORIO]








Descrizione estesa
Localizzazione (per via civico oppure selezionando punto su mappa)
Allegati
Data e ora inserimento
Operatore ricevente [collegato a tabella utenti/operatori procedura]
Servizio ricevente [collegato a tabella struttura procedura]
Stato [collegato a tabella stati] [campo in sola visualizzazione]
Competenza (Interna /Esterna)
1. se competenza = Interna
prevedere campo di Inoltra a interno[ collegato a tabella gruppi/operatori] [vedi
azione Inoltra-Interno nella gestione iter]
2. se competenza = Esterna
prevedere campo di Inoltra a esterno [ collegato a tabella enti/operatori] [vedi
azione Inoltra-Esterno nella gestione iter]

Destinatari Estesi: campo in cui indicare mail di ulteriori destinatari a cui indirizzare
segnalazione oltre a quelli definiti nel punto precedente
Chiuso SI/NO
Esito risposta [collegato a tabella di trascodifica degli Esiti]
Note



Accesso Atti – URP o Ufficio Generico
I campi da prevedere sono:
 Identificatore (progressivo annuale) [campo in sola visualizzazione]
 Nome e Cognome del richiedente [OBBLIGATORIO]
 Via e civico [collegati a tabella toponomastica per residente a RE, libero per residenti fuori
RE] [OBBLIGATORIO – da valutare]
 Località e Provincia[collegati a tabelle Località e Provincia fornite da Comune di Re]
[OBBLIGATORIO – da valutare]
 Mail o Cellulare [OBBLIGATORI in alternativa]
 Documento di Identità [OBBLIGATORIO]
 Protocollo [n. di protocollo generale del Comune di RE ottenuto tramite Web Service]
 Tipo di accesso [collegato a tabella di trascodifica dei tipi di accesso]
 Tipo di ritiro [collegato a tabella di trascodifica dei tipi di ritiro documentazione]
 Titolo/Oggetto [OBBLIGATORIO]
 Descrizione estesa [OBBLIGATORIO]
 Allegati
 Data e ora inserimento
 Operatore ricevente [collegato a tabella utenti/operatori procedura]
 Servizio ricevente [collegato a tabella struttura procedura]
 Costi da sostenere/sostenuti
Segnalazione Area Verde
I campi da prevedere sono:
 Identificatore (progressivo annuale) [campo in sola visualizzazione]
 Nome e Cognome del richiedente [FACOLTATIVO]
 Via e civico [collegati a tabella toponomastica per residente a RE, libero per residenti fuori
RE] [FACOLTATIVO]
 Località e Provincia[collegati a tabelle Località e Provincia fornite da Comune di Re]























Mail o Cellulare [FACOLTATIVO]
Tipo di contatto [collegato a tabella di trascodifica dei tipi di contatti]
Ambito [collegato a tabella di trascodifica degli Ambiti] [OBBLIGATORIO][MANUTENZIONE]
Categoria [collegato a tabella di trascodifica delle Categorie] [VERDE]
Sotto-Categoria [collegato a tabella di trascodifica delle Sotto-Categorie] con filtro su
CATEGORIA
Centrico [Collegato a tabella Centrico del Comune di Reggio Emilia]
Titolo/Oggetto [OBBLIGATORIO]
Descrizione estesa [OBBLIGATORIO]
Localizzazione (per via civico oppure selezionando punto su mappa)
Allegati
Data e ora inserimento
Operatore ricevente [collegato a tabella utenti/operatori procedura]
Servizio ricevente [collegato a tabella struttura procedura]
Competenza (Interna /Esterna)
 se competenza = Interna
prevedere campo di Inoltra a interno[ collegato a tabella gruppi/operatori] [vedi
azione Inoltra-Interno nella gestione iter]
 se competenza = Esterna
prevedere campo di Inoltra a esterno [ collegato a tabella enti/operatori] [vedi
azione Inoltra-Esterno nella gestione iter]
Stato [collegato a tabella stati] [campo in sola visualizzazione]
Chiuso SI/NO
Esito risposta [collegato a tabella di trascodifica degli Esiti]
Tecnico
Ditta esecutrice lavori
Commessa
Data programmazione lavoro
Data esecuzione lavoro
Note
Segnalazione Global Service
I campi da prevedere sono:
 Identificatore (progressivo annuale) [campo in sola visualizzazione]
 Nome e Cognome del richiedente [FACOLTATIVO]
 Via e civico [collegati a tabella toponomastica per residente a RE, libero per residenti fuori
RE] [FACOLTATIVO]
 Località e Provincia[collegati a tabelle Località e Provincia fornite da Comune di Re]
 Mail o Cellulare [FACOLTATIVO]
 Tipo di contatto [collegato a tabella di trascodifica dei tipi di contatti]
 Ambito [collegato a tabella di trascodifica degli Ambiti] [OBBLIGATORIO][MANUTENZIONE]
 Categoria [collegato a tabella di trascodifica delle Categorie] [GLOBAL]
 Sotto-Categoria [collegato a tabella di trascodifica delle Sotto-Categorie] con filtro su
CATEGORIA
 Centrico [Collegato a tabella Centrico del Comune di Reggio Emilia]
 Titolo/Oggetto [OBBLIGATORIO]
 Descrizione estesa [OBBLIGATORIO]
 Localizzazione (per via civico oppure selezionando punto su mappa)
 Allegati












Data e ora inserimento
Operatore ricevente [collegato a tabella utenti/operatori procedura]
Servizio ricevente [collegato a tabella struttura procedura]
Competenza (Interna /Esterna)
 se competenza = Interna
prevedere campo di Inoltra a interno[ collegato a tabella gruppi/operatori] [vedi
azione Inoltra-Interno nella gestione iter]
 se competenza = Esterna
prevedere campo di Inoltra a esterno [ collegato a tabella enti/operatori] [vedi
azione Inoltra-Esterno nella gestione iter]
Stato [collegato a tabella stati] [campo in sola visualizzazione]
Chiuso SI/NO
Esito risposta [collegato a tabella di trascodifica degli Esiti]
Tecnico
Commessa
Data programmazione lavoro
Data esecuzione lavoro
Note
Segnalazione Strade/Segnaletica
I campi da prevedere sono:
 Identificatore (progressivo annuale) [campo in sola visualizzazione]
 Nome e Cognome del richiedente [FACOLTATIVO]
 Via e civico [collegati a tabella toponomastica per residente a RE, libero per residenti fuori
RE] [FACOLTATIVO]
 Località e Provincia[collegati a tabelle Località e Provincia fornite da Comune di Re]
 Mail o Cellulare [FACOLTATIVO]
 Tipo di contatto [collegato a tabella di trascodifica dei tipi di contatti]
 Ambito [collegato a tabella di trascodifica degli Ambiti] [OBBLIGATORIO][MANUTENZIONE]
 Categoria [collegato a tabella di trascodifica delle Categorie] [STRADE o SEGNALETICA]
 Sotto-Categoria [collegato a tabella di trascodifica delle Sotto-Categorie] con filtro su
CATEGORIA
 Centrico [Collegato a tabella Centrico del Comune di Reggio Emilia]
 Oggetto [OBBLIGATORIO]
 Descrizione estesa
 Localizzazione (per via civico oppure selezionando punto su mappa)
 Allegati
 Data e ora inserimento
 Operatore ricevente [collegato a tabella utenti/operatori procedura]
 Servizio ricevente [collegato a tabella struttura procedura]
 Stato [collegato a tabella stati] [campo in sola visualizzazione]
 Chiuso SI/NO
 Esito risposta [collegato a tabella di trascodifica degli Esiti]
 Tecnico
 Ditta esecutrice lavori
 Commessa
 Data programmazione lavoro
 Data esecuzione lavoro
 Note
Iter
Iter Richiesta Call Center Manutenzioni
1. Le richieste al Call Center Manutenzioni possono essere inserite tramite diversi canali:
 Inserimento da parte del cittadino mediante canali esterni: in questo caso la
segnalazione viene inserita in banca dati tramite web services ed il Call Center
Manutenzioni deve avere a disposizione queste richieste mediante un elenco di
“Richieste da validare”.
 L'operatore del Call Center Manutenzioni apre la richiesta “Da Validare” (stato “Da
Validare”) e la “Completa” andando ad aggiungere tutte le informazioni necessarie
per il completamento.
 Inserimento da parte di un operatore di un ufficio generico del Comune mediante la
form “Suggerimento/Reclamo – URP o Ufficio Generico”: l'operatore del Comune
compila una richiesta generica e la assegna alla categoria “Manutenzioni”; anche
in questo caso la richiesta va nell'elenco delle “Richieste da validare”. L'operatore
del Call Center Manutenzioni apre la richiesta “Da Validare” (stato “Da Validare”) e
la “Completa” andando ad aggiungere tutte le informazioni necessarie per il
completamento.
 Inserimento da parte di un operatore del Call Center Manutenzioni che ha a
disposizione i layout definiti nel paragrafo precedente.
2. Le richieste arrivano all'operatore del Call Center Manutenzioni che le valuta; una volta
concluso il completamento della scheda, l'operatore può inviare una
risposta
di
cortesia al cittadino per informarlo che la sua richiesta è stata “Presa in carico” da un
operatore. (stato “Completa”).
3. L'operatore del Call Center Manutenzioni può decidere se assegnare la richiesta ad una
commessa oppure inviare la commessa ad un tecnico validatore per l'apertura di un ordine
di lavoro/ richiesta di intervento.
4. L'operatore del Call Center Manutenzioni può anche decidere di assegnare la richiesta ad
un operatore interno nel caso di interventi eseguiti e/o risolti da personale del Comune di
Reggio Emilia.
5. Il tecnico/validatore, analogamente all'operatore del Call Center Manutenzioni può
assegnare la richiesta ad una commessa;
6. Il tecnico/validatore può anche definire un tempo massimo di chiusura del lavoro e fare una
quantificazione economica di massima che sarà valutata dalla ditta esecutrice;
7. L'assegnazione di una richiesta ad una commessa può generare 2 eventi diversi:
 invio mail alla ditta associata alla commessa con link a richiesta;
 invio mail alla ditta associata alla commessa con richiesta formattata (senza link)
nel caso di ditte esterne che non sono state configurate come utenti della
procedura.
8. Le commesse possono essere di 2 tipologie:
 a scalare/consumo: l'assegnazione della richiesta alla commessa deve poter
visualizzare (sulla stessa maschera o popup o finestra collegata) i dati relativi
all'importo iniziale, all'impegnato ed al saldo della commessa. In questo caso la
ditta
deve predisporre un preventivo che deve essere accettato dal
committente:
 di tipo “global-service”: in questo caso la ditta deve comunicare data inizio e
data fine lavori ed eventuali risorse/costi sostenuti.
9. La ditta a cui viene assegnata la commessa può presentare un preventivo all'Ente che a sua
volta può accettare o rifiutare;
10. Una volta conclusi i lavori la ditta deve notificarlo all'Ente; la notifica deve contenere i dati
di fine lavori ed eventualmente la contabilità lavori laddove richiesta. La notifica può essere
corredata da allegati di tipo foto e relazioni;
11. Il tecnico/validatore deve accettare la quantificazione economica comunicata dalla ditta:
una volta accettata, questo importo resta in attesa di entrare in uno “Stato di Avanzamento
Lavori” da liquidare;
12. Il tecnico/validatore o l'operatore del Call Center Manutenzioni a questo punto può
chiudere la richiesta e scegliere fra diversi esiti. L'operatore può anche inviare una risposta
di cortesia al cittadino per informarlo dell'esito della segnalazione;
13. Periodicamente l'operatore del Comune predispone degli “Stati di Avanzamento Lavori”
suddivisi per commessa che poi provvederà a liquidare; la liquidazione di uno stato di
avanzamento lavori deve produrre un report in cui vengono riepilogate tutte le
quantificazioni economiche delle richieste aperte su una determinata commessa e in attesa
di pagamento. L'operatore del Comune può decidere quante e quali richieste liquidare.
Iter Contatto – URP o Ufficio Generico
Per quanto riguarda la gestione del Contatto, non è da prevedere alcun iter in quanto tale modello
è funzionale al solo conteggio delle richieste di informazioni generiche pervenute all'URP o ad un
ufficio Generico.
Iter Suggerimento-Reclamo
L'iter relativo ai Suggerimenti e/o Reclami da parte di un cittadino deve prevedere:
1. compilazione da parte di un utente del sistema interno al Comune della form
relativa;
2. la form in questo caso assume lo stato “Completa”;
3. invio (opzionale) di una mail al cittadino come “Risposta di Cortesia” per informarlo
che la sua richiesta è stata “Inserita” sul sistema;
4. inoltro della richiesta ad un Servizio/Ufficio del Comune, censito nella struttura
organizzativa (questo step può essere multiplo ossia deve poter essere gestito un
doppio inoltro in successione);
5. l'utente che riceve la chiamata può “Prenderla in carico” ed iniziare la lavorazione
definendo la Competenza se Interna o Esterna.
Se la competenza è INTERNA deve poter essere possibile assegnarla ad un gruppo
[tabella GRUPPI]. Questa assegnazione genera 2 eventi:
 invio mail ai componenti del gruppo assegnatario
 cambio di stato della segnalazione che va nello stato “Assegnata” e passa
in visualizzazione ai componenti del gruppo assegnatario che devono
avere visualizzazione chiamate assegnate.
Se la competenza è ESTERNA deve poter essere possibile assegnarla ad un Ente
[tabella ENTI]. Questa assegnazione genera 2 eventi:
 invio mail ai componenti dell'Ente assegnatario con link a richiesta (nel
caso in cui l'Ente esterno è configurato come operatore/utente del
software)
 in alternativa invio mail ai componenti dell'Ente assegnatario con mail
formattata come richiesta (nel caso in cui l'Ente esterno NON è
configurato come operatore/utente del software)
6. l'utente che prende in carico la richiesta “Assegnata” può fare le seguenti azioni:
 “Riassegnarla” ad altro destinatario INTERNO o ESTERNO (si ripete punto
5)
 “Sospenderla” specificando una data di inizio e fine sospensione
 “Chiudere” la richiesta specificando Risposta ed Esito.
7. Una volta “Chiusa” la chiamata deve essere possibile inviare risposta al cittadino.
Iter Accesso Atti
L'iter relativo alla richiesta di accesso agli atti da parte di un cittadino deve prevedere:
 compilazione da parte di un utente del sistema interno al Comune della form relativa;
 inoltro della richiesta ad un Servizio/Ufficio del Comune, censito nella struttura
organizzativa (questo step può essere multiplo ossia deve poter essere gestito un doppio
inoltro in successione);
 ritorno (opzionale al Servizio/Ufficio del Comune che ha inserito la richiesta);
 risposta via mail al cittadino.
Tutti gli step esposti negli iter descritti devono tener conto della data e ora di inzio e fine fase (cfr.
RF4); in prossimità della scadenza del termine per la risposta al cittadino deve essere possibile
inviare automaticamente un alert/notifica ad un gruppo predefinito di operatori (cfr. RF5).
Deve essere possibile definire un report che contenga il conteggio dei tempi complessivi di
chiusura di una richiesta, sia i tempi relativi ossia suddivisi per i vari stati.
Ricerche e Reportistica
Le richieste/segnalazioni devono poter essere ricercabili, ordinabili ed esportabili (formati csv,
testo e pdf) secondo i seguenti criteri (eventualmente combinati fra loro):
 cronologicamente (ordine progressivo di inserimento);
 per numero chiamata;
 per anno;
 dalla data.... alla data;
 per centro di costo;
 per tipologia documento (contatto/reclamo/accesso atti/verde/segnaletica/strade etc.) con
modalità di scelta multipla;
 per protocollo;
 per chiusura ed esito;
 per mese;
 per utente ricevente;
 per utente richiedente;
 per Ente assegnatario;
 per Servizio assegnatario;
 per parola della descrizione;
 per ditta assegnataria;
 per tecnico responsabile;
 per assistente responsabile;
 parola del titolo;
 per categoria, sotto-categoria, classificazione, argomento, ambito;
 per competenza (Interna/Esterna);
 per zona/mappa geografica;
i campi e le colonne che devono essere ricomprese nell'output della ricerca devono poter essere
parametrizzabili dall'utente o dall'Amministratore del sistema.
Gestione scadenziario e alert
Devono poter essere messe a disposizione visualizzazioni e report che riportano le richieste in
scadenza:
 ad una determinata data
 in un intervallo di date
La data di scadenza è calcolata in base a data inserimento + giorni procedimento, tenendo conto
dei periodi di sospensione.
Devono poter essere definiti degli alert che un numero parametrizzabile di giorni prima della
scadenza della richiesta mandi mail di avviso a gruppi di utenti definibili da amministratore della
procedura.
L'associazione alert ← → gruppo di utenti deve poter essere fatta dall'Amministratore della
procedura (Committente).
L’offerta tecnica deve contenere una descrizione delle funzionalità del software offerto e di come
tali funzionalità soddisfano i requisiti funzionali richiesti nei paragrafi precedenti; devono inoltre
essere descritte funzionalità aggiuntive che il fornitore del software intende includere nell'offerta,
senza costi aggiuntivi per il Committente.
E' facoltà del Committente richiedere una demo del software proposto, per verificare che i
requisiti funzionali descritti nella relazione tecnica, siano effettivamente presenti e
corrispondenti a quanto dichiarato dalle ditte.
Requisiti non funzionali
Si riportano di seguito i requisiti NON funzionali che la soluzione software deve soddisfare:
REQUISITO NON FUNZIONALE
INDICE
REQUISITO
RNF1
“Deve essere uno strumento facile da utilizzare sia per utenti interni che
per le form utilizzate da attori esterni”
Il software deve avere una interfaccia semplice ed intuitiva, deve
contenere le informazioni essenziali ed essere di facile utilizzo per gli
operatori dell'Ente.
RNF2
“Progettazione con visione customer centric”
Il software deve essere pensato focalizzando l'attenzione sul problem
solving delle segnalazioni e sulla soddisfazione dell'operatore del call
center ovvero trovare l'equilibrio ottimale fra completezza maschera di
inserimento e velocità di inserimento di una chiamata.
RNF3
“Strumento trasversale per l'Ente”
Lo scopo è quello di fornire un servizio integrato fra i diversi uffici
dell'Ente e fra Ente e fornitore in grado di fornire un valore aggiunto in
termini di riduzione dei tempi, efficacia ed efficienza del processo
amministrativo.
RNF4
“Tecnologie e manutenibilità”
È richiesto l'utilizzo di soluzioni tecnologiche innovative e possibilmente
open source : è altresì obbligatoria la scelta di tecnologie compatibili e
rispettose degli standard per lo sviluppo di soluzione web-based.
Il software deve essere progettato rispettando i parametri canonici
della qualità del software, tra cui la manutenibilità.
RNF5
“Struttura modulare”
La modularità richiesta garantisce all'Ente di utilizzare la piattaforma in
un'ottica di crescita e informatizzazione di nuovi processi, mediante il
riutilizzo di componenti (moduli) già sviluppati.
RNF6
“Ottimizzazione della visualizzazione dei contenuti ”
Le componenti di interfaccia web devono essere progettate in modo da
garantire la facilità di recupero delle informazioni principali, per
ciascuna fase del processo amministrativo.
RNF7
“Deve essere fornito un supporto professionale garantito per
manutenzione ordinaria e straordinaria”
Al fine di rendere l'applicativo affidabile ed evitare il prolungarsi di
eventuali periodi di disservizio, il supporto professionale che garantirà il
servizio di assistenza e manutenzione deve essere in grado di
intervenire rapidamente soprattutto in situazioni critiche con una
copertura delle fasce orarie di lavoro dell'Ente.
Requisiti Accessibilità
L'applicazione da realizzare dovrà essere accessibile ossia ottimizzata anche per utenti
diversamente abili; dovranno quindi essere seguite le raccomandazioni e le norme in materia:
 Legge n. 4 del 9 gennaio 2004 “Disposizioni per favorire l’accesso dei soggetti disabili agli
strumenti informatici”
 Decreto Ministeriale 8 luglio 2005 “Requisiti tecnici e i diversi livelli per l’accessibilità à agli
strumenti informatici”
 Decreto 20 Marzo 2013 “Modifiche all’allegato A del decreto 8 luglio 2005 del Ministro per
l’innovazione e le tecnologie recante: «Requisiti tecnici e i diversi livelli per l’accessibilità
agli strumenti informatici»” (Prot. 195/Ric).