TYPE TYPE DETAIL

Technical Specification Capitolato per i processi di approvvigionamento

PROJECT

JOB

TASK

TITLE

CAPITOLATO per "Affidamento del servizio di realizzazione e manutenzione del nuovo sistema informativo gestionale di pianificazione e controllo del CIRA".

PREPARED	Xxxxxxxxxx Xxx	DATE	08/07/2021
APPROVED	De Matteis Xxxx Xxxxx	DATE	08/07/2021
AUTHORIZED	Xxxxx Xxxxx	DATE	08/07/2021

DOCUMENTO FIRMATO DIGITALMENTE

This Document is uncontrolled when printed. Before use, check the Document System to verify that this is the current version.

Questo documento non è controllato quando viene stampato. Prima dell'uso, controllare il Sistema Documentale per verificare che questa sia la versione corrente.

By The Terms Of The Law In Force On Copyright, The Reproduction, Distribution Or Use Of This Document Without Specific Written Authorization Is Strictly Forbidden

A NORMA DELLE VIGENTI LEGGI SUI DIRITTI DI AUTORE QUESTO DOCUMENTO E' DI PROPRIETA' CIRA E NON POTRA' ESSERE UTILIZZATO, RIPRODOTTO O COMUNICATO TERZI SENZA AUTORIZZAZIONE

TITLE:

CAPITOLATO per "Affidamento del servizio di realizzazione e manutenzione del nuovo sistema informativo gestionale di pianificazione e controllo del CIRA".

ABSTRACT:

Per correzione errori editoriali

AUTHORS:

Xxxxxxxxxx Xxx

Xx Xxxxxxx Xxxx Xxxxx; Xxxxx Xxxxx; Xx Xxxxx Xxxxxxxx; Xxxxxxxxx Xxxxxxx; Xxxxxx Xxxxx; Fiume Xxxxxxxx; Xxxxxxxxx Xxxxxxx; Xxxxxx Xxxxxxxxx

APPROVAL REVIEWERS:

Xxxxxx Xxxxxxxxx; Xxxxx Xxxxxxxx; Xxxxxxxxx Xxxxxxxxx; Xxx Xxxxx Xxxxxxx

APPROVER:

De Matteis Pier Paolo

AUTHORIZATION REVIEWERS:

AUTHORIZER:

Xxxxx Xxxxx

DISTRIBUTION RECORD:

Xxxxx Xxxxxxxx ( direttore generale ); Xxxxxxxx Xxxxxxxx ( presidente cira ); Xxxxxxxx Xxxxx; Xxxxx Xxxxx Xxxxx; Xxxxxxxx Xxxxxxxxxx

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

CAPITOLATO

Affidamento del servizio di realizzazione e manutenzione del nuovo sistema informativo gestionale di pianificazione e controllo del CIRA

Sommario

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

1. INTRODUZIONE 5

1.1 Riservatezza 5

1.2 Profilo del CIRA 5

2. OGGETTO DELL’APPALTO 6

3. DOCUMENTAZIONE E DEFINIZIONI 9

3.1 Documentazione applicabile 9

3.2 Documentazione di riferimento 9

3.3 Acronimi 9

4. CONTESTO DI RIFERIMENTO 10

4.1 Ambito organizzativo 10

4.2 Organizzazione delle attività 10

4.3 Pianificazione e programmazione operativa 13

5. SISTEMA INFORMATIVO GESTIONALE 20

5.1 Architettura di sistema 20

5.2 Requisiti di interfaccia vs sistemi esistenti 22

5.2.1 Breve nota sul workflow di creazione commesse 22

5.2.2 Dati da acquisire dai sistemi gestionali. 22

5.2.3 Modalità di gestione delle interfacce 23

5.2.4 Nota sul sistema documentale in uso al CIRA 23

6. REQUISITI DELLA SOLUZIONE SAAS (SOFTWARE AS A SERVICE) 24

6.1 Requisiti organizzativi (RO) 24

6.2 Requisiti specifici 24

6.3 Sicurezza (RS) 24

6.4 Performance e scalabilità (RPS) 25

6.5 Interoperabilità e portabilità (RIP) 25

6.6 Conformità legislative Sicurezza e Privacy (RCL) 26

6.7 Modalità e tempistica di erogazione della manutenzione e dell’assistenza tecnica 27

6.8 Altre raccomandazioni di carattere generale 27

7. MODALITÀ DI ESECUZIONE 28

7.1 Durata del progetto 28

7.2 Analisi Funzionale e Tecnica 29

7.3 Sviluppo di una Versione β 29

7.4 Versione 1.0 (Validazione e Collaudo) 30

7.5 Commissioning e rilascio versione finale 1.0 31

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3 7.6 Corso (addestramento) 31

7.7 Assistenza post vendita 31

8. SERVICE LEVEL AGREEMENT E PENALI 32

9. Attività di fine contratto 34

APPENDICE 1 – REQUISITI ALTO LIVELLO 35

Indice figure:

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

Figura 1 – Blocchi funzionali del prodotto 6

Figura 2 – Progetto, Commessa, WP 10

Figura 3 – Piramide aziendale 14

Figura 4 – Architettura “AS IS” sistemi gestionali. 20

Figura 5 ‐ Architettura “TO BE” sistemi gestionali 21

Figura 6 – Fasi di Progetto 28

Figura 7 – Planning di progetto 28

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

1. INTRODUZIONE

1.1 Riservatezza

Il presente Capitolato contiene informazioni proprietarie e confidenziali relativamente all’organizzazione ed alle strategie del C.I.R.A. S.C.p.a. – Centro Italiano Ricerche Aerospaziali (di seguito CIRA). Qualsiasi uso o pubblicazione, parziale o integrale, delle informazioni qui contenute, senza l’autorizzazione scritta del CIRA, non è consentito.

1.2 Profilo del CIRA

Il CIRA, Centro Italiano Ricerche Aerospaziali, è una società a prevalente partecipazione pubblica costituita nel 1984 per svolgere attività di ricerca nelle discipline aeronautiche e spaziali. Il Centro, che ha sede e strutture operative a Capua, in Campania, è nato per volontà dello Stato italiano che ha voluto dotare il nostro paese di una capacità di ricerca e sviluppo tecnologico in campo aeronautico e spaziale adeguata a quella degli altri paesi europei, al fine di consentire alle imprese italiane di competere ad alti livelli sui mercati internazionali. La presenza, nella compagine societaria, di enti come l'Agenzia Spaziale Italiana (socio di riferimento) e il Consiglio Nazionale delle Ricerche, della Regione Campania (attraverso l'Area di Sviluppo Industriale di Caserta) e di industrie e PMI del settore aerospaziale fa sì che gli obiettivi del CIRA siano coerenti con gli indirizzi strategici nazionali e con le esigenze delle imprese, contribuendo così allo sviluppo economico e sociale del Paese.

Il CIRA possiede la più grande dotazione di infrastrutture di ricerca in campo aerospaziale presente in Italia con impianti di prova unici al mondo e laboratori all'avanguardia utilizzati da enti e industrie nazionali ed internazionali. Le attività svolte riguardano le tematiche più avanzate della ricerca aerospaziale: dallo studio di velivoli aeronautici e spaziali in grado di volare in modo autonomo e a velocità elevatissime, alla messa a punto di sistemi innovativi per ridurre l'impatto ambientale dei velivoli, aumentare la sicurezza del volo, rendere più efficiente la gestione del traffico aereo fino allo sviluppo di tecnologie abilitanti per i futuri sistemi di trasporto spaziale.

Il CIRA partecipa ai principali programmi di ricerca europei e internazionali, collabora con le più importanti università e aziende aeronautiche e spaziali, italiane e straniere, ed è un forte attrattore di talenti e di investimenti industriali.

In un contesto di business aziendale così articolato in progetti di ricerca, formazione e servizi, con fonti di finanziamento pubbliche e private diversificate, è di fondamentale importanza per il CIRA dotarsi di strumenti efficaci ed efficienti di supporto ai processi di pianificazione e controllo, fruibili a livello sia di unità centrali amministrative che operative di linea e di team di progetto (Project Management), attraverso metodologie e strumenti informativi standard, in linea con un processo di trasformazione digitale che interesserà il Centro nei prossimi anni.

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

2. OGGETTO DELL’APPALTO

L’appalto oggetto del presente capitolato riguarda la fornitura di una soluzione “Software as a Service” (SaaS) in cloud, basata su una piattaforma SW “multivendor”, tale da garantire il principio di rotazione degli inviti e degli affidamenti per i rinnovi successivi alla scadenza del contratto derivante del presente appalto, a tutti i partner del produttore della piattaforma.

Per consentire quanto espresso è necessario che il software sviluppato sia aperto e documentato e non preveda “add on” o moduli proprietari della azienda aggiudicataria di questa gara e quindi non utilizzabili da altri partner della piattaforma. Dovranno essere inoltre consegnati al CIRA sia il SW che la base dati (vedi § 9).

La soluzione SW costruita su tale sistema dovrà costituire un sistema informativo di supporto ai processi di pianificazione, programmazione operativa e controllo del CIRA, operabile a diversi livelli aziendali (Direzioni, Unità Operative, Project Manager, Task Manager). Il presente Capitolato Speciale definisce i requisiti e le specifiche di progettazione, sviluppo e messa in esercizio del sistema.

Il sistema deve essere interoperabile con gli altri sistemi gestionali del CIRA (NAVISION 2018; Sistema di Gestione del Personale; Sistema Documentale) nell’ambito dell’architettura definita nel presente capitolato.

Il sistema deve assicurare funzionalità relative a processi di pianificazione, programmazione operativa, controllo e analisi, reporting, di seguito descritte sinteticamente rimandando alle successive sezioni una descrizione più dettagliata della loro applicazione nel contesto operativo del CIRA ed all’Appendice 1 la strutturazione dei requisiti di alto livello (funzionali e non funzionali).

Sistema

Controllo

Gestione

Reporting

Integrazione

di sistema

Pianificazione

Figura 1 – Blocchi funzionali del prodotto

Pianificazione budgeting aziendale e progetti

