Distribuzione Elettrica Adriatica S.p.A. Area Sistemi Informativi Area Commerciale

Il presente documento e le sue appendici definiscono i requisiti minimi ed è inteso a fornire informazioni rispetto alla richiesta di fornitura di un sistema software per la gestione del servizio di distribuzione e misura di energia elettrica e delle attività correlate di integrazione con i sistemi legacy esistenti adeguati alle esigenze ed alle aspettative di Distribuzione Elettrica Adriatica

S.p.A. (di seguito anche DEA S.p.A.) in termini di quantità, qualità e livelli di servizio.

2. Acronimi e definizioni

Acronimi	Definizione
ASI	Area Sistemi Informativi
DEA S.p.A. o	Distribuzione Elettrica Adriatica S.p.A.
Committente o cliente o l’Azienda	Distribuzione Elettrica Adriatica S.p.A.
Sistema Software o Ambiente Software o Software Applicativo	Se non diversamente indicato, il software oggetto della presente fornitura
AT	Alta Tensione
BT	Bassa Tensione
FORNITORE o Appaltatore	La ditta aggiudicataria della fornitura
MT	Media Tensione
POD	Point of Delivery
RTN	Rete di Trasporto Nazionale
SLA	Service Level Agreement / livelli di servizio
SW	Software

Tabella 1

3. Informazioni su DEA S.p.A.

Distribuzione Elettrica Adriatica SpA, svolge l’attività di distribuzione e misura di energia elettrica nei confronti di circa 32.500 punti di fornitura finali dislocati nei comuni di Osimo (AN), Recanati (MC) e Polverigi (AN).

La Società fa parte del gruppo ASTEA, nell’ambito del quale svolge le attività sopra descritte, oltre allo svolgimento del servizio di gestione di impianti di illuminazione pubblica.

Il gruppo ASTEA svolge le seguenti attività:

- l’attività di distribuzione e misura dell’energia elettrica (attività in concessione), mediante Distribuzione Elettrica Adriatica SpA controllata al 93% dalla capogruppo;

- l’attività di vendita dell’energia elettrica/gas naturale sia sul mercato libero che tutelato, mediante Astea Energia SpA controllata al 94% sempre dalla capogruppo.

- L’attività di distribuzione e misura di gas naturale.

- L’attività di produzione Energia Elettrica

- L’attività di gestione del servizio Igiene Urbana

Per le ragioni esposte, Distribuzione Elettrica Adriatica SpA, è soggetta alle norme di separazione funzionale ai sensi del TIUF (Testo Integrato Unbundling Funzionale).

Nel dettaglio il parco clienti di Dea S.p.A. al 31/12/2015 era così costituito:

Tipologia cliente	Numero totale utenze attive	Di cui produttori
BT uso domestico	24.691	1.164
BT altri usi	7.468	344
MT altri usi	255	106

4. Definizione della fornitura

4.1. Oggetto della fornitura

DEA S.p.A. ha di recente avviato una rivalutazione delle strategie di utilizzo dei propri sistemi software di Gestione del Servizio Distribuzione e Misura Energia Elettrica.

In seguito a valutazioni di carattere strategico e operativo tale riflessione ha portato, rispetto ai diversi scenari possibili, alla valutazione di modificare l’attuale modalità di fruizione del software e dei relativi servizi di manutenzione, per coprire le mutate esigenze dell’Azienda, adeguandone allo stato dell’arte i requisiti tecnici e le funzionalità.

Il presente capitolato, dunque, ha lo scopo di definire le esigenze, il perimetro e i requisiti in base ai quali verrà selezionato il FORNITORE di un nuovo Ambiente Software per la gestione del servizio di Distribuzione e Misura di Energia Elettrica. Tale fornitura dovrà pertanto comprendere almeno quanto di seguito previsto:

• Fornitura, installazione, configurazione e personalizzazione dell’Ambiente Software e delle relative licenze di utilizzo, compreso SW di terze parti (cd. middleware), secondo i requisiti espressi in seguito (vedi paragrafo 6).

• Import nel SW Applicativo dei dati attualmente presenti, secondo il tracciato origine distribuzione descritto in Allegato “DEA_TRACCIATI_SIU32.XLSX”, esportati dal software "SIU32" di ENGINEERING attualmente utilizzato. Per tutti i dati per i quali non verrà fornito da DEA S.p.A un tracciato di input, sarà concordata con il FORNITORE la modalità di import dei dati stessi. Verifica della corretta importazione della base dati.

• Collaudo dell’Applicativo secondo le specifiche di DEA S.p.A., per la verifica della rispondenza rispetto ai requisiti espressi.

• Integrazione della soluzione con gli Applicativi esistenti in DEA S.p.A. (cd. Applicativi Legacy).

• Implementazione di un ambiente di test per finalità di formazione e prove di patch o di nuove funzionalità

• Attività di formazione agli utenti DEA S.p.A. a supporto del corretto utilizzo dell’Applicativo erogate presso la sede del cliente con presenza fisica del personale del FORNITORE.

• Attività di supporto erogate presso la sede del cliente con presenza fisica del personale del FORNITORE durante la fase di “post avvio” (come di seguito definita) per il supporto in fase iniziale di utilizzo del sistema in produzione;

• Licenza d’uso dell’Applicativo non esclusiva ed a tempo indeterminato.

• Servizi di manutenzione correttiva, adeguativa ed evolutiva dell’Applicativo. Seguono ulteriori dettagli sulle modalità di erogazione nel paragrafo 8.

Si sottolinea che i servizi di manutenzione saranno estesi e validi per tutti i moduli/applicativi che completano la soluzione software, inclusi eventuali SW di terze parti (cd. middleware) non presenti nell’infrastruttura attuale di DEA S.p.A.

Si sottolinea inoltre che la fornitura non include l’attività di esportazione dei dati dalla soluzione applicativa attualmente in essere che sarà totalmente a carico di DEA S.p.A. nel periodo che precederà il rilascio in ambiente di collaudo.

Nel seguito del documento si riportano i dettagli funzionali e tecnici relativi alla fornitura richiesta.

4.2. Elementi di dimensionamento dell’Ambiente Software

Allo stato attuale è possibile indicare i seguenti dettagli relativi al contesto della fornitura:

• Numero di POD da gestire alla data di avvio: 35.300 circa di cui 32.500 utenze attive;

• Numero di utenti aziendali del sistema: circa 25 operatori;

• Numero di utenti per il “Portale Web”: circa 60 utenti del trasporto.

• Numero di contatori GME teleletti: circa 500

• Numero di utenti utilizzatori di software applicativo di campo (palmare o smartphone): circa 15

4.3. Attività e Tempistiche

Di seguito si elencano le varie fasi di sviluppo del progetto con le tempistiche attese:

Fase	Attività	Tempistiche
A	AVVIO E DEPLOYMENT – Avvio del progetto, deployment dell’infrastruttura (DB, Sistemi operativi, Middleware) e degli applicativi, popolamento dell’ambiente di collaudo con dati prelevati dall’attuale ambiente di produzione, parametrizzazione dell’ambiente. Formazione del personale dell’Area Sistemi Informativi.	A partire dalla data di stipula del contratto. Durata massima 60 gg solari (esclusa formazione).
B	COLLAUDO – collaudo dell’ambiente con i dati di produzione di DEA, con l’obbiettivo di: verificare la congruenza dei dati importati, testare le funzionalità prioritarie (“CORE”) indicate al paragrafo 6, testare l’integrazione del sistema con gli ambienti legacy aziendali. Al termine del collaudo è previsto il deployment di un ambiente di test separato. Formazione del personale “key user”	Inizio attività entro 60 gg solari dalla data di stipula del contratto. Durata massima prevista 45 gg solari.
C	GO LIVE – a seguito del positivo superamento del collaudo delle funzionalità “CORE”: migrazione dei dati in effettivo e messa in produzione dell’applicativo.	Durata massima 15 gg solari a partire dalla data di positivo superamento del collaudo
D	POST AVVIO - Supporto “on-site” da parte del Fornitore nella fase di Post Avvio. Collaudo delle funzionalità “NON CORE”, eventuali attività di	Durata massima 90 gg a partire dal

	messa a punto delle funzionalità “CORE”. Messa in produzione delle funzionalità “NON CORE”. Messa in funzione dell’ambiente di Test	termine della fase C
E	CHIUSURA PROGETTO – Termine della fase di “post avvio”	Al termine della fase D
F	INIZIO PERIODO DI GARANZIA	Durata di mesi 24 a partire dal termine della fase D
G	FINE PERIODO DI GARANZIA

Tabella 2

In sede di offerta il FORNITORE dovrà indicare quindi un Piano di Lavoro di massima relativo all’oggetto della fornitura a partire dalla data di avvio attività coerente con le tempistiche sopracitate (vedi anche paragrafo 7.3 e seguenti).

Nel calcolo dei giorni solari vengono esclusi il mese di agosto e 15 giorni del periodo natalizio.

5. Vincoli e Prerequisiti della fornitura

5.1. Caratteristiche generali e vincoli

La fornitura richiesta dovrà rispettare almeno i vincoli e prerequisiti generali sintetizzati di seguito, e puntualizzati nell’ambito del presente documento:

1. Non comportare, da parte di DEA S.p.A., alcun investimento, non previsto alla data di redazione del presente capitolato, in infrastrutture hardware e componenti software, in quanto:

a. Il FORNITORE dovrà assicurare la corretta funzionalità dell’applicativo all’interno dell’architettura attuale, descritta nel seguito nel paragrafo 5.3, eventualmente facendosi carico delle integrazioni necessarie (sistemi operativi, RDBMS, ecc.).

b. La fruizione del servizio da parte degli utenti avverrà tramite le postazioni di lavoro già in esercizio presso DEA S.p.A.

2. Garantire la fruizione di tutte le funzionalità richieste e descritte nel seguito attraverso un’applicazione i cui componenti siano prodotti dal FORNITORE stesso e siano caratterizzati da un’unica interfaccia grafica (escludendo eventualmente le interfacce di amministrazione);

3. Garantire altresì la modularità, poiché la soluzione realizzata dovrà essere espandibile in ogni momento in funzione di necessità future;

4. Garantire un buon livello di scalabilità dimensionale, rendendo le prestazioni sostanzialmente indipendenti sia dagli utenti simultaneamente attivi sia nel caso di significative variazioni del perimetro (per esempio a seguito di future acquisizioni che dovessero essere effettuate da DEA S.p.A.);

5. Essere conforme agli standard applicativi più comuni in termini di usabilità e accessibilità;

6. Garantire agli utenti rapidi tempi di accesso e di interazione rispetto alle funzionalità previste dall’Applicativo;

7. Fornire adeguata flessibilità rispetto all’evoluzione della normativa in materia;

8. Garantire che l’infrastruttura IT dove sarà installata l’applicazione sia di proprietà del Gruppo Astea e non dovrà essere data in outsourcing.

Le caratteristiche del sistema per l’erogazione del servizio richiesto, in ogni caso, dovranno garantire la minimizzazione dei rischi operativi (es. ritardi o mancate partenze imputabili alle

componenti software del FORNITORE) in funzione delle potenzialità hardware messe a disposizione di DEA S.p.A. e validate dal FORNITORE.

5.2. Tutela dati, riservatezza e sicurezza informatica

Il presente paragrafo descrive i requisiti che il FORNITORE e il software proposto devono possedere per la corretta erogazione della fornitura prevista dal contratto, in ambito di sicurezza e tutela dei dati.

Tali requisiti sono minimi ed essenziali per la partecipazione alla procedura di Gara. L’ambito a cui si riferiscono è costituito dai dati relativi agli utenti del trasporto di DEA S.p.A. e ai clienti finali, titolari dei punti di prelievo, e più in generale a qualsiasi dato personale, ai sensi del D.lgs. 196/2003, trasmesso e/o elaborato dal FORNITORE, integrati con le informazioni relative all’erogazione dei servizi verso tali soggetti.

Rischi che si vogliono mitigare:

• Non compliance a leggi e normative sulla riservatezza dei dati (vedi successivo paragrafo)

• Furto o divulgazione di informazioni a soggetti non autorizzati;

• Modifica fraudolenta o accidentale dei dati elaborati dal FORNITORE;

• Indisponibilità del servizio erogato dal FORNITORE a causa di eventi naturali, errori di gestione o attacchi intenzionali (es. DDOS);

• Danni a terzi (es. diffusione di virus) a causa della mancata protezione dei sistemi gestiti dal FORNITORE per conto di DEA S.p.A.;

5.2.1. Conformità del fornitore a requisiti legislativi in materia di sicurezza e riservatezza delle informazioni

Al FORNITORE è richiesta la conformità alle seguenti normative:

- TIUF (Testo unico Unbundling Funzionale).

- D.lgs. 196/2003 e successive modificazioni in materia di protezione dei dati personali.

- D.lgs. 231/2001 e successive integrazioni

A tal fine, in fase di stipula del contratto verranno sottoscritti dal fornitore specifici impegni relativi a: riservatezza in merito all’accesso alle informazioni commercialmente sensibili di DEA S.p.A., al rispetto del Codice di Protezione dei dati personali, e al rispetto delle indicazioni contenute nel D.lgs. 231/2001

Inoltre il fornitore deve assicurare la conformità legislativa sull’utilizzo di materiale sottoposto a copyright e licenze per software necessari all’erogazione della fornitura in oggetto.

5.2.2. Funzionalità del software

Di seguito sono riportati i prerequisiti specifici di sicurezza che devono essere garantiti dal FORNITORE nell’ambito del software fornito. In particolare:

• L’applicativo oggetto della fornitura dovrà gestire l’identificazione e l’autenticazione di tutti i soggetti che accedono, in accordo alle policy DEA S.p.A. di sicurezza informatica, o quantomeno alle misure minime previste dall’allegato B del D. Lgs. 196/2003.

• Il sistema deve supportare la definizione di profili personalizzabili in funzione dei quali abilitare gli operatori che vi appartengono alla fruizione di sottoinsiemi limitati di funzionalità. La gestione delle autorizzazioni potrà andare dal generale (es. processo di fatturazione) fino alla singola funzionalità.

• Il sistema deve consentire l’abilitazione di determinati operatori all’utilizzo del sistema con riferimento a determinate aree geografiche precedentemente definite.

• L’interconnessione fra il sistema oggetto della fornitura, i sistemi di DEA S.p.A. ed eventuali sistemi esterni (per maggiori dettagli fare riferimento al successivo paragrafo 6.3) dovrà essere conforme alle policy DEA S.p.A. di network security.

• Il FORNITORE, per l’intera durata del contratto, ai sensi del D.lgs. 196/2003, deve tempestivamente comunicare eventuali variazioni nei rapporti di lavoro e/o di mansione dei propri dipendenti e collaboratori coinvolti nel progetto. Questo per consentire a DEA la coerente modifica dei profili di autorizzazione e autenticazione memorizzati all’interno del proprio ambiente software.

