Capitolato Tecnico

Acquisizione di un applicativo per la gestione delle convenzioni di ATS Città Metropolitana di Milano

Aggiudicatario	Il Concorrente scelto dall’Ente appaltante per erogare le forniture ed i servizi coperti dal contratto.
ATS	ATS Milano Città Metropolitana, Ente appaltante e Cliente per il presente contratto.
Concorrente	Qualsiasi partecipante alla Gara di appalto per il presente contratto.
Software di base	Per software di base si intende l’insieme dei programmi che consentono ad un utente di eseguire operazioni base come costruire e mandare in esecuzione un programma o gestire una base dati. Tipici esempi di software di base sono il sistema operativo, gli editor, i compilatori ed i sistemi di gestione di basi di dati.
Software d’ambiente	Il software d’ambiente rappresenta l’insieme di programmi specializzati che facilitano la scrittura/gestione di applicazioni. Tipici esempi di software d’ambiente sono gli Application Server.
Software di rete	Il software di rete è inteso come l’insieme di programmi specialistici per la gestione delle comunicazioni. Tipici esempi di software di rete sono i gestori di posta ed i prodotti di gestione e condivisione di risorse distribuite.
Software applicativo	Programma che utilizza il software di base, d’ambiente e di rete per realizzare funzionalità legate agli scopi dell’organizzazione che lo utilizza.
Service Level Agreement (SLA)	Sono i Livelli di Servizio minimi contrattualmente richiesti. Definizione ed associato criterio di misura per la valutazione della qualità dei servizi che saranno erogati dall’Aggiudicatario.
Malfunzionamento bloccante	Malfunzionamento (difetto, errore, anomalia) che rende totalmente o parzialmente non utilizzabili ad un utente una o più funzionalità del sistema.
Malfunzionamento non bloccante	Malfunzionamento (difetto, errore, anomalia) che non inibisce l’operatività di un utente del sistema; l’utente può ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità offerte dal sistema e senza eccessivo aggravio sulla sua operatività.
Sistema di gestione dei ticket e Ticket	Un ticket contiene una richiesta di assistenza o di manutenzione attraverso una delle modalità di accesso al servizio e ne traccia l’evoluzione. Il sistema di gestione dei ticket è un tool software che permette di gestire la base dati dei ticket, il flusso di ogni ticket e l'estrazione di misure per la verifica degli SLA.

Manutenzione software correttiva	Rimozione di eventuali malfunzionamenti delle procedure applicative segnalati dal Cliente o dal Fornitore e verificatisi nell’ambito del corretto utilizzo dei programmi. Per malfunzionamento si intende una non conformità con quanto specificato nei manuali operativi o nelle specifiche tecniche / funzionali consegnate al Cliente.
Manutenzione software normativa	Comprende attività da svolgere per l’adeguamento del software applicativo al fine di adempiere ad obblighi di legge o a fronte di requisiti tecnici, informativi, funzionali e organizzativi che siano definiti da organismi normativi esterni alla struttura del Cliente (Stato, Ministeri, Regioni...).
Manutenzione software evolutiva	Comprende la modifica / aggiunta di funzioni o la parametrizzazione del software applicativo sulla base di specifici requisiti del Cliente.
Manutenzione preventiva programmata	Comprende interventi periodici e/o programmati per garantire il mantenimento del buon funzionamento del sistema informativo, attraverso il costante aggiornamento del software applicativo e di base.

1.2 Altre definizioni, abbreviazioni e sigle ‌

Sistema	Con sistema si intende complessivamente l’insieme dei moduli applicativi, delle basi dati e delle interfacce, grafiche e di comunicazione, che costituiscono l’oggetto della presente Fornitura.
Utente	Con utente si intende un generico utilizzatore del sistema; ogni utente è caratterizzato da un proprio profilo ed ha la visibilità delle sole aree applicative connesse al proprio utilizzo del sistema.
Software “orizzontale”	Applicazioni software di uso generalizzato (general-purpose) adattabili alle esigenze di diversi settori commerciali. Si tratta di software commerciali con funzioni di utilità standard quali ad esempio: ERP, CRM, Knowledge and Content Management, Business Intelligence, sistemi di gestione documentale.
Software “verticale”	Applicazioni software con funzionalità specifiche di un determinato settore commerciale.
Software proprietario	Software privato, non libero di cui è possibile al beneficiario l’utilizzo sotto particolari condizioni (in relazione alla licenza) ma non ne è permessa la modifica, la condivisione, lo studio, la ridistribuzione o il reverse engineering.
FP	Function Point è una metrica utilizzata per esprimere la dimensione o misura delle funzionalità fornite da un prodotto software (secondo la metodologia IFPUG 4.3 ed eventuali versioni successive).

ARIA	ARIA S.p.a. Azienda Regionale per l'Innovazione e gli Acquisti
PSN	Polo Strategico Nazionale (PSN) è l’infrastruttura ad alta affidabilità che ha l’obiettivo di dotare la Pubblica Amministrazione di tecnologie e infrastrutture cloud che possano beneficiare delle più alte garanzie di affidabilità, resilienza e indipendenza.
PA	Con il termine “PA” o “P.A.” va intesa la Pubblica Amministrazione.
Piattaforma Sintel	Piattaforma di e-procurement di Regione Lombardia, istituita con lo scopo di realizzare un sistema di Intermediazione Telematica che supporti la Regione e tutte le PA della Lombardia nella realizzazione delle proprie gare.
RL	Regione Lombardia.
Cloud computing	Si indica un modello di erogazione di servizi offerti on demand da un fornitore ad un cliente finale attraverso la rete Internet.
OWASP	Open Web Application Security Project. Progetto open-source con l'obiettivo di realizzare linee guida, strumenti e metodologie per migliorare la sicurezza delle applicazioni.
SCCM	Microsoft System Center Configuration Manager.
SPO	Microsoft SharePoint Online.
SIA	Sistemi Informativi Aziendali.
NDA	Non Disclosure Agreement.
DPA	Data Protection Agreement.
PC	Personal Computer.
AD	Active Directory.
CA	Certification Authority.
HA	High Availability.
SSO	Single Sign On.
QA	Quality Assurance.
VAPT	Vulnerability Assessment & Penetration Test.

Vulnerability Assessment & Penetration Test.

ATS Città Metropolitana di Milano (d’ora in avanti, ATS) ha l’esigenza di individuare, tramite apposita Procedura di Appalto, un operatore economico a cui affidare i servizi realizzativi e aggiuntivi di un applicativo software web-based che consenta la governance dei processi gestionali relativi alle Convenzioni che ATS predispone, redige e stipula con soggetti terzi all’Agenzia.

La presente fornitura riguarda le attività di sviluppo di una soluzione applicativa e l’hosting dell’applicazione web in cloud.

Il sistema richiesto deve implementare la gestione delle convenzioni stipulate da ATS, garantendo in particolare la copertura delle seguenti macroaree funzionali:

• Document Management

o editing dei documenti integrato nell’applicazione

o registro delle convenzioni

o fascicolazione

o invio in conservazione

• Scadenziari

• Integrazioni

o Active Directory

o Sistema di gestione documentale e protocollo

o Gestione delibere

o Gestione del personale

o Portale dei pagamenti

• Gestione del processo di firma digitale

• Reportistica e cruscotti gestionali

• Interfacce applicative personalizzate

• Gestione del workflow di processo

• Gestione dell’intero ciclo di vita delle convenzioni

• Gestione delle utenze ATS

o Dell’ufficio convenzioni

o Degli uffici richiedenti

o Degli uffici riceventi stagisti e specializzandi

o Dei consulenti interni ad ATS (Data Protection Officer, SC Bilancio, SC Gestione Acquisiti, SC Gestione Patrimoniale, SC Gestione Risorse Umane)

• Gestione degli stakeholders contraenti e di tutti i contatti;

• Gestione degli stagisti e specializzandi

2.2 Modalità acquisitiva ‌

ATS intende individuare un operatore economico che possa garantire i servizi realizzativi e aggiuntivi di una soluzione applicativa dedicata ad ATS attraverso le seguenti modalità:

• realizzazione di un prodotto software ad hoc secondo le specifiche funzionali successivamente indicate;

• erogazione dei seguenti servizi aggiuntivi: formazione utenti, assistenza e manutenzione correttiva, preventiva programmata, normativa ed evolutiva, l’integrazione della soluzione con altre applicazioni in uso,

A questo proposito ATS ha individuato, tra le soluzioni di mercato con maggiore grado di copertura dei requisiti funzionali e tecnici/tecnologici indicati nel presente documento, il prodotto open source CMDBuild READY2USE, distribuito sul repository SourceForge al seguente indirizzo Internet:

xxxxx://xxxxxxxxxxx.xxx/xxxxxxxx/xxxxxxxx/xxxxx/xxxxx0xxx-0.0/

La soluzione software richiesta da ATS potrà anche essere presa in riuso dal repository Developers Italia, purché basata sul prodotto open source CMDBuild READY2USE.

Si ribadisce che nella proposta di fornitura non dovranno essere previsti né costi di licenza di alcun tipo se non inclusi nella fornitura stessa, né l’integrazione di prodotti commerciali proprietari “verticali” anche se concessi con licenze illimitate.

2.3 Ambito della fornitura ‌

La fornitura deve prevedere quanto segue:

• Attività di sviluppo e di personalizzazione del prodotto software CMDBuild READY2USE, disponibile in licenza open source, tale da garantire la copertura di tutti i requisiti funzionali, non funzionali e tecnologici espressi nel presente documento, senza vincoli o dipendenze da componenti software proprietarie anche se concesse con licenze illimitate. L’applicazione software open source adottata deve essere acquisita dalla piattaforma internazionale SourceForge dedicata alla gestione di progetti software open source. La soluzione software richiesta da ATS potrà anche essere presa in riuso dal repository Developers Italia, se disponibile, purché basata sul prodotto open source CMDBuild READY2USE.

• Attività di formazione all’utilizzo del sistema da parte delle diverse tipologie di utenza previste da ATS.

• Attività di assistenza agli utenti utilizzatori e manutenzione correttiva, preventiva programmata, normativa ed evolutiva per garantire la continuità operativa a tutti gli utenti del sistema a partire dalla data di rilascio in produzione fino alla scadenza naturale del contratto.

• A partire dalla data di sottoscrizione del contratto e per tutta la durata contrattuale, acquisizione di tutti i certificati digitali necessari per la gestione del sistema.

• Coordinamento e supporto verso terzi e supporto ad ATS per la messa a punto delle integrazioni applicative richieste.

• Attività di predisposizione del repository del codice sorgente e relativo caricamento unitamente a tutta la documentazione di progetto e di esercizio, sulla sottoscrizione Microsoft Azure DevOps di ATS.

• Attività di configurazione ed esecuzione di testing automatici al fine valutarne il comportamento ed evitare regressioni;

• Attività connesse alla messa in riuso del codice sorgente del progetto, secondo quanto previsto dalle Linee Guida AgID e dai relativi allegati tecnici.

• Cessione perpetua del codice sorgente relativo a tutte le componenti funzionali sviluppate per conto di ATS e delle personalizzazioni, delle configurazioni sistemistiche, della base dati nonché della documentazione tecnica e di esercizio integralmente prodotta per ATS.

• Inclusione della predisposizione di ulteriori dieci (10) report e/o cruscotti gestionali, da realizzarsi nel corso del contratto, oltre a quelli già richiesti nel presente Capitolato Tecnico.

• Attività di manutenzione evolutiva a consumo; a questo proposito si segnala la possibilità di progettare e sviluppare, con riconoscimento a consumo, ulteriori report rispetto a quelli già richiesti all’interno del presente Capitolato Tecnico e degli ulteriori report già previsti nel corso del periodo contrattuale.

• Adeguato periodo di garanzia, proporzionato alla durata contrattuale, relativo al servizio di manutenzione correttiva, a partire dall’avvio del sistema in produzione.

2.4 Contesto normativo, tecnologico e operativo ‌

Il sistema informativo richiesto da ATS prevede che tutte le componenti applicative e dati siano erogate in ambiente cloud messi a disposizione da ARIA Spa conformemente alla normativa vigente a cui si rimanda per completezza con particolare riferimento ai criteri per la qualificazione dei servizi cloud per la PA.

ATS richiede che l’Aggiudicatario sia in possesso della certificazione secondo lo standard ISO/IEC 27001. Tale certificazione dovrà essere stata rilasciata da organismi nazionali di accreditamento riconosciuti dalla Unione Europea. Ciò è volto ad assicurare che l’Aggiudicatario abbia adottato misure tecniche ed organizzative volte a minimizzare il rischio di perdita di integrità (anche accidentale) dei dati, di accesso non autorizzato, di trasmissione non sicura, di illecita diffusione, di trattamento non consentito o non conforme alle finalità della raccolta. L’Aggiudicatario dovrà, in sintesi, mettere a disposizione di ATS una soluzione tecnologica ed operativa che garantisca il rispetto dei previsti obiettivi di sicurezza, dal punto di vista della confidenzialità, integrità e disponibilità dei dati trattati.

L’Aggiudicatario dovrà dare evidenza ad ATS di eventuali altri soggetti o subfornitori che concorrano all’erogazione del servizio quindi al trattamento dei dati. È compito di ATS verificare l’effettivo rispetto delle dichiarazioni prodotte in sede di qualificazione dall’Aggiudicatario. In caso di servizi non conformi a quanto dichiarato dall’Aggiudicatario, ATS è tenuta a segnalare la circostanza ad XxXX e ACN proponendo, in caso di esito confermativo dell’apposita verifica, la revoca della qualificazione.

In relazione agli obblighi e alle responsabilità dell’Aggiudicatario relativamente al trattamento dei dati, con particolare riferimento a quelli personali e sensibili, la fornitura prevede la sottoscrizione di una adeguata polizza assicurativa per ottemperare alla responsabilità risarcitoria a fronte di eventuali danni, economici e/o di immagine, causati da violazioni agli obiettivi di sicurezza previsti da ATS ed i cui termini sono disciplinati all’interno nel documento “Capitolato Speciale di Appalto”, di cui il massimale è pari a

1.000.000 di euro. Occorre fare pertanto riferimento a tale documento per la descrizione esaustiva delle clausole, delle responsabilità e delle azioni contrattuali previste a carico dell’Aggiudicatario in relazione alla eventuale perdita, all’illecita diffusione dei dati trattati e gestiti nel cloud ed all’interruzione del servizio erogato. Si ricorda inoltre che nella nomina dell’Aggiudicatario a Responsabile al Trattamento Esterno dei dati (Regolamento UE 679/2016) sono già indicati i compiti, gli obblighi e le responsabilità contrattuali dell’Aggiudicatario previsti da ATS.

Per una copertura completa dei requisiti richiesti in ambito di servizi cloud occorre fare riferimento alla normativa nazionale vigente ed a quanto indicato al capitolo “Progettazione, realizzazione e delivery” del presente documento.

Al fine di permettere ad ATS di valutare l’efficacia del servizio, l’Aggiudicatario dovrà rendere disponibile ad ATS strumenti idonei di monitoraggio, di audit, di Quality Assurance (QA) e di accesso alle basi dati dell’applicativo, oltre che consentire di effettuare verifiche di conformità alla normativa in materia di privacy, sicurezza e accessibilità.

Si sottolinea che ogni passaggio in produzione di software sviluppato dall’Aggiudicatario e di ogni personalizzazione ed evoluzione dedicata ad ATS, dovrà essere necessariamente condiviso e concordato con i referenti di progetto di ATS a cui dovrà essere data evidenza del buon esito dei test automatici di non regressione effettuati.

Le performance del sistema erogato dovranno in ogni caso essere adeguate all’effettivo numero di accessi concorrenti che si avranno a regime ed all’eventuale aumento dei dati trattati. La soluzione web dovrà prevedere l’espandibilità del numero di utenti e garantire la

scalabilità delle risorse cloud per gestire efficacemente anche potenziali condizioni di picco delle attività, degli accessi e del trattamento dei dati.

2.5 Durata del contratto ‌

La durata nominale del contratto previsto dalla presente fornitura è di 60 mesi.

A partire dalla data di sottoscrizione del contratto, l’Aggiudicatario dovrà provvedere alla fornitura dei certificati digitali relativi a tutti gli ambienti operativi dedicati ad ATS (collaudo, produzione).

L’Aggiudicatario è tenuto a consegnare la soluzione completa di tutte le parti specificate: collaudo, formazione... nel presente Capitolato Tecnico entro un massimo di 180 (centottanta) giorni solari dalla data di sottoscrizione del contratto. La non osservanza di tale pianificazione da parte dell’Aggiudicatario è soggetta all’applicazione di penali e può determinare l’eventuale risoluzione del contratto.

