Silea è una società interamente pubblica che si colloca tra i principali operatori del ciclo integrato dei rifiuti e dell’economia circolare presenti in Lombardia. Gestisce i servizi di raccolta rifiuti e di igiene urbana in 87 comuni delle province di Lecco, Como e Bergamo, su un bacino complessivo di circa 340 mila abitanti.

La società gestisce inoltre un termovalorizzatore ed un impianto di compostaggio per il trattamento della frazione organica, nonché numerosi Centri di Raccolta comunali (piattaforme ecologiche).

Al fine sia di migliorare ulteriormente l’efficacia dei propri processi operativi, sia di predisporsi alle richieste ARERA in materia di dati ed indicatori di performance, Silea ha deciso di rinnovare il proprio software gestionale di waste management, relativamente ai seguenti principali servizi:

• Raccolta rifiuti (prevalentemente in modalità porta a porta);

• Spazzamento strade e aree verdi (manuale e meccanizzato);

• Lavaggio strade;

• Svuotamento cestini;

• Ritiro rifiuti ingombranti e RAEE a domicilio;

• Pulizia caditoie e pozzetti stradali;

• Cura di parchi e giardini (sfalci e potature).

Il software dovrà consentire di supportare le attività in ambito “Gestione Servizi”, come sintetizzate

nello schema concettuale di seguito rappresentato:

“CRM”

(Interazione con utenza)

• Gestione segnalazioni e reclami

(ticket interni ed esterni)

• Gestione prenotazione servizi

(es. ingombranti a domicilio)

Focus del progetto

(*) Non vincolante e indipendente da applicativo gestionale

• Gestione «Contratti di servizio»

• Gestione cartografica

• Progettazione servizi

• Programmazione operativa

• Consuntivazione servizi

(completamento %, esito su singolo punto prelievo; lettura tag, …)

• Gestione «anomalie» da parte dell’operatore

(mancati servizi, segnalazioni, etichette di non conformità.)

Rilevazione GPS su flotta*

“GESTIONE SERVIZI”

(gestione interna del servizio)

Le principali aree di funzionalità attese, sono le seguenti:

• Gestione “calendario” dei servizi, per singolo comune o quartiere (giorno in cui è previsto il singolo servizio) e progettazione dei servizi (“scheda servizio”);

• Programmazione dei servizi (risorse assegnate al servizio e scheduling del servizio);

• Consuntivazione del servizio effettuato – in termini di ore utilizzate e % di completamento del servizio - a cura dell’addetto operativo assegnato al servizio stesso;

• Gestione attività di back-office;

• Reporting e controllo.

Il nuovo software dovrà consentire di gestire sia i servizi svolti da personale Silea (“gestioni dirette”) sia quelli svolti da operatori terzi (“gestioni in appalto”).

In particolare, l’esigenza primaria aziendale è quella di disporre di un software finalizzato a “consuntivare” in modo semplice (tendenzialmente in modalità self-service, tramite dispositivo mobile, a cura degli operatori ecologici sul campo) l’esito del servizio - consentendo così di monitorarne l’effettivo svolgimento (livello di espletamento del servizio) e di quantificarne i tempi di svolgimento (durata del servizio) - nonché a disporre di un set di KPI e di reportistica operativa da utilizzare anche in logica ARERA. La rappresentazione dell’avvenuto servizio dovrà essere fornita anche graficamente (es. su mappa).

Stante la finalità primaria di consuntivare l’esito del servizio, le attività gestionali di programmazione giornaliera/settimanale dei servizi tipicamente a carico del capocentro/responsabile di turno (es. assegnazione risorse ad un percorso, ecc.), non dovranno essere vincolanti/bloccanti ai fini della consuntivazione del servizio da parte degli addetti sul campo: dovrà dunque essere possibile attestare l’avvenuto completamento di un servizio, indipendentemente dalla preventiva programmazione dello stesso.

2. OGGETTO DEL CONTRATTO

Come accennato in premessa, oggetto del presente capitolato è la seguente fornitura:

Licenze

1. Licenze d’uso a tempo illimitato per la gestione di un sistema relativo ai seguenti macro- processi (come meglio descritto nel paragrafo successivo):

▪ Gestione calendario servizi;

▪ Progettazione servizi e scheda servizi (risorse generiche assegnate al servizio, ai fini di dimensionamento)

▪ Programmazione servizi (risorse specifiche assegnate al servizio, ai fini di espletamento);

▪ Consuntivazione del servizio effettuato (durata e livello di espletamento);

▪ Gestione attività di back-office;

▪ Reporting e controllo.

Progetto di implementazione

2. Servizi per l’avviamento del sistema, comprensivi dell’integrazione con i sistemi Silea, e la formazione sia agli utenti che al personale informatico.

3. Installazione, attivazione e successiva gestione dell’intero sistema necessario ed erogare i servizi da un data center del fornitore.

4. Supporto all’utente per l’utilizzo del sistema per 3 mesi successivi alla data di messa in esercizio.

5. Documentazione tecnica e funzionale relativa ai prodotti rilasciati.

Canone

6. Servizi di manutenzione correttiva, adeguativa/normativa/evolutiva, per la durata della fornitura, comprensiva degli aggiornamenti a nuove patch e versioni.

Il progetto si intende “chiavi in mano” ovvero senza ulteriori oneri a carico di Silea.

Eventuali costi delle licenze GIS, del database o di altri software di base necessari per l’utilizzo, saranno a carico dell’Aggiudicatario.

Al termine del rapporto contrattuale tutti i dati raccolti e quant’altro elaborato, al fine della gestione informatizzata del sistema, dovranno essere trasmessi a Silea nei formati e con le modalità che saranno comunicati. Contestualmente l’Aggiudicatario si impegna a cancellarli definitivamente da tutti i propri sistemi e da eventuali sistemi terzi utilizzati.

3. DESCRIZIONE DELLA FORNITURA

La soluzione proposta dovrà coprire le seguenti principali aree di funzionalità attese:

• Gestione “calendario” dei servizi (giorno in cui è previsto il singolo servizio, a livello di intero comune/quartiere/ via);

• Progettazione servizi e scheda servizi (risorse generiche assegnate al servizio, ai fini di dimensionamento)

• Programmazione servizi (risorse specifiche assegnate al servizio, ai fini di espletamento);

• Consuntivazione del servizio effettuato, in termini di:

▪ Rilevazione durata del servizio (ore di servizio di personale e automezzi);

▪ Rilevazione esito del servizio (livello di effettivo espletamento del servizio), con gestione delle causali di mancato servizio o errati comportamenti dell’utenza, direttamente a carico dell’addetto al servizio sul campo (tramite dispositivo mobile).

• Gestione attività di back-office;

• Reporting e controllo.

Saranno meglio valutate gli applicativi software che integrino “nativamente” soluzioni di Customer Relationship Management (CRM) per la gestione e la tracciabilità completa di tutte le informazioni relative a segnalazioni e richieste di servizi da parte di cittadini e aziende. Questo elemento non è oggetto di fornitura ma potrebbe essere incluso nelle migliorie presentate.

Le descrizioni sopra riportate sono da ritenersi esemplificative e non esaustive. Il dettaglio dei requisiti verrà dettagliato nei paragrafi successivi.

Poiché i servizi di igiene urbana vengono svolti anche da ditte esterne che potranno variare nel corso degli anni, il sistema dovrà inoltre poter essere utilizzato dalle nuove ditte, alle condizioni economiche e contrattuali non superiori a quelle applicate a Silea SpA.

La soluzione proposta dovrà essere dimensionata per coprire l’accesso alle componenti applicative, del seguente numero di utenti:

Licenze Silea SpA

N°30 utenti per la funzionalità di consuntivazione su sistema “mobile”

N°20 utenti per la funzionalità di gestione operativa, back-office e reporting

Licenze ditte esterne

N° 270 utenti per la funzionalità di consuntivazione su sistema “mobile”

N°10 utenti delle ditte esterne per la funzionalità di back-office

Silea SpA prevede, nei prossimi anni, un sensibile incremento dei servizi gestiti in proprio, per i quali si riserva l’acquisto di ulteriori licenze, alle quali dovranno essere applicati i prezzi quotati in offerta.

Per l’avviamento del sistema, dovrà essere effettuata un’analisi dettagliata preliminare dei requisiti utenti e dell’integrazione con i sistemi attuali che dovrà essere validata da Silea.

Dovranno essere predisposte le necessarie sessioni di formazione (in aula e on the job) per le tipologie di utenti; per quanto riguarda gli operatori sul campo verranno selezionati dei key user che a loro volta fungeranno successivamente da formatori al resto del personale.

Per i 3 mesi successivi alla messa in esercizio del sistema, dovrà essere fornito un servizio di supporto all’utilizzo agli utenti (verranno definiti dei referenti che si interfacceranno con la ditta).

Per tutta la durata della fornitura dovranno essere garantiti gli aggiornamenti di manutenzione (correttiva, adeguativa normativa ed evolutiva) legati sia alla sicurezza che al corretto e costante funzionamento di tutto il sistema informatico e di tutte le eventuali attrezzature fornite.

Tutta la documentazione (manualistica, istruzioni, ecc.), da consegnare a corredo del sistema, dovrà essere redatta in lingua italiana, fornita su supporto digitale e dotata di funzionalità di ricerca per facilitarne la consultazione.

A titolo esemplificativo e non esaustivo, la documentazione dovrà contenere le seguenti informazioni:

• Disegno architetturale-infrastrutturale complessivo;

• Struttura delle tabelle;

• Struttura, descrizione e funzione dei processi supportati;

• Schema dei flussi di integrazione con gli attuali sistemi;

• Strumenti di amministrazione (GUI, Scripts, ecc.);

• Manuali operativi (start, stop, monitoraggio, operazioni periodiche di manutenzione, ecc.);

• Caratteristiche dell’infrastruttura hardware e software necessarie per ottenere livelli prestazionali ottimali al fine di sfruttare a pieno ogni potenzialità del prodotto offerto.

4. REQUISITI FUNZIONALI

I servizi che Silea svolge sono molteplici e diversi a seconda del singolo Comune servito.

Si ricorda nuovamente che la finalità prioritaria del sistema dovrà essere quella di semplificare la fase di consuntivazione dei servizi (rilevando la durata del servizio ed attestandone e certificandone l’effettivo livello di svolgimento) e di disporre degli indicatori richiesti da ▇▇▇▇▇.

4.1 Gestione dei Contratti di servizio e del Calendario dei servizi

Con questa funzionalità si dovrà poter gestire il “calendario dei servizi” previsto dal Contratto di Servizio con ciascun Comune.

Il calendario definisce, su base annuale, la frequenza (“quando”) con cui deve essere svolto ciascun servizio, a livello di intero Comune (come nel caso di una raccolta rifiuti) o di quartiere/zona o a livello di singola strada (ad esempio nel caso dello spazzamento).

