GARA PER LA

Il nuovo Sistema dovrà coprire le esigenze del Fondo e dei suoi uffici, sia per quanto riguarda l’operatività quotidiana che l’interazione tra i diversi soggetti individuati, garantendo a tutti gli utenti l’accesso alle informazioni secondo i ruoli ed i privilegi specifici e secondo quanto previsto e stabilito dal Fondo ed in ottemperanza con la legge 196/03 e successivi pareri espressi dal Garante della Privacy in materia di tutela e gestione dei dati personali ed in particolare dei cosiddetti dati sensibili.

Il Sistema dovrà essere aderente alle esigenze di gestione e mantenimento dei dati, tracciatura degli accessi e delle modifiche ad essi applicati e dovrà fungere da supporto alle decisioni.

Il Sistema dovrà inoltre essere in grado di produrre dati da trasmettere e importare e gestire dati ricevuti da altri sistemi informatici e quindi di adempiere gli obblighi di comunicazione dati che il Fondo ha verso i Ministeri ed enti preposti al monitoraggio dell’attività formativa finanziata.

Il Sistema dovrà essere aderente agli standard di usabilità e qualità di prodotto, e quindi possedere le caratteristiche di cui alle linee guida identificate dallo standard ISO 9241 ove applicabile.

Il Sistema dovrà interfacciarsi al meglio con il Portale FAPI per la gestione delle utenze e loro policy di accesso, come oltre indicato.

Il Sistema dovrà prevedere degli strumenti per la generazione di uno o più flussi di backup dei dati e relative funzioni di ripristino.

1.3 Finalità del documento

Questo documento contiene linee guida per la realizzazione di un nuovo Sistema Informatico per FAPI, destinato a sostituire quelli esistenti.

Quanto descritto all’interno di questo documento ha lo scopo di mettere in evidenza l’esigenza del Fondo e fornire indicazioni sul grado di complessità degli argomenti oggetto di fornitura. In nessun caso quanto riportato sostituisce il lavoro di analisi delle necessità e dei requisiti che l’Affidatario dovrà svolgere una volta assegnato l’appalto.

1.4 Caratteristiche della fornitura

Il bando prevede che il Fornitore rilasci i servizi e il software richiesto in due fasi successive, come descritto nel paragrafo “2 - Oggetto della gara” e in base a quanto ulteriormente specificato nei successivi paragrafi e specificatamente al paragrafo “5 – Attività oggetto della fornitura”.

Pertanto, la descrizione dei processi Fapi, fornita al paragrafo “4 - Processi da Automatizzare e Strumenti Infrastrutturali” va considerata come complessiva delle esigenze del FAPI per i quali si richiede un rilascio nelle due fasi suddette.

Al termine delle attività di sviluppo previste nella Fase 1, verrà effettuata un’accurata attività di review e analisi del deliverable. Qualora tale analisi dovesse superare i criteri di accettazione che verranno definiti in avvio della fornitura, il Fornitore verrà chiamato a svolgere le attività previste dalla Fase 2.

Per il dettaglio operativo della suddivisione riferirsi al Bando ed al Disciplinare di Gara.

1.5 Definizioni e convenzioni generali

Termine	Definizione
Committente	Il Fondo Formazione per la Piccola e Media Impresa FAPI
Fondo	Il Fondo Formazione per la Piccola e Media Impresa FAPI
Fornitore	Colui che dovrà realizzare / fornire il Sistema Informatico
Sistema Informatico (o Sistema)	Insieme di strumenti informatici per la gestione dell’Informazione all’interno del Fondo
Avviso/avvisi	Bando tramite il quale il Fondo annuncia la disponibilità di fondi per la formazione e che può definire regole di gestione specifiche collegate al Manuale di gestione
Manuale di gestione	Documento prodotto da FAPI che contiene le linee guida generali e comuni tra tutti gli Avvisi.
Attuatore	Ente di formazione o azienda che richiede il finanziamento di uno o più Piani formativi per se stessa o per una o più Aziende Beneficiarie. E’ il soggetto che, una volta approvato il finanziamento, è responsabile dell’effettiva realizzazione dell’Attività Formativa.
Azienda beneficiaria	Azienda aderente a FAPI che beneficia di uno o più Piani formativi finanziati da FAPI o che si candida a beneficiarne
Lavoratore	Lavoratore dipendente aderente (tramite l’Azienda Beneficiaria) a FAPI
Fase di Presentazione	Fase nella quale l’Attuatore può presentare a FAPI la richiesta di finanziamento per i Piani di formazione
Fase di Valutazione	Fase nella quale il FAPI valuta ammissibilità e punteggi dei Piani presentati finalizzata alla costituzione delle Graduatorie dei Piani finanziati e no

	da approvare in Cda
Fase di Gestione	Fase nella quale un Attuatore svolge effettivamente l’attività di formazione per i Piani formativi finanziati da FAPI
Fase di Rendicontazione	Fase nella quale l’Attuatore, completato il Piano formativo, provvede a rendicontare le spese sostenute, divise per le voci di costo previste
Fase di Attuazione	Somma delle Fasi di Gestione e Rendicontazione
Progetto Formativo (o Progetto)	Attività Formativa che l’Attuatore si prefigge di realizzare per le Aziende Beneficiarie
Piano Formativo (o Piano)	“Contenitore” che include uno o più Progetti contenenti l’Attività formativa. I dati relativi ad un Piano sono la somma degli elementi caratteristici dei Progetti che lo compongono
Formulario	Strumento informativo predisposto da FAPI che permette all’Attuatore di presentare le richieste di finanziamento dei Piani Formativi.
Convenzione	Contratto tramite il quale è regolato il rapporto tra il Fondo e l’Attuatore per l’erogazione dei finanziamenti e lo svolgimento del Piano formativo finanziato da FAPI.
Strumento/Strumenti	Insieme di Procedure, Funzioni, Moduli, Interfacce, Programmi ed Applicazioni in grado di automatizzare le funzioni richieste
Delibera	Atto ufficiale emesso dal CdA. Per questioni di urgenza essa può essere sostituita da una Determina Presidenziale, che sarà comunque seguita da una Delibera nella prima riunione del CdA utile.
Utente	Persona che utilizza il Sistema
Utente Interno	Personale in organico al FAPI abilitato all’utilizzo del Sistema
Utente Esterno	Utente non in organico al FAPI abilitato all’utilizzo del Sistema (per esempio: Attuatore)

Tabella 1 – Definizioni

Per "Applicazione" o “Sistema” s’intende non solo l'insieme dei programmi eseguibili dall'elaboratore, ma anche eventuali programmi a corredo, accessori, componenti, parti, moduli, librerie, documenti, manuali ed in genere ogni altra parte necessaria alla regolare installazione, funzionamento e proficuo uso dell'applicazione da parte degli utenti sulle apparecchiature destinate a ospitarli.

Le Applicazioni, in particolare, sono qui considerate al pari di ogni altro bene strumentale in quanto, indipendentemente dal loro carattere di "immaterialità", sono prodotti finiti, scelti ed acquistati solo per la loro capacità di svolgere una qualche specifica funzione, dal cui esercizio il Fondo stesso si prefigge di ricavare una qualche propria utilità.

La possibilità di ottenere tali funzioni rappresenta lo scopo del Fondo nell'accedere alla presente fornitura, il cui vero oggetto è pertanto costituito dalle funzioni offerte e non da un mero insieme di programmi in quanto tali.

Per la descrizione compiuta della fornitura varranno pertanto le funzioni elencate nella documentazione presentata dal Fornitore a corredo dell'applicazione. Essendo stato il Fornitore libero ed autonomo nella scelta di quali funzioni includere o meno nella propria applicazione (a partire dal momento progettuale, fino a quelli realizzativo e commerciale) fatte salve le funzionalità minime specificate al paragrafo “5.2.1 - Requisiti Funzionali” del presente Capitolato. Sarà compito del Fornitore stesso fornire un Sistema che automatizzi quanto richiesto nel presente Capitolato, negli altri documenti a corredo e di quanto dichiarato nella documentazione d’offerta.

Saranno a carico del Fornitore tutte le eventuali ed ulteriori componenti hardware e software specializzate che non siano state espressamente indicate come tali nell'offerta tecnica e che dovessero rivelarsi indispensabili per assicurare le funzionalità della procedura a regime.

In caso contrario si procederà a un collaudo negativo del Sistema o di alcune sue parti, da sanare con le modalità previste al paragrafo “4.9 - Penali “ del Disciplinare di Gara.

Il Sistema deve essere in grado di gestire la complessità, le problematiche e quindi le esigenze di automazione proprie di un Fondo interprofessionale quale il FAPI con un sistema Informatico aziendale integrato al meglio per quanto sia permesso dall’attuale situazione tecnologica di mercato e relativamente alle specificità del Fondo FAPI.

La lingua utilizzata per tutte le comunicazioni ed i servizi di cui al presente capitolato è la lingua italiana, salvo l’impiego di acronimi e termini propri del campo informatico e correntemente utilizzati nella lingua originale, nonché nei casi particolari espressamente accettati dal Fondo.

1.6 Acronimi utilizzati all’interno del documento

Termine	Definizione
CdA	Consiglio di Amministrazione
ISFOL	Istituto per lo sviluppo della formazione professionale dei lavoratori
MAC	Manutenzione Adeguativa e Correttiva
MEV	Manutenzione Evolutiva
SC	Steering Committee
SPC	Servizi Professionali Correlati
SGR	Sistema Gestione Revisioni
SGD	Sistema Gestione Difetti
TT	Trouble Ticketing
SAL	Stato Avanzamento Lavori
SLA	Service Level Agreement
FAQ	Frequently Asked Question

Tabella 2 - Acronimi

2. Oggetto della gara

Oggetto del presente bando di gara è la fornitura ed installazione del Sistema per la gestione dell’attività del FAPI e per la gestione dell’iter degli avvisi per il finanziamento di piani di formazione e gli aspetti correlati.

La fornitura prevede 2 (due) Fasi distinte:

la Prima Fase prevede la realizzazione e predisposizione in esercizio del sistema di gestione delle Richieste di Finanziamento;

la Seconda Fase prevede l’integrazione funzionale del sistema realizzato durante la Prima Fase e l’erogazione di servizi aggiuntivi.

L’avvio delle attività previste nella Seconda Fase è condizionato dalla corretta esecuzione e collaudo di quanto previsto nella Prima Fase.

Il bando di gara comprende i prodotti ed i servizi di seguito elencati, che saranno forniti secondo le modalità specificate nel presente capitolato.

Fase 1

❑ Progettazione Esecutiva, Installazione e Configurazione delle infrastrutture e/o piattaforme software necessarie per il funzionamento del Sistema;

❑ Sviluppo e/o personalizzazione e/o configurazione delle componenti software e/o funzionalità necessarie alla realizzazione delle funzionalità del Sistema;

❑ Formazione degli Utenti Interni;

Fase 2

❑ Sviluppo e/o personalizzazione e/o configurazione delle componenti software e/o funzionalità necessarie alla realizzazione di ulteriori funzionalità del Sistema;

❑ Assistenza all’avviamento del Sistema;

❑ Help Desk Tecnico di secondo livello;

❑ Manutenzione del Sistema;

❑ Assistenza Sistemistica;

❑ Analisi dei dati pregressi dei sistemi in dismissione.

2.1 Fase 1

2.1.1 Progettazione Esecutiva, Installazione e configurazione delle infrastrutture/piattaforme software necessarie per il funzionamento del Sistema

Il presente bando consente al fornitore di proporre le infrastrutture/piattaforme software che ritiene più consone per la corretta implementazione di quanto richiesto.

Il fornitore sarà pienamente responsabile della corretta installazione e configurazione delle medesime, nonché della piena corrispondenza con i requisiti funzionali richiesti.

Tutte le attività di installazione e configurazione dovranno essere correttamente corredate da opportuna documentazione che consenta al personale del fornitore stesso, o di eventuali fornitori subentranti, di prenderne in carico la gestione senza necessità di periodi di affiancamento.

2.1.2 Sviluppo e/o personalizzazione e/o configurazione delle componenti software e/o funzionalità necessarie alla realizzazione delle funzionalità del Sistema

Il bando di gara prevede la fornitura di software applicativo per la gestione del ciclo di vita degli Avvisi, relativamente ai flussi elencati nel paragrafo “4 Processi da Automatizzare e Strumenti Infrastrutturali” il cui contenuto dà una visione di massima di quelle che sono le esigenze e dei processi che dovranno essere automatizzati, ma in alcun modo dovranno essere considerate sostitutive di una più approfondita analisi da svolgere in avvio dell’attività.

Le caratteristiche (generali, tecnologiche e funzionali) cui il software applicativo dovrà aderire sono specificate nel Paragrafo “5.2 – Software Solution“. Tale software, dovrà essere consegnato, correttamente configurato, e reso operativo a carico dello stesso Fornitore.

Fanno parte di quest’attività anche le attività di integrazione del nuovo software con i sistemi esterni indicati nel Paragrafo “4.2 - Processi di Controllo e Monitoraggio”.

Tutto il software applicativo sviluppato, nonché le basi dati utilizzate, dovrà essere correttamente corredato da opportuna documentazione che consenta a personale del fornitore stesso, o di eventuali fornitori subentranti, di prenderne in carico la gestione senza necessità di periodi di affiancamento.

La realizzazione dovrà essere coerente con i requisiti funzionali richiesti per la Fase 1 nella tabella del paragrafo “5.2.2 - Requisiti Funzionali”.

A livello di Processi questa attività della Fase 1 dovrà automatizzare tutti i processi previsti nel paragrafo “4 - Processi da automatizzare” con esclusione di quelli previsti per la Fase 2 al paragrafo “2.2.1 - Sviluppo e/o personalizzazione e/o configurazione delle componenti software e/o funzionalità necessarie alla realizzazione di ulteriori funzionalità del Sistema”.

2.1.3 Formazione degli utenti interni

L'appalto include la formazione degli Utenti Interni al Fondo, per tutte le tipologie di utenza per cui è prevista tale attività, con la realizzazione di una guida operativa utilizzabile online.

Le modalità di svolgimento dell'attività sono delineate nel Paragrafo “5.7 - Formazione del Personale Interno”.

Le specifiche della guida di utilizzo del sistema sono descritte nel Paragrafo “7.1 - Guida all’utilizzo del sistema”.

2.2 Fase 2

2.2.1 Sviluppo e/o personalizzazione e/o configurazione delle componenti software e/o funzionalità necessarie alla realizzazione di ulteriori funzionalità del Sistema

In questa attività è prevista l’integrazione delle funzionalità del sistema con i requisiti funzionali richiesti per la Fase 2 nella tabella del paragrafo “5.2.2 - Requisiti Funzionali”.

A livello di Processi questa attività della Fase 2 dovrà automatizzare i processi descritti ai paragrafi seguenti:

“4.2.5 – Business Intelligence/Controllo di Gestione”; “4.3 – Processi di Marketing”.

Tutti gli altri processi dovranno essere automatizzati nella Fase 1.

2.2.2 Assistenza all'Avvio del Sistema

L'appalto include un'attività di affiancamento di personale del Fornitore agli utenti del Fondo nella fase di avviamento del Sistema.

Una volta che il sistema realizzato e collaudato sia stato messo in esercizio, il Fornitore affiancherà il personale del Fapi nello svolgimento delle attività correnti al fine di facilitarne e velocizzarne il corretto utilizzo.

La durata del servizio è prevista in 2 (due mesi).

Il fornitore in offerta dovrà definire la struttura operativa, composta principalmente da personale tecnico/operativo di supporto, che metterà a disposizione del Fapi per svolgere tale attività.

2.2.3 Help Desk Tecnico di secondo livello per gli Utenti Fapi

L'appalto include la fornitura di un servizio di assistenza tecnica (sia telefonica che tramite altri canali di comunicazione) agli utenti Fapi per risolvere gli eventuali problemi tecnici che gli Utenti Esterni dovessero incontrare nell’utilizzo del Sistema.

Il servizio dovrà essere assicurato per tutti il periodo di vigenza del contratto.

Le modalità di svolgimento del servizio sono delineate nel Paragrafo “5.5 - Help Desk Tecnico“.

2.2.4 Manutenzione del Sistema

L'appalto include un'attività di manutenzione ordinaria e straordinaria del software applicativo, da svolgersi in maniera coordinata con le necessità del Fondo.

Tale manutenzione si differenzierà tra Manutenzione Adeguativa e Correttiva (MAC) e Manutenzione Evolutiva (MEV) come di seguito dettagliate.

Le modalità di svolgimento dell'attività sono delineate nel Paragrafo ”5.8 - Manutenzione”.

2.2.5 Assistenza Sistemistica

L'appalto include le attività necessarie alla gestione del Sistema per il mantenimento dell’operatività Sistema fino al termine del periodo contrattuale.

Le caratteristiche e i contenuti della fornitura sono delineati nel Paragrafo “5.6 - Assistenza Sistemistica”.

2.2.6 Analisi dati pregressi dai sistemi in dismissione

L’appalto prevede che il fornitore svolga le attività propedeutiche alla migrazione dei dati attualmente presenti sui precedenti sistemi di gestione del Fapi e/o archiviati nelle banche dati dell’Ente. Il fornitore dovrà procedere ad una prima analisi delle basi dati stesse, con l’obiettivo di fornire un quadro esauriente della situazione in essere. Il deliverable dovrà fornire:

- Un quadro chiaro della numerosità delle basi dati

- Un’analisi della consistenza del dato con particolare riferimento ad errori, mancanze e disallineamenti che potrebbero compromettere la migrazione/integrazione dei dati stessi verso il nuovo sistema

- Una descrizione delle possibili modalità di migrazione/integrazione e delle tempistiche necessarie

Le caratteristiche e i contenuti della fornitura sono descritti nel Paragrafo “5.9 - Analisi Dati dei Sistemi attualmente in uso”.

3. Contesto Attuale

3.1 Struttura Organizzativa del Fondo

Al fine di rendere evidente il livello della complessità organizzativa in cui dovrà operare il Sistema, il presente capitolo descrive la Struttura Organizzativa del Fondo.

Il Fondo è rappresentato da un Presidente ed un Vicepresidente.

Attualmente il Fondo ha diviso la propria operatività tra 5 uffici, più una segreteria condivisa tra essi.

La struttura attuale prevede i seguenti uffici:

❑ Direzione;

❑ Ufficio Formazione;

❑ Ufficio Organizzazione;

❑ Ufficio Amministrazione;

❑ Ufficio Marketing.

Ognuno di questi uffici svolge il proprio ruolo istituzionale in autonomia, secondo le rispettive responsabilità.

A questi Uffici si aggiungono:

❑ Nucleo di Valutazione, ovvero un organismo che opera in contatto con l’Ufficio Formazione il cui ruolo è valutare (sia nella completezza che nel merito) le proposte di Piani formativi candidate dagli Attuatori ad essere finanziate (totalmente od in parte, in relazione alla normativa vigente in relazione agli Aiuti di Stato ed alle Aziende Beneficiarie coinvolte) dal Fondo.

❑ Help Desk Normative, che ha il compito di aiutare gli Attuatori a compilare le proposte di Piani formativi. Svolge quindi un ruolo di assistenza alla compilazione NEL MERITO DELLE NORMATIVE e non di natura tecnica informatica. Tale servizio è usualmente svolto dagli stessi membri del Nucleo di Valutazione.

❑ Ispettori, hanno il compito di effettuare le visite ispettive in Itinere presso le sedi in cui si svolgono i corsi di formazione ed ex-post presso la sede dichiarata come tenutaria della documentazione. Il servizio di ispezione viene di volta in volta appaltato a società di consulenza esterna; pur operando in autonomia secondo quanto previsto dagli obblighi contrattuali, gli ispettori possono essere visti come Utenti Interni del Fondo operando in nome e per conto del Fondo stesso. Agiscono in contatto con l’Ufficio Organizzazione.

❑ Commissioni o gruppi di lavoro, eventualmente istituiti dal Fondo per l’analisi o lo studio di fabbisogni o risultati ottenuti dagli Avvisi.

❑ Presidenza, CDA e Assemblea

❑ Sindaci revisori.

❑ Articolazioni regionali

Questi utenti o gruppi di utenti hanno specifiche mansioni e responsabilità, ma normalmente non fanno capo a particolari uffici e hanno incarichi con una durata determinata nel tempo.

3.2 L’attuale sistema informatico del FAPI

3.2.1 Localizzazione

Le infrastrutture in termini di server, sistemi storage, apparati di telecomunicazione ed altri apparati di supporto, sia di proprietà del FAPI che di terzi fornitori di servizi per il FAPI, sono dislocate in un edificio a Settimo Milanese (MI) del fornitore X.XXX .

In particolare presso l'edificio di X.XXX, all'interno del data center, sono localizzati la maggior parte degli apparati informatici utilizzati dal FAPI per erogare la gran parte dei servizi IT interni ed esterni ed ospita anche i servizi nella loro fase di pre-esercizio.

Nella sede di Roma in Via del Gesù a Roma, presso la sede del FAPI, sono presenti delle applicazioni di contabilità e di servizi interni, con la relativa infrastruttura di minore rilevanza e capacità, con una connettività adibita alla fruizione di servizi intranet e dei servizi erogati tramite X.XXX.

Il portale aziendale pubblico è invece erogato attualmente e provvisoriamente attraverso il servizio internet di Wordpress attraverso la loro infrastruttura di riferimento.

3.2.2 Gestione

Il fornitore Almaviva gestisce la infrastruttura di produzione localizzata presso X.XXX , mentre X.XXX fornisce i servizi infrastrutturali (backup, networking, monitoring, sicurezza perimetrale, connettività, etc.), con un servizio di service management secondo le best practices ITIL che comprende i servizi di Service Desk,Incident management, Assistenza Eyes & Hands e Service Request management.

3.2.3 Architettura

L’architettura utilizzata dal sistema di produzione è quella organizzata a livelli (layer), ed è quella predominante nello sviluppo di applicazioni server-side. In tale architettura i componenti sono organizzati in livelli separati, ciascuno dei quali svolge un compito ben definito:

• presentation layer: è responsabile della visualizzazione della Graphical User Interface (GUI) e della gestione dell’input utente (passando le richieste al business logic layer);

• business logic layer: contiene tutta la logica dell’applicazione ovvero i processi che l’applicazione può eseguire, recupera e salva dati interagendo con il persistence layer;

• persistence layer: fornisce un’astrazione ad alto livello e object-oriented del database layer;