Il sistema deve assicurare l’esecuzione dei processi di pianificazione a livello di budget aziendale, di singole unità operative e di progetto/commessa, garantendo il raccordo tra i vari livelli. Sulla base di input di alto livello, tipicamente rispondenti a indirizzi del top management o derivanti da trend storici, come il valore della produzione, i costi generali e amministrativi, il costo del lavoro, i costi esterni di produzione, il sistema dovrà quindi assicurare analisi di scenari per predisporre ed ottimizzare i conti economici previsionali pluriennali (Piani Triennali), la successiva programmazione operativa su base annuale (Piani Budget) e la preparazione di specifici piani (approvvigionamenti, portafoglio proposte nuove iniziative, utilizzo delle risorse). Il processo di redazione ed approvazione dei piani aziendali deve essere implementato in conformità alla procedura aziendale, [AD.1].

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3 L’attività del CIRA è strutturata per progetti e relative commesse, quali elementi di base per la raccolta dei dati di budget (di norma si prevede che ciascun progetto abbia una commessa, sebbene per necessità organizzative di progetto o di controllo gestione sussistono casi di più commesse per progetto). Per l’intero

ciclo di vita, dalla fase di proposta (NI) a quella di implementazione, al progetto sono associati tempi e milestone, ore Manpower per ciascuna Unità Operativa e Impianti, altri costi diretti, costi esterni, ricavi per tipologia di finanziamento, da pianificare e monitorare costantemente. Il processo di apertura e variazione del progetto è oggetto di specifica procedura aziendale, [AD.2]. Al fine di assicurare un adeguato monitoraggio di ogni singolo progetto, al livello di dettaglio opportuno, il CIRA intende adottare metodologie e indicatori di performance standard (Earned Value), anche sulla base delle informazioni contabili disponibili alla data, che dovranno essere implementate nel sistema.

Sulla base di un’anagrafica progetti/task e commesse comune, attraverso la rilevazione dei dati contabili (ciclo passivo e attivo, ore lavorate e trasferte) dagli altri sistemi gestionali, il sistema dovrà assicurare l’analisi economica (costi e ricavi) alla data, per l’elaborazione dei consuntivi, rendicontazioni dei progetti per clienti e enti finanziatori, nonché l’aggiornamento dei conti economici previsionali (forecast) di esercizio e a vita intera.

Controllo di gestione

Il sistema si configura come uno strumento di estrazione, aggregazione, elaborazione delle informazioni, secondo un set di dimensioni per:

• Valutazione dello scostamento degli obiettivi stabiliti in sede di programmazione operativa ed i risultati conseguiti. Tali scostamenti saranno resi disponibili ai responsabili (Cdc, UO, progetto, commessa), affinché possano decidere e attuare le opportune azioni correttive.

• Analisi del conto economico secondo tre differenti approcci ricavi/costi, sulla base del modello e la procedura adottati dal CIRA, [AD.3]: per natura (voce merceologica); per responsabilità (centro di costo); per destinazione (concorso di risorse).

• Composizione dei costi e come questi contribuiscono alla realizzazione del prodotto.

Gli elementi del controllo gestione, oltre a rappresentare la base della reportistica aziendale ai vari livelli, alimentano i processi di pianificazione e controllo, fornendo l’avanzamento dei costi alla data necessari per i forecast ed il calcolo degli indicatori di avanzamento dei progetti.

Reporting aziendale

Sulla base delle funzionalità operative sopra descritte, il sistema dovrà quindi assicurare la rappresentazione dei dati, sia in fase di pianificazione che di controllo, per la redazione dei piani ed il reporting periodico, previsionale e di avanzamento (su base mensile) per:

• livello società (conti economici)

• centri di responsabilità economica (aggregazione di centri di costo);

• centri di costo;

• progetti e relative commesse.

attraverso specifiche “dashboard” che saranno definite all’avvio del progetto. Il sistema dovrà inoltre permettere il reporting per:

• cliente o finanziatore;

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

• prodotto, come risultato intermedio o finale;

• funzione, come profilo delle risorse impegnate;

• processo, come concorso di attribuzione dei costi e dei ricavi

Il CIRA, inoltre, per la parte di finanziamento pubblico ha la necessità di elaborare rendicontazioni di costi e report periodici di stato di avanzamento, che richiedono informazioni aggregate in specifici inviluppi di programma (es. PRORA), nonché in specifiche aggregazioni di commesse e dati di contabilità generale, rispondenti alla Direttiva MEF per la contabilità separata [RD.2]1

Integrazione di sistema

L’integrazione del sistema con gli altri applicativi gestionali è un requisito essenziale per garantire che le informazioni su cui si basano i processi di pianificazione, controllo di gestione, consuntivazione e reporting, siano affidabili, complete, integre e riconciliabili. Sul piano della qualità è necessario favorire la tempestività e l’accuratezza delle elaborazioni, riducendo il rischio di errori, nelle fasi sia di pianificazione che di controllo e reporting. Sul piano della produttività è essenziale minimizzare i tempi (ore‐uomo) dedicati dalle risorse per l’estrazione ed elaborazione dei dati, favorendone l’impiego per le attività di analisi a valore aggiunto. Per il raggiungimento di tali obiettivi è richiesto:

• analizzare e individuare le fonti dei dati;

• Integrare i sistemi che forniscono tali dati e centralizzarne l’elaborazione sul sistema/servizio da fornire, con l’ulteriore scopo di fare a meno degli strumenti di produttività individuale.

La nuova piattaforma dovrà essere perfettamente integrata con i sistemi attualmente presenti al CIRA, pertanto si richiede al Fornitore un’attività di integrazione tra nuova piattaforma e sistemi attuali.

1 Per evidenza dei report specifici previsti per la contabilità separata si potrà fare riferimento anche ad altra documentazione che sarà resa disponibile, in aggiunta alla Direttiva MEF del 9 settembre 2019 in via di definizione e recepimento da parte del CIRA.

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

3. DOCUMENTAZIONE E DEFINIZIONI

3.1 Documentazione applicabile

[AD.1] “Redazione piani di periodo” ‐ CIRA‐CF‐06‐0822

[AD.2] “Gestione dei progetti. Manuale e procedure” ‐ CIRA‐DTS‐17‐0272 [AD.3] “Modello di Controllo di Gestione”, CIRA‐DTS‐21‐0087

[AD.4] “Disposizione Generale n.41 rev.1”, CIRA‐CIP‐21‐0074

[AD.5] “Condizioni contrattuali generali CIRA” ‐ CIRA‐DTS‐20‐2590 rev.0 [AD.6] “Xxxxx Xxxxxxxxx 00‐00” – CIRA‐DTS‐21‐1005

3.2 Documentazione di riferimento

[RD.1] Decreto legislativo 18 aprile 2016 n.50 Codice degli Appalti Pubblici [RD.2] Direttiva MEF del 9 settembre 2019 – contabilità separata

3.3 Acronimi

AC – Actual Cost

ACWP – Actual Cost of Work Performed

BAC ‐ Budget at Completion

BCWP ‐ Budgeted Cost of Work Performed BCWS – Budgeted Cost of Work Scheduled CdC – Centro di Costo

CPI ‐ Cost Performance Index

CV ‐ Cost Variance

EAC ‐ Estimate at Completion

EBITDA ‐ Earnings Before Interest, Taxes Depreciation and Amortization

EV – Earned Value KoM – kickoff Meeting NI – Nuove Iniziative

ODBC ‐ Open DataBase Connectivity

PJC – Project Charter

PM – Project Manager

PNI – Proposta Nuova Iniziativa

PRORA – Programma di Ricerche Aerospaziali

PV – Planned Value

PT – Piano Triennale

SAL – Stato Avanzamento Lavori SPI ‐ Schedule Performance Index SV ‐ Schedule Variance

UO – Unità Organizzativa

WP ‐ Work Packages

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

4. CONTESTO DI RIFERIMENTO

4.1 Ambito organizzativo

L’organizzazione del CIRA vigente, [AD.4], aggrega funzioni di staff e tecnico‐operative in ambienti omogenei (Direzioni), puntando all’accrescimento dell’accountability del management intermedio, alla riduzione del rapporto indiretti/diretti per una migliore competitività industriale.

L’organizzazione delle Unità Operative delle Direzioni tecniche (Ricerca, Infrastrutture e Sperimentazione) è intesa assicurare il presidio del progressivo bilanciamento del portafoglio delle attività che contribuiscono al Valore della Produzione: ricavi da parte terza, svolgimento del programma istituzionale PRORA, attività di servizi di ingegneria (sia teorico‐numeriche che sperimentali). Sul piano più strettamente gestionale, le Unità Operative tecniche devono quindi garantire:

• la gestione di un portafoglio bilanciato di progetti assegnati all’unità, in termini di ricavi da fonti terze, PRORA investimenti, autofinanziamento;

• l’allocazione dinamica delle competenze e skills ed utilizzo delle capacità (laboratori, infrastrutture) sui progetti;

• gestione dei laboratori ed infrastrutture, loro manutenzione, valorizzazione ed estensione degli inviluppi operativi in risposta al mutevole scenario della R&ST nonché degli aspetti normativi e certificativi;

Ogni Unità Operativa del CIRA gestisce un portafoglio progetti, della cui pianificazione ed avanzamento rispetto agli obiettivi è responsabile. Il budget affidato ad ogni unità ed il relativo conto economico si compongono quindi dei costi e dei ricavi di progetti afferenti all’unità stessa, in forma esclusiva oppure come quota di partecipazione a progetti afferenti ad altre unità operative, attraverso specifiche commesse.

4.2 Organizzazione delle attività

L’intera attività tecnico‐scientifica e produttiva del CIRA è organizzata in progetti, quali elementi base della pianificazione e della programmazione operativa. Ogni progetto di ricerca può a sua volta essere strutturato in una o più commesse, quali aggregati di Work Packages (Task) e costi associati, sulla base di una organizzazione del progetto proposto dal Project Manager (PM). L’organizzazione in più commesse risponde a esigenze di carattere organizzativo o gestionale.

Progetto

Commessa 1

Commessa 2

WP2000

WP3000

WP1000

WP4000

Figura 2 – Progetto, Commessa, WP

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3 L‘intero progetto è descritto in un documento aziendale, Project Charter (PJC), la cui redazione è disciplinata dalla procedura [AD.2], che contiene le informazioni tecnico‐programmatiche, organizzative ed economico‐ finanziarie necessarie per l’approvazione iniziale e per la successiva apertura. Il PJC viene prodotto in sede di proposta di nuova attività, sia finanziata da terzi che autofinanziata, ed allega una scheda di budget, denominata Proposta Nuova Iniziativa (PNI), che dovrà essere sottoposta ad un iter approvativo, da implementare nel sistema informativo, disciplinato dalla procedura [AD.2]. Le variazioni in corso d’opera del progetto sono riportate nella revisione del Project Charter e sono ugualmente soggette allo stesso iter approvativo della PNI, anch’esso da implementare nel sistema informativo.