• Il sistema di autorizzazione deve essere costituito da profili di accesso coerenti con il minimo livello di privilegio necessario per l’esecuzione delle attività previste.

• Qualsiasi azione o tentativo di azione critica ai fini di sicurezza (es. accesso degli amministratori di sistema o azione concordata con DEA S.p.A.) deve essere tracciato in modalità non-ripudiabile riconducibile ad una persona fisica (Identity Management e Log Management). I log devono essere conservati per almeno 6 mesi.

• In caso di incidente di sicurezza informatica, il FORNITORE deve adottare corrette procedure di monitoring e incident handling per contenere l’incidente e ridurre gli impatti. Devono essere concordate con DEA S.p.A. adeguati livelli di escalation e deve essere prodotto report periodico degli incidenti accaduti.

• Devono essere previsti procedure e strumenti per il salvataggio dei dati concordate con il cliente in base alle policy standard di backup di DEA; I dati di DEA S.p.A. eventualmente trasmessi su rete pubblica devono essere crittografati secondo gli standard di sicurezza più recenti e universalmente riconosciuti.

• Per quanto riguarda gli aspetti di Privacy, il FORNITORE, dovrà garantire l’aderenza dell’ambiente software a quanto previsto dal “Codice in materia di protezione dei Dati Personali” (DL 196/2003), e certificare ciò mediante anche sottoscrizione di apposito documento. Il FORNITORE dovrà produrre per DEA S.p.A. una dichiarazione di conformità annuale del sistema software fornito.

5.2.3. Attività di analisi e gestione del rischio

Il fornitore si impegna ad effettuare, in data concordata con il cliente, con cadenza almeno annuale e per tutta la durata del contratto, delle attività di “vulnerability assessment” sul sistema software fornito, al fine di valutare potenziali rischi di sicurezza. I risultati di tale verifica e le eventuali azioni correttive devono essere trasmesse a DEA S.p.A. entro 20 gg solari dalla data di effettuazione dei test.

In caso di segnalazione da parte di DEA S.p.A. di una sospetta attività fraudolenta, il FORNITORE deve garantire tempestivo intervento atto alla risoluzione del problema e fornire supporto all’analisi delle cause che hanno portato all’incidente.

5.3. Scenario di implementazione nella infrastruttura tecnologica di DEA S.p.A.

Di seguito si illustra l’attuale ambiente infrastrutturale di DEA S.p.A. dove dovrà essere installato l’Ambiente Software. Si precisa che DEA S.p.A. richiede l’utilizzo anche di un ambiente di test, pertanto il dimensionamento dell’ambiente (server virtuali) dovrà essere previsto in linea con le esigenze di gestire due ambienti logicamente separati, in una ottica di sicurezza, performance e scalabilità.

Elemento Architetturale	Caratteristiche
Ambiente Operativo Server	Server virtuali su infrastruttura VMWare vSphere 6.0 U2

Sistema Operativo Server	Windows Server 2012 R2 Datacenter
RDBMS	Oracle Database Standard 11g o superiore in ambiente Windows (licenze per processore)
Risorse Hardware Server	CPU classe XEON 2.6 GHz E5-2660 v3 RAM disponibile totale per i server virtuali: 64 GB Spazio disco totale disponibile: 1 TB
Ambiente Operativo Client	Microsoft Windows 7 Professional, Windows 8.1 Pro, Windows 10 Pro, Windows Server 2008 R2 Remote Desktop Services (thin client)

Tabella 3

In particolare lo scenario architetturale dovrà prevedere almeno:

1) DB Server (ospitato nella LAN aziendale)

2) Application Server (ospitato nella LAN aziendale)

3) Portale Web del Distributore (ospitato in DMZ)

Costituirà titolo di preferenza l’utilizzo di tecnologia Web per la fruizione dell’Ambiente Software verso i client aziendali.

Si ribadisce che la presente fornitura non dovrà comportare, da parte del committente, alcun investimento in infrastrutture hardware e componenti software o middleware, in quanto il FORNITORE dovrà assicurare la corretta funzionalità dell’Ambiente Software all’interno dell’architettura illustrata in Tabella 3. Qualsiasi costo legato ad elementi di infrastruttura (hardware o software o sistemi operativi) attualmente non previsti da DEA S.p.A. (ad es. MS SQL Server o Citrix XenApp) saranno a carico del FORNITORE.

5.4. Modalità di erogazione della fornitura

Le modalità di erogazione della Fornitura prevedono che le attività vengano svolte sia presso la sede del FORNITORE (ad es. per quanto riguarda le attività connesse all’implementazione degli applicativi) sia presso la sede centrale di DEA (ad es. per quanto riguarda le attività che richiedono interazione con il personale aziendale che utilizzerà il sistema, per Raccolta Requisiti, Analisi Funzionale, Formazione, Test e Collaudi, Integrazioni ecc.) durante i normali orari di lavoro.

5.5. Subappalto

La stazione appaltante vieta la possibilità di subappalto.

5.6. Durata del contratto

Il contratto ha validità a partire dalla data di stipula e avrà termine alla data di scadenza dei servizi di manutenzione sottoscritti.

5.7. Prezzi

I prezzi della fornitura dell’ambiente software sono da intendersi come fissi ed invariabili e comprensivi di tutti gli oneri occorrenti a realizzare l’oggetto della fornitura in conformità alle previsioni contrattuali e a perfetta regola d’arte. Il FORNITORE non potrà pretendere aumenti di prezzo, richiedere indennità e compensi particolari o la risoluzione del contratto, adducendo a motivo errori di valutazione in sede di presentazione dell’offerta.

E’ esclusa l’applicazione dell’art. 1664, 1° comma, del codice civile.

Di seguito si elencano le modalità con cui dovranno essere forniti i prezzi di ogni singola componente dell’offerta, sulla base delle definizioni presenti nel paragrafo 6, 7 e 8.

5.7.1. Licenze d’uso

I prezzi per la fornitura di licenze d’uso dell’Ambiente Software (sia per le componenti proprietarie che di terze parti) sono espressi a corpo, per singolo gruppo (funzionalità “CORE” e “NON CORE”, OPZIONALI, middleware), sulla base del degli elementi di dimensionamento indicati nel presente capitolato, e sono uso illimitato nel tempo.

In caso di richiesta di ampliamenti fino ad un massimo del 3% di ciascuno degli elementi di dimensionamento, per nuove esigenze della società, l’Appaltatore dovrà fornirli a titolo gratuito.

5.7.2. Attività di progetto

Il prezzo per tutte le attività di progetto volte alla messa in produzione dell’Ambiente Software debitamente collaudato e certificato sono espressi a corpo. In via non esaustiva le attività di progetto comprendono:

• Attività di Installazione, configurazione e parametrizzazione dell’Ambiente Software, compreso software di terze parti (ambiente di collaudo, di produzione, di test)

• Attività di implementazione di tutte le funzionalità previste al paragrafo 6 del presente capitolato.

• Attività di importazione dei dati dall’attuale ambiente di produzione (ambiente di collaudo, produzione e test)

• Attività di collaudo

• Attività di messa in produzione del sistema

• Attività di supporto all’integrazione della soluzione con gli Applicativi Legacy

5.7.3. Attività di formazione

I prezzi per ciascuna sessione di formazione sono espressi a corpo.

5.7.4. Assistenza nella fase di Post Avvio

I prezzi per il servizio di assistenza nella fase di post avvio sono offerti a corpo.

5.7.5. Manutenzione degli applicativi

I prezzi per i canoni di Manutenzione Correttiva e Adeguativa sono espressi a corpo. Resta inteso che il pagamento dei canoni ai relativi prezzi indicati decorrerà a partire dal termine del collaudo delle funzionalità “NON CORE” per la Manutenzione Adeguativa e al termine del periodo di garanzia per la manutenzione Correttiva.

I prezzi relativi al servizio di Manutenzione Evolutiva saranno quotati a giornata/uomo. Ai fini della formazione del prezzo di offerta, si ipotizza la fruizione di 15 giornate uomo all’anno per un totale di 60 gg/uu nell’ambito della durata contrattuale.

I prezzi espressi per i canoni di manutenzione sono fissi ed invariabili per tutta la durata del contratto.

5.8. Garanzie

5.8.1. Cauzione provvisoria

Si rimanda al Disciplinare di Gara.

5.8.2.Polizza fideiussoria definitiva

Il FORNITORE deve costituire, prima dell’inizio delle attività oggetto del presente appalto, una garanzia fideiussoria bancaria “a prima richiesta” per il contratto sottoscritto con DEA S.p.A., contenente la rinuncia ad avvalersi delle eccezioni di cui agli artt. 1945 e 1957 c.c. pari al 10% dell’importo contrattuale, a garanzia del mancato o non completo adempimento delle obbligazioni contrattuali.

Tale garanzia dovrà essere redatta in conformità all’art. 103 del D.Lgs. 50/2016 e avrà validità fino alla fine del contratto, avvero fino al termine dei periodi di manutenzione – correttiva ed adeguativa - degli applicativi.

La mancata presentazione della fideiussione nelle forme e nei tempi contrattualmente previsti darà luogo alla risoluzione del contratto per colpa del FORNITORE con diritto per DEA S.p.A. di pretendere il risarcimento dei danni subiti.

La garanzia cesserà di avere efficacia dal momento della conclusione del contratto.

5.8.3.Garanzia di buon funzionamento delle forniture (Periodo di Garanzia)

L’Appaltatore garantisce che i beni forniti sono immuni da vizi in conformità a quanto previsto dagli art. 1490 s.s. c.c.

In deroga all’art. 1495 c.c., DEA S.p.A. si riserva la facoltà di effettuare il collaudo e di notificare gli eventuali vizi entro 60 giorni dalla scoperta degli stessi.

L’Appaltatore garantisce ai sensi dell’art. 1512 c.c. per la durata di 24 mesi dalla data di positivo esito di collaudo funzionalità “NON CORE” (fine fase D), il buon funzionamento dell’Ambiente software, tale da assicurarne la completa funzionalità.

La garanzia si intende estesa all’intero sistema: l’appaltatore garantisce che i vari componenti siano compatibili tra loro e che interagiscano in modo tale da soddisfare tutti i requisiti di cui al presente Capitolato.

Durante il periodo di garanzia e qualora si renda necessario, l’Appaltatore deve ripristinare le funzionalità del sistema in modo tale da riportarle allo stesso stato di efficienza che avrebbero dovuto avere (in conformità ai requisiti descritti al paragrafo 6).

Gli interventi devono essere effettuati nei tempi e nei modi richiesti nel servizio di manutenzione “full service” (vedi paragrafo 8).

5.9. Recesso e risoluzione del contratto

5.9.1.Recesso

DEA S.p.A. ha facoltà di recedere dal contratto in qualunque momento, dandone un preavviso di almeno 120 giorni solari. In questo caso essa è tenuta al pagamento delle prestazioni regolarmente eseguite ai prezzi di contratto, nonché al solo pagamento, a titolo di indennizzo, di una somma pari al decimo (calcolato sulla differenza fra l'importo dei quattro quinti del prezzo che è servito di base al contratto e l'ammontare netto delle prestazioni eseguite) dell'importo delle prestazioni non eseguite.

Il recesso si verifica automaticamente nel momento in cui perviene al domicilio del FORNITORE la lettera raccomandata con la quale DEA S.p.A. esprime la propria volontà di recedere dal contratto.

5.9.2.Risoluzione

In caso di inadempimento del contratto, DEA S.p.A. può valutare di risolvere il contratto secondo le modalità di seguito indicate.

In caso di risoluzione, la società affida la fornitura ad un soggetto terzo a spese del FORNITORE, rimanendo impregiudicato ogni ulteriore diritto, ivi compreso quello di agire per il risarcimento dei danni.

La società può dichiarare la risoluzione del contratto qualora il FORNITORE si renda responsabile di frode o di grave negligenza nei confronti della società stessa o di terzi, tali da menomare il rapporto di fiducia che sta alla base del contratto.

La risoluzione del contratto può altresì essere dichiarata qualora nel corso dello stesso vengano a mancare i requisiti di affidamento previsti dalla normativa sulla lotta alla delinquenza mafiosa.

In caso di inadempimento degli obblighi contrattuali, DEA S.p.A. comunica per iscritto al FORNITORE le inadempienze riscontrate, ingiungendogli di adeguarsi, entro un congruo termine, alle prescrizioni impartite per la corretta esecuzione del contratto.

Qualora le attività del presente contratto non vengano condotte secondo le prescrizioni o rimanessero sospese per cause imputabili al FORNITORE, DEA S.p.A. può dichiarare risolto il contratto se, in seguito a formale diffida, nel termine perentorio ed improrogabile di quindici giorni non venga garantita la regolare e continuativa esecuzione delle attività contrattuali.

Alla scadenza del termine, si procede ad una constatazione, a cui il FORNITORE può partecipare, delle attività effettuate per l'adeguamento alle suddette prescrizioni.

Qualora, a giudizio di DEA S.p.A., tali attività non fossero sufficienti, viene comunicata al FORNITORE, con lettera raccomandata, la risoluzione del contratto.

In caso di esito negativo del primo collaudo delle funzionalità “CORE”, il presente contratto viene risolto ai sensi dell’art. 1456 c.c.

E’ interesse primario di DEA S.p.A. che tutti coloro che incorrano in relazioni d’affari con esse svolgano la propria attività in osservanza dei principi e dei valori contenuti nei rispettivi Codici etici.

Qualsiasi violazione grave o reiterata dei principi contenuti nel Codice etico, ai paragrafi di competenza, è considerato un inadempimento degli obblighi scaturenti dal presente contratto e determina la risoluzione del contratto stesso ai sensi dell’art. 1456 c.c., nonché il risarcimento dei danni eventualmente subiti dalla società.

Il presente contratto viene comunque risolto ex art. 1456 c.c. in caso di commissione di un reato previsto dal D.Lgs. 231/01 e successive modifiche e integrazioni, accertato con sentenza passata in giudicato o a seguito di applicazione della pena su richiesta delle parti ex art. 444 c.p.p., nonché in caso di irrogazione, anche in sede cautelare, delle sanzioni interdittive del divieto di contrattare con la pubblica amministrazione o dell’interdizione dall’esercizio dell’attività.

In tutti i casi di risoluzione per sua colpa del contratto, il FORNITORE ha diritto soltanto al pagamento delle prestazioni regolarmente eseguite, ai prezzi di contratto, ed è tenuto al risarcimento di tutti i danni derivanti dall'inadempimento, fra cui il rimborso dei maggiori costi derivanti alla società dalla stipulazione di un nuovo contratto o comunque dalla necessità di procurarsi in altro modo le prestazioni oggetto di contratto.

Il contratto è inoltre risolto dalla data della dichiarazione di fallimento dell’Appaltatore. DEA S.p.A. ha facoltà di dichiarare, con comunicazione scritta, la risoluzione del contratto qualora l’Appaltatore sia ammesso ad una procedura di amministrazione controllata o straordinaria ovvero chieda di essere ammesso ad un concordato extrafallimentare o preventivo.