Il calendario dei servizi rappresenta dunque l’elenco dei servizi da svolgere in ciascun comune/zona/strada, nei diversi giorni della settimana (es. RD carta: martedì; RD plastica: giovedì; Spazzamento quartiere “centro”: ogni giorno; Lavaggio piazza: il primo lunedì di ogni mese; …).

A seconda del servizio o del Comune, il calendario di ciascun servizio potrà essere definito a livello di intero comune e/o di singolo quartiere e/o di singola strada.

Il calendario dovrà poter essere caricato nel sistema in modo “massivo” (anche partendo da semplici tabelle Excel predefinite), oltre che essere inserito/modificato “manualmente” direttamente sul sistema stesso.

Il calendario dei servizi viene comunicato a tutti i cittadini: a tal fine il sistema dovrà consentire di estrarre/alimentare con i dati del calendario, sia il sito web aziendale sia l’APP aziendale sia altri sistemi informativi.

4.2 Gestione cartografica

Trattandosi di servizi fortemente connessi al territorio ed alla logistica, sarà necessario disporre di una rappresentazione sia in tabella sia su mappa di tutti gli elementi operativi necessari alle attività, in termini di “punti fissi” (es. contenitori, cestini, caditoie, ...) e di itinerari stradali.

Il sistema dovrà consentire la “digitalizzazione” degli elementi da geo-referenziare (cassonetti, cestini, punti di conferimento sacchi, ecc.): sia attraverso l’acquisizione automatica da tabelle esterne, sia consentendo l’acquisizione manuale “sul campo” rilevando la posizione GPS delle singole attrezzature direttamente durante lo svolgimento del servizio.

Il sistema cartografico dovrà gestire i seguenti dati principali:

• Punti di raccolta rifiuti;

• Cestini gettacarte;

• Strade;

• Confini comunali e municipali;

• Localizzazione altri siti Silea (es. punti di trasbordo, centri di raccolta, eco stazioni, ecc.);

• Dislocazione utenze;

• Altro.

Il sistema dovrà consentire la possibilità di rilevare su mappa, in tempo reale, la posizione degli automezzi dotati di GPS.

4.3 Progettazione dei servizi e “Scheda Servizio”

Il sistema richiesto permetterà di definire la “Scheda” di ciascun servizio, per singolo Comune, contenente:

• sequenza di attività da svolgere (in termini descrittivi, tabellari e/o di itinerari e di punti di intervento rappresentati su mappa);

• dimensionamento tecnico (in termini di quantità e tipologie di risorse da utilizzare, relativamente a mezzi e personale);

• dimensionamento economico (costo del servizio, sulla base delle risorse stimate).

Stante la suddetta finalità (definizione della “Scheda servizio”), in questa fase non sarà necessario ind+icare né i nominativi del personale né le targhe degli automezzi assegnati al servizio: tale attività sarà infatti eventualmente necessaria nella successiva fase di programmazione operativa per la gestione dei servizi.

Nel caso di servizi basati su “percorsi” (es. spazzamenti e raccolta), il sistema dovrà consentire di:

• Disegnare gli “itinerari” su mappa e/o di definirli in forma tabellare (es. elenco vie da servire), anche partendo da file Excel da caricare in input;

• Tener conto di punti di partenza/arrivo nonché di punti intermedi di scarico;

• Gestire più Comuni (limitrofi) nello stesso turno, rilevando ore/costi relativi a ciascun comune.

Al fine di evitare le attività preventive di disegno percorsi “su carta”, il sistema dovrà consentire la possibilità di creare/disegnare percorsi “in automatico”, partendo dalla acquisizione tramite GPS dell’itinerario effettivamente svolto dall’operatore sul campo ed identificato come “percorso standard” di riferimento (“progettazione a posteriori”).

In particolare, per ogni servizio e, ove necessario, per ogni “percorso”, dovranno poter essere gestibili i seguenti elementi principali, con possibilità di “variante stagionale” (es. versione del servizio estivo):

• Ditta che svolgerà il servizio (Silea o ditte in appalto);

• Tipologia di personale che effettuerà il servizio, (es. AUTI, ADEC, ADSP, …);

• Tipologia di mezzi da utilizzarsi per il servizio (es. vasca, compattatore, ...);

• Frequenza di svolgimento del servizio (es. settimanale, bisettimanale, mensile, …);

• Turno/orario di servizio;

• Ore uomo previste per lo svolgimento del servizio;

• Punto di partenza, punti intermedi, punto di arrivo del servizio;

• Elenco aziende da servire (es. nel caso di servizi dedicati integrativi o a pagamento).

Al fine di determinare il dimensionamento economico del servizio, il sistema dovrà consentire di inserire il costo medio unitario per ciascun profilo di personale o di automezzo. In base alle ore stimate per ciascun servizio ed al mix uomini/mezzi ipotizzati, il sistema dovrà infatti determinare il costo complessivo del servizio stesso.

4.4 Programmazione operativa

Il sistema dovrà consentire di effettuare la programmazione operativa “standard" del servizio: per ciascun servizio/percorso dovrà essere definito data e orario di svolgimento, nonché assegnato il personale ed il mezzo da utilizzare (c.d. “vestizione del servizio”).

Il sistema dovrà consentire al responsabile del servizio di gestire situazioni “impreviste” o differenti rispetto alla programmazione operativa standard:

• A livello giornaliero o settimanale, dovranno cioè essere gestite situazioni legate all’indisponibilità del personale o dell’automezzo assegnato al servizio, nonché situazione di “pronto intervento”;

• Dovranno inoltre essere disponibili le informazioni relative a segnalazioni dei cittadini ed a mancati servizi nei turni precedenti (ad esempio contenitore non svuotato o strada non pulita), al fine di poterli aggiungere ai servizi del giorno;

• I disservizi dovranno poter essere gestiti attraverso specifici “percorsi di soccorso”, indipendenti dai percorsi originali.

Sulla base delle informazioni inserite, il sistema dovrà poter generare i fogli settimanali/giornalieri dei servizi per ciascuna unità operativa (a supporto del capocentro) nonché gli ordini di lavoro per gli addetti al servizio (sia per Silea che per le ditte esterne).

Il sistema dovrà garantire la semplicità e la velocità delle attività di attribuzione delle risorse al servizio (programmazione) e di gestione di variazioni quotidiane, in termini di minimizzazione di attività manuali e tempi di inserimento richiesti.

Il servizio dovrà poter essere successivamente “consuntivato” anche in assenza di una programmazione operativa e/o di progettazione preventiva (es. servizi straordinari, gestione anticipi dei servizi; servizi integrativi spot a richiesta; servizi di “soccorso” in caso di disservizio, ecc.): le informazioni su durata, personale e automezzo relative al servizio dovranno infatti essere in ogni caso rilevate in fase di consuntivazione del servizio (direttamente “sul campo” in fase di esecuzione o eventualmente in back-office)!

4.5 Consuntivazione delle attività svolte

All’interno della fase di consuntivazione delle attività svolte, il sistema dovrà consentire di svolgere le seguenti due attività principali:

• Rilevare il tempo dedicato a ciascun Servizio/Comune, relativamente a personale e automezzi (🡪 Rilevazione durata del servizio);

• Certificare il servizio effettivamente svolto, in termini di strade effettivamente spazzate, cestini effettivamente svuotati, cassonetti svuotati, ecc. (🡪 Rilevazione livello di espletamento del servizio).

Tali attività dovranno essere tendenzialmente svolte direttamente dagli addetti operativi sul campo (tipicamente tramite device mobile), ove possibile in tempo reale, minimizzando le attività di inserimento manuale.

Il concorrente dovrà indicare le specifiche tecniche dei dispositivi mobili che possono essere utilizzati (non è ammesso l’utilizzo di sistemi proprietari).

Dovrà in ogni caso essere possibile la gestione di tale attività in fase di back-office (ad esempio in caso di mancata rilevazione sul campo o per scelte gestionali aziendali).

4.5.1 Rilevazione durata del servizio

Dal momento in cui l’operatore ha premuto il pulsante di “avvio servizio” sino a quando l’operatore ha premuto il pulsante di “conclusione servizio” – come meglio descritto nei paragrafi successivi - il sistema dovrà rilevare il tempo dedicato al Comune/Servizio.

Nel caso di servizio svolto in più Comuni nello stesso turno, dovrà essere possibile, tramite algoritmi parametrizzabili, attribuire ai singoli Comuni i tempi di servizio di propria competenza, nonché i tempi di trasferimento verso gli impianti di destino e/o di trasbordo intermedi, nonché dei tempi di trasferimento dalla sede al primo Comune servito e quelli dall’ultimo al rientro.

Il sistema dovrà consentire l’inserimento di informazioni minime da parte dell’ operatore (ad esempio, la modalità di identificazione di inizio/fine servizio in un Comune nel caso di più Comuni svolti in sequenza nello stesso giro di servizio).

Il sistema dovrà consentire di poter consuntivare/rilevare anche servizi non programmati per quella giornata.

Modalità di “avvio servizio”

Come sopra ricordato, per tutti i servizi, l’attività di consuntivazione del servizio dovrà essere effettuata in prima battuta direttamente dall’operatore addetto al servizio stesso, “sul campo”.

Ad inizio servizio, tramite dispositivo mobile in dotazione, l’operatore dovrà svolgere le seguenti attività:

• Identificarsi;

• Inserire targa dell’automezzo eventualmente utilizzato;

• Specificare (selezionandolo da elenco predefinito) “Comune” o “quartiere del Comune” o “raggruppamento di Comuni” da servire in quel turno di servizio;

• Specificare tipologia di servizio da svolgere (da elenco tendina: es. RD carta; RD vetro; Spazzamento manuale; Servizio di soccorso ecc.);

• Avviare attività di rilevazione (tramite pulsante).

Una volta premuto il pulsante di “avvio servizio”, il sistema dovrà acquisire automaticamente data/ora di avvio del servizio.

Il sistema dovrà consentire la possibilità di identificare automaticamente l’ID dell’operatore e dell’automezzo utilizzato (targa), mediante acquisizione automatica delle informazioni (es. tramite lettura Rfid o altre soluzioni), evitandone l’inserimento manuale.

Il concorrente dovrà indicare le specifiche tecniche dei dispositivi mobili che possono essere utilizzati (non è ammesso l’utilizzo di sistemi proprietari).

Modalità di “conclusione servizio”

A conclusione del servizio, l’operatore dovrà segnalare (tramite pulsante di “chiusura servizio”) che il servizio stesso è stato terminato. Tale conferma dovrà assumere la forma di certificazione (tramite ad esempio pulsante di “doppia conferma”).

Il sistema dovrà automaticamente acquisire data/ora della chiusura dell’attività specifica, e determinare di conseguenza la durata del servizio svolto.