Anche le attività ricorrenti gestionali, riconducibili a funzioni di staff o alla conduzione di impianti di prova ed ausiliari, sono assimilate a progetti. In virtù della loro natura continuativa e ricorrente, tali attività vengono pianificate e dimensionate, su base annuale, dai responsabili di centro di costo.

Ogni progetto e tutte le relative commesse sono associate, nell’anagrafica della programmazione, ad una delle categorie di seguito descritte:

• Linee Strategiche di Ricerca, che comprendono tutti i progetti di ricerca e sviluppo tecnologico, i cui indirizzi derivano dalla pianificazione strategica e da specifiche Roadmap tematiche che il CIRA intende sviluppare in un arco temporale pluriennale, a loro volta rispondenti agli indirizzi nazionali ed europei del settore aerospaziale, [AD.6].

• Infrastrutture e impianti di ricerca, progetti di investimento e adeguamento tecnologico sui beni strumentali di patrimonio dello Stato e di cui CIRA è concessionario, finanziati dal PRORA.

• Servizi di Ingegneria e Sperimentazione, progetti di vendita di servizi a terzi che prevedono l’utilizzo degli asset materiali e immateriali (competenze) del CIRA, secondo tassi certificati e rispondenti alla policy aziendale adottata.

• Formazione, attività di formazione interna ed esterna.

• Gestione, attività relative alla conduzione del Centro (gestione e conduzione impianti e laboratori, gestione strutture operative).

Ai progetti e alle relative commesse, sono inoltre associati degli attributi, al fine di consentirne l’aggregazione per necessità di pianificazione, controllo, rendicontazione e analisi di business:

• Tipologia di Finanziamento, in relazione all’obbligo di adesione a specifici sistemi di rendicontazione, nonché all’effettuazione di adempimenti richiesti dalla normativa nazionale o europea (ad es. MIUR PRORA 662/20, UE Framework Program, PON‐POR MIUR, FAR L.297/99 MIUR, Accordi quadro con la Regione Campania, bandi ASI, bandi SEGREDIFESA, bandi ESA, ecc.);

• Cliente, in relazione al soggetto che eroga il finanziamento o stipula il contratto (UE, MIUR, Regione Campania, Aziende Nazionali, Aziende UE, Aziende Non‐UE, ecc.);

• Programma PRORA, in relazione alle esigenze di controllo della programmazione dei costi a vita intera dei programmi/progetti di investimento finanziati direttamente dal MUR e degli obblighi di rendicontazione periodica (Stati Avanzamento Lavori).

• Tipologia di attività, correlata alla natura delle attività sviluppate (ad es. attività di sviluppo autofinanziate, attività di ricerca da fonti terze, attività PRORA, servizi di ingegneria e sperimentazione, servizi di formazione, gestione e conduzione impianti, gestione struttura, ecc.), in relazione alle esigenze di controllo della contabilità separata.

• Centro di Costo, relativo al Responsabile di Commessa per le commesse e al Responsabile di progetto per i progetti.

La gestione dei progetti riguarda l’intero ciclo di vita a partire dalla proposta con successiva fase negoziale, in cui viene definita una prima pianificazione, denominata Proposta Nuova Iniziativa (PNI), all’esecuzione del contratto stesso.

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3 Risulta fondamentale tenere in considerazione l’orizzonte temporale nel quale si prevede di portare a termine il progetto per la previsione della distribuzione dei costi nel tempo, tenendo in considerazione la necessità di gestire in modo efficiente l’allocazione delle risorse, e la maggior difficoltà nel pianificare correttamente le tempistiche necessarie per assolvere attività particolarmente lunghe.

Le informazioni di preventivo (Budget Cost Work Scheduled) e di avanzamento fisico (Budget Cost Work Performed) per progetto, che devono essere residenti e gestite nel sistema oggetto della presente fornitura, e quelle di consuntivo (Actual Cost Work Performed), raccolte dai sistemi informativi NAV2018 e Sistema Gestione Personale, consentono ogni mese di rappresentare l’avanzamento del progetto al mese precedente e di fare una proiezione sull’anno ed a finire.

Sottoinsieme	Entità	Modalità di calcolo/acquisizione	Dati per ciascun elemento dell’entità
Costo pianificato (BCWS)	• Ore • Skill risorsa • Impianti • Costi Esterni • Trasferte	Profilo di costo come somma dei costi mensili diretti pianificati per Task Pianificazione Mensile/Trimestrale	• Codice Progetto • Codice Commessa • Codice Task (WP) • Centro di Costo
Avanzamento attività (BCWP)	• Milestone • SAL • Deliverable	Profilo di costo come somma dell’avanzamento alla data per Task a costi pianificati	• Codice Progetto • Codice Commessa • Codice Task (WP) • Centro di Costo
		Avanzamento calcolato su base %
		rispetto al costo pianificato per
		Task:
		Milestone superate
		SAL emessi
		Percentuale deliverables emessi
Avanzamento Costo (ACWP)	• Ore • Profilo risorsa • Impianti • Costi Esterni • Trasferte • Ricavo	Somma dei costi mensili consuntivati per commessa: • valorizzazione ordini “emessi” sulla base dei benestare “rilasciati” alla data • valorizzazione ore ai tassi di riferimento • valorizzazione trasferte • numero risorse impegnate	• Codice Progetto • Codice Commessa • Codice Task (WP) • Centro di Costo
Indicatori	• Varianza costi (CV) • Varianza tempi (SV) • Indicatore Costi (CPI) • Indicatore Tempi (SPI) • Indicatori di Performance (PI) • Budget a finire	CV = BCWP ‐ ACWP SV = BCWP ‐ BCWS CPI = BCWP/ACWP Cost Performance Index SPI = BCWP/BCWS Schedule Performance Index PI = CPI*SPI Performance Index Budget at Completion (BAC)=AC + costo previsto a budget per il lavoro rimanente Estimate at Completion (EAC)=BAC/CPI	• Codice Progetto • Centro di Costo

Tabella 1 ‐ Dati estratti per Progetti per applicazione metodologia Earned Value

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

4.3 Pianificazione e programmazione operativa

Il processo di pianificazione del CIRA si articola su due cicli, denominati rispettivamente top‐down e bottom‐ up, così da coinvolgere tutti diversi livelli aziendali della catena gerarchica coinvolte nel processo e che hanno responsabilità. Il risultato di tale processo, che tipicamente richiede più iterazioni per un allineamento della pianificazione al più alto livello (conto economico previsionale) con quella analitica per progetto/commessa nello stesso periodo, è un piano pluriennale (di norma triennale con proiezioni anche decennali per alcuni programmi). Tale piano viene aggiornato su base annuale, [AD.6].

La programmazione operativa viene implementata nel piano budget o piano annuale, e articola il budget solare per unità operative/centri di costo e progetti, fissando obiettivi misurabili di periodo, il cui andamento viene monitorato nel corso dell’anno. La sua importanza ai fini della gestione dell’esercizio è notevole, perché permette di:

• identificare con anticipo i possibili fabbisogni di risorse evidenziandone eventuali esuberi o carenze

• attribuire ai responsabili di progetto obiettivi di vendita che risultino coerenti con gli obiettivi annuali

• valutare il fabbisogno finanziario necessario le risorse allocate sulle diverse commesse

Per far sì che il budget solare generi il valore aggiunto atteso dalle strategie aziendali, fissate nella pianificazione pluriennale, è necessario che il piano budget sia costruito tenendo in considerazione le linee guida e gli obiettivi aziendali, i vincoli strutturali e finanziari e le realistiche capacità di crescita dell’azienda, legate all’attribuzione di obiettivi sfidanti ma raggiungibili ai responsabili di progetto.

E’ altresì fondamentale, in corso di esercizio, produrre degli aggiornamenti periodici del conto economico previsionale del piano budget, così detti Forecast, sulla base dei rilevi degli avanzamenti dei progetti e del controllo gestione, come di seguito descritto.

4.4 Controllo di Gestione

Il modello di controllo di gestione del CIRA è descritto in, [AD.3] e rappresenta l’anello finale di un più ampio processo di pianificazione, che prendendo le mosse dalla formulazione delle scelte fondamentali dell’impresa, definisce programmi ed azioni, necessari all’attuazione di tali scelte, verificandone, sistematicamente il grado di realizzazione. Al fine di perseguire obiettivi di miglioramento della redditività e dell’efficienza il CIRA adotta una classificazione dei costi e dei ricavi per centri di costo.

I centri di costo sono centri di responsabilità o raggruppamenti di unità operative, al cui titolare vengono affidati obiettivi di ottimizzazione dei costi, attraverso il razionale impegno delle risorse impiegate.

Requisito fondamentale affinché un’unità operativa venga definita “Centro di Costo” è la presenza di un budget di costi ad essa riferiti. L’attuale struttura organizzativa del CIRA è di tipo gerarchico ed è organizzata su quattro livelli. La cosiddetta piramide aziendale vede al livello più basso l’Unità operativa (IV Livello) che si raggruppa nei Centri di Costo (III Livello). I Centri di Costo a loro volta, possono essere raggruppati nelle Direzioni (Livello II) che a loro volta possono essere raggruppati in Presidenza e Direzione Generale (Livello I).

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

Presidenza e

Direzione Generale

‐Direzione Ricerca

‐Direzione Infrastrutture e sperimentazione

‐Direzione amministrativa

Centri di Costo

Unità Operative

Figura 3 – Piramide aziendale

Sotto il profilo della responsabilità, nell’ambito di ciascuno dei centri di costo il sistema dovrà distinguere:

• i costi primari: ossia quei costi relativi alle risorse direttamente gestite (o indirettamente tramite le commesse) da ciascun Centro di Costo per lo svolgimento della propria attività;

• i costi ricevuti: ossia i costi ribaltati da altri centri di costo a fronte di prestazioni (ore) cedute su commesse appartenenti al centro;

• i costi ceduti: ossia i costi ribaltati ad altri Centri di Costo per prestazioni svolte su altre commesse. Per quanto attiene la responsabilità, i centri riceventi sono responsabilizzati sulle unità di prestazioni che ricevono e che, quindi, utilizzano per la propria attività. I centri cedenti, invece, sono responsabilizzati sul costo unitario delle prestazioni che forniscono e quindi sull’efficienza con la quale svolgono la propria attività. Il sistema dovrà essere in grado di sviluppare report che analizzino e sintetizzino le variazioni intervenute all’interno di un centro di costo, in termini di prezzo (differenza tra le unità d’opera a prezzi standard e le unità d’opera cedute a prezzi effettivi) e in termini di volume (differenza tra unità d’opera effettivamente cedute e cessioni previste a budget).