In ogni caso, DEA S.p.A. non corrisponderà alcun compenso per le prestazioni non eseguite o non correttamente eseguite.

5.10. Legge applicabile, controversie, fori competenti

Ai contratti regolati dal presente capitolato si applica la legge italiana.

Nel caso di disputa o disaccordo tra le parti, con riferimento all’interpretazione di una qualsiasi clausola del Contratto che verrà stipulato o ai rispettivi adempimenti, e comunque ogni volta in cui una delle parti ne faccia richiesta con congruo preavviso, ciascuna parte nominerà un rappresentante incaricato di incontrarsi con la controparte per risolvere la controversia.

I rappresentanti si incontreranno con la frequenza che le parti riterranno necessaria per raccogliere e scambiarsi tutte le informazioni relative al problema in discussione ritenute utili per favorire il raggiungimento di una soluzione.

Per tutte le controversie fra DEA S.p.A. e il FORNITORE per le quali non sia stata possibile una soluzione in sede di conciliazione, è competente esclusivamente il Foro della sede legale di DEA

S.p.A. (foro di Ancona).

Sono a carico del FORNITORE tutte le spese del contratto, compresi gli oneri di registrazione e le spese di copia del contratto stesso, degli eventuali disegni e degli altri allegati necessari. A carico del FORNITORE sono pure tutte le spese di bollo inerenti agli atti occorrenti durante l'esecuzione del contratto.

6. Requisiti della fornitura

6.1. Requisiti non funzionali richiesti ai fini dell’ammissione alla gara

Si rimanda al Disciplinare di Gara

6.1.1. Dimensione ed Organizzazione

Si rimanda al Disciplinare di Gara

6.1.2.Certificazioni di Qualità

Si rimanda al Disciplinare di Gara

6.2. Requisiti Funzionali

Di seguito vengono elencate le funzionalità minime che il nuovo ambiente software per la gestione del servizio di Distribuzione e Misura Energia Elettrica dovrà garantire, suddivise per Aree Funzionali. Tale elenco costituisce la base a partire dalla quale i rispondenti dovranno proporre una soluzione esaustiva a copertura delle funzionalità. Il FORNITORE qualora risulti aggiudicatario della fornitura, è tenuto obbligatoriamente, e senza oneri aggiuntivi per DEA, ad implementare anche le funzionalità dichiarate “NON DISPONIBILI” ai sensi del Disciplinare di Gara.

Nell’ambito di tale elenco, per ogni funzionalità indicata come OPZIONALE, il FORNITORE è tenuto ad esplicitare e descrivere la soluzione proposta: DEA S.p.A. tuttavia, si riserva la facoltà di richiedere o meno l’implementazione del modulo stesso, in relazione alle disposizioni normative del settore e/o esigenze aziendali.

Il sistema deve garantire inoltre il rispetto della normativa vigente nel settore distribuzione e misura energia elettrica e degli obblighi informativi per le aziende distributrici di riferimento, sia nei contenuti che nei formati, previsti da:

- Autorità per l’Energia Elettrica, il Gas e il Sistema Idrico

- TERNA

- Acquirente Unico

- Gestore dei Servizi Energetici

- Camera di Commercio

- Cassa per i Servizi Energetici e Ambientali

- Agenzia delle Dogane

L’ambiente software inoltre dovrà recepire i testi integrati di riferimento, le relative delibere dai quali derivano, gli eventuali loro aggiornamenti, le relative determine, a cui DEA S.p.A. come gestore del servizio di distribuzione e misura energia elettrica dovrà conformarsi. Tali documenti sono consultabili all’indirizzo xxxx://xxx.xxxxxxxx.xxxxxxx.xx/xx/xxxxxxxxx/xxx_%00xxxxxxxxxxxxx.xxx presente all’interno del sito dell’AEEGSII.

A titolo esemplificativo e non esaustivo si elencano di seguito alcuni dei testi di riferimento:

- TIBEG: Bonus Energia Elettrica e Gas

- TIC: Condizioni economiche per l'erogazione del servizio di connessione

- TICA: Condizioni tecniche ed economiche per la connessione alle reti elettriche con obbligo di connessione di terzi degli impianti di produzione

- TIME: Disposizioni per l'erogazione del servizio di misura

- TIMOE: Morosità Elettrica

- TIQE: Regolazione output-based dei servizi di distribuzione e misura dell'energia elettrica, per il periodo di regolazione 2016-2023

- TIS: Regolazione delle partite fisiche ed economiche del servizio di dispacciamento (settlement)

- TISP: Modalità e delle condizioni tecnico-economiche per lo scambio sul posto

- TISSPC: Regolazione dei Sistemi Semplici di Produzione e Consumo

- TIT: Disposizioni per l'erogazione dei servizi di trasmissione e distribuzione

- TIUC: Unbundling Contabile

- TIUF: Unbundling Funzionale

- TIV: Erogazione dei servizi di vendita dell'energia elettrica di maggior tutela e di salvaguardia ai clienti finali

- TUP: Testo unico ricognitivo della produzione elettrica

- CADE: Codice di Rete Tipo per il servizio di trasporto dell’Energia Elettrica

Infine l’ambiente software dovrà anche essere rispondente al disposto del DPR 633/72 in materia di fatturazione elettronica.

6.2.1. Macro Requisiti

Di seguito si elencano le macro-funzionalità che dovranno essere implementate dal FORNITORE nell’ambito della fornitura richiesta con il presente Capitolato.

Le caratteristiche funzionali minime richieste per il software, suddivise per macro-Aree funzionali e distinte tra funzionalità “CORE” e “NON CORE”, sono riportate nella seguente tabella.

Le funzionalità “CORE” sono quelle considerate prioritarie e saranno oggetto di collaudo durante la FASE B di tabella 2. Le funzionalità “NON CORE” saranno invece oggetto di collaudo in fase di POST AVVIO (FASE D).

Alcune funzionalità sono dichiarate “OPZIONALI”, per queste DEA S.p.A. si riserva la facoltà di acquisto, come illustrato nel DISCIPLINARE DI GARA.

6.2.1.1. Gestione anagrafiche e pratiche commerciali con gli utenti

Identificativo	Descrizione della funzionalità	CORE / NON CORE
	SEZIONE A.1 – Anagrafiche POD
A.1.1	Il sistema deve prevedere la gestione delle anagrafiche POD come dal testo integrato "TIS - Regolazione delle partite fisiche ed economiche del servizio di dispacciamento (settlement)" delibera AEEG 107/09. Devono essere previste le funzionalità avanzate utili alla ricerca dei POD presenti nel sistema. Tali funzionalità di filtraggio di ricerca utilizzabili dall'utente potranno riguardare ad esempio la tipologia del punto di prelievo, l'indirizzo di ubicazione, i riferimenti anagrafici dell'utente del dispacciamento e/o dell'utente finale. La struttura del sistema deve prevede che l'anagrafica POD sia l’entità principale all'interno dell'architettura software e ad essa siano collegate tutte le altre entità. Il POD è un elemento invariante e non ridondante nel sistema, entità e caratteristiche ad esso collegate sono gestite opportunamente in base alla competenza temporale delle stesse.	CORE
A.1.2	Il modulo di gestione delle anagrafiche POD deve fornire gli strumenti utili a: • Gestire i dati di ubicazione della fornitura, inclusi quelli utili alla georeferenziazione del POD • Gestire i dati relativi al posizionamento del POD nella rete elettrica (punto A.4) • Gestire le informazioni tecniche del POD quali potenza disponibile, potenza contrattuale, potenza in franchigia, potenza massima, codice di rete, tecnologia del gruppo di misura installato ed i riferimenti catastali, le coordinate GPS del punto. • Assicurare il collegamento con le altre funzionalità di sistema adibite alla gestione di informazioni collegate al POD quali: a. i dati tecnici del contratto di fornitura; b. i dati tecnici del gruppo di misura installato nel POD; c. lo storico dei misuratori installati nel POD con inclusi i dati tecnici; d. lo storico dei consumi/letture associati al POD; e. lo storico dei dati di fatturazione associati al POD; f. l'elenco delle pratiche commerciali (storiche ed in corso) associate al POD; g. i contratti di fornitura collegati, inclusi i riferimenti degli utenti del servizio di dispacciamento; h. i clienti finali collegati.	CORE
A.1.3	Devono essere previste le funzionalità utili alla produzione delle anagrafiche POD da inviare agli utenti del dispacciamento ai sensi del TIS art.36 ed al "Sistema Informativo Integrato" (portale SII) dell'Acquirente Unico secondo le normative in vigore.	CORE

	SEZIONE A.2 – Anagrafiche utenti del servizio di dispacciamento
A.2.1	Il sistema deve prevedere la gestione di anagrafiche per ogni utente del servizio di dispacciamento (venditore) come dal testo integrato "TIS" Regolazione delle partite fisiche ed economiche del servizio di dispacciamento (settlement)" delibera AEEG 107/09. Deve essere prevista la funzionalità di inserimento nuovi utenti e di modifica dei dati di un utente già registrato a sistema.	CORE
A.2.2	Per ogni utente del servizio di dispacciamento le funzionalità del sistema devono garantire la gestione degli estremi amministrativi, dei dati di recapito, delle date di attivazione del contratto di trasporto dei riferimenti del contratto di dispacciamento, recapiti telefonici, degli indirizzi email e PEC.	CORE
	SEZIONE A.3 – Anagrafiche strumenti di misura
A.3.1	Il sistema deve fornire funzionalità utili all'inserimento di nuovi strumenti di misura ed alla modifica di quelli già presenti. Come requisito minimo deve esser possibile gestire le seguenti tipologie di misuratori: • misuratori adibiti all'immissione di energia nella rete di distribuzione; • misuratori adibiti al prelievo di energia dalla rete di distribuzione; • misuratori bidirezionali adibiti sia all'immissione che al prelievo di energia dalla rete di distribuzione; • misuratori installati nelle interconnessioni tra reti di distribuzione • misuratori installati presso impianti di accumulo • Trasformatori di Tensione (TV) e Corrente (TA) afferenti al gruppo di misura (anagrafica e caratteristiche tecniche) Il sistema deve fornire funzionalità utili ad identificare in maniera univoca ogni singolo misuratore installato nella rete di distribuzione. Le informazioni minime che il sistema deve permettere di censire per ogni singolo misuratore sono le seguenti: • Matricola estesa • Produttore • Modello • Anno produzione e eventuale Anno di certificazione MID • Numero di Cifre • Abilitazione alla telelettura/telegestione con relativa data di avvio • Dati inerenti l'installazione comprensivi delle misure iniziali per ogni singola fascia e funzione consumo • Costanti di trasformazione • Eventuali altri misuratori collegati • Dati per la denuncia alla CCIIAA (anno marcatura MID, classe di precisione) • Storicizzazione di tutte le modifiche apportate alla configurazione • Disponibilità di reportistica su scadenza della certificazione MID per i contatori • Deve essere inoltre prevista la possibilità di poter associare a ciascun misuratore uno o più allegati in formato ".jpg", ".csv", ".pdf", excel.	CORE
	SEZIONE A.4 – Elementi della Rete
A.4.1	Il sistema deve fornire le funzionalità necessarie per descrivere e dettagliare la struttura logica della rete, pertanto deve essere possibile eseguire: • Censimento delle linee AT, semibarre AT, MT e BT • Censimento delle cabine • censimento dei concentratori per la telegestione	CORE

	• Censimento dei trasformatori (comprensivo almeno dei seguenti dati: anno di fabbricazione, matricola, potenza) • Censimento delle sezioni MT e BT • Associazione POD - codice rete (derivazione, linea, cabina, fase) • Storicizzazione dell'assetto di rete Deve essere inoltre prevista la funzionalità di aggiornamento della struttura logica della rete tramite l'acquisizione di opportuni file in formato Excel o CSV o XML, sia in modalità online che in modalità batch. Devo inoltre essere previste modalità di sincronizzazione automatica delle informazioni relative alla rete BT e all'associazione POD/Trasformatore verso il sistema IBM AMM (rete LVN).
	SEZIONE A.5 – Gestione delle pratiche commerciali con gli utenti del servizio dispacciamento
A.5.1	Il sistema deve prevedere funzionalità utili ad automatizzare la gestione delle pratiche commerciali richieste dagli utenti del servizio di distribuzione. Lo scambio dati tra il sistema del distributore e gli utenti del servizio trasporto può avvenire tramite e-mail/PEC, sistemi Application To Application e/o portale del distributore. Tutte le funzionalità richieste dovranno rispondere ai Testi integrati della AEEG che regolamentano il rapporto tra distributire e utenti del servizio trasporto. Il fornitore si impegna ad implementare eventuali aggiornamenti ed interazioni con il Sistema Informativo Integrato (SII).	CORE
A.5.2	Il sistema deve garantire la gestione delle seguenti tipologie di richieste: • Preventivi per nuovo impianto • Preventivi per modifica impianto • Preventivi per rimozione impianto • Preventivi per aumenti di potenza e/o variazione livello tensione fornitura • Esecuzione lavori da preventivo • Attivazione preposato • Cessazione amministrativa con verifica morosità • Segnalazioni call center per reparti operativi o ufficio commerciale • Attivazione nuova fornitura con misuratore (vari registri) • Attivazione/disattivazione allacci straordinari-forfait • Attivazione/Sospensione fornitura stagionale con misuratore (es. usi irrigui agricoltura) • Attivazione fornitura chiusa • Disattivazione fornitura per cessazione • Riduzione potenza e disattivazione per morosità • Variazioni contrattuali e di potenza • Volture contrattuali • Verifiche metriche degli strumenti di misura • Sostituzione Misuratore • Sostituzione Elementi del gruppo di misura (TA, TV) • Verifiche tensione di fornitura POD • Messa a disposizione di dati tecnici acquisibili con rilevazione di lettura • Messa a disposizione di altri dati tecnici • Riattivazione della fornitura a seguito di sospensione per morosità • Switch (sostituzione FORNITORE) • Switch (variazione mercato) Il sistema deve inoltre fornire gli strumenti e funzionalità utili a fatturare in modo automatizzato, sulla base di listini tariffari precedentemente	CORE

	caricati a sistema, gli importi derivanti da ciascuna pratica. Il sistema deve fornire gli strumenti utili a calendarizzare, sulla base delle richieste fatte dagli utenti del dispacciamento, la programmazione delle attività operative. Inoltre per un insieme di pratiche commerciali, definibile dal distributore, deve essere disponibile la funzionalità per dare la possibilità all'utente del dispacciamento di poter pianificare, in modo autonomo all'interno di periodi temporali predeterminati dal Distributore, gli appuntamenti con i clienti finali.