Tutte le informazioni rilevate dovranno essere associate al Comune / area di riferimento.

La rilevazione del servizio effettuata con il sistema mobile, dovrà automaticamente integrarsi, a fine servizio, con i dati del tracciamento rilevati dai sistemi GPS posizionati sui mezzi. Nel caso di discordanza tra quanto dichiarato dall’operatore (es. Comune gestito) e le informazioni rilevate dal sistema GPS, il sistema dovrà segnalare la possibile anomalia e consentirne la gestione in fase di back-office.

I dati identificativi del servizio (es. tipologia di rifiuto raccolto, Comune servito, targa del mezzo, …) dovranno essere utilizzabili per consentire il riconoscimento telematico (es. tramite lettura targa) e l’accesso ad impianti di destino automatizzati.

Rilevazione in back-ground / off-line dell’attività di consuntivazione

Ove l’applicazione fosse installata su smartphone, la rilevazione del tempo dedicato al servizio non dovrà interrompersi a seguito di ricezione/effettuazione di telefonate.

4.5.2 Rilevazione livello di espletamento del servizio

Le modalità di rilevazione/consuntivazione dell’effettivo livello di espletamento del servizio, dipenderanno dalla tipologia di servizio, e potranno richiedere un diverso livello di manualità richiesto all’operatore, come descritto all’interno del presente paragrafo.

In particolare, la rilevazione potrà avvenire con le seguenti tre modalità, a seconda del servizio svolto:

1. Manualmente (ad esempio nel caso dello spazzamento manuale o del ritiro ingombranti a domicilio) attraverso un’autocertificazione del servizio svolto su dispositivo mobile o, in casi eccezionali, in back-office;

2. Manualmente + integrazione dei tracciati GPS (ad esempio nel caso di spazzamento meccanizzato) attraverso un’autocertificazione del servizio svolto su dispositivo mobile ed una successiva integrazione con i dati del tracciamento rilevato con il sistema GPS posizionato sui mezzi;

3. Tramite lettura tag apposti su cestini, sacchi o cassonetti stradali o altro (Casetta Ecologica).

Silea dovrà poter predefinire parametricamente, per ciascuna tipologia di servizio, la modalità di rilevazione da utilizzarsi (scegliendo una delle tre suindicate). In fase di consuntivazione, in base alla tipologia di servizio svolto, sul dispositivo mobile dovranno essere visibili unicamente le informazioni da inserire, (ad esempio targa, Comune, servizio, inizio servizio, fine servizio, etc).

Il sistema dovrà consentire all’operatore di indicare manualmente sul dispositivo mobile, eventuali “mancati servizi” o” anomalie”, selezionando la causale da un elenco predefinito (almeno 5 causali predefinite). La gestione degli elenchi di causali dovrà essere flessibile e facilmente parametrizzabile e modificabile da Silea.

Indipendentemente dalla modalità di consuntivazione utilizzata, il sistema dovrà consentire di visualizzare anche graficamente su cartografia l’esito del servizio, in termini di itinerari (es. strade spazzate) o di punti “singoli” (cestini svuotati, caditoie pulite, ecc.).

Laddove, in fase di progettazione, fosse stato preliminarmente caricato l’elenco degli “oggetti” da gestire (strade, cestini, cassonetti, caditoie, ecc.), il sistema dovrà evidenziare graficamente anche i mancati servizi (es. strade non spazzate, cestini non svuotati, ecc.).

Di seguito si riportano le ipotesi di impiego delle tre suddette modalità di consuntivazione, che il nuovo sistema dovrà consentire, applicate ai diversi servizi.

4.5.2.1 Rilevazione” esito servizio” mediante inserimento manuale

Tale modalità di consuntivazione si potrebbe utilizzare per i seguenti servizi:

• Spazzamento manuale;

• Pulizia caditoie;

• Ritiro a domicilio di rifiuti ingombranti e RAEE.

Spazzamento manuale

Dal momento in cui l’operatore ha premuto il pulsante di “avvio servizio” sul dispositivo mobile in dotazione, sino a quando l’operatore ha premuto il pulsante di “conclusione servizio”, il sistema dovrà tracciare il tempo dedicato al Comune/Servizio.

A fine servizio, tramite l’utilizzo dell’APP, l’operatore ecologico dovrà manualmente “autocertificare” l’effettivo servizio svolto nel corso del tempo rilevato.

Saranno meglio valutate le soluzioni che semplifichino e riducano i tempi di consuntivazione del servizio (ad esempio il sistema potrebbe richiedere di inserire, per eccezione, le sole strade “non spazzate”, dando così per correttamente spazzate tutte le restanti strade inserite nel programma operativo).

Come già ricordato, indipendentemente dalla preventiva progettazione/programmazione del servizio (ad esempio in assenza dell’elenco strade da servire in un Comune), dovrà in ogni caso essere possibile attestare l’avvenuto espletamento (totale o parziale) del servizio.

A consuntivo, il sistema dovrà consentire di visualizzare - graficamente su cartografia e su report sintetico (tipo excel, csv) - sia le strade correttamente servite, sia le strade nelle quali il servizio previsto non è stato effettuato.

Pulizia Caditoie

Ove non già precaricate, il sistema dovrà consentire di acquisire sul campo, tramite dispositivo mobile, la geolocalizzazione delle caditoie (🡪 gestione cartografica) e la fotografia.

Tramite l’utilizzo dell’APP, posizionandosi accanto alla caditoia - anche in assenza di elenco/posizione delle caditoie precaricato - l’operatore dovrà segnalare di aver effettuato il servizio di pulizia di quella caditoia. Il sistema ne acquisirà la posizione GPS e l’esito del servizio (positivo o negativo con relativa causale di mancato servizio) e dovrà consentire la possibilità di allegare fotografie.

A consuntivo, il sistema dovrà consentire di visualizzare graficamente - graficamente su cartografia e su report sintetico (tipo excel, csv) - sia le caditoie correttamente pulite, sia le caditoie nelle quali il servizio previsto non è stato effettuato.

Ritiro a domicilio di rifiuti ingombranti e RAEE

Dal momento in cui l’operatore ha premuto il pulsante di “avvio servizio” sino a quando l’operatore ha premuto il pulsante di “conclusione servizio”, il sistema dovrà tracciare il tempo dedicato al Comune/Servizio.

Posizionandosi nel punto stabilito per il ritiro, l’operatore dovrà segnalare di aver effettuato il ritiro dei rifiuti. Il sistema ne acquisirà la posizione GPS./

Il sistema dovrà consentire la possibilità di allegare fotografie, nonché di acquisire ulteriori informazioni inerenti il ritiro a domicilio (es. numero pezzi raccolti, pezzi ulteriori rispetto al previsto, ecc.).

Il sistema dovrà essere predisposto per potersi integrare con applicativi esterni dedicati al servizio di ritiro a domicilio (gestione prenotazione), acquisendo i dati relativi ai ritiri da effettuare e trasferendo l’esito del servizio effettuato.

Sarà oggetto di valutazione la fornitura di una con soluzione integrata per la gestione end-to-end del servizio di ritiro ingombranti a domicilio, da includere nelle proposte migliorative.

4.5.2.2 Rilevazione” esito servizio” mediante inserimento manuale e tracciati GPS

Tale modalità di consuntivazione, basata sull’autocertificazione e la successiva integrazione con i dati di tracciamento rilevati dai sistemi GPS a bordo mezzo, si potrebbe utilizzare per i seguenti servizi:

• Spazzamento meccanizzato;

• Raccolta rifiuti porta a porta;

• Trasporto rifiuti dai Centri di Raccolta agli impianti di recupero.

Spazzamento meccanizzato

A fine servizio, tramite l’utilizzo dell’APP, l’operatore ecologico dovrà manualmente “autocertificare” l’effettivo servizio svolto nel corso del tempo rilevato.

Saranno meglio valutate le soluzioni che semplifichino e riducano i tempi di consuntivazione del servizio (ad esempio il sistema potrebbe richiedere di inserire “per eccezione” le sole strade “non spazzate” – con relativa indicazione della causale di mancato servizio - dando così per correttamente spazzate tutte le restanti strade, ove inserite nel programma operativo).

A fine servizio, in fase di back-office, l’autocertificazione del servizio effettuata dall’operatore con il sistema mobile, dovrà integrarsi con i dati del tracciamento rilevati dai sistemi GPS posizionati sulla spazzatrice:

• ll sistema dovrà essere in grado di distinguere le strade di semplice “transito” rilevate dal GPS, rispetto a quelle di effettivo servizio: a tal fine il sistema dovrà acquisire le informazioni, georefenziate, anche relative alle attività effettivamente svolte dalla spazzatrice (es. scarico acqua, spazzole abbassate, presa di forza attiva), e tenerne conto ai fini di determinare la consuntivazione del servizio svolto.

• Nel caso di discordanza tra le informazioni rilevate da GPS (es. località non coerente, effettivo utilizzo spazzole) e autocertificazioni manuali, il sistema dovrà segnalare la possibile anomalia e consentirne la gestione in fase di back-office.

Raccolta rifiuti porta a porta

A fine servizio, tramite l’utilizzo dell’APP, l’operatore ecologico dovrà manualmente “autocertificare” l’effettivo servizio svolto nel corso del tempo rilevato.

Il sistema dovrà consentire di semplificare e ridurrei tempi di consuntivazione del servizio (ad esempio il sistema potrebbe richiedere di inserire, per eccezione, le sole strade “non gestite” – con relativa indicazione della causale di mancato servizio - dando così per correttamente effettuate le raccolte in tutte le restanti strade).

Come già ricordato, indipendentemente dalla preventiva progettazione/programmazione del servizio (ad esempio in assenza dell’elenco strade/utenze da servire in un Comune), dovrà in ogni caso essere possibile attestare l’avvenuto espletamento (totale o parziale) del servizio.

• ll sistema dovrà essere in grado di distinguere le strade di semplice “transito” rilevate dal GPS, rispetto a quelle di effettivo servizio: a tal fine il sistema dovrà acquisire le informazioni, georefenziate, anche relative alle attività effettivamente svolte dall’automezzo (es. tempi di fermata, presa di forza attiva), e tenerne conto ai fini di determinare la consuntivazione del servizio svolto;

• Nel caso di discordanza tra le informazioni rilevate da GPS (es. località non coerente) e autocertificazioni manuali, il sistema dovrà segnalare la possibile anomalia e consentirne la gestione in fase di back-office.

Trasporto rifiuti dai Centri di Raccolta agli impianti di recupero

A fine servizio, tramite l’utilizzo dell’APP, l’operatore ecologico dovrà manualmente “autocertificare” l’effettivo servizio svolto nel corso del tempo rilevato.