La contabilità gestionale al CIRA costituisce il vertice dell’informativa di controllo e si costituisce, oltre che per responsabilità, anche per natura e per destinazione.

Il sistema dovrà aggregare ed elaborare le informazioni, determinando:

• il conto economico scalare per natura, in cui i costi e i ricavi si suddividono in base alla causa economica (natura) del fattore che li ha originati;

• il conto economico scalare per destinazione con evidenza dei vari stadi della formazione del risultato lordo di gestione caratteristica e l’utilizzo delle risorse sia interne che esterne all’azienda atte a modificare l’utile o la perdita d’esercizio.

Risulta evidente che per il CIRA è mandatario conoscere la composizione dei costi diretti ed eventualmente di trasformazione di ogni singolo prodotto; inoltre al fine di ottimizzare le risorse sapere il contributo che ogni singolo CdC riesce a fornire per la definizione di quello che classicamente viene definito come “Costo economico tecnico” del prodotto di vendita.

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3 Altro punto sostanziale è quello di definire quanto quel tipo di prodotto incide sul risultato globale del CIRA, oppure fino a che punto quel prodotto copre con il prezzo di vendita i propri costi diretti e i costi ribaltati da altri CdC.

La struttura del presente sistema di controllo di gestione che dovrà essere implementato nel nuovo sistema di supporto ai processi di pianificazione, programmazione operativa e controllo di gestione del CIRA, dovrà dare la possibilità di gestire il reporting su quattro piani organizzativi:

• Società

• Centri di responsabilità economica

• Centri di costo

• Programma, progetti, commesse Nonché di gestire il reporting per:

• Prodotto

• Funzione

• Processo.

In tal senso, il nuovo sistema di supporto ai processi di controllo di gestione del CIRA si configura come uno strumento di estrazione, aggregazione, elaborazione e stampa delle informazioni derivanti dal sistema informativo NAVISION 2018 e dal Sistema Gestione Personale.

È inoltre indispensabile l’alimentazione automatica dei dati a consuntivo provenienti dalle procedure collegate (sottosistemi: di contabilità generale e contabilità analitica, gestione risorse e paghe, rilevazione ore lavorate, conduzione degli impianti, budget ecc.). Nella tabella che segue sono riportati i sottosistemi, e per ognuno di essi i dati da estrarre.

Sottoinsiemi	Entità	Annotazioni	Dati per ciascun elemento dell'entità
Rilevazione Ore Lavorate	Ore lavorate per skill: - Manager -Quadri -Impiegati -Operai divise in: -Ordinarie -Straordinarie	Le ore vengono valorizzate a Costo orario medio standard per dipendente	Codice commessa
			Quantità
			Valore
			Data di competenza
			Centro di costo
			Codice voce merceologica
Gestione risorse e paghe	Costi di retribuzione	Valorizzati a costi di cedolino	Centro di costo
			Valore
			Data di competenza
			Livello
			Codice voce merceologica
	Costi accessori del lavoro	Altri costi da contratto	Codice commessa
			Quantità
			Valore
			Data di competenza
			Centro di costo
			Codice voce merceologica

Costo della trasferta	Sistema Travel	Codice commessa
		Valore
		Quantità
		Data di competenza
		Codice voce merceologica
Costo standard orario	Calcolato in sede di budget	Costo di retribuzione standard diviso per:
		Skill

Sottoinsiemi	Entità	Annotazioni	Dati per ciascun elemento dell'entità
Contabilità generale Contabilità analitica	Ricavi	Costi contabilizzati per competenza	Codice commessa
	Materiali		Codice voce merceologica
	Prestazioni		CdC
	Servomezzi		Valore
	Trasporti		Data di competenza
	Imposte		Codice Macchina/Impianto
	Contributi
	Oneri finanziari
	Costi diversi
Gestione ordini fornitori	Progettazione	Ratei di costi estratti dall'archivio per prestazioni di natura ripetitiva	Codice commessa
	Consulenze		Codice voce merceologica
	Pubblicità		CdC
	Servizi		Valore
	Locazione e leasing		Data di competenza
	Canoni		Codice Macchina/Impianto
	Assicurazioni		Num rda/oda/bda

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3 Il processo di produzione del reporting appartiene al “sottosistema” di controllo di gestione che dovrà consentire l’ottenimento di varie categorie di tabulati ai vari livelli d’aggregazione desiderati. In generale dovranno essere prese in esame le seguenti categorie di dati:

• Dati consuntivi;

• Dati di budget (relativi al periodo in esame);

• Forecast (dati consuntivi più proiezioni a fine anno);

• Budget originario (dati fissi dell’anno);

• Differenza periodo (1‐2);

• Differenza anno (3‐4).

• Contabilità separata2

Il sistema di reporting del CIRA è articolato in tre parti che rispecchiano i vari livelli decisionali:

1. Reporting Direzionale (informazioni strategiche): comprende gli elementi di sintesi più significativi del reporting attuativo ed operativo, nonché informazioni relative allo scenario macro‐economico interno ed esterno all’azienda.

2. Reporting attuativo (informazioni direttive): è lo strumento volto a fornire ai responsabili aziendali di primo e secondo livello, a seconda della loro competenza, i dati economici qualitativi e quantitativi.

3. Reporting operativo (informazioni per aree): è lo strumento volto a fornire i dati economici qualitativi e quantitativi ai centri di responsabilità per l’operatività gestionale.

Queste informazioni sono, in prima battuta, destinate alla verifica degli indirizzi programmatici e in seconda battuta, da supporto ai processi di natura decisionale e di controllo della propria attività.

Di seguito sono elencati i rapporti di gestione, classificati per destinatario dell’informazione, con l’indicazione della vista logica e frequenza e della reportistica di base che il sistema di controllo di gestione deve fornire ai diversi destinatari aziendali.

2 Per evidenza dei report specifici previsti per la contabilità separata si faccia riferimento a XXXX-XXX-00-0000, XXXX- XXX-00-0000, XXXX-XXX-00-0000, nonché alla Direttiva MEF del 9 settembre 2019 in via di definizione e recepimento da parte del CIRA.

Destinatario	Descrizione	Vista logica	Frequenza
ALTA DIREZIONE	Conto economico per destinazione	Società	QUADRIMESTRE
	Conto economico per destinazione: sintesi	Società	MESE
	Conto economico per natura	Società	QUADRIMESTRE
	Margine operativo lordo per Cdc	Responsabilità	QUADRIMESTRE
	Margine operativo lordo per Cdc: sintesi	Responsabilità	MESE
	Margini di prodotto: sintesi	Responsabilità	QUADRIMESTRE
	Margini di prodotto: sintesi	Prodotto	QUADRIMESTRE
	Prospetto di Conto economico per contabilità separata	Società	ANNUA
	Prospetto di Stato Patrimoniale per contabilità separata	Società	ANNUA
	Nota integrativa ai prospetti di contabilità separata	Società	ANNUA
AREA DIRETTIVA	Margine operativo lordo per commessa	Destinazione	QUADRIMESTRE
	Margine oper. lordo per commessa e Cdc	Destinazione	MESE
	Margine oper. lordo per commessa e Cdc	Responsabilità	MESE
	Margine di prodotto per commessa e Cdc	Prodotto	QUADRIMESTRE
		Destinazione
		Responsabilità
	Margini di prodotto per Cdc: Sintesi	Prodotto	QUADRIMESTRE
	Analisi costi e performance per CdC	Natura	MESE
	Analisi costi e performance per CdC	Responsabilità	MESE
RESPONSABILI	Analisi degli scostamenti per CdC	Natura	MESE
	Analisi degli scostamenti per CdC	Responsabilità	MESE
	Analisi degli scostamenti per commessa	Natura	MESE
	Analisi degli scostamenti per commessa	Destinazione	MESE

Tabella 2 – Tipologia di report

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

4.5 Finanza Agevolata

Il sistema dovrà assicurare le funzionalità relative a processi di rendicontazione dei costi e delle risorse. I dati di commessa/PNI dovranno essere strutturati in:

✓ Task per tipologia di attività (es: Ricerca Industriale/Sviluppo Sperimentale/Ricerca Fondamentale/Sviluppo Precompetitivo);

✓ sotto‐task per Work Packages/Obiettivi Realizzativi. Relativamente ai costi rendicontabili (ammissibili):

• i dati relativi ai costi “esterni” (trasferte incluse) ed alla manpower dovranno riportare l’indicazione delle task/sotto‐task nonché il numero e data di registrazione nel sistema Navision 2018;

• i dati relativi ai costi esterni dovranno riportare le indicazioni dei rispettivi giustificativi di pagamento (data/numero/etc) nonché il numero e data di registrazione nel sistema Navision 2018;

• in caso di beni ammortizzabili il sistema dovrà esporre il valore contabilizzato della singola quota di ammortamento per periodo di competenza e il nr. del cespite come da libro cespiti nonché il numero e data di registrazione nel sistema Navision 2018;

• la valorizzazione dei dati di Manpower dovrà essere effettuata al costo diretto previsto dai singoli finanziamenti;

• i costi orari indicati dovranno riferirsi alla determinazione effettuata da Amministrazione del Personale sulla base dei dati riferiti all’ultimo bilancio approvato;

• la valorizzazione dei costi per “Ore Impianto” dovrà essere effettuata al costo determinato sulla base dei dati riferiti all’ultimo bilancio approvato.

5. SISTEMA INFORMATIVO GESTIONALE

5.1 Architettura di sistema

Il sistema oggetto della presente fornitura sarà interoperabile con gli altri sistemi gestionali in uso. Di seguito sono rappresentati gli schemi” AS IS” e il “To Be” dei sistemi.

Attualmente tutte le fasi di Pianificazione e Contabilità sono realizzate all’interno di Navision 2018 e di una applicazione integrata con essa: Timevision / Nota Spese.

Le ore che il personale ha effettivamente lavorato sono raccolte dal sistema di gestione del Personale (One Service, modulo Time, di ADP). Queste ore servono per la verifica dell’input nel sistema di abbinamento ore a commessa (le ore dichiarate a commesse non possono differire da quelle realmente lavorate).