A.5.3	Il sistema deve prevedere strumenti e funzionalità di verifica di congruenza delle pratiche che permettano di automatizzare la fase di validazione, limitando le attività manuali richieste al personale di back office del distributore. Deve inoltre essere garantita la gestione della concorrenza e compatibilità tra diverse pratiche in corso. Il sistema deve fornire gli strumenti di reporting utili a: • Monitorare il numero di pratiche in corso suddivise per tipologia con indicato il livello di gestione e il rispetto dei livelli di servizio indicati nella normativa vigente. Tali informazioni devono essere esportabili in formato Excel, .csv, .xml e .pdf. • Fornire la documentazione riguardante lo storico delle pratiche gestite dal distributore secondo template definiti dall'utente. Tali informazioni devono essere esportabili in formato Excel, .csv, .xml e .pdf. • Generare i dati utili a rispondere alle indagini della AEEGSII o ad altri vincoli normativi. Il sistema deve inoltre fornire gli strumenti e funzionalità utili a gestire in modo automatizzato l'intero processo della pratica commerciale, sia in merito alle attività di back office ed amministrative sia per quanto riguarda la gestione di eventuali attività operative da svolgere sul campo, pertanto devono essere fornite le funzionalità di integrazione con il modulo di gestione lavori.	CORE
A.5.4	Il sistema deve fornire gli strumenti utili alla gestione degli indennizzi come regolato dalla AEEG per determinate pratiche. Tali funzionalità devono poter garantire che il modulo di gestione degli indennizzi sia integrato con quello della fatturazione. Per la gestione degli indennizzi automatici le funzionalità di sistema deve rispondere ai requisiti normativi indicati nei testi integrati AEEG denominato "TIQE". Il sistema deve mettere a disposizione funzionalità per la gestione degli indennizzi automatizzata, nello specifico: • si deve avere la possibilità di poter calcolare l'importo degli indennizzi da accreditare agli utenti del servizio di dispacciamento. • deve essere previsto un collegamento tra le pratiche di gestione indennizzo e le richieste di prestazioni commerciali, infatti il sistema deve fornire gli strumenti utili a generare in automatico una pratica di indennizzo quando una richiesta di prestazione commerciale non è stata eseguita, da parte del distributore, nel rispetto dei livelli di servizio imposti dalla AEEG.	NON CORE
A.5.5	Il sistema deve fornire gli strumenti di workflow e di reporting utili a monitorare il processo di gestione degli indennizzi automatici.	NON CORE
A.5.6	Il sistema deve prevedere l'integrazione con il sistema AMM di IBM con riferimento all'esecuzione di pratiche sui misuratori oggetto di telegestione, in particolare devono essere supportati tramite integrazione	CORE

	bidirezionale almeno i seguenti processi: • Variazione Contrattuale • Cessazione della fornitura • Distacco per morosità • Voltura • Riattivazione a seguito cessazione o riduzione - distacco per morosità • Installazione contatore elettronico GIS • Rilevazione curve di carico monodirezionali o bidirezionali • Rilevazione lettura corrente/precedente mono e bidirezionale • Riduzione della fornitura per morosità • Riprogrammazione del contatore • Spostamento del contatore • Sostituzione del contatore
	SEZIONE A.6 – Portale del distributore, funzionalità "Application To Application" e SNC
A.6.1	Nel sistema devono essere previsti un portale Web e funzionalità di tipo "Application To Application" utili a gestire i rapporti con gli utenti del servizio di dispacciamento secondo quanto riportato nella normativa vigente. Il sistema deve prevedere meccanismi che ne limitino l'utilizzo agli utenti del servizio di dispacciamento che dispongono di credenziali valide (ad es. username e password). In particolare deve supportare la definizione di profili personalizzabili in funzione dei quali abilitare gli operatori che vi appartengono alla fruizione di sottoinsiemi limitati di funzionalità. Il portale deve inoltre mettere a disposizione: • possibilità di download di template xml ed Excel / CSV per tutti i flussi oggetto di scambio dati tra distributore ed utente del servizio di dispacciamento, tale funzionalità deve garantire lo scambio di dati secondo le norme indicate nello "Standard nazionale di comunicazione" noto come S.N.C., o con tracciati specifici per quei flussi non riportati nello "standard Nazione di Comunicazione". • funzionalità atte a garantire lo scambio dati tra distributore ed utente del servizio di dispacciamento in modalità "Application To Application" tramite tecnologia Web Services; tale funzionalità deve garantire lo scambio di dati secondo le norme indicate nello "Standard nazionale di comunicazione" noto come S.N.C., o con tracciati specifici per quei flussi non riportati nello "standard Nazione di Comunicazione". Il sistema deve fornire tutte le funzionalità utili a gestire sia tutte le tipologie di richieste riportate nello "Standard nazionale di Comunicazione" sia quelle per le quali ancora non è presente una regolamentazione. Ogni tipologia di processo avviene mediante portale web o mediante integrazione con il SII (punto A.7.1), parametricamente, in funzione dell'evoluzione normativa.	CORE
A.6.2	Il portale web deve fornire all'utente del servizio di dispacciamento tutti gli strumenti utili a ricercare e consultare: • i dati anagrafici dei POD presenti nel proprio contratto di dispacciamento.	CORE

	• i dati tecnici dei POD presenti nel proprio contratto di dispacciamento. • i dati storici inerenti letture/consumi dei POD presenti nel proprio contratto di dispacciamento. Tutte le tipologie di flussi di scambio dati oggetto devono avvenire con le seguenti modalità: • Upload / Download di file xml; • Upload / Download di file Excel/CSV singoli. Il portale web deve consentire agli utenti del servizio di dispacciamento di: • Poter visualizzare lo stato delle richieste inviate al distributore. • Gestire gli appuntamenti a seguito di una richiesta di prestazione. • Poter effettuare il download dei consumi fatturati nel formato file stabilito nella delibera AEEG 65/12/R/EEL. • Poter avere evidenza dei misuratori sostituiti con riferimento ai POD presenti nel proprio contratto di dispacciamento. • Poter effettuare il download delle fatture inerenti consumi, prestazioni, indennizzi di propria competenza. in formato excel e/o pdf. • Poter consultare ed effettuare il download in formato Excel dei dati del "delta Pra" per anno e mese di riferimento. • Poter effettuare il download dei dati inerenti le curve di carico su base mensile per i POD di propria competenza. • Produrre la valutazione degli esiti di ammissibilità in tempo reale.
A.6.3	Il layout grafico del portale deve essere coerente rispetto al sito web aziendale di DEA Spa; pertanto devono essere presenti le funzionalità necessarie a customizzare e manutenere in autonomia il layout grafico.	NON CORE
	SEZIONE A.7 – Gestione Pratiche SII
A.7.1	Il sistema deve provvedere l'integrazione con il portale del sistema informativo integrato (SII) per tutte tipologie di pratiche che sono e, in futuro, saranno gradualmente gestite tramite detto portale. Le funzionalità previste sono: • Acquisizione flussi dal SII • validazione/ elaborazione dati • integrazione con la relativa pratica commerciale • generazione flussi di risposta • invio flussi al SII Deve essere prevista la gestione in modalità web, con possibilità di passaggio alla modalità "Application to Application" (porta di comunicazione). Il portale del distributore deve mettere a disposizione funzionalità utili a garantire che tutte le interazioni di scambio dati tra gli utenti del dispacciamento ed il distributore non prevedano attività manuale da parte degli utenti del back office del distributore. Il sistema deve fornire le funzionalità utili alla produzione dei dati (tecnici e funzionali) richiesti dalla normativa vigente. Deve essere possibile la gestione degli switch riguardanti l'attivazione delle forniture di ultima istanza (Maggior Tutela o Salvaguardia).	CORE
A.7.2	Al fine di facilitare la fase di validazione delle richieste di switch, il sistema deve fornire funzionalità utili a: • monitorare lo stato di lavorazione delle pratiche, fornendo un resoconto di sintesi con le principali informazioni utili al Distributore	CORE

	• integrare le pratiche gestite con il SII con il modulo di rilevazione, anche tramite telegestione, delle letture. Il sistema deve inoltre fornire le funzionalità utili a: • Calcolare una lettura stimata ad una determinata data. • validare e storicizzare le letture di switch/voltura o altra operazione che richieda la rilevazione della misura.
A.7.3	Il sistema dovrà prevedere la comunicazione con il SII per: • l'aggiornamento anagrafiche POD del RCU (Registro Centrale Unico) • l'integrazione dati del RCU • popolamento mensile RCU Il Fornitore si impegna ad implementare eventuali aggiornamenti ed interazioni con il Sistema Informativo Integrato (SII)	CORE
	SEZIONE A.8 – Gestione Pratiche di Reclamo
A.8.1	Il sistema deve prevedere funzionalità utili alla gestione delle pratiche di reclamo dei clienti finali verso il distributore di riferimento. Tali richieste dovranno rispondere al Testo integrato AEEGSII "TIQUE" ed inoltre il Fornitore si impegna ad implementare eventuali aggiornamenti ed interazioni con il Sistema Informativo Integrato (SII).	CORE
A.8.2	Deve essere prevista la funzionalità per registrare e classificare il reclamo secondo le categorie stabile dalla normativa AEEGSII. Il reclamo può essere di tipo: 1. distribuzione 2. misura 3. provenienti dallo sportello del consumatore Al momento dell'inserimento a sistema di una pratica di reclamo, il sistema in automatico deve collegare le informazioni anagrafiche del POD e del cliente di riferimento e, ove necessario, deve generare un ordine di lavoro da evadere attraverso il back office o le squadre operative. Le funzionalità di sistema devono permettere di allegare alla pratica di reclamo una serie di documenti in formato pdf, word, excel, csv, etc.	CORE
A.8.3	Le funzionalità di sistema devono consentire di definire la risposta da inviare ai clienti che hanno avviato la pratica di reclamo, a partire da template definibili dall'utente in cui la valorizzazione dei campi avviene in automatico sulla base delle informazioni presenti a sistema.	NON CORE
	SEZIONE A.9 – Gestione Pratiche per le connessioni attive (TICA)
A.9.1	Il sistema deve fornire le funzionalità utili a gestire tale tipologia di pratiche ai sensi del "Testo Integrato per le Connessioni Attive (TICA)" e del DL 19 maggio 2015 (TICA SEMPLIFICATA). • scadenziario eventi e allarmi per varie fasi dell'iter pratica • produzione flussi normati per comunicazione al GSE, esempio "Modello Unico"	CORE
A.9.2	Il sistema deve prevedere un portale web in cui all'utente finale, previa registrazione, siano fornite le seguenti funzionalità minime: • acquisizione della domanda di connessione del Cliente Finale • Messa a disposizione del preventivo al Cliente Finale • Verifica stato di avanzamento preventivo • Messa a disposizione di fatture, verbali di attivazione o altra documentazione per il Cliente Finale in congruenza con la tipologia di pratiche ai sensi TICA / TICA SEMPLIFICATA.	NON CORE
	SEZIONE A.10 – TIBERG – Bonus Energia Elettrica

A.10.1

Il sistema deve prevedere le funzionalità necessarie alla gestione del bonus elettrico ai sensi della Delibera AEEG 117/08 e successive modificazioni ed integrazioni. Il sistema deve pertanto:

• Prevedere le logiche e gli strumenti di integrazione con il sistema SGATE ANCI tramite canale Web Service.

• Fornire gli strumenti di reporting utili ad individuare i bonus erogati ed i relativi dati di fatturazione.

• Prevedere le funzionalità utili a gestire le richieste di utenti disagiati.

• Fornire strumenti utili alla validazione delle condizioni di erogazione del bonus.

• Fornire gli strumenti necessari a determinare ed a valorizzare gli importi da erogare alle utenze alle quali è stato concesso il Bonus.

• Fornire gli strumenti utili per rettificare importi già erogati.

CORE

SEZIONE A.11 – Sistema Indennitario

A.11.1

Il sistema deve gestire le funzionalità di scambio dati con il "sistema indennitario" di Acquirente Unico nel rispetto della normativa vigente. In particolare consente:

• acquisizione pratiche dal Sistema indennitario (portale)

• elaborazione pratiche

• generazione addebiti/accrediti

• rendicontazione e comunicazioni verso il Sistema indennitario (portale)

CORE

6.2.1.2. Gestione misura e fatturazione

Tutte le funzionalità richieste, elencate in questa sezione, dovranno rispondere ai requisiti normativi indicati nei testi integrati AEEG denominati "TIV", "TIS", "TIME", "TISP","TIMOE" e "TIT", e nella delibera AEEG ARG/elt 1/10.

	SEZIONE B.1 – Programmazione delle attività di rilevazione dei dati di misura
B.1.1	Il sistema deve gestire le funzionalità di scambio dati con il "sistema indennitario" di Acquirente Unico nel rispetto della normativa vigente. In particolare consente: • acquisizione pratiche dal Sistema indennitario (portale) • elaborazione pratiche • generazione addebiti/accrediti • rendicontazione e comunicazioni verso il Sistema indennitario (portale)	CORE
	SEZIONE B.2 – gestione delle attività di telemisura verso il sistema AMM di IBM
B.2.1	Il sistema deve prevedere l'integrazione con il sistema AMM di IBM con riferimento alle attività di telemisura (in particolare invio di ordine di telelettura di tipo SRR e PPR e aggiornamento dell'elenco dei contatori di cui leggere anche la curva di carico mono o bidirezionale), fornendo gli strumenti utili a definire i gruppi di contatori da tele leggere. Deve essere integrata la funzionalità per gestire l'acquisizione dal sistema AMM delle letture massive e/o puntuali ad una determinata data dei contatori elettronici (consuntivazione delle letture SRR e PPR). Il sistema deve	CORE

	garantire inoltre l'importazione al suo interno delle curve di carico quartorarie dei contatori telegestiti con il sistema AMM (monodirezionali e bidirezionali).
	SEZIONE B.3 – Acquisizione dati di telemisura da file
B.3.1	Il sistema deve garantire l'acquisizione dei dati di misura attraverso l'acquisizione di file in formato Excel, csv o XML. In particolare Deve essere prevista l'acquisizione di letture quartorarie o letture per fasce dal sistema Goerlitz IDspecto (ex EDW) anche attraverso file in formato LPEX 2.0. Deve essere prevista la possibilità di caricare a sistema l'immagine della lettura rilevata dal misuratore in formato .jpg. e le coordinate gps di ubicazione del misuratore. Infine deve essere prevista l'acquisizione dei dati quartorari provenienti da file scaricati da portale ENEL DISTRIBUZIONE o formato proprietario ENEL	CORE
B.3.2	Il sistema, per tutti i misuratori per cui non è stato possibile rilevare in maniera automatica il dato di misura o dove non è attiva la telemisura (GME o Contatore Elettronico BT), deve fornire gli strumenti necessari a rilevare e acquisire a sistema le letture mancanti. Il sistema deve pertanto prevedere funzionalità necessarie a: • programmare le attività di misura; • individuare i misuratori teleletti per i quali la misura non è stata rilevata (sulla base di criteri di raggruppamento definiti da DEA S.p.A.) per inviare direttamente gli ordini di lettura al sistema AMM (nel caso di contatori BT), oppure generare un report nel caso di GME) distinti in gruppi omogenei (es. Area Geografica, classificazione commerciale, ecc..); (Nel caso di acquisto di funzionalità OPZIONALE per la telelettura diretta dei GME: rilevazione dei dati di misura direttamente dal contatore tramite dispositivo portalile Windows e/o Android con applicativo sviluppato dal fornitore utilizzando una sonda ottica ZVEI.) • analogamente al punto precedente, stessa funzionalità deve essere prevista per le letture di switching non rilevate da remoto. Il sistema deve prevedere funzionalità per l'estrazione delle informazioni riguardanti le attività di lettura in file formato Excel o CSV.	CORE
	SEZIONE B.4 – Validazione dei dati di misura