• database layer: consiste di un relational database management system.

3.2.4 Componenti principali

L’architettura dei sistemi FAPI prevede la virtualizzazione dei server, realizzando una movimentazione dinamica dei server logici in stile private cloud. L’infrastruttura elaborativa è

composta da server host fisici che ospitano server virtuali tramite l’infrastruttura VMware sui quali è installato e configurato il sistema operativo windows Server 2008 R2.

Il parco applicativo esistente, è quindi basato su architettura web n-tier con server web IIS versione

7.5 , con .NET Framework 3.51 e 4.0 e con data layer su RDBMS Microsoft SQL Server 2008 R2 .

3.2.5 Dimensionamento e numerosità dei dati

I database di corrente utilizzo, escludendo quelli storicizzati su precedenti sistemi informatici descritti successivamente, sono relativamente piccoli, bisogna considerare che sono presenti solo gli avvisi a partire dal 4-2012, alcuni ancora in fase iniziale.

Le tabelle sono quasi 300 ed altrettante sono le viste, la cui tabella successiva ne rappresenta una sintesi (Nota: i numeri riportati in tabella potrebbero essere differenti da quelli realmente riscontrabili nei DB al momento della esecuzione dell’appalto).

DB	DATA (KB)	Index Size (KB)
Fapi principale	113.552	7.800
Fapi streaming	544	112
Fapi staging	315.648	664
Reporting services	24.200	225
Totali per tipo	453.944	8.801
Totale	462.745

Di seguito si riportano a titolo puramente indicativo i database storicizzati su precedenti sistemi informatici e la numerosità delle informazioni trattate. Di seguito si riporta una sintesi della grandezza dei DB e delle tabelle presenti (Nota: i numeri riportati in tabella potrebbero essere differenti da quelli realmente riscontrabili nei DB al momento della esecuzione dell’appalto).

DB	DATA (KB)	N° Tabelle
FAPI2007A1	460.000	187
FAPIDEF	140.000	90
FAPIStorico	440.000	23
TOTALI	940.000	290

4. Processi da Automatizzare e Strumenti Infrastrutturali

Nel presente Capitolato non si descrivono nel dettaglio tutti i processi del Fondo. Questi costituiranno oggetto del progetto esecutivo del Fornitore e, come definito nell’ambito della struttura di governo del progetto, saranno costruiti sulla base dei seguenti elementi:

a. Documentazione fornita dal Fondo;

b. Indicazioni operative fornite dal Fondo stesso successivamente all’aggiudicazione, in fase di analisi dei requisiti funzionali;

c. Manuale di Gestione nelle sue versioni;

d. Avvisi per gli ambiti dei Piani a ciascuno relativi.

Sono oggetto del presente Capitolato tutti i processi che dovranno essere supportati dal Sistema software che si intende acquisire e comunque tutti quelli necessari all’operatività dei singoli uffici come dedotti dalle fonti di cui sopra e come approvati dalla struttura di governo del progetto di cui sopra.

Di seguito sono quindi riportati a titolo informativo ed in maniera sintetica e non esaustiva, i diversi processi che costituiscono il fulcro dell’attività del FAPI, con la relativa descrizione, fermo restando che nel tempo tali flussi possono subire variazioni per mantenere la compatibilità con quanto indicato nel Manuale di Gestione e nei vari Avvisi, nonché con la strutturazione interna del Fondo.

Per alcuni processi, quelli ritenuti più significativi, è anche indicato sommariamente il tipo di supporto operativo che i singoli Uffici si attendono dal Sistema; per i restanti se ne rimanda l’individuazione alla fase di definizione dei requisiti in sede di progettazione del Sistema.

Il Fornitore dovrà quindi verificare la situazione degli effettivi flussi da automatizzare al momento dell’inizio del proprio incarico e durante la fase di Raccolta dei Requisiti e dell’Analisi di dettaglio relativa.

4.1 Processi di Gestione Avvisi e Piani Finanziati

In questo paragrafo e nei successivi sottoparagrafi saranno brevemente descritti gli attuali processi relativi al ciclo di vita di un Avviso. I processi e le operazioni descritte sono d’importanza strategica per il Fondo.

Per una descrizione visuale di questi processi, si rimanda all’ALLEGATO A al Capitolato - DIAGRAMMI DI FLUSSO.

4.1.1 Preparazione Avvisi

Il Comitato di Direzione (CD), su indicazione delle Parti Sociali, definisce le caratteristiche di un nuovo Avviso sia riguardo la disponibilità di fondi da destinare, sia riguardo le caratteristiche delle attività formative finanziabili, approvato dal Consiglio di Amministrazione (CdA).

In coerenza con il Manuale di Gestione in vigore al momento, sono decise le caratteristiche del nuovo Avviso, gli eventuali Assi (o Misure) in cui si divide, le scadenze (ognuna dotata di una propria porzione del totale dei fondi a disposizione) ed il regolamento.

Ogni Avviso può avere un regolamento anche molto differente dai precedenti, con cui può condividere anche solo un limitato numero di informazioni.

Ogni Avviso può essere diverso dai precedenti sia come fondi a disposizione per l’erogazione di formazione, sia per la loro destinazione (generale, dedicato ad un particolare settore, dedicato ad una particolare categoria o tematica; interaziendale, aziendale o individuale), che come informazioni richieste (e relativi parametri di controllo), che come flusso: “a scadenza” (tutti i Piani devono essere presentati entro una precisa data), “a sportello” (i Piani vengono valutati ed eventualmente finanziati di volta in volta che vengono presentati tramite apposita delibera fino ad esaurimento dei fondi a disposizione).

Ogni Avviso può essere suddiviso in uno o più Assi (detti in passato anche Misure), ognuno con le proprie regole, i propri destinatari, le proprie informazioni richieste (e relativi parametri di controllo) e le proprie scadenze. All’interno dello stesso Avviso possono essere presenti Assi completamente diversi tra loro (per esempio un Avviso può contenere un Asse generalista, un Asse dedicato ad un particolare settore ed un terzo Asse dedicato ai Voucher, ovvero assegni di formazione personali).

Ogni Avviso ed ogni Asse hanno una precisa quantità di fondi a disposizione per la formazione, che possono essere divisi tra una o più scadenze e/o su base territoriale (con ogni regione od ogni Aggregazione di Regioni dotate di una propria quantità di fondi a disposizione). Ogni Avviso può avere una destinazione diversa e l’aggregazione di regioni (solitamente definita come “Macroregione”) può variare da Avviso ad Avviso.

Ogni Avviso, in caso di ricorsi o per decisione del CdA, può essere rifinanziato, sia in maniera puntuale (per finanziare i Piani per cui è stato accolto il ricorso), sia generale (nel caso in cui per esempio il CdA decida di destinare ulteriori fondi per un particolare Avviso o per uno o più Assi). Ogni finanziamento (e quindi ogni rifinanziamento) è deciso tramite Delibera del CdA, che dovrà essere riportata (assieme agli estremi di tale Delibera) all’interno delle convenzioni dei Piani Finanziati.

Ogni Avviso ha coerenza in relazione alla Versione del Manuale di Gestione in vigore in quel dato momento. Le modifiche del Manuale di Gestione non è recepita dagli Avvisi precedenti.

Possono essere previsti Avvisi per i quali, a seguito di specifici accordi, solo un determinato tipo di Soggetti selezionati dal Fondo possono presentare proposte di Attività Formative.

In sintesi la Preparazione di un Avviso prevede la definizione delle seguenti informazioni (l’elenco ha titolo esemplificativo e non esaustivo):

• Assi componenti;

• Budget totale e per asse;

• Tipologia di valutazione (a scadenza singola, a scadenza iterata, a sportello) che può essere differente per ogni asse;

• Tipologia di Piani ammessi a finanziamento definiti per Asse;

• Territori ammessi a finanziamento per asse e tipologia;

• Massimali di Piano (importo massimo finanziabile, numero di progetti per piani, numero di allievi per progetto, importo massimo per progetto, numero di ore di formazione, …)

• Tipologia di aziende beneficiarie (territorio, PMG azienda, …)

• Tipologia Attuatore/proponente (ente, azienda, dipendente)

• Tipologia di regime di aiuti ammesso;

• Scheda finanziaria e relative voci di costo;

• Criteri di ammissibilità e valutazione;

• Tempi di presentazione, ricorso, attuazione;

• Convenzioni;

• Polizze Fideiussorie;

• Documentazione da presentare/produrre/inviare in presentazione ed in attuazione;

• Punteggi di valutazione;

• Ecc.

Ognuno dei parametri definiti in questa fase ha ricadute sui controlli formali e sostanziali che vengono effettuati nelle successive fasi di:

presentazione; valutazione; attuazione; rendicontazione.

La redazione del regolamento dell’Avviso è eseguita dall’Ufficio Formazione.

4.1.2 Approvazione Avvisi e Pubblicazione Avvisi

Una volta stabilite le caratteristiche del nuovo Avviso (a cura del Comitato di Direzione, su indicazione delle Parti Sociali) e la redazione del bando dell’Avviso e relativo regolamento (a cura dell’Ufficio Formazione), la documentazione prodotta viene sottoposta al CdA per approvazione.

In caso di approvazione, tramite Delibera, sono stanziati i fondi ed approvato il testo dell’Avviso.

4.1.3 Pubblicazione Avvisi

Una volta approvato l’Avviso, il relativo Bando ed il regolamento, l’Ufficio Formazione provvede a trasferire il testo dell’Avviso, la Delibera e la prevista documentazione di corredo all’Ufficio Marketing che provvederà alla pubblicazione sul Portale Fapi dell’annuncio del nuovo Avviso, del relativo regolamento e di eventuali ulteriori documenti necessari all’Attuatore per la presentazione delle proprie Proposte di Formazione (Piani).

L’Ufficio Formazione procederà invece alla automazione dell’Avviso e una volta completata, procederà con l’abilitazione della Presentazione da parte degli Attuatori.

Caratteristiche del Sistema

Il Sistema dovrà supportare l’Ufficio Formazione nella creazione e la configurazione di un nuovo Avviso in maniera automatica ed autonoma fornendo tutti gli strumenti di parametrizzazione dei campi che andranno a costruire l’avviso.

Il Sistema, quindi, dovrà permettere di:

• definire le regole (assi, budget, destinatari, massimali, ecc.);

• rivolgere l’Avviso esclusivamente verso Enti di Formazione ed Aziende Beneficiarie oppure ai singoli lavoratori (voucher).

• definire tipologie diverse dei destinatari della formazione;

• definire più scadenze per uno stesso avviso o per un singolo Asse;

• predisporre i formulari di presentazione con le relativi parametri e controlli;

• permettere di importare i formulari di presentazione da un Avviso precedente;

• elaborare i testi dei documenti che dovranno essere disponibili per gli utenti attuatori (es. Convenzione, Fidejussione, Dichiarazione di partecipazione al piano, ecc.)

• Creare le schede di:

o Valutazione di completezza, ove Ufficio Formazione potrà predisporre una checklist contenente le informazioni su tutti gli elementi da verificare da parte del Nucleo di Valutazione affinché un Piano presentato sia da considerare completo;

o Valutazione di merito, ove Ufficio Formazione potrà predisporre una serie di criteri (ognuno dotato di un punteggio minimo e di uno massimo) per la valutazione del Piano;

o permettere di importare la griglia di valutazione (sia per la valutazione di completezza che quella di merito) da un Avviso precedente

Tutte le suddette informazioni dovranno essere modificabili, secondo le policy e le modalità che verranno fissate in sede di definizione dei requisiti, fino a quando l’Avviso non sia Approvato e Pubblicato. Dopo tale operazione il Sistema dovrà tenere traccia delle modifiche (e dell’autore della modifica) e richiedere di inserire le informazioni riguardanti l’eventuale Delibera che la autorizza.

Completata la compilazione dell’Avviso il Sistema dovrà consentire l’apertura della fase di Presentazione.

4.1.4 Presentazione Piani

Una volta reso disponibile il software per la presentazione dei Piani Formativi e aperta la procedura di presentazione, gli Attuatori possono inserire le proposte di Attività Formativa che intendono eseguire, e per cui si richiede il finanziamento da parte del Fondo. La percentuale di finanziamento ammissibile dipende dalla tipologia di formazione e dal regime di Aiuti di Stato delle Aziende Beneficiarie interessate dall’Attività.

L’Avviso può prevedere una o più scadenze per la presentazione dei Piani, oppure la valutazione “A Sportello”. Nel primo caso l’Attuatore può presentare piani entro una data ed orario prestabiliti. Tutti i Piani pervenuti saranno valutati dopo tale scadenza. Nel secondo caso ogni Piano viene valutato senza attendere una scadenza e, se tale operazione ha esito positivo, finanziato di volta in volta fino ad esaurimento dei fondi a disposizione.

Il formulario di presentazione dei piani deve essere aderente alle norme contenute nel Manuale di Gestione e dell’Avviso. In caso vi siano norme differenti tra i due documenti si considerano valide quelle riportate nell’Avviso.

Poiché la fase di Presentazione Piani è di competenza dell’Ufficio Formazione, i membri di tale ufficio monitorano l’attività di presentazione dei Piani da parte degli Attuatori.

Ogni Attuatore può inserire più Piani, sia per richiedere di finanziare formazione per se stesso (caso in cui l’Attuatore sia anche Azienda Beneficiaria), che per conto terzi (caso in cui l’Attuatore non sia anche Azienda Beneficiaria. Caso tipico degli Enti di Formazione).

I Piani possono essere di cinque tipi:

❑ Individuale

❑ Aziendale (Piano Formativo dedicato ad una sola Azienda Beneficiaria)

❑ Interaziendale (Piano Formativo che vede la partecipazione di più Aziende Beneficiarie)

❑ Territoriale (Piano Formativo dedicato a più Aziende Beneficiarie, tutte provenienti da uno specifico territorio)

❑ Settoriale (Piano Formativo dedicato a più Aziende Beneficiarie, tutte provenienti da uno specifico settore produttivo)

Queste tipologie non sono fisse e non è detto che siano applicabili a tutti gli Avvisi o a tutti gli Assi all’interno di un Avviso (per esempio non è prevista nel caso dei Voucher) ed è possibile che certi Avvisi prevedano un numero maggiore di tipologie.

Ogni Piano può contenere uno o più Progetti Formativi (il numero massimo è definito all’interno dell’Avviso), ognuno con le proprie Aziende Beneficiarie (almeno una) e con propri dati relativi a numero (suddiviso per tipologia) di lavoratori in formazione previsti ed eventuali uditori, ore di formazione da svolgere (divise per tipologia) e valori economici propri (che sono il risultato di più voci). La somma dei valori dei singoli Progetti da come risultato i valori del Piano che li contiene.

Tutti i Piani ed i Progetti hanno una base comune di informazioni necessarie ed un sottoinsieme di informazioni che variano di Avviso in Avviso.

Le informazioni richieste in questa fase sono in maggioranza di tipo quantitativo più che qualitativo (per esempio in questa fase può essere richiesto per ogni Progetto il numero di lavoratori in formazione per ogni Azienda Beneficiaria e quale tipologia, anche senza richiedere i dati anagrafici degli stessi). Tali informazioni possono essere di diversa tipologia, sia parametrici sia finanziari sia flag sia quantitativi o descrittivi, e possono variare da Avviso ad Avviso. I controlli su tali dati o i parametri di controllo ad essi legati possono variare da Avviso ad Avviso.

4.1.4.1 Chiusura Presentazione Piano

La fase di compilazione di un Piano termina con la chiusura della Presentazione, ovvero quell’operazione che l’Attuatore svolge una volta compilate tutte le parti del Formulario.

La Presentazione di un Piano può essere chiusa solo dopo una verifica di consistenza e completezza dei dati, oltre che di coerenza tra le informazioni inserite (per esempio che il prospetto di costo sia coerente e che i totali delle diverse voci imputate siano corretti).

La chiusura della presentazione prevede l’assegnazione di un codice univoco parlante al piano presentato.

Una volta completata tale operazione sono generate le stampe di riepilogo delle informazioni inserite.

La Fase di Presentazione di un Piano termina quando l’Attuatore, oltre ad aver chiuso la presentazione del Piano inserito, invia nei tempi previsti al Fondo tutta la documentazione

richiesta all’interno del Manuale di Gestione ed all’Avviso. Il tempo massimo entro il quale il Fondo deve ricevere tale documentazione è riportato nel Manuale di Gestione ed eventualmente emendato dall’Avviso.

L’Attuatore è responsabile di quanto dichiarato e dell’autenticità delle informazioni fatte pervenire al Fondo sia sotto forma di dati inseriti che di documentazione.

Il Fondo può decidere di erogare assegni di formazione individuali (“voucher”) nei confronti di lavoratori aderenti a FAPI. In tale caso, oltre a quanto visto in precedenza (ovvero che la presentazione possa essere fatta direttamente dall’Azienda Beneficiaria o da un Ente di Formazione o da professionisti di Formazione in genere), può essere previsto che sia il lavoratore stesso a presentare richiesta, secondo quanto specificato dall’Avviso.

Caratteristiche del Sistema

Il Sistema dovrà supportare la fase di Presentazione di un Piano con:

• la costruzione tramite il portale FASI della documentazione necessaria alla Presentazione di un Piano, garantendo:

o l’aderenza alle norme contenute nel Manuale di Gestione e dell’Avviso (in caso entrambi i documenti abbiano norme differenti relativamente allo stesso argomento, si considera come valido quanto riportato nell’Avviso)

o consistenza, completezza e ammissibilità dei dati inseriti, tra i quali fondamentali:

− Xxxxxxx Xxxxxxxxxx Xxxxxxxxx;

− Tipologia e Numero minimo e massimo dei Destinatari della formazione

− Modalità e Tematiche di formazione consentite nell’avviso

− Numero massimo dei finanziamenti ottenibili per beneficiaria sull’avviso di riferimento

− Data di validità dell’avviso e relative sessioni di scadenza

− Xxxxxxx xxxxx orario di formazione;

− Xxxxxxx xxxxx orario riconosciuto per Tematica Formativa

o la costruzione, sulla base delle informazioni fornite, della scheda di budget a livello di progetto formativo e piano formativo, con il calcolo automatico de:

− le voci di budget che potranno essere calcolate in base alle informazioni fornite dai soggetti attuatori,

− del cofinanziamento di tutte le aziende beneficiarie in base al regime aiuti di stato scelto dalle stesse.

• l’invio tramite il portale della suddetta documentazione (atto che sancisce la chiusura del Processo di Presentazione da parte dell’Attuatore)

• l’assegnazione di un particolare codice al Piano secondo una regola di nomenclatura specifica stabilita in sede di definizione dei requisiti

• la protocollazione ed il salvataggio in automatico del documento nel Sistema Documentale

• la produzione delle stampe di riepilogo delle informazioni inserite/inviate:

o Stampa Definitiva del Formulario;

o Stampa della Ricevuta di invio del Piano Formativo riportante la data e l’ora di invio al Fondo.

4.1.5 Valutazione Piani

I Piani per cui è stata Chiusa la Presentazione passano nella Fase di Valutazione Piani.

I Piani per cui non è stata Chiusa la Presentazione non saranno valutati. In questo caso i formulari vengono comunque conservati.

La Valutazione è la fase nella quale uno o più Piani Presentati sono analizzati. Per svolgere tale attività il Fondo ha predisposto un gruppo di lavoro dedicato, denominato Nucleo di Valutazione composto secondo le regole della bilateralità.

Il Nucleo di Valutazione per ogni Piano esegue le seguenti analisi:

• Verifica di ammissibilità: si verifica che l’Attuatore abbia inviato per tempo tutta la documentazione richiesta da XXXX, e che questa sia completa e coerente. Si verifica che le Aziende Beneficiarie siano effettivamente aderenti al Fondo e che l’Attuatore (nel caso sia un Ente di Formazione) sia aderente ai requisiti richiesti all’interno del Manuale di Gestione. Il passaggio con esito positivo della Valutazione di Completezza è fondamentale al fine di poter eseguire la Valutazione di Merito.

• Valutazione di Merito: è eseguita un’analisi nel merito delle informazioni inserite dall’Attuatore al momento della Presentazione del Piano e dei singoli Progetti. Ad ogni voce presente all’interno di una griglia di valutazione (pubblicata all’interno dell’Avviso e redatta dall’Ufficio Formazione) viene assegnato un punteggio (entro un minimo ed un massimo indicati per ogni singola voce all’interno dell’Avviso).

La somma delle singole voci di punteggio costituisce il Punteggio Totale ottenuto dal Piano. Il Punteggio ottenuto deve essere validato attualmente da almeno 2 (due) valutatori diversi.

La valutazione è eseguita in autonomia dal Nucleo di Valutazione, secondo la metodologia di lavoro che è ritenuta migliore dai membri.

La valutazione avviene a livello di Piano: se un Piano viene “approvato” (ovvero riceve un punteggio sufficiente per entrare nella graduatoria in una posizione tale da poter essere tra quelli eleggibili a finanziamento, e la cui documentazione risulta completa), vengono approvati tutti i Progetti che lo formano. Al contrario, se un Piano risulta “non approvato”, tutti i Progetti che lo compongono sono “non approvati” e quindi non ammessi a finanziamento.

Nel caso in cui la valutazione sia eseguita su Avvisi “a scadenza”, al completamento della valutazione di tutti i Piani, viene generato un elenco ordinato per punteggio. Tale documento sarà la base su cui sarà generata la Graduatoria.

Nel caso in cui l’Avviso preveda la valutazione “a sportello”, il Nucleo di Valutazione valuta il singolo piano (sempre secondo le modalità descritte in precedenza) di volta in volta che un Attuatore chiuderà la presentazione di un Piano e provvede ad assegnarne il punteggio.

Caratteristiche del Sistema

Il Sistema dovrà supportare l’utente del Nucleo di Valutazione nello svolgimento delle proprie valutazioni di ammissibilità e di merito sul Piano, secondo tutte le tipologie di avviso gestite dal Fondo.

In particolare il Sistema dovrà garantire la possibilità di:

• ricercare tutti i Piani in valutazione o presenti nello storico, anche per Attuatore ed aziende, divisi per Avviso ed eventualmente relativi ad uno specifico Avviso selezionato dall’Utente, con l’accesso alla scheda di Valutazione del Piano in sola lettura per i piani la cui valutazione è stata consolidata, in lettura e scrittura per i piani in valutazione;