In esito al collaudo positivo, decorrerà il servizio di assistenza tecnica e manutenzione che l'Aggiudicatario dovrà garantire sino alla scadenza naturale del contratto.

Alla conclusione naturale del contratto è prevista la possibilità di prorogare i servizi di manutenzione correttiva e di assistenza tecnica, senza variazioni di canone.

Alla conclusione naturale del contratto l’Aggiudicatario è tenuto a garantire ad ATS il trasferimento integrale della base dati, opportunamente documentata attraverso metadati ed in un formato aperto e non proprietario; per lo svolgimento di queste attività l’Aggiudicatario non potrà imputare alcun costo ad ATS in quanto già dovuti e ricompresi nella presente fornitura.

In generale, in linea con quanto previsto dalla normativa e dalle Linee Guida AgID, l’Aggiudicatario è tenuto a garantire, in ogni momento e senza oneri per ATS, l’export dell’intera base dati, in un formato standard, aperto e documentato (attraverso metadata e schema E-R del DB relativa all’ultima versione funzionante in produzione).

In linea con la normativa vigente (fare riferimento al capitolo “Riferimenti documentali e normativi” del presente documento), al termine del contratto l’Aggiudicatario, nell’eventualità che ATS decidesse di avvalersi di un diverso provider infrastrutturale, dovrà consentire la migrazione dei dati del servizio verso un altro gestore. Si ribadisce che al termine del contratto o in qualsiasi momento solo dopo esplicita richiesta del Titolare, i dati in possesso dell’Aggiudicatario e/o di eventuali suoi subfornitori dovranno essere cancellati, in qualsiasi forma essi siano detenuti.

2.6 Titolarità del codice sorgente ‌

Si ribadisce che tutto il software sviluppato specificatamente per conto di ATS (codice sorgente) e relativo alla presente fornitura, unitamente a tutte le successive modifiche evolutive che verranno introdotte dall’Aggiudicatario nel corso del contratto, unitamente a tutta la documentazione tecnica e di esercizio prodotta, dovranno intendersi di proprietà intellettuale di ATS, che avrà facoltà di poter cedere gratuitamente, in riuso, tutto il software sviluppato e le previste personalizzazioni alle pubbliche amministrazioni che lo dovessero richiedere.

Lo stesso software e le personalizzazioni potranno essere segnalati ad AgID e ACN attraverso il repository Developers Italia.

Il sistema software richiesto da ATS prevede che le componenti relative all’applicazione web-based ed ai dati siano collocate in ambiente cloud, conformemente alle Linee Guida di AgID per la PA.

Si sottolinea che ogni passaggio del software sviluppato dall’Aggiudicatario, comprensivo della relativa documentazione di progetto, dall’ambiente di sviluppo all’ambiente di collaudo dedicato ad ATS e da quest’ultimo a quello di produzione, dovrà essere sempre condiviso e concordato con i referenti di progetto di ATS.

L’utilizzo delle funzionalità del sistema in oggetto dovrà essere possibile attraverso i più diffusi browser Internet, anche in mobilità. L’accesso alle funzionalità ed ai dati gestiti dovrà essere consentito solo agli utenti abilitati in funzione dei previsti livelli e profili di accesso.

Ai fini del corretto dimensionamento del sistema in ambito al presente Capitolato Tecnico, di seguito sono forniti alcuni dati relativi agli utilizzatori, agli asset e ai volumi documentali previsti:

utenti interni ATS: indicativamente 50;

volumi documentali previsti: non è possibile fornire una quantificazione a priori ma annualmente vengono realizzate 100 convenzioni ca. annue.

Le performance del sistema erogato devono essere tali da consentire un numero di accessi concorrenti pari ad almeno a 10 (dieci) utenze.

Al di là dei limiti dimensionali suddetti, l’applicazione web dovrà prevedere l’espandibilità del numero di utenti finali e la possibilità di variare indefinitamente il numero delle convenzioni gestiti mantenendo lo storico, oltre a garantire la scalabilità delle risorse di elaborazione per gestire efficacemente potenziali picchi delle attività.

2.7 Durata del contratto ‌

Al fine di consentire un'efficace quotazione della fornitura richiesta, si evidenzia che la durata nominale del contratto previsto dalla presente fornitura è di 60 mesi a partire dalla data di sottoscrizione del contratto.

2.8 Proprietà intellettuale e titolarità del codice sorgente ‌

Si ribadisce che tutto il software sviluppato per conto di ATS e relativo alla presente fornitura (in particolare: moduli di front-end, back-end, back-office e connettori) unitamente a tutte le successive modifiche (correttive e/o evolutive e/o migliorative) che verranno introdotte dall’Aggiudicatario, unitamente a tutta la documentazione tecnica e di esercizio prodotta, dovranno intendersi di proprietà intellettuale di ATS.

Al termine del periodo contrattuale, ATS dovrà poter gestire l’acquisizione del solo servizio di assistenza e manutenzione attraverso procedure acquisitive aperte in linea con la normativa vigente.

ATS avrà la possibilità di cedere in riuso il software inclusivo delle relative personalizzazioni ad altri Enti pubblici che lo dovessero eventualmente richiedere. La stessa soluzione software potrà essere segnalata ad AgID per essere resa disponibile in modalità open source sul repository Developers Italia. A questo proposito, fare riferimento alle Linee Guida di AgID riportate nel capitolo “Riferimenti documentali e normativi”.

Sono in carico all’Aggiudicatario tutte le attività connesse alla messa in riuso del codice sorgente del progetto, secondo quanto previsto dalle Linee Guida AgID e dai relativi allegati tecnici.

3 Requisiti Funzionali ‌

Si sottolinea che, per completezza, sono da considerarsi parti integranti della presente specifica funzionale tutti i riferimenti bibliografici, documentali e normativi referenziati all’interno del presente documento.

3.1 Caratteristiche specifiche della soluzione ‌

RIC1

RICHIESTA DI STIPULA

1) Il sistema deve prevedere delle forms specifiche per la compilazione della richiesta (che ricalchino la modulistica in uso: Mod.01 “Richiesta stipula” – Mod.02 “Emissione parere” – Mod.03 “Form Enti esterni”.

2) La form dei suddetti moduli, una volta compilata, dev’essere trasmessa alla direzione competente, per l’acquisizione delle relative sottoscrizioni. Il sistema dovrà proporre, al termine della compilazione della form di richiesta, la form “compila lo schema di convenzione” (attingendo ai dati già inseriti nelle form di richiesta).

a. Se il richiedente è una SC, l’approvazione della richiesta avviene a livello del dipartimento di afferenza.

b. Se il richiedente è un Dipartimento/una Struttura in staff allo stesso, l’approvazione avviene a livello della Direzione strategica competente.

c. Se il richiedente è la Direzione Strategica, la richiesta è automaticamente approvata dal richiedente stesso.

i. Il sistema deve in ogni caso prevedere la possibilità che i direttori strategici richiedano l’approvazione del Direttore Generale.

ii. Tutte le convenzioni onerose proposte da DS/DA/DSS devono essere obbligatoriamente approvate dal Direttore Generale.

d. Se il richiedente è un soggetto/ente esterno all’Agenzia, che invia una lettera di richiesta a mezzo pec, (per. es. Università/ASST), l’Ufficio convenzioni compilerà una specifica form (Mod.03 “Form Enti esterni”), inserendo in essa i dati forniti dal richiedente. Detta form consentirà di redigere automaticamente la struttura di massima della form di lettera di intenti (per le richieste inerenti alle Scuole di Specializzazione) / nota di risposta (per le ASST e per le richieste inerenti ai tirocini curriculari) che l’Agenzia redigerà per accogliere la richiesta di stipula. Dall’invio della stessa, a mezzo protocollo, decorreranno i termini procedimentali.

3) Il richiedente dovrà poter allegare eventuale documentazione a supporto della richiesta (uno o anche più allegati)

4) Il sistema verificherà che i campi obbligatori delle form di richiesta siano correttamente alimentati e che i controlli siano tutti favorevoli, (es: convenzione a titolo oneroso è obbligatorio indicare l’onere) altrimenti blocca il processo (I campi obbligatori o i controlli sono da definire sulla base della modulistica di esempio)

5) Il funzionario compilatore della form di richiesta invia al richiedente (Direttore di SC/Dipartimento/SSD) la richiesta per la relativa sottoscrizione.

6) Il sottoscrittore (funzionario/Direttore) può:

a. modificare autonomamente la richiesta:

b. rinviarla al compilatore per le modifiche, il quale riceverà una mail (con il link alla richiesta) che lo avviserà della necessità di apportate le modifiche. Il Direttore richiedente dovrà poter fornire nella mail specifiche indicazioni al funzionario compilatore che, effettuate le modifiche, rinvia la richiesta al richiedente con le medesime

modalità.

7) La richiesta sottoscritta dal richiedente (e completa di tutti gli allegati) sarà trasmessa all’approvatore (Direttore di Dipartimento/Direzione Strategica/Direzione Generale quando previsto), che riceverà una mail che lo informerà della necessità di approvare. La mail dovrà contenere link alla richiesta da firmare.

8) La richiesta approvata e completa degli eventuali allegati sarà trasmessa all’Ufficio convenzioni che riceve (xxxxxxxxxxxxxxxxxx@xxx-xxxxxx.xx) la comunicazione di avvenuta presentazione di una richiesta di stipula.

9) Tutte le richieste pervenute vengono “spostate” sulla scrivania del Responsabile del procedimento (RPD) che le assegna agli istruttori.

10) Gli istruttori assegnatari effettuano la verifica preliminare circa la completezza della richiesta. Se la verifica è negativa (richiesta incompleta), la rendono al richiedente per acquisirne i dati mancanti; se la richiesta è positiva, viene inviata al Protocollo, per la relativa protocollazione.

11) Dalla protocollazione decorrono i termini di conclusione del procedimento (fissati in 90 gg, “in via sperimentale per il primo anno di utilizzo del gestionale”).

12) Il sistema deve essere provvisto di un meccanismo di conteggio dei termini di conclusione del procedimento che consenta di monitorare e visualizzare (attraverso una specifica rappresentazione grafica e numerica) non solo il rispetto di detti termini, ma anche il valore medio dei termini procedimentali in riferimento a una specifica cadenza periodica.

RIV1

RICEVIMENTO ISTANZE

1) Tutte le richieste finiscono in un contenitore a disposizione del Direttore della SC o suo delegato che effettua l’assegnazione di ogni procedimento all’istruttore.

2) Il sistema dovrà garantire anche la possibilità che gli operatori dell’Ufficio Convenzioni si assegnino i procedimenti pervenuti informando con email il responsabile circa l’avocazione.

3) Ogni richiesta pervenuta all’Ufficio convenzioni genera una mail indirizzata al Direttore della SC (e alla mail istituzionale dell’ufficio convenzioni), contenente il link al fascicolo, affinché possa essere

assegnata all’istruttore.

4) A fronte dell’assegnazione effettuata dal responsabile, il sistema genera una mail indirizzata all’istruttore assegnatario, che lo informa dell’avvenuta assegnazione del procedimento.

5) L’istruttore potrà visualizzare l’elenco delle pratiche pervenute all’Ufficio Convenzioni e, se ritenuto necessario, può effettuare una presa in carico del procedimento. In questo caso il sistema genera una mail di notifica al Direttore della SC dell’avvenuta auto-assegnazione.

IST1	AMBIENTE ISTRUTTORIA
	L’istruttore entra nel proprio ambiente nel quale visualizzerà tutte le box che corrisponderanno allo stato di avanzamento del procedimento. Le box sono indicative delle seguenti fasi procedimentali (F), che si articolano in specifiche sotto fasi (SF):
		F	VERIFICA PRELIMINARE
		F	ATTO IN REDAZIONE
		SF	RICHIESTA PARERI		IMPOSTA DI BOLLO
		F	CONDIVISIONE TESTO CON LE CONTROPARTI
		SF	CRISTALLIZZAZIONE DELL’ATTO
		F	GESTIONE DELLA SOTTOSCRIZIONE DIGITALE
		SF	FASE DELIBERANTE
		SF	MODALITÀ ORDINARIA		MODALITÀ STRAORDINARIA
		SF	NOTA PROT. E AVVISO DI PAGAMENTO
		SF	ATTI IN COMPLETAMENTO
		F	REGISTRAZIONE DELLA CONVENZIONE
		F	GESTIONE TIROCINI
		F	ADDENDUM ALLA CONVEZIONE
		F	ARCHIVIO CONVENZIONI
		F	SOSPENSIONE DEL PROCEDIMENTO
		F	MONITORAGGIO
		SF	INDICATORE DI QUALITÀ	IMPOSTA DI BOLLO	SCADENZA CONVENZIONI

VER1

VERIFICA PRELIMINARE

1) È il box nel quale vengono inserite tutte le richieste assegnate agli istruttori dal RDP o auto assegnate dagli istruttori stessi.

2) L’istruttore assegnatario effettua le verifiche e:

a. se l’esito della verifica è positivo, il sistema protocolla la richiesta e la inserisce nel box “Atto in redazione”, dando così avvio alla decorrenza dei termini procedimentali;

b. se l’esito della verifica è negativo, rinvia la richiesta al richiedente per le integrazioni/modifiche necessarie. In questo caso il fascicolo viene inserito nel box stand-By con la caratterizzazione della tipologia di attesa che, in questo caso, è “Attesa integrazioni”.

3) A completamento della verifica l’istruttore avvia il procedimento inviando al protocollo gli atti (domanda e allegati). L’avvenuta protocollazione dà avvio alla decorrenza dei termini procedimentali ed inserisce nel box atto in redazione.

4) Nel caso di ricezione di richiesta proveniente da Università, ai fini dell’avvio del procedimento, l’istruttore compila una form ad hoc che consente di recepire le informazioni relative alla persona giuridica richiedente, al referente ATS della convenzione e alla durata della convenzione.

5) Il sistema, completata la compilazione, genera la lettera di intenti/nota di risposta e la invia al DG per la sottoscrizione. Preliminarmente all’invio, l’istruttore dovrà avere la possibilità di integrare/modificare il testo della lettera di intenti generata dal sistema (vedi modello lettera di intenti allegato)

6) Una volta sottoscritta il sistema provvede alla protocollazione ed invio all’Università richiedente.

7) Completato il processo, il procedimento viene inserito nel box atto in redazione.

RED1

ATTO IN REDAZIONE

1) L’istruttore redige l’atto direttamente all’interno del SW, scegliendo fra i modelli di convenzione predisposti e caricati all’interno del sistema quello confacente alla tipologia di convenzione da redigere. Il sistema acquisisce le informazioni presenti sul modulo di richiesta. (xxx.xx.: oggetto della convenzione, denominazione della controparte e dati relativi [sede legale, P.IVA e/o Codice Fiscale, ecc. …], tipologia della convezione [attiva, passiva, gratuita], durata della convezione e referente della convenzione). L’istruttore, operando sul modello, provvederà a completare la redazione del testo della convenzione, non solo operando sui dati importati automaticamente dal sistema per integrarli/modificarli, ma anche, eventualmente, per copiare e incollare altri dati presenti su altri documenti (eventualmente presenti anche all’interno del sistema). Il sistema dovrà poter consentire di inserire in calce al testo della convenzione gli allegati, ovvero immagini e tabelle e/o altri documenti in formato editabile e non.

2) L’atto viene redatto sempre nel format uso bollo, indipendentemente dal fatto che la convenzione sia soggetta, ai sensi di legge, al pagamento dell’imposta

di bollo. Per la determinazione dell’imposta di bollo si veda il punto 8.

3) RICHIESTA PARERI: devono essere previste delle funzionalità specifiche per l’acquisizione dei pareri funzionali alla redazione dell’atto e per la storicizzazione degli interventi effettuati dai soggetti aditi per l’emissione dei relativi pareri. Dovrà trattarsi di “specifici pulsanti” che renderanno disponibile al destinatario la visualizzazione della specifica sezione nel relativo cruscotto: il soggetto adito riceverà una mail con il link che gli consentirà di accedere, solo in visualizzazione, al testo in redazione e ad una specifica sezione (a latere del testo) nella quale esprimerà il parere richiesto ed espresso (di cui dovrà restare traccia), così che l’istruttore possa acquisirlo all’interno del testo in redazione.

4) La chat relativa dovrà essere personalizzata per ogni interlocutore, mentre l’istruttore potrà visualizzare tutte le chat intercorse con i soggetti aditi per i vari pareri.

5) Nell’attesa dell’emissione del parere richiesto, l’atto viene spostato nel box “Stand by” con l’indicazione “Attesa parere da XXX” (XXX è l’ufficio cui il parere è richiesto).

6) Il sistema deve consentire all’istruttore di richiedere il parere del RDP anche sul testo della convenzione, nella sua versione finale o nel corso della sua redazione.