Come già ricordato, indipendentemente dalla preventiva progettazione/programmazione del servizio (ad esempio in caso di vuotatura cassone non programmata in un Centro di Raccolta), dovrà in ogni caso essere possibile attestare l’avvenuto espletamento (totale o parziale) del servizio.

A fine servizio, in fase di back-office, l’autocertificazione del servizio effettuata dall’operatore con il sistema mobile, dovrà “integrarsi” ed essere “coerente” con i dati del tracciamento rilevati dai sistemi GPS posizionati sui mezzi di raccolta: nel caso di discordanza tra le informazioni rilevate da GPS (es. località non coerente) e autocertificazioni manuali, il sistema dovrà segnalare la possibile anomalia e consentirne la gestione in fase di back-office.

4.5.2.3 Rilevazione” esito servizio” tramite sistemi di lettura TAG

Tale modalità di consuntivazione, basata sulla lettura di TAG identificativi (RFID/NFC o QRCODE), si potrebbe utilizzare per i seguenti servizi:

• Raccolta porta a porta tramite sacchi/contenitori dotati di tag (“tariffa puntuale”)

• Raccolta dedicata utenze non domestiche dotate di cassonetto taggato (“servizi B2B”);

• Svuotamento di cestini dotati di tag;

Raccolta tramite sacchi/contenitori/cassonetti dotati di tag

Dal momento in cui l’operatore ha premuto il pulsante di “avvio servizio” sino a quando l’operatore

ha premuto il pulsante di “conclusione servizio”, il sistema dovrà tracciare il tempo dedicato al

Comune/Servizio.

Il servizio dovrà essere consuntivato acquisendo le letture dei tag effettuate dall’operatore in occasione di ciascuno svuotamento, integrate con i dati di data, ora e coordinate geografiche dello svuotamento.

Nel caso di servizi B2B tramite cassonetti, il sistema dovrà consentire di poter acquisire sul campo, tramite dispositivo mobile, la geolocalizzazione dei contenitori e dovrà consentire la possibilità di allegare fotografie.

I dati puntuali di svuotamento dovranno inoltre poter essere trasmessi ad altri applicativi (es. tariffazione puntuale).

La rilevazione del servizio effettuata con il device mobile in dotazione all’operatore (o tramite antenne nel caso di lettura automatica), a fine servizio dovrà “integrarsi” ed essere “coerente” con i dati del tracciamento rilevati dai sistemi GPS posizionati sui mezzi.

A consuntivo, il sistema dovrà consentire di visualizzare - graficamente su cartografia e tramite elenchi - sia i contenitori correttamente svuotati, sia i contenitori per i quali il servizio previsto non è stato effettuato.

Svuotamento cestini dotati di “tag”

Il sistema dovrà permettere l’acquisizione delle letture dei tag (RFID, NFC, ecc.) applicati sui cestini.

Ove non già precaricato, il sistema dovrà consentire di acquisire sul campo, tramite dispositivo mobile, la geolocalizzazione dei cestini e dovrà consentire la possibilità di allegare fotografie inerenti allo stato del cestino segnalando eventuali anomalie o danneggiamenti.

La rilevazione del servizio effettuata con il sistema mobile in dotazione all’operatore, a fine servizio dovrà “integrarsi” ed essere “coerente” con i dati del tracciamento rilevati dai sistemi GPS posizionati sui mezzi.

A consuntivo, il sistema dovrà consentire di visualizzare - graficamente su cartografia e tramite elenchi - sia i cestini correttamente svuotati, sia i cestini per i quali il servizio previsto non è stato effettuato.

4.5.3 Gestione “segnalazioni” e “non conformità” (da parte dell’operatore)

4.5.3.1 Gestione mancati servizi

Il sistema dovrà consentire all’operatore di indicare manualmente sul dispositivo mobile, eventuali “mancati servizi” o” anomalie” – a livello generale o per singola strada o oggetto da gestire - selezionando la causale da un elenco predefinito (almeno 5 causali predefinite).

La gestione degli elenchi di causali dovrà essere flessibile e facilmente parametrizzabile e modificabile da Silea.

4.5.3.2 Gestione segnalazioni

L’applicazione dovrà consentire all’operatore di effettuare “segnalazioni” (es. cestini rotti, rifiuti abbandonati, ecc.).

Dovrà essere possibile associare fotografie geolocalizzate relative ad una segnalazione. Le foto andranno caricate direttamente nella App.

Il sistema dovrà potersi integrare con applicativi esterni dedicati alla “gestione ticket”, trasmettendo i dati relativi alla segnalazione effettuata dall’operatore attraverso API, webservices o altre modalità definite da Silea.

4.5.3.3 Gestione “sacchi non conformi”

In caso di sacchi di rifiuti non correttamente conferiti dall’utenza (es. sacco non idoneo; rifiuto non corretto; errato giorno/orario di esposizione), attualmente l’operatore è tenuto a non raccoglierli ed a lasciarli su strada, avendo cura di attaccare sul sacco un’etichetta adesiva di “non conformità”, indicando con una “X” la causale di non conformità dall’elenco presente sull’etichetta.

Il nuovo sistema dovrà consentire all’operatore l’inserimento manuale della “causale di non conformità” – già indicata fisicamente sull’adesivo applicato sul sacchetto non conforme - , selezionandola da un elenco predefinito, al fine di disporre di tali informazioni anche in forma digitale.

Sarà oggetto di valutazione, da includere nelle proposte migliorative, la fornitura di soluzioni nelle quali il sistema consenta di “leggere” ed acquisire automaticamente le causali di non conformità già indicate sull’adesivo (es. tramite lettura OCR dell’adesivo) evitandone l’inserimento manuale ed in generale proposte migliorative per la gestione degli adesivi di non conformità.

L’ App dovrà inoltre consentire di acquisire le seguenti informazioni:

• Data/ora;

• Posizione GPS;

• Codice identificativo dell’utenza (nel caso di sacchi dotati di tag);

• Foto ed eventuali note inserite dall’operatore.

I sacchi non conformi dovranno poter essere visibili a fine turno su mappa.

4.5.3.4 Identificazione dell’utenza tramite lettura di tag

Il sistema dovrà consentire all’operatore, in qualsiasi situazione, di poter “leggere” i TAG applicati sui sacchetti/contenitori, attraverso il dispositivo mobile in dotazione (riconoscendo in questo modo l’utenza che ha effettuato il conferimento).

I dati acquisiti (Identificativo utenza, data/ora prelievo, coordinata geografica, ecc.) dovranno essere resi disponibili per altri applicativi (es. misurazione puntuale, controllo qualità conferimenti, sanzioni, ecc.).

L’applicazione in uso all’operatore dovrà consentire di effettuare tutte le suindicate operazioni di segnalazione manuale, di cui ai punti precedenti, senza interrompere la rilevazione del servizio stesso.

4.5.4 Rilevazione peso del rifiuto raccolto e gestione operazioni di “trasbordo”

4.5.4.1 Gestione operazione di “trasbordo” rifiuti e pesate intermedie (nel caso di servizi svolti in più Comuni)

A completamento dei servizi, al fine delle successive operazioni di conferimento ad impianti di trattamento/smaltimento finale, sarà necessario acquisire “dal campo” il peso dei rifiuti da conferire nonché l’esatta attribuzione al Comune produttore.

Gli automezzi che conferiscono agli impianti di trattamento/smaltimento finale possono essere sia quelli direttamente utilizzati nello svolgimento del servizio (es. nel giro di raccolta porta a porta o di spazzamento o di svuotamento cestini) sia mezzi “madre” utilizzati per il trasporto rifiuti a seguito di operazioni di “trasbordo”.

Nel caso di servizio svolto con lo stesso mezzo in più Comuni all’interno dello stesso giro/turno (raccolte porta a porta, svuotamento cestini, ecc.), l’operatore addetto all’operazione di “trasbordo” e trasporto verso impianti di trattamento/smaltimento dovrà poter inserire (manualmente o in qualche modalità automatica) il peso dei rifiuti raccolti nei singoli Comuni (registrati con strumenti a bordo mezzo o tramite pese esterne).

Sarà oggetto di valutazione, da includere nelle proposte migliorative, la fornitura di soluzioni che consentano l’efficace modalità di acquisizione delle pesate, nella logica di minimizzare gli errori di inserimento e di miglior certificabilità del dato (ad esempio evitando il data entry, mediante scansione dello “scontrino” rilasciato dalla pesa).

4.5.4.2 Gestione ingresso presso impianti di trattamento/smaltimento “automatizzati”

Il sistema dovrà consentire la possibilità di accesso degli automezzi ad impianti di trattamento/smaltimento “automatizzati”: tali impianti – gestiti da Silea o da terzi - consentono l’ingresso degli automezzi attraverso sistemi telematici di “riconoscimento” del veicolo e di compilazione automatica dei registri (attraverso software di lettura targhe, sbarre automatizzate, pese, ecc.).

Per tale finalità, il sistema dovrà dunque essere in grado sia di acquisire i dati relativi al servizio svolto (targa del mezzo, tipologia di rifiuto trasportato, Comune produttore, peso del rifiuto raccolto, ecc.) sia di trasmetterli in tempo reale al sistema di ingresso/pesa degli impianti di destino, in modo da consentirne la corretta gestione di conferimento. Il sistema di pesa dell’impianto di destino, dovrà essere in grado di ricevere i dati acquisiti dal sistema ed abbinare correttamente il peso del rifiuto conferito ed il Comune produttore stesso, predisponendo automaticamente la registrazione di ingresso ai sensi della normativa.

4.6 Modalità di gestione del Back Office

Il Fornitore dovrà mettere a disposizione di ▇▇▇▇▇ un sistema di acquisizione, analisi e controllo dei dati di consuntivazione, che consenta di gestire e analizzare il servizio.

Inoltre, il sistema dovrà:

• Consentire di inserire e/o modificare in fase di back-office i dati di consuntivazione del servizio, nel caso di indisponibilità del sistema mobile o di erroneo utilizzo da parte

dell’operatore (tenendo traccia che il dato è stato gestito dal backoffice);

• Richiedere la “validazione finale” (a cura del responsabile, chiamato a confermare l’effettivo svolgimento del servizio) dei dati di consuntivazione inseriti dall’operatore o acquisiti in automatico dal sistema;

• Visualizzare i servizi che sono in attesa di validazione finale;

• Visualizzare in tempo reale, anche su cartografia, i dati di consuntivazione rilevati e ricevuti dai sistemi mobili;

• Consentire di gestire eventuali disservizi;

• Consentire di gestire eventuali anomalie tecniche;

• Consentire di gestire eventuali “incoerenze” tra l’autocertificazione inserita dall’operatore

sul campo (es. Comune servito), ed il riscontro della posizione GPS;

• Consentire di mettere a disposizione di altre piattaforme informatiche i dati rilevati dai propri sistemi;