• mostrare, per ogni singolo Piano, le informazioni in grado di consentire all’utente la Valutazione di Completezza, attraverso una checklist su cui verificare tutti i criteri di completezza ed i documenti pervenuti tramite le modalità ed entro le tempistiche stabilite dal Fondo

• segnalare in automatico l’esito della valutazione (tutte le check box spuntate: Ammissibile a Valutazione; una o più check box non spuntate: Non Ammissibile a Valutazione);

• supportare la Valutazione nel Merito, attraverso:

o l’evidenziazione della lista dei criteri di valutazione predisposta dall’Ufficio Formazione, con indicazione del punteggio minimo e massimo che possono ottenere le singole voci di valutazione e la possibilità che per ognuna il Valutatore possa inserire il valore assegnato

o il calcolo automatico del risultato ottenuto ed il salvataggio dei dati e degli esiti della Valutazione.

• gestire la validazione dei dati da parte di almeno (attualmente) due Valutatori diversi tenendo memoria degli interventi di ognuno (inserimento modifiche successive, registrazione degli utenti e delle date di esecuzione delle operazioni, etc.),

• congelare i dati, una volta dichiarata formalmente chiusa la fase di Valutazione da parte dei Valutatori, e consentire solo all’Ufficio Formazione, secondo le policy che saranno definite, la eventuale riapertura della valutazione di uno o più Piani e conseguente rettifica/annullamento delle valutazioni degli esiti.

• calcolare automaticamente, dietro apposita richiesta, i punteggi ottenuti dai singoli piani secondo gli algoritmi definiti in analisi con il cliente e di generare uno o più report relativi ai piani valutati e di renderli esportabili secondo i formati richiesti dal FAPI.

4.1.6 Generazione Graduatoria

Il Nucleo di Valutazione, una volta completata la valutazione dei Piani, genera un documento ove i Piani valutati sono ordinati in base ai punteggi. Tale documento viene consegnato all’Ufficio Formazione.

Tramite la Direzione, tale documento è sottoposto al Consiglio di Amministrazione per l’Approvazione. In caso questo passaggio abbia ottenuto esito positivo, da tale documento è generata la Graduatoria, ordinata per punteggi, oggetto di pubblicazione.

Il Consiglio di Amministrazione delibera (tramite Delibera) il Finanziamento dei Piani evidenziati dalla Graduatoria come eleggibili. L’Ufficio Amministrazione riceve la Graduatoria e provvede ad accantonare i relativi fondi in contabilità.

In caso di Valutazione “a Sportello”, verificata la disponibilità di fondi per coprire il finanziamento dei Piani, è generata una Delibera per ogni singolo Piano che si decide di approvare. Anche in questo caso l’Ufficio Amministrazione riceve la Delibera e provvede ad accantonare i relativi fondi in contabilità.

Caratteristiche del Sistema

Il Sistema dovrà supportare questa fase con funzionalità in grado di:

• produrre la “graduatoria” da sottoporre all’attenzione del CdA e tutte le informazioni da inoltrare all’attenzione del Cda nei formati previsti, eventualmente inserite all’interno di un template fornito dal Fondo;

• a seguito del CdA, produrre la “graduatoria” definitiva da pubblicare;

• recepire le decisioni del CdA e di inserire (sia in maniera puntuale per un singolo Piano sia massiva per più Piani) le informazioni relative alla Delibera per i Piani Ammessi a Finanziamento ed eventuali modificazioni.

• generare un flusso di dati verso il software di contabilità attualmente in uso dall’Ufficio Amministrazione, che permetta il recepimento delle informazioni relative ai Piani Ammessi a Finanziamento. Tra le informazioni da inserire all’interno del flusso si citano le seguenti a titolo di esempio:

o Codice Piano;

o Ente beneficiario (Attuatore);

o Tipologia di Piano (Aziendale/Interaziendale/Settoriale), per attività di monitoraggio;

o Finanziamento / Cofinanziamento.

4.1.7 Pubblicazione Graduatoria

Una volta approvata, la Graduatoria, provvisoria e/o definitiva, viene inoltrata dal Consiglio di Amministrazione all’Ufficio Formazione affinché venga recepita ed all’Ufficio Marketing affinché sia resa pubblica tramite il Portale FAPI.

Caratteristiche del Sistema

Il Sistema dovrà consentire:

• la pubblicazione sul portale della Graduatoria;

• la comunicazione, in formato pdf e tramite posta certificata, dell’avvenuto finanziamento del piano formativo al soggetto attuatore.

4.1.8 Gestione Ricorsi e Variazioni

In seguito alla Pubblicazione della graduatoria gli Attuatori (entro un numero di giorni indicato all’interno del Manuale di Gestione ed all’Avviso) i cui Piani Formativi non sono stati considerati eleggibili per il Finanziamento da parte del Fondo, hanno diritto a ricorrere contro la decisione del CdA, esponendo le proprie ragioni e tutta la documentazione necessaria.

Il CdA valuta quanto pervenuto e decide se accettare o no il ricorso. In caso il ricorso sia accolto, sarà generata una Delibera di rifinanziamento, atta a finanziare i Piani i cui ricorsi sono stati accolti.

Caratteristiche del Sistema

Il Sistema dovrà permettere:

• la definizione della Graduatoria Definitiva comprensiva delle eventuali variazioni derivanti dall’accettazione dei ricorsi;

• la ridefinizione, mantenendo comunque evidenza delle impostazioni iniziali, dello stanziamento dell’avviso;

• di comunicare le variazioni all’Ufficio Amministrazione con gli importi ridefiniti.

4.1.9 Attuazione Piani

Una volta approvata la Graduatoria e per ogni ricorso accolto, è possibile avere l’informazione definitiva relativa ai Piani per cui è stato approvato il finanziamento (in totale od in parte, in relazione al regime di Aiuti di Stato di cui godono le Aziende Beneficiarie interessate da tale Piano).

Tali Piani vengono “Passati in Attuazione”, ovvero segnalati all’interno del Sistema come Approvati (riportando inoltre i dettagli dell’approvazione, ovvero la Delibera, la Data della Delibera, i dati finanziari) e quindi resi visibili all’Attuatore che è abilitato a completare l’inserimento di tutte le informazioni necessarie alla Gestione dei Piani.

Tale operazione è di competenza dell’Ufficio Formazione.

4.1.10 Gestione Convenzione ed Avviso Piano

Recepita la Graduatoria (o la Delibera), l’Ufficio Formazione provvede ad abilitare la stipula della/e Convenzione/i (ogni Avviso può avere una Convenzione diversa dagli altri, sia come testo sia per i campi da compilare al suo interno) per i Piani ammessi a finanziamento. Da tale momento, dal portale, gli Attuatori potranno visualizzare, scaricare e stampare tali documenti ed reinviarli firmati per accettazione al Fondo.

Le copie pervenute saranno controfirmate dal Presidente del Fondo. Una copia sarà ritornata all’Attuatore tramite Posta Raccomandata e contestualmente l’Ufficio Formazione abiliterà l’Avvio del Piano.

In caso la Convenzione non giunga al Fondo entro la data attesa, il Piano sarà bloccato. L’Attuatore ha la facoltà di chiedere lo sblocco del Piano, giustificando il ritardo attraverso il sistema informatico. Se tale richiesta è inoltrata al Fondo entro un certo numero di giorni (specificato sul Manuale di Gestione), l’Ufficio Formazione può concedere lo sblocco. Oltre tale data lo sblocco può essere autorizzato solo tramite delibera del CdA.

L’Ufficio Formazione inserisce a Sistema la data di ricezione della Convenzione.

Caratteristiche del Sistema

Il Sistema pertanto dovrà consentire:

• la generazione in automatico delle Convenzioni secondo un formato deciso in sede di definizione dei requisiti riportante un template stabilito dal Fondo ed un testo generato a partire da un tracciato standard e completato automaticamente dal sistema inserendo le informazioni specifiche per il singolo Piano

• la visualizzazione da parte dei vari Attuatori delle singole Convenzioni per i piani finanziati, con contestuale segnalazione dei giorni ancora a disposizione per stampare la Convenzione, firmarla ed inviarla al Fondo.

• La possibilità all’Attuatore, una volta stampata e firmata la Convenzione, (ferma restando sempre la possibilità dei normali canali di posta) di trasmetterla al Fondo tramite il portale FAPI; in tal caso:

o la protocollazione e salvataggio in automatico da parte del Sistema Documentale

o la costante consultazione del documento sia da parte degli Attuatori interessati che degli utenti FAPI abilitati

o la ristampa della Convenzione a seguito di variazioni sul Piano (p.e. rinuncia progetti, diminuzione ore formazione, variazione aziende/partecipanti,…)

• la gestione da parte dell’Ufficio Formazione della fase di avvio formale e/o blocco/sblocco delle singole Convenzioni

4.1.11 Fidejussioni

La responsabilità della gestione di tutto il ciclo di vita di una o più Fidejussioni legate ad un singolo Piano ed in relazione alla Gestione degli Anticipi è in capo all’Ufficio Amministrazione.

Caratteristiche del Sistema

Relativamente a tale attività il Sistema dovrà supportare L’Ufficio ne:

• l’inserimento, la visualizzazione automatica e la modifica, secondo le rispettive policy, delle informazioni relative alle Fidejussioni con opportuni controlli, consentendo all’utente Fondo di visualizzare ed eventualmente approvare le informazioni inserite dall’Attuatore.

• l’invio all’Attuatore tramite posta certificata, in caso l’utente dell’Ufficio Amministrazione dia parere negativo alle informazioni inserite, di una e-mail di notifica a partire dai testi predisposti dal Fondo ed opportunamente compilati in automatico.

• l’autorizzazione, una volta verificate una serie di condizioni, dello svincolo delle Fidejussioni, sia in modalità puntuale per una singola Fidejussione che in modalità massiva per più Fidejussioni

• la generazione di tutti i documenti necessari al completamento formale dello svincolo.

4.1.12 Gestione Anticipi

La responsabilità della gestione delle richieste di Anticipo legate ad un singolo Piano è in capo all’Ufficio Amministrazione.

Caratteristiche del Sistema

Relativamente a tale attività il Sistema dovrà supportare L’Ufficio nel:

• consentire la visualizzazione di tutte le richieste di Xxxxxxxx concesse e da concedere, evidenziando per ciascuna le informazioni che la caratterizzano, tutti i documenti trasmessi dall’Attuatore e necessari per validare la richiesta e

• verificare la completezza dei dati inseriti dall’Attuatore in relazione alle coordinate bancarie ed ai dati necessari all’Ufficio Amministrazione per l’erogazione dell’anticipo.

• permettere, in caso la richiesta sia ammissibile e l’anticipo erogabile:

o la generazione dell’Ordine di Pagamento, la lettera accompagnatoria ed il documento di presa di responsabilità da parte del/i dirigente/i interessati. Tutti questi documenti dovranno essere generati a partire da un tracciato standard ed un template fornito dal Fondo e completato con le informazioni relative al Piano.

o l’inserimento da parte dell’Utente dell’Ufficio Amministrazione, una volta effettuato il pagamento, delle informazioni relative al pagamento per poter chiudere la pratica.

o la visibilità degli acconti erogati nelle operazioni relative ai Piani, in base alle policy di accesso dei vari utenti.

o la generazione di un flusso di dati, suddivisi per soggetto attuatore e per Piano/progetto, verso il programma di contabilità in uso presso l’Ufficio Amministrazione.

4.1.13 Attuazione Piani

Una volta che il Fondo ha ricevuto dall’Attuatore la Convenzione opportunamente firmata ed in seguito alla controfirma dal Presidente del Fondo, l’Ufficio Formazione provvede ad abilitare il Piano all’Avvio, cioè abilitare l’Attuatore all’accesso alle funzioni per l’Avvio del Piano formativo e dei relativi Progetti (per brevità in seguito si farà riferimento a questo come “Avvio Piano”).

Caratteristiche del Sistema

Il Sistema dovrà:

• consentire all’Attuatore l’Avvio Piano, cioè di inserire, entro il numero di giorni indicati dal Manuale di Gestione ed indicati a livello di avviso, le informazioni concernenti l’Attuazione dell’Attività formativa ed i dati di specifico interesse dell’Ufficio Amministrazione;

• segnalare quanti giorni l’Attuatore ha ancora a disposizione per realizzare tali operazioni;

• l’inserimento da parte dell’Attuatore di tutte le informazioni relative ai Partecipanti ai singoli Progetti, dando la possibilità di recuperare per via automatica i dati eventualmente già presenti nel sistema medesimo per precedenti attività formative;

• controllare, in caso di inserimento di nuovi dati, la coerenza e completezza logica dei medesimi.

L’Attuatore, l’Ufficio Formazione, l’Ufficio Organizzazione, l’Ufficio di Amministrazione e gli altri utenti abilitati devono poter accedere alle informazioni inserite in Fase di Presentazione con le rispettive policy di accesso.

4.1.14 Attuazione Progetti

Una volta avviato il Piano, l’Attuatore può iniziare ad organizzare la propria Attività e quindi avviare i Progetti Formativi che in fase di Presentazione ha proposto e che il Fondo ha approvato.

L’Attuatore deve tenere un registro presenze cartaceo. Il modello di tale registro è fornito dal Fondo. La normativa collegata a tale registro è specificata all’interno del Manuale di Gestione.

Questa fase è di competenza dell’Ufficio Formazione, nonché dell’Ufficio Organizzazione per le informazioni relative ai calendari (in quanto quest’ultimo Ufficio ha competenza sul monitoraggio delle attività e sulle visite ispettive).

Caratteristiche del Sistema

Relativamente a tale processo il Sistema dovrà prevedere:

• l’inserimento e la gestione da parte dell’Attuatore, per ogni singolo Progetto di un Piano Avviato e secondo le direttive vigenti, delle informazioni relative alle date di calendario ed ai partecipanti delle Attività di Formazione, quali ad esempio:

o Calendario Attività d’Aula;

o Calendario Attività Non d’Aula;

o Orario di inizio e di Fine Attività,

o la sede ove tale Attività sarà svolta (città, indirizzo, numero di telefono),

o il docente incaricato,

o l’eventuale tutor, se previsto in progettazione,

o gli argomenti trattati;

o i dati riferiti ai partecipanti alla formazione (nominativi, CF,…) in relazione all’azienda di appartenenza inserita nel singolo Progetto;

• la verifica che quanto inserito sia aderente a quanto dichiarato dall’Attuatore in fase di Presentazione e non permettere l’inserimento di un numero di ore di formazione diverso o ripartito diversamente da quanto originariamente dichiarato.

• l’inserimento dei dati da parte dell’Attuatore possa avvenire in maniera temporalmente graduale e progressiva (ovvero le Attività possono essere inserite e modificate di volta in volta), purché tale operazione sia svolta secondo quanto concesso dal Manuale di Gestione.

• la gestione, secondo modalità individuate in sede di definizione dei requisiti, da parte dell’Attuatore delle eventuali modifiche in norma e fuori norma.

• il recupero rapido ed efficiente di dati presenti nel sistema (es. anagrafiche lavoratori, estremi Azienda Beneficiarie, etc.) per precedenti attività formative anche se diverse dallo specifico Piano.

• controlli che verifichino l’aderenza a quanto dichiarato in Fase di Presentazione, sia come numero totale di Lavoratori in formazione per Azienda, sia come tipologia (es. la effettiva presenza, se dichiarati in sede di Presentazione Piano, di lavoratori appartenenti a “categorie svantaggiate” e che queste siano coerenti con quelle indicate all’interno del Manuale di Gestione ed eventualmente emendato nell’Avviso), con contestuale segnalazione dell’eventuale errore presente e conseguente impedimento all’Attuatore di proseguire.

• la specificazione della qualifica di partecipante od uditore per ogni Lavoratore associato al Progetto.

• l’inserimento, entro i limiti previsti dal Manuale di Gestione, di un numero di Lavoratori a sostituzione di quelli ritirati dal Progetto.

• che gli avvii delle singole fasi (Avvio del Piano, Avvio dei singoli Progetti Formativi, avvio dell’effettiva somministrazione della formazione), per le quali è obbligatoriamente

propedeutica la relativa segnalazione all’Ufficio Formazione, avvengano in modo sequenziale e solo dopo che sia stata completato l’inserimento dei dati della fase funzionalmente antecedente

• un controllo che verifichi che tra il momento in cui l’Attuatore comunica l’avvio del Progetto e la prima data a calendario trascorrano un certo numero di giorni, normato all’interno del Manuale di Gestione, con:

o segnalazione, laddove tra le due date trascorrano un numero di giorni minore,

o stampa automatica, su richiesta dell’Attuatore, della documentazione di Avvio Progetto secondo un tracciato stabilito in sede di definizione di definizione dei requisiti, qualora il controllo dia esito positivo

4.1.15 Gestione Variazioni / Anomalie

Durante la Fase di Attuazione possono accadere eventi che provochino la necessità per l’Attuatore di variare quanto finora inserito in fase di Attuazione oppure che vadano a modificare le informazioni inserite in Fase di Presentazione.

Tali operazioni di variazione delle informazioni inserite sono previste e normate dal Manuale di Gestione e dall’Avviso.

Tali variazioni possono essere di due tipi:

• Variazioni “in norma”, ovvero previste dal Manuale di Gestione.;

• Variazioni “fuori norma”, ovvero fuori da quanto previsto all’interno del Manuale di Gestione.

Caratteristiche del Sistema

Il Sistema dovrà:

• in caso la variazione sia “in norma”, memorizzare e concedere l’esecuzione dell’operazione di modifica. I dati inseriti in precedenza non dovranno essere cancellati ma storicizzati, e dovrà essere sempre possibile ricostruire per ogni informazione il suo ciclo di vita e come sia cambiata nel tempo. Il Sistema dovrà notificare all’Ufficio Formazione l’avvenuta variazione in norma.

• in caso la modifica sia riconosciuta come “fuori norma”:

o memorizzare il tentativo di modifica ed i dati modificati, ma non validare i dati. Essi rimarranno congelati fino a quando l’Ufficio Formazione, tramite apposita interfaccia, dovrà segnalare se la richiesta di modifica sia stata accolta o meno. In caso la richiesta sia accolta, l’Ufficio Formazione dovrà inserire le informazioni relative alla eventuale Delibera di accoglimento;

o laddove richiesto, segnalare all’Attuatore la necessità di istruire richiesta scritta al Fondo, specificando la prassi da seguire, quali documenti allegare alla richiesta e come inoltrarla.

• riattivare, in caso la richiesta di variazione fuori norma non sia accolta, le informazioni precedenti alla richiesta di variazione, mantenendo la storia di questi passaggi.

4.1.16 Gestione Proroghe

L’Attuatore deve completare le diverse fasi che compongono il Ciclo di Vita di un Piano entro intervalli di tempo ben precisi, stabiliti dal Manuale di Gestione ed eventualmente emendati dall’Avviso.

In caso l’Attuatore non sia in grado di ottemperare a tali obblighi, ha la facoltà di chiedere la concessione di una Proroga.

La richiesta di Xxxxxxx deve essere inviata online all’Ufficio Formazione opportunamente giustificata. Tale Xxxxxxx ha la competenza sull’istruzione di una pratica in proposito, e sul suo eventuale inoltro al CdA affinché essa sia valutata ed eventualmente deliberata.

Caratteristiche del Sistema

In caso la richiesta sia accolta, il Sistema dovrà supportare l’Ufficio Formazione nella gestione delle proroghe consentendo a:

• l’Attuatore di richiedere tramite il Sistema al Fondo, se previsto nell’avviso di riferimento, una o più proroghe per il piano di interesse;

• l’Ufficio Formazione di inserire le informazioni relative alla proroga concessa (per esempio il numero di giorni concessi per completare le operazioni), così come la eventuale revoca di una Proroga concessa in precedenza e controllare che siano inserite le informazioni della relativa Delibera laddove da Manuale sia necessario l’assenso del CdA;

• il sistema, sulla base della proroga, deve ricalcolare i tempi di vita del Piano.

4.1.17 Gestione Visite Ispettive

L’Attuatore, al momento della stipulazione della Convenzione, accetta esplicitamente che il Fondo possa svolgere attività di verifica del suo operato. Per fare questo FAPI utilizza il metodo delle visite ispettive.

Tale servizio è svolto da un’Azienda terza vincitrice di una apposita gara di appalto, che svolge in autonomia la gestione delle visite ispettive.

L’Ispettore (o per suo conto l’Azienda fornitrice del servizio di Ispezione e Verifica) accede ai calendari inseriti dagli Attuatori e su essi stabilisce un calendario delle Visite Ispettive da effettuare. Il Fondo non ha visibilità sul calendario visite.

Il Fondo viene a conoscenza dell’esecuzione di una visita quando riceve il verbale di ispezione. La competenza sulle visite ispettive è dell’Ufficio Organizzazione.

Le visite ispettive possono avvenire in due diversi momenti:

1. Visite ispettive in “in itinere” (attualmente 60% circa del totale): l’Ispettore si presenta durante una data calendarizzata per verificare che l’attività si stia effettivamente svolgendo secondo quanto dichiarato e che quanto dichiarato all’interno del registro sia veritiero (per esempio che i partecipanti dichiarati come presenti lo siano effettivamente). In genere ogni Piano riceve almeno una visita ispettiva “in itinere” per Piano.

2. Visite Ispettive “ex post” (attualmente 40% circa del totale): tale visita è eseguita al termine della fase di Rendicontazione; l’Ispettore verifica che quanto dichiarato in fase di Gestione del Piano e di Rendicontazione sia comprovato e che la documentazione non sia affetta da vizi.

Al termine di ogni visita l’Ispettore redige un Verbale di Visita Ispettiva, riportante quanto rilevato. L’Ispettore è tenuto a consegnare una copia di tale verbale all’Attuatore ed una all’Ufficio Organizzazione.

In caso siano riscontrate anomalie rispetto a quanto atteso, l’Ufficio Organizzazione istruisce una pratica accogliendo eventuali osservazioni e giustificazioni da parte dell’Attuatore. L’Ufficio

Organizzazione ha la facoltà di esprimere un parere in proposito ed inoltra la pratica al CdA (tramite la Direzione).

Il CdA si esprime in proposito e delibera eventuali sanzioni. L’Attuatore può fare ricorso contro la decisione del CdA. Sarà il CdA stesso ad esprimersi in proposito e decidere se accogliere l’istanza oppure confermare le sanzioni.

Caratteristiche del Sistema

Il Sistema dovrà consentire agli ispettori di:

• accedere a tutte le informazioni dei piani (sia di presentazione che di attuazione) in ispezione al fine di verificarne la congruità con quanto riscontrato durante la visita;

• accedere ai calendari dei singoli piani e progetti per poter definire i propri calendari di ispezione;

• in caso di visita ispettiva ex-post, accedere alle informazioni di rendiconto per verificarne la congruità con quanto riscontrato a livello cartaceo.

• aggiornare i dati dei Piani sul sistema online in esito alle verifiche, dietro approvazione del Fondo.

Il Sottosistema Documentale dovrà essere in grado di recepire i verbali redatti dagli Ispettori e di gestirli in modo integrato con il Sistema così che gli utenti abilitati possano sia cercare i dati circa le visite ispettive e i relativi verbali, sia estrarre le informazioni relative al Piano ed ai Progetti oggetto della Visita Ispettiva.

4.1.18 Chiusura Piani

Al termine dell’attività formativa prevista e completate le procedure di inserimento dei dati riguardanti i singoli Progetti (cfr. dati indicati nel precedente paragrafo “Attuazione Progetti”), l’Attuatore può chiudere il Piano. Nessuna variazione sarà più possibile alle informazioni inserite.

L’Attuatore ha peraltro la possibilità a rinunciare in maniera Parziale o Totale ai Piani, potendo rinunciare ad uno o più Progetti costituenti il Piano, a delle ore sul singolo Progetto, od al Piano nel suo complesso; le norme che regolano le Rinunce, sia di tipo Totale sia di tipo Parziale sono contenute all’interno del Manuale di Gestione.

Con tale operazione si esaurisce la Fase di Gestione del Piano e si passa alla Fase di Rendicontazione.

Caratteristiche del Sistema

Il Sistema, relativamente al processo di chiusura dei Piani da parte degli Attuatori, dovrà:

• verificare, che siano state inserite tutte le informazioni richieste: condizione vincolante per effettuare la chiusura del Piano

• memorizzare a sistema la data di Chiusura del Piano,

• generare in automatico il documento TEP, dando la possibilità di inviarlo all’Ufficio Formazione via portale con modalità di posta certificata.

• consentire, in caso di rinuncia parziale:

o la comunicazione al FAPI, tramite il SISTEMA, del numero delle ore di attività formative a cui si intende di rinunciare, del/i Progetto/i,

o la verifica che le rinunce parziali non siano retroattive e che il totale delle ore rinunciate non può essere superiore a quello delle ore di Attività Formative ancora da svolgere,

o la verifica, secondo le regole dell’avviso, che i corrispondenti valori economici del Piano e dei Progetti interessati dalla Rinuncia siano coerentemente modificati dal soggetto attuatore

4.1.19 Rendicontazione

Terminata la Fase di Gestione, il Piano passa nella Fase di Rendicontazione.

In questa fase l’Attuatore deve fornire tutte le informazioni richieste e concernenti le spese sostenute per il dato Piano attraverso il Rendiconto dell’Attuatore certificato dal Revisore legale. Entro un periodo stabilito dal Manuale di Gestione ed eventualmente emendato dall’Avviso l’Attuatore deve completare l’inserimento ed eseguire la Chiusura del Rendiconto.

Tale operazione impedisce la modifica o l’inserimento di ulteriori informazioni e genera un documento, contenente il Rendiconto dell’Attuatore e le spese riconosciute dal Revisore legale.

L’Attuatore invia tutta la documentazione richiesta all’Ufficio Organizzazione (che è competente su questa fase).

L’Ufficio Organizzazione, anche con il supporto degli Ispettori, verifica il Rendiconto e al netto di eventuali tagli e sanzioni approva il Rendiconto.

Una volta completata la Fase di Attuazione e dopo che la visita ispettiva “ex post” ha certificato l’assenza di vizi ed anomalie, l’Attuatore può emettere la fattura per il saldo dell’importo finanziato dal Fondo, al netto degli anticipi.

Con il termine della Fase di Rendicontazione termina anche la Fase di Attuazione del Piano.

Caratteristiche del Sistema

Il Sistema dovrà quindi consentire:

• l’inserimento, la modifica e la visualizzazione delle informazioni relative ai Rendiconti, nonché l’evidenza del totale degli importi inseriti, diviso per tipologia di spesa;

• l’inserimento di tutte le informazioni richieste dal Fondo per ogni rendiconto, segnalando il tipo di spesa. Allo stesso modo dovrà essere prevista un’interfaccia di modifica delle informazioni inserite in precedenza;

• la Chiusura del Rendiconto da parte dell’Attuatore subordinandola a specifici controlli di completezza dei dati inseriti e di correttezza rispetto a quanto prospettato in Fase di Presentazione;

• la immodificabilità dei dati inseriti lato Attuatore una volta chiuso il Rendiconto e la successiva produzione del documento;

• l’aggiornamento dell’importo finanziato dal Fondo (importo ‘riconosciuto’) a seguito della verifica del Rendiconto e della sua approvazione al netto di eventuali tagli e sanzioni.

• il blocco del Piano nel caso in cui l’Attuatore non chiuda il Rendiconto entro i tempi previsti dal Manuale di Gestione, con contestuale segnalazione del blocco medesimo all’Attuatore che

evidenzi quanto successo e come poter operare (per es.: se richiedere lo sblocco per il completamento della sola Rendicontazione od una Proroga).

4.1.20 Gestione Saldi

L’Ufficio Amministrazione riceve la documentazione richiesta ed il verbale delle visite ispettive, e ne verifica il contenuto e la congruità.

Se la documentazione non è affetta da anomalie, l’Ufficio di Amministrazione emette un ordine di pagamento e, per un insieme di mandati anche una lettera distinta di accompagnamento, che dovranno essere firmati dal Presidente e dal Vicepresidente del Fondo, e un documento che certifichi la presa visione ed assunzione responsabilità da parte del o dei dirigenti FAPI interessati.

Gli Ordini di pagamento, le lettere distinte di accompagnamento sono portati in banca per effettuare i pagamenti, ed i relativi estremi sono riportati sul sistema.

A seguito dell’erogazione del Saldo da parte del Fondo, l’Attuatore può chiedere lo svincolo delle Fideiussioni stipulate. Tale autorizzazione è competenza dell’Ufficio Amministrazione, che inserisce a Sistema la data di richiesta e quella di concessione dello svincolo.

L’Ufficio Amministrazione ha necessità di poter gestire l’iter della gestione di tutti i Piani per cui la fase di Rendicontazione è stata terminata, evidenziando sia quelli per cui è possibile emettere il Saldo, sia quelli le cui visite “ex-post” hanno evidenziato anomalie.

Gli utenti non richiedono il saldo, è il Fondo che in base alle proprie scadenze, allo stato dei progetti rendicontato o revisionato (caso in cui dall’avviso sia necessario un revisore), e dalle eventuali verifiche ex-post decide quando dare il saldo. Attualmente, vi sono sistemi che automaticamente, se per il piano formativo sono presenti le condizioni richieste dal Fondo, passano nella gestione del saldo automaticamente, e solo il Fondo opera in tale sezione inserendo le informazioni circa i bonifici, tutto il resto è in automatico.

Caratteristiche del Sistema

Il Sistema, per ogni richiesta di Saldo, dovrà essere in grado di:

• mostrare all’Utente dell’Ufficio di Amministrazione il Sistema sia i dettagli della richiesta, che tutti i documenti inviati tramite la piattaforma dall’Attuatore e salvati nel documentale in automatico dal sistema, per validare la richiesta;

• permettere, verificata la completezza dei dati inseriti dall’Attuatore in relazione alle coordinate bancarie, necessari all’Ufficio Amministrazione per l’erogazione del Saldo, l’espletamento della richiesta del saldo attraverso la generazione automatica dell’Ordine di Pagamento, della lettera accompagnatoria e del documento di presa di responsabilità da parte del/i dirigente/i interessati . Tutti questi documenti dovranno essere generati a partire da un tracciato standard ed un template fornito dal Fondo e completato con le informazioni relative al Piano.

• permettere all’Utente dell’Ufficio Amministrazione, una volta effettuato il pagamento, di per poter chiudere la Pratica attraverso l’inserimento delle informazioni relative al pagamento.

• dare visibilità degli acconti erogati nelle operazioni relative ai Piani, in base alle policy di accesso dei vari utenti.

• visualizzare le informazioni relative allo stato dei pagamenti relativi ad un singolo Piano.

4.2 Processi di Controllo e Monitoraggio

4.2.1 Monitoraggio Attività Operative di Gestione Finanziamenti per la Formazione

Durante tutte le fasi che compongono il Ciclo di Vita di un Avviso, il Fondo ha la necessità di poter svolgere analisi ed attività di monitoraggio. Tali attività sono svolte dagli Uffici secondo le rispettive competenze.

Essi hanno la necessità di poter monitorare quanto presente a Sistema e quanto inserito dagli Attuatori durante tutte le fasi (sempre per le rispettive competenze) sia a livello più generale sia nel particolare di uno o più Attuatori, Beneficiari o di uno o più Piani legati da caratteristiche comuni (per esempio i piani presentati dall’Attuatore nei diversi avvisi, tutti i Piani Ammessi di un particolare Avviso per una data Regione, tutti i Piani approvati di un dato avviso per cui il Fondo non ha ricevuto ancora la Convenzione, le Delibere legate ad un dato Piano e le loro motivazioni).

Il Sistema dovrà quindi consentire ai singoli Uffici di poter svolgere la propria attività in autonomia, ovvero senza la necessità dell’intervento del personale tecnico specializzato, ciascuno per le proprie competenze.

Caratteristiche del Sistema

Di seguito un riepilogo non esaustivo delle principali funzionalità, già individuate nei precedenti paragrafi, in cui il Sistema dovrà supportare i singoli Uffici.

Ufficio Formazione

• Predisposizione Avvisi e definizione relativi parametri;

• Blocco/sblocco dei Piani in tutte le fasi in cui il fondo lo ritenga opportuno es. ritardo invio convenzione da parte dell’attuatore, ecc.;

• Gestione dei Calendari;

• Gestione delle Proroghe;

• Gestione delle Sanzioni;

• Gestione delle variazioni in norma e fuori norma;

• Gestione della Convenzione, e relativo stato per un dato Piano;

• Gestione del Calendario associato ai singoli progetti;

• Gestione delle Rinunce (sia totali che parziali);

• Visibilità dei Piani bloccati, con descrizione della motivazione del blocco e relativa funzione di Sblocco;

• Annullamento della validazione degli esiti di un Piano e annullamento della chiusura della Presentazione di un Piano;

• Approvazione di uno o più Piani;

• Annullamento dell’Avvio Piano dato un Codice Piano;

• Annullamento dell’Avvio Progetto dato un Codice Piano/Progetto;

• Gestione delle Pratiche;

• Visualizzazione dello stato dei ticket dell’Help Desk di Merito, se implementato;

Nucleo Valutazione

• Accesso alle informazioni di Presentazione

• Compilazione schede di valutazione

• Predisposizione proposta di graduatoria

• Sistema di help Desk Normative

Ufficio Organizzazione

• Visualizzazione delle Rinunce (sia totali sia parziali);

• Gestione dei Calendari;

• Gestione dei Rendiconti;

• Gestione delle visite ispettive;

• Gestione delle pratiche;

• Visualizzazione dello stato dei ticket dell’Help Desk Informatico se implementato nel sistema o comunque un collegamento al sistema di help desk Tecnico implementato dal Fornitore, con indicatori che permettano anche la misurazione delle performance dell’Help Desk Tecnico stesso;

• Generazione dei flussi istituzionalmente dovuti.

• Gestione delle Sanzioni.

• Visualizzazione delle informazioni di Rendicontazione

• gestione dei Verbali delle verifiche

Ufficio Amministrazione

• Gestione del Rendiconto;

• Visualizzazione dei verbali delle Visite Ispettive;

• Gestione Anticipi;

• Gestione Saldi;

• Gestione Fidejussioni;

• Gestione Stato dei Pagamenti;

• Visualizzazione dati INPS;

• Gestione delle Pratiche;

• Import/Export flussi verso/dal Gestionale di ESA Software.

Ispettori

• Visualizzazione di tutte le informazioni di Presentazione ed Attuazione dei piani e progetti

• visualizzazione delle informazioni relative ai calendari di formazione

• Visualizzazione delle informazioni di Rendicontazione

• gestione dei Verbali delle visite ispettive

4.2.2 Gestione Banche Dati INPS

Il Fondo ha l’esigenza di gestire le informazioni e gli elenchi relativi agli Aderenti al Fondo periodicamente provenienti dall’INPS.

Un’Azienda può aderire a FAPI (o ad un altro Fondo Inter professionale) indicando la sua scelta all’interno del modulo DM10 o tramite UNIEMENS.

Il Fondo ha la necessità di gestire questa informazione e di poterla integrare con le informazioni riguardanti i Piani Formativi che hanno interessato l’Azienda Beneficiaria ed i relativi fondi erogati per la formazione.

Dall’analisi dei flussi di dati trasferiti dal’INPS al Fondo sono state individuate due tipologie di tracciati:

1. Dati riguardanti le adesioni ed alle revoche, che a loro volta sono di due tipi:

o Dati di adesione veri e propri;

o Dati relativi alle aziende aderenti e non versanti (tale dato è ovviamente desumibile dal’incrocio dei dati relativi alle adesioni e quelli relativi ai versamenti).

2. Dati riguardanti i versamenti, che a loro volta sono di due tipi:.

o Versamenti mensili incassati;

o Versamenti mensili accertati ma non incassati (insoluto).

I dati riguardanti i versamenti aziendali vengono ripartiti e comunicati al Fondo su base mensile.

L’INPS provvede inoltre a produrre mensilmente i flussi rettificati riguardanti i mesi precedenti, ovvero comprensivi delle correzioni apportate alle informazioni contenute nella propria Base Dati e già comunicate al Fondo.

Caratteristiche del Sistema

Il Sistema dovrà consentire:

• l’acquisizione di tale flusso di dati ed integrarli da “xxxxxxx.xx”nella Base Dati Aderenti del Fondo, attualmente mantenuta dall’Ufficio Marketing secondo le modalità più efficienti ed efficaci per l’utente;

• l’accesso alle relative informazioni secondo le rispettive regole di visibilità ai diversi Uffici del Fondo, mantenendo la storicizzazione delle informazioni acquisite e consentendo confronti tra dati provenienti dagli scarichi INPS e dati derivanti dalle attività formative finanziate.

4.2.3 Gestione “Portabilità” Dei Contributi Versati dalle Aziende

L’INPS con il messaggio numero 3247 del 2 Febbraio 2010 ha introdotto per un’Azienda la possibilità, all’atto del cambiamento del Fondo Inter professionale a cui aderisce, di trasferire attualmente il 70% delle somme versate nel triennio antecedente, al netto di eventuali somme già utilizzate per il finanziamento dei propri Piani Formativi.

Attualmente, per poter usufruire di tale possibilità l’Azienda deve aver dato la propria adesione al Fondo scelto in precedenza continuativamente attualmente per almeno 3 anni (valenza del triennio a partire dal 1 Gennaio 2009), non rispondere alla definizione comunitaria di miro e piccole imprese (Ra cc n. 2003/361/CE) e purché l’importo da trasferire sia pari ad almeno € 3.000,00 (tremila/00).

Il Fondo ha la necessità di gestire questa possibilità comunemente definita all’interno del Fondo come “Cassetto INPS”.

Caratteristiche del Sistema

Il Sistema dovrà in ogni momento rendere disponibile agli Uffici per le rispettive competenze ed eventualmente anche alle Articolazioni Locali, per una data Azienda Aderente:

• i periodi di adesione,

• il numero di dipendenti o dirigenti per cui versa il contributo per i Fondi di Formazione,

• le somme versate da essa al Fondo

• gli importi finanziati dal Fondo per Attività Formative (con la possibilità di accedere alle informazioni relative ai Piani Finanziati).

4.2.4 Gestione Flussi per il Ministero del Lavoro

Il Fondo ha la necessità di comunicare al Ministero del Lavoro ed eventuali enti ad esso legati le informazioni relative all’Attività Formativa erogata. Il Fondo è tenuto per legge a fornire queste informazioni, con una precisa cadenza semestrale.

Uno dei principali flussi di questo tipo è quello che il Fondo deve generare per l’Istituto per lo sviluppo della formazione professionale dei lavoratori ISFOL; si rimanda alla cura del Fornitore l’acquisizione della conoscenza dei dettagli di questo flusso.

Caratteristiche del Sistema

Il Sistema dovrà consentire, nelle modalità più efficienti ed efficaci per l’utente, lo scambio di tali informazioni tramite la creazione di flussi di dati generati a partire da tracciati specificati dal Ministero o dall’Ente ricevente. Tali flussi possono variare nel tempo sia in funzione delle informazioni richieste che del formato.

4.2.5 Business Intelligence/Controllo di Gestione

Il Fondo ha necessità di analizzare le attività svolte nel corso delle sue operazioni.

Caratteristiche del Sistema

Il Sistema dovrà quindi prevedere funzionalità che consentano agli Utenti del Fondo, ciascuno per le proprie competenze ed in base alle rispettive policy di accesso:

• interrogazioni sulla base dati:

o costruite e generate autonomamente dagli utenti del fondo

o già predisposte dal Fornitore con riferimento alle informazioni fondamentali, quali ad esempio:

− Fondi erogati

− Ore formative erogate

− Durate delle attività

− Esiti ispezioni

• analisi articolate relativamente a:

o Avvisi

o Piani formativi

o Progetti formativi

o Aziende finanziate

o Attuatori

o Lavoratori

o Caratteristiche della formazione erogata (tipologia di aziende, argomenti trattati etc)

o Articolazione territoriale o per categorie merceologiche

• quadri sinottici relativi sia a situazioni effettive (per esempio, erogazioni di fondi effettuate), sia a situazioni previsionali (per esempio, erogazioni di fondi preventivate sulla base dei piani formativi).

• elaborazione di indicatori, che potranno essere semplici (come lo scostamento tra erogazioni preventivate ed erogazioni consuntivate) oppure complessi.

Gli elenchi suddetti sono indicativi. Le informazioni da trattare, la loro articolazione, il grado di dettaglio e gli indicatori dovranno essere concordati in fase di progetto con il Committente.

Il Fornitore indicherà in fase di Offerta la quantità e tipologia di interrogazioni ed indicatori che potrà realizzare compresi nell’attività “a corpo”.

In questa sede si segnala che, al fine dell'ottenimento di informazioni significative dovranno essere individuate in fase di progetto tecniche adeguate per l'identificazione univoca delle entità coinvolte. Come esempio si cita l'identificazione delle aziende, che possono avere più riferimenti (ad esempio numerose matricole INPS) riconducibili ad una stessa realtà aziendale. Oltre all'individuazione delle tecniche suddette, si richiede che siano forniti agli uffici competenti del Committente strumenti per l'individuazione delle anomalie e la loro riconciliazione.

Il Sistema dovrà garantire che i report individuati possano consentire:

• Controllo concomitante: cioè in concomitanza con l'attività operativa, ossia devono potersi svolgere parallelamente alla gestione mostrando per le operazioni non ancora compiute (come ad esempio piani e progetti formativi) sia la situazione (per esempio, gli esborsi e/o le ore erogate) al momento dell'effettuazione dell'analisi sia la previsione del rimanente, oltre che la valutazione degli indicatori;

• Controllo conseguente: cioè in seguito alla chiusura dei cicli di gestione (Es. di un piano, di un progetto, di un avviso, di un periodo di rendicontazione dovuto) deve essere eseguita la

relativa analisi e la valutazione degli indicatori sulla base delle misurazioni finali relative al ciclo concluso.

E' ipotizzabile che l'analisi e la generazione dei report vengano in parte effettuati sulla base di una copia (appositamente strutturata per facilitare l'esecuzione delle interrogazioni sottostanti) delle informazioni presenti nella base dati del Fondo, purché tale copia venga mantenuta aggiornata con frequenza adeguata (per es. Giornaliera). Tecniche di questo tipo sono frequentemente riferite con il nome di “staging”. Da questo sono escluse ovviamente le analisi che richiedono obbligatoriamente la disponibilità dei dati “in tempo reale”.

4.2.6 Scambio dati bidirezionale con il programma di contabilità

L’Ufficio Amministrazione utilizza un programma di contabilità prodotto da ESA Software da e verso il quale sarà necessario trasferire le informazioni di interesse (budget, anticipi, saldi, ecc.) al fine di consentire un corretto livello di automazione.

Caratteristiche del Sistema

Il Sistema dovrà produrre, secondo le modalità operative più efficienti ed efficaci per l’utente, flussi di export ed import da e verso il prodotto gestionale dell’Ufficio Amministrazione.

4.3 Processi di Marketing

4.3.1 Gestione Rapporti e Contatti con Xxxxxxxx, Attuatori, Prospect

Il Fondo ha la necessità di gestire la comunicazione tra i vari uffici e gli Aderenti al Fondo, gli Attuatori, le Aziende Beneficiarie e la comunicazione con gli eventuali Prospect, anche per l’invio di documentazione e Newsletter.

Caratteristiche del Sistema

Il Sistema, secondo criteri individuati in sede di definizione dei requisiti, dovrà essere in grado di ricavare le informazioni di contatto dalle diverse basi dati a disposizione (anagrafica degli Attuatori o dei Beneficiari, Database INPS, Prospect, etc.).

4.3.2 Gestione di Piani di Marketing e Relativi Follow-up

L’Ufficio Marketing ha la necessità di strumenti a supporto delle sue attività. In particolare richiede strumenti in grado di poter analizzare su più livelli e per studiare i trend delle informazioni riguardanti i Piani Formativi e poter eventualmente svolgere campagne di Marketing più mirate e puntuali (per esempio studiare in una particolare regione quali sono le tematiche che nel corso degli avvisi hanno generato maggior interesse).

L’Ufficio Marketing ha la necessità di avere strumenti per la gestione dei contatti (con la gestione della multicanalità dei contatti stessi) e nella relazione con i destinatari degli stessi, che siano in grado di interfacciarsi con il Sistema Informatico che gestisce il ciclo di vita degli avvisi per misurare l’efficacia delle campagne di marketing e dei relativi follow-up.

Caratteristiche del Sistema

Il Sistema, secondo criteri e modalità individuate in sede di definizione dei requisiti, dovrà supportare l’Ufficio Marketing, nella gestione de:

• i rapporti con Articolazioni locali, Aderenti, Prospect

• le campagne di marketing, dei Prospect e dei relativi Follow-up

• i dati forniti dall’INPS

• le Aziende Beneficiarie

• Visualizzazione stato e performance del servizio di Help Desk tecnico e di merito

4.4 Strumenti di supporto ed infrastrutturali

4.4.1 Gestione Help Desk

Per assistere gli Attuatori, il Fondo intende continuare a fornire un servizio relativo a due Help Desk separati e tra loro indipendenti:

a. Help Desk Normativa, per la compilazione dei Formulari, che risponde ai dubbi ed assiste gli Attuatori nella compilazione NEL MERITO dei formulari per la presentazione. Tale servizio opera sotto la supervisione dell’Ufficio Formazione e non è oggetto del presente appalto.

b. Help Desk Tecnico, che assiste gli Attuatori nelle problematiche riscontrate NELL’UTILIZZO degli applicativi del sistema sw. Non risponde a dubbi NEL MERITO della compilazione. Si fa carico di scalare la richiesta di intervento ad un secondo livello, se necessario. Tale servizio opera sotto la responsabilità del Fondo con la supervisione dell’Ufficio Organizzazione. È oggetto del presente appalto la gestione dell’help desk di secondo livello che sarà a carico del Fornitore.

Caratteristiche del Sistema

Gestione supervisione Help Desk Tecnico

L’Ufficio Organizzazione ha competenza sull’attività svolta dall’Help Desk Tecnico. Il Sistema dovrà supportare l’Ufficio affinché possa:

• Inserire i ticket di intervento;

• gestire e monitorare l’attività dell’Help Desk Tecnico, o comunque essere automaticamente collegato al sistema di help desk Tecnico implementato dal Fornitore;

• visualizzare ed accedere a tutti i ticket aperti, con evidenza di quelli aperti relativamente ad attività che richiedono una autorizzazione da parte dell’Ufficio Organizzazione ed essere abilitato ad autorizzare o negare l’esecuzione dell’operazione richiesta

• visualizzare, dato in input l’eventuale codice di un Piano o di un progetto, o il riferimento di un Attuatore, i ticket di help desk aperti e accedere alle informazioni relative ad essi;

• visualizzare lo stato dei vari ticket ed in particolare:

o il testo originale,

o le note eventualmente inserite dall’operatore di Help desk

o le tempistiche relative a tale ticket:

− data ed ora apertura ticket,

− data ed ora di presa in carico ed username dell’operatore,

− data ed ora di chiusura del ticket)