B.4.1	Il sistema deve prevedere un set di funzionalità utili a validare i dati di misura rilevati sia sul campo, sia tramite telelettura. Tali funzionalità di validazione devono permettere al distributore di rilevare e correggere letture o consumi errati o non congruenti. Il sistema deve garantire inoltre la possibilità di acquisire e gestire le curve di carico di prelievo, immissione e produzione, inclusi meccanismi automatici di validazione e di ricostruzione della curva nei casi di curva di carico non completa o mancante. Deve essere prevista la validazione automatica della curva di carico tramite confronto con le letture dei registri del contatore. Devono essere previsti almeno questi meccanismi di ricostruzione: curva piatta per fasce, profilo di irraggiamento solare, modulazione della curva in base a storico, e comunque altri sistemi che dovessero essere previsti dalla normativa.	CORE
B.4.2	In caso di ricostruzione della misura, l'ambiente software deve prevedere la generazione automatica di documenti, comunque editabili, da inviare ai venditori e/o utenti interessati dalla ricostruzione della misura, dando evidenza del periodo e del consumo ricostruito, delle generalità dell'utenza e le altre informazioni previste dalla normativa vigente	NON CORE
B.4.3	Il sistema deve prevedere delle funzionalità di controllo dei consumi	NON

	dell'utente atti ad individuare potenziali malfunzionamenti/frodi del gruppo di misura, e generare la relativa reportistica. In particolare è richiesto che l'ambiente software possa effettuare dei controlli tra: il consumo registrato e il consumo storico, tra potenza rilevata, potenza storica e potenza contrattuale, confronto tra caratteristiche del gruppo trasformatori di misura e la potenza massima o minima rilevata, Consumi pari a zero su utenze attive, confronto tra energia immessa, prodotta, assorbita e rilasciata (accumulo) da un produttore.	CORE
B.4.4	OPZIONALE: Il sistema deve garantire l'acquisizione e l’interpretazione, tramite comunicazione dati GSM/GPRS verso i contatori di tipologia GME BT/MT, delle curve di carico quartorarie, dei registri totalizzatori e della diagnostica. Di seguito sono riportati i modelli di contatori GME installati nella rete elettrica di DEA SPA che il sistema dovrà teleleggere: • Landis&Gyr ZMD405/410 • Actaris - Itron SL7000 (tutte le versioni di firmware) • ISKRAEMECO MT851,MT831 • EMH LZQJ,LZKJ • CEWE Prometer -W -R • SIEMENS 7ED72 Il sistema deve tuttavia poter teleleggere e interpretare tutti gli altri modelli di contatori GME BT/MT attualmente in commercio. Il sistema deve garantire inoltre la possibilità di acquisire e gestire le curve di carico di prelievo e produzione. Il sistema deve prevedere delle chiamate automatiche periodiche o su richiesta per l'acquisizione dei dati, con frequenza configurabile. Il sistema deve segnalare eventuali anomalie o errori durante la lettura dandone evidenza all'operatore per una tempestiva risoluzione dello stesso. Deve inoltre essere previsto un software da caricare su dispositivo portatile windows e/o android per la rilevazione sul campo delle curve di carico o dei registri non rilevati da remoto.	NON CORE
B.4.5	OPZIONALE: Il sistema software deve poter gestire dei punti di fornitura "virtuali" in cui sono installati contatori di controllo (cd. "contatori padre"). Tali contatori sottendono delle intere porzioni di rete (es. trasformatore, cabina o linea). In base all'assetto di rete l'ambiente software deve poter confrontare gli scostamenti tra le misure rilevate dal contatore "padre" e l'aggregato rilevato a partire dai contatori sottesi. Il sistema deve poter produrre la relativa reportistica atta ad individuare scostamenti oltre una determinata percentuale parametrizzabile.	NON CORE
	SEZIONE B.5 – Portale misure e qualità del servizio
B.5.1	L'ambiente software deve mettere a disposizione del cliente finale, attraverso portale WEB, i dati di misura come previsto dalla normativa vigente (TIME). Il portale deve permettere l'autenticazione dell'utente in base a password di sicurezza e protocollo di comunicazione https basato sui più moderni standard di sicurezza. Deve essere possibile il recupero della password in autonomia da parte dell'utente finale.	NON CORE
B.5.2	Il portale, con le stesse modalità del punto precedente, deve inoltre permettere la messa a disposizione all'utente finale degli eventuali dati di misura inviati a GSE relativi alla propria fornitura (se presenti). Deve inoltre fornire all'utente finale i dati per la certificazione fiscale annuale dell'energia prodotta.	NON CORE

B.5.3	Il portale, con le stesse modalità del punto precedente, deve inoltre permettere la messa a disposizione all'utente finale in Media Tensione dei dati previsti dal TIQE relativamente alle interruzioni, alle tarature delle protezioni MT, allo stato del neutro nel punto di connessione MT interessato.	NON CORE
	SEZIONE B.6 – Gestione Tariffari e Listini
B.6.1	Il sistema deve prevedere funzionalità necessarie alla gestione delle tariffe di distribuzione del servizio elettrico come previsto dalla AEEG, ed alla gestione anche dei listini utili a fatturare gli interventi e le prestazioni (punto C.1.1). Devono essere previsti tool di aggiornamento dei listini tariffari tramite acquisizione di file in formato excel e/o csv.	NON CORE
	SEZIONE B.7 – Gestione del calcolo ed emissione fatture
B.7.1	Il sistema deve fornire gli strumenti utili alla gestione dell'intero ciclo di fatturazione, in accordo con quanto previsto dal CADE, specifico deve esser consentito di: • Poter emettere fatture per ogni utente del servizio di dispacciamento, per ogni tipologia di fattura e per un periodo di competenza scelto arbitrariamente dal distributore. • Poter emettere fatture riguardanti l'energia immessa nelle altre reti di distribuzione. • Poter fare un controllo degli importi e consumi, su base venditore, in fase di fatturazione prima dell'emissione della fattura stessa • Poter individuare tutti i contratti per i quali è presente un blocco di fatturazione e non è quindi possibile emettere la fattura a causa di errori nei dati contrattuali, abilitando alle modifiche del caso. • Poter fatturare partite manuali il cui importo viene calcolato dall'operatore extra-sistema. • Poter emettere fatture di storno e di rettifica di importi precedentemente fatturati. Le operazioni di storno e rettifica generano automaticamente modifiche, per perido di competenza, ai dati elaborati per le comunicazioni Load Profiling (Punto E.1.3.) Il sistema deve prevedere le funzionalità utili alla fatturazione dell'energia prelevata dai produttori fotovoltaici che possono essere connessi alla rete del distributore.	CORE
B.7.2	Il sistema deve fornire l'automatismo utile alla stima dei consumi per tutti quei POD dove non è stato possibile recuperare i dati di misura effettivi, e produrre apposita reportistica dei POD con misura stimata per la verifica prevista dal CADE. Il sistema, per tutti quei POD che hanno più di una lettura all'interno dello stesso periodo di fatturazione, deve fornire le funzionalità necessarie per poter aggregare il periodo di consumo e riportare in fattura la lettura con valore maggiore. Il sistema deve fornire gli strumenti necessari per calcolare il conguaglio di consumi stimati già fatturati e dei consumi reali che sono stati oggetti di rettifica post fatturazione.	CORE
B.7.3	Al fine di effettuare attività di verifica sul calcolo, il sistema deve mettere a disposizione i dettagli analitici, in formato Microsoft Excel e/o csv, per tipologia di importo fatturato, tra cui: • Analitico fatturazione consumi • Analitico fatturazione prestazioni • Analitico fatturazione indennizzi • Analitico fatturazione bonus • Analitico fatturazione CTS • Analitico misure e importi del Prelievo di potenza	CORE

	• Analitico misure e importi dell'energia reattiva • Analitico misure e importi di ogni singola voce contenuta in fattura • Report di confronto per ogni singolo POD fatturato, per quantità ed importi, tra potenza disponibile e potenza prelevata • Report di controllo in cui per ogni singolo POD si deve riportare la percentuale di scostamento tra le quantità fatturate riferite ai consumi di energia attiva, energia reattiva e potenza prelevata (nei casi in cui sia presente un POD con installato un misuratore avente il registro di potenza) ed il consumo medio del POD fatturato nei periodi predenti se presenti.
B.7.4	Il sistema deve garantire gli strumenti necessari al distributore per la corretta compilazione delle fatture e deve essere garantita: • la gestione della numerazione delle fatture; • la possibilità di poter stampare in formato PDF la fattura con tutti i dettagli per POD, per tariffa e prestazione; • la possibilità di poter inviare la fattura all'utente del servizio di dispacciamento via PEC o portale del distributore. Il sistema inoltre produce apposito allegato alla fattura contenente le indicazioni di dettaglio sui POD o le prestazioni oggetto di fatturazione come in corso di definizione da parte dell'AEEGSII	CORE
	SEZIONE B.8 – Gestione del Credito / Morosità
B.8.1	Devono essere presenti gli strumenti utili a definire i tassi di interesse e ad effettuare il calcolo e l'addebito degli interessi di mora. • Il sistema deve permettere di esporre, nelle apposite fatture, il dettaglio analitico del calcolo degli interessi di mora. • Deve altresì essere data la possibilità di escludere, dal calcolo degli interessi di mora, una singola fattura o un singolo contratto	CORE
B.8.2	Il sistema deve prevedere delle funzionalità di reporting che permettano un'analisi del credito: • Per causali contabili • Per tipo documento di fatturazione • Per partita contabile • Per scadenzario clienti Il sistema deve prevedere strumenti utili alla gestione del recupero crediti, in particolare deve essere possibile: • L'individuazione dei clienti morosi e delle relative scadenze • La produzione dei solleciti e diffide di pagamento secondo le tempistiche fissate dal CADE ed il loro invio tramite email/PEC	CORE
B.8.3	Il sistema deve prevedere la gestione delle garanzie del contratto di trasporto come previsto dell'allegato B del CADE. In particolare: • calcolo garanzia • verifica periodica adeguatezza e tipologia della garanzia prestata	NON CORE

6.2.1.3. Gestione lavori e interventi

SEZIONE C.1 – Gestione lavori e interventi

C.1.1

Il sistema deve fornire le funzionalità necessarie per gestire, nel rispetto dei vincoli normativi, i processi di:

• esecuzione lavori da preventivo

• interventi tecnici sulla rete

CORE

	generati dalle richieste al punto A.5.2. Per ogni pratica viene gestito un "ordine di lavoro" (ODL) contenente le informazioni necessarie all'effettuazione dell'operazione richiesta. L'oggetto ODL prevede inoltre la possibilità di associare il dato del progetto/commessa DEA e la rendicontazione delle ore lavorate dai tecnici che hanno effettuato l'intervento. Deve essere prevista la possibilità di aggiornare le informazioni relative alle coordinate GPS dell'elemento di rete, a fronte di determinate tipologie di OdL.
C.1.2	Il sistema dovrà prevedere, in base alla tipologia della prestazione richiesta (rif. punto A.5.6), l'invio di corrispondenti flussi verso i sistemi di telegestione e telemisura (AMM o sistema OPZIONALE di telelettura GME). In particolare, se la prestazione è verso un'utenza con misuratore telegestibile (BT), deve essere inviato anche il relativo CMO al sistema AMM (vedi anche requisiti RI.1.X). Nel caso di utilizzo del modulo OPZIONALE per la lettura diretta dei GME invio dell'ordine di lettura curve/registri al misuratore.	CORE
C.1.3	Il sistema dovrà fornire funzionalità di WORK FORCE AUTOMATION per: • Effettuare ricezione/invio in tempo reale degli ordini di lavoro, derivanti da una pratica commerciale o da una segnalazione di Pronto Intervento, attraverso collegamento wireless (4G / Wi-Fi) con centrale operativa. Registrazione guidata dei dati relativi all'intervento con controlli sulla completezza e correttezza delle informazioni registrate. • gestire le squadre operative inclusa l'assegnazione degli ordini di lavoro da evadere • Produzione sul campo della modulistica da consegnare e far firmare agli utenti finali con registrazione informatica immediata dell'esito degli interventi, attraverso l'utilizzo di stampanti wireless • Documentare tutte le attività svolte mediante l'acquisizione di foto digitali archiviazione automatica delle immagini a sistema con possibilità di associarle al POD ed al contratto. • Georeferenziare i POD nelle pratiche di pronto intervento e prestazione servizi utilizzando il dispositivo GPS presente nel dispositivo mobile.	NON CORE
C.1.4	OPZIONALE: In aggiunta al punto precedente acquisizione digitale della firma grafometrica dell'operatore e del cliente finale a completamento degli interventi, invio del verbale al cliente finale tramite email, o cartaceo su richiesta del cliente	NON CORE

6.2.1.4. Gestione qualità e pronto intervento

SEZIONE D.1 – Gestione qualità e pronto intervento

D.1.1

Il sistema deve garantire la disponibilità a supporto integrale delle procedure imposte dalla normativa vigente per le aziende di distribuzione di Energia Elettrica. In particolare il sistema deve:

• avere funzionalità atte a registrare i riferimenti delle richieste di Pronto intervento che pervengono al Call Center esterno o ad operatori della società di distribuzione.

• essere predisposto all'integrazione con il modulo di workforce automation, permettendo l'inoltro delle richieste di pronto

CORE

	intervento agli operatori tramite l'utilizzo di apparati mobili (palmari, Tablet). • permettere di rendicontare le manovre effettuate dal personale tecnico a seguito di un ODL per interruzione su linea BT.
D.1.2	Devono essere previste funzionalità di monitoraggio e reporting, allo scopo di avere evidenza dello storico delle richieste pervenute e dei tempi di esecuzione di ciascun intervento, anche in linea con quanto richiesto dalla normativa vigente.	NON CORE
D.1.3	Il sistema deve prevedere funzionalità avanzate di monitoraggio e reporting necessarie a rispettare gli obblighi normativi attualmente in vigore. Inoltre le informazioni di origine commerciale riguardanti i POD necessari alla gestione della Qualità del Servizio devono prevedere l'univocità delle posizioni, la tracciabilità delle variazioni, la congruenza delle date di riferimento, l'identificativo dell'impianto risultante dalla anagrafica di rete. Il sistema deve fornire gli strumenti utili per il distributore nel monitoraggio degli indicatori inerenti la qualità commerciale e la gestione delle interruzioni.	NON CORE
D.1.4	Il sistema deve acquisire l'elenco delle interruzioni di rete da apposito file in formato Excel o CSV (v. tracciato allegato “Interruzioni_rete_EE.xlsx”) Il sistema genera l'elenco dei POD interrotti elaborando il file precedentemente acquisito in funzione della mappatura di rete e sua storicizzazione.	NON CORE