• Interfacciarsi con altri sistemi per il caricamento/aggiornamento di tutte le anagrafiche (per esempio quelle relative ai mezzi), necessarie al corretto funzionamento del servizio in tutti i suoi aspetti.

Al fine di semplificare l’attività manuale di back-office, il sistema dovrà supportare la gestione efficace delle anomalie(es. mancato abbinamento servizio a GPS, discordanza tra autocertificazioni manuali e rilevazione GPS).

Tutte le anomalie tecniche ed i disservizi consuntivati, dovranno essere raggruppati e filtrati a scelta dell’utente (a prescindere dal “percorso”).

Il responsabile del servizio dovrà, in maniera semplice e flessibile, poter inserire eventuali disservizi (es. mancati ritiri o mancati svuotamenti) all’interno di altri percorsi o creare percorsi “spot” (di soccorso).

Nel caso di ditte terze che non utilizzino il nuovo software di consuntivazione, occorre prevedere anche la possibilità di acquisizione dei loro dati (importazione file predefiniti, portali, ecc.).

4.7 Reporting e controllo

Per consentire la più efficace gestione dei servizi, dovrà essere disponibile una dashboard che renda accessibile in tempo reale le varie informazioni in modo semplice ed immediato, mediante l’utilizzo di tabelle, grafici, riepiloghi, allarmi, segnalazioni, ecc. (“control room”).

Impostando filtri per area, periodo temporale e tipo di rifiuto, il responsabile del servizio o il personale addetto al back-office dovrà, a seconda dei diversi livelli di autorizzazione:

• Poter navigare nella mappa geografica e stampare a qualsiasi livello di zoom le cartografie;

• Analizzare ciascun servizio in dettaglio, con la possibilità di applicare “filtri” su: Comuni, quartieri, singole strade, tipologia di rifiuto, causali di non svolgimento del servizio, ecc.;

• Disporre di viste personalizzabili per l’analisi dei causali di disservizio o dei conferimenti non conformi, anche su mappa;

• Visualizzare sulla mappa anche più di un percorso in contemporanea (sia con i dati di progettazione che con i dati di consuntivazione), di diversi mezzi e di diverse giornate - allo scopo di eseguire verifiche e confronti.

Il sistema dovrà in particolare evidenziare (anche con strumenti di “alert”), in maniera semplice ed efficace, le eventuali anomalie rilevate – riconducili sia ad errati comportamenti dell’operatore sia ad errori tecnici dei sistemi - quali ad esempio:

• Servizi programmati per quel giorno e non consuntivati;

• Incoerenze tra l’autocertificazione inserita dall’operatore sul campo (es. Comune servito), ed il riscontro della posizione GPS;

• Servizi che risultano consuntivati, pur in assenza dell’associazione di personale e automezzo;

• Automezzi che da GPS risultano aver operato, dei quali però non c’è riscontro sulla consuntivazione.

Dovrà inoltre essere fornita una Reportistica di rendicontazione servizi, strutturata e parametrizzabile su diversi periodi temporali (singolo turno, settimana, mese, anno), finalizzata a disporre di un quadro complessivo dell’andamento dei servizi, in ottica di fornire informazioni/dati sia ai Comuni che ad Arera.

🡺 Il sistema dovrà inoltre consentire di disporre degli indicatori di performance (KPI) richiesti dalle delibere ARERA, vigenti e successive.

In particolare, per ciascuna tipologia di servizio previsto da Silea (spazzamento, svuotamento cestini, raccolta carta, raccolta umido, pulizia caditoie, …) e per singolo Comune, dovranno essere disponibili i seguenti dati principali minimi:

• Ore complessivamente lavorate/attribuite al servizio;

• Durata media di svolgimento del servizio;

• Costo medio del servizio;

• % media di completamento servizio;

• Statistica delle causali per mancato servizio/disservizio;

• Statistiche dei sacchi non conformi (comune/quartiere, causale, ecc.);

• Variazioni temporali (tendenza).

Le suddette informazioni dovranno essere rappresentate tramite tabelle, grafici ed eventualmente

mappe, da configurare in maniera semplice e parametrica da Silea.

Tutti i dati e le visualizzazioni dovranno essere esportabili anche in formato csv ed Excel. Il tracciato dovrà inoltre garantire la possibilità di caricamento dei dati su un qualsiasi tipo di cartografia o software GIS.

Tramite l’esposizione dei dati mediante API (integrazione obbligatoria), ▇▇▇▇▇ dovrà poter realizzare ulteriore reportistica tramite Qlik Sense o altri software di business intelligence.

5. REQUISITI NON FUNZIONALI

Viene richiesta la fornitura di una soluzione completa supportata da una piattaforma che permetta una gestione efficiente e resiliente per tutti gli utenti che usufruiscono del servizio.

Gli operatori in particolare dovranno essere in grado di utilizzare la piattaforma sia dagli uffici sia da remoto in modalità mobile worker. Dovrà essere garantita l’interazione e la fruizione sia dai personal computer in dotazione (desktop, terminali virtuali VDI, laptop) che da dispositivi mobili.

Si richiede che i client rispondano a questi requisiti minimi di compatibilità:

• Sistema operativo: Microsoft Windows 10 Professional / Enterprise o superiori;

• Browser: Google Chrome, Microsoft Edge;

• Desktop virtuali erogati da piattaforma WMWARE Horizon versione 8.0 in modalità non persistente tramite dispositivi Praim Meridian;

• Mobile: piattaforma Android.

L’implementazione del Sistema, oggetto del presente capitolato, dovrà rispondere pienamente ai

requisiti non funzionali di seguito dettagliati.

a) Requisiti architetturali

La soluzione proposta dovrà garantire la continuità dei servizi durante l’orario di lavoro e dovrà garantire la possibilità di scalare facilmente risorse/istanze quando necessario. La piattaforma dovrà altresì garantire la continuità operativa assicurando meccanismi di business continuity,

recovery e back up.

In sede di offerta il concorrente dovrà fornire dettagli su come viene gestita l'affidabilità e la disponibilità della soluzione proposta, includendo dettagli di come viene gestito l'eventuale failure applicativo della piattaforma o dei sistemi di comunicazione. Inoltre, dovrà fornire dettagli sulla ridondanza applicata ai diversi livelli applicativi ed infrastrutturali. Il concorrente dovrà dettagliare le policy di disaster & recovery e di business continuity, includendo i tempi previsti per il ripristino delle precedenti configurazioni.

Migrazione ed aggiornamenti della soluzione non dovranno causare perdite di dati o corruzione delle informazioni presenti nel sistema. Il concorrente deve descrivere se la soluzione prevede tali meccanismi e nel caso quali tools esterni possono essere utilizzati per migrare i dati.

Si richiede che i data center su cui sono presenti i dati degli utenti della piattaforma proposta, siano dislocati sul territorio EU. Dovrà inoltre avere almeno una delle seguenti certificazioni:

• AGID;

• UNI CEI ISO/IEC 27001.

Il concorrente dovrà fornire un disegno architetturale della nuova soluzione e studiare il corretto dimensionamento delle licenze e dei server/istanze e predisporre una catena di ambienti (Test/Collaudo, Produzione);

Risulta parte integrante della proposta la messa a disposizione dei seguenti ambienti:

• Ambiente di test/collaudo;

• Ambiente di produzione.

L’ambiente di Test/▇▇▇▇▇▇▇▇ dovrà avere caratteristiche tali da poter replicare esattamente le funzionalità e le performance dell’ambiente di Produzione.

b) Sicurezza, privacy e gestione utenti

Il Sistema dovrà essere implementato dal Fornitore in modo da garantire un elevato livello di sicurezza; pertanto, dovrà essere in grado di supportare adeguati meccanismi di gestione utenze e accessi, di gestione delle sessioni ed essere conforme alle buone pratiche di sicurezza per quanto riguarda la gestione delle vulnerabilità. Nello specifico la gestione di utenti e dei relativi accessi deve tenere conto di specifiche politiche di riservatezza e di protezione dei dati, ovvero garantire l’accesso ai dati esclusivamente ai soggetti autorizzati tramite opportune profilazioni d’utente;

La gestione di tali politiche è supportata da un gestore utenti e un sistema di autenticazione unico e centralizzato ed integrato nel sistema Microsoft Azure per la gestione del SSO. In

particolare, la soluzione dovrà obbligatoriamente validare la user identity e supportare le policy per la gestione delle password e relative policy aziendali.

La soluzione dovrà prevedere un pannello di controllo per permettere la gestione della configurazione da parte dei supervisori e del personale IT addetto agli sviluppi e alla manutenzione.

Si richiede inoltre, per le attività dell’amministratore di sistema, la conformità a quanto indicato con il provvedimento del Garante per la protezione dei dati personali del 27 novembre 2008 riguardante le “Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema” (G.U. n. 300 del 24 dicembre 2008).

c) Unicità, tracciabilità e storicizzazione di dati e documenti

L’unicità delle informazioni è un requisito imprescindibile: dati replicati e ridondati incrementano pericolosamente la possibilità di propagazione degli errori oltre a rallentare sensibilmente le attività operative.

Si richiede pertanto che dal punto di vista operativo il Sistema proposto sia implementato dal Fornitore in modo da garantire che il dato possa essere inserito una e una sola volta tra i diversi sistemi interessati in modo razionale e tempestivo.

Per quanto riguarda l’integrità del dato, il modulo deve essere implementato in modo da impedire l’alterazione diretta o indiretta delle informazioni, sia da parte di utenti e processi non autorizzati, che a seguito di eventi accidentali. Anche la perdita di dati (per esempio a seguito di cancellazione o danneggiamento) viene considerata come alterazione.

Dovrà essere assicurata la tracciabilità di tutte le registrazioni informatiche effettuate sulle procedure, sia per i dati e sia per i documenti, ovvero il modulo deve consentire di risalire a chi ha effettuato e quando ogni singola registrazione/modifica in ogni fase del processo.

L’identificazione della data e ora di una registrazione deve essere effettuata mediante l’apposizione dell’indicazione del tempo di sistema, che deve essere opportunamente gestito dal Sistema secondo procedure che ne garantiscano la coerenza.

Inoltre, l’applicativo deve contenere tutti i meccanismi necessari a garantire la congruenza dei dati e report di controllo.

d) Integrazione, interoperabilità, aderenza agli standard

L’implementazione del Sistema dovrà essere attuata utilizzando protocolli e metodi standard e allo stato dell’arte rispetto all’attuale livello di innovazione tecnologica del settore.

L’adozione di protocolli standard deve essere finalizzata anche a garantire l’interfacciamento del

sistema con sistemi di parti terze laddove previsto.

