CAPITOLATO TECNICO
v03_13032
Allegato 7
Lario Reti Holding S.p.A.
CAPITOLATO TECNICO
INFRASTRUTTURA IT
REALIZZAZIONE DI UN’ENTERPRISE DATA PLATFORM ABILITANTE ALLE APPLICAZIONI DSS WMS, AI, ADVANCED ANALYTICS PER LARIO RETI
Giugno 2023
Intervento finanziato dall’Unione Europea nel contesto dell’iniziativa Next Generation EU con codice PNRR M2C4-I4.2_058 incluso nel “Progetto per la riduzione delle perdite nelle reti di distribuzione dell’acqua, compresa la digitalizzazione e il monitoraggio delle reti, in Provincia di Lecco – PNRR M2C4-I4.2”
Sede legale: |Lecco – Xxx Xxxxxxx, 00
Contatti: |Telefono – 0000.000.000 |E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx
|Sito web – xxx.xxxxxxxxx.xx |Servizio Clienti – 800.085.588 |Pronto Intervento – 800.894.081
Sommario
ART. 2 - DOCUMENTI CONTRATTUALI E ACRONOMI 6
ART. 3 - OGGETTO DELL'APPALTO 8
ART. 4 - REQUISITI DI INTEGRAZIONE E ARCHITETTURA 8
ART. 5 - REQUISITI TECNICI ED INFRASTRUTTRURALI 12
ART. 6 - DESCRIZIONE DELLE PRESTAZIONI RICHIESTE 21
ART. 7 - PROPOSTA DEL SOFTWARE E DISEGNO DELLA SOLUZIONE 21
ART. 8 - REALIZZAZIONE DEL PROGETTO DI IMPLEMENTAZIONE 21
ART. 9 - RISORSE E PIANIFICAZIONE 23
ART. 10 - DEFINIZIONE E DISEGNO ARCHITETTURA APPLICATIVA/INTEGRAZIONI 27
ART. 11 - ANALISI FUNZIONALE PER LA RACCOLTA DEI REQUISITI DI BUSINESS 27
ART. 12 - CONFIGURAZIONE / SVILUPPO 27
ART. 13 - SYSTEM, INTEGRETION E PERFORMANCE E TEST 28
ART. 16 - MIGRAZIONE IN PRODUZIONE 30
ART. 19 - GESTIONE DEL SERVIZIO DI MANUTENZIONE DI BASE 32
ART. 21 - SUPPORTO APPLICATIVO AGLI UTENTI 34
ART. 22 - FORMAZIONE DEL PERSONALE NELL’USO DELLE APPLICAZIONI 34
ART. 23 - CONFIGURAZIONE DEL SISTEMA 35
ART. 24 - PREDISPOSIZIONE DI REPORT ED ESTRAZIONI DEI DATI DAL DATA BASE 36
ART. 25 - MANUTENZIONE CORRETTIVA (Business Continuity) 37
ART. 26 - MANUTENZIONE ADEGUATIVA 38
ART. 27 - PREDISPOSIZIONE PROCEDURE E SCRIPT PER LA RETTIFICA DI DATI ERRATI SU DATABASE 38
ART. 28 - MONITORING APPLICATIVO 38
ART. 29 - ATTIVITA’ DI CONSULENZA A SUPPORTO DEL PASSAGGIO DI CONSEGNE AD
ALTRO AGGIUDICATARIO AL TERMINE DEL CONTRATTO 39
ART. 30 - GESTIONE DEL SERVIZIO DI MANUTENZIONE EVOLUTIVA E SERVIZI A CONSUMO ..
ART. 32 - VINCOLI GENERALI DEL SERVIZIO 45
ART. 33 - PROFILI PROFESSIONALI RICHIESTI 48
ART. 34 - DOCUMENTAZIONE DI PROGETTO 55
ART. 35 - IMPORTO E DURATA DELL’APPALTO 56
ART. 36 - GESTIONE DEL CONTRATTO 58
ART. 38 - APPARATI HARDWARE E LICENZE SOFTWARE 59
ART. 39 - PROPRIETA’ DEL SOFTWARE SVILUPPATO NELL’AMBITO DELL’APPALTO 59
ART. 40 - PERIODO DI PROVA DEL PERSONALE DELL’AGGIUDICATARIO 60
ART. 1 - PREMESSA
Nell’ottica dell’ammodernamento continuo e, contestualmente, del raggiungimento degli obiettivi indicati dalle normative ARERA, si è deciso di realizzare, all’interno delle iniziative del progetto PNRR, un’infrastruttura resiliente, cloud, a basso impatto energetico ed integrata con la mappa applicativa di Lario Reti, con il fine ultimo di gestire e sviluppare modelli predittivi volti a fornire al gruppo strumenti attivi di prevenzione delle perdite, in sinergia con l’abilitazione all’utilizzo degli algoritmi di machine learning e artificial intelligence.
Gli algoritmi di machine learning ed artificial intelligence, possono essere efficaci solo se la gestione del dato avviene su infrastrutture data centriche che consentono di acquisire le informazioni da diverse fonti (strutturate e non), archiviarle e storicizzarle permettendo agli algoritmi di imparare e perfezionare le tecniche predittive; a tale scopo verrà realizzata un’Enterprise Data Platform.
L’Enterprise Data Platform, che si intende realizzare, integrerà dati provenienti dai sistemi di telecontrollo e IoT, dai sistemi della mappa applicativa di Lario Reti con dati provenienti da sistemi terzi (ad es. meteo, open data, etc).
L’Enterprise Data Platform dovrà includere la realizzazione di un datalake che fungerà da collettore di dati provenienti da fonti eterogenee e dovrà essere arricchita con tutti i dati necessari per abilitare le integrazioni con applicazioni quali ad esempio DSS WMS (Decision Support Sistem Water Management System), AI (Artificial Intelligence), Predictive Maintenance,.
Oggetto del seguente capitolato è quindi il progetto di realizzazione sulle più moderne piattaforme cloud dell’Enterprise Data Platform, garantendo adeguate risorse di calcolo e di spazio dati per l’attuazione dei modelli di simulazione utili alle applicazioni sopra citate.
I principali benefici attesi dalla seguente iniziativa sono i seguenti:
• disponibilità di una Enterprise Data Platform che apra la strada a progetti interfunzionali con un modello semantico comune;
• centralizzazione, riutilizzabilità e gestione comune dei dati;
• riduzione del Time-to-Market per lo sviluppo di nuovi progetti di business analytics;
• disponibilità di un’architettura dati moderna, flessibile, scalabile, affidabile e sicura;
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
• disponibilità di una data platform a supporto delle iniziative in ambito Big Data, Advanced Analytics, DSS WMS, AI, Predictive Maintenance, IoT e Machine Learning della mappa applicativa di Lario Reti;
• definizione di linee guida per la Data Governance dettagliando specifici ruoli e responsabilità;
• diffusione della cultura dei dati condivisa in tutta l’organizzazione.
Lario Reti, conscio dell’importanza informativa dei dati e delle informazioni provenienti dai propri asset, ha ben compreso che un quadro incompleto dei dati disponibili, può condurre ad analisi fuorvianti, conclusioni analitiche spurie e processi decisionali inibiti, per tale motivo ritiene strategico dotarsi di un’Enterprise Data Plaform che raccoglie tutte le fonti dati necessarie al decision making ed al reporting aziendale e correla, quindi, i dati provenienti da più fonti, storicizzandoli in una posizione centralizzata, fruibile da tutte le applicazioni di Lario Reti.
La centralizzazione dei dati consentirà di alimentare le nuove applicazioni e gli analytics da un’unica fonte, senza dover accedere continuamente alle applicazioni sorgenti dei dati. Inoltre, la nuova infrastruttura sarà utilizzata come repository ufficiale dei dati di Lario Reti garantendo qualità, coerenza e documentazione funzionale/semantica degli stessi.
Le informazioni dovranno essere caricate nell’Enterprise Data Platform, nei formati nativi,
prima di poter essere elaborate e rese disponibili ai sistemi di Lario Reti.
Analisti, manager e responsabili delle decisioni potranno usufruire di questa nuova infrastruttura per migliorare la qualità e la disponibilità dei dati e le tecnologie associate: l’introduzione dell’Enterprise Data Platform garantirà un approccio strategico e moderno alla progettazione della pipeline di dati ed aiuterà a determinare, in ultima analisi, anche il valore aziendale.
La realizzazione dell’Enterprise Data Platform è strategicamente necessaria per consentire la continua evoluzione tecnologica che apre grandi opportunità di miglioramento della qualità del servizio idrico verso i cittadini e risparmi sui costi legati alle attività manutentive o di emergenza.
ART. 2 - DOCUMENTI CONTRATTUALI E ACRONOMI
La seguente tabella descrive i documenti allegati al presente capitolato:
SIGLA | DESCRIZIONE | NOME FILE |
LDR | Lista dei requisiti | Lista dei requisiti DIGITAL_HUB.xls |
In tutto il documento l’allegato sarà indicato utilizzando le sigle di cui sopra. La seguente tabella descrive gli acronimi utilizzati nel presente documento: Acronimi
Tabella 1 - Acronimi
ACRONIMO | SIGNIFICATO |
ARERA | Autorità di Regolazione per Energia Reti e Ambiente. |
cti | Commissione tecnica interna composta da personale dipendente di Lario Reti e da consulenti esterni esperti sul prodotto software aggiudicatario, che sarà avviata in fase esecutiva del servizio, con il ruolo di supervisore tecnico delle attività svolte. |
cg | Comitato guida per la gestione e il controllo delle attività riguardanti i servizi inclusi nel capitolato, composta da: • personale della Direzione Information Technology di Lario Reti • consulenti esterni esperti sul prodotto cloud aggiudicatario • Contract Manager • Project Manager e Service Manager della società appaltatrice |
AI | Artificial Intelligence |
OCR | Optical Character Recognition sono programmi dedicati al rilevamento dei caratteri digitali contenuti in un documento; i recenti software OCR utilizzano algoritmi in grado di riconoscere i contorni e in grado di ricostruire oltre al testo anche la formattazione della pagina. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ACRONIMO | SIGNIFICATO |
CDS | Carta dei Servizi: è il documento che individua gli standard di qualità nelle attività di gestione dei servizi di acquedotto, fognatura e depurazione. In base ai livelli di standard indicati nel documento la società può emettere eventuali indennizzi agli utenti del Servizio Idrico integrato. |
SII | Sistema Informativo Integrato è lo strumento messo a disposizione dall’Acquirente Unico con la legge 129/2010 che gestisce i flussi informativi relativi ai mercati Energia Elettrica, Gas naturale e del settore idrico. |
La soluzione dovrà essere rispondente e conforme alla normativa vigente nell’ambito del Servizio Idrico Integrato, in quanto potrà essere utilizzata per il calcolo degli indicatori della qualità tecnica. Si riportano a titolo non esaustivo la normativa di riferimento:
Descrizione | Riferimento |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 3 - OGGETTO DELL'APPALTO
L’oggetto del presente appalto riguarda la realizzazione di un’Enterprise Data Platform, su cui verranno integrate tutte le fonti dati (strutturate e non) necessarie per l’alimentazione delle soluzioni DSS WMS, AI, Predictive Maintenance, Advanced Analytics (ad es. Qlik e PowerBI) ed altre applicazioni strategiche di Lario Reti
Le attività richieste all’aggiudicatario sono le seguenti:
• Realizzazione del Progetto di implementazione
o Risorse e pianificazione
▪ Definizione gruppo di lavoro, ruoli e responsabilità
▪ Definizione pianificazione di massima
▪ Definizione piano di dettaglio
o Definizione e disegno architettura applicativa/integrazioni
o Analisi funzionale per la raccolta dei requisiti di business
o Configurazione/sviluppo
o System, Integration e Performance Test
o User Acceptance Test/Collaudo
o Training
o Migrazione in produzione
o Golive
o Post-Golive
• Gestione del Servizio di Manutenzione di Base
• Gestione del Servizio di Manutenzione Evolutiva
ART. 4 - REQUISITI DI INTEGRAZIONE E ARCHITETTURA
La stazione appaltante richiede ai concorrenti una descrizione complessiva dell’Enterprise Data Platform che si intende proporre, fornendo, quindi, una visione d’insieme delle potenzialità che tale architettura dati è in grado di offrire; saranno oggetto di valutazione sia la visione complessiva che le tecnologie proposte.
Di seguito si riporta una breve descrizione delle principali fonti dati che dovranno essere
integrate nell’Enterprise Data Platform di Lario Reti (si veda mappa applicativa):
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Tabella 2 Principali fonti dati
CRM Salesforce | Soluzione Salesforce Service cloud per la gestione dei case multicanale e il calcolo e il monitoraggio delle performance legate ai canali, ai parametri descritti nella carta servizi e a quelli descritti nella delibera dell’autorità ARERA, inerenti i processi gestiti dal sistema in ambito commerciale ed industriale. Comprende: Field Service, Chat, Knowledge Management, Service Cloud. Gestisce sia clienti civili sia clienti industriali. Gestisce gli appuntamenti (campionamenti) dei clienti industriali tramite il modulo Field Service. |
Billing NetA2A | Sistema che gestisce la fatturazione e gestione contratti dei clienti di Lario Reti. Integrato principalmente con CRM (Salesforce), ERP (NetA SIAL in corso di migrazione su Oracle Erp Fusion a metà del 2024), gestisce i dati commerciali del cliente finale e della relativa fornitura, necessari alla fatturazione. Oltre alla fatturazione (bolletta), gestisce gli incassi, le note di credito/debito, la gestione dei piani di rateizzazione ed il recupero crediti. |
NetA SIAL (in sostituzione nel corso del 2024 con Oracle Fusion ERP) | Sistema ERP di lario reti che gestisce principalmente i processi contabili, il ciclo passivo, il ciclo attivo, i magazzini.A partire dalla seconda metà del 2024 verrà sostituito dal prodotto Oracle Fusion ERP Cloud . |
Oracle Fusion ERP | Sistema ERP in cloud di Lario Reti che gestirà a partire dalla seconda metà del 2024 i processi contabili, il ciclo passivo, il ciclo attivo, i magazzini, i cespiti. È basato sul prodotto Oracle cloud Fusion. |
LIMS | Sistema di Laboratory Information Management System (LIMS) che supporta l'intero processo dal campionamento all'emissione del rapporto di prova (RDP) e di tutte le statistiche di analisi collegate alle 3 aree di copertura: acque potabili, acque reflue e fanghi. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Infoworks | Sistema per la modellazione idraulica sia delle reti in pressione (acquedotto) che delle reti a pelo libero (fognatura) |
Suite DHI | Composta da più applicativi: sistema per il monitoraggio dei distretti idrici di acquedotto e sistema per la creazione di scenari di rete basati su modello idraulico |
OVARRO | Piattaforma per la consultazione di strumentazione varia legata al settore idrico: data logger di pressione, misure di portata, noise logger per la ricerca perdite |
INFLOWMATIX | Piattaforma per la consultazione di strumentazione legata al settore idrico: registrazione di transitori di pressione |
RADAR | Piattaforma per la consultazione di strumentazione legata al settore idrico: registrazione di transitori di pressione e ricerca perdite |
FRACTA | Sistema di supporto decisionale che utilizza l’intelligenza artificiale applicata alla manutenzione predittiva delle infrastrutture |
GIS | Sistema per la gestione cartografica delle reti e degli impianti. È basato sui prodotti Esri e Geocortex. Raccoglie i dati delle reti e degli impianti e consente di divulgare le informazioni a tutte le strutture legate al servizio idrico integrato agli operatori interni ed esterni (imprese) e ai tecnici comunali. Le informazioni sono consultabili anche dal campo. |
TELECONTROLLO | applicazione che effettua, tramite appositi sensori SCADA, il monitoraggio degli apparati presenti negli impianti e delle reti. La soluzione è basata sull’applicativo telecontrollo di ID&A |
Consumi POD Edison | Dati di consumo elettrico provenienti dal sito del gestore |
Dati Meteo ARPA Lombardia | Dati di precipitazione, temperatura, portate fluviali scaricabili dal sito di ARPA Lombardia |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Letture e consumi Contatori | Dati di lettura e allarmistica dei contatori d’utenza smart installati alle utenze servite da Lario Reti Holding. I dati provengo dai Sistemi di Acquisizione Centralizzati proprietari di ogni fornitore (Watertech, Sensus, Kamstrup) |
A titolo informativo, ma non esaustivo, forniamo un ulteriore dettaglio delle fonti dati che dovranno alimentare l’Enterprise Data Platform di Lario Reti con la frequenza di aggiornamento richiesta e la profondità storica che dovrà essere predisposta:
Tabella 3 Frequenza di aggiornamento delle fonti dati
FONTE DATI | STORICO | FREQUENZA DI AGGIORNAMENTO |
Telecontrollo | Profondità Storico 60 mesi (da gennaio 2019) | Real Time |
CRM Salesforce | Profondità storico 3 anni | Real Time |
LIMS | Profondità storico dal 2018 | Giornaliero |
ARERA | Profondità storica dal 2016 | Mensile |
GIS | Totale | Giornaliero |
LETTURE | Profondità Storico dal 2018 | On demand |
NETA2A | Profondità Storico dal 2018 | Real Time |
Suite DHI | Profondità storico dal 2019 | Giornaliero |
A titolo puramente indicativo, si forniscono i volumi delle principali fonti alimentanti:
Tabella 4 Volumi delle principali fonti alimentanti
FONTE DATI | MB giornalieri |
Telecontrollo | 920 |
CRM Salesforce | 5 |
NETA2A | 50 |
LIMS | 25 |
GIS | 2,50 |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
I concorrenti, per la realizzazione dell’Enterprise Data Platform, potranno proporre eventuali soluzioni ETL i cui costi di licenza, così come i costi dell’infrastruttura cloud e di tutte le componenti applicative proposte, dovranno essere inclusi nella proposta complessiva.
ART. 5 - REQUISITI TECNICI ED INFRASTRUTTRURALI
La seguente tabella descrive i requisiti tecnici ed infrastrutturali che la soluzione proposta dal concorrente dovrà soddisfare; qualora la soluzione non possedesse tali requisiti “off the shelf”, si richiede di specificare la stima in gg/uu (giorni/uomo) necessari per lo sviluppo del singolo requisito. I concorrenti dovranno compilare l’apposito allegato (Lista Dei Requisiti DIGITAL_HUB) dettagliando nel campo note di ogni requisito il livello di compliance dichiarato e gli eventuali riferimenti ai documenti tecnici inseriti nell’offerta che descrivono la soluzione proposta. Lo sviluppo necessario alla copertura dei requisiti richiesti dovrà essere incluso nella proposta economica senza alcun onere aggiuntivo a carico della stazione appaltante.
Tabella 5 Requisiti Tecnici ed infrastrutturali
Requisiti Tecnici | ||
ID Requisito | Area d'intervento | Descrizione |
RAR_00 | Architettura e Solution Management | |
RAR_01 | Architettura | Il fornitore della soluzione dovrà descrivere l’architettura applicativa, dettagliando i singoli componenti ed indicando le tecnologie e le versioni software adottate (ad esempio database postgresql versione xx, database Oracle versione xx, …). Nessun componente della soluzione proposta dovrà essere vicina allo stato di end-of-life (incluse librerie, API, etc.). |
RAR_02 | Roadmap | Il fornitore dovrà presentare la roadmap della soluzione proposta che includa l’evoluzione della stessa per almeno tutta la durata del contratto. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RAR_03 | Architettura | L’architettura applicativa dovrà includere tutte le interfacce che il sistema è in grado di esporre verso applicativi esterni e le tecnologie usate; a tal proposito si richiede che la soluzione proposta esponga API in formato REST/SOAP/JSON, utilizzi protocolli di integrazione non proprietari e possa essere integrata tramite flussi application to application (web services, flussi batch sftp) con i sistemi della mappa applicativa di Lario Reti. |
RAR_04 | Architettura | La soluzione deve essere scalabile (fornire dettagli sulle modalità di scalabilità HW e SW). |
RAR_05 | Referenze | Il fornitore deve fornire documentazione dettagliata (case studies, customer reference, success stories) sull’utilizzo della versione della soluzione proposta in realtà analoghe al Lario Reti. |
RAR_06 | Architettura | Il fornitore deve dettagliare eventuali vincoli architetturali e limitazioni della soluzione proposta. Deve inoltre fornire indicazioni su eventuali point of failure, processi di gestione e potenziali impatti sul servizio. |
RAR_07 | Architettura | Nessun componente della soluzione proposta deve essere vicina allo stato di end-of-life (incluse librerie, API, etc.). |
RAR_08 | Architettura | La soluzione deve prevedere meccanismi di debugging facilmente attivabili/disattivabili con diversi livelli di dettaglio. |
RAR_09 | Architettura | Il fornitore deve inviare dettagliata documentazione sull'error handling ed i tools di debugging disponibili per la soluzione proposta. |
RAR_10 | Architettura | Il fornitore deve indicare se la soluzione include tools che aiutino ad identificare gli errori che si verificano durante la fase di acquisizione dei dati (single row error identification, gestione degli scarti, strumenti di data quality embedded). |
RAR_11 | Architettura | Il fornitore deve dettagliare le caratteristiche HW degli ambienti di sviluppo, test, collaudo/preproduzione e produzione inclusi nella soluzione proposta. |
RAR_12 | Architettura | Il fornitore dovrà consegnare un disegno architetturale dell'applicativo indicando il corretto sizing delle licenze e dei server/istanze cloud per predisporre una catena di ambienti (Sviluppo, Test, Pre-produzione, Produzione). L’ambiente di Pre-produzione dovrà avere delle caratteristiche tali da poter replicare esattamente le funzionalità e le performance dell’ambiente di Produzione. Tutti gli ambienti non di produzione dovranno prevedere delle procedure di anonimizzazione dei dati personali dei clienti. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Dovrà essere prevista la configurazione di utenze amministrative per il personale del Lario Reti. | ||
RAR_13 | Architettura | Gli ambienti sviluppati dal fornitore (Sviluppo, Test, Pre- produzione, Produzione) dovranno utilizzare gli strumenti necessari allo sviluppo di soluzione algoritmiche, sfruttando i tool necessari quali, ad esempio,Jupyter notebook ed altri affini. |
RAR_14 | Architettura | Le funzionalità della soluzione esposte verso i sistemi esterni dovranno usare interfacce basate su open standards (ad esempio XML, web services, SQL Standard). Si richiede di specificare la versione di ogni open standard disponibile nella soluzione proposta. |
RAR_15 | Architettura | La soluzione deve essere fruibile in modalità SaaS e/o PaaS senza alcuna limitazione rispetto a quanto disponibile su equivalente versione disponibile on Premise (sia per l’ambiente di produzione che per gli ambienti non di produzione, ad esempio per i dati caricabili su ambienti non di produzione). |
RAR_16 | Architettura | Il fornitore deve specificare con quali tecnologie è implementato il caricamento dei dati da eventuali fonti esterne, l'archiviazione e la profondità di storicizzazione che viene mantenuta. |
RAR_17 | Architettura | Il fornitore, ove applicabile, deve dettagliare le modalità di gestione del caching dei dati in memoria. |
RAR_18 | Architettura | Il fornitore deve dettagliare le modalità ed i protocolli utilizzati per la gestione dei dati tra i diversi layer che compongono la soluzione. |
RAR_19 | Architettura | Il fornitore deve dettagliare quali sono le tecnologie utilizzate a livello applicativo dalla soluzione (.NET, Java, etc.). |
RAR_20 | Architettura | Il committente valuterà positivamente la proposizione di soluzioni Paas/SaaS offerte su cloud quali AWS, Azure, Google. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RAR_21 | Architettura | La soluzione proposta dovrà prevedere un’interfaccia per il monitoraggio del corretto funzionamento degli apparati utilizzati per il trasferimento dei dati raccolti sugli asset di Lario Reti; tale interfaccia dovrà essere accessibile via web al personale di Lario Reti. |
RAR_22 | Availability and Reliability | La soluzione proposta (applicativa, infrastrutturale) dovrà garantire la continuità dei servizi H24, 7 giorni su 7, 365 giorni l’anno e dovrà garantire la possibilità di scalare facilmente risorse/istanze quando necessario. La soluzione dovrà altresì garantire la continuità operativa assicurando meccanismi di business continuity, recovery e back up. |
RAR_23 | Availability and Reliability | Il fonritore deve indicare come viene gestita l'affidabilità e la disponibilità della soluzione proposta, includendo informazioni su come viene risolto l'eventuale failure applicativo della soluzione e/o dei sistemi di comunicazione. |
RAR_24 | Availability and Reliability | Il fornitore deve descrivere i meccanismi di ridondanza applicati ai diversi livelli applicativi ed infrastrutturali. |
RAR_25 | Availability and Reliability | La soluzione non deve contenere alcun single point of failure. |
RAR_26 | Availability and Reliability | Il fornitore deve dettagliare le policy di Disaster & Recovery, includendo i tempi previsti per il ripristino delle precedenti configurazioni. |
RAR_27 | Availability and Reliability | Il fornitore deve dettagliare se la soluzione supporta meccanismi di query/data caching. |
RAR_28 | Availability and Reliability | Migrazione ed aggiornamenti della soluzione non devono causare perdite di dati o corruzione delle informazioni presenti nel sistema, Il fornitore deve descrivere se la soluzione prevede tali meccanismi e nel caso quali tools vengono per tali scopi. |
RAR_29 | Scalability | Il fornitore deve dettagliare eventuali costi legati all'espansione ed alla crescita del sistema (licenze, indicazione dei costi per l'ampliamento dell'infrastruttura HW aggiuntiva). |
RAR_30 | Scalability | Il fornitore deve dettagliare quali solo i key drivers che possono causare degradi prestazionali e quali sono i meccanismi previsti per mitigare tali problematiche. |
RAR_31 | Scalability | Il fornitore deve descrivere altre implementazioni in uso presso realtà analoghe al Lario Reti, sia in termini di volumi gestiti che di funzionalità utilizzate. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RAR_32 | System Management | Il fornitore deve descrivere le modalità di aggiornamento delle release software (come vengono applicate nel caso di SaaS e nel caso di PaaS, con quale frequenza, come viene garantita la compatibilità rispetto alle funzionalità utilizzate e le personalizzazioni effettuate). Il fornitore deve, altresì, indicare la modalità di gestione degli aggiornamenti, separando gli ambienti di produzione e non, indicandone la possibilità di pianificazione. |
RAR_33 | System Management | Il fornitore deve fornire documentazione dettagliata sugli strumenti di gestione/monitoraggio disponibili sulla soluzione. |
RAR_34 | System Management | La soluzione deve essere in grado di creare e trasmettere notifiche o alerts basati sul livello di severity di eventuali fault o disservizi. |
RAR_35 | System Management | La soluzione deve essere in grado di supportare meccanismi di monitoraggio, maintenance ed upgrade centralizzati. |
RAR_36 | System Management | Il fornitore deve descrivere le modalità di backup previste dalla soluzione e le performance attese nel caso di esecuzione del backup on line a caldo (senza spegnere alcuna componente applicativa). |
RAR_37 | System Management | Il fornitore deve dettagliare quali skill sono necessari per effettuare eventuali attività di amministrazione della soluzione. |
RAR_38 | System Management | Il fornitore deve descrivere le funzionalità, ove previste, nella UI per la gestione complessiva della soluzione. In particolare, deve dettagliare le seguenti aree: monitoraggio, fault management & diagnosi, management di ruoli e permission associate, performance management, configuration e versioning management. |
RAR_39 | System Management | Il fornitore deve dettagliare quali funzionalità sono disponibili per la verifica del corretto funzionamento delle componenti software della soluzione. |
RAR_40 | Data quality | Il fornitore deve dettagliare quali meccanismi di data quality sono disponibili nella soluzione e come misurare la qualità dei dati caricati nella soluzione. |
RAR_41 | Networking | Il fornitore deve inviare documentazione dettagliata che descriva l'architettura di rete, i protocolli utilizzati ed eventuali impatti da prevedere per garantire la corretta connettività. |
RAR_42 | Networking | Firewall, nat, address changes e configurazioni di rete richiesti dalla soluzione architetturale proposta non devono generare effetti indesiderati sulle funzionalità. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RMO_00 | Application Monitoring | |
RMO_01 | Application Monitoring | La soluzione deve essere in grado di misurare la QoS (KPI). La lista dei KPI oggetto di monitoraggio sarà concordata durante la fase di analisi. |
RMO_02 | Application Monitoring | La console di monitoraggio, ove applicabile, deve consentire il monitoraggio di ogni singola componente/funzionalità applicativa. |
RMO_03 | Application Monitoring | Devono essere disponibili meccanismi di System Performance Monitoring. |
RMO_04 | Application Monitoring | Devono essere disponibili meccanismi di Log activities Monitoring. |
RMO_05 | Application Monitoring | Devono essere disponibili meccanismi di Failure events Monitoring. |
RMO_06 | Logging and Audit Trail | La soluzione deve prevedere diversi livelli di logging. |
RMO_07 | Logging and Audit Trail | La soluzione deve consentire di loggare ogni tipo di transazione, indicando, ove applicabile, l'utente che ha eseguito l'attività, le modifiche introdotte, il timestamp della singola transazione. |
RMO_08 | Logging and Audit Trail | La soluzione deve consentire il tracciamento di qualsiasi attività di amministrazione. Le attività di amministrazione dovranno essere tracciate analogamente a qualsiasi altra transazione. |
RMO_09 | Logging and Audit Trail | La soluzione deve consentire il tracciamento di tutte le informazioni necessarie per la misurazione continua nel tempo, dell'accuratezza dei risultati prodotti e delle performance in termini di tempi di elaborazione, degli algoritmi di Artificial Intelligence, ove presenti. |
RMO_10 | Logging and Audit Trail | La soluzione deve consentire il tracciamento di tutte le informazioni riguardanti le conversazioni effettuate con i clienti, dagli algoritmi di Artificial Intelligence, ove presenti. |
RSIC_00 | Security Requirements | |
RSIC_01 | Security Requirements | La sicurezza deve poter essere gestita centralmente e su tutti i livelli applicativi ed infrastrutturali cui occorre accedere. |
RSIC_02 | Security Requirements | Il fornitore deve garantire l'aderenza alle normative vigenti in ambito sicurezza e privacy. |
RSIC_03 | Security Requirements | La soluzione deve fornire meccanismi di protezione verso tentativi di accesso non autorizzato e modifiche non autorizzate all'intera configurazione. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RSIC_04 | Security Requirements | La soluzione deve fornire meccanismi di allarme e di audit per fallimenti di security e tentativi di security breaches. |
RSIC_05 | Security Requirements | La soluzione deve fornire accessi securizzati per la gestione, lo sviluppo ed il deployment, su tutti gli ambienti proposti. |
RSIC_06 | Security Requirements | Il prodotto deve supportare meccanismi di cifratura dei canali di trasferimento dei dati tra differenti applicazioni e tra i diversi layer che lo compongono. |
RSIC_07 | Security Requirements | Il prodotto deve consentire la gestione di utenze miste (locali ed integrate con AD). Nel caso di utenze locali il sistema deve supportare le policy per la gestione delle password del Lario Reti (cambio automatico ogni 3 mesi, lunghezza, utilizzo di caratteri speciali, …). |
RSIC_08 | Security Requirements | La soluzione deve fornire funzionalità per gestire meccanismi di encryption di dati (personali e di business). |
RSIC_09 | Security Requirements | La soluzione deve prevedere meccanismi di profilazione e di controllo degli accessi per restringere l'utilizzo dei servizi ai soli utenti autorizzati garantendo la segregation of duty nel rispetto dei principi di least priviledge e need to know. |
RSIC_10 | Security Requirements | Il fornitore deve dettagliare eventuali costi e la complessità per la gestione dei meccanismi di data encryption e delle relative regole. Tali costi dovranno essere parte integrante dell'offerta. |
RSIC_11 | Security Requirements | Il fornitore deve spiegare come vengono limitati gli accessi ai dati ed alle funzionalità offerte dal sistema alle sole utenze abilitate. |
RSIC_12 | Security Requirements | La soluzione deve garantire la compliance rispetto a quanto previsto nel GDPR 2016/679 e successive rettifiche. In particolare, la soluzione deve rispettare tutti i requisiti tecnici previsti dalla normativa privacy vigente (principi di privacy by design e by default). |
RSIC_13 | Security Requirements | Nel caso di soluzioni SaaS/PaaS si richiede che i DataCenter su cui è presente la soluzione proposta ed i relativi dati, siano dislocati sul territorio EU. |
RSIC_14 | Security Requirements | La soluzione deve garantire l'aggiornamento continuo alle ultime patch di sicurezza di ogni singola componente (Hardware e Software). |
RSIC_15 | Security Requirements | La soluzione deve garantire meccanismi di controllo delle credenziali sia degli operatori sia degli amministratori e gestori dei contenuti del sistema, volti a evitare accessi malevoli e in generale qualsiasi attacco o intrusione volta all’appropriazione di dati personali o aziendali. Si richiede di specificare la possibilità di attivare meccanismi di strong authentication |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RPER_00 | Performance Benchmarking & Capacity Planning | |
RPER_01 | Performance Benchmarking & Capacity Planning | La soluzione deve prevedere meccanismi di caching per velocizzare accessi ripetuti alle stesse informazioni (purché non contengano dati sensibili). |
RPER_02 | Performance Benchmarking & Capacity Planning | Il fornitore deve fornire dettagli sulle performance e le caratteristiche della soluzione relative a: -- massima capacity e throughput -- response time per il caricamento dei dati -- response time per le sessioni utente -- volumi di picco e medi gestiti in progetti e realtà similari -- sessioni di utenti concorrenti |
RINT_00 | Integrazione | |
RINT_01 | Integrazione strumenti di Business Intelligence | La soluzione deve essere integrabile automaticamente, anche attraverso meccanismi di web services e/o standard API, con le soluzioni di BI di Lario Reti (Qlik, Power BI). |
RINT_02 | Integrazione sistemi di auditing | La soluzione deve essere in grado di offrire funzionalità di export dei dati relativi alle attività (inclusi gli accessi) degli amministratori di sistema adottata da Lario Reti (ad esempio file txt, csv, viste, PDF non modificabili). |
RINT_03 | Reporting | La soluzione dovrà consentire agli utenti di estrarre i dati elaborati in formati standard quali csv, excel; eventuali report e/o dashboard messe a disposizione dalla soluzione proposta dovranno essere estraibili nei formati office standard e in pdf. |
RINT_04 | Integrazione SSO | La soluzione, qualora abbia delle interfacce utente, dovrà essere integrata con l'active directory aziendale di Lario Reti (Microsoft AD) utilizzando le seguenti modalità di integrazione: • SAML2.0 • OAUTH2 • Kerberos per la windows native autenticazione • LDAP mediante form di inserimento credenziali. |
RINT_05 | Reporting | La soluzione deve prevedere la disponibilità di app mobile o web app per la consultazione di dati e/o della reportistica. |
RINT_06 | Integrazione Telecontrollo | La soluzione deve essere integrabile con i sistemi di telecontrollo di Lario Reti |
RPR_00 | Proprietà dei dati e del software |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RPR_01 | Dati | Tutti i dati, provenienti da apparati installati su asset di Lario Reti, dovranno rimanere di proprietà del committente. Al termine del contratto, il fornitore dovrà restituire tutti i dati e le elaborazioni effettuate, garantendo la rimozione degli stessi dai propri sistemi. |
RPR_02 | Dati | La soluzione dovrà garantire per tutta la durata del contratto la disponibilità dei dati raccolti ed elaborati. |
RPR_03 | Dati | Il fornitore, al termine del contratto, concorderà con i referenti di Lario Reti le modalità e la profondità storica dei dati da trasferire, qualora gli stessi non fossero già stati resi disponibili tramite apposita integrazione sui sistemi della mappa applicativa di Lario Reti. |
RPR_04 | Software | Il software realizzato dal fornitore nell’ambito del presente appalto (personalizzazioni, interfacce verso altri sistemi già esistenti, ecc.) unitamente alle versioni “sorgenti”, nel caso di applicazioni custom, ed a tutta la documentazione relativa, resterà di proprietà esclusiva di Lario Reti, che ne deterrà i diritti di sfruttamento commerciale. Parimenti saranno di proprietà di Lario Reti le metodologie, le tecniche nonché le scoperte relative all’elaborazione dei dati sviluppati nel corso della prestazione, ferma restando la proprietà intellettuale che rimarrà al realizzatore. |
RPR_05 | Software | Al termine del contratto, il fornitore dovrà consegnare a Lario Reti il codice "sorgente" e l’intera documentazione relativa al software sviluppato, e si impegnerà a non riprodurre, commercializzare o comunque cedere copia del prodotto a società o soggetti diversi senza la preventiva autorizzazione da parte del committente. |
RPR_06 | Software | Si precisa ulteriormente ed esplicitamente che le "procedure applicative" (eventuali sviluppi ad hoc e/o personalizzazioni software, interfacce, ecc.) comunque previste, dovranno essere realizzate e fornite secondo modalità che consentano al personale del Lario Reti un utilizzo autonomo (non dovranno, cioè, essere "compilate", né "crittografate", né rese in alcun modo illeggibili e/o non editabili) e dovranno essere corredate da esauriente documentazione. |
RSM_00 | Support & Maintenance | |
RSM_01 | Maintenance | Il fornitore deve descrivere il processo, la schedulazione adottata ed i tempi di downtime solitamente adottati per la maintenance della soluzione (quante major, minor release all'anno, tempistiche di rilascio di fix). |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RSM_02 | Supporto | Il fornitore deve dettagliare la loro capacità di fornire un supporto 24x7 . |
RSM_03 | Supporto | Il fornitore deve descrivere il loro modello di escalation per la gestione dei fault durante le fasi di delivery e post go- live. |
ART. 6 - DESCRIZIONE DELLE PRESTAZIONI RICHIESTE
Gli elementi che compongono le prestazioni richieste sono:
• Realizzazione dell’Enterprise Data Platform
• Gestione del Servizio di Manutenzione di Base
• Gestione del Servizio di Manutenzione Evolutiva
Nei paragrafi successivi si descrivono le modalità operative di dettaglio per l’esecuzione
delle attività di progetto.
ART. 7 - PROPOSTA DEL SOFTWARE E DISEGNO DELLA SOLUZIONE
Viene richiesto di fornire una soluzione completa (includendo le licenze di tutte le componenti necessarie applicative, infrastrutturali, Database), disponibile in cloud, con un modello di servizio di tipo SaaS, in grado di integrarsi sia con altre piattaforme in cloud sia con sistemi on premise di Lario Reti.
Il proponente dovrà fornire il disegno funzionale e tecnico di tutte le componenti della soluzione, così come richiesto nel capitolato tecnico e nella Lista Dei Requisiti DIGITAL_HUB.
ART. 8 - REALIZZAZIONE DEL PROGETTO DI IMPLEMENTAZIONE
Il progetto consiste nella realizzazione dell’Enterprise Data Platform di Lario Reti, basata su un modello di servizio di tipo ‘’SaaS’’, integrato con i sistemi della mappa applicativa di Lario Reti. Le principali fonti di integrazione richieste sono:
• CRM Salesforce
• Billing NetA2A
• NetA SIAL (in sostituzione nel corso del 2024 con Oracle Fusion ERP)
• Oracle Fusion ERP
• LIMS
• Infoworks
• Suite DHI
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
• OVARRO
• INFLOWMATIX
• RADAR
• FRACTA
• GIS
• TELECONTROLLO
• Consumi POD Edison (eventuali fogli excel/csv/txt)
• Dati Meteo ARPA Lombardia (eventuali fogli excel/csv/txt)
• Letture e consumi Contatori (eventuali fogli excel/csv/txt)
La lista completa delle fonti da integrare verrà fornita durante l’avvio e la fase di analisi del
progetto.
La figura sottostante rappresenta l’architettura logico/applicativa che dovrà essere realizzata; in particolare, l’Enterprise Data Platform dovrà prevedere un datalake di staging su cui convogliare le diverse fonti dati in formato nativo, il layer di aggregazione, gli eventuali datamarts necessari per l’alimentazione delle applicazioni quali DSS WMS, AI, Advanced Analytics (ad es. Qlik e PowerBI), altre applicazioni strategiche di Lario Reti; l’architettura proposta dovrà rispettare le caratteristiche indicate nell’allegato Lista Requisiti DIGITAL_HUB.
Letture e consumi contatori
Letture e consumi contatori
Dati ARPA
Letture e consumi contatori
Oracle Fusion oErp
Salesforce CRM
OVARRO
NETA2A
RADAR
INFLOWMATIX
Consumi POD Edison
e fonti esterne
Sistemi on cloud
Dashboard
Telecontrollo
Dashboard
Dashboard
LIMS
Analisi dell’acqua
Dashboard
GIS
Infowoks
Suite DHI
Sistemi on Prem
Sistemi on cloud
Altr
Enterprise Data Platform Datamarts
Figura 1 Mappa Applicativa di Lario Reti
FRACTA
Predictive Maintenance
DSS WMS
Enterprise Data Platform Datalake
Layer aggregazione Entità
Enterprise Data Platform Datalake
Area Staging acquisizione dati grezzi
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 9 - RISORSE E PIANIFICAZIONE
L’aggiudicatario dovrà mettere a disposizione un Project Manager (PM), con il profilo descritto nel presente Capitolato per tutta la durata del progetto, che si occuperà di:
• definire un organigramma delle risorse che parteciperanno al progetto, con la descrizione dei ruoli e delle responsabilità;
• supervisionare e coordinare il personale del team (analisti, architetti, sviluppatori, tester);
• definire e governare il piano delle attività di tutti gli attori coinvolti, sia interni al team di
progetto dell’aggiudicatario, che relativi a Lario Reti o degli altri fornitori coinvolti;
• garantire l’organizzazione, la qualità e l’efficienza delle attività di progetto.
Il PM avrà l’obbligo di partecipare a riunioni di avanzamento settimanali, nell’ambito del comitato cg, presso le sedi della stazione appaltante o in modalità remota. In occasione di tali incontri dovrà inoltre produrre una relazione scritta contenente lo stato di avanzamento delle attività di progetto, in cui si dovranno evidenziare le criticità emerse e le relative soluzioni individuate e l’aggiornamento del piano di realizzazione.
Si precisa che l’aggiudicatario dovrà rispettare tutti i requisiti di delivery espressi nel file Lista Dei Requisiti DIGITAL_HUB all’interno del foglio ‘’Delivery Contract Reqs’’, che riportiamo di seguito:
Tabella 6 Requisiti di Delivery
Requisiti | ||
ID Requisito | Area d'intervento | Descrizione |
RDEL_00 | Delivery | |
RDEL_01 | Project Delivery | È richiesto che tutta la fase di progettazione, sviluppo, creazione e rilascio del nuovo applicativo avvenga attraverso un susseguirsi di iterazioni. Per la fase di design viene richiesta un’attività di co-design delle UI insieme al gruppo responsabile del progetto del Lario Reti dove esplorare le necessità e opportunità della nuova soluzione. |
RDEL_02 | Project Delivery | Il fornitore deve descrivere la metodologia di Project Management che prevede di mettere in atto per la delivery della soluzione nel Lario Reti. |
RDEL_03 | Project Delivery | Il fornitore deve dettagliare la metodologia di risk ed issue management che adotterà. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RDEL_04 | Project Delivery | Il fornitore deve descrivere la metodologia di change management che adotterà relativamente ad eventuali modifiche dei requisiti e/o funzionalità che si dovessero manifestare durante la fase di implementazione. |
RDEL_05 | Project Delivery | Il fornitore deve indicare un project manager che possiede un'esperienza di almeno 5 anni in progetti analoghi per dimensioni e tecnologia utilizzata, nell’ambito utility (idrico, gas, elettrico), per il coordinamento della delivery, l'implementazione, il controllo del piano, le verifiche di qualità e tutte le attività necessarie sulla base della metodologia adottata e descritta nei requisiti precedenti. |
RDEL_06 | Project Delivery | Il fornitore deve descrivere ruoli, responsabilità di ogni membro del team e fornire il relativo CV. |
RDEL_07 | Project Delivery | Il fornitore deve fornire un piano di progetto con milestones e deliverable associati. |
RDEL_08 | Project Delivery | Il fornitore deve descrivere come la soluzione che verrà implementata si integra rispetto alla reference architecture del Lario Reti. |
RDEL_09 | Project Delivery | Il fornitore deve indicare eventuali dipendenze sulle milestone ed i deliverable derivanti da attività affidate a terze parti. |
RDEL_10 | Project Delivery | Il fornitore deve condividere il piano di progetto utilizzando tool standard ed effettuare dei SAL con cadenza settimanale. |
RDEL_11 | Project Delivery | Il report di SAL deve essere in un formato standard concordato con il referente del progetto del Lario Reti, deve includere almeno gli obiettivi raggiunti, i deliverable principali e le date in cui erano stati pianificati, eventuali slittamenti, issue. |
RDEL_12 | Project Delivery | Il fornitore deve descrivere il processo di sviluppo ed i deliverable principali. Tale processo deve includere almeno: tracciabilità dei requisiti, change control sulla documentazione prodotta, standard utilizzati per la documentazione, standard applicati per il coding, software di Change Control utilizzato, deliverable adottati per le fasi di analisi, detail design, testing (includendo la metodologia adottata), sistema di versioning e gestione delle release. |
RDEL_13 | Project Delivery | Il fornitore deve descrivere il proprio ambiente di sviluppo adottato e l'ambiente di test che verrà messo a disposizione per effettuare i collaudi prima del passaggio in produzione. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RDEL_14 | Project Delivery | Il fornitore deve mettere in evidenza le best practice adottate in progetti analoghi dal punto di vista tecnologico e di complessità. |
RDEL_15 | Project Delivery | Il fornitore deve descrivere il proprio sistema di gestione della qualità che deve essere tra gli standard riconosciuti a livello internazionale, includendo la documentazione rilevante. |
RDEL_16 | Project Delivery | Il fornitore deve produrre la certificazione del proprio standard di gestione della qualità adottato. |
RDEL_17 | Project Delivery | Il piano di qualità adottato dal fornitore deve essere referenziato all'interno del project plan del progetto. |
RDEL_18 | Project Delivery | Il fornitore deve adottare il piano di gestione della qualità durante tutte le fasi dello sviluppo, della delivery e della maintenance. |
RDEL_19 | Project Delivery | Il fornitore deve descrivere la natura delle eventuali relazioni commerciali con i partner inclusi nella soluzione. |
RDEL_20 | Project Delivery | Il fornitore deve essere completamente responsabile di tutti i deliverable prodotti da eventuali terze parti che sono stati inclusi come parte della soluzione (rispetto delle date di consegna, qualità, performance e SLA per la maintenance). |
RDEL_21 | Project Delivery | Il fornitore deve descrivere come sarà organizzato l'account team includendo anche i referenti delle terze parti nelle relazioni con il team di progetto e gli stakeholder del Lario Reti. |
RDEL_22 | Project Delivery | Il fornitore deve descrivere ruoli e responsabilità di ogni team member dei partner coinvolti nella soluzione e fornire i rispettivi CV. |
RDEL_23 | Project Delivery | Il fornitore deve fornire una roadmap dettagliata delle evoluzioni funzionali ed architetturali della soluzione proposta (inclusi i componenti forniti da terze parti). |
RDEL_24 | Service Flexibility and Time to Market | La soluzione deve essere flessibile per supportare lo sviluppo rapido di nuovi servizi ed applicazioni. Saranno preferite soluzioni che sono configurabili e che forniscono meccanismi di template/tabelle e meta dati/regole e wizard. |
RDEL_25 | Service Flexibility and Time to Market | La soluzione proposta deve essere configurabile: le regole di business ed i processi devono essere realizzati preferibilmente attraverso configurazioni. |
RDEL_26 | Service Flexibility and Time to Market | La soluzione deve essere pronta a recepire variazioni organizzative e deve reagire in tempo reale ad eventuali modifiche richieste dagli utenti. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
RDEL_27 | Service Flexibility and Time to Market | La soluzione deve fornire strumenti di sviluppo e configurazione semplici da utilizzare. |
RDEL_28 | Service Flexibility and Time to Market | La soluzione proposta deve essere facilmente adeguabile ad eventuali nuove normative, preferibilmente attraverso configurazioni. |
RTR_00 | Training | |
RTR_01 | Training | ARGOMENTI: Il training dovrà coprire i seguenti ambiti: |
-- funzionalità di business disponibili | ||
-- operation & administration (funzionalità di maintenance, analisi di errori/failure, tuning e ottimizzazioni, log, audit e monitoraggio, start & stop dei servizi, modalità di deployment) | ||
-- tools per creazione, progettazione nuove funzionalità tramite le API e/o wizard disponibili | ||
-- training per gli utenti finali (in aula e/o modalità Formazione a Distanza). | ||
Per ogni corso dovrà essere disponibile la documentazione correlata in lingua italiana e dovranno essere indicati gli skills necessari per il personale del Lario Reti | ||
RTR_02 | Training | LINGUA:Tutti i corsi, i manuali e la documentazione tecnica e funzionale dovranno essere in lingua Italiana |
RTR_03 | Training | EXTRA COSTI PER MATERIALE: Tutto il materiale per i corsi dovrà essere fornito a tutti i partecipanti senza ulteriori costi aggiuntivi. |
RTR_04 | Training | Tutto il materiale per i corsi dovrà essere adattato per riflettere quanto presente nel sistema deliverato per il Lario Reti. |
RTR_05 | Training | Il fornitore dovrà erogare i corsi nelle tempistiche presenti nel Project Plan ed in accordo alle disponibilità del personale del Lario Reti coinvolto. Il personale coinvolto nel training dovrà riuscire ad acquisire le abilità necessarie per effettuare tutti gli interventi (funzionali, sistemistici, gestionali) necessari per l'utilizzo ed il mantenimento della soluzione deliverata. Il fornitore dovrà descrivere quali modalità verranno adottate per assicurare quanto precedentemente richiesto. |
RTR_06 | Training | I corsi dovranno essere erogati preferibilmente presso le sedi Lario Reti o, in alternativa, tramite video conference utilizzando strumenti interattivi. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Di seguito si riporta una descrizione delle modalità di esecuzione delle fasi principali di progetto che l’aggiudicatario dovrà effettuare, in collaborazione con il personale della Direzione DIGITAL_HUB e dei Process Owner e Key User di Lario Reti:
ART. 10 - DEFINIZIONE E DISEGNO ARCHITETTURA APPLICATIVA/INTEGRAZIONI
L’aggiudicatario dovrà predisporre un documento che descriva l’architettura applicativa ed il dettaglio tecnico (data mapping, tecnologia di integrazione prevista) delle interfacce verso tutti gli applicativi coinvolti nell’attività d’integrazione
ART. 11 - ANALISI FUNZIONALE PER LA RACCOLTA DEI REQUISITI DI BUSINESS
La fase di raccolta dei requisiti tecnico/funzionali della nuova Enterprise Data Platform dovrà essere dall’aggiudicatario insieme all’IT di Lario Reti interviste e incontri con i process owner ed i key user.
Tutti i requisiti funzionali, che saranno implementati nella fase di sviluppo, dovranno essere riportati dall’aggiudicatario in un repository di progetto da tenere costantemente aggiornato e il cui formato sarà definito e condiviso con Lario Reti nelle fasi progettuali preliminari.
ART. 12 - CONFIGURAZIONE / SVILUPPO
L’aggiudicatario dovrà provvedere ad includere profili professionali in grado di occuparsi
di:
• disegno della nuova architettura applicativa
• disegno e configurazione dell’applicativo
• disegno e sviluppo di funzionalità non supportate out-of-the-box individuate durante la fase di analisi funzionale
• disegno e configurazione di tutte le interfacce richieste con gli applicativi sorgenti delle fonti dati.
L’aggiudicatario si occuperà anche di garantire l’integrazione con servizi terzi e di test di connettività simulata. L’aggiudicatario dovrà dimostrare, attraverso la descrizione di progetti analoghi sia per dimensioni che per complessità, di possedere l’esperienza necessaria per garantire la corretta implementazione del progetto in ogni sua parte.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 13 - SYSTEM, INTEGRETION E PERFORMANCE E TEST
Al termine di ogni ciclo di sviluppo è richiesto che l’aggiudicatario effettui una serie di test interni funzionali sulle nuove implementazioni (System Test), a valle dei quali, se non sono stati individuati bug bloccanti, verranno effettuati gli integration test con i sistemi esterni coinvolti.
Tutti i test dovranno prevedere la documentazione di supporto (Test book), predisposta dall’aggiudicatario e validata dall’IT di Lario Reti, che racchiuda tutti i test case necessari alla validazione delle funzionalità delineate, e che preveda il dettaglio delle attività di test di:
• Sistema (rispondenza del sistema ai requisiti individuati durante la fase di analisi)
• Integrazione del sistema (corretto funzionamento del dialogo con gli altri sistemi con cui sono previste interfacce)
I bug individuati dovranno essere tracciati attraverso una piattaforma di bug reporting, che verrà anch’essa concordata dall'aggiudicatario con l’IT di Lario Reti nelle fasi progettuali preliminari.
Performance test
Al termine degli integration test, l’aggiudicatario effettuerà un rilascio su un ambiente di Preproduzione/Collaudo, così da poter avviare i performance test. L’ambiente di Preproduzione dovrà essere analogo all’ambiente di Produzione sia in termini infrastrutturali che di volumi dei dati presenti.
Dovrà essere prevista dall’aggiudicatario una procedura per poter effettuare dei performance test / test di carico sul nuovo applicativo in modo da anticipare eventuali problematiche relative alle performance di calcolo dell’applicativo e di richieste verso i sistemi integrati di Lario Reti.
Tutti i dati del performance test dovranno essere reportizzati per poter essere valutati e poter eventualmente definire azioni successive.
ART. 14 - COLLAUDO
Durante questa fase, l’aggiudicatario, alla presenza dei process owner, dei key user e dell’IT di Lario Reti, dovrà svolgere tutti i test sulla soluzione al fine di consentire la validazione delle configurazioni e le personalizzazioni realizzate nella fase precedente,
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
secondo quanto espresso nei requisiti definiti in fase di analisi.
Il sistema rilasciato sarà valutato in tutte le sue parti, compresa la documentazione a corredo, verificandone la rispondenza, in termini di completezza e di correttezza di funzionamento, rispetto a quanto descritto nella documentazione tecnica (requisiti, specifiche funzionali, …) approvata dalla commissione ct e le prestazioni in termini di tempi di esecuzione. Tale attività coinvolgerà tutti i processi supportati dal sistema. Sarà valutata anche la completezza e la chiarezza di tutta la documentazione consegnata.
Laddove richiesto, gli operatori responsabili di Lario Reti potranno richiedere supporto on- site o da remoto all’aggiudicatario nello svolgimento di sessioni congiunte di collaudi (User Acceptance Test, UAT), con lo scopo di verificare funzionalità, integrazioni con servizi terzi ed individuare eventuali bug.
L’esecuzione del collaudo sarà effettuata dall’aggiudicatario, alla presenza dei process owner, dei key user e dell’IT di Lario Reti, utilizzando il documento di specifiche dei test redatto dall’aggiudicatario e precedentemente condiviso ed approvato dalla commissione ct.
Il ciclo di UAT dovrà essere eseguito al termine di ogni iterazione di sviluppo.
L’esito del collaudo potrà essere:
• Positivo:
il sistema è completo in tutte le sue parti, inclusa la documentazione, non sono presenti anomalie di funzionamento e i tempi di risposta sono adeguati; pertanto, la commissione ct redigerà un apposito Verbale di Accettazione e il sistema potrà passare alla fase successiva di avvio in esercizio.
• Positivo con riserva:
il sistema è completo in tutte le sue parti, inclusa la documentazione, i tempi di risposta sono adeguati e sono presenti solo errori (bugs) valutati dalla commissione ct come “non gravi” e “non pregiudicanti per la messa in esercizio”. La commissione ct redigerà un apposito Verbale di Accettazione in cui saranno elencate le suddette anomalie e il sistema potrà passare alla fase successiva di avvio in esercizio. L’aggiudicatario dovrà provvedere all’eliminazione di tutti i difetti riscontrati entro 10 giorni lavorativi dalla data di redazione del verbale di accettazione.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
• Negativo:
il sistema non è completo in tutte le sue parti, inclusa la documentazione, oppure i tempi di esecuzione non sono adeguati, oppure sono presenti errori (bugs) valutati dalla commissione ct come “gravi” e “pregiudicanti per la messa in esercizio”, pertanto il sistema non riceverà l’autorizzazione alla messa in esercizio. L’aggiudicatario dovrà correggere tutte le anomalie (discordanze rispetto alla documentazione tecnica, incompletezze, bugs, tempi di esecuzione non adeguati, ecc.) rilevate entro 10 giorni lavorativi dalla data di termine del collaudo. Successivamente dovrà avvenire un nuovo collaudo.
Prima del go-live, di ogni sviluppo, l’aggiudicatario dovrà prevedere un ciclo di test su tutto l’applicativo così da verificarne l'integrità completa.
ART. 15 - TRAINING
L’aggiudicatario dovrà garantire ed organizzare delle sessioni di training e formazione, supportate da relativa documentazione dettagliata (manuali utenti), per gli utenti di Business e per gli utenti IT di Lario Reti volte a creare le conoscenze e competenze sulla nuova applicazione.
Sarà compito dell’aggiudicatario predisporre e fornire delle sessioni di formazione (in aula o da remoto) con gli strumenti e il materiale necessario per istruire tutto il personale delle funzioni di Business coinvolte ed il personale IT interno di Lario Reti sulle modalità di utilizzo e gestione dell’applicativo sviluppato.
Il training dovrà garantire l’acquisizione degli skill necessari per tutti gli utilizzatori e gli
amministratori del sistema.
Tutta la documentazione dovrà essere redatta in lingua italiana.
L’aggiudicatario dovrà predisporre il training per tutti gli utilizzatori e gli amministratori del sistema prima del go live.
ART. 16 - MIGRAZIONE IN PRODUZIONE
La nuova applicazione potrà essere resa operativa unicamente se il relativo collaudo avrà avuto esito positivo o positivo con riserva.
A seguito della validazione avvenuta nella fase di collaudo (UAT), l’aggiudicatario dovrà provvedere alla migrazione in produzione delle configurazioni e delle personalizzazioni necessarie alla messa in esercizio dell’Enterprise Data Platform di Lario Reti.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 17 - GO-LIVE
La fase di go-live avverrà al termine con successo del collaudo descritto precedentemente.
ART. 18 - POST GO-LIVE
La fase di Post Go-Live inizierà al termine della fase di go-live. In questo periodo l’aggiudicatario dovrà assicurare la presenza, nelle sedi di Lario Reti o attraverso Microsoft Teams o altri tools di instant messaging e videoconferenza, di tutti gli analisti funzionali del team di progetto a supporto dell’attività degli utenti, e comunque, la disponibilità di tutto il team per la pronta risoluzione delle anomalie. Tale servizio si concretizza in un supporto strutturato con l’obiettivo di:
• fornire, ai dipendenti di Lario Reti e ai tecnici appartenenti all’IT, un valido affiancamento operativo nel consolidamento delle conoscenze acquisite nei corsi, nel contesto di esercizio del sistema;
• correggere prontamente eventuali difetti e anomalie di funzionamento del sistema;
• analizzare ulteriori parametrizzazioni di base non emerse nella fase di analisi per valutarne la realizzazione.
La chiusura della fase avverrà esclusivamente a seguito di emissione di verbale di accettazione da parte della commissione ct e comunque non prima dello scadere del periodo pari a 40 giorni lavorativi
Il servizio di Manutenzione sarà suddiviso nelle due seguenti modalità:
o Manutenzione di base
o Manutenzione evolutiva e servizi a consumo
Nello svolgimento del servizio l’aggiudicatario potrà accedere da remoto utilizzando l’accesso via VPN la piattaforma Microsoft Teams e avrà l’obbligo di registrare e gestire tutte le richieste d’intervento effettuate dagli utenti del sistema, per qualunque tipologia di manutenzione, attraverso l’uso dell’applicazione di Service Desk ManageEngine, le cui licenze saranno messe a disposizione dalla stazione appaltante.
Per quanto riguarda le riunioni di coordinamento o di gestione delle attività nell’ambito della manutenzione, queste potranno essere svolte sia da remoto, che in presenza nelle sedi di Lario Reti, sulla base delle esigenze del committente.
I seguenti paragrafi descrivono in modo dettagliato i servizi richiesti e le modalità di erogazione degli stessi.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 19 - GESTIONE DEL SERVIZIO DI MANUTENZIONE DI BASE
Al termine della fase di post Go-Live del progetto, il sistema sviluppato entrerà nella fase di
Manutenzione di Base, per un periodo di 24 mesi dalla data di avvio dei lavori.
Il servizio dovrà essere erogato per tutti i moduli applicativi in oggetto all’appalto e per tutti quelli che potrebbero essere avviati in esercizio nell’ambito delle attività di Manutenzione Evolutiva e Servizi a Consumo del presente contratto, sino alla conclusione del contratto stesso.
Per lo svolgimento del servizio l’appaltatore dovrà mettere a disposizione un team di
persone completamente dedicato ai servizi di Manutenzione di Base.
Tutte le richieste di assistenza saranno aperte direttamente dagli utenti del sistema attraverso la creazione di ticket nell’ambito dell’applicazione ManageEngine messa a disposizione dalla stazione appaltante. Nella fase di creazione dei ticket gli utenti definiranno la tipologia della richiesta (Incident, Richiesta estrazione dati, Richiesta configurazione nuovo accesso applicativo, etc.), il livello di Gravità (valido solo nei casi di Incident, descritto nella Tabella Gravità del disciplinare di gara) e di Priorità ( descritto nella Tabella Priorità del disciplinare di gara e valido solo nei casi di richieste di estrazione dati, configurazione del sistema o creazione di procedure di bonifica dei dati) della segnalazione. I ticket saranno assegnati automaticamente al gruppo di lavoro del fornitore. Come primo step il fornitore dovrà avviare la fase di analisi/revisione del ticket, consistente nello svolgimento delle seguenti attività:
o Assegnazione del ticket al tecnico mediante apposita funzione di ManageEngine. L’operazione di assegnazione al tecnico, la cui data ed ora saranno registrati sul programma di service desk, rappresenterà l’evento di “presa in carico” valutato nell’ambito del calcolo dello SLA contrattuale.
o Verifica della corretta tipologia del ticket e rettifica della stessa in caso di errore
commesso dall’utente.
o Verifica della correttezza del livello di Gravità e Priorità suggeriti dall’utente nel ticket e registrazione sul ticket dei valori effettivi di Gravità e Priorità ottenuti sulla base dell’analisi dei contenuti della segnalazione. Queste informazioni saranno utilizzate per la valutazione del rispetto degli SLA contrattuali.
Le suddette attività sono considerate essenziali dalla stazione appaltante per la corretta gestione dei servizi di manutenzione di base; pertanto, è prevista l’applicazione di una penale, descritta nel paragrafo “Penali relative alle attività svolte nell’ambito della
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
manutenzione di base”, nei casi in cui queste non vengano espletate in maniera
corretta e completa.
La stazione appaltante utilizzerà l’applicazione AMeter, di cui Lario Reti è proprietaria dei sorgenti, la quale è integrata con la piattaforma ManageEngine, come unico strumento per la verifica del rispetto degli SLA (Service Level Agreement), delle prestazioni del fornitore e dei KPI di qualità del servizio svolto nell’ambito della Manutenzione di Base. L’uso del programma AMeter sarà messo a disposizione dell’appaltatore gratuitamente e sarà utilizzato in tutte le riunioni di coordinamento.
Nello svolgimento del servizio l’aggiudicatario potrà accedere da remoto utilizzando l’accesso via VPN la piattaforma Microsoft Teams.
Per quanto riguarda le riunioni di coordinamento o di gestione delle attività nell’ambito della manutenzione, queste potranno essere svolte sia da remoto, che in presenza nelle sedi di Lario Reti, sulla base delle esigenze del committente.
Nel servizio di manutenzione base l’aggiudicatario dovrà mettere a disposizione almeno:
o N.1 Service Manager
o Supporto applicativo agli utenti
o Formazione del personale nell'uso dell'applicativo
o Configurazione del sistema
o Predisposizione di report ed estrazioni dei dati dal Data Base
o Manutenzione correttiva (Business Continuity)
o Manutenzione adeguativa
o Predisposizione procedure e script per la rettifica di dati errati su Data Base
o Monitoring applicativo
o Attività di consulenza a supporto del passaggio di consegne ad altro aggiudicatario al termine del contratto
Si riporta nei paragrafi seguenti il dettaglio di tutte le voci sopraelencate.
ART. 20 - SERVICE MANAGER
L’aggiudicatario dovrà mettere a disposizione una risorsa, per tutta la durata del contratto, dipendente e/o socio dell’azienda, con il ruolo di Service Manager.
Questa persona dovrà essere contattabile telefonicamente su telefono mobile.
Per tutte le attività che saranno svolte nell’ambito del contratto, si occuperà di:
• supervisione e coordinamento delle attività;
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
• pianificazione delle attività;
• garantire l’organizzazione, la qualità e l’efficienza del servizio svolto monitoraggio e validazione delle soluzioni tecniche implementate
Il Service Manager avrà l’obbligo di partecipare a riunioni di coordinamento con il Service
Manager IT e i Process Owner di Lario Reti, con le seguenti frequenze:
• Riunione settimanale: saranno analizzati i ticket in corso di lavorazione, valutate le eventuali criticità di gestione ed individuare le relative soluzioni.
• Riunione mensile: il Service Manager dovrà consegnare una relazione scritta (report per la qualità del servizio) contenente la descrizione del rispetto dei livelli di servizio (SLA degli Incident e delle Richieste di supporto applicativo, estrazione dati, configurazione del sistema, creazione di procedure per la bonifica dei dati) e l’andamento delle misure dei KPI di qualità, ottenuti dai report messi a disposizione dal programma AMeter.
I KPI di qualità del servizio saranno definiti in fase di avvio del contratto. La stazione appaltante si riserva la possibilità di revisionare tali KPI all’inizio di ogni anno, per tutta la durata del contratto.
ART. 21 - SUPPORTO APPLICATIVO AGLI UTENTI
Il servizio di supporto applicativo agli utenti ha come scopo di agevolare l’utente nell’utilizzo delle applicazioni. L’aggiudicatario dovrà utilizzare la piattaforma virtuale Microsoft Teams, con cui fornire supporto in video conferenza. Le attività previste saranno:
• supporto all’utente per il migliore utilizzo delle funzionalità applicative;
• supporto alle attività di amministrazione di sistema del personale IT;
• supporto al personale IT sull’utilizzo delle informazioni presenti sulla base dati.
L’appaltatore dovrà contattare l’utente e avviare l’attività di supporto in un tempo che soddisfi il rispetto del livello di servizio “tempo di presa in carico ed erogazione del servizio di supporto applicativo” descritto nel disciplinare di Gara, al paragrafo “Criteri di valutazione dell’offerta tecnica”, il cui valore sarà definito puntualmente nella documentazione tecnica presentata dall’aggiudicatario nell’ambito dell’offerta.
ART. 22 - FORMAZIONE DEL PERSONALE NELL’USO DELLE APPLICAZIONI
Questo servizio sarà erogato sulla base delle necessità che emergeranno volta per volta, e
prevede l’organizzazione e la gestione di corsi di formazione sull’utilizzo del sistema per il
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
personale di Lario Reti. L’appaltatore dovrà mettere a disposizione 12 giornate lavorative
all’anno per lo svolgimento di questo servizio.
Le date saranno concordate con il personale IT. Ogni prestazione dovrà essere erogata entro 5 giorni lavorativi dalla data d’invio della mail di formalizzazione della richiesta da parte della società Appaltante.
Per ogni argomento trattato i corsi dovranno includere:
• consegna di manuali e documenti didattici;
• spiegazione degli aspetti teorici e svolgimento di esercizi pratici.
I docenti dovranno conoscere, oltre le funzioni del sistema, i processi e le procedure organizzative adottate dalla stazione appaltante a supporto dell’utilizzo di tali funzioni.
La formazione potrà essere erogata in aule fisiche o virtuali messe a disposizione della stazione appaltante, la quale sceglierà in base alle proprie esigenze il contenuto, la modalità e la durata dei corsi di formazione.
ART. 23 - CONFIGURAZIONE DEL SISTEMA
Questo servizio dovrà includere le attività di configurazione dei parametri dei moduli applicativi inclusi nell’appalto, a cui vanno aggiunti anche quelli che andranno in produzione dopo l’avvio del contratto nell’ambito della manutenzione evolutiva, compresi:
• Software relativo alle personalizzazioni dei moduli;
• Software relativo alle interfacce di comunicazione e scambio dati verso altri sistemi aziendali;
• Report ed oggetti di business intelligence;
necessarie per correggere i malfunzionamenti, risolvere eventuali problemi di violazione della sicurezza dei dati e dei sistemi, ottimizzare le prestazioni del sistema, a cui si aggiungono:
• Creazione/modifica dei work-flow autorizzativi;
• Creazione/modifica/chiusura dei profili utente. Per queste richieste sarà necessaria una verifica preliminare della disponibilità delle licenze. Il fornitore dovrà interagire con l’interfaccia messa a disposizione dal sistema Ameter, per verificare la disponibilità e registrare puntualmente il decremento della disponibilità (per nuovo accesso) oppure l’incremento della disponibilità (per chiusura accesso).
• Reset password;
• Configurazione password policies;
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
• Modifica delle configurazioni necessarie al corretto funzionamento del sistema in relazione a revisioni organizzative della struttura delle Sedi/Direzioni/Uffici, della stazione appaltante;
Terminate le attività di configurazione richieste, l’aggiudicatario dovrà aggiornare tutta la
documentazione disponibile relativa alle configurazioni del sistema.
Il livello di priorità dei ticket sarà definito dagli utenti all’atto della richiesta d’intervento. La ditta appaltatrice dovrà effettuare la presa in carico e interagire con il personale IT per concordare un eventuale livello di priorità differente da assegnare alla richiesta.
Una volta definito il livello di priorità, l’intervento dovrà essere svolto nel rispetto dei livelli di servizio descritti nel disciplinare di Gara, al paragrafo “Criteri di valutazione dell’offerta tecnica”, nella Tabella SLA priorità, per i quali i tempi di presa in carico e di risoluzione saranno definiti puntualmente nella documentazione tecnica presentata dall’aggiudicatario nell’ambito dell’offerta.
Nei casi di richieste di creazione/modifica di profili utente, sarà necessaria una verifica preliminare della disponibilità delle licenze. Il fornitore dovrà interagire con l’interfaccia messa a disposizione dal sistema Ameter, per verificare la disponibilità e registrare puntualmente la richiesta di decremento delle disponibilità (per nuovo accesso) oppure l’incremento della disponibilità (per chiusura accesso).
ART. 24 - PREDISPOSIZIONE DI REPORT ED ESTRAZIONI DEI DATI DAL DATA BASE
Questo servizio sarà erogato sulla base delle necessità che emergeranno volta per volta, e prevede la creazione/modifica di report e query per estrarre i dati presenti sui database di qualunque istanza del sistema, su file in formato Microsoft Excel.
Il livello di priorità dei ticket sarà definito dagli utenti all’atto della richiesta d’intervento. La ditta appaltatrice dovrà effettuare la presa in carico e interagire con il personale IT per concordare un eventuale livello di priorità differente da assegnare alla richiesta.
Una volta definito il livello di priorità, l’intervento dovrà essere svolto nel rispetto dei livelli di servizio descritti nel disciplinare di Gara, al paragrafo “Criteri di valutazione dell’offerta tecnica”, nella Tabella SLA priorità, per i quali i tempi di presa in carico e di risoluzione saranno definiti puntualmente nella documentazione tecnica presentata dall’aggiudicatario nell’ambito dell’offerta.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 25 - MANUTENZIONE CORRETTIVA (Business Continuity)
La manutenzione correttiva comprende tutte le attività necessarie a garantire il ripristino delle condizioni di sicurezza dei dati e delle applicazioni, o della operatività continua dei sistemi, a seguito di eventi che implicano:
• un pericolo già in essere, o un potenziale pericolo, di violazione della sicurezza dei dati e delle applicazioni;
• il degrado o l’interruzione del funzionamento del servizio;
attraverso la diagnosi e la rimozione delle cause e degli effetti di malfunzionamenti, parziali o totali, per tutti i moduli applicativi (errori logici e tecnico/funzionali).
Il servizio riguarderà:
• tutti i moduli applicativi inclusi nel contratto;
• le personalizzazioni degli stessi;
• moduli software d’interfaccia e di comunicazione per lo scambio dei dati verso altri
sistemi aziendali;
• report ed oggetti di business intelligence.
Il livello di degrado e la relativa gravità degli interventi (Livello di Gravità) saranno definiti dagli utenti all’atto della richiesta d’intervento. La ditta appaltatrice, a valle della notifica dell’anomalia, dovrà avviare le attività di presa in carico e risoluzione del malfunzionamento e interagire con il personale IT per discutere dei dettagli tecnici ed eventualmente per concordare un diverso livello di gravità.
Una volta definito il livello di gravità, l’intervento dovrà essere svolto nel rispetto dei livelli di servizio descritti nel disciplinare di Gara, al paragrafo “Criteri di valutazione dell’offerta tecnica”, nella Tabella SLA gravità, per i quali i tempi di presa in carico e di risoluzione saranno definiti puntualmente nella documentazione tecnica presentata dall’aggiudicatario nell’ambito dell’offerta.
Le attività di manutenzione correttiva dovranno garantire la non regressione del codice, ovvero l’introduzione di nuovi difetti (bugs) del software (a livello generale del prodotto) dovuti alle modifiche effettuate per la realizzazione della patch o per la rimozione di un malfunzionamento.
Il prodotto dovrà quindi comportarsi secondo quanto descritto nella documentazione tecnico/funzionale del sistema.
Le patch ed i service pack dovranno documentare, oltre al contenuto della correzione e/o evoluzione, le variazioni sulla documentazione di sistema sia sul piano infrastrutturale sia su quello applicativo, ove tali variazioni sussistano.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 26 - MANUTENZIONE ADEGUATIVA
L’aggiudicatario dovrà impegnarsi a fornire, senza costi aggiuntivi, le modifiche al software che si rendessero necessarie per adempiere a variazioni normative (nazionali e/o comunitarie) attraverso attività di sviluppo, parametrizzazione o configurazione o attraverso il rilascio di patch software. Tali adeguamenti dovranno essere programmati, realizzati e collaudati in modo che siano installati in esercizio entro le scadenze previste dalla norma. Gli aggiornamenti e le patch dovranno essere applicabili in forma di procedura automatica o semiautomatica. La ditta appaltatrice renderà contestualmente disponibile tutta la documentazione relativa, riportante le caratteristiche degli aggiornamenti e delle patch nonché le modalità operative di loro applicazione.
ART. 27 - PREDISPOSIZIONE PROCEDURE E SCRIPT PER LA RETTIFICA DI DATI ERRATI SU DATABASE
Questo servizio sarà erogato sulla base delle necessità che emergeranno volta per volta, e prevede la creazione/modifica di procedure per aggiornare dati presenti sui database, a scopo di rettifica di errori generati nell’ambito delle applicazioni, o delle interfacce di comunicazione, su qualunque istanza del sistema (produzione, pre-produzione, test e sviluppo).
Tali attività saranno espressamente richieste e supervisionate dal personale IT che, al momento della richiesta, segnalerà il livello di priorità.
Una volta definito il livello di priorità, l’intervento dovrà essere svolto nel rispetto dei livelli di servizio descritti nel disciplinare di Gara, al paragrafo “Criteri di valutazione dell’offerta tecnica”, nella Tabella SLA priorità, per i quali i tempi di presa in carico e di risoluzione saranno definiti puntualmente nella documentazione tecnica presentata dall’aggiudicatario nell’ambito dell’offerta.
ART. 28 - MONITORING APPLICATIVO
Il servizio di monitoring applicativo ha l’obiettivo di verificare il corretto funzionamento di:
• tutti i moduli applicativi inclusi nel contratto;
• Interfacce standard dei moduli applicativi inclusi nel contratto;
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
• Interfacce verso altre applicazioni esterne;
Nuove interfacce/procedure che saranno realizzate nell’ambito del servizio di
Manutenzione Evolutiva e Servizi a Consumo.
L’aggiudicatario dovrà implementare, in accordo con il personale IT, un sistema di
monitoraggio giornaliero di:
• parametri di funzionamento
• log del sistema
• corretto esito dei job di sistema
• corretto funzionamento delle interfacce verso altri sistemi
Una volta individuati malfunzionamenti, questi dovranno essere gestiti nell’ambito dei servizi di “Manutenzione correttiva” o di “Predisposizione procedure e script per la rettifica di dati errati su Database”, con l’obiettivo di ripristinare al più presto il corretto funzionamento delle applicazioni e le transazioni di scambio dati tra le applicazioni non andate a buon fine. La definizione dettagliata delle modalità di erogazione di questa attività sarà concordata in fase di avvio del servizio.
Inoltre, l’aggiudicatario dovrà produrre un report mensile che evidenzi il numero di licenze
effettivamente in uso rispetto a quelle disponibili.
ART. 29 - ATTIVITA’ DI CONSULENZA A SUPPORTO DEL PASSAGGIO DI CONSEGNE AD
ALTRO AGGIUDICATARIO AL TERMINE DEL CONTRATTO
Al termine del contratto, l’aggiudicatario dovrà fornire 40 giornate di consulenza a supporto delle attività di passaggio di consegne e di acquisizione delle competenze sul sistema, da parte del nuovo aggiudicatario del servizio. Questa attività dovrà essere obbligatoriamente effettuata dal personale appartenente al Team che ha gestito il servizio nel corso del contratto e che ha maturato la maggior esperienza e conoscenza del sistema. Il costo della suddetta attività sarà completamente a carico dell’aggiudicatario.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 30 - GESTIONE DEL SERVIZIO DI MANUTENZIONE EVOLUTIVA E SERVIZI A CONSUMO
Lario Reti si riserva, per l’intera durata del contratto, la possibilità di comunicare
all’aggiudicatario la necessità di:
• aggiungere nuove funzioni al sistema e/o effettuare variazioni di funzioni già esistenti rispetto a:
o configurazioni dell’applicativo oggetto del bando
o personalizzazioni dell’applicativo oggetto del bando
o procedure software per l’integrazione della soluzione proposta con altri
sistemi aziendali
o implementazione di nuove aree di analisi, datamart
o consulenze tecniche per l’integrazione di nuove soluzioni applicative quali
ad esempio DSS WMS, AI, Predictive Maintenance
o ruoli e autorizzazioni
o integrazioni di nuove fonti dati
o attività su richiesta, con preavviso di 24 ore dalla data di inizio del servizio, di supporto, monitoraggio e risoluzione di problematiche legate all’esecuzione del motore di calcolo da effettuarsi in fascia oraria notturna, sabato o festivi (il turno di 8 ore sarà consuntivato come 1,5 FTE)
Il servizio include un pacchetto di 550 giornate lavorative da effettuarsi con le figure professionali descritte nel presente Capitolato.
La manutenzione evolutiva non include tutte le tipologie di attività descritte nell’ambito del
servizio della Manutenzione di Base.
Il processo per la gestione di tutte le richieste di Manutenzione evolutiva e servizi a consu- mo dovrà seguire le seguenti macro-fasi:
1. Analisi ed Accettazione dei Documenti funzionali e tecnici
2. Emissione ed accettazione del preventivo per il rilascio della nuova richiesta
3. Realizzazione e Test
4. Collaudo e predisposizione Test Book
5. Avvio in esercizio
6. Post Go-Live
Si riporta di seguito il dettaglio delle macro-fasi:
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
1. Analisi ed Accettazione dei Documenti Funzionali e Tecnici
L’aggiudicatario dovrà effettuare l’analisi di dettaglio dei requisiti della attività evolutiva da implementare. Nell’ambito dell’analisi dovrà valutare gli impatti della stessa riguardo ai seguenti aspetti:
• costruzione ed evoluzione dell’Enterprise Data Platform
• sviluppo dell’integrazione della soluzione con altri applicativi/fonti dati;
Al termine di questa fase dovrà produrre la relativa documentazione funzionale e tecnica. La commissione cti valuterà la documentazione prodotta e la qualità delle soluzioni tecniche proposte. Qualora la suddetta commissione ritenesse le soluzioni tecniche proposte dall’aggiudicatario non adeguate, la commissione cti non darà l’approvazione e l’aggiudicatario dovrà sottoporre una nuova soluzione funzionale e tecnica e/o una nuova revisione della documentazione che recepiscano le indicazioni della commissione cti. In caso di approvazione la commissione cti emetterà un apposito Verbale di Accettazione.
2. Emissione e Accettazione del Preventivo
Una volta approvati i documenti, l’aggiudicatario dovrà produrre e sottoporre all’approvazione della commissione cti, un preventivo scritto contenente l’elenco delle prestazioni e il piano di progetto necessari alla realizzazione della modifica evolutiva richiesta e descritta nei documenti.
Qualora l’attività evolutiva riguardi l’avvio in esercizio di nuovi software non inclusi nel presente capitolato, l’aggiudicatario potrà inserire nel preventivo una quota parte di giornate (non superiore al 10% del costo di realizzazione dell’attività) corrispondenti all’erogazione di tutti i servizi previsti nella Manutenzione di Base, nel periodo dall’avvio in esercizio sino allo scadere del contratto.
Il preventivo sarà considerato in modalità “chiavi in mano”, dopo l’approvazione da parte della stazione appaltante, non potrà più essere modificato, ad eccezione dei casi in cui la stazione appaltante ne richieda una revisione per aggiungere nuove prestazioni.
Per quanto riguarda il preventivo, per ogni prestazione dovranno essere elencare le figure professionali coinvolte, e per ognuna di esse, il corrispondente numero di giorni/uomo necessari per compiere le attività da svolgere.
Per quanto riguarda il piano delle attività, dovranno essere descritte le milestone di progetto, le relative date di inizio e fine attività e i nominativi delle persone coinvolte, in coerenza con quanto affermato nel documento di preventivo.
La stazione appaltante valuterà la congruenza dei preventivi rispetto alla mole di attività richiesta per lo sviluppo della modifica. Tale valutazione sarà svolta dalla commissione cti.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Nel caso in cui il preventivo non venga ritenuto adeguato con le attività da svolgere, il preventivo non sarà approvato e l’aggiudicatario verrà invitato a presentare un nuovo preventivo che verrà sottoposto alla verifica di cui sopra. In caso di esito nuovamente negativo e qualora l’aggiudicatario, per il preventivo in esame, non si adegui alle condizioni poste dalla stazione appaltante, quest’ultima potrà avvalersi della risoluzione del contratto ai sensi dell’art. 1467 del C.C. per eccessiva onerosità dello stesso.
3. Realizzazione e Test
La fase realizzativa potrà essere avviata solo a fronte dell’approvazione scritta, da parte
della commissione cti, del preventivo.
In questa fase l’aggiudicatario svilupperà tutto il software necessario, svolgendo inoltre le seguenti attività:
• creazione della nuova documentazione e/o revisione di tutta la documentazione già esistente del sistema;
• formazione agli utenti di Lario Reti (formazione in aula e training on the job) sull’utilizzo
delle modifiche o nuove funzioni introdotte;
• formazione ai tecnici appartenenti al personale IT per le attività di amministrazione del sistema.
Tutto il software e i report in questa fase dovranno essere oggetto di test da parte dell’aggiudicatario in modo da eliminare vizi ed anomalie prima di essere messi a disposizione del personale del Lario Reti per l’effettuazione del test utente necessario al collaudo del sistema.
Qualora la stazione appaltante ritenesse necessario effettuare la supervisione delle fasi di test del software prima dei rilasci in ambiente di collaudo, l’aggiudicatario, a fronte di una richiesta scritta, avrà l’obbligo di eseguire i test del software “on site”, presso le sedi di Lario Reti.
4. Collaudo
L’aggiudicatario, alla presenza dei process owner, dei key user e dell’IT di Lario Reti, dovrà eseguire il collaudo del sistema. A tal fine, l’aggiudicatario dovrà mettere a disposizione una nuova installazione completa dell’intero sistema sull’ambiente dedicato al test, da utilizzare appositamente per il collaudo.
Il sistema rilasciato sarà valutato in tutte le sue parti, compresa la documentazione a corredo, verificandone la rispondenza, in termini di completezza e di correttezza di funzionamento, rispetto a quanto descritto nella documentazione tecnica (requisiti, specifiche funzionali, …) approvata dalla commissione cti e le prestazioni in termini di tempi
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
di esecuzione. Tale attività coinvolgerà tutti i processi supportati dal sistema nonché le singole funzionalità di tutti i moduli applicativi, quali:
• funzioni standard e personalizzazioni;
• funzioni d’integrazione del pacchetto con gli altri sistemi;
• report e dashboard.
Sarà valutata anche la completezza e la chiarezza di tutta la documentazione consegnata.
L’esecuzione dei test sarà effettuata dal personale dell’aggiudicatario, alla presenza del personale di Lario Reti, utilizzando il documento di specifiche dei test redatto dallo stesso e approvato dalla commissione cti.
L’esito del collaudo potrà essere:
• Positivo:
il sistema è completo in tutte le sue parti, inclusa la documentazione, non sono presenti anomalie di funzionamento e i tempi di risposta sono adeguati, pertanto la commissione cti redigerà un apposito Verbale di Accettazione e il sistema potrà passare alla fase successiva di avvio in esercizio.
• Positivo con riserva:
il sistema è completo in tutte le sue parti, inclusa la documentazione, i tempi di risposta sono adeguati e sono presenti solo errori (bugs) valutati dalla commissione cti come “non gravi” e “non pregiudicanti per la messa in esercizio”. La commissione cti redigerà un apposito Verbale di Accettazione in cui saranno elencate le suddette anomalie e il sistema potrà passare alla fase successiva di avvio in esercizio. L’aggiudicatario dovrà provvedere all’eliminazione di tutti i difetti riscontrati entro 10 giorni lavorativi dalla data di redazione del verbale di accettazione.
• Negativo:
il sistema non è completo in tutte le sue parti, inclusa la documentazione, oppure i tem-pi di esecuzione non sono adeguati, oppure sono presenti errori (bugs) valutati dalla commissione cti come “gravi” e “pregiudicanti per la messa in esercizio”, pertanto il sistema non riceverà l’autorizzazione alla messa in esercizio. L’aggiudicatario dovrà correggere tutte le anomalie (discordanze rispetto la documentazione tecnica, incompletezze, bugs, tempi di esecuzione non adeguati, ecc) rilevate entro 10 giorni lavorativi dalla data di termine del collaudo. Successivamente dovrà avvenire un nuovo collaudo.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
5. Avvio in Esercizio
Il sistema dovrà essere reso operativo unicamente se il relativo collaudo ha avuto esito positivo o positivo con riserva. Prima di effettuare il rilascio, l’aggiudicatario dovrà organizzare ed erogare i corsi di formazione al personale di Lario Reti, riguardanti le modi- fiche apportate al sistema nella nuova release che sarà rilasciata in esercizio.
Inoltre, è richiesto all’aggiudicatario di utilizzare procedure e strumenti di continuous integration (ad esempio Git, Xxxxxxx, Bitbuket, etc.), per garantire l’automatizzazione del processo di versionamento del codice e il deploy.
6. Post Go-Live
La stazione appaltante si riserva di valutare volta per volta se richiedere il periodo di post Go-Live per i rilasci riguardanti la manutenzione evolutiva e servizi a consumo, la cui durata potrà variare sulla base dei contenuti del rilascio e sarà in ogni caso concordata in fase di realizzazione del preventivo.
Durante tale periodo, l’aggiudicatario dovrà assicurare la presenza nelle sedi di Lario Reti di tutti gli analisti funzionali del team di progetto a supporto dell’attività degli utenti, e comunque, la disponibilità di tutto il team per la pronta risoluzione delle anomalie. Tale servizio si concretizza in un supporto strutturato con l’obiettivo di:
• fornire, agli utenti di Lario Reti e ai tecnici appartenenti al personale IT, un valido affiancamento operativo nel consolidamento delle conoscenze acquisite nei corsi, nel contesto di esercizio del sistema;
• correggere prontamente eventuali difetti e anomalie di funzionamento del sistema;
• analizzare e dare seguito alla realizzazione di ulteriori parametrizzazioni di base non emerse nelle fasi di analisi e disegno.
La chiusura della fase avverrà esclusivamente a seguito di emissione di verbale di accettazione del collaudo da parte della commissione cti e comunque non prima dello scadere del periodo concordato.
Tutte le fasi descritte in precedenza dovranno essere tracciate sull’applicazione di Service Desk “ManageEngine”.
ART. 31 - UTILIZZO DEL SOFTWARE GESTIONALE DI LARIO RETI HOLDING PER LA MANUTENZIONE DI BASE ED EVOLUTIVA
L’aggiudicatario sarà tenuto ad utilizzare il sistema in produzione presso il Lario Reti per tutta
la gestione della manutenzione di Base e la manutenzione Evolutiva.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Il sistema in uso è totalmente ITIL compliant e si basa sul presupposto della tracciabilità della richiesta da parte del business/IT e dei fornitori coinvolti.
Tutte le richieste, categorizzate in incident, correzione dati, change request o evolutive, vengono inserite tramite il sistema e smistate tramite l’ufficio Service desk della Direzione Digital_HUB di Lario Reti.
L’aggiudicatario verrà quindi abilitato, per tutto il personale necessario, all’accesso all’applicativo sia per la gestione che per il monitoraggio delle richieste.
L’applicativo in uso è ManageEngine.
ART. 32 - VINCOLI GENERALI DEL SERVIZIO
Il servizio dovrà essere erogato nel rispetto dei seguenti vincoli generali:
• Il servizio dovrà essere svolto integralmente sotto la supervisione del personale della Direzione DIGITAL_HUB di Lario Reti, il cui ufficio è nella sede di Lario Reti, sita in Xxx xxxxx Xxxxxxx, 00, Xxxxx.
• Le informazioni tecniche contenute nel presente CSA e negli Allegati, costituiscono una descrizione generale delle principali funzionalità dei sistemi oggetto di appalto e del progetto di implementazione del sistema. L’aggiudicatario avrà l’obbligo di erogare i servizi contenuti nel presente capitolato per tutte le funzioni presenti:
o nei sistemi oggetto dell’appalto;
o nel software relativo alle personalizzazioni dei suddetti sistemi e moduli;
o nel software relativo alle interfacce di comunicazione e scambio dati verso altri sistemi aziendali;
o nelle procedure software per la creazione dei layer applicativi e dei Datamarts;
o nei report ed oggetti di business intelligence;
anche se tali funzioni risultassero difformi o non esplicitamente descritte nei suddetti documenti.
• tutte le prestazioni da realizzare nell’ambito del contratto dovranno essere svolte nel rispetto delle regole, delle specifiche tecniche e dei livelli di servizio descritti nel presente capitolato
• I ruoli di Service Manager, per la gestione e l’organizzazione delle attività svolte nei
servizi di Manutenzione di Base, e di Project Manager, per la gestione e
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
l’organizzazione delle attività svolte nei servizi di Manutenzione Evolutiva, dovranno essere ricoperti da due persone distinte, per tutta la durata del contratto.
• L’erogazione dei servizi dovrà avvenire nelle giornate dal lunedì al venerdì, escluse le festività, nella fascia oraria dalle ore 8 alle ore 17; ad eccezione delle attività che compromettono o interrompono il corretto funzionamento dei sistemi in ambiente di Produzione, le quali dovranno essere effettuate dopo le ore 19 oppure durante i Sabati e le Domeniche.
• Nello svolgimento del servizio l’aggiudicatario avrà l’obbligo di registrare e gestire tutte le richieste d’intervento effettuate dagli utenti del sistema, per qualunque tipologia di manutenzione, attraverso l’uso dell’applicazione di Service Desk Manage Engine, le cui licenze saranno messe a disposizione dalla stazione appaltante. Si specifica che non sarà ammesso l’utilizzo di nessun altro software.
• La stazione appaltante utilizzerà l’applicazione AMeter, di cui Lario Reti è proprietaria dei sorgenti, che è integrata con la piattaforma ManageEngine, come unico strumento per la verifica del rispetto degli SLA (Service Level Agreement), delle prestazioni del fornitore e dei KPI di qualità del servizio svolto nell’ambito della Manutenzione di Base. Si specifica che non sarà ammesso l’utilizzo di nessun altro software.
• Ogni anno verrà richiesto il piano ferie delle persone dei Team. Questi dovranno essere consegnati entro il 30/06 per le ferie estive, ed entro il 30/11 per quelle di fine anno. I piani saranno analizzati dai Service Manager e dai Project Manager IT per verificare la congruenza tra i dati del piano e la reale copertura del servizio. I piani saranno approvati dai Service Manager IT e dai Project Manager IT solo se ritenuti idonei.
• Al fine di recepire nella gestione del servizio di AM applicativo, le best practice di cybersecurity, sono definite le seguenti procedure:
o Gestione delle password: in tutti i casi in cui nell’ambito del servizio sarà necessario comunicare delle credenziali di accesso ad un utente finale, queste dovranno essere consegnate all’assegnatario in maniera sicura, ossia fornendo nome utente e password in due modalità o momenti diversi.
In particolare, sarà necessario seguire puntualmente le seguenti indicazioni:
o Lo username dovrà essere sempre inviato via e-mail tramite le funzioni di ManageEngine.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
o La password:
▪ Non dovrà mai essere comunicata tramite le funzioni di ManageEngine
▪ Se nel ticket di richiesta è presente il numero di cellulare aziendale della persona da abilitare, la password dovrà essere comunicata via sms a tale numero.
▪ Altrimenti, qualora il numero di cellulare aziendale non fosse disponibile, dovrà essere inviata con una e-mail dedicata contenente solo la password.
o Creazione di account nelle applicazioni e/o VPN per il personale dei Team: in tutti i casi in cui sarà necessaria la creazione di account sui sistemi oggetto dell’appalto o accessi via VPN, per il personale dei Team del fornitore, sia per la gestione del Progetto sia per la gestione delle attività di manutenzione di base ed evolutiva, Il fornitore dovrà seguire la seguente procedura:
▪ Il fornitore invia una mail di richiesta degli accessi al Project Manager (nei casi del Progetto o della Manutenzione Evolutiva) o al Service Manager (in caso di Manutenzione di Base), con allegato un template in excel, che sarà fornito ad avvio del servizio, compilato in tutte le sue parti con le informazioni richieste.
▪ Il Service Manager/Project Manager, verificherà la congruenza della richiesta rispetto al servizio svolto dal personale e, se congruente, invierà una mail al fornitore con l’autorizzazione alla creazione degli account e le credenziali di accesso alla VPN.
• Per tutte le comunicazioni, i contenuti di tutti i documenti e le riunioni si utilizzerà esclusivamente la lingua italiana.
• Ogni attività di modifica degli Applicativi oggetto del servizio, sia di tipo adeguativo che evolutivo, dovrà essere preventivamente autorizzata per iscritto mediante mail dal personale della Direzione Digital_HUB di Lario Reti, per gli aspetti riguardanti:
o priorità di realizzazione
o pianificazione dell’intervento
o convalida delle analisi dei requisiti, funzionale, tecnica e architetturale
o convalida alla pubblicazione della modifica nell’ambiente di Esercizio
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
• Ogni attività di modifica degli Applicativi oggetto del servizio di tipo correttivo, dovrà essere preventivamente autorizzata per iscritto mediante mail dal personale della Direzione DIGITAL_HUB di Lario Reti, per gli aspetti riguardanti:
o priorità di realizzazione, qualora ci fossero più punti aperti con lo stesso livello di gravità, nel rispetto dei livelli di servizio
o convalida alla pubblicazione della modifica nell’ambiente di Esercizio
• Il personale della Direzione Digital_HUB di Lario Reti potrà effettuare degli Audit senza preavviso di tutti i sorgenti software oggetto del servizio, al fine di verificare il rispetto della qualità e degli standard aziendali.
• Tutti i componenti del Team dovranno possedere, oltre ad un’ottima conoscenza parlata e scritta della lingua italiana, un profilo professionale tra quelli descritti in Tabella 7.
• È previsto un periodo di prova del personale appartenente ai due team (team dedicato alla Manutenzione di Base e team dedicato alla Manutenzione Evolutiva), della durata di due mesi a partire dalla data di avvio dei relativi servizi. Durante questo periodo la stazione appaltante potrà effettuare dei colloqui individuali conoscitivi a tutti i membri dei team. Al termine del periodo di prova la commissione ct si riserva di dare conferma del personale selezionato per i due team. In caso contrario l’azienda dovrà garantire, entro 10 giorni lavorativi, la sostituzione delle risorse non ritenute idonee con altre aventi il medesimo profilo professionale, esperienza e certificazioni. Qualora anche le ulteriori risorse proposte non fossero ritenute idonee, come esito di ulteriori colloqui individuali conoscitivi, sulla base di motivata argomentazione, la stazione appaltante potrà procedere alla risoluzione del contratto.
• I componenti dei team dovranno restare in staff per tutta la durata del contratto. In caso di cessazione di rapporto o indisponibilità l’azienda dovrà garantire la sostituzione della risorsa con una avente la medesima figura professionale, analoga esperienza, ed in possesso dei medesimi attestati di certificazione.
ART. 33 - PROFILI PROFESSIONALI RICHIESTI
Il seguente paragrafo ha l’obbiettivo di indicare la tipologia di figure richieste e la relativa
esperienza necessaria per l’espletamento delle attività oggetto del capitolato.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
L'aggiudicatario, per la realizzazione dell’oggetto contrattuale dovrà mettere a disposizione un adeguato gruppo di lavoro, composto unicamente da figure professionali aventi i seguenti profili minimi, previsti dai documenti di richiesta d’offerta e qui riportati per completezza:
• Esperienza lavorativa almeno quinquennale nell’ambito delle attività previste dall’oggetto contrattuale, documentata dalla descrizione dei progetti svolti, del ruolo e della durata di ricopertura di quest’ultimo
• Esperienza lavorativa almeno quinquennale sulla soluzione applicativa proposta per lo sviluppo, documentata dalla descrizione dei progetti svolti, del ruolo e della durata di ricopertura di quest’ultimo
• Certificazioni sull’applicativo proposto relative all’attività in cui la figura
professionale sarà coinvolta:
o Certificazioni architect;
o Certificazioni consultant;
o Certificazioni developer;
o Eventuali Certificazioni sistemistiche.
Le figure professionali coinvolte nel progetto dovranno essere dotate degli skill necessari alla realizzazione del progetto. Tali skill ed eventuali certificazioni dovranno essere necessariamente documentabili e dovranno essere adeguate al ruolo ricoperto. Non potrà essere utilizzato personale alla prima esperienza nel settore se non per giustificati motivi; in tal caso dovrà essere comunque garantita l’assistenza di personale dotato di esperienza nel settore.
L’aggiudicatario dovrà fornire a Lario Reti indicazioni sulla tipologia di figure professionali che comporranno il team di progetto.
Sarà comunque facoltà di Lario Reti chiedere la sostituzione, nel più breve tempo possibile, di una o più risorse del gruppo di progetto, qualora il capo progetto IT di Lario Reti lo ritenesse necessario.
I profili chiave ritenuti necessari sono elencati nella seguente Tabella 7
Tabella 7 - REQUISITI MINIMI DELLE FIGURE PROFESSIONALI RICHIESTE
FIGURA PROFESSIONALE | ESPERIENZA |
Project Manager | Anzianità lavorativa nel ruolo di almeno 10 anni, di cui almeno 8 nel coordinamento di progetti in ambito Big Data ed Enterprise |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
FIGURA PROFESSIONALE | ESPERIENZA |
Data Platform oggetto della proposta. Si richiede una pregressa esperienza di almeno 5 anni nell’ambito utilities (elettrico, gas, idrico, con preferenza per quest’ultimo) nel mercato italiano. Si richiede, altresì, conoscenza delle normative Italiane e comunitarie relative al settore idrico. Deve essere dipendente dell’azienda appaltatrice e possedere preferibilmente certificazioni in ambito Project Management (PMI o Prince2 practitioner). Inoltre, è richiesta provata esperienza come analista funzionale e di processo. Si fa portatore della propria conoscenza relativamente a: • Coordinamento di gruppi di lavoro • Gestione avanzamenti e steering committee con il business • Redazione di minute e presentazioni / report di avanzamento lavori • Conoscenza di soluzioni Big Data • Metodologie di sviluppo e manutenzione del software • Conoscenze ed uso di tecniche e prodotti SW per project management e risk management | |
Service Manager | Anzianità lavorativa nel ruolo di almeno 10 anni, di cui almeno 5 nel coordinamento di progetti in ambito Big Data, Enterprise Data Platform ed Analytics oggetto della proposta. Si richiede una pregressa esperienza di almeno 5 anni nell’ambito utilities (elettrico, gas, idrico, con preferenza per quest’ultimo) nel mercato italiano. Si richiede, altresì, conoscenza delle normative Italiane e comunitarie relative al settore idrico. Deve essere dipendente dell’aggiudicatario e possedere preferibilmente certificazioni ITIL v4 o COBIT 5 foundation. Inoltre, è richiesta provata esperienza come analista funzionale e di |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
FIGURA PROFESSIONALE | ESPERIENZA |
processo. Si fa portatore della propria conoscenza relativamente a: • coordinamento di gruppi di lavoro • conoscenza di soluzioni Big Data, Enterprise Data Platform ed Analytics cloud/on premise • metodologie di implementazione dei sistemi cloud per la gestione delle risorse umane • metodologie di gestione dei servizi in Operation | |
Team Leader Funzionale | Anzianità lavorativa nel ruolo di almeno 5 anni, ha partecipato in almeno 3 progetti basati sulla soluzione proposta ricoprendo il ruolo di team leader funzionale. Si richiede una pregressa esperienza di almeno 2 anni nell’ambito utilities (elettrico, gas, idrico, con preferenza per quest’ultimo) nel mercato italiano su progetti in ambito Big Data, Enterprise Data Platform ed Analytics. Si richiede, altresì, conoscenza delle normative Italiane e comunitarie relative al settore idrico. Possiede approfondite conoscenze in ambito di: • redazione di specifiche funzionali di progetto • redazione di modelli dei processi • disegno e progettazione di test • aspetti funzionali relativi alla soluzione proposta • progettazione e conduzione di corsi in ambito alla soluzione proposta • predisposizione materiale di formazione di supporto |
Data Scientist | Anzianità lavorativa nel ruolo di almeno 5 anni, ha partecipato in almeno 3 progetti basati sulle tecnologie proposte ricoprendo il ruolo di Data Scientist. Sarà ritenuta preferibile una pregressa esperienza di almeno 2 anni nell’ambito utilities (elettrico, gas, idrico, con preferenza per quest’ultimo) nel mercato italiano. Possiede approfondite conoscenze in ambito di: |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
FIGURA PROFESSIONALE | ESPERIENZA |
• Analisi dei problemi di business al fine di tradurli in problemi di dati, identificando i dati rilevanti e definendo i modelli di analisi da utilizzare. • Raccolta, pulizia, integrazione e analisi di dati strutturati e non strutturati da diverse fonti. • Sviluppo di soluzioni innovative per problemi complessi di business utilizzando strumenti (Python, R, Hadoop, and Spark …) e tecniche di Machine Learning e Deep Learning, come regressione, clustering, classificazione e deep learning, per sviluppare modelli predittivi e di ottimizzazione. • Modalità e strumenti (Qlik, PowerBI, Plotly, Bokeh, Matplotlib ...) per la visualizzazione dei dati e la comunicazione dei risultati in modo chiaro e comprensibile anche per non addetti ai lavori. • Ingegneria dei dati e delle architetture di big data • Uso di linguaggi di programmazione (C, C++, Java, Xxxxx …) • Teamworking | |
AI Engineer/Architect | Anzianità lavorativa nel ruolo di almeno 5 anni, ha partecipato in almeno 3 progetti basati sulle tecnologie proposte. Sarà ritenuta preferibile una pregressa esperienza di almeno 2 anni nell’ambito delle utilities (elettrico, gas, idrico, con preferenza per quest’ultimo) nel mercato italiano. Possiede approfondite conoscenze in ambito di: • Tecniche di apprendimento automatico, dell'elaborazione del linguaggio naturale e delle architetture di reti neurali. • Principali linguaggi di programmazione utilizzati in AI come ad esempio Python, R, Java, C ++ e altri. • Ingegneria dei dati e delle architetture di big data • Trattamento e nella pulizia dei dati, nella selezione delle feature, nell'addestramento dei modelli e nella valutazione delle prestazioni. |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
FIGURA PROFESSIONALE | ESPERIENZA |
• Progettazione e sviluppo di algoritmi di machine learning e deep learning, compresi algoritmi di classificazione, regressione, clustering, neural network e algoritmi di apprendimento per rinforzo. • Teamworking | |
Analista funzionale | Anzianità lavorativa nel ruolo di almeno 4 anni su tecnologie e progetti in ambito Big Data, Enterprise Data Platform ed Analytics, ha partecipato ad almeno 2 progetti basati sulla soluzione proposta ricoprendo il ruolo di analista funzionale. Si richiede una pregressa esperienza di almeno 2 anni nell’ambito utilities (elettrico, gas, idrico, con preferenza per quest’ultimo) nel mercato italiano su progetti in ambito Big Data, Enterprise Data Platform ed Analytics. Possiede approfondite conoscenze in ambito di: • redazione di specifiche funzionali e di modelli dei processi con relativa documentazione • redazione di requisiti funzionali e trasferimento degli stessi nel repository di progetto esplicitandoli nelle varie categorie • disegno e progettazione delle fasi di test funzionali e grafici (UAT) accompagnati da materiale di supporto |
Sviluppatore/Configuratore Applicativo Senior | Anzianità lavorativa nel ruolo di almeno 5 anni. Possiede almeno 4 anni di esperienza di sviluppo sulla soluzione proposta ed eventuali certificazioni tecniche specifiche. Possiede approfondite conoscenze in ambito di: • analisi dei requisiti utente • redazione di specifiche tecniche di progetto • sviluppo di funzioni e procedure software • disegno, progettazione ed esecuzione dei test • stima di risorse per lo sviluppo del software • stima di tempi e pianificazione attività • progettazione e conduzione di corsi in ambito tecnico cloud sulla soluzione proposta |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
FIGURA PROFESSIONALE | ESPERIENZA |
• predisposizione materiale di formazione di supporto | |
Sviluppatore/Configuratore Applicativo Junior | Anzianità lavorativa nel ruolo di almeno 4 anni. Possiede almeno 2 anni di esperienza in progetti di sviluppo e configurazione sulla soluzione proposta ed eventuali certificazioni tecniche specifiche. Possiede approfondite conoscenze in ambito di: • analisi dei requisiti utente • redazione di specifiche tecniche di progetto • sviluppo di funzioni e procedure software • disegno, progettazione ed esecuzione dei test • stima di risorse per lo sviluppo del software • stima di tempi e pianificazione attività • progettazione e conduzione di corsi in ambito tecnico cloud sulla soluzione proposta • predisposizione materiale di formazione di supporto |
Tester Senior | Anzianità lavorativa nel ruolo di almeno 5 anni. Possiede almeno 4 anni di esperienza su progettazione, gestione ed esecuzione di test sulla soluzione proposta ed eventuali certificazioni tecniche specifiche. Si richiede una pregressa esperienza di almeno 2 anni nell’ambito utilities (elettrico, gas, idrico, con preferenza per quest’ultimo) nel mercato italiano su progetti in ambito Big Data, Enterprise Data Platform ed Analytics. Si richiede, altresì, conoscenza delle normative Italiane e comunitarie relative al settore idrico. Possiede approfondite conoscenze in ambito di: • analisi dei requisiti utente • redazione di test book e test plan • sviluppo di eventuali stub e procedure software per l’esecuzione di test automatizzati • disegno, progettazione ed esecuzione dei test • stima di tempi e pianificazione attività |
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
FIGURA PROFESSIONALE | ESPERIENZA |
• progettazione e conduzione di UAT sulla soluzione proposta • predisposizione materiale di formazione di supporto |
ART. 34 - DOCUMENTAZIONE DI PROGETTO
Tutta la documentazione prodotta dovrà essere redatta in lingua italiana. L’aggiudicatario dovrà utilizzare gli standard documentali in uso da Lario Reti. Tale documentazione in generale riguarda:
• Requisiti utente;
• Specifiche funzionali;
• Specifiche tecniche/data mapping;
• Documentazione dei processi;
• Disegno della base dati relativamente a tutte le parti del sistema che contengono “personalizzazioni” e/o funzioni di integrazione con gli altri applicativi aziendali (diagramma entità relazioni e documento con descrizione dettagliata di ciò che rappresentano le tabelle e i relativi attributi);
• Disegno dell’architettura del sistema e delle funzioni software realizzate per le
“personalizzazioni” e l’integrazione con gli altri applicativi aziendali (con particolare
attenzione alle parti d’integrazione con gli altri applicativi aziendali);
• Disegno del flusso dei dati relativamente a tutte le parti del sistema che
contengono “personalizzazioni” e/o funzioni di integrazione con gli altri sistemi aziendali;
• Specifiche di interfaccia;
• Specifiche e casi di test;
• Manuali utente.
Dovrà essere redatto un manuale utente per la gestione degli operatori e di tutti gli utenti della soluzione proposta.
Dovrà essere redatto un manuale amministrativo per la gestione dell’applicativo per il personale IT di Lario Reti, per poter effettuare eventuali attività di manutenzione e di gestione di riavvii/ripristini qualora l’applicativo lo richiedesse.
Per tutta la durata dell’appalto l’aggiudicatario avrà l’obbligo di realizzare
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
periodicamente nuove revisioni della documentazione (almeno una all’anno), in modo tale che questa risulti sempre aggiornata rispetto ai cambiamenti e alle evoluzioni del sistema.
Tutta la documentazione, realizzata in lingua italiana, prodotta dovrà essere caratterizzata da:
• Comprensibilità
• Completezza
• Accuratezza
L’utilizzo di strumenti e tools di documentazione, che dovranno comunque rispondere a criteri di larga diffusione di mercato, dovranno essere concordati con Lario Reti. Resta comunque vincolante l’utilizzo dei seguenti strumenti:
• per il text editor: Microsoft Word;
• per la gestione delle presentazioni: Microsoft Power point;
• per la gestione del progetto: Microsoft Project;
• per la gestione dei fogli elettronici: Microsoft Excel;
• per la gestione delle mappe applicative ed il disegno dei processi: Microsoft Visio.
Tutta la documentazione dovrà essere consegnata in formato elettronico editabile (no pdf), oltre che nel formato sorgente dei vari tool utilizzati.
ART. 35 - IMPORTO E DURATA DELL’APPALTO
L'importo complessivo d'appalto – comprendente tutte le prestazioni e forniture di servizi cloud, previste nel presente capitolato tecnico - è di € 650.000,00 + I.V.A. e sarà finanziato dall’Unione Europea nel contesto dell’iniziativa Next Generation EU con codice PNRR M2C4-I4.2_058 incluso nel “Progetto per la riduzione delle perdite nelle reti di distribuzione dell’acqua, compresa la digitalizzazione e il monitoraggio delle reti, in Provincia di Lecco – PNRR M2C4-I4.2”
Il contratto avrà durata di 27 mesi consecutivi dalla data di stipula del contratto, di cui 5 mesi per la realizzazione del progetto di realizzazione dell’Enterprise Data Platform, 1 mese dedicato alla fase di post Go-Live e 21 mesi per il servizio di manutenzione di Base.
Di seguito si segnalano le suddivisioni dei costi di cui al punto precedente:
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
Tabella 8 - Suddivisione degli importi
Progetto realizzazione Enterprise Data Platform | € 180.000,00 |
Canoni infrastruttura cloud ed eventuali licenze software | € 108.000,00 |
Gestione manutenzione di Base; | € 117.600,00 |
Gestione manutenzione Evolutiva | € 244.400,00 |
I prezzi si intendono fissi ed invariabili per tutta la durata del contratto. Lario Reti si riserva la facoltà di aggiudicare la gara anche in presenza di una sola offerta valida.
L’aggiudicatario prende atto che in caso di modificazioni legislative e giurisprudenziali e scelte societarie che modifichino la ragione sociale, e/o la composizione azionaria della stazione appaltante si procederà a subentro automatico e successione ex lege nelle posizioni attive e passive facenti capo a Lario Reti in virtù del contratto conseguente alla presente procedura di gara.
In caso di inadempienza contrattuale da parte del soggetto aggiudicatario, la Stazione appaltante, si riserva la possibilità di richiedere l’esecuzione del contratto in via d’urgenza, al fine di scongiurare la perdita dei fondi europei PNRR, ad altro operatore, presente possibilmente in graduatoria di gara.
In caso di fallimento di un operatore economico aggiudicatario, ovvero di risoluzione
dell’accordo quadro, ovvero nelle more del completamento delle procedure di cui all’art.
110 del D.Lgs. 50/2016, la Stazione appaltante, si riserva la possibilità di richiedere l’esecuzione del contratto in via d’urgenza, al fine di scongiurare la perdita dei fondi europei PNRR, ad un altro operatore, presente possibilmente in graduatoria di gara;
In caso di comprovata necessità e urgenza, come nei casi previsti dall’art. 163 del d.lgs 50/2016, oltre che per il rispetto dei target/milestone ed ulteriori condizioni (es. DNSH) previste dai progetti finanziati dal PNRR, la Stazione appaltante, verificata l’immediata indisponibilità di personale da parte dell’aggiudicatario del contratto, si riserva la possibilità di richiedere l’esecuzione ad un altro operatore, presente possibilmente in graduatoria di gara.
In fase attuativa, l’appaltatore dovrà far riferimento alla “Mappatura di correlazione fra Investimenti” contenuta all’interno della “GUIDA OPERATIVA PER IL RISPETTO DEL PRINCIPIO
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
DI NON ARRECARE DANNO SIGNIFICATIVO ALL’AMBIENTE (cd. DNSH)” ed in particolare per
la linea di finanziamento oggetto del presente progetto identificata come Missione 2 Componente C4 Id Inv. 4.2 - “Riduzione delle perdite nelle reti di distribuzione dell'acqua, compresa la digitalizzazione e il monitoraggio delle reti” il Regime identificato è il Regime 2, ovvero, “L'investimento si limita a "non arrecare danno significativo", rispetto agli aspetti ambientali valutati nella analisi DNSH” e sono individuate le schede tecniche da applicare, recepite dalla Stazione Appaltante; in particolare, l’appaltatore è obbligato ad assicurare che la realizzazione del servizio/fornitura oggetto di OdL risulti coerente con i principi e gli obblighi specifici del PNRR relativamente al principio del “Do No Significant Harm” (DNSH) e, ove applicabili, ai principi del Tagging clima e digitale, della parità di genere (Gender Equality), della protezione e valorizzazione dei giovani e del superamento dei divari territoriali, in conformità delle modalità e tempistiche previste per l'attuazione dei suddetti fondi ai sensi del DL 77/2021 come convertito in L. 108/2021 e s.m.i.p
ART. 36 - GESTIONE DEL CONTRATTO
Per la gestione e il controllo sulle attività svolte nell’ambito del presente appalto saranno predisposte le commissioni cg e ct:
Per tutta la durata del contratto il comitato guida si riunirà con frequenza mensile per valutare l’avanzamento delle attività e la qualità del servizio. Ad ogni riunione l’aggiudicatario dovrà consegnare:
• una relazione scritta contenente lo stato di avanzamento delle attività del progetto e/o dei servizi di manutenzione correttiva, adeguativa ed evolutiva, in cui si dovranno evidenziare le criticità emerse e le relative soluzioni individuate e l’aggiornamento del piano di realizzazione delle attività
• una relazione scritta riguardante il rispetto dei livelli di servizio che dovrà includere le statistiche mensili riguardanti i tempi di presa in carico e di risoluzione dei problemi segnalati nell’ambito del servizio di manutenzione di base.
ART. 37 - SEDE DI LAVORO
Le attività nell’ambito dei servizi svolti (ad esempio riunioni per l’espletamento delle attività di analisi, coordinamento, collaudo, formazione) si terranno da remoto con Microsoft Teams o presso le sedi di Lario reti in base alle esigenze della stazione appaltante.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 38 - APPARATI HARDWARE E LICENZE SOFTWARE
Il costo dei canoni degli ambienti di Sviluppo, Test, Pre-produzione e Produzione dovrà essere compreso all’interno del canone di cui alle licenze cloud offerte, inclusi i costi di infrastruttura ed eventuali Database.
Le stazioni di lavoro (personal computer) usate dal team dell’aggiudicatario nello svolgimento delle attività riguardanti il presente capitolato, e tutte le relative licenze software installate a bordo, nonché tutte le licenze dei tool per lo sviluppo della soluzione software in ambito al Cloud proposto, dovranno essere messe a disposizione dall’aggiudicatario.
Il costo delle licenze del software WEB per la tracciatura delle richieste di manutenzione (ManageEngine) sarà completamente a carico di Lario Reti.
ART. 39 - PROPRIETA’ DEL SOFTWARE SVILUPPATO NELL’AMBITO DELL’APPALTO
Il software realizzato dall’impresa nell’ambito del presente appalto (le sole personalizzazioni, interfacce verso altri sistemi di Lario reti, nuove funzionalità richieste ecc.) unitamente alle versioni “sorgenti” ed a tutta la documentazione relativa, resterà di proprietà esclusiva di Lario Reti, che ne deterrà i diritti di sfruttamento commerciale. Parimenti saranno di proprietà di Lario Reti le metodologie, le tecniche nonché le scoperte relative all’elaborazione dei dati sviluppati nel corso della prestazione, ferma restando la proprietà intellettuale che spetta al realizzatore.
L’impresa consegnerà al cti il codice "sorgente" e l’intera documentazione relativa al software sviluppato, e si impegna a non riprodurre, commercializzare o comunque cedere copia del prodotto a società o soggetti diversi senza la preventiva autorizzazione da parte di Lario Reti.
Si precisa ulteriormente ed esplicitamente che le "procedure applicative" (eventuali sviluppi ad hoc e/o personalizzazioni software, interfacce, ecc.) comunque previste, dovranno essere realizzate e fornite secondo modalità che consentano al personale di Lario Reti un utilizzo autonomo (non dovranno, cioè, essere "compilate" né "crittografate" né rese in alcun modo illeggibili e/o non editabili) e dovranno essere accompagnate da esauriente documentazione.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx
ART. 40 - PERIODO DI PROVA DEL PERSONALE DELL’AGGIUDICATARIO
All’avvio del Progetto è previsto un periodo di prova del personale appartenente ai due team (team dedicato alla Manutenzione di Base e team dedicato alla Manutenzione Evolutiva), della durata di due mesi a partire dalla data di avvio del servizio. Durante questo periodo la stazione appaltante potrà effettuare dei colloqui individuali a tutti i membri dei team. Al termine del periodo di prova la commissione ct si riserva di dare conferma del personale selezionato per i due team. In caso contrario l’azienda dovrà garantire, entro 10 giorni lavorativi, la sostituzione delle risorse non ritenute idonee con altre aventi il medesimo profilo professionale, esperienza e certificazioni. Qualora anche le ulteriori risorse proposte non fossero ritenute idonee, come esito di ulteriori colloqui individuali, sulla base di motivata argomentazione, la stazione appaltante potrà procedere alla risoluzione del contratto.
Lario Reti Holding S.p.A.
E-mail – xxxx@xxxxxxxxx.xx |Pec – xxxxxxxxxx@xxxxxxxxxxxx.xx |Sito web – xxx.xxxxxxxxx.xx