o eventuali autorizzazioni alla modifica e relative informazioni:

− data ed ora di autorizzazione,

− utente che ha autorizzato o negato l’esecuzione,

− esito.

• visualizzare lo storico dei ticket di Help Desk.

• avere la disponibilità di cruscotto con indicatori che permettano di monitorare l’aderenza del servizio di Help Desk Informatico con gli standard di qualità previsti da contratto.

• avere disponibili strumenti statistici che segnalino:

o i tempi medi di presa in carico (misurato in ore) dagli operatori dell’Help Desk,

o il tempo medio per la risoluzione e chiusura della pratica,

o il numero di pratiche i cui tempi di soluzione siano superiori ad una soglia (al netto dei tempi di attesa per autorizzazione da parte degli uffici per le rispettive competenze) ,

o i ticket di Help Desk affetti da tempi di risoluzione sopra la soglia definita.

4.4.2 Gestione Documentale

L’operatività del Fondo prevede una grossa mole di documentazione da e verso le diverse tipologie di utenze, in particolare tra Uffici Formazione, Amministrazione, Organizzazione ed Attuatori.

Allo stato attuale non tutti i documenti prodotti/scambiati sono automatizzati o digitalizzati, ma è interesse del Fondo, nel tempo, ridurre al minimo lo scambio di documentazione cartacea.

Si ritiene quindi necessario l’utilizzo di una infrastruttura documentale che sia di supporto a tutte le fasi del processo di gestione consentendo la gestione integrata dei documenti.

Caratteristiche del Sistema

Il Sottosistema di Gestione Documentale, deve fornire agli operatori del Sistema tutti gli strumenti necessari per minimizzare la necessità di utilizzare documenti su supporto cartaceo. Esso costituisce un componente fondamentale del sistema.

Vari tipi di documenti vengono ricevuti, generati, trattati e diffusi in ogni fase di ogni ciclo operativo del sistema.

Il Sottosistema di Gestione Documentale dovrà prevedere:

• la generazione di un protocollo standard attivato dal sistema per la produzione di documenti PDF da essa generati

• la generazione del Protocollo anche per documenti passivi non generati dal sistema ma archiviati manualmente dal Fondo

• la fruibilità della documentazione all’interno del sistema per i soli utenti del Fondo regolato in base al profilo di autorizzazioni dell’utente autenticato

• l’archiviazione in automatico tutti i documenti inviati dagli utenti interni del Fondo ed esterni nel relativo Archivio Documenti Digitali.

• un’interfaccia direttamente presente nel nuovo sistema per operazioni di archiviazione, ricerca e successiva fruizione dei documenti

• la suddivisione dell’Archivio Documenti Digitali in aree così definite:

o Modulistica emanata dal Fondo

o Archivio documenti prodotti dall’Applicazione

5. Attività oggetto della fornitura

Nel presente paragrafo si dettagliano tutti gli elementi e le attività oggetto della fornitura. Per ciascuno si dettagliano le caratteristiche in base alle quali il rispondente dovrà uniformare la propria offerta. L’aderenza a tali caratteristiche costituirà oggetto di valutazione sia qualitativa che quantitativa.

5.1 Delivery delle Infrastrutture Tecnologiche

5.1.1 Caratteristiche richieste per la SDP (Service Delivery Platform)

Da un punto di vista infrastrutturale, la piattaforma di erogazione dei servizi dovrà garantire le caratteristiche seguenti:

• alta affidabilità e disponibilità realizzata sia attraverso il software che l’hardware ( High Availability, Fault Tolerance e Fail Over, Load Balancing)

• scalabilità della soluzione, prevedendo la possibilità di espansione del sistema elaborativo, di un servizio o dei componenti modulari dell'applicazione software (es. sulla base del numero di utenti, di incrementi prestazionali, incrementi del volume di dati stimato, ecc.), dei componenti HW e SW basati su architetture “multinodo” e “multiprocessore”, che possano consentire operazioni di “scalabilità verticale” (ossia potenziamento degli elaboratori utilizzati) e di “scalabilità orizzontale” (ossia aumento del numero di elaboratori inizialmente previsti);

• sicurezza dei servizi erogati e dei dati gestiti, sia dal punto di vista logico che fisico. Tutti i sistemi di sicurezza logica della infrastruttura di rete saranno implementati e gestiti dal FAPI o da suoi delegati.

Il fornitore dovrà predisporre una dettagliata descrizione dei building blocks delle componenti infrastrutturali della piattaforma di erogazione proposta e di supporto alla gestione dell'infrastruttura e delle motivazioni delle scelte effettuate. Ciascuna componente applicativa dovrà essere pienamente integrabile con gli ambienti software di supporto individuati (per es. dataserver, frameworks, etc., ...) e/o realizzati ed in tal senso certificata dal “produttore” del Software di mercato offerti/utilizzati/previsti.

Inoltre, dovranno essere dettagliati i requisiti di compatibilità e di certificazione della piattaforma applicativa con le apparecchiature HW e gli ambienti di virtualizzazione, sistemi operativi e infrastrutturali di corredo utilizzate.

5.1.2 Principali requisiti per i componenti realizzati su architetture WEB

• rispetto dei requisiti di accessibilità (legge n. 4 del 9 gennaio 2004),

• aderenza alle raccomandazioni del World Wide Web Consortium (W3C) [HTTP 1.1, HTML 4.0.1

• strict XHTML (eXtended Hypertext Markup Language) 1.0 strict o XHTML 1.1, e CSS 2.0 e xForms (eXtended Forms)];

• compatibilità con i browser: Internet Explorer 8.x o superiori, Safari ultima versione, Firefox ultima versione (obbligatori); Opera 6.0/7.0 o superiori (raccomandato); Google Chrome 3.0 o superiori (raccomandato);

• accesso sicuro a pagine web secondo gli standard SSL 2.0 (obbligatorio) e SSL 3.0 (opzionale);

• compatibilità con i principali standard relativi alla gestione dei contenuti [JSR 168, JSR 170, WSRP 1.0];

• compatibilità con gli standard XML, RDF, RSS relativi ai formati di descrizione dei contenuti;

• compatibilità con gli standard internazionali ISO 9241-11, ISO 9126-4: effectiveness, efficiency, (safety), satisfaction.

5.1.3 Caratteristiche di sicurezza

Aderenza a standard e raccomandazioni

Le applicazione enterprise in ambienti Internet e Intranet sono sottoposte ad una varietà di minacce, infatti il sessanta per cento degli attacchi alle applicazioni sono facilitate dalla vulnerabilità sfruttabili presenti nel codice sorgente.

Molti attacchi che compromettono la disponibilità delle applicazioni e l'integrità e la confidenzialità dei dati sfruttano errori di codifica introdotti a livello di sorgente delle applicazioni, che avrebbe potuto essere facilmente evitato utilizzando dei framework architetturali più idonei e buone pratiche nello sviluppo del codice. L'aderenza a raccomandazioni e standard di varie organizzazioni permettono quindi di ottenere un maggiore livello di qualità e sicurezza delle applicazioni. come ad esempio OWASP , NIST , ecc., i quali incidono nell'elevare il livello qualitativo delle applicazioni realizzate.

I criteri per la valutazione della sicurezza delle applicazioni ruotano in ogni caso attorno ai servizi di sicurezza di base conosciuti collettivamente come CI4A che identificano la Riservatezza (confidenzialità del dato), Integrità (salvaguardia del dato in termini di validità della informazione ed esistenza), Autenticazione (identificazione di chi accede), Autorizzazione (profilazione di accesso), Disponibilità (rendere il dato disponibile quando serve) , Accountability (intesa come tracciamento della attività svolta legata al rendere conto dell’azione fatta o fatta fare)

Conformità alle normative italiane in ambito privacy

Nell'ambito dei dati personali è richiesta la conformità dell'infrastruttura applicativa e della piattaforma di erogazione dei servizi alla normativa vigente sul trattamento dei dati personali, il Decreto legislativo 196/2003 “Codice in materia di protezione dei Dati Personali” e in particolare ai requisiti minimi di sicurezza per garantire: integrità, confidenzialità dei dati sia nella comunicazione, sia nella custodia ed accesso, con espressa aderenza alle normative vigenti.

I diversi componenti applicativi e di supporto devono inoltre permettere di integrarsi con eventuale infrastrutture di gestione degli utenti Amministratori di Sistema e degli account delle applicazioni batch ed esterni accedono ai repository attraverso protocolli standard di riferimento di gestione come LDAP e permettere anche il tracciamento anche esterno degli accessi su server dedicato, attraverso protocollo SYSLOG, al fine di essere conformi al Provvedimento a carattere generale - 27 novembre 2008 del Garante della Privacy sull'operato degli Amministratori di Sistema.

5.1.4 Gestione utenti

Gli utenti interni ed esterni dei sistemi del FAPI sono oggi circa 400, l’associazione dei ruoli agli utenti può essere o meno soggetta ad approvazione in relazione ai privilegi specifici del ruolo.

Il sistema di gestione degli utenti dovrà gestire e tracciare le tre principali fasi legate alla gestione delle identità degli utenti esterni, interni :

• Authentication: il modulo gestisce il processo di autenticazione di un utente che si collega al sistema e che viene riconosciuto in base alla credenziali di accesso ;

• Authorization - Accesso controllato: il modulo fornisce alle applicazioni le informazioni sull’utente e le sue autorizzazioni di accesso . Un esempio di modello utilizzato è di tipo RBAC (Role Based Access Control) ;

• Profile Manager: il modulo gestisce tutte le entità del sistema di autorizzazione (utenti, ruoli, gruppi, permessi), consente la gestione flessibile di informazioni aggiuntive per ogni utente e abilita la gestione autonoma del profilo personale.

Il sistema dovrà preferibilmente fornire una funzionalità di accesso in Single Sign-On che abilita un utente ad identificarsi una sola volta e ottenere l'accesso a differenti servizi delle applicazioni senza la necessità di una successiva fase di identificazione. L'identificazione può avvenire sia in modalità debole che forte.

5.2 Software Solution

Il Sistema dovrà gestire ed automatizzare tutti i processi descritti nel paragrafo “4 - Processi da Automatizzare e Strumenti Infrastrutturali”.

Al rispondente si chiede di descrivere la soluzione software proposta tenendo presenti le caratteristiche generali e gli elementi funzionali descritti di seguito.

5.2.1 Caratteristiche Generali

Il Sistema di gestione descritto al paragrafo 4 ha due macro caratteristiche generali di cui il rispondente dovrà tener conto in fase di risposta:

• un sistema informativo con un’architettura logica in grado di supportare l’aggiornamento dei dati e i protocolli di comunicazione standardizzati con INPS, Ministero del Lavoro e ISFOL per l’input e l’output dei dati (business intelligence)

• un sistema di workflow e cooperazione applicativa in ambiente web-based per la gestione del passaggio dati, la pubblicazione dinamica sul web degli Avvisi e la conseguente gestione documentale.

Per quanto riguarda il punto 1 si richiede:

• La progettazione/configurazione di strumenti per l’elaborazione statistica dei dati, la predisposizione e la pubblicazione sul sito e in backend di report e output grafici che favorisca le attività di monitoraggio e rendicontazione previste, garantendo anche un flusso bidirezionale di informazioni dal sistemi locali ai sistemi delle Amministrazioni centrali, nel rispetto delle leggi sulla privacy.

• Rielaborazione di un data model condiviso in risposta alle esigenza di individuazione di indicatori prioritari e di elaborazioni e analisi statistiche avanzate da mettere a disposizione del personale FAPI.

• L’aggiornamento e implementazione di protocolli interni e protocolli esterni necessari per il trasferimento e la normalizzazione dei microdati sulla base delle modalità di transcodifica e delle specificità di importazione rilevate durante la ricognizione sullo stato dei sistemi statistici ed informatici, dei tracciati e delle codifiche dei dati delle fonti esterne.

Per quanto riguarda il punto 2 si richiede che il software presenti livelli intrinseci di flessibilità in grado di supportare il Fondo e gli garantisca la possibilità di specificare di volta in volta, semplicemente e velocemente, le informazioni trattate, le regole di trattamento e le procedure di gestione di tali informazioni.

La flessibilità richiesta dall’alta variabilità di cui sopra dovrà applicarsi nelle seguenti fasi operative:

• In fase di definizione Avviso

• in fase di Presentazione Piani;

• in fase di Valutazione Piani;

• in fase di Gestione Piani;

• in fase di Rendicontazione e Monitoraggio.

Di conseguenza, si richiede:

• Lo sviluppo di un sistema di workflow, in ambiente distribuito, web developed con metodi standard (service XML con trasporto in modalità sicura) e tempistica prestabilita, che permetta di gestire tutte le fasi di validazione e monitoraggio dei processi collegati agli Avvisi.

• La creazione della procedura (batch + logging) configurabile per l'esecuzione automatica delle procedure di post-caricamento (generazione tabelle derivate, rigenerazione viste, encoding dati, trattamenti, normalizzazione secondo dizionario)

• La progettazione di un sistema di amministrazione che consenta di creare in maniera strutturata, semplice e veloce le maschere di inserimento dei dati e di upload delle informazioni, in modo tale da prevedere un ricorso minimo ad attività di manutenzione evolutiva e da assicurare al Fapi la massima autonomia nella creazione della documentazione

• La progettazione di un sistema documentale a supporto dell’inserimento, dell’archiviazione, della taggatura e del tracking della documentazione da parte del Fapi e delle aziende.

• La progettazione di un’interfaccia web per il caricamento e l’aggiornamento dei dati da parte delle aziende.

• L’ideazione, progettazione e realizzazione di un portale di front-end con accesso riservato per l’interazione con gli Avvisi e la presentazione dei Piani formativi. Il portale dovrà essere alimentato da un CMS (Content Management System) con funzioni di amministrazione.

In particolare, le caratteristiche di flessibilità e autonomia del Sistema devono essere fruibili dai vari uffici per le rispettive competenze.

Il Sistema, oggetto del presente bando, dovrà garantire l’adattabilità all’evoluzione continua delle attività del Fondo, intendendo sia l’evoluzione in termini di variazioni procedurali imposte dalla normativa interna ed esterna a cui fa riferimento il Fondo stesso, sia l’evoluzione in termini di crescita delle risorse dedicate alla formazione continua che il Fondo amministrerà. Di conseguenza modelli, moduli, procedure non dovranno essere “cablati” nel Sistema ma essere costruiti dinamicamente e interattivamente sia durante lo sviluppo del Sistema stesso che durante l’esercizio e gestiti dal sistema stesso come oggetti di lavoro da condividere, pubblicare, scambiare, modificare, cancellare, validare.

Ogni sottosistema o modulo dell'applicazione dovrà essere completamente e coerentemente integrato con gli altri sottosistemi o moduli per quanto riguarda i dati gestiti. Ciò significa, in particolare, che il database di riferimento dell'applicazione sarà unificato e adeguatamente normalizzato, allo scopo di evitare duplicazioni e l’inconsistenza dei dati.

Il Sistema dovrà presentare un'interfaccia utente grafica intuitiva, snella, coerente. Dovrà essere adottato ogni accorgimento affinché l'utente possa essere "naturalmente" guidato e facilitato nell'utilizzo dell’Applicazione. Dovrà essere curata la razionale organizzazione delle transazioni complesse, prestando particolare attenzione alle caratteristiche di usabilità quali: intuitività, composizione e disposizione delle maschere a video, organizzazione dei menu e delle funzioni, disponibilità nelle operazioni d’input di dati precaricati e ogni altro accorgimento atto a facilitare i compiti degli utenti.

Tutte le informazioni d’interesse degli utenti dovranno essere ricercabili sia attraverso funzioni standard, che automatizzino le richieste ricorrenti con maggiore frequenza, sia in maniera non predefinita, utilizzando schemi il più possibile liberamente definiti dall'utente per l'estrazione parametrica dei dati secondo le diverse esigenze e privilegi degli utenti. I risultati delle interrogazioni dovranno poter essere visualizzati, stampati su dispositivi locali ed esportati secondo i più comuni formati come sotto definito.

Il Sistema dovrà prevedere specifiche funzionalità che forniscano opportuni "template" per la predisposizione di modulistica standard secondo schemi predefiniti, personalizzabili dall'utente e compilabili a partire dalle informazioni contenute all’interno della Base di Dati.

5.2.2 Requisiti Funzionali

Con la finalità di assicurare il massimo della flessibilità, si riportano di seguito una serie di funzionalità che il FAPI considera fondamentali per il funzionamento del Sistema.

L’elenco, strutturato per macroaree, è stato elaborato per presentare in maniera atomica tali funzionalità..

Al rispondente si richiede di indicare se la soluzione software proposta copre in maniera nativa, ovvero attraverso configurazione, ovvero attraverso apposita attività di sviluppo la funzionalità elencata (la segnalazione di tale dettaglio è facilitata tramite apposita tabella presente nel Disciplinare di Gara).

Nella tabella sottostante, si riportano nel dettaglio le funzionalità per le quali si richiede il rilascio nella Prima Fase di fornitura e quelle che dovranno essere rilasciate nella Seconda Fase.

In linea generale, dal punto di vista dello sviluppo:

- le funzionalità richieste nella Fase 1 coprono le esigenze espresse al paragrafo “4.1 - Processi di Gestione Avvisi e Piani Finanziati”

- mentre le funzionalità previste nella Fase 2 completano quelle di cui alla prima Fase e prevedono lo sviluppo delle esigenze legate ai paragrafi “4.2 - Processi di Controllo e Monitoraggio” e “4.3 - Processi di Marketing”.

In sostanza, al Fornitore si chiede di rilasciare durante la Prima Fase le funzionalità che supportano le attività core del Fapi, e durante la Seconda Fase quelle accessorie e di servizio.

Ambito	Funzionalità					Codice	FASE
Workflow Sicurezza	e	Organizzazione del lavoro editoriale di una redazione distribuita, assegnando compiti e responsabilità differenti ai				WF 01	1
		vari utenti; il workflow implementato dal Sistema deve
		soddisfare i requisiti di moderazione concordati con il
		Committente in base alle risorse disponibili e
		all’organizzazione del lavoro degli addetti al back-office..
		Gestione avanzata dei collaboratori del progetto, di modo che possano essere dotati di permessi e ruoli diversi per cooperare				WF 02	1
		su aree e sezioni differenti secondo un sistema gerarchico a più
		livelli.
		Progettazione e Realizzazione di flussi di lavoro complessi attraverso i concetti di utente, ruolo e gruppo, e l'associazione				WF 03	1
		di questi a determinate categorie di contenuto, del sistema.
		Gestione avanzata dei profili e assegnazione a ciascun profilo di ruoli, visibilità e funzioni differenti per oggetto, funzionalità,				WF 04	1
		step di workflow.
CMS	Creazione di pagine web a partire da template standard inserendo e modificando i contenuti utilizzando un'interfaccia					CM 01	1
	WYSIWYG simile a quella dei più comuni programmi di Word
	Processing (editor).
	Predisposizione di funzionalità di editing: scrittura e formattazione del testo, inserimento e formattazione di					CM 02	1
	immagini, gestione di link a risorse e pagine interne o esterne; il
	tutto generando un codice valido secondo gli standard e
	semanticamente corretto oppure segnalando le difformità
	quando non lo fosse.
	Caricamento, categorizzazione, versioning, e archiviazione nel repository del sistema di qualsiasi tipo di contenuto o oggetto					CM 03	1
	digitale, destinato al web o ad altri media .
	Predisposizione di funzioni	di	download	dei	contenuti	CM 04	1
	documentali e multimediali.					CM 04
	Organizzazione e strutturazione delle informazioni in categorie					CM 05	1
	e sottocategorie tra di loro legate da vincoli di subordinazione.					CM 05
	Collegamento di ciascun contenuto a più di una categoria.					CM 06	2
	Gestione del versioning dei contenuti, mantenendo le tracce					CM 07	1