7) I pareri ricevuti vengono valutati dal RDP e:

a. se la valutazione è negativa, vengono richieste ulteriori integrazioni al parere e l’atto ritorna nel box “Stand by”, con l’indicazione “Attesa parere da XXX”;

b. se la valutazione è positiva, l’atto viene spostato nel box “Atto in redazione” affinché l’istruttore possa condividerlo con la controparte via mail selezionando l’apposito pulsante di invio. Il sistema propone gli indirizzi a cui inviare il testo, attingendo dall’anagrafica oppure consentendo l’inserimento di nuovi indirizzi, che andranno ad alimentare l’anagrafica stessa inserendo il procedimento nel box “Condivisione testo con le controparti”.

c. Se le controparti di ATS sono maggiori di una, l’istruttore procede alla condivisione del testo scegliendo tra l’invio singolo (ad una specifica controparte) ovvero l’invio contestuale a tutte le controparti. In entrambi i casi, acquisite le condivisioni, il sistema deve effettuare la verifica delle versioni (la corrispondenza dei testi), in modo da evidenziare le eventuali differenze che l’istruttore provvederà a trasferire sul documento originario.

7 bis) Nel caso in cui all’esito degli approfondimenti istruttori richiesti ai CONSULENTI INTERNI (Data Protection Officer, SC Bilancio, SC Gestione Acquisiti, SC Gestione Patrimoniale, SC Gestione Risorse Umane), si ravvisi l’opportunità di non proseguire nella redazione del testo, l’Istruttore comunicherà al richiedente (tramite nota protocollare) la chiusura dell’iter procedurale, per mancanza delle condizioni per la stipula della convezione.

All’atto dell’invio di detta nota, il sistema interromperà i termini procedimentali (se già avviati). La documentazione relativa alla convenzione in parola sarà archiviata in apposita sezione dell’applicativo, denominata “Convezioni non stipulate”.

8) IMPOSTA DI BOLLO: nel caso in cui l’imposta di bollo sia dovuta, i criteri che il sistema dovrà utilizzare per determinarne il relativo importo saranno i seguenti: l’importo dell’imposta viene calcolato in ragione di 16,00 euro per ogni 100 righe o frazioni di esse, ovvero ogni 4 pagine di foglio uso bollo (D.P.R. n. 642/1972). Considerata la possibilità che, a fronte della condivisione del testo con la controparte, le pagine possano aumentare o diminuire di numero, il sistema dovrà calcolare il valore definitivo dell’imposta di bollo solo sul testo cristallizzato1.

9) È necessario, pertanto, prevedere un pulsante “Atto cristallizzato”, agendo sulla quale il sistema provvede al calcolo definitivo dell’imposta di bollo. L’istruttore agirà su questo pulsante solo a termine della condivisione del testo con la/le controparte/i.

10) Il sistema deve comunque dare la possibilità di sostituire l’atto cristallizzato con una nuova versione dello stesso, per tutti quei rari casi nei quali si renda necessaria una ulteriore modifica dell’atto già cristallizzato. In questo caso l’atto dovrà poter essere inviato alla fase atto in redazione, per le modifiche del caso.

11) Terminata la redazione dell’atto, è necessario che il sistema consenta all’istruttore di accedere a una specifica maschera che mostri tutti i contraenti e la relativa suddivisione del bollo tra le controparti. L’istruttore, a seconda dei casi, avrà la possibilità di confermare o modificare le assegnazioni proposte dal sistema, così da consentire la generazione del corretto avviso di pagamento (integrazione col Portale dei pagamenti). L’istruttore dovrà avere anche la possibilità di escludere l’applicazione dell’imposta di bollo. Sostanzialmente, il sistema deve alimentare la maschera relativa all’imposta di bollo per tutte le convenzioni, indipendentemente dal fatto che il bollo sia o meno dovuto. Spetterà all’istruttore scegliere, agendo sui pulsanti ad hoc previsti, se confermare o meno l’applicazione dell’imposta e attribuirne la/le quota/quote parti al/ai contraenti. È richiesta la presenza di una specifica funzione di controllo che verifichi la corrispondenza tra il totale dell’imposta e le la somma delle quote parti attribuite ai contraenti.

CON1	CONDIVISIONE DEL TESTO CON LE CONTROPARTI

1 Il testo si intende cristallizzato a valle della condivisione definitiva del suo contenuto tra le parti contraenti. Solo a fronte dell’avvenuta cristallizzazione dell’atto è possibile determinare correttamente il valore dell’imposta di bollo (se prevista) e condividere il testo con le controparti per l’acquisizione delle firme digitali.

1) Questo box deve contenere i procedimenti che l’istruttore invia alle controparti al fine di definire congiuntamente la versione finale del testo, prima di passare alla sottoscrizione dell’atto.

2) L’invio del testo può essere fatto attraverso il gestionale, a mezzo pec o a mezzo mail. Il testo da inviare dovrà essere classificato come versione n.1, al fine di tenere memoria delle diverse successive eventuali versioni.

3) Nel primo caso (invio a mezzo pec) ricevuto il riscontro, il sistema dovrà consentire di acquisire il file ricevuto e di caricarlo quale nuova versione della convenzione, tenendo memoria della versione precedente.

4) Nel secondo caso (invio a mezzo mail), l’istruttore dovrà uplodare sul gestionale il file ricevuto, classificandolo come nuova versione del testo convenzionale in sostituzione della versione già condivisa. Anche in questo caso va tenuta memoria delle versioni precedenti.

5) Se la condivisione è negativa, (ovvero, se le controparti ravvisano la necessità di modificare/integrare il testo), l’atto viene inviato al box “Atto in redazione” e vi rimane fintanto che l’istruttore non abbia provveduto ad integrare/modificare il testo sulla base delle richieste pervenute, per rinviarlo alla controparte ai fini della definizione condivisa del suo contenuto.

6) CRISTALLIZZAZIONE DELL’ATTO: se la valutazione è positiva, il testo cristallizzato viene trasformato in file Pdf/A e inviato via mail alla controparte/alle controparti ai fini della relativa sottoscrizione digitale.

GES1

GESTIONE DELLA SOTTOSCRIZIONE DIGITALE

La fase di gestione della sottoscrizione digitale può prevedere due diverse fattispecie, determinate dalla necessità di finalizzare la sottoscrizione dell’atto prima dell’avvenuta pubblicazione della relativa delibera di adozione.

A. MODALITÀ ORDINARIA

1) Di norma, cristallizzato il testo convenzionale, ognuna delle parti contraenti, provvede ad adottare (se prevista) la delibera di stipula della convenzione, per poter, solo successivamente all’avvenuta pubblicazione della stessa, dare avvio al procedimento di acquisizione delle sottoscrizioni digitali.

2) FASE DELIBERANTE: nel nostro caso, l’istruttore dà avvio all’iter deliberativo, che consiste nell’alimentare l’apposita form (ad hoc predisposta), in parte autoalimentata con le informazioni già presenti nel sistema ed in parte alimentata con altre informazioni da inserire manualmente. Tutte queste informazioni andranno ad alimentare in forma automatica il sistema di gestione delle delibere (IRIDE).

3) Ad avvenuta pubblicazione della delibera, il sistema avvisa l’istruttore tramite mail circa l’avvenuta pubblicazione. L’istruttore invia a mezzo mail (generata all’interno del SW) al Direttore Generale la delibera unitamente al file PDF/A della convenzione, al fine di acquisirne la sottoscrizione digitale di

competenza.

4) NOTA PROT. E AVVISO DI PAGAMENTO: acquisita la sottoscrizione digitale da parte del Direttore generale, l’istruttore, avvalendosi del sistema provvede a:

a. generare la nota protocollare di trasmissione dell’atto digitalmente sottoscritto dal DG;

b. se previsto dalla tipologia di convenzione, generare (grazie l’integrazione col Portale dei pagamenti) il relativo avviso di pagamento dell’imposta di bollo, da allegare alla nota protocollare di trasmissione. Il sistema, per la generazione dell’avviso di pagamento, si avvale degli inserimenti effettuati dall’istruttore, di cui al punto 11 della fase “ATTO IN REDAZIONE”.

c. L’istruttore, generata la nota protocollare e l’avviso di pagamento, provvede attraverso l’integrazione con il Protocollo, all’invio degli stessi alla controparte a mezzo pec, per acquisire la sottoscrizione di competenza da parte del/dei contrante/i.

d. Il sistema proporrà i contraenti della convenzione; l’istruttore, dovrà poter avere la possibilità di modificare quelli proposti, inserendone manualmente dei nuovi (alimentando, così, la rubrica stessa) ovvero attingendo dagli indirizzi presenti in rubrica.

5) ATTI IN COMPLETAMENTO: ad avvenuta acquisizione delle sottoscrizioni digitali (ovvero a fronte della ricezione della relativa pec da parte del contraente) e solo a fronte dell’avvenuta pubblicazione della delibera di stipula, il sistema sposta la convenzione perfezionata e la relativa delibera all’interno del box “Atti in completamento”. L’istruttore dovrà quindi poter operare le seguenti scelte:

A) agendo su uno specifico pulsante trasmettere gli atti al referente ATS della convenzione. Attivato il pulsante, il sistema presenterà un’apposita maschera nella quale saranno proposti i dati relativi al referente e uno specifico box da compilare (a cura dell’istruttore) con la data di inizio e di fine della convezione. L’istruttore, dovrà poter accedere alla rubrica aziendale per selezionare l’indirizzo mail del referente (e delle eventuali segreterie) al quale inviare gli allegati, redigere un breve testo e finalizzare l’invio dall’indirizzo mail xxxxxxxxxxxxxxxxxx@xxx-xxxxxx.xx

B) Agendo su uno specifico pulsante, inviare ai dipendenti individuati per lo svolgimento delle attività convenzionali, a specifiche strutture aziendali (per esempio SC Gestione Risorse Umane, SC Programmazione, Bilancio, Monitoraggio e rendicontazione, ecc…) ed alla controparte, una specifica nota protocollare “nota personale dipendente” (vedi modello allegato). Attivato il pulsante, il sistema presenterà lo schema editabile della nota, per le integrazioni/modifiche del caso. Il sistema, attraverso l’integrazione con il protocollo registrerà automaticamente la nota e la invierà ai destinatari.

B. MODALITÀ STRAORDINARIA

1) Nel caso in cui si ravvisi la necessità di sottoscrivere l’atto urgentemente, ovvero prima dell’avvenuta pubblicazione della relativa delibera di adozione, possono configurarsi due diverse ipotesi:

a. Atto già sottoscritto dalla controparte

I. Se i contraenti sono due (ATS e la controparte) l’atto in formato p7m viene trasmesso a mezzo mail (xxxxxxxxxxxxxxxxxx@xxx-xxxxxx.xx) generata all’interno del SW, alla Direzione Generale per acquisirne la sottoscrizione digitale di competenza.

A questo punto l’atto, provvisto delle due firme, viene trasmesso alla controparte, seguendo le seguenti modalità.

NOTA PROT. E AVVISO DI PAGAMENTO: l’istruttore, avvalendosi del sistema:

▪ genera la nota protocollare di trasmissione dell’atto digitalmente sottoscritto;

▪ se previsto dalla tipologia di convenzione, genera (attraverso l’integrazione col Portale dei pagamenti) il relativo avviso di pagamento dell’imposta di bollo, da allegare alla nota di trasmissione. L’istruttore, generati i documenti di cui sopra, provvede attraverso l’integrazione al Protocollo, all’invio degli stessi alla controparte a mezzo pec.

II. Se i contraenti sono più di due (ATS e più controparti) è necessario acquisire previamente le firme digitali di tutte le controparti e, solo successivamente, quella della Direzione Generale di ATS.

A questo punto l’atto, provvisto delle firme di tutte le controparti, viene trasmesso alle controparti, seguendo le seguenti modalità.

NOTA PROT. E AVVISO DI PAGAMENTO: l’istruttore, avvalendosi del sistema:

▪ genera le note protocollari di trasmissione dell’atto digitalmente sottoscritto;

▪ se previsto dalla tipologia di convenzione, genera (attraverso l’integrazione col Portale dei pagamenti) i relativi avvisi di pagamento dell’imposta di bollo, da allegare alla nota di trasmissione. L’istruttore, generati i documenti di cui sopra, provvede attraverso l’integrazione al Protocollo, all’invio degli stessi alle controparti a mezzo pec.

b. Atto non sottoscritto da alcun contraente.

In questo caso il documento viene trasmesso a mezzo mail (xxxxxxxxxxxxxxxxxx@xxx-xxxxxx.xx) generata all’interno del SW, alla Direzione Generale per acquisirne la prima sottoscrizione digitale.

NOTA PROT.: l’istruttore, avvalendosi del sistema genera le note protocollari di trasmissione dell’atto digitalmente sottoscritto e lo trasmette alla/alle controparte/i per acquisire le relative firme digitali.

AVVISO DI PAGAMENTO: Ricevuto via pec l’atto provvisto di tutte le firme digitali, l’istruttore, se previsto dalla tipologia di convenzione, genera (attraverso l’integrazione col Portale dei pagamenti) il relativo avviso di pagamento dell’imposta di bollo e lo invia, a mezzo pec, alle controparti. L’istruttore, nel selezionare i destinatari, dovrà poter avere

la possibilità di attingere dagli indirizzi presenti nella rubrica ovvero di inserirli manualmente qualora non presenti (alimentando, così, la rubrica stessa).

2) Completato l’iter di acquisizione delle sottoscrizioni digitali, l’istruttore avvia l’iter deliberativo, alimentare l’apposita form di cui al punto 2 della lettera a) “Modalità ordinaria”.

3) ATTI IN COMPLETAMENTO: ad avvenuta pubblicazione della delibera di presa d’atto il sistema riceve automaticamente dal gestionale IRIDE la comunicazione di avvenuta pubblicazione e acquisisce la delibera stessa. Il sistema sposta quindi l’atto perfezionato (provvisto di tutte le firme digitali dei contraenti) nel box “Atti in completamento”, affinché l’istruttore possa:

protocollo registrerà automaticamente la nota e la invierà ai destinatari.

REG1

ELENCO DELLE CONVENZIONI

A fronte dell’avvenuta pubblicazione della delibera (di stipula o di presa d’atto), il sistema deve avere la possibilità di operare nelle seguenti direzioni:

a. se l’atto è da perfezionare, ovvero devono essere acquisite tutte le sottoscrizioni digitali previste, l’atto viene spostato nel box “Acquisizione firme digitali”, così da avviarne il relativo iter;

b. se l’atto è perfezionato (provvisto di tutte le firme digitali), viene spostato

unitamente alla relativa delibera, nel box “Atti da registrare”.

Il criterio di organizzazione degli atti all’interno del box “Atti da registrare” dev’essere la data di perfezionamento della convenzione (ovvero la data di firma dell’ultimo sottoscrittore). Il sistema, nel rispetto di detto ordine cronologico, provvede al mantenimento di un elenco delle convenzioni disponibile ad uso interno dell’applicazione, dalla meno recente alla più recente.

REG2

CONVENZIONI

Tutte le convenzioni stipulate dall’Ufficio convenzioni devono essere disponibili nell’applicazione ad uso interno dell’Ufficio Convenzioni nel quale le stesse saranno disposte secondo il numero progressivo di registrazione interna all’applicazione, iniziando ogni anno dal numero 01/AAAA affinché siano facilmente individuabili all’interno della stessa.

L’elenco, che accoglierà automaticamente tutte le informazioni necessarie e richieste dalla normativa di settore, dovrà essere accessibile agli istruttori prevendendo la funzionalità di eliminazione logica dall’elenco. Tale funzionalità consente di mantenere traccia degli annullamenti effettuati, mantenendo i relativi record, contrassegnandoli come annullati.

Il sistema dovrà generare automaticamente un invio periodico delle convenzioni alla SSD Attività Istituzionali e Supporto alla Direzione Amministrativa per l’inserimento nel “Registro Convenzioni”. Il sistema dovrà generare tutti i metadati richiesti dalla

citata SSD.

TIR1

GESTIONE TIROCINI

Ad avvenuto perfezionamento della convenzione, il sistema informa via mail il “Tutor” e il referente per i tirocini circa l’attivazione della convezione.

Il referente per i tirocini dovrà, inoltre, provvedere alla segnalazione, al Medico Competente e al Responsabile del Servizio Prevenzione e Protezione, delle possibili esposizioni a rischi lavorativi durante l’attività formativa, trasmettendo la modulistica in vigore.

Il tutor procede quindi alla compilazione della schermata all’interno della quale è necessario inserire le informazioni relative all’anagrafica e alla presenza del tirocinante/specializzando.

Nello specifico, il tutor deve avere la facoltà di inserire:

- i nominativi dei tirocinanti/Specializzandi e i relativi dati anagrafici (anche il codice fiscale) e la loro qualifica