Analogamente anche i costi di trasferta sono generati in One Service, modulo Travel. La fase di associazione delle trasferte alle commesse, viene effettuata tramite una App esterna e scritta dal CIRA (il modulo Travel non permetteva una efficace gestione di tale attributo). Una volta che la richiesta di trasferta è stata trasferita in One Service/Travel (interfaccia basata su scambio file e schedulata giornalmente), viene avviato il processo autorizzativo e alla fine di questo sarà possibile associare i costi sostenuti dal dipendente (che erediteranno automaticamente la commessa). A fine mese le trasferte saranno liquidate e sarà generato un flusso dati in uscita da One Service (interfaccia basata su scambio file e lanciata on demand).

Questi dati saranno elaborati e trasferiti nel modulo Nota Spese di Timevision.

Insieme con le ore caricate a commessa, saranno utilizzati dal processo di contabilizzazione che popolerà la tabella dei consuntivi a commessa e permetterà di tenere sotto controllo gli avanzamenti progetto.

Navision 2018

Timevision/Nota Spese

(ore lavorate a commessa) (costi trasferte a commessa)

Processo di contabilizzazione

Sistema del Personale

(Consuntivi Trasferte)

App Trasferte

Interfaccia Ore lavorate e costi trasferte

Figura 4 – Architettura “AS IS” sistemi gestionali

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

Navision 2018

Anagrafiche Consuntivi ciclo passivo/attivo

Sistema del Personale

Consuntivi ore Consuntivi Trasferte Costo del Personale

CIRA‐DTS‐21‐1291 ‐ rev. 3

Sistema di Pianificazione e Controllo

Sistema Commesse e Controllo di

Gestione

Link a documenti

Sistema Documentale Sharepoint

Figura 5 ‐ Architettura “TO BE” sistemi gestionali

Nel To Be la situazione evolverà in quanto il nuovo sistema di gestione del Personale includerà sia la funzione Timevision, che quella Nota Spese. Il processo di contabilizzazione non sarà più effettuato in quanto, una volta disponibili i dati di consuntivo, questi saranno elaborati nel nuovo sistema di Pianificazione e Controllo. Di seguito si riportano i dati nativi sui vari sistemi.

NAVISION 2018 🡪 dati del ciclo passivo e attivo

Sistema Gestione Personale 🡪 ore, costo diretto, trasferte (dati del mese precedente);

costo orario;

inquadramento delle risorse (per calcolo ricavo a rendicontazione); numero di risorse disponibili per UO e per tutto il CIRA.

Sistema Documentale🡪 relazioni, documenti di progetto

I tempi di go live del nuovo sistema di Pianificazione e Controllo e quello del nuovo sistema di Gestione del Personale non potranno essere sincronizzati, quindi alla fase di avvio del sistema di Pianificazione e Controllo sarà ancora attivo il sistema rappresentato nell’AS IS.

Le interfacce quindi saranno diverse. Fino a fine 2021 dovranno puntare al sistema OneService di ADP e da gennaio 2022 potranno essere reindirizzate verso il nuovo sistema di Gestione del Personale.

5.2 Requisiti di interfaccia vs sistemi esistenti

Possiamo suddividere in 4 classi diverse la tipologia dei dati da leggere:

1. Dati di tipo Anagrafico (Navision 2018)

2. Dati di tipo Dimensione di Analisi (Navision 2018)

3. Dati di tipo Consuntivo (Navision 2018, Sistema di Gestione del Personale).

4. Documentazione connessa (Sistema Documentale)

5.2.1 Breve nota sul workflow di creazione commesse.

Affinché Navision continui ad espletare le sue attività tipiche (registrazione di documenti del ciclo passivo e attivo) è necessario che l’anagrafica commesse continui ad essere presente in NAV insieme ad alcuni attributi e da alcune dimensioni non visibili direttamente dalla pagina di gestione della commessa, ma comunque ad essa associate.

Il processo di creazione di una nuova commessa prevede come primo atto la creazione di una PNI, creata nel nuovo sistema con le dimensioni opportune. Le informazioni relative alla PNI (attributi, dimensioni, costi) dovranno generare un report, onde facilitare il loro inserimento in Navision a livello di commessa.

Una volta approvata, sarà creata la commessa relativa in Navision 2018 e potrà essere letta dal nuovo sistema.

5.2.2 Dati da acquisire dai sistemi gestionali.

Di seguito i flussi di dati da acquisire, definiti solo come lista di oggetti senza la specifica degli attributi per singolo flusso.

Lista dati di tipo anagrafico:

• Commesse

• Progetti

• Programmi

• Voci merceologiche (Articoli)

• Voci di Budget

• Conti COGE

• Anagrafica Fornitori

• Anagrafica Clienti

• Anagrafica Dipendenti

• Anagrafica Unità Operative

• Anagrafica Centri di Costo Lista dati di tipo Dimensione:

• CDC

• Commessa

• PNI

• Progetto

• Programma

• RENDICONT ‐ Progetto

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

• RENDICONT ‐ Raggruppamento

• Tipo Cliente

• Tipo Commessa

• Tipo Finanziamento

• Cat. Reg. commessa Lista dati di tipo Consuntivo:

• Ore lavorate a commessa

• Costi trasferte a commessa

• Costo del Personale

• Richieste d’Acquisto (RDA)

• Ordini

• Benestare

• Fatture passive / attive

• Pagamenti

5.2.3 Modalità di gestione delle interfacce.

Le interfacce andranno solo in lettura verso i sistemi aziendali (Navision 2018, Sistema Gestione del Personale e Sistema Documentale).

I dati dovranno essere letti in modo diretto (accessi tramite appositi connettori) o basato su scambio file, in funzione del sistema da interfacciare.

Navision 2018 è installato presso il Cira, quindi i dati potranno essere acceduti tramite interfacce ODBC o webservices.

Il sistema di gestione del Personale è in Cloud. L’attuale sistema, One Service di ADP, prevede interfacce basate su scambio file. È in corso una procedura di appalto per l’acquisizione di un nuovo sistema, per cui potrebbe essere possibile utilizzare anche webservices.

Lo scambio dati sarà schedulato con periodicità: giornaliera, settimanale, mensile e on demand.

5.2.4 Nota sul sistema documentale in uso al CIRA

Il sistema documentale è stato realizzato sulla versione “On Premises” di SharePoint 2016 Enterprise. Il sistema gestisce Il protocollo centralizzato per tutte le principali tipologie documentali ed è utilizzato come archivio per gli allegati del sistema gestionale Navision. SharePoint espone un servizio REST (Representational State Transfer) per interagire in remoto con i dati del sistema documentale.

6. REQUISITI DELLA SOLUZIONE SAAS (SOFTWARE AS A SERVICE)

Al Fornitore e alla soluzione SaaS è richiesto il soddisfacimento sia di Requisiti di natura organizzativa che di Requisiti specifici come nel seguito dettagliati.

6.1 Requisiti organizzativi (RO)

Il Fornitore del servizio SaaS dovrà:

RO‐1 disporre di un servizio di supporto clienti al fine di garantire assistenza al CIRA, tramite telefono o canali telematici, su qualunque problema di natura operativa (anomalie, malfunzionamenti, pericoli per la sicurezza, ecc..) che dovesse presentarsi nell’utilizzo dei servizi;

RO‐2 assicurare la presa in carico e la gestione delle segnalazioni di malfunzionamenti da parte del CIRA nel rispetto delle tempistiche definite nella tabella degli SLA e dare piena visibilità dei processi di tracking e supporto;

RO‐3 informare tempestivamente il CIRA della disponibilità di informazioni circa i cambiamenti e le migliorie introdotti in seguito ad aggiornamenti delle modalità di funzionamento e fruizione dei servizi erogati.;

RO‐4 assicurare la disponibilità di manuali tecnici e guide d’uso (e/o altro materiale di supporto, se disponibili in lingua italiana);

RO‐5 rendere disponibile l’accesso a strumenti di monitoraggio e di logging, consentendo al CIRA di filtrare e limitare i risultati agli eventi di proprio interesse.

RO‐6 In caso di interventi di manutenzione che comportino l’indisponibilità (anche parziale) del servizio, il Fornitoreli comunica al CIRA con almeno 3 giorni lavorativi di anticipo utilizzando un canale di comunicazione diretto.

6.2 Requisiti specifici

I requisiti specifici richiesti riguardano le seguenti tematiche:

• sicurezza;

• performance e scalabilità;

• interoperabilità e portabilità;

• conformità legislativa.

6.3 Sicurezza (RS)

Il Fornitore del servizio SaaS, oltre a dotarsi di una adeguata organizzazione e di procedure operative in grado di gestire attività continue e documentabili di aggiornamenti e migliorie in tema di sicurezza al fine di gestire tempestivamente anche eventuali situazioni emergenziali, deve:

RS‐1 dichiarare che le componenti software che costituiscono il servizio SaaS offerto sono state sottoposte ai test OWASP o equivalenti con esito positivo;

RS‐2 essere in possesso della certificazione secondo lo standard ISO/IEC 27001. La certificazione deve essere stata rilasciata da organismi nazionali di accreditamento riconosciuti dalla Unione Europea. In alternativa, il Fornitore può effettuare il CSA STAR Self‐Assessment2 con riferimento al servizio che intende qualificare (nella versione denominata CAIQ), producendo la relativa documentazione resa pubblicamente consultabile sul proprio sito Web.

6.4 Performance e scalabilità (RPS)

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

Relativamente ai requisiti di performance e scalabilità, il Fornitore del servizio SaaS oltre a dichiarare la qualità e l’affidabilità del servizio offerto deve:

RPS‐1 indicare la performance del servizio utilizzando parametri tecnici oggettivi e misurabili, sfruttando ove possibile, gli indicatori (SLI) definiti nella direttiva ISO/IEC 19086‐1:2016;

RPS‐2 dichiarare che i servizi offerti sono soggetti ad opportuni processi di gestione della continuità operativa (business continuity) in cui sono previste azioni orientate al ripristino dell’operatività del servizio e dei dati da esso gestiti al verificarsi di eventi catastrofici e imprevisti (disaster recovery)

RPS‐3 indicare le condizioni e i tempi di attivazione delle risorse aggiuntive per sopportare i maggiori carichi qualora i servizi SaaS prevedano la scalabilità automatica;

In merito alle performance il Fornitore sarà tenuto, inoltre, a produrre ed inviare al CIRA, con cadenza mensile, un report periodico con il riepilogo dell’andamento dei livelli di servizio (SLA), definiti nel presente capitolato tecnico, nel periodo considerato (un mese) evidenziando gli eventuali scostamenti rispetto al “Livello di Servizio Richiesto“ negli SLA e le conseguenti penali compensative maturate.