Ambito	Funzionalità	Codice	FASE
	della loro evoluzione nel corso del ciclo di vita informativo. Per ogni revisione occorre poter risalire all’autore e alla data di modifica.
	Organizzazione delle risorse multimediali in gallerie fotografiche con il resize automatico delle immagini e gallerie video.	CM 08	2
	Disponibilità di un ambiente di anteprima e di test prima della pubblicazione	CM 09	1
	Creazione e gestione di FAQ.	CM010	2
	Creazione/generazione della “versione stampabile” delle pagine.	CM 11	1
	Gestione dei menu a qualunque livello della struttura	CM 12	1
SEO	Generazione automatica della sitemap del sistema	SEO 01	1
SEO	Possibilità di associare da back end del CMS i metadati necessari all’indicizzazione delle pagine	SEO 02	1
Form Builder	Creazione di form online attraverso un’interfaccia semplice ed usabile	FB 01	1
	Impostazione parametrica per ciascun campo delle regole di compilazione	FB 02	1
	Impostazione parametrica di regole di compilazione e controlli intercampo che consentano di collegare la compilazione di un campo al contenuto di un altro	FB 03	1
	Impostazione di messaggi specifici di errore per ciascuna regola utilizzata	FB 04	1
	Impostazione parametrica dell’obbligatorietà/non obbligatorietà di compilazione	FB 05	1
	Impostazione di controlli di congruità dei campi a partire da flussi dati messi a disposizione da banche dati esterne (es.: INPS, etc.)	FB 06	1
	Disponibilità di sistemi di precompilazione dei campi a partire da elementi minimi inseriti (es.: da Codice Fiscale a comune di nascita) attraverso l’interfacciamento con fonti dati esterne	FB 07	1
	Associazione di ciascuna form con altre form pubblicate in un insieme coerente di elementi che, insieme, determinino un percorso coerente di immissione dati.	FB 08	1
	Associazione per ciascuna form di specifici livelli di visibilità.	FB 09	1
	Disponibilità di campi di upload della documentazione con conseguente associazione della stessa al profilo dell’utente che ha compilato i dati in fase di archiviazione e al bando di riferimento.	FB 10	1
	Parametrizzazione delle repository di archiviazione.	FB 11	1

Ambito	Funzionalità	Codice	FASE
	Associazione per ciascun campo/o per gruppi coerenti di campi in modo da consentire la creazione di form diverse per utenti tipologicamente distinti in base alla profilatura prevista dal sistema.	FB 12	1
	Collegamento delle form a db specifici (il db conserverà le relazioni dati tra le form come stabilito in fase di creazione).	FB 13	1
	Associazione alla form di metadati di sistema come ad esempio le credenziali dell’utente logato a sistema al momento della compilazione.	FB 14	1