Ciò deve essere possibile sia attraverso lo scambio dati su tracciati predefiniti e concordati tra le parti, sia attraverso la chiamata a web-services esposti dai sistemi che dovranno comunicare. Le interfacce di integrazione dovranno quindi poter abilitare lo scambio dati sia sincrono che asincrono verso soluzioni applicative esterne alla piattaforma.

e) Accessibilità e usabilità

Si richiede che il livello di presentazione dei dati abbia caratteristiche tali da rispettare requisiti di accessibilità e usabilità. A tale scopo le interfacce di accesso dovranno prevedere l’inserimento e la consultazione agevole e leggibile delle informazioni gestite, attraverso un accesso configurato al sistema (sistema adattativo), anche per mezzo di aree di sintesi o evidenza.

Per garantire l’accessibilità del Sistema da parte di tutti gli utenti, le informazioni devono essere facilmente reperibili, esplicitate in modo chiaro e rese di indubbia interpretazione.

f) Obblighi del fornitore inerenti alla sicurezza dei dati personali

Il Fornitore garantisce che le soluzioni informatiche utilizzate durante la progettazione, lo sviluppo e la prestazione dei servizi, le attività di raccolta, instradamento, trattamento, memorizzazione e/o archiviazione nonché di visualizzazione dei dati e/o informazioni sui servizi degli utenti finali siano adeguate, pertinenti e limitate a quanto strettamente necessario per la prestazione dei servizi stessi nel rispetto della normativa applicabile al Fornitore.

È fatto obbligo al Fornitore di monitorare costantemente le minacce e le vulnerabilità, nonché di rivedere periodicamente gli scenari di rischio che hanno impatti sui servizi erogati dal Fornitore, sui processi critici e sulle risorse informatiche.

Il Fornitore si obbliga a garantire la riservatezza, l’integrità e la disponibilità delle risorse logiche e fisiche critiche utilizzate per l’erogazione del Servizio, e dei dati e/o informazioni. Resto fermo l’obbligo di attuare le misure di sicurezza idonee alla protezione dei sistemi nonché di garantire l’efficacia delle stesse nel corso dell’esecuzione del Contratto.

Resta espressamente inteso che il Fornitore, fermo restando quanto previsto in altre clausole del Contratto e negli allegati, e per quanto di propria competenza, si obbliga al rispetto della normativa e/o del regolamento e/o del provvedimento generale e/o specifico che sia applicabile al Fornitore rispetto all’oggetto del Contratto anche qualora emanato da ARERA e/od Autorità Amministrative e/o di Vigilanza.

g) Log

Tutti i log generati o comunque detenuti dal Fornitore in esecuzione del Contratto sono sottoposti alle seguenti previsioni:

• Tutti i log raccolti in base al provvedimento del Garante per la protezione dei dati personali sugli amministratori di sistema del 27 novembre 2008 sono mantenuti per un tempo non inferiore a dodici mesi e consultabili presso la propria sede da Silea;

• Tutti i log raccolti a seguito di eventuali obblighi di legge e/o regolamento e/o disposizione normativa di ogni genere e natura sono mantenuti per il tempo minimo previsto dalla norma e consultabili presso la propria sede;

• Ogni e qualunque log il cui mantenimento non sia richiesto da previsioni di legge e il cui mantenimento non sia stato normato nel Contratto e/o negli allegati ma che sia giudicato dal Fornitore utile o necessario per l’erogazione dei servizi, saranno mantenuti dal Fornitore per il tempo strettamente necessario alla finalità della raccolta;

• Resta espressamente inteso che qualora Silea abbia necessità di effettuare indagini e/o verifiche sui log, il Fornitore presterà ogni necessario supporto.

5.1 Sicurezza dei dati

Il Fornitore dovrà dichiarare di garantire di aver adottato le misure di sicurezza fisiche, logiche e organizzative (di seguito: “Misure”).

Il Fornitore nei limiti di cui alla presente fornitura, si obbliga a tenere la Committente manlevata e indenne da qualunque conseguenza pregiudizievole dovesse derivarle a seguito della mancata adozione da parte del Fornitore delle Misure.

Resta espressamente inteso che sarà cura e responsabilità del Fornitore verificare che quanto sopra sia adempiuto altresì da suoi eventuali subappaltatori. In ogni caso, il Fornitore si obbliga a rispettare quanto previsto nella allegata nomina a responsabile del trattamento in relazione alla sicurezza dei dati.

Il Fornitore si obbliga altresì a comunicare da quando ne viene a conoscenza e comunque entro 5 (cinque) giorni per iscritto alla Committente una violazione della riservatezza o dell’integrità dei dati personali trattati in esecuzione del presente Contratto.

Resta espressamente inteso che il Fornitore avrà l’obbligo di adeguare le Misure e di modificare ogni

obbligazione prevista dal Contratto secondo quanto previsto ai precedenti articoli

6. REALIZZAZIONE DEL PROGETTO

L’aggiudicatario dovrà provvedere a tutte le azioni necessarie all’implementazione chiavi in mano del nuovo software. Il sistema dovrà essere inoltre integrato e scambiare dati automaticamente con gli altri applicativi aziendali, attivi in esercizio.

6.1 Documentazione di progetto

Tutta la documentazione prodotta in fase di realizzazione del progetto, dovrà essere scritta in lingua italiana.

L’aggiudicatario dovrà utilizzare gli standard documentali identificati da ▇▇▇▇▇. Tale documentazione in generale riguarda:

• Requisiti utente;

• Specifica funzionale;

• Documentazione dei processi;

• Disegno della base dati relativamente a tutte le parti del sistema che contengono “personalizzazioni” e/o funzioni di integrazione con gli altri applicativi aziendali (diagramma entità relazioni e documento con descrizione dettagliata di ciò che rappresentano le tabelle e i relativi attributi);

• Disegno dell’architettura del sistema e delle funzioni software realizzate per le “personalizzazioni” e l’integrazione con gli altri applicativi aziendali (con particolare attenzione alle parti d’integrazione con gli altri applicativi aziendali);

• Disegno del flusso dei dati relativamente a tutte le parti del sistema che contengono

“personalizzazioni” e/o funzioni di integrazione con gli altri sistemi aziendali;

• Specifica dei test;

• Manuale utente.

Tutta la documentazione prodotta dovrà essere caratterizzata da:

• Comprensibilità;

• Completezza;

• Accuratezza.

L’utilizzo di strumenti e tools di documentazione, che dovranno comunque rispondere a criteri di larga diffusione di mercato, dovranno essere concordati con Silea. Resta comunque vincolante l’utilizzo dei seguenti strumenti:

• Per il text editor: Microsoft Word;

• Per il Project Management: Microsoft Project; Power Point;

• Per la gestione dei fogli elettronici: Microsoft Excel.

Tutta la documentazione dovrà essere consegnata in formato elettronico editabile, oltre che nel formato sorgente dei vari tool utilizzati.

6.2 Fasi progettuali

Di seguito si riporta una descrizione delle modalità di esecuzione delle fasi principali di progetto che l’aggiudicatario dovrà eseguire, in collaborazione con il personale della Direzione Information Technology e dei Process Owner e Key User di Silea.

6.2.1 Project Management

L’aggiudicatario dovrà identificare un Project Manager (PM), che per tutta la durata del progetto si occuperà di:

• Definire e monitorare il piano di progetto, in termini di attività e tempi;

• Definire e governare le attività di tutti gli attori coinvolti, sia interni al team di progetto dell’aggiudicatario, che relativi a Silea;

• Organizzare incontri di avanzamento periodici;

• Garantire l’organizzazione, la qualità e l’efficienza delle attività di progetto.

6.2.2 Raccolta ed analisi dei requisiti utente

Entro 20 giorni solari dall’aggiudicazione dell’appalto, i Responsabili di Silea SpA e quelli dell’Aggiudicatario dovranno incontrarsi per verificare nel dettaglio il “piano della fornitura” come offerto in sede di gara, di descrizione delle attività, dettaglio e tempistiche di implementazione.

L’aggiudicatario dovrà predisporre un documento contenente i requisiti utente, descrivendo analiticamente tutte le eventuali personalizzazioni richieste da ▇▇▇▇▇. Tale documento dovrà essere approvato da ▇▇▇▇▇.

6.2.3 Progettazione di dettaglio, configurazione e parametrizzazione del sistema

Conclusa la prima fase di definizione e approvazione dei requisiti da parte di ▇▇▇▇▇, dovrà essere configurato il nuovo sistema.

L’aggiudicatario dovrà provvedere a:

• Disegno della nuova architettura applicativa;

• Disegno e configurazione dell’applicativo;

• Disegno e sviluppo di funzionalità non supportate out-of-the-box individuate durante la fase di analisi funzionale;

• Disegno e configurazione di tutte le interfacce richieste con gli altri applicativi.

L’aggiudicatario si occuperà anche di garantire l’integrazione con servizi terzi e di test di connettività

simulata.

In questa fase sarà consolidato anche il piano di progetto che dovrà comunque rispettare le scadenze richieste da ▇▇▇▇▇.

Le scelte implementative e di parametrizzazione a carico dell’aggiudicatario dovranno essere documentate adeguatamente, secondo la metodologia scelta dall’aggiudicatario. Il sistema realizzato dovrà garantire le seguenti funzionalità di tipo trasversale, necessarie per il collaudo finale del progetto:

• Assicurare la completa copertura di tutte le aree funzionali di interesse rispetto al progetto esecutivo;

• Garantire una parametrizzazione multi-azienda, multidevice;

• Organizzare la profilatura utente tramite menu facilmente comprensibili;

• Garantire meccanismi di gestione della sicurezza sia a livello di dati sia a livello dei privilegi di accesso degli utenti applicativi;

• Parametrizzare gli accessi al sistema coerentemente con le procedure in uso in Silea;

• Integrazione controllo accessi con il sistema aziendale in uso (Microsoft Azure AD / Microsoft Active Directory).

6.2.4 Personalizzazioni

Si intendono le attività di sviluppo software necessarie per poter tradurre a sistema, eventuali requisiti espressi da Silea, che non trovano copertura nelle funzionalità standard, ma che sono ritenuti necessari per l’avvio in esercizio del sistema.

L’aggiudicatario dovrà garantire n. 25 giornate, oltre a quelle previste come migliorie, da utilizzare per le personalizzazioni, senza alcun onere aggiuntivo per Silea SpA.

L’eventuale software prodotto durante la fase realizzativa delle personalizzazioni dovrà essere corredato da documentazione tecnica e da manuale di collaudo, in modo tale da permettere all’aggiudicatario di eliminare preventivamente bug di prodotto prima di mettere a disposizione del personale IT il software per l’effettuazione di test utente.

L’esito positivo del test utente è condizione necessaria al rilascio ed al collaudo delle

personalizzazioni.

6.2.5 Integrazione con sistemi esterni