6.2.1.5. Reportistica e Comunicazioni

SEZIONE E.1 – Reportistica e Comunicazioni

E.1.1

Il sistema deve fornire le funzionalità di reporting finalizzate all'esecuzione di comunicazioni previste dalla normativa nei confronti della AEEGSII ed alla produzione dei report richiesti dalla AEEGSII incluse le "Indagini" e “Raccolte dati" per le aziende di Distribuzione energia elettrica.

Devono inoltre essere disponibili dei report finalizzati all'analisi di:

• fatturato per tipologia di fornitura e componente tariffaria con dati quantitativi ed economici suddividi per mese di competenza, scaglioni e fasce orarie.

• analisi per verifica del "venduto di competenza" finalizzato alla riconciliazione dati della contabilità aziendale.

Tali reports saranno consultabili tramite applicativo od esportabili in formato Excel, Csv, Pdf.

NON CORE

E.1.2

Il sistema deve altresì mettere a disposizione reportistica e strumenti di calcolo idonei all'esecuzione di comunicazioni periodiche ad altri soggetti quali i Venditori, Terna, GSE, etc tra cui a solo titolo di esempio:

• Comunicazioni al GSE, tutti i tracciati previsti:

o Misure Ritiro dedicato;

o Anagrafiche e Misure Scambio sul Posto;

o Misure incentivanti fotovoltaico;

o Misure CIP6;

o altri tracciati previsti ...

• Reportistica utile ai fini delle denunce:

o Cassa Conguaglio del settore elettrico

o Componente A3 per GSE

CORE

o Dati preventivi per esercizio successivo

• Estrazione dei dati rilevanti la perequazione con possibilità di simulazione su esercizio successivo.

• Reportistica Comunicazioni Obbligatorie verso Terna:

o Invio misure SSP aggregate

o Invio misure UPNR puntuali

o Invio misure UP

• Reportistica utile all'invio dei dati di lettura come da delibera AEEG 65/12/R/EEL e successive modificazioni

• Reportistica idonea all'esecuzione della Dichiarazione di consumo (Imposte sull'energia elettrica) da inviare all'Agenzia delle Dogane

Il sistema deve prevedere inoltre la funzionalità di invio tramite PEC a ciascun venditore dei file contenenti i consumi orari e quartorari dei POD presenti nel proprio contratto di dispacciamento.

E.1.3

Il FORNITORE dovrà rendere disponibile lo schema del Database utilizzato per le funzionalità di reportistica al personale DEA SPA al fine di poter creare, in autonomia e in tempi rapidi, query e report personalizzati.

Il FORNITORE è tenuto in caso di aggiornamento del DB stesso, a fornire tempestivamente la versione aggiornata dello schema associato.

NON CORE

6.3. Requisiti Tecnici

6.3.1.Interfacce applicative

Il nuovo sistema dovrà garantire il miglior livello di integrazione, sia a livello applicativo che tecnologico, con i sistemi gestiti direttamente da DEA S.p.A. e con altri sistemi esterni (altri sistemi aziendali o altri sistemi esterni gestiti da terzi). In particolare nella figura seguente è rappresentata l’architettura applicativa target e le principali interfacce applicative che il FORNITORE dovrà garantire:

UDD

Cliente

INTRANET

Formula DIAPASON

Goerlitz Idspecto

AMM IBM

CREDEMTEL

Dispositivo Portatile

MAGAWEB OREWEB

Ambiente SW Distribuzione/Misura EE

Contatore GME

Portale WEB

AU SII / Sistema Indennitario

GAUDI

SGATE

GSE

TERNA

INTERNET

DMZ

Figura 1

I sistemi oggetto di fornitura sono rappresentati in rosso. I sistemi esterni sono rappresentati in celeste. I sistemi gestiti direttamente da DEA sono rappresentati in arancione.

In particolare i principali sistemi rappresentati in figura sono descritti in tabella:

Elemento Applicativo	Caratteristiche
Ambiente SW Distribuzione / Misura EE, Portale WEB	L’ambiente software oggetto della presente fornitura
Contatore GME	Contatore di tipo GME da teleleggere tramite modem GSM / GPRS (funzionalità OPZIONALE)
Dispositivo Portatile	Dispositivo di tipo smartphone, tablet e notebook con SO Windows 7/8.1/10 in cui installare il software di WORK FORCE AUTOMATION per le squadre operative e opzionalmente il software per la lettura locale dei GME e il modulo per la firma grafometrica
AMM IBM	Sistema di telegestione dei contatori elettronici BT sviluppato e manutenuto da IBM Italia S.p.A.
Goerlitz IDSpecto	Sistema di telelettura e gestione dei dati di misura per le utenze trattate orarie
CREDEMTEL	Sistema di conservazione a norma dei documenti digitali
FORMULA DIAPASON	Ambiente ERP di DEA S.p.A.
MAGAWEB / OREWEB	Software proprietari: gestione degli scarichi di magazzino; contabilizzazione delle ore lavorate dal personale dipendente
TERNA, GSE, SGATE, GAUDI, AU (SII, Sistema Indennitario)	Sistemi informatici esterni gestiti dagli Enti Regolatori

Nella seguente tabella sono riportati i requisiti specifici di integrazione applicativa che il FORNITORE deve garantire nell’ambito dell’ambiente software fornito e, per ognuno, il riferimento alle specifiche di integrazione o una breve descrizione della tipologia di integrazione in essere. Il FORNITORE qualora risulti aggiudicatario della fornitura, è tenuto obbligatoriamente, e senza oneri aggiuntivi per DEA, ad implementare anche le funzionalità dichiarate “NON DISPONIBILI” ai sensi del Disciplinare di Gara. In particolare il sistema dovrà garantire almeno i seguenti flussi:

Id.	Sistema da Integrare	Descrizione requisito di integrazione
	Sistema AMM IBM	L'interfacciamento con il sistema AMM avviene attraverso l'utilizzo di messaggi XML inviati o resi disponibili sulle code IBM Websphere MQ 7.5. Per le curve di carico è possibile l'accesso alle relative tabelle del DB AMM. I dati ricevuti dal sistema AMM dovranno essere utilizzati per l'aggiornamento automatico dei dati presenti all'interno dell'ambiente software. Dovrà essere prevista la gestione dei seguenti flussi:
RI.1.1		• Flusso 1.1: invio XML di aggiornamento topologia rete BT (LVN) e relativa consuntivazione esito caricamento • Flusso 1.2: Invio XML per ordine di gestione utenza (CMO) verso contatori programmati sia monodirezionali che bidirezionali, consuntivazione dell'esito di caricamento, almeno per le seguenti tipologie di CMO: 1210, 1212, 1214, 1216, 1300, RVAR-PR, RVAR-SP, RVAR_LC, RVAR_LP, 1400, 1410, 1400P, 0000X, XXXX, XXX, XXX, XXXX, RVAR-FW • Flusso 1.3: invio e ricezione fil XML di richieste di consuntivazione Esiti CMO su intervallo di date parametrizzabile, e acquisizione letture mono e bidirezionali, relativo caricamento nell'ambiente software • Flusso 1.4: invio XML richieste di lettura di tipo SRR e/o PPR (letture correnti o precedenti) e relativa consuntivazione esito del caricamento
RI.1.2		• Flusso 1.5: invio file XML di richieste di consuntivazione esiti letture SRR e/o PPR su intervallo di date parametrizzabile, acquisizione dei file XML con le letture e relativo caricamento nell’ambiente software
RI.1.3		Il sistema dovrà interfacciarsi con il sistema AMM per: • l’aggiornamento automatico dell’elenco dei POD per cui scaricare le curve di carico mono o bidirezionali del mese n-1 • lo scarico dei dati quartorari delle curve di carico (monodirezionali o bidirezionali) acquisite da remoto • lo scarico dei dati quartorari delle curve di carico acquisite tramite ordini di lavoro (CMO) da palmare.
RI.2.0	FORMULA DIAPASON	Il sistema dovrà garantire l’integrazione con l’applicativo in oggetto, anche attraverso l’utilizzo di viste personalizzate sul DB, di alcune informazioni relative alla contabilizzazione delle fatture emesse e dei relativi movimenti di pagamento, in funzione della parametrizzazione specifica (ad. es.: piano dei conti, canali di incasso, voci contabili, ecc.)

RI.3.0	Goerlitz IDSpecto	L’interfacciamento con il sistema IDSpecto di GOERLITZ avviene attraverso l’importazione automatica di file TXT o XML prodotti dalla procedura. In particolare: • Flusso 3.1: File LPEX 2.0 (txt) contenenti curve di carico quartorarie • Flusso 3.2: file XML contenente letture per fasce mensili o dei totalizzatori
RI.4.1	Dispositivo Portatile	Il software del dispositivo portatile (tablet, smartphone, Notebook, ecc) deve essere rispondente a questi requisiti: • Automatizzazione dell'operatività delle squadre tecniche secondo le specifiche illustrate nei requisiti funzionali, inclusa stampa wireless, e georeferenziazione GPS. • Coesistenza con l’applicativo per palmare sviluppato da IBM per la programmazione/lettura locale dei contatori elettronici (in ambiente Windows 7,8.1,10).
RI.4.2	Dispositivo Portatile	• OPZIONALE: Rilevazione locale registri e curve di carico tramite sonda Zvei (USB o bluethooth) • OPZIONALE: Supporto alla gestione della firma grafometrica e invio dei documenti al cliente via email
RI.5.0	CREDEMTEL	L’ambiente software, per ogni fatturaPA (fattura elettronica ai sensi del DPR 633/72), deve generare il file XML previsto dal Sistema di Interscambio, unitamente al documento PDF della fattura. I file generati devono essere riepilogati in un “file guida” predisposto su tracciato previsto da CREDEMTEL per la loro piattaforma di conservazione a norma dei documenti elettronici e per l’invio al Sistema di Interscambio.
RI.6.0	MAGAWEB/OREWEB	L'ambiente software deve garantire l'interrogazione da parte degli applicativi in oggetto, anche attraverso l'utilizzo di viste personalizzate sul DB, di alcune informazioni relative agli ordini di intervento, necessarie per la contabilizzazione del magazzino e di contabilità analitica. In particolare, il centro di costo, la commessa, e altre informazioni associate al singolo ordine di intervento, elenco degli ordini in lavorazione non ancora chiusi.
RI.7.0	Contatore GME	OPZIONALE: L'interfacciamento con i contatori GME avviene attraverso l'invio di comandi l'utilizzo di MODEM GSM/GPRS. Devono essere gestite le seguenti tipologie di comando: • Comando 7.1: Lettura periodica dei registri di fatturazione, compresa la parola di stato del contatore • Comando 7.2: rilevazione-sincronizzazione della data/ora • Comando 7.3: lettura curve di carico del contatore • Comando 7.4: lettura della diagnostica del contatore L'ambiente software deve altresì garantire la memorizzazione e la storicizzazione dei dati grezzi rilevati dal contatore, così come eventuali variazioni di costante di trasformazione (k sistema) Il sistema deve inoltre poter gestire il verso di montaggio del contatore (ad. es. se il registro 1.8.0 corrisponde ad energia prelevata dal cliente o immessa in rete).

Tabella 4

6.4. Esperienze pregresse e referenze

Nella seguente tabella è riportato il requisito specifico relativo alle referenze che il fornitore dovrà produrre.

SEZIONE REF – Esperienze pregresse e Referenze

REF.1

Il FORNITORE dovrà aver effettuato negli ultimi 4 anni antecedenti la pubblicazione del bando di gara almeno n. 3 forniture analoghe a quello in oggetto, da comprovarsi tramite i relativi certificati rilasciati e vistati dalle pubbliche amministrazioni e/o enti pubblici ovvero tramite dichiarazioni rilasciate dai committenti privati circa la effettiva esecuzione della prestazione.

Si specifica che per fornitura analoga si intende:

• fornitura ad aziende di distribuzione energia elettrica di riferimento (ai sensi dell’articolo 6 comma 1 del TIS – Testo Integrato per il Settlement);

• numero POD gestiti su ciascuna fornitura, compreso tra 25.000 e 250.000;

Le dichiarazioni delle suddette referenze, sottoscritte dalle terze parti, dovranno essere trasmesse in allegato in copia conforme all’originale con dichiarazione di autenticità resa dal procuratore della società ai sensi dell’Art. 445/2000.

Al fine del conteggio, la referenza sarà ritenuta valida se ogni sezione sarà debitamente completata e se sarà allegata la “Certificazione di Regolare Fornitura”

Tabella 5

7. Modalità di Esecuzione della Fornitura

7.1. Premessa

Nei paragrafi seguenti viene riportata una descrizione generale delle modalità di svolgimento delle attività richieste al FORNITORE in fase di sviluppo del progetto.

DEA S.p.A. si riserva di modificare le modalità di esecuzione descritte, di introdurre nuove modalità, di definire/modificare gli standard concordati, anche in corso d’opera, dandone preavviso al FORNITORE. Inoltre, tali modalità di esecuzione possono essere congiuntamente riviste, su proposta del FORNITORE, e possono essere concordate opportune semplificazioni o variazioni in funzione delle specificità delle singole funzionalità/progetti/interventi (obiettivi).

Inoltre, DEA S.p.A. si riserva di chiedere al FORNITORE di utilizzare prodotti o modulistica specifica di supporto alla gestione delle attività della fornitura (ad esempio: template di registrazione errori, log interventi, richiesta attività, ecc.).

DEA S.p.A. si riserva inoltre di avvalersi di terzi per il supporto allo svolgimento di attività di propria competenza.

Si sottolinea che al FORNITORE è richiesto, in tutte le attività, il rispetto dei processi, degli standard e delle linee guida adottate da DEA S.p.A.; il FORNITORE deve farsi carico di conoscere e diffondere al proprio interno tali conoscenze, di applicarle proattivamente e di recepirne tempestivamente eventuali variazioni.

DEA S.p.A si riserva di verificare in ogni momento la corretta esecuzione dei servizi anche attraverso la richiesta di reportistica ad hoc.

E’ fatto divieto al FORNITORE di cedere a terzi, in tutto o in parte, l’oggetto del Contratto che verrà stipulato, nonché di cedere a terzi, in qualsiasi forma, i crediti derivanti dallo stesso e di conferire procure all’incasso.