6.5 Interoperabilità e portabilità (RIP)

I servizi devono consentire l’interoperabilità dei sistemi informativi fra gli altri applicativi in uso presso il CIRA. A tal fine devono esporre opportune Application Programming Interface (API).

Tali API dovranno rifarsi alle migliori pratiche di gestione (API management), prevedendo in particolare la tracciabilità delle versioni disponibili, la tracciabilità delle richieste ricevute ed evase, la documentazione degli endpoint SOAP e/o REST disponibili e delle rispettive modalità di invocazione.

Inoltre, il Fornitore del servizio SaaS deve:

RIP‐1 assicurare che il servizio SaaS espone opportune Application Programming Interface (API) di tipo SOAP e/o REST associate alle funzionalità applicative, di gestione e configurazione del servizio;

RIP‐2 garantire al CIRA la possibilità di estrarre in qualsiasi momento una copia completa di dati, metadati e documenti memorizzati dal servizio SaaS in formati pubblici e aperti;

RIP‐3 dettagliare le procedure per garantire la reversibilità del servizio SaaS in previsione della cessazione del rapporto contrattuale con il CIRA e la eventuale migrazione del CIRA stesso verso altro fornitore XxxX a garanzia del recupero di tutti i propri dati memorizzati nel servizio che, in ogni caso, andranno eleminati permanentemente una volta terminata la migrazione;

RIP‐4 garantire che i servizi Saas offerti dovranno consentire:

✓ l’accesso a tutti gli utenti registrati nel dominio AD CIRA e ad almeno 35 accessi contemporanei;

✓ la profilazione di ogni utenza per l’accesso ai dati per cui è abilitata;

✓ l’autenticazione per utilizzare funzionalità SSO grazie alla possibilità di integrazione diretta con i sistemi di autenticazione CIRA basato su dominio Active Directory;

✓ eventualmente l'uso dell'autenticazione a due fattori.

RIP‐5 garantire che i servizi Saas offerti devono essere interamente WEB‐BASED e responsive con accesso attraverso web browser mediante una interfaccia full web, ovvero basata sull’utilizzo di HTML5, CSS e Javascript senza prevedere lo scaricamento in locale sul client di ambienti di

runtime esterni. L’accesso dovrà avvenire esclusivamente attraverso il protocollo HTTPS;

RIP‐6 garantire che i servizi Saas offerti forniscano una serie di connettori per integrare facilmente diverse origini dati;

RIP‐7 garantire che i servizi Saas offerti forniscano funzionalità di gestione amministrativa dell’applicazione che consentano di gestire l’ambiente Cloud in modo completo: monitorare il consumo di risorse; pianificare e gestire attività amministrative, attivare l'importazione di dati e le procedure batch; conservare, archiviare ed eliminare i backup dei dati; attivare la connessione alle origini dati; gestire il registro degli eventi.

ed inoltre, i browser da supportare dovranno essere almeno i seguenti: Microsoft edge, Google Chrome, Safari e Firefox.

6.6 Conformità legislative Sicurezza e Privacy (RCL)

Il servizio SaaS deve rispettate le norme vigenti riguardanti la sicurezza e la riservatezza dei dati.

Per consentire al CIRA di venire a conoscenza e valutare potenziali incompatibilità o restrizioni legislative, il Fornitore SaaS deve rendere noti gli eventuali Stati esteri in cui sono dislocati i data center, propri e/o dell’infrastruttura Cloud utilizzata, e tramite i quali verrà erogato anche parzialmente il servizio e/o all’interno dei quali transiteranno anche temporaneamente i dati gestiti dal servizio.

In particolare il Fornitore del SaaS deve:

RCL‐1 specificare per quali aspetti il servizio SaaS è conforme agli obblighi e agli adempimenti previsti dalla normativa europea e italiana in materia di protezione dei dati personali.

RCL‐2 il fornitore, in veste di Responsabile del Trattamento, in conformità all’articolo 28 del GDPR (Regolamento Europeo 679/2016), dovrà condividere con il CIRA (titolare del trattamento) apposite clausole contrattuali. Tali clausole saranno condivise e controfirmate contestualmente alla firma del contratto. Allo scopo il fornitore su specifica richiesta del CIRA dovrà fornire idonee garanzie di rispetto del GDPR e dovrà rendersi disponibile a verifiche da parte del Titolare (audit) durante l’esecuzione del contratto e senza costi aggiuntivi per il CIRA.

RCL‐3 rispettare i principi di privacy by design e privacy by default indicati dal GDPR nell’analisi dei requisiti e per lo sviluppo del software.

RCL‐4 rendere nota la localizzazione dei data center propri e dell’infrastruttura Cloud utilizzata per erogare anche parzialmente il servizio e/o all’interno dei quali transitano anche temporaneamente i dati gestiti dal servizio (ivi compresi i siti di disaster recovery e di backup), specificando quando la localizzazione sia all’interno del territorio nazionale, all’interno della UE o extra UE.

RCL‐5 in caso di localizzazione dei data center in territorio extra UE, il fornitore deve dimostrare l’esistenza di valide decisioni di adeguatezza, o norme vincolanti d’impresa, o clausole contrattuali standard volte alla salvaguardia dei dati elaborati, conservati ed a vario titolo gestiti per erogare il servizio.

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

6.7 Modalità e tempistica di erogazione della manutenzione e dell’assistenza tecnica

Di seguito si riportano le modalità e le tempistiche di erogazione dell’assistenza tecnica e degli interventi di manutenzione.

✓ Gli interventi tecnici di manutenzione preventiva e tutti quelli che richiedono un “fermo programmato” (es. aggiornamenti, adeguamenti, ecc..) dell’Applicazione, dovranno essere effettuati nei giorni e con gli orari esplicitamente concordati con CIRA;

✓ le attività di manutenzione ordinaria e per la risoluzione di malfunzionamenti non bloccanti dovranno essere sempre preventivamente pianificati con CIRA, nel rispetto dei tempi di intervento e ripristino, al fine di rendere minimo l’eventuale disservizio che da esse possa derivare;

✓ il servizio supporto clienti come definito alrequisite RO1 dovrà essere garantito tutti i giorni lavorativi dell’anno dalle ore 9:00 alle 18:00.

6.8 Altre raccomandazioni di carattere generale

Backup Interval ‐ Il tempo che intercorre tra un backup e l’altro.	24 ore solari
Retention period of backup data ‐ Il periodo di tempo in cui vengono mantenuti i backup da parte del Fornitore.	1 anno
Backup restoration testing ‐ Il numero di test di restore (a partire dai dati di backup) eseguiti durante un determinato periodo di tempo.	1 ogni 12 mesi
Recovery Point Objective ‐ L’intervallo massimo di tempo che precede un “evento catastrofico” rispetto al quale si può verificare la perdita delle modifiche ai dati come conseguenza delle attività di ripristino del servizio (disaster recovery).	48 ore solari
Limit of Simultaneous Cloud Service Connections ‐ Numero massimo di connessioni simultanee supportate dal servizio.	35

7. MODALITÀ DI ESECUZIONE

Partendo dai requisiti funzionali e di interfaccia esposti nel presente capitolato, dalla proposta progettuale e dalle soluzioni tecnologiche offerte in sede di gara, l’assuntore del servizio dovrà prevede le seguenti fasi:

• Analisi Funzionale e Tecnica

• Sviluppo di una Versione β e testing

• Collaudo e Validazione

• Rilascio della Versione Finale 1.0 con relativo User Manual

• Addestramento del personale CIRA in modalità e‐learning

• Assistenza post consegna

Ogni fase si chiuderà con una revisione della documentazione e, se ritenuta conforme alla specifica, sarà autorizzato il relativo evento di fatturazione.

Analisi

Funzionale

Versione β

Collaudo

Versione Finale

Corso e‐learning

7.1 Durata del progetto

Figura 6 – Fasi di Progetto

Il contratto spiegherà i suoi effetti dalla data della sua sottoscrizione “Data inizio attività”. Le fasi di sviluppo, collaudo, addestramento, avranno la durata di 11 mesi, secondo la pianificazione di seguito riportata, in cui si ipotizza un Kick‐off il 1 novembre 2021.

Figura 7 – Planning di progetto

La fase di manutenzione evolutiva e correttiva, descritta nel § 7.7, sarà avviata solo a valle della consegna ed accettazione da parte del CIRA del sistema (Acceptance Review) ed avrà durata di 17 mesi.

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

7.2 Analisi Funzionale e Tecnica

Nell’ambito di questa prima fase saranno analizzati i requisiti cliente e definite le funzionalità, che il nuovo prodotto deve offrire. Inoltre, sarà sviluppata l’architettura del software, il flow down dei requisiti, le interfacce ed un piano di test per la fase di collaudo e validazione.

Input

• Requisiti utente e di interfaccia dal cliente

Output

Deliverables:

• Specifica Tecnica e requisiti di dettaglio

• Studio Architetturale e di integrazione di sistema

• Piano di Test (funzionale e di performance)

Milestone CR (T0 – T0 + 2 mesi): Progetto architetturale

7.3 Sviluppo di una Versione β

A valle dello studio architetturale saranno sviluppati gli algoritmi di dettaglio, emessa una versione del software non definitiva, ma già testata dal team CIRA su una piattaforma di test, che messa a disposizione di un numero ristretto di utenti permetterà di verificare preliminarmente le funzionalità del sistema, eliminando eventuali “bug”, e di ottimizzare l’implementazione dei workflow specifici. Inoltre, questa versione servirà al fornitore ed al team CIRA per verificare interfacce e trasferimento dati con i sistemi esistenti al CIRA.

Input

da fase precedente

Output

Deliverables:

• Progetto di Dettaglio

• Test Report (incluso verifica interfacce reali) Prodotti:

• Piattaforma di Test

• Versione Beta

Milestone DDR (T0 + 7 mesi): Progetto di dettaglio, rilascio versione beta

7.4 Versione 1.0 (Validazione e Collaudo)

La fase di verifica e di validazione servirà ad accertare che il sistema risponda pienamente ai requisiti di partenza nella maniera dovuta. La verifica sarà effettuata attraverso il collaudo dello stesso sistema con test cases, definiti nell’analisi condotta nella fase iniziale insieme al team CIRA, come descritto in § 7.2.