- le presenze (per i soli tirocinanti) agendo all’interno del calendario delle presenze ovvero uploadando il pdf del diario delle presenze

- la denominazione del corso di laurea

- la/le sede/sedi di svolgimento del tirocinio

- la durata del tirocinio (data di inizio e data di fine)

- l’indicazione dell’anno accademico.

Per ogni convezione perfezionata il sistema proporrà la specifica form, autoalimentata con i dati principali della convenzione (oggetto e durata della convenzione, denominazione dell’Università).

Il sistema dovrà consentire l’elaborazione automatica di uno specifico report riepilogativo, su base annuale, contenete tutti i dati inseriti dai tutor per ognuna delle convenzioni stipulate e vigenti nel periodo di riferimento. Il report sarà trasmesso via mail dall’istruttore all’Ufficio Risorse umane.

ATS Milano si impegna a rispettare la proporzione numerica tra lavoratori assunti a tempo indeterminato e tirocinanti secondo quanto stabilito dalla normativa vigente.

L’istruttore inserisce, dopo la registrazione della convenzione, dette soglie all’interno del sistema.

A fronte degli inserimenti da parte dell’istruttore, il sistema prevede un meccanismo a scalare che si attiverà a fronte degli inserimenti da parte del tutor, bloccando la facoltà di inserimento al raggiungimento della soglia prevista, ovvero aggiornando la

soglia qualora decada un tirocinante/specializzando già registrato.

ADD1

ADDENDUM ALLA CONVEZIONE

L’addendum si configura come atto che acquisisce le modifiche al testo della convenzione già stipulata.

Tutte le predette attività previste per la redazione e gestione della convenzione si applicano anche alla redazione e gestione dell’Addendum, il quale si configura sostanzialmente come una “nuova convenzione”.

Quanto sopra vale anche per la fase della registrazione, fatta salva la necessità che il sistema colleghi sempre l’addendum alla convenzione a cui si riferisce.

Perché ciò sia possibile è necessario che il sistema consenta all’istruttore, in fase di redazione dell’addendum, di abbinarlo alla relativa convenzione, attraverso la specifica funzione “Abbina alla convezione”, creata ad hoc.

Il sistema dovrà prevedere una specifica rappresentazione grafica, che consenta di visualizzare, unitamente alle convenzioni sottoscritte, anche i relativi addendum.

SOP1

SOSPENSIONE DEL PROCEDIMENTO

Nel caso in cui si renda necessaria la sospensione dei termini procedimentali (in tutte le fattispecie normativamente previste: acquisizione atti/ informazioni di cui ATS non dispone), il sistema congela il counter dei termini procedimentali fino a un massimo di 30 gg. Il procedimento viene così inserito nel box Stand-by con l’indicazione “Procedimento sospeso”. La sospensione dei termini decorre dal momento in cui l’istruttore finalizza l’invio della specifica nota protocollare di richiesta alla controparte. Il modello della nota viene generato dal sistema, su richiesta dell’istruttore, utilizzando i modelli all’uopo predisposti e caricati sul gestionale. Acquisite le informazioni richieste (ovvero ricevuta la pec di risposta) l’istruttore

sposta la pratica nel box “Atti in redazione” e, da questo momento il conteggio dei termini procedimentali riparte da dove era stato interrotto.

MON1

MONITORAGGIO

INDICATORE DI EFFICIENZA PROCEDIMENTALE

1) Il sistema deve essere provvisto (come già riportato al punto 12 della fase “Richiesta di stipula”) di un meccanismo di conteggio dei termini di conclusione del procedimento, fissati in 90 gg. “in via sperimentale per il primo anno di utilizzo del gestionale”.

2) Il meccanismo di conteggio dovrà consentire di monitorare e visualizzare, attraverso una specifica rappresentazione grafica e numerica, che si aggiorna in tempo reale:

a. per ogni procedimento avviato, il rispetto dei termini procedimentali, ovvero il decalage dei 90 gg. in ferimento alle diverse fasi procedimentali;

b. per i procedimenti conclusi, il valore medio dei termini procedimentali in riferimento a uno specifico intervallo temporale, scelto autonomamente dall’istruttore per le verifiche del caso (dal gg/mm/aaaa al gg/mm/aaaa)

INDICATORE DI QUALITÀ

1) Il sistema deve consentire all’istruttore di monitorare il seguente indicatore, anche attraverso una specifica rappresentazione grafica (che si aggiorna in tempo reale):

“Numero di convenzioni stipulate/Numero di richieste di stipula protocollate” - valore atteso 80%.

Con cadenza periodica (di xxxxx xxxxxxxxxx), l’istruttore dovrà avere la possibilità di produrre uno specifico report che contenga:

▪ il valore assoluto del numero di convenzioni stipulate (ovvero provviste delle firme digitali di tutte le controparti) nell’intervallo temporale definito dall’istruttore e suddiviso in trimestri (01/01/ al 31/03) semestri (dal 01/01 al 30/06) e annualità (dal 01/01 al 31/12).

▪ il valore assoluto del numero di richieste di stipula protocollate nel periodo di riferimento;

▪ il valore percentuale delle convenzioni stipulate rispetto al numero di richieste di stipula protocollate nel periodo di riferimento entro 90 giorni dalla data della richiesta (esclusi i giorni di eventuale sospensione del procedimento);

▪ Il report, tenendo in considerazione l’80% quale valore atteso, deve evidenziare gli eventuali scostamenti (positivi o negativi) rispetto al valore atteso. Gli scostamenti devono essere espressi in valore percentuale ed assoluto.

2) La generazione del report, e il relativo invio, sarà automatizzato: l’istruttore richiederà al sistema di generarlo agendo sullo specifico comando “Genera report indicatore” (collocato all’interno del box “Monitoraggio indicatori”) e potrà acquisire il report da inviare al RDP attraverso la mail ufficioconvenzioni@ats-

xxxxxx.xx

3) Il sistema dovrà memorizzare gli accessi effettuati dall’istruttore per monitorare l’indicatore e generare il relativo report.

4) Effettuato l’invio, il sistema darà evidenza di ciò attraverso l’apposizione di apposito flag nel box “Monitoraggio indicatori”, in corrispondenza della voce “Report semestrale indicatore”.

5) L’ambiente dovrà essere accessibile agli istruttori e al RDP

BOL1

IMPOSTA DI BOLLO

1) L’Ufficio convenzioni provvede all’invio (di norma entro il 15 gennaio di ogni anno) alla SC Programmazione, bilancio, monitoraggio e rendicontazione, di un file riepilogativo delle imposte di bollo dovute, ai fini:

▪ del versamento della totalità degli oneri di spettanza a carico di ATS;

▪ della quota parte a carico dei contraenti;

▪ della verifica del rimborso della quota parte a carico dei contraenti.

Il report che il sistema dovrà generare, entro il 15 gennaio dell’anno successivo a quello di riferimento dovrà contenere, per ogni convenzione stipulata nell’anno di riferimento, i seguenti dati:

▪ titolo della convenzione

▪ ragione Sociale, indirizzo e Codice Fiscale e/o Partita IVA della/delle controparte/controparti

▪ Importo totale dell’imposta di bollo

▪ quota parte a carico di ATS

▪ quota parte a carico della/delle controparte/controparti

▪ avvenuto assolvimento della quota parte a carico della/delle controparte/controparti, (dato acquisibile attraverso l’integrazione col portale dei pagamenti).

2) La generazione del report e il relativo invio sarà automatizzato: l’istruttore richiederà al sistema di generare il report agendo su uno specifico comando “Genera report bollo” (collocato all’interno del box “Monitoraggio indicatori”) e potrà acquisire il report da inviare all’Ufficio competente attraverso la mail xxxxxxxxxxxxxxxxxx@xxx-xxxxxx.xx

3) Effettuato l’invio il sistema darà evidenza di ciò attraverso l’apposizione di apposito flag nel box “Monitoraggio indicatori”, in corrispondenza della voce “Report annuale imposta di bollo”.

SCC1

SCADENZA CONVENZIONI

1) L’Ufficio convenzioni ha la necessità di verificare l’approssimarsi della data di scadenza delle convenzioni stipulate, per poter dare avvio alle attività procedimentali di competenza.

2) Il sistema, pertanto, dovrà prevedere una specifica rappresentazione grafica

delle convenzioni in scadenza, ovvero di quelle convenzioni per le quali

mancano 60 gg. alla data di scadenza, così che l’istruttore e il RDP possano verificare i relativi stati.

3) Al 60esimo giorno prima della scadenza della convenzione il sistema dovrà inviare una specifica mail di Alert (di tipo PEO) a ufficioconvenzioni@ats- xxxxxx.xx avente ad oggetto, il numero di registrazione della convenzione e la data di scadenza della stessa. A titolo esemplificativo si riporta il seguente oggetto: “Convenzione n. xy in scadenza il gg/mm/aaaa”.

Il testo della mail dovrà contenere le seguenti informazioni:

Oggetto della Convenzione: “CONVENZIONE TRA ATS DELLA CITTÀ METROPOLITANA DI MILANO E ASST DI LODI PER L’EFFETTUAZIONE DI PRESTAZIONI RELATIVE AGLI ACCERTAMENTI COMPLEMENTARI ALLA SORVEGLIANZA SANITARIA DEI DIPENDENTI, AI SENSI DEL D.LGS 81/08” in scadenza

il gg/mm/aaaa

Contraente 1 Ragione sociale

Contraente 2 Ragione sociale

Contraente 3 Ragione sociale

Contraente 4 Ragione sociale

Deliberazione di rif. DB n. xy del gg/mm/aaaa

4) A fronte della ricezione della mail di Alert, l’istruttore accede alla sezione relativa al “Monitoraggio” e agisce sulle funzionalità previste dal sistema per gestire la scadenza delle convenzioni. Nello specifico, su attivazione dell’istruttore, selezionando la convenzione di interesse, il sistema propone tutti i soggetti fisici e giuridici (nominativi delle controparti, dei referenti ATS della convenzione e struttura ATS di afferenza) legati alla specifica convenzione. L’istruttore ha la possibilità di inserire degli indirizzi diversi da quelli proposti dal sistema. L’istruttore, operata la scelta del caso, invia la mail ai soggetti selezionati (referente/indirizzo struttura di afferenza) per:

a. Segnalare l’approssimarsi della scadenza della convenzione

b. Prendere atto della conclusione delle attività convenzionali alla data di scadenza prevista.

Il testo della mail, per le fattispecie a. e b. dovrà ricalcare il seguente schema esemplificativo:

Xxxxxxxxxx.

In riferimento all’oggetto, si segnala l’approssimarsi della scadenza, al gg/mm/aaaa, della convenzione in calce, di cui si allega la delibera di adozione.

Qualora si ravvisi la necessità di proseguire nelle attività convenzionali, si chiede, cortesemente, di accedere alla sezione “Scadenza convenzioni” all’interno dell’area del gestionale di

competenza, per operare le scelte del caso.

c. Comunicare la volontà da parte di ATS (solo per casi particolari e motivati da urgenza) di prorogare la scadenza della convenzione attraverso la sottoscrizione di apposita nota protocollare, sottoscritta da tutti i contraenti.

Il testo della mail, per la fattispecie c. dovrà ricalcare il seguente schema esemplificativo:

Xxxxxxxxxx.

Si fa riferimento alla convenzione in oggetto, sottoscritto tra le Parti e perfezionato in data gg/mm/aaaa, la cui conclusione è stata fissata al gg/mm/aaaa, per comunicare che le attività convenzionali potranno proseguire, senza soluzione di continuità ed alle condizioni giuridico- economiche in essere, sino al prossimo gg/mm/aaaa, nelle more della definizione dei contenuti di ulteriore atto convenzionale tra le parti. La presente nota, firmata digitalmente - ai sensi dell’art. 24 del D.Lgs. 7 marzo 2005 n. 82 e ss.mm.ii. -dal Direttore Generale di ATS Milano e per accettazione, con analoga sottoscrizione, rispettivamente dal Direttore Generale dell’ASST ,

costituisce parte integrante e sostanziale de Protocollo in oggetto.

La nota di prosecuzione delle attività convenzionali (redatta sulla base del modello predefinito e caricato nel sistema) prolunga la decorrenza della durata della convenzione; una volta che sarà perfezionata attraverso le sottoscrizioni digitali delle controparti (gestita secondo le modalità previste nella fase GESTIONE DELLA SOTTOSCRIZIONE DIGITALE) deve essere abbinata alla convezione da cui discende, così come fatto per l’addendum. Perché ciò sia possibile è necessario che il sistema consenta all’istruttore, in fase di redazione della nota di abbinarlo alla relativa convenzione, attraverso la specifica funzione “Abbina alla convezione”, creata ad hoc.

Il sistema dovrà prevedere una specifica rappresentazione grafica, che consenta di visualizzare, unitamente alle convenzioni sottoscritte, anche le relative note di prosecuzione.

ESTRAZIONI

EST1

ESTRAZIONI

▪ Il sistema deve consentire la possibilità di elaborare dei report, sulla base di specifici criteri di ricerca che l’istruttore individuerà liberamente, definendone peraltro la relativa organizzazione nel layout del report.

▪ I criteri di ricerca saranno i seguenti: oggetto della convenzione, durata della convenzione, denominazione ente richiedente, costi/introiti della convenzione, denominazione del personale impegnato nelle attività convenzionali, …..

▪ L’estrazione dovrà poter essere estesa tanto alle convenzioni in vigore quanto

alle convenzioni scadute.

LE SPECIFICHE DELLE DIVERSE FASI

SFA1

FASE DELIBERANTE

Il sistema proporne una form con tutti i campi relativi ai metadati da alimentare su IRIDE, prealimentandola laddove le informazioni fossero già presenti sul sistema.

La form prevede due pulsanti:

a. “Invia a Iride”, che rimanda a IRIDE

b. “Fuori sacco”, che invece popola il template della delibera in modo che questa possa essere inviata all’ufficio delibere. È necessario che il sistema, in questo caso, consenta anche di stampare il pdf della delibera, sulla base di un template predefinito.

Nella compilazione della delibera il sistema deve dare facoltà all’istruttore di richiedere specifici pareri alle articolazioni aziendali di competenza, compreso il RDP.

SFA2

GESTIONE DELLE FIRME DIGITALI

Il sistema, selezionato il procedimento, propone tutti i contraenti che devono sottoscrivere l’atto (ATS compresa). L’istruttore seleziona tra i contraenti disponibili quello a cui inviare l’atto per la sottoscrizione. Il sistema quindi invia la pec, grazie all’integrazione col Protocollo), con l’atto da sottoscrivere e i relativi allegati. Ricevuto l’atto sottoscritto dal primo contraente, l’istruttore fa l’upload della convenzione per ritrasmetterla al successivo contraente, fino ad avvenuta acquisizione di tutte le sottoscrizioni previste.

Una volta ricevuto da un contraente la convenzione sottoscritta, il sistema non riproporrà questo contraente nella successiva fase di invio, ma proporrà solo i contraenti dei quali è ancora necessario acquisire la firma.

SFA3

STAND BY - In attesa di parere e di firma contraente

1) In questo box sono collocati i seguenti documenti, con l’indicazione della caratterizzazione specifica della tipologia di attesa:

a) i moduli di richiesta stipula per i quali è stata chiesta un’integrazione/modifica al richiedente (caratterizzati come “attesa integrazioni”);

b) gli atti per i quali è stata avanzata una richiesta di parere alle articolazioni aziendali interne, (caratterizzati come “in attesa di parere”);

c) gli atti per i quali sono state inviate le note protocollari, e relativi allegati. alla/alle controparte/controparti per l’acquisizione della/delle sottoscrizione/i digitale/i (caratterizzati come “in attesa di sottoscrizione digitale”).

È necessario che il sistema consenta di visualizzare, per ognuno degli

invii effettuati, gli estremi dell’invio (destinatario, numero e data di

protocollo) così da consentire un agevole monitoraggio degli invii già effettuati e da effettuare (in presenza di un numero di sottoscrittori superiore a due).

Ricevuta la/le relativa/e pec di riscontro, l’istruttore dà seguito alle attività previste per l’atto perfezionato, ovvero la registrazione nel

registro convenzioni e il monitoraggio dell’indicatore.

IRI1

INTEGRAZIONE CON IRIDE

Devono prevedersi dei campi specifici, da alimentare con i dati richiesti dal software IRIDE, così da favorire l’acquisizione automatica dei dati da IRIDE stesso.

L’integrazione si declina nel seguente modo affinché la gestione del processo deliberativo di IRIDE sia gestito all’interno del software convenzioni:

▪ alimentazione dei metadati IRIDE per la creazione della proposta di delibera

▪ redazione del testo (secondo le regole di IRIDE)