Il FORNITORE è tenuto altresì a comunicare tempestivamente al cliente le eventuali modifiche di assetto aziendale o societario. Rimane facoltà di DEA S.p.A. di risolvere il suddetto contratto a norma del presente Capitolato (par. 5.9.2) entro 3 mesi dalla comunicazione dell’Appaltatore o comunque, in difetto da quest’ultima, dall’avvenuta conoscenza delle indicate modifiche.

7.2. Nomina del responsabile di progetto e del comitato guida

Il FORNITORE deve provvedere a sua cura e spese a quanto necessario affinché le forniture risultino complete e funzionanti in conformità ai documenti contrattuali: a tal scopo il FORNITORE dovrà

indicare un proprio Responsabile di Progetto (PM) e comunicare tempestivamente eventuali variazioni dello stesso.

Compito del Responsabile di Xxxxxxxx, per tutta la durata della contratto, sarà quello di interfacciarsi con il/i responsabile/i individuato/i da DEA S.p.A. e con questi ultimi concordare, anche in base alle tempistiche previste dal presente capitolato, la schedulazione delle attività di progetto, l’impiego di risorse, la gestione delle forniture, delle manutenzioni, la conduzione del collaudo, la gestione dei rischi, degli incidenti e quanto altro necessario al corretto svolgimento della fornitura. Per raggiungere tali obbiettivi il PM si avvale anche di metodi e strumenti di Software Project Management ispirati ai modelli di riferimento internazionalmente riconosciuti.

Al fine di permettere il corretto svolgimento del progetto verrà inoltre definito un Comitato Guida, ovvero un organo superiore decisionale rispetto al progetto, formato dal top management del FORNITORE e del cliente. Il CG ha compiti di indirizzo, di controllo del progetto e capacità decisionale su tutte le questioni che possono avere un impatto sull’avanzamento del progetto non direttamente risolvibili a livello di delega del Responsabile di Progetto.

7.3. Avvio del progetto

Ai fini della messa in produzione del nuovo ambiente software, si prevede una fase di avvio del progetto, per la quale il FORNITORE dovrà prevedere la produzione e consegna di un Piano di Progetto di dettaglio delle attività previste, in linea con le indicazioni di massima di Tabella 2 (FASI da A a G). Le attività di progetto dovranno comprendere:

• Analisi e affinamento delle specifiche minime relative al soddisfacimento dei singoli macro-requisiti dettagliati nei precedenti paragrafi (cfr. paragrafo 6);

• Deployment dell’infrastruttura (attività sistemistiche), implementazione del sistema e sua parametrizzazione, popolamento dati ambiente di collaudo, attività di formazione on- site del personale dell’Area Sistemi Informativi. (FASE A - DEPLOYMENT).

• Attività del collaudo componenti “CORE” di sistema con i dati di produzione, test di integrazione del sistema con ambienti legacy. Deployment ambiente di test. Formazione “key user” (FASE B - COLLAUDO);

• Attività di migrazione dei dati in produzione, rilascio in produzione dell’ambiente software, test delle funzionalità “NON CORE”, supporto on-site (FASI C – GO LIVE e D – POST AVVIO).

N.B. Il piano delle attività dovrà comunque essere redatto anche in coerenza con le normali attività svolte da DEA, con l’obbiettivo di evitare ritardi nella fatturazione e inadempienze nelle comunicazioni verso gli enti regolatori del settore (AEEGSII, TERNA, AU, GSE, CSEA, ecc.).

7.3.1.Avvio del progetto - Documentazione

Nella fase di avvio del progetto, entro 10 gg solari dalla data di stipula del contratto, il FORNITORE dovrà prevedere la produzione e la consegna della seguente documentazione, con il dettaglio delle informazioni richieste:

• Piano di Progetto

o Numero e tipo di risorse impiegate per ciascuna attività

o Definizione delle milestones di progetto (distinte per attività)

o Date di inizio/fine delle attività

o Effort complessivo e durata delle attività

o Effort risorse DEA S.p.A. e/o terze parti

• Dettaglio descrizione delle componenti tecnologiche

o Descrizione dell’architettura utilizzata e delle componenti applicative previste (interfacce verso i sistemi attualmente utilizzati da DEA S.p.A.).

o Descrizione degli eventuali vincoli previsti in funzione di una scalabilità della soluzione: rappresentare nello specifico gli scenari previsti in termini di volumi incrementali supportati, tempi e costi.

7.4. Attività di Deployment

L’attività di deployment, da eseguirsi con le tempistiche illustrate in Tabella 2, ha lo scopo di rendere disponibile l’Ambiente Software di collaudo in tutte le sue funzionalità “CORE” e con i dati e le parametrizzazioni richieste da DEA S.p.A.

7.4.1. Deployment dell’infrastruttura e degli applicativi

Le attività di deployment dell’infrastruttura e degli applicativi devono comprendere:

1. Stesura di un documento (“Operational Model”) con il dettaglio dell’architettura dell’Ambiente Software (Server, Database, Application Server, ecc.) e schema di interconnessione dei vari componenti

2. Installazione dei Server, dei Sistemi Operativi, di RDBMS Oracle e attività sistemistiche in generale

3. Installazione software applicativo ed eventuale middleware, ulteriori parametrizzazioni sistemistiche degli ambienti

Si precisa che tutte le attività al punto 2, eseguite sulla base dell’Operational Model redatto dal FORNITORE, saranno a carico di DEA S.p.A.

Le attività ai punti 1 e 3 saranno a carico del FORNITORE

7.4.2.Popolamento dati e parametrizzazione (ambiente di collaudo)

Le attività al seguente punto, a carico del FORNITORE, comprendono almeno:

1. Importazione dei dati di produzione messi a disposizione da DEA S.p.A. sulla base dei tracciati definiti in Allegato “DEA_TRACCIATI_SIU32.XLSX”

2. Parametrizzazione dell’Ambiente Software anche sulla base delle indicazioni del cliente

3. Test interni di funzionamento dell’ambiente di collaudo da parte del FORNITORE

7.4.3. Deployment – Documentazione

Nella fase di deployment, il FORNITORE dovrà prevedere la produzione e consegna della seguente documentazione, con il dettaglio delle informazioni richieste:

1. Elenco delle parametrizzazioni effettuate nell’Ambiente Software

2. Elenco dei test preliminari effettuati dal FORNITORE sull’Ambiente Software e relativo esito

7.5. Collaudo

L’attività di collaudo del sistema, svolta presso la sede del cliente, ha l’obbiettivo di verificare il buon funzionamento complessivo del sistema e la sua aderenza ai requisiti funzionali richiesti al paragrafo 5.9.

Il collaudo, individuato in due momenti distinti del progetto (fase “COLLAUDO” e fase “POST AVVIO”), sarà organizzato per le diverse aree funzionali del prodotto.

Le attività di collaudo comprenderanno:

• Test funzionalità di Prodotto

• Test di integrazione con sistemi legacy aziendali (ad es. AMM, DIAPASON, ecc.)

Per ognuno dei requisiti funzionali individuati il fornitore, almeno 30 giorni solari prima della data di inizio collaudo, dovrà produrre un elenco dei casi di test che verranno condivisi con il cliente e da questo eventualmente integrati.

Durante la fase di collaudo, i referenti di DEA dovranno certificare il buon funzionamento delle principali funzionalità del sistema e la loro aderenza ai requisiti funzionali espressi e condivisi.

In caso di esito negativo del collaudo, il FORNITORE è tenuto ad analizzare le cause e ad informare di queste il cliente. Nel caso non siano state individuate cause imputabili al cliente, il FORNITORE deve mettere in atto, a proprie cure e spese, tutte le azioni correttive idonee alla risoluzione del problema per il positivo esito del collaudo.

Qualora entro due mesi il FORNITORE non riesca a superare positivamente il collaudo e quindi l’esito del test sia negativo, anche soltanto per una delle funzionalità attese, DEA S.p.A. potrà applicare la risoluzione del contratto ai sensi dell’art. 1456 del Codice Civile. Il FORNITORE sarà comunque tenuto a corrispondere le penali così come definite al paragrafo 10.

7.5.1. Documentazione di collaudo

Per la fase di collaudo dell’ambiente software prodotto, il FORNITORE dovrà prevedere inoltre la produzione e consegna di un Piano di Collaudo, comprendente anche le seguenti informazioni:

• Piano generale di Test, suddiviso tra test funzionalità CORE, NON CORE.

• Elenco dei test case, con il dettaglio, per ciascun caso di:

o Durata e risorse richieste

o Descrizione delle linee guida nell’esecuzione della verifica

o Criteri di positivo superamento

• Verbale di accettazione

7.6. Formazione

Scopo della formazione è quello di sviluppare nelle persone coinvolte l’autonomia e la confidenza nell’utilizzo dei nuovi strumenti, oltre che la consapevolezza a riguardo delle modifiche al contesto organizzativo e di processo.

La formazione sarà svolta in base ad un piano/agenda di formazione che sarà condiviso sulla base di una proposta effettuata dal FORNITORE. Le attività di formazione dovranno essere svolte esclusivamente in lingua italiana.

All’interno del piano di formazione dovranno essere individuate attività teorico-pratiche di formazione generale all’uso del prodotto, e altre di carattere specialistico riguardanti le varie funzionalità attivate o contenuti tecnici di tipo informatico.

Devono essere comunque previsti due momenti distinti della formazione:

- Formazione del personale dell’Area Sistemi Informativi (da svolgersi durante la fase “A”)

- Formazione degli operatori “key user” (da svolgersi durante la fase “B”)

7.6.1.Documentazione sul piano di formazione e manualistica

Il FORNITORE, entro 20 gg solari a partire dalla data di stipula del contratto, dovrà provvedere alla redazione e alla consegna del piano di formazione, comprendente anche le seguenti informazioni:

• Piano e agenda per la formazione del personale dell’Area Sistemi Informativi e per i “Key User” del Cliente con il dettaglio degli argomenti (generali e specialistici)

• Documentazione a corredo (manualistica ed esercitazioni)

Il FORNITORE si impegna inoltre alla produzione e alla consegna di copia della seguente documentazione:

• Guide utente per l’utilizzo dell’ambiente software

• Note di rilascio dei componenti software installati

• Documento esplicativo sul disegno del DATABASE dell’ambiente software, comprendente:

o Descrizione degli oggetti in esso contenuti (tabelle, viste, procedure, packages, ecc…) e loro modalità di impiego

o Descrizione e spiegazione dei campi delle tabelle del database.

7.7. Avvio in Produzione (Go Live)

La fase di avvio in ambiente di produzione comprende tutte le attività che il Fornitore eseguirà per la messa in esercizio delle funzionalità “CORE” del nuovo Ambiente Software, in particolare sono previsti i seguenti step:

1) predisposizione ambiente di produzione

2) migrazione dati in effettivo

3) messa in produzione dell’applicativo

Si ribadisce, come anticipato al paragrafo 7.3, la necessità che la programmazione di queste attività non vada ad influire sulle normali attività svolte da DEA S.p.A., causando ritardi nella

fatturazione e inadempienze nelle comunicazioni verso gli enti regolatori del settore (AEEGSII, TERNA, AU, GSE, CSEA, ecc.).

Pertanto, qualora in fase di GO LIVE, si evidenziassero ritardi nell’implementazione dell’ambiente oppure, immediatamente conclusa la fase stessa, si verificassero blocchi nell’utilizzo del sistema non imputabili a DEA S.p.A., il FORNITORE sarà tenuto a risarcire eventuali danni.

7.8. Post Avvio

La fase di POST AVVIO (fase D di Tabella 2) ha inizio a partire dalla data di messa in produzione dell’applicativo. Durante questo periodo il FORNITORE dovrà prevedere la presenza fisica di proprio personale presso DEA S.p.A. a supporto dell’operatività dell’Azienda nelle prime fase di utilizzo del sistema, volta alla risoluzione di eventuali problematiche non esperite nelle fasi precedenti del progetto. Si prevede, durante tutto il periodo di post avvio (fase D), la presenza di personale on-site per almeno 20 gg lavorativi. Tali giornate possono essere distribuite nel tempo anche in maniera non continuativa.

Durante la fase di POST AVVIO dovrà inoltre essere predisposto l’ambiente parallelo di test a partire dai dati e dalle parametrizzazioni presenti nell’ambiente di produzione.

Durante questa fase si procederà infine al collaudo delle funzionalità “NON CORE”. La fase di POST AVVIO termina con il positivo collaudo delle funzionalità “NON CORE”.

7.9. Modalità di consegna dei prodotti

Il FORNITORE deve effettuare la consegna dei prodotti secondo le modalità di seguite descritte. Il caso di consegna non valida corrisponde ad una mancata consegna.

La documentazione deve essere in formato nativo digitale (Microsoft Office, Pdf, ecc.)

La consegna deve essere accompagnata dalla lettera di consegna descrittiva dei prodotti consegnati in formato cartaceo, fatto salvo diverso accordo con DEA S.p.A. per la consegna tramite posta elettronica, agli indirizzi che saranno indicati da in fase di avvio della fornitura.

La consegna di un documento è ritenuta valida solo se lo stesso rispetta gli standard previsti ed è completo di tutti gli allegati.

Il FORNITORE è tenuto alla consegna del software realizzato nell’ambiente di deployment concordato con DEA S.p.A., secondo le modalità definite.

DEA S.p.A. si riserva di chiedere la contestuale consegna di una copia del software (o di parti di esso) su supporto magnetico/ottico ovvero di richiedere la consegna anche accedendo ad apposite applicazioni messe a disposizione o via web.

In caso di indisponibilità degli ambienti sono concordate con DEA S.p.A. le modalità di consegna.

Il FORNITORE deve sempre accompagnare la consegna di funzionalità software con la relativa manualistica), completo delle Note di Rilascio con le informazioni necessarie alla gestione dell’installazione e configurazione.

Per tutti i prodotti, la presenza di anomalie/non conformità rilevate da DEA S.p.A. e per le quali è richiesta la revisione da parte del FORNITORE comporterà la riconsegna del prodotto corretto entro massimo 5 giorni lavorativi, fatto salvo diverso termine fissato da DEA S.p.A. stessa.

DEA S.p.A. si riserva di richiedere in qualsiasi momento la produzione di reportistica e/o documentazione ad hoc. Il FORNITORE è tenuto a consegnare tale reportistica e/o documentazione ad hoc al massimo entro 5 giorni lavorativi dalla richiesta, ovvero nel diverso tempo concordato con DEA S.p.A., ed eventualmente a riconsegnarla corretta entro il termine massimo di 3 giorni lavorativi.

Dovrà essere previsto l’aggiornamento della documentazione esistente o di quella prodotta nell’ambito della fornitura, al fine di mantenerla costantemente aggiornata.

L’aggiornamento della documentazione potrà avvenire per intero documento o per addendum, secondo quanto di volta in volta concordato.

Tutti i prodotti consegnati devono essere esenti da virus, codice maligno, spyware, ecc. o da componenti software estranee al contenuto dello specifico prodotto. DEA S.p.A. può verificare l’assenza di virus secondo le modalità e gli strumenti che ritiene più opportuni.

8. Servizi di Manutenzione “full service”