Si intendono le attività di analisi, sviluppo e test necessarie a integrare con i sistemi già presenti in Silea che necessitano di allineamento/scambio dati.

Si prevede la realizzazione di interfacce sia on-line che batch per permettere le integrazioni fra i diversi sistemi.

Al termine della fase di analisi, l’appaltatore dovrà produrre la relativa documentazione funzionale. L’eventuale software prodotto durante la fase realizzativa dovrà essere corredato da documentazione tecnica.

L’esito positivo dei test utente è condizione necessaria al rilascio ed al collaudo del software.

Applicativi esistenti

Il sistema dovrà essere utilizzato ed eventualmente integrato in un contesto ove operano i seguenti sistemi:

Processo/Contenuto funzionale	Prodotto/Fornitore	Indicazioni tecniche
Tracciamento veicoli	Soluzione Viasat	Il tracciamento avviene tramite dispositivi GPS installati sui mezzi. La soluzione proposta dovrà essere integrabile anche sistemi/soluzioni differenti
Customer Relationship Management	Soluzione SIUNET (Greenext)	Erogato in modalità SaaS mediante soluzione integrata nella piattaforma Greenext
Pubblicazione informazioni sui servizi da APP cittadini	App Differenziati (Greenext)	È predisposto un sistema di scambio dati su piattaforma proprietaria
Pubblicazione calendario servizi su sito aziendale		È predisposto un sistema di scambio dati tramite file predefiniti
Gestione anagrafiche utenti	SileaEcoportal (Sielco)	Integrazione tramite API
Call Center	Genesys Pure Cloud	Integrazione tramite API Genesys Pure Cloud
Reportistica di Business Intelligence	QlikSense	In logica ETL, è predisposto un sistema di scambio dati tramite file predefiniti

Gestione anagrafica e disponibilità personale Silea addetto alla raccolta	INAZ	Integrazione di sistema mediante scambio dati tramite file predefiniti
Fleet Management	Drivevolve	Integrazione ad oggi non ancora implementata. Da valutare in sede di progetto se procedere mediante API standard o interscambio mediante file
Portali di ditte esterne (appaltatori)		Integrazione mediante la definizione di uno standard da far adottare per l’intercambio dati oppure mediante portale web dedicato.
Registrazione carichi ingresso / uscita impianti	Da identificare	Integrazione ad oggi non ancora implementata. Da valutare in sede di progetto se procedere mediante API standard o interscambio mediante file
Gestione utenze di accesso	Microsoft Azure AD	Integrazione per gestione SSO tramite integrazione standard Microsoft

6.2.6 Conversione e migrazione dati

Attività non richiesta.

6.2.7 System ed Integration Test

Al termine di ogni ciclo di sviluppo è richiesto che l’aggiudicatario effettui una serie di test interni funzionali sulle nuove implementazioni (System Test), a valle dei quali, se non sono stati individuati bug bloccanti, verranno effettuati gli Integration Test con i sistemi esterni coinvolti.

Tutti i test dovranno prevedere la documentazione di supporto (Test book), predisposta dall’aggiudicatario e validata dalla Direzione IT di Silea, che racchiuda tutti i test case necessari alla validazione delle funzionalità delineate, e che preveda il dettaglio delle attività di test di:

• Sistema (rispondenza del sistema ai requisiti individuati durante la fase di analisi);

• Integrazione del sistema (corretto funzionamento del dialogo con gli altri sistemi con cui sono previste interfacce).

I bug individuati dovranno essere tracciati attraverso una piattaforma di bug reporting, che verrà anch’essa concordata dall'aggiudicatario con l’IT di Silea nelle fasi progettuali preliminari.

6.2.8 Collaudo

Al termine di un ciclo di sviluppo, è richiesto che il team effettui una serie di test interni funzionali sulle nuove implementazioni.

In particolare:

• Dovrà essere configurato un ambiente di test per la nuova piattaforma;

• Dovrà essere configurata una o più postazioni di test che ricalchino esattamente le postazioni operatore di produzione.

I test sull’ambiente/sull’applicativo di test devono prevedere una documentazione di supporto (Test book) che includa tutti i casi-di-test necessari alla validazione delle funzionalità delineate.

Il Test book dovrà essere approvato da ▇▇▇▇▇.

Laddove richiesto, gli operatori responsabili di Silea possono richiedere supporto on-site o da remoto al team del Fornitore nello svolgimento di sessioni congiunte di collaudi (User Acceptance Test, UAT), con lo scopo di verificare funzionalità, integrazioni con servizi terzi ed individuare eventuali bug.

Durante questa fase, i Process Owner e Key User di Silea, in collaborazione con l’aggiudicatario, dovranno svolgere tutti i test previsti, secondo quanto espresso nei requisiti definiti in fase di analisi.

Il ciclo di collaudo dovrà essere eseguito al termine di ogni iterazione di sviluppo. L’esito del collaudo potrà essere:

• Positivo: il sistema è completo in tutte le sue parti, inclusa la documentazione, non sono presenti anomalie di funzionamento e i tempi di risposta sono adeguati; pertanto, Silea redigerà un apposito Verbale di Accettazione e il sistema potrà passare alla fase successiva di avvio in esercizio.

• Positivo con riserva: il sistema è completo in tutte le sue parti, inclusa la documentazione, i tempi di risposta sono adeguati e sono presenti solo errori (bugs) valutati da Silea come “non gravi” e “non pregiudicanti per la messa in esercizio”. Silea redigerà un apposito Verbale di Accettazione in cui saranno elencate le suddette anomalie e il sistema potrà passare alla fase successiva di avvio in esercizio. L’aggiudicatario dovrà provvedere all’eliminazione di tutti i difetti riscontrati entro 15 giorni lavorativi dalla data di redazione del verbale di accettazione.

• Negativo: il sistema non è completo in tutte le sue parti, inclusa la documentazione, oppure i tempi di esecuzione non sono adeguati, oppure sono presenti errori (bugs) valutati da Silea come “gravi” e “pregiudicanti per la messa in esercizio”, pertanto il sistema non riceverà l’autorizzazione alla messa in esercizio. L’aggiudicatario dovrà correggere tutte le anomalie (discordanze rispetto alla documentazione tecnica, incompletezze, bugs, tempi di

esecuzione non adeguati, ecc.) rilevate entro 20 giorni lavorativi dalla data di termine del collaudo. Successivamente dovrà avvenire un nuovo collaudo.

Prima del Go-Live di ogni sviluppo, l’aggiudicatario dovrà prevedere un ciclo di test su tutto l’applicativo così da verificarne l'integrità completa (test di non regressione).

6.2.9 Formazione

Si intendono le attività necessarie all'acquisizione da parte delle diverse tipologie di utenti delle competenze richieste per operare efficacemente sulla piattaforma. Si richiede l'elaborazione di un piano formativo basato sull'integrazione di metodologie didattiche differenti (formazione d'aula, formazione online) in funzione delle caratteristiche dei destinatari, della loro numerosità e degli obiettivi di apprendimento.

Formazione separata dovrà essere erogata per gli operatori IT di Silea. Si richiede un minimo di 15 giornate di formazione.

6.2.10 Avvio in esercizio

L’applicativo potrà essere reso operativo unicamente se il relativo collaudo avrà avuto esito positivo o positivo con riserva.

A seguito della validazione avvenuta nella fase di collaudo, l’aggiudicatario dovrà provvedere alla migrazione in produzione delle configurazioni e delle personalizzazioni necessarie alla messa in esercizio dei nuovi applicativi.

La fase di Go-Live avverrà al termine della fase di migrazione in produzione.

L’aggiudicatario dovrà predisporre il piano di roll-out, ove saranno incluse tutte le attività operative e tecniche relative all’attivazione dei nuovi sistemi, sia business che IT, alla migrazione delle configurazioni ed allo spegnimento dei sistemi attuali coordinandosi con tutti i fornitori, gli utenti e l’IT di Silea.

6.2.11 Supporto Post Go-Live

A seguito del Go-Live, l’aggiudicatario dovrà assicurare la presenza, nelle sedi di Silea o attraverso Microsoft Teams o altri tools di instant messaging e videoconferenza, di tutti gli analisti funzionali del team di progetto a supporto dell’attività degli utenti, e comunque, la disponibilità di tutto il team per la pronta risoluzione di eventuali anomalie.

Tale servizio si concretizza in un supporto strutturato con l’obiettivo di:

• Fornire a Silea un valido affiancamento operativo nel consolidamento delle conoscenze acquisite in fase di formazione, nel contesto di esercizio del sistema;

• Correggere prontamente eventuali difetti e anomalie di funzionamento del sistema;

• Analizzare ulteriori parametrizzazioni di base non emerse nella fase di analisi per valutarne la realizzazione.

La chiusura della fase avverrà esclusivamente a seguito di emissione di verbale di accettazione da parte di ▇▇▇▇▇ e comunque non prima dello scadere del periodo pari a 90 giorni.

6.3 Tempi di progetto

Entro 20 giorni solari dall’aggiudicazione dell’appalto, i Responsabili di Silea SpA e quelli

dell’Aggiudicatario dovranno incontrarsi per verificare nel dettaglio il “piano della fornitura” come

offerto in sede di gara, di descrizione delle attività, dettaglio e tempistiche di implementazione.

In tale sede il Fornitore dovrà indicare le condizioni organizzative, logistiche e tecniche che il Fornitore stesso e ▇▇▇▇▇ dovranno predisporre affinché possa essere rispettato il piano di avanzamento lavori.

Il piano della fornitura dovrà prevedere rilasci successivi. In particolare:

1) Rilascio delle funzionalità base (ovvero funzionalità Core);

2) Rilascio delle funzionalità aggiuntive/migliorie proposte dal fornitore in sede di gara.

Di seguito si riporta la time line dei principali deliverable di progetto:

Attività	Timing	Deliverable
Primo Incontro	Entro 20 giorni solari dall’aggiudicazione	Piano della fornitura
Raccolta, analisi e documentazione requisiti	Secondo la tempistica indicata nella proposta tecnica
Go Live delle funzionalità base	Secondo la tempistica indicata nella proposta tecnica

Go Live delle funzionalità aggiuntive proposte dal fornitore in sede di gara	Secondo la tempistica indicata nella proposta tecnica
Documentazione di progetto e prodotto consolidata	Secondo la tempistica indicata nella proposta tecnica
Formazione	Secondo la tempistica indicata nella proposta tecnica
Conclusione	180 giorni dall’aggiudicazione
Post Go Live	90 giorni solari successivi alla conclusione

Per il rilascio delle funzionalità aggiuntive/migliorative, il fornitore dovrà proporre in fase di gara un

piano di rilascio coerente con l’intero progetto.

La formazione potrà essere pianificata anche dopo la messa in produzione.