▪ upload degli allegati alla delibera

▪ scatenare l’evento avvio (che consentirà ad iride di inviare la proposta di delibera al controllo di gestione)

▪ il sistema deve ricevere da iride le informazioni di ritorno dal controllo di gestione:

✓ se positivo, scatenare l’evento avvio che invierà la proposta al RDP

✓ se negativo, occorrerà integrare il testo e ripartire dalla prima fase di integrazione

Per tale integrazione saranno disponibili le specifiche tecniche del fornitore della soluzione applicativa in uso.

DESCRIZIONE SINTETICA DEGLI AMBIENTI

AMB1

AMBIENTE DEL RICHIEDENTE

È l’ambiente nel quale ogni richiedente può effettuare diverse operazioni, tra le quali:

1. Richiedere la stipula: il sistema proporrà la specifica maschera con tutti i campi da compilare

2. Invio della richiesta all’Ufficio convenzioni per la verifica preliminare di competenza. La richiesta inviata sarà classificata come “In attesa di verifica” e inserita nel relativo box.

3. La verifica preliminare può richiedere un nuovo inoltro per acquisire delle integrazioni. In questo caso la richiesta andrà nel box “Richiesta da integrare”.

4. Effettuate le integrazioni richieste, il richiedente invia nuovamente la richiesta all’Ufficio convenzioni e il procedimento ritorna nel box “In attesa di verifica”.

5. A fronte della valutazione positiva delle verifiche, il sistema aggiorna con i

dati della protocollazione la richiesta e invia al richiedente la mail, trasferisce la convenzione nel box “Procedimento in corso”.

6. Qualora la valutazione dovesse essere negativa (i.e., per mancanza dei requisiti sostanziale per la stipula della convenzione), il richiedente riceverà una nota protocollare da parte dell’istruttore in ordine alla non procedibilità dell’iter convenzionale.

7. Il richiedente può ricevere la richiesta di parere sul testo convenzionale da parte dell’ufficio convenzioni. In questo caso la convenzione passa nel box “Parere da fornire”.

8. Fornito il parere l’atto viene spostato box “Procedimento in corso”.

9. Completata la redazione del testo il richiedente visualizza lo stato di avanzamento del procedimento nelle sue successive fasi: deliberazione e acquisizione delle sottoscrizioni digitali.

10. Ad avvenuta conclusione del procedimento, il richiedente riceverà delibera e convenzione perfezionata.

11. In prossimità della scadenza della convenzione il richiedente riceverà una mail

informativa per avviare le procedure di rinnovo o attestare l’avvenuta conclusione della convenzione.

AMB2

AMBIENTE ISTRUTTORE

È l’ambiente nel quale operano coloro che sono incaricati di:

1. verificare la completezza della documentazione ricevuta dal richiedente

2. richiedere pareri funzionali alla redazione del testo

3. comunicare al proponente la chiusura dell’iter procedurale, per mancanza delle condizioni per la stipula della stessa

4. dare avvio alla redazione del testo convenzionale

5. condividere il testo con la controparte per cristallizzarlo e successivamente

6. acquisirne le firme digitali

7. occuparsi del procedimento deliberativo di adozione/presa d’atto del testo convenzionale

8. inviare delibera e convenzione perfezionata ai referenti

9. inviare la delibera di adozione/presa d’atto al soggetto incaricato della gestione dei relativi ordini

10. inserire all’interno del sistema, dopo la registrazione della convenzione per i tirocini, le soglie minime previste dalla normativa

11. trasmettere alla SC Gestione del personale, il report relativo ai tirocinanti presenti in Azienda.

AMB3	AMBIENTE CONSULENTI INTERNI

Attualmente i consulenti interni coincidono con le seguenti funzioni aziendali: Data Protection Officer, SC Bilancio, SC Gestione Acquisiti, SC Gestione Patrimoniale, SC Gestione Risorse Umane.

È l’ambiente nel quale operano i soggetti deputati a:

1. emettere i pareri richiesti dall’istruttore

2. verificare il rispetto della normativa Privacy

3. verificare le condizioni per esperire il negoziato e/o altre procedure ad evidenza pubblica

4. verificare la congruità dei costi/ricavi, derivanti dalla convenzione

5. verificare le incompatibilità per il personale individuato per lo svolgimento delle prestazioni convenzionali

6. valutare i bisogni inerenti all’attivazione di sedi e/o alla realizzazione di opere pubbliche e/o alla manutenzione di beni immobili o apparecchiature che costituiscono il presupposto o l’obiettivo del rapporto convenzionale

7. evidenziare impedimenti alla stipula della convenzione

8. ravvisare la necessità di ulteriori approfondimenti istruttori.

AMB4

AMBIENTE RESPONSABILE DEL PROCEDIMENTO

È l’ambiente nel quale opera il soggetto deputato a:

1. assegnare agli istruttori le convenzioni da istruire

2. valutare le istanze ricevute

3. verificare la congruità dei pareri emessi

4. verificare il testo convenzionale prima della sua cristallizzazione

5. verificare la delibera di adozione/presa d’atto della convenzione

6. agire all’interno di IRIDE per le funzioni connesse al Dirigente proponente

7. verifica e sottoscrive le note protocollari che gli istruttori inviano ai richiedenti nel caso di impossibilità di avvio del procedimento di stipula della convenzione.

AMB5

AMBIENTE TUTORS

È l’ambiente nel quale opera il soggetto deputato a:

1. inserire le informazioni relative all’anagrafica e alla presenza del tirocinante/specializzando, nonché all’inserimento delle specifiche del corso di laurea

2. monitorare il rispetto del numero massimo di tirocinanti/specializzandi ammessi

3. uploadare nel gestionale la documentazione relativa al tirocinio (i.e, Progetto formativo, documento di valutazione del tirocinio, il pdf del diario delle presenze, …)

3.2 Caratteristiche generali del servizio ‌

GEN1

Console di amministrazione

Il sistema deve prevedere una console di gestione dedicata agli amministratori per svolgere le necessarie attività di configurazione in back-office, in particolare:

• gestione, configurazione e profilazione delle diverse tipologie di utenza;

• configurazione di tutte le proprietà degli oggetti gestiti dall’applicazione;

• configurazione dei template di reportistica;

• configurazione delle etichette;

• configurazione degli alert di notifica;

• consultazione dei log applicativi.

GEN2

I&A utenti

Il sistema deve consentire l’identificazione & autenticazione (I&A) degli utenti. Tutti gli utenti sono interni ad ATS e devono poter accedere al sistema tramite le proprie credenziali del dominio Azure Active Directory (AD) di ATS.

Deve essere prevista la funzionalità di Single Sign On (SSO) per gli utenti che accedono al sistema attraverso una postazione di lavoro (PdL) in dominio ATS con le relative credenziali di dominio.

GEN3	Ruoli utenti
	L’applicativo deve permettere la definizione personalizzata dei ruoli utente. Oltre al ruolo Amministratore, da assegnare agli utenti coinvolti nella gestione di back-office che possono gestire tutte le funzionalità e le informazioni della piattaforma, sarà necessario definire altri ruoli specifici con diversi livelli di accesso ai dati e alle funzioni.

GEN4	Stampe, ricerca e reportistica

Il sistema deve implementare le seguenti funzionalità applicate ai diversi contesti d’uso (tecnico, amministrativo, economico) descritti nel documento:

• gestione delle stampe;

• strumenti e filtri di ricerca;

• navigazione e consultazione dei dati nel rispetto dei diritti di accesso attribuiti ai singoli utenti;

• ricerca degli allegati tramite metadati (tag) associati;

• export dei dati e dei documenti nei formati standard maggiormente diffusi (ad esempio: CSV, TXT, PDF, …);

• generazione report relativi a ciascuna categoria di dati gestiti;

• generazione automatica di “alert” (per la notifica di scadenze relative a certificati digitali, licenze, manutenzioni, adempimenti in genere, …). A questo proposito fare riferimento al requisito ALM1 “Alert”.

GEN5

Integrazione con Microsoft SharePoint Online (SPO)

Il sistema deve permettere l'integrazione con Microsoft SPO, il sistema documentale adottato da ATS per finalità archivistiche.

Oltre alla rappresentazione logica “embedded” legata al prodotto software utilizzato, il sistema deve permettere anche una rappresentazione gerarchica che faciliti la consultazione e la condivisione dei documenti da parte di un utente finale.

La struttura gerarchica che permette di suddividere e organizzare i dati e i documenti soggetti all’archiviazione su SPO deve essere personalizzabile da parte degli amministratori del sistema.

GEN6	Verifica integrità del software
	Il sistema deve implementare opportuni meccanismi (ad esempio: checksum) per la verifica e la visualizzazione della release del software rilasciato in produzione e la sua corrispondenza con la baseline software corrente consegnata ad ATS sul proprio repository Microsoft DevOps.

GEN8

Caricamento dei documenti

Il sistema deve permettere il caricamento di documenti nei formati più diffusi.

Tutti i file di produzione “esterna” del software devono essere compatibili con i software open source più in uso (ad esempio Open Office) nella versione più aggiornata disponibile. Il sistema deve dare la possibilità di caricare file (per esempio, PDF) che siano accessibili soltanto agli utenti con un certo profilo utente.

REQ2

Motore di workflow

Il sistema deve disporre di un motore di workflow per la gestione delle richieste di convenzioni inserite dai vari CdR di ATS e del procedimento gestito dall’Ufficio convenzioni.

La gestione del workflow autorizzativo deve avere caratteristiche differenti a seconda dei vari contesti.

Il sistema deve consentire ad un utente opportunamente profilato la gestione della presa in carico e validazione, autorizzazione ed attribuzione ad un referente di qualsiasi richiesta e procedimento.

Il sistema deve gestire l’elenco e lo smistamento delle richieste pervenute e dei procedimenti in corso.

Il sistema deve consentire l’assegnazione e l’eventuale riassegnazione di una richiesta specifica ad uno assegnatario e/o istruttore e/o consulente ecc…

Il sistema deve consentire la riassegnazione di un procedimento al richiedente.

Il workflow autorizzativo deve prevedere la notifica via e-mail al servizio richiedente in modo che sia a conoscenza delle varie fasi dell’iter procedimentale.

3.2.1 Reportistica ‌

REP1

Report

Il sistema deve consentire la generazione di reportistica dedicata attraverso cruscotti gestionali con vista riepilogativa

Il sistema deve permettere di modificare la formattazione dei report attraverso la console di amministrazione, di produrne un’anteprima ed esportarli in:

• versione editabile (Word, Excel);

• versione PDF

REP2

Tipologie di report

Il sistema deve consentire la generazione di varie tipologie di report, in particolare:

• ….

3.2.2 Avvisi, alert e notifiche ‌

ALM1

Alert