Il FORNITORE, nell’ambito del contratto, deve erogare un servizio di manutenzione agli applicativi di tipo “full service”. Pertanto tutte le attività oggetto del presente paragrafo devono comprendere le attività di deployment e il test in ambiente di stage, e successivamente in ambiente di produzione, presso la sede del cliente. Le attività di manutenzione possono essere eseguite, previa autorizzazione, anche attraverso un collegamento da remoto in VPN (crittografato) verso la sede del cliente.

I servizi di manutenzione comprendono le seguenti componenti:

• Manutenzione Correttiva

• Manutenzione Adeguativa

• Manutenzione Evolutiva

da prestare sull’Ambiente Software installato, in ottemperanza alle obbligazioni contrattuali descritti nel seguito.

I servizi di manutenzione nel loro insieme vengono erogati con le seguenti modalità:

• fino al termine delle attività di POST AVVIO (fine fase D): in forma gratuita per quanto riguarda la Manutenzione Correttiva ed Adeguativa.

• Durante il periodo di garanzia (FASE F): in forma gratuita per quanto riguarda la Manutenzione Correttiva e ai prezzi concordati per la Manutenzione Adeguativa.

• Dopo il periodo di garanzia, per una durata di 24 mesi, ai prezzi concordati per la manutenzione correttiva, previa semplice comunicazione scritta da parte di DEA S.p.A.

Il FORNITORE si impegna a indicare il nominativo di un Responsabile del Servizio di Manutenzione che sarà l’interfaccia con il cliente per tutte le problematiche (o le contestazioni che dovessero insorgere) legate alla gestione dei ticket o delle richieste di Manutenzione Evolutiva. La figura del Responsabile della Manutenzione potrà essere svolta dal Responsabile di Progetto designato dal FORNITORE.

8.1. Manutenzione Correttiva

Si intende come manutenzione correttiva la diagnosi delle cause e la rimozione degli effetti, sia sulle interfacce utente che sulle basi dati, qualora sopravvengano eventi imputabili a anomalie/lacune all’ambiente software, che possano compromettere una o più funzionalità offerte dal FORNITORE (compresa la sicurezza del sistema) e/o dei relativi livelli di servizio.

La Manutenzione correttiva è normalmente innescata da una segnalazione, ad esempio di impedimento all’esecuzione dell’applicazione/funzione o dal riscontro di differenze fra l’effettivo

funzionamento dell’Applicativo e quello atteso, come previsto dalla relativa documentazione o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente.

I malfunzionamenti, le cui cause non sono imputabili a difetti presenti nel codice sviluppato, ma ad errori tecnici, operativi o d’integrazione con altri sistemi (ad esempio interruzione della rete, uso improprio delle funzioni, etc.), comportano, da parte del servizio di Manutenzione, il supporto all’attività diagnostica sulla causa del malfunzionamento, a fronte della segnalazione pervenuta.

La classificazione del malfunzionamento sarà a carico di DEA S.p.A. secondo modalità da definire puntualmente in fase di avvio.

Il processo di gestione generale della Manutenzione Xxxxxxxxxx prevede che la segnalazione potrà essere inviata da Dea S.p.A. al FORNITORE il quale provvederà a:

• Confermare la presa in carico della segnalazione di malfunzionamento;

• Analizzare il problema, contattando se necessario il personale preposto di DEA S.p.A. per eventuali approfondimenti;

• Comunicare tempistiche entro cui il FORNITORE si impegna a regredire l’anomalia in accordo con gli SLA previsti al paragrafo 10.2.

Si richiede pertanto che il FORNITORE metta a disposizione un sistema di trouble ticketing gestito da un unico punto di contatto dedicato alla ricezione, segnalazione, gestione e tracciatura delle anomalie dell’applicativo, raggiungibile attraverso almeno due canali tra i 3 sotto-elencati:

• Sito web dove il cliente possa inserire e gestire le chiamate di supporto h24

• Casella di posta elettronica dedicata;

• Numero di telefono contattabile dal lunedì al venerdì dalle ore 8.30 alle ore 17.30 esclusi giorni festivi;

Si precisa che il FORNITORE nell’ambito del servizio di Manutenzione deve effettuare almeno le attività di seguito elencate:

• Segnalazione di presa in carico della richiesta;

• Diagnosi della natura del malfunzionamento e comunicazione a DEA S.p.A. della natura dello stesso;

• Risoluzione delle segnalazioni effettuate dall’utente, anche attraverso una soluzione temporanea, secondo gli SLA previsti dal contratto e proposti in Appendice 1;

• Nel caso di applicazione di soluzione temporanea, risoluzione definitiva della segnalazione secondo gli SLA previsti dal contratto;

• Verifica ed eventuale aggiornamento della documentazione consegnata a fronte dell’aggiornamento.

Gli interventi di manutenzione devono essere effettuati in orari concordati con la società, in modo da limitare al massimo gli impatti con l’operatività di DEA S.p.A.

Il canone di manutenzione correttiva comprende tutte le attività di gestione dell’anomalia presso l’ambiente software del cliente, comprese le relative attività di test in ambiente di stage e implementazione in ambiente di produzione.

8.2. Manutenzione Adeguativa

Si intende come manutenzione adeguativa l’insieme delle operazioni di aggiornamento dell’ambiente software di DEA S.p.A., al fine di allinearlo alle nuove disposizioni normative emanate dagli Enti regolatori del settore (cfr. paragrafo 6.2 – Requisiti Funzionali) entro le scadenze previste da ciascuna normativa, al fine di non risultare inadempiente ed incorrere nelle sanzioni previste.

Il FORNITORE dovrà quindi garantire un costante recepimento degli aggiornamenti alla normativa e agli obblighi informativi prevista per le aziende che operano nell’ambito della fornitura di servizi di distribuzione e misura di Energia Elettrica, specificando le modalità e le tempistiche di implementazione e garantendo quindi il rispetto agli adempimenti oggetto di tali aggiornamenti attraverso l’implementazione presso l’ambiente applicativo del cliente di nuove funzionalità appartenenti ad Aree funzionali già implementate o integrazioni a funzionalità già esistenti, nonché funzionalità non previste ma necessarie per l’adeguamento alla normativa.

Il canone di manutenzione adeguativa comprende tutte le attività di gestione degli aggiornamenti presso il cliente comprese le relative attività di test in ambiente di collaudo e implementazione in ambiente di produzione. Il canone deve inoltre comprendere le corrispondenti attività di formazione sulle nuove funzionalità implementate incluso il rilascio della documentazione tecnica a corredo dei nuovi moduli software (ad es. Manuale Utente, Note di Rilascio, ecc.). Infine il canone deve comprendere anche il rilascio, senza alcun onere per il cliente, di eventuali licenze d’uso per nuovi moduli installati.

8.3. Manutenzione Evolutiva

Si intende come manutenzione evolutiva la manutenzione dell’ambiente software di DEA S.p.A. atta ad ampliare funzionalità preesistenti e/o integrarne di nuove.

Il FORNITORE è tenuto a quotare le giornate necessarie per la realizzazione di nuove funzionalità (cd. Progetto) richieste da DEA S.p.A. e a concordare con essa i tempi e le modalità dell’eventuale realizzazione secondo un cronoprogramma da redigere a cura del FORNITORE.

Il cronoprogramma, per ogni Progetto, dovrà comprendere:

• Attività di deployment e parametrizzazione in ambiente di test

• Collaudo della funzionalità

• Messa in produzione della funzionalità

Ogni funzionalità implementata sarà corredata da una garanzia a copertura dei malfunzionamenti della durata pari al periodo di garanzia previsto per la fornitura principale del presente capitolato.

9. Pagamenti e Fatturazione

La fatturazione della fornitura avverrà secondo le seguenti modalità:

• Acconto del 10% dell’importo complessivo della fornitura (esclusi canoni di manutenzione) alla stipula del contratto;

• Ulteriore acconto del 20% dell’importo complessivo della fornitura (esclusi canoni di manutenzione), al termine delle attività di deployment (termine della fase A);

• Ulteriore acconto del 20% dell’importo complessivo della fornitura (esclusi canoni di manutenzione), al termine dell’attività di GO LIVE (fine fase C);

• Ulteriore acconto del 40% al rilascio in produzione dell’intero applicativo (comprese funzionalità “NON CORE” a seguito di positivo collaudo) correttamente funzionante secondo quanto previsto da specifiche, e certificato da DEA S.p.A. (fase E – chiusura progetto);

• Saldo dell’importo complessivo della fornitura (esclusi canoni di manutenzione) al termine del periodo di Garanzia (fase G);

• Il Fornitore non potrà vantare diritto ad altri compensi ovvero ad adeguamenti o aumenti del corrispettivo previsto.

Gli importi dei canoni di manutenzione full service dovranno essere fatturati su base trimestrale posticipata, a partire dall’inizio di applicazione del canone, così come previsto al paragrafo 8.

In caso di manutenzione evolutiva su richiesta del cliente, l’intervento potrà essere fatturato al termine dello stesso, previo esito positivo del collaudo.

Il pagamento delle fatture avverrà a 60 giorni data fattura fine mese a mezzo bonifico bancario.

10. Penalità

Il FORNITORE, in caso di inadempienze e/o di ritardo nel compimento delle sue prestazioni, è tenuto a sottostare ad una penale pecuniaria.

DEA S.p.A., nonostante l'applicazione delle penali, conserva la facoltà di richiedere il risarcimento degli ulteriori danni. In particolare se, a causa di ritardi imputabili al FORNITORE, il cliente dovesse incorrere in penalizzazioni previste dagli Enti Regolatori del settore Distribuzione o Misura Energia Elettrica o ritardi nella fatturazione, DEA S.p.A. ha facoltà di rivalersi sul FORNITORE stesso.

La penale viene applicata dal cliente con semplice comunicazione scritta al FORNITORE; il relativo importo viene dedotto dall'importo dei compensi ad esso spettanti, anche durante il corso del contratto.

Se l'importo delle penali è superiore all'ammontare dei compensi ancora dovuti, DEA S.p.A., per il recupero del suo credito residuo, può avvalersi delle garanzie indicate nel presente Capitolato e, in caso di insufficienza, di ogni altro mezzo, senza bisogno di diffida o di procedimento giudiziario.

L’importo complessivo delle penali non può superare il 10% dell’importo contrattuale, raggiunto il quale DEA S.p.A. si riserva il diritto di risolvere il contratto, fatto salvo il risarcimento di maggiori danni, così come in caso di reiterati ritardi, irregolarità nell’esecuzione degli obblighi contrattuali o inadempimenti.

Le situazioni che, se rilevate, danno diritto di procedere all’applicazione della penale saranno le seguenti:

10.1. Penali per ritardi nelle attività di progetto

• Ritardo nella messa a disposizione dell’Ambiente di Collaudo (termine della fase A): 0,1% dell’importo complessivo del contratto per ogni giorno solare di ritardo.

• Ritardo nel positivo superamento del collaudo delle funzionalità “CORE” (termine della fase B), comprese integrazioni con i sistemi legacy aziendali: 0,1% dell’importo complessivo del contratto per ogni giorno solare di ritardo.

• Ritardo nella messa in produzione dell’Ambiente Software a seguito di positivo collaudo (termine della fase C), escluse le funzionalità “NON CORE”: 0,2% dell’importo complessivo del contratto per ogni giorno solare di ritardo.

• Ritardo nel positivo superamento del collaudo delle funzionalità “NON CORE” (termine della fase D), escluse eventuali funzionalità OPZIONALI installate: 0,05% dell’importo complessivo del contratto per ogni giorno lavorativo di ritardo.

Il conteggio dei giorni di ritardo rispetto ad una determinata fase di progetto sarà calcolato sulla differenza tra i giorni effettivamente trascorsi a partire dalla data di stipula del contratto e

la durata massima dal progetto prevista per la conclusione della fase in questione (ad. es. per la fase C = 60 + 45 + 15 gg solari). Non saranno contabilizzabili eventuali ritardi imputabili a DEA S.p.A.

10.2. Penali per il mancato rispetto dei livelli di servizio di manutenzione correttiva (compreso periodo di garanzia)

Descrizione	Gravità1	Livelli di Servizio (SLA)	Penale
Tempo a disposizione per la presa in carico di segnalazioni di anomalia all’Ambiente Software in produzione	1	1 ora lavorativa dalla segnalazione dell’anomalia al fornitore	€ 50,00 per ogni ora lavorativa di ritardo nella presa in carico della segnalazione
	2	4 ore lavorative dalla segnalazione dell’anomalia al fornitore	€ 50,00 per ogni ora lavorativa di ritardo nella presa in carico della segnalazione
	3	8 ore lavorative dalla segnalazione dell’anomalia al fornitore	€ 200,00 per ogni giorno o frazione di giorno lavorativo di ritardo nella presa in carico della segnalazione
Tempo a disposizione per la risoluzione, anche con soluzione temporanea, dell’anomalia segnalata	1	6 ore lavorative dalla segnalazione dell’anomalia al fornitore	€ 200,00 per ogni ora o frazione di ora lavorativa di ritardo nella risoluzione della segnalazione
	2	2 giorni lavorativi dalla segnalazione dell’anomalia al fornitore	€ 100,00 ogni ora lavorativa di ritardo di ritardo nella risoluzione della segnalazione
	3	5 gg lavorativi lavorative segnalazione dell’anomalia al fornitore	€ 300,00 per ogni giorno o frazione di giorno lavorativo di ritardo nella risoluzione della segnalazione
Tempo a disposizione per la risoluzione definitiva della anomalia		20 gg lavorativi dalla segnalazione dell’anomalia al fornitore	€ 400,00 per ogni giorno lavorativo di ritardo nella risoluzione della segnalazione

Tabella 6

1 Gravità 1 – Applicativo o singola funzionalità critica bloccata: condizione di emergenza.

Gravità 2 - Applicativo o singola funzionalità non operativa: l’operatività complessiva non è immediatamente compromessa, esistono soluzioni alternative che consentono di ovviare temporaneamente al problema.

Gravità 3 - Applicativo o singola funzionalità non critica funziona in maniera degradata: l’operatività complessiva non è immediatamente compromessa.

10.3. Penali per il mancato rispetto dei livelli di servizio di manutenzione adeguativa

Descrizione

Livelli di Servizio

Penale

Tempo a disposizione per l’adeguamento dell’ambiente software ai requisiti normativi previsti dagli Enti regolatori di cui al par. 6.2.

Adeguamento del software entro la scadenza prevista dagli Enti regolatori di settore

€ 500,00 per ogni giorno lavorativo di ritardo nella messa a disposizione dell’adeguamento del software debitamente collaudato.

Copertura totale delle sanzioni previste in casi di inadempienza nei confronti degli Enti regolatori, attribuibile alla non disponibilità dell’adeguamento software.

Tabella 7

Document Metadata

Table of Contents

Distribuzione Elettrica Adriatica S.p.A. Area Sistemi Informativi Area Commerciale

Document Metadata