Il prodotto non si considererà consegnato, ad insindacabile giudizio di ▇▇▇▇▇, se il software fornito sarà ritenuto non adeguato e/o in assenza di affiancamento al personale Silea per renderlo autonomo nell’inserimento, modifica, parametrizzazione e gestione.

I termini di consegna si intendono comprensivi di ogni e qualsiasi tempo necessario per l'espletamento degli impegni da parte del Fornitore, incluse eventuali approvazioni, autorizzazioni, collaudi, ecc., secondo quanto previsto nel presente Capitolato.

7. SERVIZI DI ASSISTENZA E MANUTENZIONE

Il servizio di assistenza e manutenzione relativo al sistema, ha una durata complessiva pari a 5 anni a far data dal Go-live.

Per la componente di Incident & Problem Management è richiesto di:

• Ripristinare il corretto funzionamento dei servizi di produzione in ottemperanza ai livelli di servizio di seguito indicati, minimizzando gli impatti negativi sull'utente finale.

• Garantire la gestione di incidenti di qualsiasi genere segnalati o tramite servizio di monitoraggio o su indicazione di Silea ed aventi un effetto totale o parziale sul livello di servizio erogato;

• Nella componente di Problem Management (processo finalizzato a minimizzare l'impatto sul business degli incidenti sull'infrastruttura, prevenendo la ricorrenza di tali incidenti) individuazione e eliminazione della 'root cause' degli incidenti. Il servizio di Problem Management dovrà tracciare i dettagli relativi agli incidenti di servizio occorsi, mirando a prevenirne la ricorrenza e/o il peggioramento (estensione di perimetro ed effetto), definendone gli elementi costitutivi (problem determination), individuando e rimuovendone le cause (problem solving);

• Tracciare gli Incidenti sulla base del monitoraggio e di eventuali segnalazioni di Silea;

• Effettuare la classificazione di Incident/Problem e stabilire i livelli di priorità degli Incident/Problem (Alta, Media, Bassa), in base ai seguenti criteri di Impatto (numero utenti coinvolti) e Urgenza:

Impact Urgency	Impatto BASSO	Impatto MEDIO	Impatto ALTO
Urgenza BASSA	BASSO	BASSO	MEDIO
Urgenza MEDIA	BASSO	MEDIO	ALTO
Urgenza ALTA	MEDIO	ALTO	ALTO

✓ Priorità ALTO: Incidenti che bloccano e/o compromettono gravemente il servizio di produzione e richiedono una presa in carico e una gestione/analisi immediata oltre che una conseguente risoluzione in ottemperanza ai livelli di servizio di seguito indicati.

✓ Priorità MEDIO: Incidenti che richiedono un’analisi tempestiva ma che non richiedono necessariamente una gestione/risoluzione immediata; questi incidenti devono comunque essere notificati a Silea per la valutazione e pianificazione degli interventi risolutivi.

✓ Priorità BASSO: Incidenti che non provocano disservizi massivi e non necessitano di analisi approfondite; trattasi di eventi che vengono comunque registrati e notificati a Silea ma la cui gestione/risoluzione può avvenire attraverso una successiva pianificazione.

• Gestire il ciclo di vita del ticket assicurando la conferma di chiusura;

• Assicurare autonomamente le attività per la risoluzione dell’Incident/Problem in linea con le procedure di change management concordate. In caso contrario, procedere alla condivisione e pianificazione dell’attività;

• Gestire gli Incident/Problem, compresi eventuali coinvolgimenti di fornitori terzi;

• Coinvolgere in tempi adeguati all’urgenza il supporto di secondo livello di eventuali fornitori terzi;

• Eseguire diagnosi per incidenti di impatto generale, fornendo un’adeguata documentazione e avviando attività di prevenzione future.

Tutte le richieste di assistenza saranno aperte direttamente dagli utenti del sistema attraverso la creazione di ticket. Nella fase di creazione dei ticket gli utenti definiranno la tipologia di Incident e il livello di gravità della segnalazione. I ticket saranno assegnati automaticamente al gruppo di lavoro del fornitore.

Per la gestione dei ticket, il fornitore dovrà utilizzare un sistema di ticket management. Il fornitore potrà scegliere di utilizzare un sistema proprio oppure, preferibilmente per Silea, integrarsi o utilizzare il sistema Jira Service Managemet di Silea.

Nella fase di presa in carico il fornitore dovrà effettuare le seguenti attività:

• Verifica della corretta tipologia del ticket e rettifica della stessa in caso di errore commesso dall’utente;

• Verifica del corretto livello di gravità segnalato e rettifica dello stesso, in accordo con il Referente Silea, in caso di errore commesso dall’utente.

Nel caso di malfunzionamenti dovuti ad aggiornamenti effettuati è richiesto al fornitore di:

• Coordinare e supportare l’intero iter di analisi, diagnosi e risoluzione del problema;

• Attivare le strutture di sviluppo per l’eventuale modifica di procedure interne;

• Attivare le strutture operative per il rilascio e l’applicazione delle eventuali modifiche;

• Comunicare l’avvenuta risoluzione del problema per la sua chiusura alla struttura che l’ha segnalato;

• Effettuare le necessarie escalation, verso Silea e verso le ditte fornitrici richiedendo il rispetto dei tempi previsti di intervento.

È, quindi, nell’ambito di questo servizio che viene richiesta all’appaltatore la piena gestione delle procedure previste dalle condizioni contrattuali di manutenzione ed il controllo delle relative attività erogate dalle diverse ditte fornitrici delle componenti hardware e software di proprietà di Silea o di servizi e coinvolte dal presente bando.

È altresì responsabilità dell’aggiudicatario garantire la massima affidabilità dei cambiamenti di configurazione indotti dalle attività di amministrazione dei diversi ambienti.

Aspetti evolutivi, introduzione di nuove tecnologie saranno regolati con approccio progettuale.

Nel servizio di manutenzione il fornitore dovrà mettere a disposizione una risorsa, per l’intera durata del servizio, con il ruolo di Service Manager. La risorsa si occuperà di garantire l’organizzazione, la qualità e l’efficienza del servizio svolto. Il Service Manager parteciperà a riunioni di avanzamento periodiche.

7.1 Manutenzione correttiva

La manutenzione correttiva comprende tutte le attività per il ripristino dell’operatività a seguito di eventi che implicano un pericolo per la sicurezza o un rischio di violazione della sicurezza dei dati e dei sistemi o il degrado o l’interruzione del funzionamento del servizio, attraverso la diagnosi e la rimozione delle cause e degli effetti di malfunzionamenti, parziali o totali, di tutti i moduli applicativi (errori logici e tecnico/funzionali), al fine di garantire la costante operatività del software stesso, nonché l’aderenza alle specifiche funzionali e tecniche.

Rientrano altresì nella manutenzione correttiva, tutti gli adeguamenti richiesti dalla normativa o dai regolamenti Arera.

Il servizio riguarderà:

• Moduli della soluzione proposta;

• Personalizzazioni dei suddetti moduli;

• Software relativo alle interfacce di comunicazione e scambio dati verso altri sistemi aziendali;

• Ogni elemento facente parte dell’intero sistema proposto.

Rientrano nella Manutenzione Correttiva le seguenti attività:

• Diagnosi del malfunzionamento;

• Rimozione degli errori/difetti e dei relativi effetti che gli stessi hanno provocato;

• Contributi di competenza specialistica di prodotto necessari alla corretta soluzione del malfunzionamento;

• Test in ambiente di collaudo della soluzione realizzata;

• Allineamento della documentazione;

• Allineamento degli eventuali script automatici;

• Installazione in ambiente di esercizio;

• Segnalazione delle correttive effettuate per allineamento del software in corso di sviluppo/modifica/collaudo;

• Supporto all’attività diagnostica sulla causa del malfunzionamento le cui cause non sono imputabili a errori/difetti presenti nel software applicativo.

Il livello di degrado e la relativa priorità degli interventi (Livello di Gravità) saranno definiti dagli

utenti all’atto della richiesta d’intervento. La ditta appaltatrice, a valle della notifica dell’anomalia,

dovrà avviare le attività di soluzione del malfunzionamento e interagire con il personale Silea per discutere dei dettagli tecnici ed eventualmente per concordare un diverso livello di gravità.

Una volta definito il livello di gravità, l’intervento dovrà essere svolto nel rispetto dei livelli di servizio

definiti e per i quali i tempi di presa in carico e di risoluzione.

Le attività di manutenzione correttiva dovranno garantire la non regressione del codice, ovvero l’introduzione di nuovi difetti (bugs) del software (a livello generale del prodotto) dovuti alle modifiche effettuate per la realizzazione della patch o per la rimozione di un malfunzionamento.

Il prodotto dovrà quindi comportarsi secondo quanto descritto nella documentazione tecnico/funzionale del sistema.

Il fornitore dovrà fornire i nominativi dei propri tecnici referenti con i quali gli incaricati di ▇▇▇▇▇ si interfacceranno per la soluzione delle problematiche tecniche emergenti.

7.2 Service Level Agreement

La ditta aggiudicataria deve garantire il rispetto dei seguenti livelli di servizio.

Per la componente di Incident & Problem Management si riporta nel seguito la tabella riepilogativa dei livelli di servizio richiesti e le relative penali associate, che Silea SpA si riserva di applicare.

Definizione

Copertura

Oraria

SLA di

riferimento

Livello di servizio

Penali

Tempo di presa in carico

Lunedì –

Venerdì 08:00 – 17:30

dalla data/ora di apertura della

segnalazione

Tempo di risoluzione Incident in Priorità ALTO

Lunedì –

Venerdì 08:00 – 17:30

dalla data/ora di apertura della segnalazione

Per ogni superamento di incident con priorità ALTO rispetto allo SLA proposto

100 € per ogni giorno lavorativo eccedente

Tempo di risoluzione Incident in Priorità MEDIO

Lunedì –

Venerdì 08:00 – 17:30

dalla data/ora di apertura della

segnalazione

Per ogni superamento di incident con priorità MEDIO rispetto allo SLA proposto

50€ per ogni giorno lavorativo eccedente

Tempo di risoluzione Incident in Priorità BASSO

Lunedì –

Venerdì 08:00 – 17:30

40h

dalla data/ora di apertura della segnalazione

Per ogni superamento di incident con priorità BASSO rispetto allo SLA proposto

25€ per ogni giorno lavorativo eccedente

Nel caso in cui non vengano rispettate le tempistiche suindicate, ▇▇▇▇▇ procederà con l’applicazione

delle penali.

Qualora le prove di efficienza eseguite dal responsabile ▇▇▇▇▇ o da un suo sostituto dessero esito negativo, la chiamata non potrà essere considerata chiusa.

Si rimanda inoltre, per le applicazioni delle penali, al capitolato amministrativo.

CAPITOLATO TECNICO

Document Metadata

Document Metadata

Table of Contents