In questa fase, a partire dalla versione beta del sistema, l’assuntore implementerà tutte le modifiche necessarie per risolvere le non conformità emerse nella fase di testing precedente e rendere il sistema pienamente rispondente ai requisiti di partenza per la validazione ed il collaudo definitivo.

Contestualmente al rilascio in test, l’assuntore nominerà un responsabile del collaudo e ne darà comunicazione al CIRA, consegnando anche la proposta di piano di dettaglio del collaudo. Il piano di collaudo indicherà anche:

• sottosistemi o moduli o componenti sottoposti a verifica;

• data ed eventuale revisione (ripetizione) del collaudo (nel caso sia una successiva iterazione a seguito di aggiustamenti di malfunzionamenti rilevati in sede di precedente operazione di collaudo);

• matrice di compliance ai requisiti CIRA ed ai criteri di accettazione e parametri per il controllo della qualità del software;

• criteri di gestione dei malfunzionamenti (correzione di errori, non aderenza ai requisiti);

• piano dei test previsti (funzionalità, affidabilità, efficienza, usabilità, prestazioni ecc.).

Gli scenari di test rifletteranno vari tipi di azioni che gli utenti possono eseguire sul sistema e dovranno inoltre verificare che la latenza delle pagine sia mantenuta al di sotto dei 5 [sec]. Per valori superiori il Fornitore dovrà eseguire attività di tuning per poter garantire almeno le soglie richieste dal CIRA.

Il responsabile del collaudo dovrà coordinare le attività necessarie per l'effettuazione di dette operazioni e dovrà essere presente all'esecuzione delle prove.

Il collaudo sarà effettuato secondo i seguenti passi procedurali:

• revisione congiunta del piano di collaudo proposto dal Fornitore, eventuali integrazioni/modifiche ed approvazione finale da parte CIRA;

• individuazione, per tutte le parti coinvolte, delle risorse umane da rendere disponibili per la sessione di collaudo;

• predisposizione dell'ambiente di test atti a dimostrare le funzionalità e le prestazioni del Sistema.

• esecuzione delle prove di verifica come previsto dal piano di collaudo condiviso, per verificare la rispondenza della fornitura alle specifiche progettuali ed al Contratto stipulato;

• redazione del verbale di collaudo riportante l'esito finale.

Gli esiti del collaudo, comunque, non esonerano l’assuntore da responsabilità per difetti o imperfezioni che non siano emersi durante le operazioni relative, ma che siano accertati successivamente.

Nel caso in cui le funzionalità applicative non risultino conformi ai requisiti, l’assuntore apporterà le necessarie modifiche entro i successivi 5 gg lavorativi.

Input

• Piano di test di collaudo e validazione

• CV del responsabile del collaudo

Output

Deliverables:

• Procedure di collaudo

• Test Report

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3

Milestone TRR (T0 + 8,5 mesi): Test Readiness Review

7.5 Commissioning e rilascio versione finale 1.0

Rappresenta l’accettazione del prodotto finale, del manuale d’uso e del rapporto di collaudo.

L’accettazione finale sarà preceduta da un’attività di Commissioning svolta dal CIRA, a valle della consegna del sistema, della manualistica e del rapporto di collaudo.

Documentazione da produrre: Progetto di Dettaglio (revisionato); Manuale d’uso Prodotti: Versione 1.0

Milestone AR ‐ Acceptance Review ‐ (T0 + 9 mesi): accettazione finale

7.6 Corso (addestramento)

Sarà organizzato un corso di addestramento anche in modalità e‐learning e on‐demand (interattivo), che affiancherà il manuale d’uso. I corsi dovranno essere organizzati per 3 tipi di utenti: 1 rivolto agli amministratori di sistema, 1 rivolto agli utenti delle unità centrali, 1 rivolto ai PM e Segreterie Tecniche delle aree produttive.

Prodotto: Corso

Durata: T0 + 9 mesi – T0 + 11 mesi

7.7 Assistenza post vendita

A valle del rilascio del prodotto, è previsto un periodo di 17 mesi di servizio per la manutenzione correttiva ed evolutiva del sistema.

Per manutenzione correttiva si intende la diagnosi e la rimozione delle cause di malfunzionamenti e cali di prestazioni nelle procedure, nei programmi in esercizio, nelle basi dati e nelle interfacce nonché la diagnosi e la rimozione degli eventuali effetti di detti malfunzionamenti. Tali attività dovranno essere garantite per tutte le componenti infrastrutturali prese in carico.

La manutenzione correttiva dovrà essere assicurata entro 5 giorni lavorativi dalla richiesta CIRA anche per gli eventuali malfunzionamenti su applicazioni e procedure collaudate positivamente.

Per manutenzione evolutiva si indicano le ulteriori prestazioni che il CIRA riterrà opportuno chiedere al Fornitore al fine di sviluppare nuove funzioni e/o le eventuali revisioni grafiche per i miglioramenti dell’usabilità.

La manutenzione evolutiva sarà riconosciuta ad evento per le attività di:

• analisi dei requisiti

• implementazione, e documentazione delle nuove funzionalità

Le attività evolutive dovranno essere gestite fornendo, in anticipo sulla formalizzazione dei requisiti, un supporto per la pre‐analisi dei nuovi requisiti da iniziarsi entro 5 giorni lavorativi dalla richiesta CIRA.

Il Fornitore dovrà produrre, per ogni richiesta, entro 10 giorni lavorativi, una stima tecnica ed economica strutturata come segue:

• stima tecnica: dovrà contenere gli aspetti tecnici dei servizi offerti:

o requisiti di sistema: funzionalità e servizi che verranno implementati;

o piano delle attività;

• stima economica: dovrà indicare una stima economica specificando le ore di lavoro necessarie, comprese le prestazioni della fase di pre‐analisi.

CIRA valuterà la stima e potrà chiedere revisioni, approvare o respingere quanto proposto. A seguito dell'approvazione, l'intervento verrà realizzato come da piano delle attività concordato. Per le offerte respinte: le attività di pre‐analisi e di formulazione dell’offerta sono da intendersi senza costi e obblighi per il CIRA.

Per ogni attività concordata sarà stabilita una data massima entro la quale le funzioni richieste dovranno essere disponibili all’uso (in esercizio). Oltre tale data, a seguito di ritardi esclusivamente imputabili al fornitore, saranno applicate le penali stabilite al contratto base.

8. SERVICE LEVEL AGREEMENT E PENALI

Fatta salva l'ipotesi di forza maggiore, nel caso di mancato rispetto dei livelli di servizio richiesti di cui alla tabella seguente, il CIRA potrà applicare al Fornitore le penali indicate, salvo il diritto al risarcimento del maggior danno.

In caso di mancato rispetto dei termini di esecuzione dei servizi, potrà essere applicata una penale a carico dell’Aggiudicatario inadempiente, previa contestazione formale a mezzo PEC, con la quale la ditta inadempiente potrà essere anche sospesa immediatamente dalla iscrizione all'Albo dei Fornitori di beni e servizi del CIRA.

La ditta, con apposita comunicazione, sarà invitata a fornire spiegazioni e giustificazioni entro un termine di 5 (cinque) giorni decorrenti dal ricevimento della comunicazione. Il CIRA, esaminate le controdeduzioni, può revocare, modificare o confermare la contestazione iniziale.

Se entro il suddetto termine non saranno pervenute motivate e comprovate giustificazioni, alla ditta inadempiente verranno applicate le penali sottoindicate.

Per anomalie si intendono sia quelle applicative che quelle determinate da problemi sistemistici o di configurazione.

Nella tabella di seguito si riportano gli indicatori scelti per la valutazione del livello di servizio richiesto, il livello minimo da rispettare e il valore della penale qualora tale livello minimo non sia rispettato.

Indicatore Livello di Servizio

Offerta Ambito del Servizio

Livello di Servizio Richiesto

Valore Penale

Rispetto dei tempi di attivazione pattuiti all’atto della sottomissione dell’incarico

Piano Attività ed installazione della versione Beta e 1.0 del contratto base e manutenzioni evolutive concordate

100% degli obiettivi stabiliti nel piano di attività

0,1% dell’intero valore contrattuale per ogni giorno solare di ritardo dalla data prevista di messa in produzione del

modulo previsto

CAPITOLATO SISTEMA DI PIANIFICAZIONE E CONTROLLO

CIRA‐DTS‐21‐1291 ‐ rev. 3 In questa ulteriore tabella sono rappresentati i livelli di servizio richiesti dal momento in cui il sistema entrerà in produzione (§ 7.5)

Indicatore Livello di Servizio	Offerta Ambito del Servizio	Livello di Servizio Richiesto	Valore Penale
Availability ‐ La percentuale di tempo in un dato periodo di riferimento in cui il servizio risulta essere accessibile e usabile. Quale periodo di riferimento si assume convenzionalmente il mese. Il tempo totale del periodo di riferimento, che funge da base di calcolo del dato percentuale, può tenere conto dei fermi programmati del servizio.	Generale	> 95%	1% del valore contrattuale dopo il golive del Sistema (§ 7.5)
Maximum First Support Response Time ‐ Il tempo massimo che intercorre tra la segnalazione di un inconveniente da parte del CIRA e la risposta iniziale alla segnalazione da parte del Fornitore.	Generale	4 ore	100 Euro
Maximum Time to Service Recovery ‐ Il massimo tempo che intercorre tra l’indisponibilità del servizio dovuta a malfunzionamento di una delle sue componenti e il ripristino della sua normale operatività.	Generale	36 ore solari	1% del valore contrattuale dopo il golive del Sistema (§ 7.5)
Recovery Time Objective ‐ Il tempo massimo necessario a ripristinare completamente il servizio dopo un’interruzione dovuta ad un “evento catastrofico” che ha innescato l’attivazione di un ambiente di erogazione secondario (disaster recovery).	Generale	48 ore solari	1% del valore contrattuale dopo il golive del Sistema (§ 7.5)
Tempi di soluzione di anomalie riscontrate in fase di manutenzione	Manutenzione correttiva	100% entro le tempistiche concesse da CIRA	0,1% dell’intero valore contrattuale per ogni giornata lavorativa di ritardo sul valore del canone

Le penali possono trovare applicazione in concorso tra loro. In caso di recidiva, il CIRA può applicare le penali per importo doppio. Si considera recidiva un evento che avvenga entro 30 (trenta) giorni dal precedente evento che abbia comportato l’applicazione della stessa penale.