Logging e Reporting	Visualizzazione in ambiente di amministrazione i dati derivanti dalla compilazione degli utenti	LR 01	1
	Disponibilità di interfacce semplici per creare incroci, relazioni e calcoli tra i record del db	LR 02	2
	Disponibilità di funzioni statistiche di elaborazione dei dati	LR 03	2
	Pubblicazione di specifici dataset a partire dai dati presenti a db.	LR 04	2
	Personalizzazione dei report a partire dai parametri del db	LR 05	2
	Esportazione dei dati in diversi formati (.csv; xlsx; pdf; etc.)	LR 06	1
	Possibilità di impostare un ambiente di monitoraggio che consenta di visualizzare dati sintetici e graficizzati finalizzati al controllo delle operations.	LR 07	2
	Meccanismi di monitoraggio delle attività ("log") per tracciare tutte le interazioni utente/sistema (identificativo dell'utente, data-ora e tipo della transazione, operazione svolta, ecc.).	LR 08	1
	Visualizzazione e/o stampa dei dati e delle sintesi grafiche e non.	LR 09	2
	Configurabilità dei livelli di visualizzazione dei log attraverso appositi parametri.	LR10	2
Web Reporting	Disponibilità di reportistica sugli accessi orari/giornalieri/mensili che riporti in forma anche aggregata le caratteristiche delle visite quali: pagina di entrata, pagina di uscita, durata della visita, url di provenienza, località geografica dell’ip, sistema operativo, lingua e browser utilizzato.	WR 01	2
Integrazione	Importazione da sorgenti esterne di flussi di dati: l'integrazione può avvenire "on-the-fly", ripresentando nello spazio di navigazione gestito dal CMS i contenuti esterni, o essere più profonda e trasformare questi contenuti in oggetti gestiti dal sistema e conservati nel suo repository.	IN 01	1
Integrazione	Esportazione dei contenuti in formato XML e servirli ad altre applicazioni.	IN 02	1
Publishing	Costruzione di template capaci di separare il contenuto dall’aspetto grafico attraverso skin CSS applicabili all'intero	XX 00	1

Ambito	Funzionalità	Codice	FASE
	sistema, a sezioni o a singole pagine. Il sistema di gestione dei temi del CMS deve permettere di definire la modalità di visualizzazione del sito, l’aspetto grafico, il layout, i colori.
	Gestione delle URL in modo personalizzato sia tramite regole predefinite che definibili manualmente per rendere più facilmente individuabili gli Avvisi.	XX 00	2
	Ambiente di amministrazione per la modifica veloce degli elementi portanti dei template (colori, elementi grafici, immagini, etc.)	XX 00	1
Campaign	Pubblicazione schedulata degli Avvisi e dei documenti (e relativa revoca della pubblicazione, previo invio di messaggi di avviso, nonché cancellazione) in base a data e ora.	CA 02	2
Campaign	Invio delle comunicazioni a specifiche tipologie di utenti target in base a criteri oggettivi desumibili dal profilo	CA 09	2
Search engine	Funzione di ricerca ipertestuale all’interno del sistema sia nei contenuti in database che in documenti.	SE 01	1
Workflow Management	Process engine di creazione di eventi definiti da regole standard e concatenati in un processo strutturato con qualunque oggetto creato a sistema (form; documenti; pagine web; eventi; etc.)	WM 01	1
	Creazione di regole a qualunque livello del processo e impostazione di criteri stabili di valutazione	WM 02	1
	Impostazione di regole di comunicazione con destinatari definiti per ciascun blocco di processo e al verificarsi di qualsiasi evento.	WM 03	1
Accessibilità e usabilità	Piena conformità del CMS agli standard internazionali del World Wide Web Consortium (W3C);	AU 01	1
	Conformità agli standard internazionali (linee guida WCAG del WAI/W3C) e rispetto della normativa italiana (Legge n. 4/2004, Regolamento attuativo DPR 75/2005 e D.M. dell’8 luglio 2005);	AU 02	1
	Rispetto delle linee guida per i siti web delle Pubbliche Amministrazioni art. 4/09 delle direttive del Ministro per la Pubblica Amministrazione e Innovazione del 26 luglio 2010;	AU 03	1
	L’interfaccia utente del sistema deve essere accessibile utilizzando i seguenti browser: Internet Explorer rel. 8 o sup., Mozilla Firefox ultima versione Google Chrome ultima versione, Apple Safari ultima versione.	AU 04	1

Il rispondente deve tener presente che:

• l’elenco delle funzionalità riportate non deve considerarsi esaustivo delle caratteristiche del Sistema

• L’elenco delle funzionalità riportate non sostituisce in nessun modo l’attività di raccolta di requisiti che sarà in carico all’Azienda aggiudicatrice all’inizio dello svolgimento dell’incarico

Le informazioni fornite attraverso la tabella precedentemente mostrata, andrà a suffragare la valutazione di adeguatezza della soluzione software proposta.

In linea generale in fase di valutazione tecnica, si terrà conto del fatto che la soluzione proposta preveda o meno moduli nativi/configurabili a copertura delle esigenze espresse perché, in termini generali, questo migliora le attività di sviluppo.

Tuttavia, tale valutazione va sempre considerata come elemento di controllo e non di valutazione. Il Fapi, infatti, si riserva di valutare la soluzione software nella sua complessità, ovvero in quali termini l’architettura, le risorse, la metodologia e il master plan coprono le esigenze funzionali dell’Organizzazione.

Per quanto concerne i requisiti di Accessibilità e Usabilità genericamente riportati nel punto elenco in alto, nei successivi paragrafi si specificano gli elementi da qualificare.

5.2.3 Licensing

Sulla scorta delle recenti normative (DL n.83 del 22 giugno 2012) e con la finalità di conservare la piena ed esclusiva proprietà del software sviluppato, il Fapi è indirizzato ad adottare in via preferenziale soluzioni software Open Source.

Tuttavia, è prevista la possibilità per il Fornitore di utilizzare, integrati nell’applicazione, componenti o prodotti software di terze parti concessi in licenza d’uso. Le condizioni per fare questo sono le seguenti:

• Piena responsabilità del Fornitore per quanto attiene il corretto funzionamento di tali componenti.

• Il Fornitore dovrà indicare il costo per l’acquisizione delle licenze d’uso, che devono essere illimitate e permanenti. Dovrà essere indicato il costo di listino di tali licenze, salvo particolari convenzioni con i produttori, avendo cura di segnalare tale particolare situazione.

• In caso il Fornitore scelga di utilizzare strumenti Open Source, esso dovrà garantire il pieno rispetto della licenza di utilizzo e la piena aderenza ad essa in tutte le sue parti.

• Nel caso in cui il Fornitore proponga la fornitura di un software commerciale in licenza d’uso già esistente sul mercato e sviluppato per coprire le esigenze dei Fondi di Formazione, all’offerta dovranno essere allegate le referenze verificabili di altri Clienti che già utilizzano il suddetto.

Qualora l’offerente scelga di presentare una soluzione software che preveda costi specifici di licenza, deve tener presente che:

• Il Fondo, nel caso non sia in possesso delle licenze d’uso richieste non è vincolato all’acquisto di esse dal Fornitore

• Il costo delle licenze dovrà essere compreso all’interno dell’offerta a “corpo” che il rispondente presenterà per il sistema complessivamente inteso.

Qualora il richiedente scelga di presentare una soluzione software Open Source deve tener presente che il framework di elezione deve avere:

• una reference pubblica

• una community attiva in termini di: mailing-list, blog, group

• aggiornamenti negli ultimi sei mesi solari

• librerie esterne integrabili e configurabili; le singole librerie devono essere riportate in un unico repository di riferimento per la tecnologia ed avere anch'esse le caratteristiche open source di cui sopra (reference, community, update/upgrade)

• le soluzioni applicative proposte devono far riferimento ad un unico framework per l'implementazione del core applicativo con la sola eccezione delle componenti di frontend (UI/UX framework).

Il rispondente dovrà presentare tutti i riferimenti sopra citati necessari a comprovare le caratteristiche del software.

5.3 Grafica

In fase di raccolta dei requisiti, al fornitore si richiede di realizzare un progetto navigazionale che specifichi l’organizzazione delle informazioni contenute nel sistema e dei modi di accesso alle funzionalità principali esposte da esso. Tale progetto dovrà consentire di comprendere i meccanismi di profilazione del sistema e l’associazione tra utenti ed aree funzionali.

Il progetto dovrà tener conto delle esigenze degli utenti così da modulare e diversificare i sistemi di navigazione e i diversi stili di ricerca (operatori di back-office, aziende iscritte, valutatori, revisori)

In particolare dovranno essere valutate e analizzate le seguenti tipologie di navigazione:

1. Navigazione tradizionale: che comprende strumenti di navigazione che rimarranno sempre presenti all’interno del sito (menù di navigazione principale, menù di servizio, footer)

2. Navigazione locale: che deve essere complementare alla navigazione tradizionale

permettendo l’accesso alle sottosezioni e alle singole funzionalità. Questa funzionalità deve essere coerente in tutte le pagine del sistema;

3. Navigazione per macrotarget: che deve consentire un accesso diretto ai contenuti di interesse per i principali target di utenza del portale;

4. Navigazione supplementare: quali ad esempio mappe del sito, indice, guide che possono essere utilizzati dagli utenti per orientarsi e navigare in modo più efficace.

La struttura deve essere tale per cui le pagine foglia non vengono replicate ma semplicemente diventano raggiungibili da percorsi diversi.

Il concept grafico elaborato per il portale dovrà essere accompagnato da specifici elaborati che consentano di comprendere le dinamiche di interazione, comunicazione e presentazione delle informazioni in un processo evolutivo di raccolta del requisito che consenta di individuare in anticipo la user experience delle interfacce.

La proposta grafica dovrà consentire di indirizzare:

• separazione netta tra contenuto e struttura;

• definizione delle cromie e dei codici pantone per i fogli di stile;

• definizione della libreria iconica;

• supporto iconografico e cromatico per la presentazione delle aree del sito;

• presentazione delle informazioni strutturate con tag html specifici;

• analisi delle tipologie di font-family utilizzabili per la nuova versione della pagina.

Scopo della progettazione grafica sarà la realizzazione di una creatività in linea con i nuovi standard delle applicazioni web e la produzione di un codice quanto più “pulito” possibile in termini di struttura e di contenuto. Nello specifico analizzando dettagliatamente le sezioni del sistema attraverso la presentazione dei blocchi informativi lo studio della creatività dovrà essere tarato sulle effettive possibilità di presentazione delle grafiche e dei contenuti veicolati.

Successivamente alla fase di design, dovrà essere realizzato un mock-up navigabile delle principali pagine del sistema con un minimo di interazione via user agent. Le soluzione grafiche proposte dovranno essere originali e saranno frutto dello studio dei concept accettati.

Il rispondente alla gara dovrà proporre una prima bozza di proposta grafica realizzata in base alle metodologie e agli standard normalmente usate all’interno della propria organizzazione o a quelle che ritiene più consone alle esigenze del Fapi. Nello specifico si richiede di produrre 4 distinti elaborati grafici:

Per la piattaforma web:

• un elaborato per la home page / pagina di atterraggio successiva alla login

• una pagina informativa / dispositiva Per il back end:

• una pagina di amministrazione del bando

Nel design di queste pagine, fatta salva la libertà di adottare le migliori soluzioni di presentazione/rappresentazione, si richiede di tener conto delle linee guida funzionali espresse al paragrafo 4.

5.3.1 Requisiti di Usabilità

Si richiede il massimo focus sulle specifiche di usabilità delle applicazioni e dei siti web facendo riferimento al W3C. Per la realizzazione del front end è necessario specificare attraverso quali funzioni si garantisce l’efficacia, l’efficienza e la soddisfazione degli utenti nell’ambito delle pagine pubbliche. Requisiti principali saranno:

• html semantico;

• utilizzo di marcatori standard;

• totale gestione della grafica attraverso i fogli di stile;

• design flessibile per essere visualizzato su definizioni di schermo al di sotto dello standard minimo 1024x768;

• ideazione e produzione banner e infografiche;

• ideazione e produzione utilities che migliorino funzionalità del sito (es. icone, filtri, etc.)

• consulenza per sviluppo nuovi applicativi/aree (es. bacheca, forum, etc.);

• miglioramento funzionalità “Ricerca”;

• migliore garanzia del rispetto dei tempi di intervento ;

• garanzia di intervento tempestivo (on request);

• progetto che migliori uso del back end e del versionamento dei contenuti;

• analisi su possibilità di sviluppo continuativo del portale.

5.3.2 Requisiti di accessibilità

Per garantire la corretta fruizione dei contenuti pubblicati nel sistema, è necessario utilizzare il corredo di buone pratiche derivanti dalla legge si accessibilità attualmente in vigore (Stanca 4, 2004). Considerando l’evoluzione dei dispositivi e degli user agent è concesso il non totale adeguamento ai 22 punti di controllo.

Per il front end del sito dovranno essere garantite:

• funzionalità javascript lato client e l’utilizzo di selettori CSS in grado di fornire attributi grafici ai contenuti del sito;

• utilizzo di funzionalità per gestire il focus utente su un’unica pagina (es. libreria light box);

• utilizzo di rich media;

• utilizzo di funzionalità per la gestione dei testi all’interno della pagina;

• sistemi di ancoraggio dei contenuti;

• sistemi di paginazione automatica;

• organizzazione strutturata dei moduli lato utente con gestione delle etichette e dei relativi controlli lato utente;

• sistemi di alert organizzati in base alla tipologia di user agent.

5.4 Organizzazione di progetto

Il rispondente dovrà fornire una dettagliata descrizione delle modalità con le quali intende affrontare il progetto di sviluppo del Sistema precedentemente descritto dimostrando di saper gestire metodologie standard di Project Management che consentano di massimizzare i risultati, minimizzare i rischi, creare e gestire un ambiente di lavoro efficiente e in grado di rendere disponibile il sistema nel minor tempo possibile.

In fase di valutazione si terrà in debito conto l’uso di metodologie di Project Management e di Software Development adeguate alle esigenze del Fapi e che lo supportino nel raggiungimento degli obiettivi suddetti consentendo un corretto controllo e tracciamento delle attività e a tutti i livelli della progettazione.

5.4.1 Fase di establishment

Il rispondente sarà chiamato a gestire la prima fase di analisi del contesto attuale, di establishment del gruppo di lavoro e di pianificazione dell’intero master plan di progetto. In particolare in riferimento alle attività sopra indicate al punto 1 si richiede:

• Attività di confronto e scambio con gli stakeholder interni al FAPI, finalizzate ad una condivisione strategica ed operativa degli obiettivi, delle metodologie di lavoro e dei prodotti attesi, così da realizzare procedure di collaborazione che consentano la capitalizzazione del patrimonio informativo del FAPI in un'ottica partecipata.

• Studio ed analisi preliminari del patrimonio informativo di microdati a disposizione del Fondo al fine di aggiornare e integrare il data model e le classificazioni a cui ricondurre le variabili in

sede di produzione statistica, anche in considerazione delle informazioni richieste a livello italiano, europeo e internazionale (ad esempio monitoraggi sui fondi interprofessionali).

• Analisi dei sistemi e dei formati disponibili per l’input dati nel Sistema e l’output richiesto dalle agenzie di controllo e dal sistema centrale del Ministero del Lavoro.

• Analisi dei sistemi informativi esistenti con particolare riguardo a quelli gestiti dai precedenti fornitori con l’obiettivo di gestire al massimo livello il knowledge transfert con i soggetti uscenti sia in relazione al patrimonio di conoscenze procedurali, sia in relazione a quello di gestione delle basi dati degli Avvisi gestiti con il vecchio sistema (ed eventualmente in corso)

5.4.2 Metodologia di organizzazione del progetto

Al rispondente si richiede di fornire un’adeguata descrizione delle metodologie di gestione del progetto e del ciclo di vita del software, dimostrandone l’efficacia.

La metodologia scelta dovrà comunque prevedere l’utilizzo del formalismo UML per la produzione della documentazione tecnica e di progetto e degli schemi ER per la documentazione relativa alle basi dati.

La ditta aggiudicataria deve predisporre un processo di sviluppo software che, dovrà contemplare tutte le attività previste nel ciclo di vita del software conformemente a quanto previsto dalla norma ISO/IEC 12207 information technology – software life cycle processes.

Tale processo, pertanto, deve includere le attività descritte nella tabella successiva (cfr.: Tabella 3 – Attività). Nella seconda colonna della tabella viene fornita una descrizione di massima degli obiettivi che deve avere la corrispondente attività.

Le effettive modalità di realizzazione della stessa possono, ovviamente, essere scelte dalla ditta aggiudicataria in base al proprio know how, al proprio sistema qualità e metodologie di lavoro, purché venga garantita l'esecuzione di tutte le attività di interesse e il raggiungimento degli obiettivi indicati.

Attività

Descrizione

Organizzazione, pianificazione e supervisione del progetto.

La ditta aggiudicataria deve eseguire attività di pianificazione e supervisione per:

• Sviluppo Software

• Test funzionale e di integrazione

• System test

• Installazione del Software

Predisposizione dell’ambiente di sviluppo

La ditta aggiudicataria deve predisporre gli ambienti necessari per lo sviluppo e la manutenzione dei prodotti software, garantendone l'adeguatezza, la funzionalità e l'affidabilità necessarie allo scopo riguardo a:

• Software engineering

• Software test

	• Gestione della configurazione
Analisi dei requisiti del sistema	La ditta aggiudicataria deve eseguire l'analisi dei requisiti del sistema in conformità con le procedure e le metodologie del proprio Piano di qualità. È richiesto alla ditta aggiudicataria di utilizzare strumenti informatici di supporto (ad es. CASE tools), che, tra l’altro, consentano di mantenere la tracciabilità tra i requisiti formalizzati ed i casi di test progettati, facilitando così la verifica della piena aderenza delle funzionalità sviluppate ai requisiti.
Progettazione del sistema	La ditta aggiudicataria deve eseguire la progettazione del sistema in conformità con le procedure e le metodologie del proprio Piano di qualità.
Realizzazione e Unit Test del software	La ditta aggiudicataria deve eseguire test specifici su ogni unità di software realizzata. La ditta aggiudicataria deve effettuare tutte le necessarie modifiche al software e rieseguire tutti i test necessari in base ai risultati del test.
Test di sistema (collaudo)	Per la pianificazione ed esecuzione del collaudo la ditta aggiudicataria deve conformarsi a quanto indicato nella Procedura di collaudo.
Installazione software	La ditta aggiudicataria deve preparare il software eseguibile, inclusi i file batch, completo di comandi, di dati e di ogni altro oggetto necessario per installare e far funzionare il sistema nell'ambiente operativo previsto. La ditta aggiudicataria deve identificare e registrare la versione esatta del software predisposto per ogni ambiente operativo, deve inoltre predisporre i manuali utente e operativi. La ditta aggiudicataria deve installare e controllare il software eseguibile sulle macchine destinatarie secondo quanto concordato caso per caso con l’Amministrazione interfacciandosi e fornendo supporto ai servizi di gestione operativa sia condotti dalla ditta aggiudicataria stesso che da altri Fornitori. La ditta aggiudicataria deve fornire copia della documentazione tecnica di progetto prodotta

secondo gli standard definiti e copia dei sorgenti dei singoli applicativi realizzati. L’installazione avverrà preliminarmente nell’ambiente di Test (tale ambiente riproduce quello di esercizio) e successivamente, dopo esplicita richiesta dell’Amministrazione,

nell’ambiente finale di esercizio.

Gestione della manutenzione Software

La ditta aggiudicataria deve identificare le entità da mettere sotto controllo di configurazione e deve assegnare a ciascuna di esse un identificatore univoco. Le entità in configurazione devono includere i prodotti software da sviluppare o utilizzare e gli elementi dell'ambiente di sviluppo.

La ditta aggiudicataria deve predisporre e implementare le procedure per individuare:

- i livelli di controllo per ciascuna entità in configurazione (ad esempio controllo dell'autore, del capo progetto, del cliente);

- le persone o i gruppi con l'autorità per autorizzare ed effettuare modifiche ad ogni livello;

- i passi da seguire per richiedere l'autorizzazione per le modifiche, elaborare richieste di modifica, tracciare e distribuire le modifiche e mantenere le precedenti versioni del software.

Deve essere mantenuta registrazione dello stato della configurazione di tutte le entità poste sotto controllo.

Avvio manutenzione correttiva

La ditta aggiudicataria darà l’accesso al sistema previsto per la manutenzione correttiva garantendo gli SLA previsti e rendicontando su base mensile gli interventi effettuati, in termini di numerosità, tempi di intervento e interazioni necessarie alla risoluzione dei problemi eventualmente segnalati.

Tabella 3 – Attività

5.4.3 Master Plan

Al rispondente si chiede al di presentare un proprio Master plan di progetto di dettaglio.

Il Fapi, considerando le proprie esigenze operative, ritiene necessario il rispetto delle seguenti tempistiche di massima calcolate a partire dalla stipula del contratto con la ditta aggiudicataria:

o 1 mese per establishment, analisi e progettazione:

o 11 mesi di realizzazione del software fino alla messa in esercizio;

Nella tempistica complessiva il rispondente dovrà ricomprendere:

o tutte le fasi necessarie ad un corretto sviluppo della soluzione software (raccolta requisiti, analisi funzionale, test, collaudo, sviluppo, etc.) in coerenza con la propria metodologia.

o Gli opportuni punti di controllo periodico che consentano di mostrare al Fapi l’effettivo stato di avanzamento lavori.

o Il punto di controllo di chiusura della Fase 1, nonché tutte le attività necessarie alla valutazione dei deliverable che consentiranno al Fapi di verificarne la congruenza e al fornitore di accedere o meno alla Fase 2.

I tempi riportati non sono comprensivi della fase di approvazione della documentazione di progetto da parte del Fapi.

Tenuto conto delle tempistiche di massima e a partire dalla distinzione tra Fase 1 e Fase 2, al rispondente si chiede di dettagliare il master plan specificando:

• le tempistiche di realizzazione delle singole fasi

• i razionali di parallelizzazione delle fasi (se previsto)

• i razionali di determinazione delle tempistiche e dei parallelismi proposti

• eventuali dipendenze tra le fasi

• i deliverable proposti per ogni singola fase

• le risorse coinvolte in ogni singola fase

La valutazione delle tempistiche proposte dal rispondente sarà effettuata tenuto conto:

• della completezza delle fasi proposte

• della correttezza metodologica delle stesse in relazione alla metodologia di sviluppo proposta

• del grado di parallelizzazione

• della coerenza delle tempistiche con le modalità di erogazione delle funzionalità (native/configurabili/da sviluppare)

Al di là della proposta del rispondente, in fase di avvio di progetto le attività di progettazione e implementazione saranno preventivamente stimate congiuntamente dalla committente e dalla ditta aggiudicataria, tutte le attività saranno schedate mediante un rapporto di inizio lavori.

Alla ditta aggiudicatrice sarà richiesto, entro 30 giorni solari dalla data di firma del contratto:

- un Master Plan definitivo che integri e/o sostituisca quello presentato in fase di gara

- un piano dettagliato di Risk Management che assicuri la riduzione/eliminazione dei rischi di progetto in relazione alle esigenze operative del FAPI al momento della stipula del contratto

5.4.4 Risorse di progetto

Per le attività che il FAPI assegnerà al Fornitore quest’ultimo dovrà garantire l'utilizzo di risorse con gli skills richiesti e con capacità adeguate a:

• lavorare su indicazioni fornite dal FAPI

• relazionarsi e collaborare con altri specialisti

• gestire e risolvere problemi in un contesto regolato da SLA

• esprimere orientamento al servizio

• operare in coerenza con processi, metodologie e standard indicati dal FAPI

Il Fapi si riserva di valutare il gruppo di lavoro e chiedere eventuali sostituzioni, anche nel corso del servizio.

Gli eventuali oneri di turn over del personale sono a carico del Fornitore. Qualunque sostituzione o integrazione di risorse da parte del Fornitore deve essere concordata con il Fapi, con un anticipo di almeno due mesi.

Il Fornitore nominerà un Coordinatore, responsabile dell’intera fornitura.

Il Fapi nominerà al suo interno il Responsabile del contratto. Il Fornitore deve garantire che le capacità e le competenze delle persone utilizzate siano consone ai requisiti richiesti ed alla tipologia di conoscenze e di tecnologie richieste. Il personale del Fornitore, preposto all’espletamento del servizio, non potrà essere sostituito senza il preventivo benestare della Committente. Questo particolare aspetto gestionale è ritenuto importante ed è pertanto richiesto che il personale sia dedicato al servizio in maniera permanente, salvo deroghe che debbono costituire eccezione, e che, comunque, dovranno essere sottoposte alla insindacabile accettazione della Committente.

I profili minimi richiesti sono i seguenti:

• Responsabile di progetto: referente unico con cui si interfaccia il Committente durante tutta la durata contrattuale.

• Project Manager: referente unico dell’attività di sviluppo.

• Information architect: responsabile della progettazione e analisi dell’architettura, dei processi e delle interfacce funzionali e software.

• DBA

• Analista Programmatore Senior/Consulente IT.

• Art Director/Web Designer.

• Web Developer.

• Analista Programmatore/Tester Senior

• Front-end developer

Dato l’elevato profilo delle risorse richieste e la specificità degli ambienti di produzione per l’attività, si richiedono esclusivamente risorse di provata competenza. Al fine di consentire una valutazione il più possibile oggettiva dei profili professionali che forniranno i servizi richiesti, l’appaltatore dovrà indicare i profili dei candidati indicando le seguenti informazioni:

• Figura professionale;

• Gestione gruppi di lavoro;

• Anzianità professionale ruolo;

• Esperienza in progetti nell’ambito della formazione e in ambito P.A.

I profili dovranno aver cumulato un’adeguata esperienza sugli ambienti di produzione e tipologie di servizi succitati ed aver preferibilmente lavorato in progetti presso le Pubbliche Amministrazioni e/o aziende di servizi pubblici. La ditta aggiudicataria, deve sempre impiegare risorse dotate di un regolare rapporto di lavoro con essa aggiudicataria, contrattualizzato nel rispetto della normativa vigente in materia.

Le figure professionali comprese nell’offerta presentata dal rispondente dovranno essere coerenti con il quadro delle attività delineato al paragrafo “5.4.4 – Risorse di progetto”.

5.4.5 Software a supporto delle attività di sviluppo e manutenzione

Si richiede che siano messi in esercizio e manutenuti, sotto la responsabilità del Fornitore, alcuni sistemi di supporto e d’interazione tra le attività del Fornitore e quelle del Fapi. Nello specifico, si tratta di sistemi per:

• Gestione delle revisioni;

• Gestione dei difetti;

• Supporto help desk (“Ticketing”).

Il Fornitore dovrà proporre le piattaforme software adatte allo scopo alle quali il Fornitore avrà accesso da tutte le postazioni in cui è previsto che abbia luogo attività di sviluppo.

Anche il Fapi avrà accesso a tali strumenti software primariamente per scopi di audit e di backup nonché per eventuali esigenze di gestione delle change request o dei ticket.

Le piattaforma software adottate dovranno rispettare i seguenti vincoli:

• Dovrà trattarsi di piattaforme sviluppate specificamente per gli scopi indicati;

• Dovranno avere caratteristiche tali da supportare la metodologia di sviluppo adottata dal fornitore e precedentemente descritta.

Il rispondente deve:

• Dimostrare che le componenti funzionali di tali piattaforme consentono di supportare le metodologie di sviluppo adottate;

• Assicurare che tutte le fasi di gestione delle change request e dei ticket saranno gestite tramite gli strumenti software segnalati;

• Assicurare in qualunque momento al Fapi e al personale incaricato l’accesso alle piattaforme;

• Assicurare un back up costante dei dati e delle informazioni immesse in queste piattaforme;

• Assicurare una corretta gestione delle risorse hardware sulle quali saranno installati tali software;

• Consegnare, al termine della fornitura, i dati e le informazioni contenuti in tali strumenti software in un formato universalmente leggibile ed esportabile (es.: csv)

Nel caso in cui le piattaforme scelte fossero soggette a costi per licenze d’uso o canoni, il costo relativo, in misura adeguata a soddisfare le esigenze di accesso da parte degli sviluppatori e da parte del Fapi, dovrà essere specificato nell'offerta economica da parte del Fornitore.

5.5 Help Desk Tecnico

Lo scopo del servizio è fornire, tramite e-mail, telefono, fax ed eventuale interfaccia ad un apposito modulo applicativo se implementato, assistenza agli utenti del Fapi per la gestione delle problematiche che gli Utenti Finali dovessero incontrare nell’uso del sistema.

Deve essere reso disponibile un servizio di help-desk di secondo livello per gli Utenti Interni del FAPI, dall‘entrata in esercizio del Sistema e fino alla conclusione dei servizi oggetto di questa fornitura.

Il Sevizio dovrà rispettare i seguenti Livelli di Servizio.

Requisito	Valore	Evento di controllo
Tempo di attesa per la presa in carico di una richiesta	< 1 hh lavorativa	Dalla segnalazione
Tempo di completamento della richiesta	< 8 hh lavorative	Dalla presa in carico
Orario erogazione servizio	9.00 – 18.00 dal Lun. al Ven., festivi esclusi
Disponibilità media del servizio	> 4 hh/gg lavorative

Disponibilità di picco (nel periodo di scadenza Avvisi)

per 4 volte/anno per 5 gg lavorativi consecutivi per

ciascuna delle 4 volte

>6 hh/gg lavorative

Tabella 4 - SLA del servizio di Help Desk tecnico

Come precedentemente indicato, il servizio potrà essere acceduto in modalità multicanale. Qualunque sia la forma di accesso si richiede che ogni richiesta ed il relativo intervento vengano registrati nel sistema di ticketing (eventualmente ad opera degli stessi operatori incaricati di fornire il servizio).

Il servizio telefonico sarà fornito tramite Operatore (persona fisica) e dovrà essere dimensionato in modo tale da garantire la connessione con gli operatori entro un tempo medio di attesa che ne garantisca la reale fruibilità da parte del Fapi.

Al di fuori dell'orario minimo di erogazione del servizio le segnalazioni potranno comunque avvenire tutti i giorni nell'arco delle 24 (ventiquattro) ore tramite fax o posta elettronica o tramite la Piattaforma di Ticketing, fermo restando che per il calcolo del livello di servizio (SLA) vengono sottratti i tempi relativi ad orari al di fuori del periodo di erogazione del servizio.

Il servizio di assistenza sarà fornito per tutta la durata del contratto a partire dal rilascio in esercizio del Sistema e fino al termine del periodo contrattuale.

Per tutta la durata del servizio il Fornitore fornirà con periodicità mensile al Committente una documentazione, anche in formato elettronico, sulle attività svolte. La documentazione conterrà gli elementi di riscontro principali per la valutazione del servizio e dell'impatto del sistema sugli utenti del Committente.

5.6 Assistenza Sistemistica

Vista la complessità del Fondo e del suo sistema informatico, il Committente richiede che il Fornitore sia in grado di sostenere con particolare impegno la qualità del proprio prodotto durante la sua vita operativa, al fine di conservare i livelli di efficacia ed efficienza che lo caratterizzavano al momento della sua messa in esercizio.

Per adempiere a tale scopo il Fornitore dovrà predisporre un adeguato servizio sistemistico per l'ottimizzazione e la messa a punto periodica dell'intero sistema installato (c.d. "fine tuning"), come di seguito definito all’interno della più ampia attività sistemistica che il Fornitore è tenuto a svolgere.

Per "gestione" in questo caso si intende l'insieme organizzato di attività messe in atto dal Fornitore secondo i vincoli contrattuali per fornire al Committente i servizi necessari a fare in modo che il Sistema non degradi le normali prestazioni e garantisca disponibilità dell'applicazione nei confronti degli utenti.

In particolare il Fornitore curerà i seguenti aspetti, fornendo al Committente rapporti e statistiche mensili sull'andamento delle prestazioni:

❑ Installare, configurare e testare i servizi di base relativi all’infrastruttura informatica;

❑ Applicare gli aggiornamenti del software di base che si rendessero necessari;

❑ Monitorare performance, sicurezza e funzionalità del sistema;

❑ Definire e amministrare le credenziali d’accesso ai sistemi sotto lo propria responsabilità;

❑ Effettuare di attività necessarie a garantire, nell’esercizio quotidiano, le prestazioni ottimali per i servizi applicativi, e l’accessibilità del sistema, anche mediante periodiche e costanti riconfigurazioni ambientali (processi; priorità ecc.);

❑ Effettuare l’analisi dei malfunzionamenti e l’individuazione delle modalità correttive;

❑ Eseguire backup e ripristino dei dati;

❑ Automatizzare varie procedure nel sistema;

❑ Fornire supporto nel controllo delle infrastrutture software di base e delle applicazioni;

❑ Fornire il necessario supporto nello svolgimento di collaudi applicativi e/o verifiche sulle funzionalità delle procedure di gestione.

Tale attività Sistemistica ed Operativa per la Gestione Ordinaria del Sistema dovrà essere rivolta al Mantenimento dell’operatività del Sistema dall’entrata in funzione dello stesso fino alla conclusione dei servizi oggetto di questa fornitura.

Prima di eseguire ogni intervento di manutenzione straordinaria o che comunque possano impattare sulla disponibilità o stabilità del sistema il Fornitore dovrà informare il Committente ed ottenerne il parere favorevole, in mancanza del quale potrà comunque procedere per quanto di propria competenza assumendosene ogni responsabilità.

5.7 Formazione Personale Interno

La specifica attività di formazione degli Utenti Interni all’utilizzo del nuovo Sistema potrà essere organizzata "on site", di preferenza presso la sede operativa del Committente a Roma; sarà erogata da istruttori incaricati Fornitore e sarà rivolta agli utenti secondo moduli formativi distinti. Gli utenti in formazione conoscono gli specifici processi automatizzati ed hanno conoscenze di base degli strumenti di Office Automation di MS Windows, dell’utilizzo dei browsers e degli strumenti di posta elettronica.

Il Committente si riserva di richiedere o meno tale attività a seconda delle proprie insindacabili valutazioni. L’Offerta dovrà comunque garantire che il Fornitore possa erogare quanto qui indicato se e nella misura in cui venga eventualmente richiesta dal Committente.

I moduli forniranno informazioni generali sull'ambiente di riferimento e, ciascuno per il proprio ambito, informazioni specifiche sulle funzionalità del sistema e sul loro utilizzo da parte degli utenti.

I moduli formativi erogati dovranno includere apposite procedure di valutazione o autovalutazione del livello di apprendimento conseguito dai discenti.

La formazione degli utenti informatici ed amministratori di sistema sarà organizzata secondo un unico modulo formativo, erogato immediatamente dopo l'installazione dell'applicazione e preliminarmente all'entrata in esercizio dei primi moduli del Sistema.

Nel caso in cui il rilascio di nuovi moduli abbia impatto sulle funzioni di amministrazione, la formazione sarà completata ed aggiornata preliminarmente all'entrata in esercizio di tali moduli.

La formazione degli utenti del Fondo sarà organizzata in opportuni moduli, da tenersi prima del rilascio in esercizio dei corrispondenti moduli software.

Uno specifico modulo sarà dedicato ad una presentazione generale delle informazioni gestite dal Sistema e delle funzionalità di consultazione, stampa, selezione, estrazione, analisi e sintesi offerte dai diversi moduli, fornendo un quadro esaustivo della ricchezza informativa offerta dal sistema.

I corsi si terranno, salvo diversamente concordato con il Committente, a Roma in ambienti didattici adeguati messi a disposizione dal Committente.

Il Fornitore curerà la realizzazione e la distribuzione del materiale didattico - su supporto cartaceo

- ai discenti di ciascun modulo formativo, mettendo a disposizione del Fondo la documentazione anche in formato digitale.

Il Fornitore fornirà copia elettronica del materiale didattico nel SGR. Il Committente potrà riprodurre senza limiti il materiale didattico e pubblicarlo sui propri siti interni.

Le modalità di organizzazione e la proposta di calendarizzazione dei moduli formativi sarà dettagliata nel Piano di Progetto.

A tale scopo il Fornitore specificherà nell'offerta tecnica i contenuti dei corsi e le modalità di svolgimento per un gruppo di massimo 10 utenti.

5.8 Manutenzione

Il fornitore dovrà fornire un servizio di manutenzione Manutenzione Adeguativa e Correttiva (MAC) e di Manutenzione Evolutiva (MEV).

La MAC è inclusa nel valore dell’offerta “a corpo” presentata per lo sviluppo del sistema, mentre per la MEV viene richiesto un servizio “a consumo” secondo quanto di seguito definito.

5.8.1 Manutenzione Adeguativa e Correttiva (MAC)

Il servizio di Manutenzione Correttiva dovrà includere le attività legate alla gestione dell’ambiente operativo del Sistema in esercizio, considerando, in particolare (vedi CNIPA – “DIZIONARIO DELLE FORNITURE ICT” - Manuale operativo – v.3.3 del 13.1.2009) la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio.

Il servizio di MAC sarà reso operativo dalla fine (entrata in esercizio delle funzionalità previste per la Fase 1) della Fase 1 fino ai 12 mesi successivi al completamento della Fase 2 ed a copertura di tutti gli sviluppi previsti per la Fase 1, per la Fase 2 e di quelli eventualmente richiesti tramite il servizio di MEV.

La manutenzione correttiva, di norma, non comporta la modifica della baseline.

I livelli minimi di servizio richiesti sono:

Requisito	Valore	Evento di controllo
Intervento in caso di malfunzionamento della piattaforma	< 8 hh lavorative	Dalla segnalazione
Eliminazione del malfunzionamento SW applicativo	< 16 hh lavorative	Dalla segnalazione

Tabella 5 - SLA Manutenzione Adeguativa e Correttiva

Tale attività di XXX dovrà essere rivolta al Mantenimento dell’operatività del Sistema dall’entrata in funzione dello stesso fino alla conclusione dei servizi oggetto di questa fornitura.

5.8.2 Manutenzione Evolutiva (MEV)

Il Fondo, oltre le attività già predefinite, riportate nel precedente punto, si riserva la possibilità di richiedere lo sviluppo di ulteriori funzionalità per il sistema che ad oggi non sono ancora definite, mediante un servizio di manutenzione evolutiva (MEV).

A tal fine al fornitore viene richiesto di specificare in sede di offerta tecnica le risorse messe a disposizione per l’attività di MEV. Il costo dell’attività deve essere specificato globalmente nella parte dei per i servizi a consumo. Questo importo è calcolato su un impegno previsto di 290 giorni/persona. In sede di aggiudicazione l’importo offerto a ribasso non va a incidere sul numero dei giorni/persona previsti, che rimangono 290, ma sul valore risultante del giorno persona medio applicato (sulla base del mix di professionalità coinvolte), e costituirà la tariffa di ingaggio di tali risorse nei 36 (trentasei) mesi successivi all’aggiudicazione della gara.

Le attività a consumo riguarderanno fondamentalmente sviluppo di componenti software il cui contenuto potrà essere definito successivamente ed il cui costo, in termini di tipologia e quantità delle risorse impegnate, saranno di volta in volta concordati sulla base della tariffa media per giorno di lavoro calcolata come sopra risultante dalla dichiarazione dei servizi a consumo nell’offerta economica e il valore dei 290 giorni/persona d’impegno previsto.

5.9 Analisi Dati dei Sistemi attualmente in uso

Il Fondo ha la necessità di mantenere disponibili i dati storici relativi ai precedenti Avvisi gestiti dai sistemi già esistenti e residenti nei relativi Data Base per consentire le attività di governo, reporting, analisi dati e per le comunicazioni obbligatorie verso il Ministero e per fornire agli utenti del Fapi un quadro completo dello storico delle proprie attività presenti e passate.

La situazione delle basi dati attualmente gestite dal Fondo necessità un’attività preliminare di analisi della consistenza del dato stesso che faccia da base per le future attività di migrazione.

Nel presente bando, al fornitore si richiede di effettuare un’attività di analisi e discovery sui dati esistenti che indichi con chiarezza:

- Quali e quanti dati sono attualmente disponibili nelle basi dati

- Qual è il livello di allineamento dei dati tra i DB esistenti e quali e quanti record possono essere utilizzati per riconciliare coerentemente le basi dati stesse

- Indichi, in termini accurati, quali e quanti errori sono rinvenibili nelle basi dati e a quali rischi determinano nella gestione dello storico

- Individuino la base coerente effettivamente utilizzabile sia in termini qualitativi che quantitativi

- Descriva con chiarezza le modalità migliori di migrazione e le tempistiche necessarie

Il Fornitore all’interno della sua offerta dovrà proporre un proprio piano per la gestione di tale attività indicando una coerente metodologia di analisi.

Resta inteso che l’attività di migrazione dei dati non è oggetto del presente bando.

6. Utenti del Sistema

Il FAPI per la centralizzazione della gestione degli utenti e delle policy di accesso richiede di considerare per lo meno i seguenti distinti ruoli:

❑ Utenti della Direzione;

❑ Utenti della Segreteria;

❑ Utenti dell’Ufficio Amministrazione;

❑ Utenti dell’Ufficio Formazione;

❑ Utenti dell’Ufficio Marketing;

❑ Utenti dell’Ufficio Organizzazione;

❑ Utenti del Nucleo di Valutazione;

❑ Utenti Ispettori;

❑ Utenti del servizio di Help Desk Informatico;

❑ Utenti del gruppo lavoratori;

❑ Utenti Articolazioni locali;

❑ Utenti Attuatori;

❑ Utenti Amministratori del Sistema.

Ogni utente (persona fisica) del Sistema può appartenere contemporaneamente a più tipologie di utenza.

I privilegi potranno essere assegnati agli utenti sulla base di elementi quali unità organizzativa o ambito territoriale di appartenenza dell'utente, ruoli costituiti da funzioni/mansioni e profili di competenza all'interno di unità organizzative, gruppi di utenti strutturabili anche in modo trasversale rispetto alle unità organizzative, considerando che gli utenti possono svolgere più ruoli nell'ambito di più unità organizzative.

L'amministrazione dei privilegi deve essere svolta tramite funzioni dedicate che consentano all'amministratore di sistema l'attribuzione, la revoca dei privilegi e l’abilitazione o la disabilitazione all’accesso ad altri utenti.

L’amministratore del sistema deve avere la facoltà di generare nuovi gruppi di utenze e configurarne le policy di accesso.

Il modello organizzativo sotteso alle policy del Sistema sarà definito concordemente tra il Fondo e il Fornitore nel corso della fornitura e sarà recepito nel Piano di Progetto previsto dal Paragrafo “8.2 - Piano di progetto”.

L’utente deve avere a disposizione strumenti per la gestione in autonomia della propria utenza e per la modifica ed il recupero della propria Password. L’Amministratore del Sistema dovrà comunque avere a disposizione una interfaccia per il reset di una Password

Le utenze e le relative Password devono essere associate solo a persone fisiche, di cui devono essere come minimo salvati anche Cognome e Nome completi per la corretta identificazione anche a seguito di ispezioni di autorità o organi di controllo.

Non può essere attribuita quindi una stessa utenza a più persone fisiche.

7. Documentazione

Per tutti gli Strumenti forniti realizzati e consegnati, dovrà essere rilasciata tutta la documentazione specifica.

La documentazione dovrà essere fornita sia su supporto cartaceo sia in formato elettronico (su SGR) e dovrà includere:

❑ Specifiche tecniche e funzionali generali;

❑ Descrizione completa e commentata della struttura della base dati;

❑ Documenti d'analisi e progetto elaborati nelle forme consuete dal Fornitore;

❑ Manuali sistemistici ad uso degli utenti informatici;

❑ Manuali operativi ad uso degli utenti amministratori;

❑ Manuali utente ad uso degli utenti gestionali;

❑ La Documentazione esplicativa ed esemplificativa ad uso degli utenti generici;

❑ La documentazione relativa alle decodifiche eventualmente utilizzate all'interno dell'applicativo rispetto ai flussi ISFOL;

❑ La documentazione relativa alle decodifiche eventualmente utilizzate all'interno dell'applicativo rispetto ai flussi di informazione provenienti dall’INPS;

❑ Documentazione relativa agli strumenti di backup;

❑ Piano di Restore;

❑ Piano per garantire la Continuità Operativa.

La documentazione dovrà essere in lingua italiana, salvo l’impiego di acronimi e termini propri del campo informatico e correntemente utilizzati nella lingua originale, nonché nei casi particolari espressamente accettati dal Fondo.

La prima versione delle documentazioni dovrà essere consegnata secondo i tempi previsti nel Piano di cui al Paragrafo “8.2 - Piano di progetto” e, nel tempo, essa dovrà essere costantemente integrata dai successivi aggiornamenti, in particolare quelli dovuti a personalizzazioni, MAC e MEV.

Il Fondo potrà riprodurre la documentazione su supporto cartaceo o in formato digitale e pubblicarla liberamente sul Portale FAPI.

7.1 Guida all’utilizzo del sistema

Al fine di fornire anche agli utenti non partecipanti alle sessioni formative tutte le conoscenze necessarie relative al nuovo Sistema, il Fornitore fornirà (compreso nelle attività “a corpo”) su SGR, oltre al materiale didattico utilizzato durante l’attività formativa di cui sopra, anche una "Guida all'utilizzo del sistema".

La guida sarà organizzata secondo le modalità diffusamente utilizzate negli ambienti di Help-on- line dei vari prodotti software in commercio e conterrà, pertanto, sommario, indici, funzioni di ricerca, pagine di descrizione delle funzionalità del sistema e delle loro modalità di utilizzo, link

ipertestuali, esempi pratici dell'uso del sistema e quant'altro ritenuto utile per favorire il reperimento delle informazioni e la conoscenza ed uso del Sistema.

Saranno preferite soluzioni che rendano disponibile la guida all'interno del sistema stesso. Il Committente potrà riprodurre senza limiti la guida e pubblicarla sui propri siti interni.

La "Guida all'utilizzo del sistema" sarà rilasciata dal Fornitore anche in assenza di attività formativa di cui al Paragrafo “5.7 - Formazione Personale Interno” ed in parallelo al rilascio delle varie funzionalità.

8. Organizzazione e gestione del rapporto contrattuale

8.1 Vincoli contrattuali

Fanno parte del contratto d'appalto:

❑ Tutto il materiale di gara (bando, capitolato, disciplinare);

❑ L'offerta presentata dal Fornitore, completa di ogni documento prodotto e di tutto il materiale documentale;

❑ Il contratto firmato tra le parti.

Con la sua partecipazione alla presente gara, il Fornitore espressamente riconosce ed accetta tutte le condizioni contenute nella documentazione che regola la gara e la successiva fornitura.

Le norme di cui al presente Capitolato hanno validità sino alla scadenza del periodo contrattuale e non prima del totale esaurimento della consegna e del positivo collaudo di accettazione dei prodotti relativi.

Il Fondo non riconosce come formalmente assolta l'obbligazione di consegna da parte del Fornitore fino al positivo superamento del collaudo, in quanto qualsiasi prodotto non ancora funzionante, difettoso, viziato o comunque inadeguato non può fornire al Fondo l'utilità che la stessa si è prefissa e che costituisce lo scopo stesso della presente fornitura.

Le norme che si riferiscono a servizi successivi all’iniziale periodo contrattuale (manutenzione, assistenza, aggiornamenti, etc.) conservano invece la loro validità per tutto il tempo di utilizzo del prodotto acquistato da parte del Fondo ed in base agli eventuali rinnovi contrattuali.

8.2 Piano di progetto

La prima attività susseguente alla stipulazione del contratto sarà l’aggiornamento e la consegna del Piano di Progetto Definitivo da parte del Fornitore. Esso sarà formulato sulla base della proposta di Piano presentata dal Fornitore nella sua offerta tecnica - oggetto di valutazione - e sarà mantenuto aggiornato apportandovi tutte le modifiche occorrenti per una migliore e più completa aderenza alle esigenze del Fondo, secondo quanto concordato con il Fondo stesso in sede di SC.

Si precisa, pertanto, che la proposta di Piano presentato dal Fornitore in sede di offerta tecnica non è vincolante per il Fondo il quale si riserva la facoltà di fornire informazioni integrative ai fini della stesura del Piano di Progetto definitivo.

Il Piano di Progetto Definitivo sarà presentato dal Fornitore al Responsabile del Sistema Informativo entro 15 (quindici) giorni dalla stipulazione del contratto, e dal momento della sua presentazione si ritengono iniziate le attività oggetto della fornitura.

Il Piano di Progetto dovrà pianificare le attività di progetto per la messa in esercizio di quanto previsto in Fase 1 e per il suo collaudo finale in un arco temporale massimo di 12 (dodici) mesi decorrenti dalla stipulazione del contratto, periodo oltre il quale dovrà e potrà avere inizio la Fase 2, e dovrà essere compatibile con queste tempistiche massime:

❑ 1 (uno) mese di establishment e pianificazione (cfr: § 5.4.1Fase di );

❑ 11 (undici) mesi massimi di realizzazione e passaggio in esercizio (cfr: § 5.4.3 Master Plan);

Il Piano di Progetto dovrà pianificare inoltre le attività di progetto per la messa in esercizio di quanto previsto in Fase 2 e per il suo collaudo finale in un arco temporale massimo di 12 (dodici) mesi decorrenti dal completamento della Fase1.

A completamento della Fase 1 e della Fase 2 decorrerà il periodo di Garanzia Obbligatoria di 12 (dodici) mesi solari e l’attività di Esercizio Corrente del Sistema.

Il Piano di Progetto dovrà includere, inoltre, un Piano di collaudo (test-plan) coerente con le specifiche di cui al paragrafo “9 - Collaudi e verifica dei Servizi”, che sarà approvato dal Committente contestualmente al Piano di progetto.

Lo sviluppo del progetto sarà monitorato con incontri di pianificazione e monitoraggio, da svolgersi con periodicità mensile nell'ambito dello SC, salvo altrimenti concordato.

In occasione di tali incontri il Fornitore rilascerà documentazione esplicativa che sarà utilizzata come base per il riscontro delle attività svolte e per la pianificazione delle attività da svolgere.

Tali documenti saranno rilasciati, nelle versioni previste dal Piano di Progetto, nelle diverse fasi di implementazione del progetto stesso e saranno sottoposti al Committente per l'approvazione.

Salvo diversamente concordato fra le due parti, il Fondo si impegna a comunicare la propria valutazione sui documenti, con eventuali richieste di modifiche/integrazioni e osservazioni, entro 10 (dieci) giorni lavorativi dalla loro consegna e il Fornitore si impegna a recepire le richieste del Fondo entro i 10 (dieci) giorni lavorativi successivi alla comunicazione del Fondo. Il documento finale sarà approvato, se conforme, dal Committente.

Nel caso in cui il Fondo accetti un adempimento parziale, l’eventuale penale (paragrafo 4.9 - Penali del Disciplinare di Gara) sarà commisurata al prezzo relativo ai prodotti non consegnati o non messi in esercizio.

8.3 Durata contrattuale e xxxxxxx

La durata massima complessiva del contratto è stabilita in 24 (ventiquattro) mesi solari decorrenti dalla sua sottoscrizione.

Tale durata è suddivisa in:

• Fase 1 – durata massima di 12 (dodici) mesi solari; in questo caso si parla di durata massima perché quanto ivi previsto dovrà essere realizzato ed installato in esercizio in un tempo massimo di 12 mesi, il fornitore potrà ridurre tale durata sulla base della tempistica definita nel Piano Definitivo di Progetto relativi alla Fase 1;

• successivi 12 (dodici) mesi solari per la esecuzione di quanto previsto dalla Fase 2.

Si ribadisce che la realizzazione di quanto previsto per la Fase 1 è propedeutica all’esecuzione delle attività previste dalla Fase 2.

Il FAPI si riserva, successivamente ai 24 mesi solari massimi previsti per l’esecuzione, di sottoscrivere un successivo contratto di assistenza e manutenzione secondo quanto previsto per i relativi servizi erogati nel periodo contrattuale.

Il Fondo si riserva inoltre di richiede ulteriori attività di sviluppo non previste dal capitolato tra le attività “a corpo” sulla base delle tariffe esposte in offerta per le attività “a consumo”.

8.4 Obblighi del Fornitore

E' responsabilità del Fornitore, ove la Fornitura preveda l’utilizzo anche di software di terze parti, scegliere, dimensionare ed assemblare i vari componenti di ciascuna soluzione software offerta per assicurarne la perfetta integrazione e compatibilità al fine di ottenere il miglior funzionamento complessivo possibile.

Il Fornitore dovrà installare, configurare ed attivare, con proprio personale tecnico e a proprie spese tutto il sistema Informatico oggetto della presente fornitura sulle piattaforme hardware/software messe a disposizione dal Fondo.

Il Fornitore dovrà curare, tramite la prevista attività di Assistenza all’Avviamento “a corpo”, l'addestramento iniziale del personale del Fondo in modo da metterlo in condizione di provvedere autonomamente al funzionamento corrente dell'applicazione, ricavando il maggior beneficio dall'uso di tutti i programmi e delle funzionalità rilasciate.

Il Fornitore dovrà eseguire le attività previste “a misura” ed “a consumo” secondo le richieste del Committente ed in base a quanto definito nel presente Capitolato.

Il Fornitore assume l'obbligo di tenere indenne in ogni tempo il Fondo da tutte le rivendicazioni, responsabilità, perdite, danni, costi, risarcimenti e quanto altro chiunque possa avanzare e/o pretendere per la presunta violazione di diritti d'Autore, marchi di fabbrica, brevetti e simili, italiani o stranieri, derivanti dalla presente fornitura o dal suo uso.

Il Fornitore, ove si scelga di utilizzare prodotti Open Source, deve impegnarsi a rispettare in toto quanto previsto dalla licenza d’uso ed utilizzo legata a tali prodotti comprese le clausole relative ai sorgenti ed alle loro modifiche.

Il Fornitore ed il Fondo si impegnano a darsi reciprocamente immediata notizia di qualsiasi azione o questione di terzi di cui siano venute a conoscenza relativamente a quanto sopra.

Il Fornitore assumerà a sue spese la difesa contro tale azione e terrà a suo carico gli oneri eventualmente conseguiti nei confronti del terzo attore.

Il Fornitore si assume tutte le responsabilità inerenti eventuali infortuni o danni a persone o cose arrecati al Fondo o a terze parti, per propria negligenza, imperizia, colpa o dolo, durante lo svolgimento di attività legate alla fornitura.

A garanzia di quanto sopra, e della corretta esecuzione degli obblighi contrattuali, il Fornitore dovrà fornire al Fondo idonea polizza fideiussoria come indicato nel paragrafo “9 - Cauzione provvisoria e definitiva” del Disciplinare di Gara. Il Fornitore si obbliga a garantire e sollevare il Fondo da qualunque pretesa, azione, domanda, molestia od altro che possa derivargli da terzi, in dipendenza della prestazione o per mancato adempimento da parte del Fornitore degli obblighi contrattuali e per trascuratezza o colpa nell'adempimento degli stessi o comunque in conseguenza diretta delle attività poste in essere dal Fornitore stesso.

Il Fornitore s’impegna ad ottemperare a tutti gli obblighi verso i propri dipendenti, derivanti da disposizioni legislative, regolamenti e norme contrattuali vigenti in materia di lavoro, assicurazioni sociali e previdenza, assumendo a suo carico tutti gli oneri relativi.

Il Fondo solleva il Fornitore da qualsiasi responsabilità nei seguenti casi:

❑ Eventuale utilizzo, da parte di personale del Fondo, di prodotti software non regolarmente licenziati, tranne che nei casi in cui detto software sia stato installato dal Fornitore o su sua iniziativa;

❑ Le caratteristiche tecniche dell'installazione (apparecchiature, ambiente, impianto elettrico, collegamenti, infrastrutture, etc...) non corrispondano alle specifiche tecniche del costruttore ed alle indicazioni del Fornitore come requisiti minimi indicati in fase di Offerta;

❑ Guasti e anomalie della Procedura o sui dati provocati da colpa, dolo o negligenza del personale del Fondo;

❑ Guasti e anomalie della Procedura o sui suoi dati provocati dall'utilizzo di software diverso da quello prodotto o indicato dal Fornitore.

8.5 Obblighi del Fondo

L’infrastruttura tecnica di esercizio Hardware (Server, Router, centralino) e le relative linee di collegamento dati e telefoniche saranno a carico del Fondo.

Il Fondo metterà quindi a disposizione del Fornitore, se ritenuta corrispondente ai requisiti, la propria piattaforma hardware/software descritta al paragrafo “3 - L’attuale sistema informatico del FAPI” e successive integrazioni di questa appositamente acquistate ed installate, nonché l’accesso alle proprie macchine disposte presso il provider. Nel caso la piattaforma a disposizione risulti inadeguata, il Fondo si impegna a metterne a disposizione una stimata in grado di eseguire efficacemente quanto in oggetto alla presente fornitura, almeno secondo quanto indicato in fase di Offerta dal Fornitore come requisiti minimi, nei tempi definiti dal Piano di Progetto Definitivo.

Il Fondo darà accesso operativo a tali infrastrutture nelle modalità necessarie al fornitore per espletare il mandato.

Ogni ritardo dovuto al non rispetto da parte del Fondo delle tempistiche convenute verrà scomputato dagli eventuali ritardi conseguenti da parte del Fornitore.

8.6 Deposito e proprietà dei codici sorgente

Il Fondo richiede la fornitura dei codici sorgenti e dei moduli necessari alla modifica e ricompilazione di ogni elemento sviluppato e realizzato dal Fornitore per la realizzazione di quanto riportato nel presente Capitolato.

Entro la data del collaudo, i codici sorgente dei moduli componenti l'applicazione sviluppati verranno depositati, insieme con la loro documentazione, presso la sede del Fondo, nella modalità indicata nel Paragrafo “5.4 - Organizzazione di progetto”.

E' condizione per il rinnovo annuale del contratto di assistenza e manutenzione l'aggiornamento, con le modifiche e le personalizzazioni nel frattempo apportate all'applicazione, dei codici sorgente depositati presso il Fondo.

9. Collaudi e verifica dei Servizi

In questo capitolo sono esplicitate le diverse attività previste per i test di accettazione provvisoria, per i collaudi e per le verifiche degli altri servizi erogati.

A tal fine il Fornitore dovrà allegare in sede di offerta una proposta di Piano di collaudo (test- plan), sia per i test di accettazione provvisoria che per i collaudi.

In particolare, si prevede che il Piano di collaudo sia strutturato secondo una logica gerarchica, a partire da un Master Test-Plan, in cui si pianificano tutti i singoli test dei vari elementi da collaudare (funzionalità, sicurezza, performance, lato client e lato server, etc).

Un singolo test-plan dovrebbe contenere almeno le seguenti indicazioni:

❑ Introduzione, motivazione del test;

❑ Elementi oggetto di test;

❑ Elementi non oggetto di test;

❑ Approccio utilizzato nel test;

❑ Criteri di pass/fail del test;

❑ Criteri di sospensione del test;

❑ Deliverables del test (report);

❑ Attività del test;

❑ Responsabilità;

❑ Pianificazione dei test;

❑ Rischi nel testing;

❑ Parte di approvazione finale del test.

Secondo quanto specificato in precedenza, il software applicativo potrà essere attivato in varie fasi, secondo quanto previsto nel Piano dei rilasci.

I moduli software saranno sottoposti a test di accettazione provvisoria prima di essere rilasciati in esercizio presso gli utenti.

I "test di accettazione" sono prove di funzionalità volte ad accertare, nel loro complesso, la rispondenza dell'applicazione alle specifiche del presente Capitolato e dell'offerta del Fornitore.

I test saranno svolti su insiemi adeguati di dati di prova.

Il Fornitore dovrà inoltre fornire dei test di stress che consentano di rilevare la rispondenza del sistema ai requisiti prestazionali.

Si richiede, inoltre, che almeno uno dei test previsti nel Master Test-plan sia volto a verificare la sicurezza a livello applicativo.

In quest’ambito, si terranno in particolare considerazione le principali vulnerabilità delle applicazioni (esposizione di dati sensibili all'interno di schermate di errore dell'applicazione, buffer overflow, sicurezza dei dati nel database, controllo degli accessi, log di accessi errati o sospetti, etc) e gli aspetti legati alla validazione dei dati inseriti dal client (controllo dei dati passati da client a server - ad esempio negli URL HTTP, del range dei valori inseriti, validazione campi numerici, di tipo data, e stringa, etc).

I test saranno effettuati, di regola, in contraddittorio fra le due parti.

I test potranno essere eseguiti anche in assenza di rappresentanti del Fornitore, purché il loro esito sia verbalizzato e controfirmato dai partecipanti e controfirmato dal Fornitore.

Dell'esito dei test sarà redatto apposito verbale, con particolare riguardo per l'efficacia, la completezza, la facilità d'uso, l'efficienza ed ogni altro aspetto oggetto del test stesso.

Il Fornitore s’impegna a recepire le eventuali mancanze rilevate nei test entro il termine massimo di 15 (quindici) giorni solari.

9.1 Collaudi

Il collaudo è inteso a verificare, per tutti i prodotti software utilizzati nell'ambiente "di produzione", che siano conformi alle caratteristiche tecniche offerte in gara e comunque non inferiori ai requisiti minimi descritti nel Capitolato e che siano in grado di svolgere le funzioni richieste, comprese le personalizzazioni eventualmente effettuate.

Allo svolgimento del collaudo sovrintenderà un gruppo di lavoro del Fondo. Tutte le prove e le verifiche del collaudo saranno effettuate presso le sedi del Fondo. I collaudi saranno eseguiti secondo quanto previsto nel Piano di collaudo allegato al Piano di Progetto.

Il collaudo sarà eseguito, in contraddittorio fra le due parti, entro 30 (trenta) giorni solari dalla comunicazione di disponibilità al collaudo da parte del Fornitore.

Il collaudo sarà eseguito anche rieseguendo tutti i casi di test effettuati nei test di accettazione provvisoria, simulando intenzionalmente anche una serie di guasti anche con l’assistenza del Fornitore, per verificare l'efficacia, l'efficienza e l'affidabilità complessive dell'applicazione.

Gli eventuali moduli software realizzati successivamente al collaudo, anche a seguito di manutenzione sia migliorativa che correttiva di cui al Paragrafo “5.8 - Manutenzione”, saranno collaudati separatamente, secondo le stesse modalità.

Delle operazioni di collaudo di cui sopra sarà redatto apposito verbale che dovrà essere controfirmato dai partecipanti e dal referente del Fornitore.

In caso di esito negativo di un collaudo, il Fornitore dovrà provvedere entro il termine massimo di 15 (quindici) giorni solari all'eliminazione dei vizi e delle difformità riscontrati. A discrezione del Fondo, la ripetizione del collaudo può essere eseguita anche su un campione di informazioni diverso da quello già esaminato.

9.2 Verifiche dei servizi

Il regolare e corretto svolgimento di tutti i servizi erogati sarà sottoposto a verifica che siano conformi alle caratteristiche tecniche offerte in gara e comunque non inferiori ai requisiti minimi descritti nel Capitolato e che siano in grado di realizzare gli obiettivi previsti.

La tipologia dei servizi offerti, la quantità di prestazioni effettuate rispetto a quelle previste e la qualità delle prestazioni svolte, saranno verificate in corrispondenza delle scadenze periodiche di verifica previste nel Piano di Progetto.

L'attività di docenza e di espletamento per i corsi di formazione sarà verificata in forma preventiva ed in corso d'opera.

In caso di esito negativo di una verifica, il Fornitore dovrà provvedere entro il termine massimo di 15 (quindici) giorni solari all'eliminazione dei vizi e delle difformità riscontrati. A discrezione del Fondo, potrà essere liquidata la quota parte di servizi che abbia superato la verifica positiva.

Considerata la complessità delle applicazioni in esame, è possibile che alcune funzioni o loro parti sfuggano alle verifiche sperimentali di cui sopra ma tali omissioni, anche se avvenute con il consenso o per scelta del Fondo, non potranno in nessun caso essere addotte dal Fornitore per giustificare un imperfetto funzionamento scoperto a posteriori, rientrando anche in questo caso negli obblighi di fornitura.

Ciascuna parte della fornitura nonché la realizzazione globale si intendono accettate solo dopo l’esito positivo dei collaudi e delle verifiche corrispondenti.

Document Metadata

Table of Contents

GARA PER LA

Document Metadata