Il sistema deve consentire la generazione di alert relativi ad eventi programmati (ad esempio: warning per la segnalazione di convenzioni in scadenza, procedimenti in scadenza, ecc…

A fronte di ogni alert, il sistema deve poter inviare automaticamente delle e-mail di notifica (promemoria o “reminder” periodici o specifici come ad esempio ai cambi di stato) ai destinatari configurati attraverso la console di amministrazione.

3.2.3 Reportistica e scadenziario ‌

CONV8	Monitoraggio scadenze convenzioni
	Il sistema deve consentire il monitoraggio di tutte le convenzioni in stato “Attivaa”.

CONV9	Report selettivi
	Il sistema deve consentire la generazione, l’export e la stampa di report selettivi in base allo stato del procedimento. Devono essere previsti tutti i criteri di filtraggio in base agli attributi definiti precedentemente.

CONV10

Scadenzario

Il sistema deve consentire la gestione dello scadenziario ovvero inviare ad una lista di distribuzione, predefinita e configurabile tramite console di amministrazione, degli alert via e-mail per la notifica della scadenza della convenzione (in mesi).

La gestione dei mesi dalla scadenza deve essere configurabile attraverso la console di amministrazione. Deve essere possibile configurare e differenziare gli alert a seconda della tipologia di affidamento: ad esempio, 12 mesi prima della scadenza nel caso di una precedente gara aperta, 2 mesi prima della scadenza per un affidamento diretto.

CONV11

Gestione convenzioni in scadenza

Il sistema deve consentire la gestione degli alert relativi alle convenzioni in scadenza (fare riferimento al requisito CONV9 “Report selettivi”) verso il CdR richiedente/contraente la convenzione. Deve essere anche possibile per l’utente amministrativo selezionare l’inoltro automatico della scadenza ai referenti della convenzione al fine di verificare la necessità di procedere o meno con una nuova convenzione. Se confermata l’esigenza, il processo riparte con l’inserimento di una nuova richiesta di convenzione (fare riferimento al requisito RIC1 “Procedure di richiesta di beni/servizi”).

4 Requisiti non funzionali ‌

Si elencano di seguito i requisiti non funzionali, organizzativi, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura.

4.1 Requisiti organizzativi ‌

ORG1	SPOC (Single Point of Contact)
	Al fine di rendere più efficaci le comunicazioni tra ATS e Aggiudicatario, quest’ultimo dovrà individuare e comunicare ad ATS, fin dalle prime fasi di analisi e durante tutte le fasi operative, un referente unico di contatto (SPOC) per tutta la durata del servizio.

ORG2	Assistenza tecnica qualificata
	A seconda della tipologia di intervento richiesto, l’Aggiudicatario metterà a disposizione di ATS un proprio servizio di assistenza tecnica specialistica in grado di intervenire efficacemente, eventualmente anche attraverso work-around temporanei, nonché tempestivamente in funzione del livello di gravità del malfunzionamento.

4.2 INTEGRAZIONI ‌

Nei requisiti funzionali sono descritte funzionalità che richiedono integrazioni con applicazioni in uso in ATS. In particolate erano indicate le seguenti integrazioni:

• Active Directory

• Sistema di gestione documentale e protocollo

• Gestione delibere

• Gestione del personale

• Portale dei pagamenti

• Datawarehouse

Fatte salve le applicazioni o sistemi gestiti direttamente da ATS (Active Directory e portale dei pagamenti), le applicazioni erogate da soggetti fornitori terzi di ATS dovranno essere realizzate dal fornitore della presente fornitura attraverso il diretto coinvolgimento dei fornitori delle applicazioni da integrare.

INT1

INTEGRAZIONI

La realizzazione delle integrazioni, per ogni soluzione applicativa da integrare, avverrà secondo le seguenti macro fasi:

1. Condivisione con ATS della documentazione tecnica di integrazione

2. Eventuali incontri ad hoc tra tutte le parti coinvolte (ATS, Fornitore della presente fornitura e fornitore della soluzione da integrare)

3. Definizione di un documento tecnico a carico del fornitore della presente fornitura (includendo le parti del fornitore del software da integrare) che indichino le attività necessarie all’integrazione con l’identificazione delle giornate di attività richieste

(che dovranno includere sia quelle del fornitore della presente fornitura che quelle del fornitore del software da integrare)

4. Valutazione della congruità della richiesta di giornate da parte di ATS

5. Esecuzione delle attività, nel caso di congruità

6. Collaudo dell’integrazione

7. Ad esito favorevole del collaudo dell’integrazione, liquidazione. Le integrazioni che sono soggette a tale processo realizzativo sono:

• Sistema di gestione documentale e protocollo

• Gestione delibere

• Gestione del personale

• Portale dei Pagamenti

• Datawarehouse

I tempi di realizzazione e collaudo sono quelli stabiliti per la soluzione applicativa da realizzarsi con la presente fornitura.

ATS ha facoltà decidere di posticipare o, se lo ritenesse opportuno, anche di non effettuare una o più delle integrazioni indicate.

4.3 Requisiti di security ‌

SEC1

Sicurezza logica, fisica e organizzativa

L’Aggiudicatario dovrà garantire tutte le misure di sicurezza logica (riservatezza, integrità, disponibilità dei dati) e organizzativa per garantire il rispetto della normativa vigente, tenendo conto delle best practices (in particolare, quanto previsto dalle linee guida OWASP) di sicurezza informatica. Fare riferimento a quanto riportato al capitolo “Riferimenti documentali e normativi” del presente documento.

Tutte le integrazioni applicative con il sistema dovranno essere effettuate tenendo conto di tutte le best practices e protocolli di sicurezza informatica.

SEC2

Privacy

Fare riferimento alla normativa sulla privacy secondo quanto riportato al capitolo “Riferimenti documentali e normativi” del presente documento.

L’Aggiudicatario sarà designato come Responsabile Esterno al trattamento dei dati.

SEC3	GDPR (General Data Protection Regulation) – Regolamento UE 2016/679
	Le prestazioni oggetto della presente fornitura dovranno essere conformi al Regolamento Generale sulla Protezione dei Dati (GDPR, General Data Protection Regulation – Regolamento UE 2016/679) e all’adeguamento della normativa italiana alle disposizioni del Regolamento UE 2016/679 (D. Lgs. n. 101/2018).

SEC4

Protocollo HTTPS

Il software applicativo, oggetto della presente fornitura, dovrà essere fruibile dai client esclusivamente mediante protocollo HTTPS.

L’Aggiudicatario dovrà provvedere alla fornitura ed al rinnovo dei certificati digitali necessari per il corretto funzionamento del sistema. Ogni certificato fornito dovrà essere emesso da una CA pubblicamente riconosciuta ed essere intestato ad ATS.

SEC5

Accordi di Non Divulgazione (NDA) e di Trattamento dei Dati (DPA)

L’Aggiudicatario dovrà garantire la non divulgazione delle informazioni sensibili trattate dal sistema a cui avrà accesso nel corso delle fasi di progettazione, sviluppo, avviamento e manutenzione del sistema. Tali accordi (Non Disclosure Agreement, NDA) dovranno valere anche dopo la conclusione della presente fornitura.

L’Aggiudicatario dovrà garantire il rispetto di accordi specifici sul trattamento e la protezione dei dati (Data Protection Agreement, DPA), personali e sensibili secondo la normativa vigente, con cui verrà in contatto nel corso delle attività.

SEC6

Audit e Monitoraggio

ATS si riserva la facoltà di sottoporre ad audit e monitoraggio tutte le attività del servizio erogato e in particolare relative al trattamento delle informazioni confidenziali effettuate dall’Aggiudicatario e dal personale di cui esso intende avvalersi, per tutta la durata contrattuale. Le attività di audit e monitoraggio potranno riguardare i seguenti processi:

• qualità e prestazioni dei servizi erogati dal sistema;

• conformità dei servizi erogati dal sistema alle policy di ATS, riferite nel presente documento;

• vulnerability assessment e relativi penetration test (VAPT) del sistema.

ATS informerà lo SPOC dell’Aggiudicatario, con preavviso di almeno 30 giorni, della pianificazione, dei tempi e delle modalità delle sessioni di audit previste.

4.4 Requisiti e vincoli tecnologici e infrastrutturali ‌

TEC1	Accesso web

Le funzionalità messe a disposizione dal sistema dovranno essere raggiungibili dagli utenti (interni ad ATS), attraverso l’accesso alla rete Internet, col solo utilizzo di un browser, senza limitazioni di accessi concorrenti.

Lato client, il sistema dovrà essere conforme alle normative nazionali in tema di accessibilità dei sistemi informatici. Il rispetto dei requisiti di accessibilità verrà verificato da ATS in fase di collaudo, riservandosi la facoltà di subordinare la valutazione del progetto al parere di una o più associazioni a tutela di disabilità di vario genere.

La progettazione del portale dovrà rispettare in particolare i requisiti tecnici di accessibilità riportati nell’Allegato A del Decreto Ministeriale 8 luglio 2005 e successive modifiche. Una particolare attenzione deve essere prestata ai temi di accessibilità, secondo quanto previsto dalle più recenti linee guida AgID in tema di design di siti web. Fare riferimento a quanto riportato al capitolo “Riferimenti documentali e normativi” del presente documento.

La progettazione del portale dovrà garantire la massima conformità ai requisiti del W3C (priorità 3, AAA) ed il rispetto delle linee guida W3C.

Non dovrà essere richiesta l'installazione o l'utilizzo di componenti aggiuntivi (come ad esempio: plug-in, componenti ActiveX, java applet, DLL, …) né si dovranno rendere necessarie configurazioni particolari sulle impostazioni dei browser o dei sistemi operativi dei client.

L’applicazione dovrà poter essere utilizzata anche in mobilità, attraverso tablet e smartphone delle piattaforme più comuni (ad esempio, iOS, Android, …).

TEC2

Interfaccia web

Le funzionalità messe a disposizione dal sistema dovranno poter essere fruibili dagli utenti con tutti i principali browser presenti sul mercato, garantendo la corretta rappresentazione dei contenuti da parte dei motori di rendering utilizzati.

Più nel dettaglio, a seconda del dispositivo operativo utilizzato dall’utente, dovrà essere garantita la compatibilità con i seguenti sistemi operativi e browser:

• piattaforma desktop: Windows, OS X, Linux;

• piattaforma mobile: IOS e Android;

• Microsoft Edge, Mozilla Firefox, Google Chrome;

nelle versioni che i rispettivi vendor garantiranno dal punto di vista del supporto per tutto il periodo della validità contrattuale del presente Capitolato Tecnico.

Per una rapida visualizzazione delle pagine web, il sistema dovrà garantire un peso pagina web ottimizzato dal punto di vista della dimensione.

Le interfacce grafiche esposte dal servizio dovranno essere “responsive”, quindi in grado di adeguarsi alle esigenze di visualizzazione dei dispositivi mobile, ovvero riducendo al minimo la necessità per l'utente di scorrere o ridimensionare le pagine adattando la dimensione delle immagini ed in generale di tutti i contenuti a larghezza fissa alla risoluzione e alle dimensioni dello schermo visualizzante.

La presentazione delle pagine web dovrà essere realizzata in HTML5, dovrà essere omogenea in tutti i contesti con modalità di navigazione quanto più ricorrenti per facilitare l'utente nell'accesso ai contenuti o servizi di interesse.

Il sistema nel suo complesso dovrà utilizzare meccanismi di “url rewrite” o implementare un meccanismo di “smart URL” per generare URL di navigazione parlanti.

TEC3

RDBMS, infrastruttura applicativa e scalabilità

L’organizzazione della base dati del sistema dovrà essere implementata utilizzando le tecnologie open source RDBMS di accesso ai dati.

Il deployment del database schema dovrà avvenire tramite script SQL così come eventuali modifiche alla struttura del database in caso di aggiornamenti. Tali script dovranno essere:

• sviluppati e collaudati in ambiente di sviluppo in modo da consentire il corretto deployment del database nei previsti ambienti di collaudo e produzione erogati dall’Aggiudicatario;

• conservati nel repository del codice di Azure DevOps in quanto parte integrante della fornitura.

Il sistema potrà essere scritto nelle seguenti tecnologie: .NET, .NET Core, Java, Ruby, Node.js, PHP, Python.

La componente web server del sistema dovrà essere stateless per garantire la scalabilità orizzontale. A questo proposito il sistema dovrà essere progettato in modo da essere quanto più aderente ad una logica stateless in modo da poter sfruttare le funzionalità di scalabilità elastica del cloud computing. Quando un'applicazione è stateless, il server su cui viene indirizzata una generica richiesta non memorizza nessuno stato della sessione client; i dati di sessione devono essere memorizzati sul client e passati al server secondo necessità oppure memorizzati in un sistema di sessione centralizzato (utilizzando un database dedicato oppure un servizio di cache, se disponibile).

Un’efficace scalabilità orizzontale della soluzione applicativa è fondamentale in cloud per rispondere ad un aumento del carico applicativo semplicemente aumentando i server e senza impatti sull’applicazione.

Si considerano preferenziali piattaforme applicative che garantiscano by default la protezione dei dati inattivi (database, file di log, backup) attraverso meccanismi crittografici senza la necessità di interventi a livello applicativo.

L’Aggiudicatario dovrà garantire, nel corso del contratto di manutenzione, l’adeguamento di tutte le componenti applicative e delle relative strutture dati a fronte di eventuali aggiornamenti che si rendano necessari per adeguamenti normativi, di sicurezza o tecnologici.

Deve essere garantito l’accesso al DBMS da parte di operatori ATS.

TEC4

Evoluzioni tecnologiche

L’Aggiudicatario dovrà garantire l’adeguamento del sistema informativo oggetto del presente Capitolato Tecnico anche rispetto a nuove versioni ed aggiornamenti di browser, sistemi operativi, software di base, middleware che i vari vendor dovessero rilasciare per tutto il periodo di validità contrattuale.

Tali aggiornamenti dovranno essere garantiti entro:

• un mese per quanto riguarda il rilascio di patch;

• tre mesi per quanto riguarda il rilascio di nuove release.

TEC5

Identificazione & Autenticazione degli utenti

Il sistema dovrà utilizzare la seguente soluzione tecnologica di I&A:

• Microsoft Azure Active Directory (conforme alla normativa di sicurezza GDPR) per gli utenti interni ad ATS e per gli utenti amministratori (sia essi interni ad ATS che utenti guest dell’Aggiudicatario); l’accesso dovrà essere possibile in SSO (Single Sign On) da PdL in dominio ATS.

Azure AD dispone di una modalità di registrazione delle utenze esterne al dominio ATS (guest) come indicato in TEC6 - “Gestione utenti e Azure Active Directory (AD)”.

TEC6

Gestione utenti e Azure Active Directory (AD)

L’accesso al sistema dovrà avvenire mediante autenticazione Microsoft Azure AD (protocolli SAML 2.0 e OpenID Connect).

Le utenze del sistema dovranno essere create in Azure AD ed opportunamente profilate (ruoli utente) all’interno dell’applicazione stessa (attraverso la console di amministrazione).

L’applicazione dovrà disporre di tutte le informazioni (certificati e metadati) e funzionalità per la convalida dei token di autenticazione restituiti da Azure AD: a valle della convalida dei token verranno avviate le sessioni utente.

Le policy di validità temporale delle sessioni utente implementate da Azure AD e dall’applicazione stessa dovranno impedire la potenziale perdita dei dati alla scadenza dei token di sicurezza.

Microsoft Azure AD dispone di una modalità di registrazione delle utenze esterne (appartenenti all’Aggiudicatario) al dominio ATS in modo che possano essere anche loro soggette alle policy di gestione delle password previste per le utenze interne di dominio.

TEC7	Integrazione con strumenti documentali aziendali

Il sistema dovrà permettere l’archiviazione di tutti i file caricati anche attraverso l’integrazione con Microsoft SharePoint Online (SPO), il sistema di archiviazione adottato da ATS.

La consultazione dei documenti depositati in SPO dal sistema è subordinata ad una gestione dei privilegi utente a cura dell’amministratore dello stesso.

TEC8

Caricamento dei documenti

Il sistema dovrà permettere il caricamento di documenti nei formati più diffusi, comprendendo anche file firmati digitalmente e cartelle compresse.

Tutti i file di produzione “esterna” del software (ad esempio: report, tabelle, fogli di calcolo, …) dovranno essere compatibili con i software open source più in uso (ad esempio: Open Office) nella versione più aggiornata disponibile.

TEC9

Azure DevOps

Il sistema applicativo richiederà, per tutto il suo ciclo di vita, l'esecuzione di attività sistemistiche da parte dell'Aggiudicatario connesso all'ambiente cloudgestito in hosting e alle relative risorse.

Nell’ambito del servizio di hosting oggetto di fornitura, per quanto concerne le attività di predisposizione degli ambienti e di deployment del software negli ambienti operativi previsti (collaudo, produzione), ATS considera preferenziale la gestione dell’infrastruttura di hosting dedicata al sistema e delle specifiche tecniche attraverso modelli standard (ad esempio: template JSON) che dovranno essere documentati e messi a disposizione di ATS nel proprio repository del codice sorgente su Microsoft Azure DevOps.

Il progetto dovrà essere condotto secondo metodologia DevOps (Agile), attraverso strumenti e tecniche di Continuous Integration/Continuous Delivery.

L’Aggiudicatario dovrà adottare gli strumenti messi a disposizione da Azure DevOps, in particolare:

• Azure DevOps Project, ambiente dedicato alla gestione del progetto;

• Azure Repos, repository del codice sorgente dell’applicazione e dei file (template JSON);

• Azure Boards, strumenti per la pianificazione, governance e condivisione degli avanzamenti del progetto.

L’utilizzo da parte dell’Aggiudicatario degli strumenti Microsoft Azure DevOps permette di assicurare ad ATS la supervisione sulla governance del progetto, nelle fasi di progettazione, realizzazione, delivery ed esercizio.

TEC10

Performance

Il sistema dovrà nel suo complesso garantire massimi livelli di scalabilità.

Dovrà essere garantito un efficace monitoraggio, h24 per 365 giorni all'anno, dello stato di disponibilità del servizio di hosting e delle sue componenti (disponibilità dell’applicazione web e della banda di connessione) con notifica automatica (e-mail, sms) ad ATS in caso di eventuali disservizi. Il sistema dovrà prevedere la disponibilità di pagine di cortesia o “Landing Page” a cui indirizzare gli utenti del sistema in caso di sua indisponibilità per potenziali disservizi o per attività di manutenzione programmata. La manutenzione programmata dovrà essere sempre condivisa e autorizzata da ATS.

TEC11

Backup

Il sistema dovrà permettere il ripristino totale o parziale dei dati dalle copie di backup. A questo proposito dovrà essere possibile il ripristino dei contenuti relativamente agli ultimi 14 giorni lavorativi.

L’Aggiudicatario dovrà sottoporre alla validazione ed accettazione di ATS le policy e le procedure di backup adottate, prevedendo una retention minima di 14 giorni, al fine di garantire il backup dei dati gestionali e di sistema.

L’Aggiudicatario dovrà eseguire le attività di backup in accordo con le policy e le procedure di backup e dovrà notificare ad ATS, entro otto ore lavorative successive, ogni evento che abbia causato la mancata esecuzione di una attività di backup.

ATS potrà richiedere, per finalità di monitoraggio del servizio, l’esecuzione di procedure di test sulla funzionalità di backup / restore per assicurarsi attraverso verifiche ispettive la corretta operatività del servizio.

TEC12

Sistema di testing automatici

Al fine di mitigare i rischi derivanti da comportamenti anomali del software determinati per esempio dalla presenza di bugs o da regressioni a seguito di interventi manutentivi correttivi e/o evolutivi e/o normativi, tutte le sessioni di collaudo (secondo le regole previste negli appositi capitoli del presente documento) dovranno prevedere anche l’esecuzione di test automatici, configurati dal fornitore attraverso appositi tools di cui il fornitore dovrà essere dotato e i cui eventuali costi di licenza saranno totalmente a

carico del fornitore stesso.

4.5 Requisiti di migrazione ‌

MIG1	Popolamento iniziale
	La Fornitura dovrà prevedere la predisposizione dei database interni del sistema (import: anagrafiche dei fornitori, …) e garantire il popolamento iniziale del sistema

secondo le tempistiche stabilite da ATS. Tali attività saranno propedeutiche al collaudo ed all’avviamento del sistema in produzione.

4.6 Requisiti di usabilità ‌

USA1	Facilità d’Uso
	Il sistema dovrà essere progettato e implementato in modo da agevolare ogni categoria di utenza prevista durante le relative fasi operative. L’interfaccia grafica dovrà essere implementata in italiano.

USA2	Interfacce Help-On-Line
	Il sistema dovrà disporre di una guida in linea delle funzionalità, ad integrazione della documentazione utente e operativa. La guida in linea dovrà essere implementata in italiano.

USA3

Inserimento dati

Il sistema dovrà disporre di opportuni controlli per evitare l’inserimento di informazioni errate e/o incomplete, garantendo controlli di congruenza dei dati inseriti dall’utente.

Il sistema dovrà inoltre fornire avvisi, eventualmente non bloccanti, qualora le maschere di inserimento dati non risultino essere state integralmente compilate. La messaggistica utente (avvisi, alert) deve essere configurabile in funzione delle diverse tipologie di utenza.

Il sistema dovrà massimizzare l’utilizzo di menu a tendina e dizionari, limitando ai soli campi di annotazione l’inserimento del testo libero.

USA4

Dispositivi mobili

Il sistema dovrà essere progettato e implementato in modo da agevolare ogni categoria di utenza nella consultazione dei dati, sui diversi dispositivi utilizzati (desktop, mobile).

L’Aggiudicatario dovrà utilizzare strumenti e tecniche volte a garantire che l’interfaccia grafica dell’applicazione risponda adeguatamente sui diversi dispositivi e/o browser, in modo particolare per consentire una adeguata navigazione sui dispositivi mobili (smartphone, tablet).

4.7 Cessione in riuso ad altre PA ‌

REU1

Cessione in riuso

L’Aggiudicatario dovrà garantire tutte le attività di messa a riuso del software commissionato o di una sua parte, per conto di ATS e secondo quanto definito dalle Linee Guida AgID.

Ogni componente applicativa del sistema potrà essere segnalata ad AgID per essere resa disponibile in modalità open source sul repository Developers Italia. A questo proposito, fare riferimento alle linee guida di XxXX riportate nel capitolo “Riferimenti documentali e normativi”.

5 Progettazione, realizzazione e delivery ‌

5.1 Responsabilità ‌

L’Aggiudicatario è responsabile delle attività di progettazione, realizzazione e messa in esercizio del sistema informativo oggetto del presente Capitolato Tecnico.

Per tutto quanto non espressamente menzionato nel presente Capitolato si richiama quanto disciplinato e previsto dal regolamento adottato dall’AgID con Determinazione del 15 dicembre 2021,

n. 628, dalle determine n. 306 e n. 307 del 18 gennaio 2022 dell’ACN e al Decreto direttoriale prot.

N. 29 del 02/01/2023 di ACN e di tutti i relativi allegati.

Sono inoltre comprese nella fornitura tutte le attività relative alla predisposizione del repository del codice sorgente sulla sottoscrizione Microsoft Azure DevOps di ATS, mentre il deployment del software deve essere previsto negli ambienti operativi (collaudo, produzione) in cloud. A questo proposito fare riferimento a quanto indicato nel requisito tecnologico “TEC9 - Azure DevOps”.

Il progetto esecutivo dell’Aggiudicatario deve dare evidenza dell’applicazione delle best practices sulla conduzione del progetto, dalla pianificazione, alle scelte organizzative, alle metodologie adottate volte ad assicurare il controllo e la riduzione dei rischi di progetto per tutto il suo ciclo di vita, dalla progettazione, allo sviluppo, alla manutenzione del sistema in esercizio.

ATS intende cooperare con l’Aggiudicatario per garantire il corretto andamento ed avanzamento delle attività di progettazione e di realizzazione del sistema informativo oggetto del presente Capitolato Tecnico.

Nel suo ruolo di responsabilità del contratto e di gestione del rapporto di fornitura, si richiede all’Aggiudicatario la massima trasparenza e tracciabilità delle attività svolte in tutte le fasi del progetto, nel rispetto degli obiettivi e dei vincoli contrattuali previsti. A questo proposito il progetto esecutivo dell’Aggiudicatario deve definire le modalità, le fasi e le date (milestone) di condivisione con ATS dei previsti deliverable di progetto.

Per assicurare ad ATS la supervisione sulla governance del progetto in tutte le sue fasi (progettazione, realizzazione, delivery ed esercizio), l’Aggiudicatario è tenuto a adottare gli strumenti Microsoft Azure DevOps utilizzati da ATS ed applicare la relativa metodologia Agile ed un approccio operativo di Continuous Integration/Continuous Delivery. La gestione del progetto da parte dell’Aggiudicatario deve consentire ad ATS di disporre nel proprio repository Azure DevOps, oltre al codice sorgente, consistente ed allineato con il codice rilasciato in produzione, di tutta la documentazione di progetto

comprendente la pianificazione di dettaglio (piano di progetto, piano di qualità, piano di test), i documenti di analisi funzionale di dettaglio (incluso il disegno dei mockup delle UI) e di specifica architetturale (comprendente le modalità di realizzazione delle integrazioni applicative), la strategia di integrazione e di test, la documentazione di collaudo, la strategia di caricamento e migrazione dei dati già esistenti, la manualistica operativa da utilizzare anche nel corso delle attività di formazione dell’utenza di ATS. Si sottolinea che ATS dovrà poter disporre su Microsoft Azure DevOps di tutto lo storico delle versioni rilasciate in produzione.

Nello specifico:

• il piano di progetto deve essere condiviso e manutenuto tra l’Aggiudicatario ed ATS attraverso Microsoft Azure DevOps (per esempio attraverso gli strumenti: Backlog per la gestione dei requisiti; Sprint e Delivery Plans per la pianificazione) sulla sottoscrizione di ATS;

• nel proprio piano di qualità l’Aggiudicatario deve garantire l’utilizzo degli strumenti di qualità del software (QA) adottati da ATS (attualmente, almeno SonarQube, WhiteSource, …) tale da consentirgli, preventivamente al rilascio in produzione e dandone evidenza ad ATS, di effettuare l’analisi statica del codice ed il monitoraggio secondo le metriche indicate:

o complessità cognitiva e ciclomatica (minore di 20 per metodo);

o duplicazioni del codice: inferiore al 5%;

o vulnerabilità critiche e bug: assenti;

o violazioni d’uso delle licenze su librerie di terze parti: assenti.

ATS si riserva di valutare preventivamente (quality gate) ogni rilascio software dell’Aggiudicatario e di rigettare quelli che non rispettino i suddetti requisiti standard.

ATS metterà a disposizione dell’Aggiudicatario uno specifico manuale (“A101-MS003 - Istruzioni DevOps per Fornitori”) con indicazioni specifiche riguardanti tutte le attività di integrazione con la piattaforma Microsoft Azure DevOps di ATS. L’Aggiudicatario sarà tenuto ad attenersi a quanto indicato nel suindicato manuale.

5.2 Strumenti di project management ‌

L’Aggiudicatario è tenuto a adottare gli strumenti di project management Azure Boards, nella sottoscrizione Azure DevOps di ATS, per assicurare ad ATS la massima trasparenza e la governance in tutte le fasi del progetto.

A questo proposito è in carico all’Aggiudicatario la corretta e completa esecuzione di tutte le seguenti attività, in linea con la metodologia Agile richiesta da ATS:

• definizione di un adeguato staff di risorse (team di progetto), dando evidenza ad ATS della capacity assegnata al progetto per ogni figura professionale prevista, tale da garantire il completamento del progetto nei tempi contrattualmente previsti;

• creazione e pianificazione di tutti task che garantiscono la copertura di tutti i requisiti funzionali (User Story) previsti nel presente Capitolato Tecnico;

• dall’avvio del progetto fino alla messa in esercizio di tutte le componenti tecniche e funzionali previste (Backlog), gestione giornaliera dell’avanzamento dei task (Task Board) per ogni Sprint o Iterazione della pianificazione condivisa con ATS; il piano operativo previsto dall’Aggiudicatario deve essere necessariamente previsto su Azure Boards avendo cura di pianificare Sprint della durata massima di due-tre settimane.

Le suddette attività dovranno essere previste e garantite anche in fase di manutenzione ordinaria ed evolutiva.

L’Aggiudicatario, nel caso l’ATS ritenga necessario, dovrà essere disponibile a partecipare ad incontri periodici sull’andamento del progetto.

5.3 Formazione ‌

Il servizio deve comprendere la formazione all’utilizzo del sistema dedicato agli utilizzatori finali dell’applicazione, interni ad ATS.

La formazione dovrà consistere in almeno 5 giornate. La formazione potrà essere fruita anche tramite mezze giornate. L’attività d’aula sarà effettuata presso la sede che verrà indicata da ATS. Tale sede si troverà sul territorio di competenza di ATS. Se concordato con ATS, alcune fasi dell’attività di formazione potranno essere effettuate in teleconferenza. La formazione deve essere fruibile anche in modalità asincrona attraverso supporti multimediali.

L’attività formativa dovrà essere pianificata in accordo con ATS in modo da non intralciare, rallentare o impedire la normale operatività degli utenti coinvolti.

L’Aggiudicatario dovrà mettere a disposizione di ATS un'attività di assistenza continuativa nelle fasi di avvio del sistema per tutti gli operatori impegnati sul campo.

A supporto degli utenti del sistema, l’Aggiudicatario dovrà prevedere la produzione, la consegna, il mantenimento di un’adeguata documentazione tecnica ed operativa, in generale di tutto quanto, anche successivamente, si rendesse necessario produrre per documentare modifiche e/o adeguamenti al sistema in esercizio. In particolare, dovranno essere resi messi a disposizione di ATS i seguenti manuali:

• Manuale d’Uso dell’Utente, eventualmente suddiviso in più moduli dedicati alle diverse tipologie di utenti, contenente le informazioni di riferimento necessarie per il corretto uso del sistema in tutti gli scenari di utilizzo previsti.

• Manuale di Amministrazione di Sistema, contenente la descrizione esaustiva di tutte le funzioni specifiche dell’Amministratore di Sistema.

• Documento Tecnico di Dettaglio, contenente tutte le informazioni tecniche di dettaglio relative al sistema, alla propria base dati, ai connettori di integrazione ed alle relative interfacce grafiche e di comunicazione.

• Documenti Tecnici delle integrazioni, contenenti tutte le informazioni tecniche sugli strumenti di integrazione con sistemi che alimentano o sono alimentati dal software convenzioni.

La documentazione tecnica, utente e operativa dovrà essere messa a disposizione anche attraverso un help-on-line (come specificato nel requisito tecnico “USA2 - Interfacce Help-On-Line”), con specifici rimandi dalle varie sezioni.

6 Collaudo e Avviamento ‌

Il sistema oggetto del presente Capitolato Tecnico è vincolato al superamento di una opportuna procedura di collaudo, condivisa con ATS, prima dell’effettiva accettazione del sistema e quindi dell’effettivo rilascio in produzione.

Il collaudo dovrà essere effettuato in un ambiente di test dedicato, messo a disposizione in hosting dall’Aggiudicatario, il più simile possibile, in termini di risorse cloud, a quello di produzione. In collaudo verranno utilizzate postazioni client coerenti con quanto previsto dal contratto di Fornitura.

Si sottolinea che ogni futura modifica, correttiva o evolutiva o migliorativa, da apportare al sistema dovrà essere anch’essa soggetta a collaudo preventivo prima dell’effettivo rilascio in produzione.

Anche nel contesto di erogazione del servizio, ATS richiede che ogni eventuale modifica all’ambiente di utilizzo (software d’ambiente, patch, …) sia soggetta anch’essa a specifiche procedure di verifica da parte dell’Aggiudicatario onde garantire la non regressione delle funzionalità applicative, dandone evidenza ad ATS.

Prima di eventuali sessioni di precollaudo e delle effettive sessioni di collaudo, l’Aggiudicatario è tenuto a presentare un’opportuna documentazione (check list di collaudo) soggetta ad eventuali integrazioni ed alla accettazione finale da parte dei referenti di ATS.

In caso di inadempimenti dell’Aggiudicatario legati al rilascio in produzione di funzionalità o modifiche non condivise o che non abbiano positivamente superato le procedure di collaudo, ATS si riserva la facoltà di valutare l’applicazione di penali secondo quanto previsto dal contratto di Fornitura.

Ad integrazione di quanto indicato, l’Aggiudicatario è tenuto a consegnare ad ATS, preventivamente alle procedure di collaudo, una specifica documentazione (test list e test report funzionali) che dia evidenza dell’adeguata copertura delle funzionalità e del buon esito delle verifiche funzionali effettuate internamente durante lo sviluppo del sistema. Dalle verifiche funzionali previste verranno selezionati gli scenari di collaudo.

Durante il collaudo e/o gli eventuali precollaudi saranno verificate punto per punto tutte le funzionalità indicate nelle procedure stesse (check list collaudo) condivise con ATS. Al termine delle fasi di collaudo sarà redatto un verbale corredato da un opportuno documento (test report di collaudo) attestante l'esito delle verifiche effettuate.

Nel caso in cui una o più specifiche funzionali, non funzionali e tecniche o altri aspetti rilevanti della Fornitura, inclusi nel presente Capitolato Tecnico e/o eventualmente forniti come requisiti migliorativi dall’Aggiudicatario, non superino il collaudo (requisito non implementato o con gravi mancanze), il collaudo terminerà con esito negativo.

Nel caso in cui il collaudo sia superato solo parzialmente, a causa di problemi minori risolvibili in un tempo stimato limitato, il collaudo terminerà con esito di superamento parziale (con riserve). L’Aggiudicatario rilascerà l’elenco dei problemi da risolvere con un piano temporale di risoluzione concordato con ATS. La verifica della risoluzione dei problemi sarà oggetto di una ulteriore sessione di collaudo da parte di ATS.

Al superamento del collaudo, l’effettivo rilascio in produzione avverrà secondo un piano di avviamento che assicuri, al momento dell’apertura del servizio in produzione, la corretta operatività a tutti gli utenti finali del sistema, interni ad ATS.

La messa in esercizio del sistema è quindi vincolata al completamento delle seguenti attività:

• predisposizione dei database interni del sistema (per esempio, import di anagrafiche fornitori,

…) e importazione dei dati documentali preesistenti;

• sessioni di formazione per le diverse tipologie di utenti, secondo un piano condiviso con ATS.

Ai fini del rilascio in produzione, è indispensabile quindi che il sistema abbia superato il collaudo funzionale e disponga di tutti i dati che ne consentano la corretta ed efficace operatività.

Una volta rilasciato il sistema in esercizio, ATS si riserva la facoltà di monitorare il corretto andamento del funzionamento del sistema in produzione per un per periodo di due mesi (fase di avvio) per valutare l’affidabilità e la maturità del software rilasciato dall’Aggiudicatario.

7 Servizi di assistenza e manutenzione ‌

L’Aggiudicatario è tenuto a garantire, per tutta la durata del periodo contrattuale, la manutenzione (correttiva, preventiva programmata, normativa, evolutiva) e l’assistenza all’utilizzo del sistema informativo in esercizio in modo tale da assicurare la continuità operativa del nuovo applicativo e delle integrazioni del sistema stesso con gli applicativi esterni coinvolti.

7.1 Manutenzione correttiva, preventiva programmata ed assistenza ‌

Il servizio di manutenzione correttiva e preventiva programmata deve includere:

• interventi periodici da parte dell’Aggiudicatario finalizzati alla verifica del sistema sia dal punto di vista funzionale che prestazionale, in funzione dei livelli transazionali e di carico del sistema in esercizio; le metriche relative all’utilizzo delle risorse riguardano i seguenti indicatori che dovranno essere monitorati attraverso strumenti dedicati:

o errori;

o saturazione delle risorse;

o latenze nei tempi di risposta;

• la correzione dei difetti emersi a seguito di malfunzionamenti rilevati durante l'esercizio o individuati anche autonomamente dall’Aggiudicatario, anche durante le attività di manutenzione programmata; le anomalie dovranno essere segnalate e gestite anche attraverso Azure DevOps.

Le attività di individuazione e correzione di eventuali anomalie dovranno essere estese anche alle successive modifiche correttive, normative ed evolutive che si rendessero necessarie per tutta la durata contrattuale, in modo tale da escludere potenziali regressioni, funzionali e non, che possano impattare le funzionalità e le performance del sistema in esercizio. La manutenzione correttiva e l’assistenza tecnica si applicano negli stessi termini anche alle integrazioni con gli altri sistemi del medesimo perimetro operativo.

Tutte le attività suddette dovranno essere preventivamente programmate, condivise / concordate con ATS ed opportunamente pianificate e gestite in modo coordinato secondo le regole definite nel capitolo relativo ai collaudi, al fine di minimizzare i disagi alle attività operative e causare blocchi temporanei del servizio, nel rispetto dei vincoli organizzativi e infrastrutturali di ATS. L’Aggiudicatario è tenuto a dare evidenza ad ATS, attraverso il buon esito delle procedure di collaudo, di ogni modifica correttiva apportata al sistema. Si ribadisce che le procedure di collaudo dovranno essere sempre preventivamente condivise e approvate da ATS.

Il servizio di assistenza includerà:

• un servizio di help desk di secondo livello attivabile direttamente dall’Ufficio preposto di ATS o attraverso i servizi di help desk di primo livello di ATS. Il servizio potrà essere richiesto sia a seguito di malfunzionamenti e/o disservizi sia per richiesta di supporto all'operatività ordinaria. Tutte le attività di help desk di secondo livello hanno carattere esclusivamente informatico.

• Il servizio di help desk dovrà essere garantito nei giorni feriali da lunedì a venerdì, dalle ore 09:00 alle 18:00, secondo quanto specificato nel capitolo “Livelli di servizio minimi richiesti e criteri di misura”. Quanto indicato costituisce pertanto la definizione di “giornata lavorativa” nel contesto della presente fornitura.

L’Aggiudicatario è tenuto a fornire ad ATS idonee e chiare istruzioni operative per l’interazione con il servizio di help desk: gli interventi di assistenza potranno effettuarsi sia in loco che a distanza, anche in teleassistenza.

L’Aggiudicatario dovrà impegnarsi, nel caso di attivazione del servizio di secondo livello, a dare riscontro ad ATS di tutte le fasi di gestione di una richiesta di assistenza (presa in carico, risoluzione, chiusura), garantendo un sistema di gestione dei ticket. A seguito della ricezione del ticket, L’Aggiudicatario è tenuto ad inserire nella piattaforma Azure DevOps di ATS il relativo work item per approfondimenti. Tutti gli interventi di tipo sistemistico conseguenti alle attività sopra indicate dovranno essere preventivamente pianificati e concordati con ATS.

Il servizio di manutenzione correttiva, preventiva programmata e assistenza dovrà comprendere:

• la mano d’opera (illimitata);

• l'assistenza telefonica (illimitata);

• la teleassistenza (illimitata);

• eventuali costi di trasferta del personale dell’Aggiudicatario o di suo consulente di cui vorrà avvalersi.

L’Aggiudicatario è tenuto a produrre, almeno trimestralmente, specifica reportistica relativa alle attività di assistenza svolte nel rispetto degli SLA contrattuali.

7.2 Manutenzione normativa ‌

Il servizio di manutenzione normativa ha come obiettivo quello di assicurare l’eventuale aggiornamento delle funzionalità erogate dal sistema in relazione a variazioni delle normative regionali o nazionali.

La manutenzione normativa include in particolare ogni adeguamento legato ai temi di Privacy e di sicurezza informatica, nel rispetto delle normative e delle disposizioni europee, nazionali e regionali.

Tali interventi potranno essere richiesti da ATS per tutta la durata del periodo contrattuale e dovranno essere garantiti dall’Aggiudicatario nei tempi utili all’entrata in vigore delle modifiche normative.

Il processo di manutenzione normativa si articola nelle seguenti attività:

1. invio da parte di ATS della richiesta di intervento di adeguamento normativo per le variazioni normative regionali e nazionali;

2. analisi della variazione normativa: tale attività implicherà il coinvolgimento di ATS e dell’Aggiudicatario;

3. redazione da parte dell’Aggiudicatario di un documento tecnico di dettaglio contenente l’analisi dell’intervento concordato ed una valutazione dell’impegno richiesto utilizzando la metrica dei Function Point (FP);

4. valutazione indipendente di ATS, in base alla documentazione prodotta, della congruità dell’impegno richiesto, con richiesta di eventuali approfondimenti all’Aggiudicatario; in caso di discordanza sulle stime, ATS si riserva la facoltà di rivolgersi ad un soggetto terzo per una valutazione indipendente; si considerano inclusi nella manutenzione normativa gli interventi per i quali l’adeguamento delle funzionalità esistenti o l’applicazione di nuove configurazioni richiede un impegno dell’Aggiudicatario non superiore alle 10 giornate/uomo; oltre tale soglia gli interventi saranno ambito della manutenzione evolutiva;

5. finalizzazione della stima economica da parte dell’Aggiudicatario, tenendo conto di eventuali economie di scala e dei fattori di produttività;

6. accettazione da parte di ATS della stima economica o ridiscussione della medesima;

7. pianificazione dell’intervento di adeguamento normativo in accordo con ATS;

8. sviluppo, collaudo e rilascio in produzione dell’adeguamento normativo;

9. aggiornamento della documentazione, tecnica e di esercizio, da parte dell’Aggiudicatario ed eventuale formazione dell’utenza.

7.3 Manutenzione evolutiva ‌

Non essendo identificabili a priori gli interventi evolutivi determinati da necessità non comprese nelle specifiche iniziali di capitolato, la realizzazione di tali attività presuppone la preventiva analisi dei bisogni, la quotazione delle attività, la pianificazione degli interventi, la realizzazione ed il relativo collaudo. Tutte le fasi del processo sopra descritto sono da concordarsi con ATS.

Per lo svolgimento di tali attività, ATS richiede all’Aggiudicatario di quotare all’interno della presente fornitura, un “pacchetto” di giornate/uomo, da utilizzarsi “a consumo” ovvero l’utilizzo di giornate o anche di mezze giornate di attività per lo sviluppo di tali interventi evolutivi.

Il pacchetto di giornate-uomo richiesto è stimato fino ad un massimo di 90 giornate/uomo o anche in 180 mezze giornate/uomo da erogarsi a consumo per tutta la durata contrattuale. Tali giornate potranno anche essere utilizzate solo in parte da ATS; in tal caso ATS corrisponderà all’Aggiudicatario solo il costo delle giornate/mezze giornate effettivamente erogate e preventivamente concordate con ATS sulla base di un documento tecnico, redatto dall’Aggiudicatario, che dia evidenza delle attività effettivamente previste.

Il valore del “pacchetto” deve comprendere:

• le attività di analisi, progettazione e sviluppo degli adeguamenti richiesti con la fornitura delle professionalità necessarie;

• la documentazione tecnica e operativa, la documentazione in linea del sistema, eventualmente attraverso l’integrazione della documentazione già rilasciata dall’Aggiudicatario (compresi i contenuti di help-on-line);

• gli eventuali costi di trasferta del personale dell’Aggiudicatario, da garantire solo in caso di esplicita richiesta da parte di ATS.

L’implementazione delle modifiche richieste dovrà essere validata sulla base di specifiche di collaudo concordate con ATS. Si ribadisce che ogni intervento evolutivo dovrà essere sempre preventivamente approvato da ATS sulla base di un documento tecnico di dettaglio dell’Aggiudicatario, comprendente la valutazione dell’impegno richiesto secondo la metrica dei Function Point (FP). In base alla documentazione prodotta, ATS effettuerà una valutazione indipendente dell’impegno richiesto per confermare l’adeguatezza dell’offerta economica dell’Aggiudicatario. In caso di discordanza sulle stime, ATS si riserva la facoltà di rivolgersi ad un ente/soggetto terzo per una valutazione indipendente.

L’Aggiudicatario è tenuto ad allineare tutta la documentazione tecnica ed operativa del sistema.

A seguito del rilascio in produzione, ogni modifica evolutiva o nuova funzionalità diventa parte integrante del sistema stesso e comporta quanto definito nelle restanti parti del Capitolato Tecnico.

Per ogni evolutiva rilasciata in esercizio, ATS si riserva la facoltà di monitorare il corretto andamento del funzionamento del sistema in produzione per un per periodo di due mesi (fase di avvio) per

valutare l’affidabilità e la maturità delle evolutive rilasciate ed in particolare l’assenza di regressioni sulle funzionalità del sistema.

8 Durata del contratto e modalità di conclusione ‌

La durata nominale del contratto previsto dalla presente fornitura è di 60 mesi a partire dalla data di sottoscrizione del contratto.

L’Aggiudicatario è tenuto a consegnare la soluzione completa di tutte le parti specificate nel presente Capitolato Tecnico entro un massimo di 180 giorni solari dalla data di sottoscrizione del contratto. La non osservanza di tale pianificazione da parte dell’Aggiudicatario è soggetta all’applicazione di penali e può determinare l’eventuale risoluzione del contratto.

Le attività di collaudo, formazione ed avviamento del sistema in produzione dovranno completarsi entro un periodo di 20 giorni solari dal termine delle attività di sviluppo del sistema e comunque entro e non oltre 180 giorni solari dalla sottoscrizione del contratto.

In esito al collaudo positivo, decorrerà il servizio di assistenza e manutenzione (in questo secondo caso, trascorso il previsto periodo di garanzia contrattuale) che l'Aggiudicatario dovrà garantire sino alla scadenza naturale del contratto. La durata del servizio di assistenza è di 42 mesi e/o comunque fino alla decorrenza dei 60 mesi del contratto, a partire dalla data di avvio del sistema in produzione.

Il servizio di manutenzione correttiva comprende un periodo di garanzia di 12 mesi a partire dalla data di avvio del sistema in produzione; il servizio di manutenzione correttiva proseguirà, dopo il periodo di garanzia, fino alla decorrenza dei rimanenti 42 mesi del contratto.

Alla conclusione naturale del contratto l’Aggiudicatario è tenuto a garantire ad ATS un adeguato passaggio di consegne al fornitore subentrante. Le stesse modalità dovranno essere assicurate dall’Aggiudicatario in caso di eventuale conclusione anticipata della fornitura. Si sottolinea che l’affiancamento dell’Aggiudicatario al fornitore subentrante deve riguardare in particolare il trasferimento della base dati nel futuro ambiente operativo in modo da rendere più efficace l’avvio del nuovo servizio di fornitura; per lo svolgimento di queste attività l’Aggiudicatario non potrà imputare alcun costo ad ATS in quanto già dovuti e ricompresi nel presente contratto.

In linea con la normativa vigente, con particolare riferimento alle circolari AgID n. 2 e n. 3 del 9 aprile 2018 e relativi allegati (fare riferimento al capitolo “Riferimenti documentali e normativi” del presente documento), l’Aggiudicatario deve consentire la migrazione del servizio verso un altro gestore, con conseguente eliminazione permanente dei dati ATS dai propri archivi al termine del contratto.

9 SLA richiesti e criteri di misura ‌

La gestione della prevista fornitura, dei servizi realizzativi, della manutenzione correttiva, preventiva programmata e del servizio di assistenza è disciplinata all’interno nel documento “Capitolato Speciale di Appalto” in cui vengono illustrati gli indicatori di qualità e gli SLA della fornitura stessa

come parte integrante del presente Capitolato Tecnico: occorre fare pertanto riferimento a tale documento per la descrizione esaustiva degli obiettivi e delle azioni contrattuali previsti.

Dato il rilevante impatto che tale applicativo ha sull’operatività di ATS, un importante elemento di valutazione è la qualità del servizio offerto agli utenti del sistema, in tutti gli scenari di riferimento, misurata attraverso la rispondenza a specifici indicatori di qualità e relativi SLA riguardanti anche i tempi di risoluzione di eventuali problematiche o anomalie o difetti che dovessero emergere e verificarsi in esercizio.

L’Aggiudicatario è tenuto a garantire il servizio di manutenzione ed assistenza secondo la seguente copertura oraria:

Giorno	Copertura
Lunedì	dalle 9:00 alle 18:00
Martedì	dalle 9:00 alle 18:00
Mercoledì	dalle 9:00 alle 18:00
Giovedì	dalle 9:00 alle 18:00
Venerdì	dalle 9:00 alle 18:00

Negli stessi orari devono essere garantiti i seguenti servizi:

• help desk;

• raccolta, registrazione e instradamento delle richieste di intervento in caso di guasto;

• verifica dell’esecuzione dell’intervento riparatore e registrazione della conclusione del ticket.

Il sistema di tracciatura utilizzato dall’Aggiudicatario deve permettere ad ATS la ricezione di notifiche o comunicazioni relative ad ogni cambio di stato delle segnalazioni effettuate fino alla chiusura dei ticket da parte dei gruppi tecnici preposti.

10 Requisiti infrastrutturali ‌

Nell’ambito del progetto di Agid per la razionalizzazione dei data center delle P.A., ARIA è stata accreditata come Polo Strategico Nazionale (PSN).

Come definito nel paragrafo 2.4, per la soluzione scelta, ATS si avvarrà dei servizi infrastrutturali erogati da ARIA,

Per le specifiche tecniche relative all’infrastruttura prevista per l’erogazione della soluzione si rimanda all’ Allegato Tecnico – Requisiti Infrastrutturali – ver.1.0.

11 Riferimenti documentali e normativi ‌

Accessibilità

Il sistema dovrà rispondere ai requisiti tecnici di accessibilità definiti nei seguenti atti normativi e di indirizzo:

• Linee Guida AgID per l’Accessibilità degli strumenti informatici.

• Legge 4 del 9 gennaio 2004, (Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici) e successivo D.M. 8 luglio 2005 (Regolamento di attuazione della Legge 4 del 9 gennaio 2004, per favorire l’accesso dei soggetti disabili agli strumenti informatici) aggiornato con

D.M. del 20 marzo 2013.

• Decreto Legislativo 82/2005 (Codice dell'Amministrazione Digitale);

• Decreto del Presidente della Repubblica 75/2005 Regolamento di attuazione della Legge 4/2004, per favorire l'accesso dei soggetti disabili agli strumenti informatici.

• Decreto del Ministro per l'Innovazione e le Tecnologie 8 luglio 2005 recante "Requisiti tecnici e diversi livelli per l’accessibilità agli strumenti informatici".

• Direttiva 27 luglio 2005 della Presidenza del Consiglio dei ministri - Dipartimento per l’Innovazione e le Tecnologie Qualità dei servizi Online e misurazione della soddisfazione degli utenti.

• Direttiva n. 8/2009 - Ministro per la pubblica amministrazione e l'innovazione relativa alla riduzione dei siti web delle P.A. e per il miglioramento della qualità dei servizi e delle informazioni on line al cittadino.

• Linee Guida per i siti web delle P.A. (previste dalla Direttiva

n. 8/09 - Ministro per la pubblica amministrazione e l'innovazione).

• Decreto Legislativo 33/2013 Riordino della disciplina riguardante gli obblighi di pubblicità, trasparenza e diffusione di informazioni da parte delle pubbliche amministrazioni (pubblicato sulla Gazzetta Ufficiale della Repubblica Italiana

n. 80 del 5 aprile 2013) e s.m.i.

• Decreto Legislativo recante revisione e semplificazione delle disposizioni in materia di prevenzione della corruzione pubblicità e trasparenza, correttivo della Legge 6 novembre 2012, n. 190 e del decreto legislativo 14 marzo 2013, n. 33, ai sensi dell'articolo 7 della legge 7 agosto 2015, n. 124, in

materia di riorganizzazione delle amministrazioni pubbliche.

	• Circolare n. 61/2013 del 29 marzo 2013 dell'Agenzia per l'Italia Digitale in materia di accessibilità dei siti web delle pubbliche amministrazioni.
Usabilità	Il sistema dovrà rispettare gli standard minimi di usabilità del web: • Normativa ISO 9241 • Circolare n. 61/2013 ex-D-Lgs. 179/2012 • Linee Guida AgID di design per i servizi web della PA
Privacy e Security	GDPR (General Data Protection Regulation), Regolamento UE 2016/679. D. Lgs. 101/2018 (“Disposizioni per l’adeguamento della normativa nazionale alle disposizioni del regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati”). D. Lgs. 196/2003 (“Codice in materia di protezione dei dati personali”). Misure di sicurezza e modalità di scambio dei dati personali tra amministrazioni pubbliche - 2 luglio 2015. Linee guida AgID in merito alle misure minime di sicurezza ICT per la PA (Circolare n. 1 del 17/3/2017 pubblicata in GU del 4/4/2017). Misure Minime di Sicurezza AgID (circolare n. 2 del 18/4/2017). Fare riferimento a best practices e standard proposti nell’ambito del progetto OWASP e consultabili al seguente link: xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxx_Xxxx
Grafica	Il sistema dovrà rispettare i seguenti standard (e successive evoluzioni) e requisiti: • normativa ISO/IEC 15445:2000(E) (HTML). • normativa ISO/IEC 16262:2002 (ecma-script), nota anche come standard ECMA 262. • Recommendation del W3C relative al linguaggio HTML nella versione 4.01 e successive e al linguaggio XHTML nella versione 1.0 e successive. • Recommendation del W3C relative al linguaggio CSS nella versione 1.0 e successive. • Recommendation del W3C relative a linguaggi e a specifiche tecniche relative alla realizzazione di pagine, oggetti e applicazioni web, quali, ad esempio, HTTP, URI, URL, HTML, XHTML, XML, SVG, SMIL, SOAP. • compatibilità con i seguenti standard di gestione dei contenuti: o JSR 168 (specifica dei “Portlet”); o JSR 170 (API standard per accedere ai servizi di un sistema di Gestione Contenuti Web);

	o WSRP 1.0 (Web Services for Remote Portlet per la definizione del protocollo standard di dialogo fra il portale e i Portlet); • compatibilità con i seguenti standard relativi ai formati di descrizione dei contenuti: o XML (Extensible Markup Language, vedi xxxx://xxx.x0.xxx/XXX/); o PRISM (Publishing Requirements for Industry Standard Metadata, xxxx://xxx.xxxxxxxxxxxxx.xxx/); o Dublin Core Metadata Initiative (basato su ISO/IEC 11179, xxxx://xxxxxxxxxx.xxx/); o XMP (Extensible Metadata Platform, creato da Adobe).
Data Center e cloud	Indicazioni di AgID: Piano triennale per l’informatica nella Pubblica Amministrazione – 2020-2022. Circolare n. 5 del 30 novembre 2017 relativa agli obiettivi e alle linee guida per la PA rispetto al risparmio di spesa ICT e al consolidamento dei data center. Circolare AgID n. 2 del 9 aprile 2018, “Criteri per la qualificazione dei Cloud Service Provider per la PA”.
Linee Guida AgID	Linee Guida su acquisizione e riuso di software per le Pubbliche Amministrazioni. 2019. Allegato A delle suddette linee guida: Guida alla pubblicazione di software come open source. Linee Guida AGID per i servizi digitali delle PA, testo consultabile al seguente link: xxxxx://xxxx.xxxxxx.xx/xxxxxx/xxxxxxxxx-xxxxxx/xxxxxx-xxxxx- guida-docs/it/stabile/index.html Linee Guida AgID di design per i servizi web della PA.
Microsoft Azure DevOps	Fare riferimento alla documentazione ufficiale Microsoft reperibile a partire dal seguente link: xxxxx://xxxx.xxxxxxxxx.xxx/xx-xx/xxxxx
Proprietà intellettuale	L. 633/41 (“Protezione del diritto d'autore e di altri diritti connessi al suo esercizio”).

Document Metadata

Table of Contents

Capitolato Tecnico

Document Metadata