L’importo complessivo delle penali non può superare il 10% dell’importo netto contrattuale dell’appalto. L’applicazione della penale non solleva l’Appaltatore dalle responsabilità che si è assunto con la stipula del contratto e di quelle che dovessero derivare dall’incuria e dall’inadempienza dello stesso.

In caso di inadempienze per inosservanza di leggi e regolamenti per le quali sia prevista l’irrogazione di specifica sanzione amministrativa, l’applicazione della stessa non assorbe l’applicazione delle penali contrattuali che verranno irrogate e riscosse in modo autonomo.

È ammessa, su motivata richiesta dell’Appaltatore, la totale o parziale disapplicazione della penale quando si riconosca che l’inadempimento degli obblighi contrattuali non è imputabile allo stesso.

9. Attività di fine contratto

A fine contratto l’assuntore dovrà consegnare al Cira la base dati ed il SW sviluppato, in modo che sia attuabile quanto specificato nel § 2. Il formato dei file dovrà essere compatibile con la piattaforma adottata in modo da consentire l’import dei dati e del SW ad un eventuale nuovo assuntore di futuri contratti di manutenzione.

APPENDICE 1 – REQUISITI ALTO LIVELLO

Il prodotto finale dovrà implementare i requisiti di alto livello che sono raggruppati in requisiti funzionali e non funzionali come segue:

Requisiti Funzionali (FUN_XXX): descrivono le funzionalità del sistema in termini di workflow, gestione dati ed elaborazioni che il prodotto dovrebbe eseguire.

Requisiti Non Funzionali (NFU_XXX): descrivono le proprietà che devono essere soddisfatte, ad esempio requisiti di prodotto (piattaforma), organizzativi, esterni (es. interoperabilità).

Partendo da questo set di requisiti, all’avvio delle attività sarà condotta un’analisi congiunta per una più puntale definizione e classificazione. Successivamente, il fornitore nell’ambito dello studio iniziale, dovrà eseguire i seguenti step logici prima di entrare nella fase di sviluppo:

• Analisi delle esigenze – comprendere attraverso interviste le esigenze del cliente e mappare i requisiti di alto livello da cui scaturiranno i requisiti di sviluppo dei moduli software.

• Pianificazione della gestione dei requisiti ‐ sviluppo di un piano di sviluppo del progetto per scegliere l'approccio migliore rispettando il seguente ciclo di vita dei requisiti: tracciare; mantenere; verificare.

• Monitoraggio e controllo dei requisiti ‐ continuamente tracciare, monitorare e controllare i requisiti approvati per garantire la gestione delle richieste di modifiche.

• Valutazione della soluzione architetturale ‐ attività di verifica dei risultati dell'implementazione nel rispetto dei requisiti.

Di seguito si riportano le tabelle di sintesi dei requisiti di alto livello, Funzionali e Non Funzionali, che saranno esplicitati in dettaglio un documento di requisiti che sarà fornito all’avvio delle attività.

Rif.

Id. Requisito

Descrizione

Versione

Beta

Versione

Finale

Requisiti Funzionali

FUN_001

Il sistema dovrà assicurare le funzionalità relative a processi di pianificazione e programmazione operativa delle risorse.

• I dati di pianificazione dovranno essere inseriti e aggiornati per ciascun progetto/commessa/PNI a vita intera per voce di budget:

‐ Manpower;

‐ Ore impianto;

‐ Materiali;

‐ Prestazioni;

‐ Altri Costi;

‐ Immobilizzazioni;

‐ Trasferte.

• I dati di Manpower verranno inseriti per centro di costo con le date di inizio e fine competenza (solitamente annuale) per tutta la durata del progetto.

• Le Ore impianto saranno inserite a seconda dell’impianto utilizzato.

• I dati relativi a tutti i costi “esterni” (trasferte incluse) dovranno, invece, tenere conto delle date di competenza realmente attribuibili alla singola

Prestazione, al singolo acquisto di materiali/forniture, alle presunte date in cui si prevede di andare in trasferta e alla distribuzione in quote del valore dei beni ammortizzabili (HW/SW).

• La valorizzazione dei dati di Manpower verrà effettuata automaticamente in funzione dei valori di costo diretto e tasso ammissibile (per i ricavi) in funzione della tipologia di finanziamento attribuita al progetto/commessa/PNI.

• La valorizzazione dei ricavi relativi ai costi esterni avverrà automaticamente sulla base di algoritmi specifici in funzione della tipologia di costo e quindi della regola di finanziamento ad esso associata per progetti/commesse/PNI a rendicontazione. Mentre per progetti/commesse/PNI a corpo la valorizzazione dei ricavi avverrà con la metodologia cost to cost.

• I dati di costo diretto e tasso ammissibile (per le ore uomo e impianto) verranno forniti, periodicamente, e con aggiornamento semestrale da parte dell’ufficio del Personale per le ore uomo e da parte dell’ufficio Impianti per le ore impianto.

•

FUN_002

Il sistema dovrà assicurare anche le seguenti funzionalità di Project Management:

• Strumenti per la pianificazione di progetto (WBS, OBS, Gantt, pianificazione risorse) e delle relative commesse (quali aggregati di WP/Tasks).

• Rappresentazione di diagrammi di Gantt, prevedendo l’inserimento di milestones e deliverable per il controllo progetti.

• Inserimento di allerting su milestone o eventi di consuntivazione.

FUN_003

Il sistema dovrà assicurare le funzionalità relative a processi di controllo di gestione, elaborando e aggregando i dati per l’ottenimento di:

• conto economico scalare per natura, in cui i costi e i ricavi si suddividono in base alla causa economica (natura) del fattore che li ha originati;

• conto economico scalare per destinazione con evidenza dei vari stadi della formazione del risultato lordo di gestione caratteristica e l’utilizzo delle risorse sia interne che esterne all’azienda atte a modificare l’utile o la perdita d’esercizio.

Dovrà calcolare il costo standard orario di ogni Cdc ai fini della valorizzazione delle ore cedute da un centro di costo ad un altro. All’interno del report il costo standard

orario è calcolato come quoziente del totale dei costi primari e dei costi ricevuti rispetto al totale delle ore cedute ad altri cdc per interventi.

Relativamente ad ogni cdc dovrà coadiuvare il controllo di gestione nel controllo per margini, elaborando:

• report che sintetizzino le variazioni intervenute in ogni Cdc in termini di prezzo (differenza tra le unità d’opera a prezzi standard e le unità d’opera cedute a prezzi effettivi) e in termini di volume (differenza tra unità d’opera effettivamente cedute e cessioni previste a budget).

• Report di Analisi costi e performance per Cdc,

con la rilevazione dell’EBIT, MOL e EBITDA.

FUN_004

Il sistema dovrà assicurare analisi di scenari per

ottimizzare i conti economici previsionali:

• Elaborazione di conti economici previsionali per i piani aziendali, pluriennali e annuali, tramite rappresentazioni aggregate dei dati di pianificazione di progetto/commessa, in categorie funzionali alle decisioni direzionali.

• Strumenti di supporto alle analisi di scenari, nella fase di pianificazione strategica, per il raggiungimento di obiettivi strategici e di sostenibilità economico‐ finanziaria, attraverso macro‐indicatori quali il valore della produzione, il costo del lavoro, costi esterni di produzione.

• Bilanciamento delle risorse per ciascuna Unità Operativa e Cdc a vari livelli, analizzando gli scostamenti tra la necessità espressa da ciascuna unità operativa e da ciascun cdc, in termini di ore uomo, e la disponibilità della stessa per anno e per il triennio a venire.

• Forecast di periodo, tipicamente con aggiornamento mensile, sulla base dei report di consuntivo risultanti dal controllo di gestione.

FUN_005

L’avanzamento dei progetti/commesse deve essere calcolato con le tecniche dell’Earned Value

Rif.	Id. Requisito	Descrizione	Versione Beta	Versione Finale
Requisiti Non Funzionali	NFUN_001	La piattaforma dovrà interfacciarsi con i sistemi aziendali NAV 2018 e Gestione Personale per l’acquisizione dei dati		ϒ	ϒ
	NFUN_002	La piattaforma dovrà interfacciarsi con il sistema documentale aziendali per l’acquisizione dei documenti			ϒ
	NFUN_003	La piattaforma potrà essere utilizzata in contemporanea da almeno 35 utenze con differenti livelli di accesso: • Controller (lettura/scrittura): Unità Pianificazione e Controllo di Gestione, user per l’aggiornamento di tutti i progetti e le commesse CIRA e per l’elaborazione di report funzionali di progetto, di Conto Economico, di Unità e per CdC. • Project Manager e responsabili di commessa (lettura/scrittura), user per l’aggiornamento dei dati di pianificazione dei progetti/ commesse di propria responsabilità, poteri di firma nei flussi approvativi, elaborare report di Unità e di progetto/commessa. • Segreterie Tecniche (lettura/scrittura), user per aggiornare i dati di pianificazione dei progetti/commesse dell’unità a cui afferisce, inviare in approvazione commesse/progetti e PNI, elaborare report di Unità e di progetto/commessa dell’unità a cui afferisce • Top Management (lettura)			ϒ
	NFUN_004	L’interfaccia utente dovrà garantire un Dashboard di gestione di facile intuizione (suddividendo la schermata per tipologia di richiesta) Anagrafica Progetto • Codice progetto e commessa • Project Charter • Cliente e contratto • Data inizio e fine e revisione autorizzata • Redditività (attuale e stimata) • Stato del progetto • Ulteriori informazioni: PM, UO, Descrizione, Resp. WP, RUP, Partner e Contatti • Workflow di approvazione dei progetti e delle variazioni in corso d’opera, secondo le regole definite nella procedura vigente PLANNING MONITORING CONTROLLING • Attività di Progetto eseguite nel tempo • Per commessa, per WBS • Attività valutate, calcolate, pianificate (EV)		ϒ	ϒ

• Allocazione delle risorse sul progetto

• Suddivisione del carico di lavoro

(*in quest’area il PM potrà accedere ai link di modifica GANTT, deliverables, …/ogni modifica rispetto alla pianificazione di baseline richiede un’autorizzazione

BACHECA

• Promemoria (elenco dei TO‐DO)

• Bacheca condivisa con invio notifiche

• Storico delle riunioni

• Milestone e KIP (data e stato)

• SAL (data e stato)

• Documenti/Deliverable (link a Sistema Documentale

REPORT

• Report singolo o aggregato (con viste selezionabili)

• Forecast singolo o aggregato (sull’anno o vita intera)

Document Metadata

Table of Contents

TYPE TYPE DETAIL

Document Metadata