CAPITOLATO SPECIALE D’ONERI

- Specifiche Tecniche: insieme delle caratteristiche/disposizioni che definiscono le esigenze tecniche che l’Impresa Aggiudicataria deve soddisfare per lo svolgimento delle attività richieste dalla Stazione appaltante.

- Codice degli Appalti o Codice: il D. Lgs. 18 aprile 2016, n. 50 (Codice dei contratti pubblici) e successive modifiche e integrazioni;

- API (Application Programming Interfaces): insieme di risorse, procedure e funzionalità raggiungibili pubblicamente tramite indirizzi Web che permettono l’interazione fra prodotti software di terze parti e lo sviluppo di nuove funzionalità, basandosi su protocolli e standard aperti come XML e JSON;

- Catalogo / OPAC: interfaccia di interrogazione delle risorse locali che permette all’utente di individuare se e quali biblioteche possiedano il documento desiderato per poterlo consultare o prendere in prestito;

- Cloud computing: insieme di tecnologie che consentono, tramite Internet, di accedere ad applicazioni e dati ospitati su hardware remoto;

- Discovery Tool: strumento che consente di accedere, tramite una singola ricerca, a tutte le risorse bibliografiche dell’Ateneo (libri, articoli e periodici sia in formato cartaceo che elettronico), oltre a quelle disponibili in linea ad accesso aperto;

- Document Delivery / DD: servizio di fornitura documenti in copia fra una biblioteca del Politecnico di Torino ed una biblioteca esterna all’Ateneo, su richiesta degli utenti. Il servizio può prevedere un pagamento o un rimborso spese;

- ERMS: (Electronic Resource Management System): software che consente la gestione centralizzata di tutte le fasi del ciclo di vita delle risorse elettroniche, indipendentemente dalla granularità (risorse singole o pacchetti) e dalle modalità di acquisizione (acquisto, sottoscrizione, open access);

- ILS (Integrated Library System): software per la gestione automatizzata della biblioteca, generalmente composto da più moduli, corrispondenti alle diverse funzioni di gestione amministrativa, catalografica e di erogazione dei servizi all’utenza;

- Interfaccia Utente Unificata / IUU: interfaccia di interrogazione e di recupero dell’informazione che si pone come punto di accesso unificato per tutte le risorse a disposizione della biblioteca, sia analogiche che elettroniche e come punto di accesso online ai servizi a disposizione dell’utenza;

- Knowledge Base: base di dati in cui sono contenuti record descrittivi di risorse elettroniche, eventualmente comprensivi di abstract, relativi metadati, servizi per il loro utilizzo e altre informazioni, raccolti tramite harvesting fra quelli messi a disposizione da editori e/o aggregatori;

- Library Service Platform (LSP): piattaforma che unisce le funzionalità di un ILS e quelle di un ERMS pienamente integrati con l’Interfaccia Utente così da garantire un rapido ed efficiente flusso dei dati e un’efficace erogazione dei servizi, interamente basato su architettura web service;

- Modello SaaS (Software-as-a-Service): modello di distribuzione del software applicativo in cui il produttore del software sviluppa, opera (direttamente o tramite terzi) e gestisce un’applicazione web, che mette a disposizione dei clienti via Internet su abbonamento. Si tratta di solito di un servizio di cloud computing;

- NILDE (Network for InterLibrary Document Exchange) Servizio basato sul web offerto dal CNR di Bologna per supportare il DD e il prestito interbibliotecario a tutte le biblioteche aderenti.

- Prestito Interbibliotecario /ILL: servizio di fornitura documenti in originale fra una biblioteca del Politecnico di Torino ed una biblioteca esterna all’Ateneo, su richiesta degli utenti. Il servizio può prevedere il pagamento di un contributo come rimborso spese;

- Prestito locale: servizio che consente all’utente registrato presso le biblioteche del Politecnico di Torino di ottenere in consegna, per un periodo di tempo predeterminato, uno o più documenti posseduti dalla stessa biblioteca a cui rivolge la richiesta;

- Risorse analogiche: nel presente Capitolato per Risorse analogiche si intendono tutte le risorse bibliografiche cartacee o comunque disponibili su supporto fisico. A titolo esemplificativo e non esaustivo: monografie e periodici a stampa, spartiti musicali, carte geografiche, videocassette (VHS), CD-ROM, DVD, ecc.;

- Risorse elettroniche: nel presente capitolato per Risorse elettroniche si intendono tutte le risorse bibliografiche accessibili online. A titolo esemplificativo e non esaustivo: e-book, periodici elettronici, banche dati bibliografiche e fattuali, siti web, ecc.;

- RPO (Recovery Point Objective): massima finestra temporale entro cui è ammissibile la perdita dei dati in caso di disastro;

- RTO (Recovery Time Objective): massima interruzione del servizio ammissibile o tollerabile

- ICCU Istituto Centrale per il Catalogo Unico

- SBN (Servizio Bibliotecario Nazionale): rete delle biblioteche italiane, articolata in Poli locali

collegati all’indice SBN, gestito dall’ICCU, il cui posseduto confluisce nel catalogo collettivo;

- Sistema Informativo gestionale: si intende l’insieme costituito dai gestionali di back office (ILS

ed ERMS) e dell’interfaccia Utente Unificata;

- Team di progetto del Committente: gruppo di operatori (archivisti, bibliotecari, informatici e tecnici) individuati dal Committente che coadiuva il Direttore dell’Esecuzione del Contratto (DEC) nelle fasi esecutive dell’Appalto, collabora alla migrazione, effettua i test, verifica il buon funzionamento della Piattaforma, segnala malfunzionamenti;

- Sistema Informativo gestionale: si intende l’insieme costituito dai gestionali di back office (ILS

ed ERMS) e dell’interfaccia Utente Unificata;

- Team di progetto del Committente: gruppo di dipendenti dell’Ateneo, incaricato di partecipare alle fasi esecutive dell’Appalto, collaborare alla migrazione, effettuare test e verificare il buon funzionamento della piattaforma.

- Primo: Discovery tool sviluppato da Exlibris che permette la ricerca integrata sulle risorse

cartacee ed elettroniche possedute dall’Ente appaltante.

- SLA: Service Level Agreement

1. PREMESSE

Il Politecnico di Torino intende individuare un Operatore Economico cui affidare la fornitura di una piattaforma informativo - gestionale per le biblioteche di Ateneo - utilizzabile in cloud secondo il modello “Software-as-a-Service” (SaaS) - di un database di test popolato con dati reali e relativi servizi di manutenzione ordinaria ed evolutiva, supporto specialistico, assistenza e supporto al cliente, nel rispetto di quanto previsto dal presente Capitolato Tecnico.

Il Sistema Bibliotecario del Politecnico di Torino:

• coordina le attività di acquisizione, gestione, uso e conservazione dei patrimoni librari e

documentali dell’Ateneo e delle risorse bibliografiche in formato tradizionale ed elettronico;

• coordina le attività volte all’adeguamento delle risorse bibliografiche alle necessità didattiche,

scientifiche e culturali dell’Ateneo;

• provvede a garantire il più ampio accesso all’informazione scientifica a supporto dell’attività di didattica, ricerca e terza missione dell’Ateneo grazie ad un’efficace organizzazione e gestione delle risorse bibliografiche, sia in formato elettronico che cartaceo.

Il software gestionale per le biblioteche attualmente in uso è “Aleph500”, basato su un’architettura

client server, installato localmente, che necessita di periodici upgrade di versione. L’attuale gestione delle risorse bibliografiche e documentarie segue due canali separati:

1. il patrimonio cartaceo e in generale su supporto fisico (risorse analogiche) viene gestito utilizzando un ILS (Integrated Library System) che permette di effettuare tutte le procedure

amministrative (acquisizione, inventariazione, ecc.), l’attività di catalogazione/gestione copie e

di gestione dei servizi agli utenti (anagrafica, circolazione, prenotazione).

I dati relativi alle risorse analogiche attualmente gestite nell’ILS sono i seguenti:

- numero di biblioteche: 19

- numero totale di record bibliografici: oltre 360.000 di cui:

• monografie: 285.000

• periodici a stampa: 7300

• tesi: 61.000

- Utenti inseriti in anagrafica: 45.000

- Utenti staff: 45

- Transazioni di prestito annuali (prestiti, rinnovi e restituzioni): 92.000.

2. Le risorse elettroniche vengono gestite per le funzioni amministrative e catalografiche con applicativi diversi integrati fra di loro in parte in modo automatico e in parte ad opera del personale bibliotecario.

I dati relativi alle risorse elettroniche sono i seguenti:

- numero periodici elettronici: 64.000

- numero e-book: 125.000

- numero banche dati: 30

L’accesso alle collezioni ed ai servizi per gli utenti finali è fornito da un discovery tool (“Primo”) e da un link resolver (“SFX”) che permettono l’interrogazione di tutte le risorse (cartacee ed elettroniche). Non è possibile una gestione integrata delle risorse cartacee ed elettroniche e digitali dal punto di vista catalografico, amministrativo e dei servizi agli utenti.

2. FINALITÀ DELL’APPALTO

L’appalto ha come obiettivo il raggiungimento delle seguenti finalità:

• aumentare l’efficienza del lavoro dei bibliotecari nella gestione del back office, grazie all’integrazione dei sistemi di gestione e dei processi amministrativi e catalografici di tutte le risorse, sia cartacee che elettroniche;

• razionalizzare, tramite una gestione unificata di tutte le risorse bibliografiche, indipendentemente dal formato o collocazione, i flussi di lavoro eliminando la duplicazione di attività e di dati;

• potenziare l’esperienza degli utenti finali tramite l’offerta di un punto di accesso unico e potenziato all’intero patrimonio bibliografico di Ateneo ed ai servizi, favorendo la valorizzazione ed il pieno utilizzo delle risorse elettroniche, la cui importanza è crescente sia nello sviluppo delle raccolte sia negli investimenti;

• mettere in evidenza la ricchezza e l’articolazione dell’offerta bibliografica di Ateneo;

• permettere il dialogo con il sistema SBN (Servizio Bibliotecario Nazionale) per una cooperazione con le realtà bibliotecarie cittadine e nazionali;

• contenere gli oneri gestionali relativi all’hardware ed alle attività tecniche correlate al mantenimento delle installazioni locali degli applicativi;

• disporre di un servizio SaaS funzionante H24 con adeguato supporto tecnico.

3. OGGETTO DELL’APPALTO

Il presente Appalto ha ad oggetto:

1. La messa a disposizione di una Piattaforma informativo gestionale per le biblioteche del Politecnico di Torino, utilizzabile in cloud secondo il modello SaaS (Software-as-a-Service) che permetta di:

• supportare le attività di back office utilizzando un’unica Library Services Platform che integri le funzioni di un ILS ed un ERMS e permetta di gestire le procedure amministrative, di catalogazione, gestione dei periodici cartacei, gestione delle risorse elettroniche, ricerca, circolazione, statistiche, ecc. come meglio specificato nella Sez. II – Specifiche Tecniche del presente atto;

• offrire una perfetta interoperabilità con il Discovery Tool già in uso (“Primo”) per garantire all’utente finale un’interfaccia unica tramite la quale interrogare tutte le risorse possedute, senza distinzione di formato, avendo a disposizione più modalità di ricerca e la possibilità di richiedere on-line molteplici servizi, come meglio specificato nella Sez. II – Specifiche Tecniche del presente atto;

• assicurare una disponibilità del servizio h 24.

2. La fornitura dei seguenti servizi:

• migrazione dei dati dai sistemi attualmente in uso (Aleph 500 – ver. 22, SFX);

• configurazione e l’avvio della nuova Piattaforma;

• formazione degli Amministratori (informatici e bibliotecari) del sistema;

• formazione degli operatori delle biblioteche d’Ateneo;

• erogazione dei servizi di manutenzione ordinaria ed evolutiva;

• supporto specialistico;

• assistenza e supporto al cliente;

• messa a disposizione di un database di test popolato con dati reali.

In relazione al precedente punto 1, si precisa che il servizio SaaS e la sua documentazione restano di proprietà del Fornitore, senza alcun trasferimento di diritti di proprietà intellettuale. I dati di terzi accessibili attraverso il servizio SaaS restano di esclusiva proprietà della Stazione Appaltante nella loro interezza, così come tutti i dati che ad essa afferiscono (ad esempio, i dati personali dei dipendenti o degli studenti del Politecnico di Torino, i dati dei prestiti, ecc.).

4. DURATA CONTRATTUALE

Il contratto ha la durata di tre anni decorrenti dalla sua sottoscrizione o, nel caso di avvio anticipato, dalla data del relativo verbale. Entro un congruo termine dalla scadenza del Contratto, verificata la qualità dei servizi resi ed accertate le ragioni di convenienza, il Politecnico di Torino potrà procedere al rinnovo del contratto, per ulteriori tre anni.

5. AMMONTARE DELL’APPALTO

Ai sensi e per gli effetti dell’art. 35 D.lgs. 50/2016 e ss.mm.ii, e ai soli fini dell’individuazione della disciplina applicabile in materia di appalti di servizi, il valore complessivo dell’affidamento (oltre IVA), è stato stimato in € € 745.000,00 come da Tabella I sottostante:

	Descrizione	Importo triennale a base di gara (IVA esclusa)	Importo contrattuale (IVA esclusa)
I TRIENNIO
Base di gara soggetta a ribasso	importo una tantum relativo alle attività di implementazione della Piattaforma, migrazione dei dati, formazione degli operatori	€ 85.000,00 una tantum
Base di gara soggetta a ribasso	canone relativo all’accesso alla Piattaforma, la messa a disposizione di un ambiente di test e dei servizi di manutenzione della Piattaforma ed assistenza al cliente per gli anni contrattuali	€ 330.000,00
Importo complessivo a Base di gara soggetto a ribasso		€ 415.000,00	€ 415.000,00 al netto del ribasso offerto
II TRIENNIO (eventuale)
Opzione Rinnovo	canone offerto per l’accesso alla Piattaforma, la messa a	€ 330.000,00	€ 330.000,00

per ulteriori tre anni

disposizione di un ambiente di test e dei servizi di manutenzione della Piattaforma ed assistenza

al cliente per gli anni contrattuali

al netto del ribasso offerto

Valore complessivo

€ 745.000,00

al netto del ribasso offerto

Considerata la natura dell’oggetto dell’affidamento non sono previsti costi per la sicurezza dovuti a rischi interferenziali.

L’importo di aggiudicazione resta fisso e invariato per l’intera durata contrattuale.

6. FASI DI ESECUZIONE DEL CONTRATTO

L’esecuzione del contratto dovrà articolarsi in più fasi e precisamente:

• Fase 1: attività preliminari alla migrazione (analisi dei dati di partenza, impostazione delle configurazioni, formazione degli amministratori del sistema, definizione dei formati di migrazione dei dati in accordo con il committente, ecc.);

• Fase 2: migrazione di prova e test, formazione degli operatori delle biblioteche;

• Fase 3: migrazione definitiva e sua valutazione con go live della Piattaforma;

• Fase 4: verifica di conformità ed emissione del certificato di regolare esecuzione;

• Fase 5: gestione della Piattaforma a regime.

Le tempistiche delle prime 4 fasi dovranno essere specificate dal Concorrente nell’Offerta Tecnica presentata in sede di partecipazione alla procedura. La pianificazione di dettaglio verrà condivisa con la Stazione Appaltante a seguito dell’aggiudicazione.

7. PRESTAZIONI OBBLIGATORIE

L’Affidatario, oltre alle funzionalità indicate nelle Sez. II - Specifiche tecniche del presente Atto dovrà inoltre garantire, a pena di esclusione, le seguenti prestazioni:

⮚ la migrazione;

⮚ la gestione dell’infrastruttura tecnologica;

⮚ la sicurezza dei dati;

⮚ il trattamento dei dati personali.

Le modalità di assolvimento a tali prestazioni obbligatorie dovranno essere descritte nell’Offerta

Tecnica e saranno oggetto di valutazione ai fini dell’ammissibilità dell’offerta.

7.1 Migrazione dei dati dal sistema precedente

Prima di avviare a regime la nuova Piattaforma, l’Affidatario dovrà procedere alla completa

migrazione dei dati presenti nel vecchio sistema verso quello nuovo.

Nell’Offerta Tecnica l’Affidatario dovrà presentare un Piano per la gestione della migrazione dei dati. Il Piano dovrà prevedere in dettaglio attività, strumenti, procedure e la loro distribuzione nelle fasi di esecuzione del contratto (v. precedente punto 6) e dovrà essere corredato di una proposta di cronoprogramma particolareggiato.

Tale migrazione, che ricomprende le fasi 1, 2 e 3 del contratto, dovrà avvenire secondo il percorso sotto indicato:

1. attività preliminari alla migrazione (analisi dei dati di partenza, impostazione delle configurazioni, formazione degli amministratori del sistema, ecc.) FASE 1 dell’esecuzione del contratto;

2. migrazione di prova e test, formazione degli operatori delle biblioteche FASE 2

dell’esecuzione del contratto;

3. correzione di criticità ed eventuale nuova migrazione e test;

4. migrazione definitiva ed entrata in produzione della Piattaforma FASE 3 dell’esecuzione

del contratto.

Il concorrente, nell’ambito dell’Offerta Tecnica, dovrà evidenziare il piano relativo ai periodi di fermo-macchina dell’attuale gestionale, nonché le misure adottate per ridurre al minimo i disservizi. I dati di cui l’Affidatario dovrà garantire la migrazione alla nuova Piattaforma sono di diversa tipologia e provengono da due fonti diverse:

✓ dati relativi alle risorse analogiche, provenienti dal gestionale in uso Aleph500, versione 22.1.6:

o record bibliografici (con tutte le informazioni che consentono la descrizione completa della risorsa, incluse le relazioni tra risorse: monografie a livelli, schede di periodici con legami, ecc.);

o dati amministrativi delle monografie e dei periodici cartacei (ordini, abbonamenti, fascicoli, piani previsionali, ecc.);

o record di copia (stato della copia, politiche di prestabilità, collocazione, inventario, ecc.);

o record di operatori, utenti e fornitori;

o record di acquisizione (ordini);

o transazioni attive e storiche seguenti:

- prestiti locali e interbibliotecari (mantenendo invariata la data di scadenza);

- prenotazioni;

- ordini chiusi e aperti;

- volumi non presenti in sede (per rilegatura, restauro, ecc.);

✓ dati relativi alle risorse elettroniche sottoscritte dall’Ateneo, provenienti dal link resolver in uso

(SFX) seguenti:

- titoli;

- numeri standard;

- consistenze;

- attivazioni.

Oltre al Piano per la migrazione, dovranno essere descritti in maniera dettagliata:

• il supporto richiesto al Team di Progetto del Committente nella fase di pre-migrazione (Fase 1);

• la formazione del Team di progetto del Committente, al fine di prendere familiarità con la nuova Piattaforma, le sue caratteristiche e configurazioni;

• la collaborazione del Team di progetto del Committente, durante la migrazione di test (Fase 2), al fine di testare il corretto trasferimento dei dati dal vecchio gestionale alla nuova Piattaforma;

• il supporto post-migrazione al Team di progetto del Committente.

7.2 Aggiornamento e manutenzione dell’infrastruttura tecnologica

L’Affidatario è tenuto a garantire il costante aggiornamento e manutenzione dell’infrastruttura tecnologica di cui intende servirsi lungo tutta la durata dell’appalto.

L’Affidatario è tenuto inoltre a specificare a quali provider intende appoggiarsi: questi dovranno avere affidabilità (availability) almeno pari al 99,5% su base mensile.

7.3 Disaster Recovery

L’Affidatario deve disporre di un servizio di Disaster Recovery (DR) conforme almeno a quanto previsto per il livello Tier 3 indicato nelle linee guida AGID, allo scopo di garantire la continuità operativa in caso di problemi.

7.4 Back-up e restore

L’Affidatario deve provvedere a tutte le attività di back-up e restore (quando richiesto) di tutti i dati e le configurazioni coinvolti nella gestione del contratto. Il backup deve essere effettuato almeno una volta al giorno e devono essere resi disponibili i backup almeno degli ultimi 7 giorni.

7.5 Sicurezza informatica e trattamento dati

L’Affidatario è obbligato al Segreto d’Ufficio su notizie e dati conosciuti in ragione dello svolgimento delle attività oggetto di affidamento, ai sensi della normativa vigente, ed al rispetto delle normative nazionali e sovranazionali in materia di trattamento e protezione dei dati, ai sensi del Regolamento UE 679/2016 (GDPR), del D.lgs. 196/2003 e s.m.i. (Codice Privacy) e del presente Capitolato.

Il Politecnico in quanto “Titolare del trattamento”, nominerà l’Affidatario “Responsabile del trattamento” (ai sensi del Regolamento UE 2016/679 art. 28), specificando analiticamente per iscritto i compiti dello stesso e vigilando periodicamente sulla puntuale osservanza delle istruzioni impartite e sul generale rispetto della normativa italiana ed europea in materia di protezione dei dati personali.

La Piattaforma deve pertanto garantire la conformità a quanto prescritto dalla Circolare 18 aprile 2017, n. 2 dell’Agenzia per l’Italia Digitale (AgID), recante le Misure minime di sicurezza ICT per le pubbliche amministrazioni; il Concorrente nell’ambito dell’Offerta Tecnica oltre a fornire descrizione dettagliata della Piattaforma deve comprovarne - con idonea documentazione - la sua sicurezza informatica.

In particolare, si richiede:

• che l’Affidatario conservi tutti i dati presso locali tecnici di cui abbia la piena disponibilità per tutta la durata del contratto;

• che il Data Center - che deve ospitare e gestire le risorse hardware e software, nonché gli archivi di dati relativi alla fornitura ed ai servizi oggetto dell’Appalto - sia ubicato all’interno del territorio dell’Unione Europea. Il Data Center deve essere organizzato e gestito nel rispetto della normativa italiana ed europea sulle misure di sicurezza informatica e sulla protezione dei dati, oltre ad essere dotato di idonee misure atte a prevenire il rischio derivante dalla distruzione, perdita, modifica, divulgazione non autorizzata o dall’accesso, in modo accidentale o illegale, a dati personali trasmessi, conservati o comunque trattati. In particolare, dovrà essere dotato di opportuni sistemi di protezione logica e fisica al fine di impedire accessi non autorizzati;

• che sia garantito un continuativo e metodico processo di auditing – almeno annuale e, in ogni caso, anche su richiesta del Committente – volto a verificare l’efficacia e quindi a effettuare una valutazione complessiva dell’adeguatezza delle misure tecniche ed organizzative adottate, tenendo anche conto delle conoscenze acquisite in base al progresso tecnico e di cui informerà il Committente.

Il Committente ha facoltà di effettuare verifiche informative e documentali, al fine di effettuare controlli sull’operato dell’Affidatario, sul rispetto delle istruzioni impartite e sulle misure tecniche ed organizzative adottate per garantire un livello adeguato di sicurezza dei dati;

• che l’Affidatario adotti soluzioni idonee a registrare gli accessi degli Amministratori di sistema (access log), tali da (i) garantire che le registrazioni siano complete e inalterabili, (ii) consentire verifiche di integrità e (iii) poterle conservare per un congruo periodo non inferiore a 6 (sei) mesi. Inoltre, il sistema di verifica deve consentire di monitorare ogni aspetto della gestione quotidiana della Piattaforma, in termini di accesso, operazioni effettuate, eventi occorsi. Deve essere possibile la registrazione sequenziale e cronologica delle operazioni effettuate – dagli operatori, dall’amministratore ed anche automatiche – onde consentire l’analisi delle segnalazioni di

errore, l’analisi delle operazioni fatte e dei relativi responsabili e la produzione di statistiche di

utilizzo;

• che sia prevista la tracciatura delle operazioni eseguite, sia da parte degli utenti esterni che dalle procedure interne, e il monitoraggio dei tentativi di accesso non autorizzato da parte di sistemi esterni dandone evidenza al Committente tramite report periodico. In presenza di incidenti di sicurezza che interessino la Piattaforma, o nel caso si verifichi qualsiasi violazione o rischio di violazione di dati personali, l’Affidatario dovrà repentinamente (e nelle modalità specificate nell’atto di nomina) avvisare il Committente dell’accaduto, fornendo le informazioni utili a verificare la portata della violazione dei dati, almeno in termini di tipo e quantità di dati personali pregiudicati, categorie e numero di interessati verosimilmente coinvolti, a indicare il contatto presso cui ottenere più informazione, oltre agli interventi attuati o che si prevede di attuare. In relazione all’eventuale scoperta di vulnerabilità di cui risulta afflitta la Piattaforma, l’Affidatario dovrà altresì dare immediata comunicazione al Committente, dando indicazioni specifiche sulle tempistiche di risoluzione, diversificate sulla base del rischio associato e della complessità delle misure da attuare, e sull’applicazione delle opportune contromisure atte a ridurre il rischio e adottate nella finestra di esposizione;

• che siano previsti strumenti di monitoraggio e di logging, secondo quanto previsto dalla Circolare AgID numero 3 del 9 aprile 2018;

• nel caso in cui la Piattaforma operi in ambiente multi-tenant, che sia garantito l’isolamento dei dati;

• che l’Affidatario si impegni a fornire ai soggetti autorizzati del Politecnico di Torino le informazioni relative a chi può accedere ai dati e a quali tipologie di accessi e di controlli sono in atto sui possibili accessi ai dati del Committente.

7.6 Proprietà e portabilità dei dati

I dati del Politecnico rimangono nel suo esclusivo possesso: l’Affidatario è autorizzato esclusivamente alla loro gestione nonché per le necessità ed i fini connessi alla gestione del contratto, nei termini previsti dalla Circolare AgID numero 3 del 9 aprile 2018.

L’Affidatario dovrà garantire, senza ulteriori oneri, la portabilità dei dati del Committente verso altra

Impresa al termine del contratto o in caso di interruzione anticipata del rapporto contrattuale.

Al termine del rapporto contrattuale l’Affidatario dovrà provvedere a:

- estrarre i dati e metterli a disposizione dell’Impresa subentrante in un formato concordato

tra le parti, fornendo tutto il supporto necessario per un efficace passaggio di consegne;

- mettere a disposizione del Committente la documentazione descrittiva dei formati di esportazione, garantendo il formato UNIMARC ed il formato MARC21, qualora richiesti;

- garantire la continuità del servizio fino all’avvio delle operazioni di migrazione, le cui tempistiche verranno concordate tra le parti;

- garantire la conservazione e l’accesso ai dati per tutta la durata delle operazioni di

migrazione;

- mettere a disposizione del Committente tutta la documentazione correttamente conservata;

- rendere impossibile il recupero dei dati di cui il Committente abbia chiesto la cancellazione.

Durante la fase di chiusura, l'Utenza dovrà poter continuare lo svolgimento delle attività sulla Piattaforma e non dovrà subire alcun peggioramento del servizio erogato.

La riconsegna dei dati e la chiusura del servizio dovranno essere formalizzate in un apposito verbale. La Commissione potrà giudicare inadeguata la Piattaforma offerta qualora fosse verificata la mancanza di uno o più elementi relativi alla sicurezza e al trattamento dei dati, alla continuità del servizio e al disaster- recovery, alla portabilità e alla proprietà dei dati.

7.7 Formazione

L’Affidatario si impegna, a proprie spese, ad erogare attività di formazione tecnica sia relativamente al Team di progetto del Committente sia agli Operatori. La stessa dovrà essere effettuata durante la fase di migrazione e prima dell’emissione del certificato di verifica di conformità di cui al precedente punto 6 relativo alla verifica di conformità di funzionamento del sistema.

Dovranno inoltre essere forniti manuali e documentazione in lingua italiana relativi a tutte le funzionalità della piattaforma.

La formazione dovrà obbligatoriamente essere erogata in lingua italiana, secondo un calendario concordato con il Committente e dovrà contare su materiale didattico in italiano e avvalersi dell’utilizzo di un ambiente di test.

Al termine dell’attività di formazione tecnica dovrà essere rilasciata per ciascuna unità di personale

partecipante un attestato di partecipazione al corso.

I corsi dovranno svolgersi preferibilmente in presenza, presso il Politecnico di Torino, salvo diversi accordi da prendersi con la Stazione Appaltante a seguito dell’aggiudicazione.

Le modalità secondo cui l’Affidatario intende provvedere alla formazione dovranno essere

esplicitate nell’Offerta Tecnica.

Il corso dovrà essere erogato a tutti gli operatori, indicativamente 30.

7.8 Verifica di conformità ed emissione del certificato di regolare esecuzione

Il Responsabile unico del procedimento controlla l'esecuzione del contratto congiuntamente al Direttore dell'esecuzione ed emette il certificato di verifica di conformità se accerta che l'oggetto del contratto in termini di prestazioni, obiettivi e caratteristiche tecniche, economiche e qualitative sia stato realizzato ed eseguito nel rispetto delle previsioni contrattuali e delle pattuizioni concordate in sede di affidamento.

Durante tutto l’iter di migrazione dei dati (punto 7.1) il RUP ed il DEC assicureranno il corretto adempimento delle prestazioni. In particolare, durante la FASE 4 descritta al precedente punto 6 del presente Capitolato, il RUP ed il DEC procederanno a verificare il buon esito della migrazione definitiva ed il corretto funzionamento della Piattaforma a regime.

Tale verifica potrà durare fino a 40 giorni a partire dal momento in cui l’Affidatario comunicherà di

aver terminato le attività di migrazione (FASE 3 – punto 6).

Durante la verifica, l’Affidatario dovrà garantire il necessario supporto al Team di Progetto del

Committente e gli interventi correttivi indispensabili al buon funzionamento della Piattaforma.

Tutte le spese per le verifiche saranno poste a carico dell’Affidatario e il loro costo si intende compreso nel prezzo dell’offerta complessiva.

A seguito della migrazione, nella fase di gestione a regime, si procederà a verifiche parziali.

A completamente di tutte le verifiche (FASE 5) e all'esito positivo delle stesse, e comunque non oltre i termini previsti dall’art. 4, commi 2, 3, 4 e 5 del decreto legislativo 9 ottobre 2002, n. 231, il Responsabile Unico del Procedimento emetterà certificato di regolare esecuzione.

Nel caso in cui le verifiche non abbiano esito positivo il RUP comunicherà tramite PEC la non conformità riservandosi la possibilità di applicare le eventuali penali previste fino alla risoluzione del contratto.

7.9 Qualità della fornitura e dei servizi connessi

L’Affidatario deve provvedere all’esecuzione della fornitura e dei servizi connessi con la necessaria perizia e diligenza impiegando personale qualificato, in modo da garantirne l’attuazione a perfetta regola d’arte, nel rispetto dei tempi stabiliti e degli SLA concordati.

8. OBBLIGHI DELLA STAZIONE APPALTANTE

La Stazione Appaltante si obbliga a:

• non avvalersi di altro Appaltatore per il medesimo servizio fino alla scadenza del contratto;

• fornire tutta la collaborazione necessaria all’Appaltatore per la buona riuscita del risultato del servizio secondo le regole della correttezza imposte dal Codice civile e dalla vigente normativa;

• ispirare i rapporti con l’Appaltatore alla massima trasparenza ed alla buona fede, nel rispetto

delle norme vigenti;

• provvedere al pagamento delle fatture regolarmente emesse ed autorizzate nei termini previsti dal presente Capitolato Speciale d’Appalto e sulla base della vigente normativa civilistica e di contabilità pubblica. Si precisa che il Politecnico di Torino resta estraneo a qualsiasi rapporto fra l’aggiudicatario e i suoi dipendenti, collaboratori e fornitori.

9. GARANZIA FIDEIUSSORIA O CAUZIONE DEFINITIVA

Ai sensi dell’art. 103 del D.lgs. 50/2016 e ss.mm.ii. l’Affidatario è tenuto a prestare, a garanzia dell’adempimento di tutte le obbligazioni del contratto, del risarcimento dei danni derivanti dall’eventuale inadempimento delle obbligazioni stesse, nonché a garanzia delle somme pagate in più all’esecutore rispetto alle risultanze della liquidazione finale, una garanzia definitiva nella misura del 10% dell’importo contrattuale, ovvero nella maggiore misura stabilita ai sensi del citato art. 103. Si rinvia al disciplinare di gara.

10. OBBLIGHI ASSICURATIVI A CARICO DELL’AFFIDATARIO

L’impresa Affidataria assume la piena ed esclusiva responsabilità di tutti i danni che possono capitare in relazione al presente affidamento, tenendo manlevato ed indenne il Committente per ogni e qualsiasi danno cagionato a persone e cose, siano essi terzi o personale dell’impresa aggiudicataria, verificatosi durante l’esecuzione dell’appalto.

Sono, di conseguenza, a carico dell’Affidatario – senza che risultino limitate le sue responsabilità contrattuali – le spese per assicurazioni contro danni, furti e responsabilità civile.

Prima della stipula del contratto, l’impresa Affidataria deve consegnare al Politecnico una polizza di assicurazione che copra la responsabilità civile dell'impresa verso i terzi per tutte le attività relative al servizio appaltato con i seguenti massimali di garanzia:

• Euro 1.500.000,00 quale limite per sinistro.

Resta inteso che l’esistenza e quindi la validità ed efficacia della polizza assicurativa di cui al presente articolo è condizione essenziale e, pertanto, qualora l’Affidatario non sia in grado di provare in qualsiasi momento la copertura assicurativa di cui si tratta, il Contratto si risolve di diritto con conseguente incameramento della cauzione prestata a titolo di penale e fatto salvo l’obbligo di risarcimento del maggior danno subito.

Copia delle polizze deve essere consegnata alla Stazione Appaltante prima della firma del contratto e, qualora essa preveda rate scadenti durante il periodo di affidamento del servizio, deve altresì essere consegnata, entro i quindici giorni successivi a tali scadenze di rate, copia dell’avvenuta quietanza di pagamento del premio.

11. DISPOSIZIONI PARTICOLARI RIGUARDANTI L’APPALTO

L’assunzione dell’appalto di cui al presente C.S.O. da parte dell’Impresa Affidataria equivale a dichiarazione di perfetta conoscenza e incondizionata accettazione della legge, dei regolamenti e di tutte le norme vigenti in materia di affidamenti pubblici. In particolare, l’Impresa Affidataria, all’atto della firma del contratto, accetta tutte le clausole contenute nelle suddette disposizioni di legge nonché quelle contenute nel presente Capitolato. Inoltre, tale assunzione implica la perfetta conoscenza di tutte le condizioni locali, ed in generale di tutte le circostanze, di tipo generale e particolare, che possano aver influito sul giudizio dell’Impresa Aggiudicatrice circa la convenienza

di assumere l’appalto, anche in relazione alla prestazione da rendere ed ai prezzi offerti. Infine, si precisa che l’assunzione dell’appalto implica il pieno rispetto degli obblighi relativi alle disposizioni in materia di sicurezza, di condizioni di lavoro e di previdenza ed assistenza.

L’Impresa Affidataria è tenuta ad osservare le istruzioni e gli ordini impartiti dalla Stazione appaltante. Il contratto è regolato, oltre che dalle norme del presente Capitolato, e per quanto non sia in contrasto con le norme stesse, anche con le leggi statali e regionali, comprensive dei relativi regolamenti, dalle istruzioni ministeriali vigenti, inerenti e conseguenti la materia di appalto.

In particolare, l’Impresa Aggiudicataria si intende inoltre obbligata all’osservanza di:

• leggi, regolamenti, disposizioni vigenti e di successiva emanazione, emanate durante l’esecuzione delle prestazioni, relative alle assicurazioni degli operai contro gli infortuni sul lavoro, sull’assunzione della manodopera locale, l’invalidità e la vecchiaia ecc.

• leggi e norme vigenti sulla prevenzione degli infortuni e sulla sicurezza del luogo di lavoro e nei cantieri.

12. XXXXXXX AD ADEMPIERE E RISOLUZIONE DI DIRITTO DEL CONTRATTO

Nel caso di difformità delle prestazioni oggetto del contratto rispetto a quanto richiesto in relazione alle singole fasi, la Stazione appaltante ha la facoltà di rifiutare la prestazione e di intimare di adempiere alle prestazioni pattuite, a mezzo di lettera raccomandata/PEC, fissando un termine perentorio non superiore a 15 giorni (naturali e consecutivi) entro il quale l’Affidatario si deve conformare alle indicazioni ricevute. Trascorso inutilmente il termine stabilito, il Contratto è risolto di diritto.

Nel caso di Inadempienze gravi o ripetute, la Stazione appaltante ha la facoltà di risolvere il Contratto, a mezzo di lettera raccomandata/PEC, con tutte le conseguenze di legge che la risoluzione comporta, ivi compresa la facoltà di affidare l’appalto a terzi in danno dell’Impresa Affidataria e l’applicazione delle penali già contestate.

In ogni caso, il Politecnico non corrisponderà alcun compenso per le prestazioni non eseguite o non eseguite esattamente.

La risoluzione comporta altresì il risarcimento da parte dell’Affidatario dei maggiori danni subiti dal

Politecnico.

Il Politecnico comunicherà all’Autorità Nazionale Anticorruzione le violazioni contrattuali riscontrate in fase di esecuzione del contratto da parte dell’Affidatario, di cui sia prevista la segnalazione dalla Determinazione AVCP n. 1/2008.

13. CLAUSOLA RISOLUTIVA ESPRESSA

Il contratto di appalto è risolto ai sensi e per gli effetti dell’art. 1456 del Codice civile, con riserva di risarcimento danni, nei seguenti casi:

a) frode nell’esecuzione delle prestazioni contrattuali;

b) situazione di fallimento, di liquidazione coatta, di concordato preventivo ovvero procedura

di insolvenza concorsuale o di liquidazione dell’appaltatore;

c) manifesta incapacità nell’esecuzione delle prestazioni contrattuali, violazione delle prescrizioni minime previste nel presente capitolato e nell’offerta presentata in fase di gara;

d) inadempienza accertata alle norme di legge sulla prevenzione degli infortuni, la sicurezza del lavoro e le assicurazioni obbligatorie delle maestranze nonché ai contratti collettivi di lavoro;

e) subappalto non autorizzato della prestazione;

f) cessione totale o parziale del contratto;

g) quando l’ammontare delle penali applicate nei confronti dell’Affidatario superi il 10% dell’importo contrattuale;

h) mancata reintegrazione della cauzione definitiva nel termine indicato dal Politecnico;

i) ingiustificata interruzione o sospensione del servizio/fornitura per decisione unilaterale

dell’Appaltatore;

j) DURC irregolare per due volte consecutive durante il periodo dell’esecuzione contrattuale

k) violazione degli obblighi di tutela dei dati e riservatezza, di gravità tale da non consentire

l’ulteriore prosecuzione delle obbligazioni contrattuali;

l) qualora l’Appaltatore risulti destinatario di provvedimenti definitivi o provvisori che dispongano misure di prevenzione o divieti, sospensioni o decadenze previsti dalla normativa antimafia, ovvero di pendenze di procedimenti per l’applicazione delle medesime disposizioni, ovvero di condanne che comportino l’incapacità di contrarre con la pubblica amministrazione;

m) qualora l’Appaltatore non sia in grado di provare in qualsiasi momento la copertura

assicurativa;

n) In tutti i casi in cui, in violazione di quanto prescritto dall’art. 3 della legge 136/2010 e dall’art. 7, c. 1, lett. a del D. L. 187/2010, le transazioni finanziarie relative al contratto siano state effettuate senza avvalersi dello strumento del bonifico bancario o postale, ovvero con altri strumenti di pagamento idonei a consentire la piena tracciabilità delle operazioni;

o) in caso di gravi ed accertate violazioni del Codice di Comportamento del Politecnico di Torino;

p) in caso di mancata tempestiva stipulazione del contratto e in caso di tardivo avvio

dell’esecuzione dello stesso, qualora imputabili all’operatore economico;

q) in tutti gli altri casi previsti dalla disciplina di gara, ove la risoluzione di diritto sia espressamente comminata.

Resta salva ed impregiudicata la possibilità per il Politecnico di Torino di procedere alla risoluzione del contratto, anche al di fuori delle ipotesi qui previste, in caso di gravi ed oggettive inadempienze

da parte del Fornitore, oltre che nei casi espressamente previsti dall’art. 108 del D.lgs. 50/2016 e

ss.mm.ii.

In caso di fallimento, di liquidazione coatta e concordato preventivo, ovvero di procedura di insolvenza concorsuale o di liquidazione dell’Appaltatore, o di risoluzione del contratto ai sensi dell’art. 108 del D.lgs. 50/2016 e ss.mm.ii., ovvero di recesso dal contratto ai sensi dell’art. 88, comma 4 – ter, del D.lgs. 159/2011, ovvero in caso di dichiarazione giudiziale di inefficacia del contratto, la Stazione appaltante procederà ai sensi dell’art. 110 del D.lgs. 50/2016 e ss.mm.ii. Qualora l’esecutore sia un’associazione temporanea, in caso di fallimento si applica la disciplina prevista dall’art. 48, c. 17 e 18 del D.lgs. 50/2016 e ss.mm.ii.

Ove si proceda alla risoluzione del contratto per fatto imputabile all’Affidatario, sarà riconosciuto a quest’ultimo unicamente l’ammontare relativo alla parte della fornitura eseguita in modo completo ed accettata dall’Amministrazione, decurtato delle penali applicabili e degli oneri aggiuntivi derivanti dallo scioglimento del contratto, determinati anche in relazione alla maggiore spesa sostenuta per affidare ad altro operatore economico la fornitura ove non sia stato possibile procedere all’affidamento ai sensi dell'articolo 110, c.1.

L’Impresa dovrà in ogni caso risarcire il Politecnico di Torino per qualsiasi danno diretto o indiretto

che possa comunque derivare dal suo inadempimento.

14. RISOLUZIONE DEL CONTRATTO PER SOPRAVVENIENZA DI CONVENZIONI CONSIP E/O SCR- PIEMONTE

In base a quanto previsto dal combinato disposto dell’art. 1, comma 3 del D.L. 95/2012, come convertito dalla legge 135/2012, e dell’art. 1, comma 450 della legge 296/2006, il Politecnico di Torino procederà alla risoluzione del contratto stipulato all’esito della presente procedura qualora, nel corso dell’esecuzione del contratto, i beni/servizi ivi previsti si rendano disponibili nell’ambito di una convenzione stipulata:

• da Consip, ai sensi dell’art. 26 della legge 488/1999

• ovvero, dalla centrale di committenza regionale, ai sensi dell’art. 1 comma 455 della

legge 296/2006.

15. ESECUZIONE IN DANNO

Nel caso di inadempienze gravi o ripetute o in caso - eccettuati i casi di forza maggiore - di omissione ovvero di sospensione anche parziale, da parte dell’Affidatario, dell’esecuzione delle prestazioni oggetto del contratto, il Politecnico, dandone opportuna comunicazione, potrà avvalersi di soggetto terzo in danno e spese dell’Affidatario, oltre ad applicare le previste penali.

16. CESSIONE DEL CONTRATTO E CESSIONE DEI CREDITI

È vietata la cessione del contratto sotto qualsiasi forma; ogni atto contrario è nullo.

È ammessa la cessione dei crediti, ai sensi dell’articolo 106, c. 13, D.lgs. 50/2016 e ss.mm.ii.

17. RECESSO

Il Politecnico può recedere dal contratto in qualunque tempo secondo quanto previsto all’art. 109

D.lgs. 50/2016 e ss.mm.ii., cui si rinvia.

18. FATTURAZIONE E PAGAMENTI

Il pagamento, ove non emergano eccezioni, avverrà con le seguenti modalità:

• l’importo una tantum, da corrispondere per le attività di implementazione della Piattaforma, migrazione dei dati e formazione degli operatori, verrà versato in quattro tranche uguali con le seguenti cadenze (v. art. 6):

- prima tranche: alla conclusione della Fase 1;

- seconda tranche: alla conclusione della Fase 2;

- terza tranche: alla conclusione della Fase 3;

- quarta tranche: alla firma della verifica di conformità (conclusione Fase 4);

• il canone annuo verrà versato in 1 rata annuale tramite fatturazione in forma elettronica, ai sensi della normativa vigente.

Al fine di dar seguito ai pagamenti secondo le cadenze sopra previste, Il Responsabile Unico del Procedimento - previa verifica positiva delle attività svolte nelle singole fasi - rilascerà il certificato di pagamento al ricevimento del quale l’Affidatario potrà emettere la relativa fattura.

Nei prezzi espressi dall’Impresa Affidataria e nei corrispettivi corrisposti alla stessa s’intendono interamente compensati tutti gli oneri previsti per la mano d’opera occorrente, tutto quanto occorre per il funzionamento dei mezzi, le imposte di ogni genere nessuna esclusa, le spese generali, l’utile dell’impresa e quant’altro possa occorrere per eseguire le prestazioni in maniera compiuta e a perfetta regola d’arte.

In attuazione di quanto disposto dall’art. 113 bis, comma 3, del D.lgs. 50/2016 e ss.mm.ii., l’Affidatario provvederà all’emissione della fattura a seguito della trasmissione da parte del Responsabile Unico del Procedimento del certificato di pagamento conseguente alla positiva verifica di conformità della fornitura.

In base al combinato disposto dell’art. 1, comma 209 della L. 244/2007, dell’art. 6, comma 3 del Decreto MEF 55/2013 e dell’art. 25, comma 1 del D.L. 66/2014, la fatturazione nei confronti del Politecnico di Torino deve essere effettuata esclusivamente in formato elettronico, secondo le modalità previste dal Sistema di Interscambio appositamente realizzato dall’Agenzia delle Entrate e da SOGEI: tutte le informazioni necessarie per operare secondo le predette modalità sono disponibili all’indirizzo internet xxx.xxxxxxxxx.xxx.xx.

Tutti i movimenti finanziari relativi all’appalto saranno registrati sul conto corrente bancario o postale

dedicato, anche in via non esclusiva, alla presente commessa pubblica. I relativi pagamenti saranno

effettuati esclusivamente a mezzo bonifico bancario o postale, ovvero con altri strumenti di pagamento idonei a consentire la piena tracciabilità delle operazioni.

Nelle fatture ed altri documenti fiscali emessi ai fini dell’ottenimento del pagamento, l’I.A. è tenuto

a riportare negli stessi:

• gli estremi del conto corrente dedicato

• il codice CIG

• il numero di ordine riportato nel bando/lettera di invito/disciplinare, se previsto per la tipologia di affidamento

• Il codice identificativo amministrazione: LDUOKT.

Con riferimento al regime IVA, si precisa che il Politecnico di Torino rientra nel campo di applicazione del Decreto del Ministero dell’Economia 23.01.2015: le fatture di cui al presente paragrafo dovranno pertanto essere emesse in regime di scissione dei pagamenti (cd. Split Payment) e recare la relativa annotazione.

Il pagamento delle fatture sarà effettuato mediante bonifico bancario a 30 giorni data ricevimento fattura, fatte salve le tempistiche necessarie per le verifiche di regolarità contributiva e fiscale previste dalla vigente normativa.

In caso di riscontrata inadempienza contributiva risultante dal documento unico di regolarità

contributiva, si applica l’art. 30, c. 5, D.lgs. 50/2016 e ss.mm.ii.

19. ANTICIPAZIONE DEL PREZZO

É ammessa l’anticipazione del prezzo, previa costituzione da parte dell’affidatario di una garanzia fideiussoria bancaria o assicurativa di importo pari all’anticipazione maggiorato del tasso di interesse legale, ai sensi dell’art. 35 co. 18 D.lgs. 50/2016.

20. TRACCIABILITÀ DEI FLUSSI FINANZIARI

L’Affidatario è tenuto ad assumere gli obblighi di tracciabilità dei flussi finanziari, di cui all’art. 3 della legge 136/2010 e sanzionati dall’art. 6 della medesima legge e ss.mm.ii. In particolare, è tenuta a comunicare alla Stazione appaltante gli estremi identificativi del conto corrente dedicato, anche in via non esclusiva, alla commessa pubblica oggetto del presente affidamento, nonché le generalità e il codice fiscale delle persone delegate ad operare su di essi. L’Affidatario è altresì tenuto a comunicare ogni modifica relativa ai dati trasmessi.

La comunicazione deve essere effettuata entro sette giorni dall'accensione del conto corrente ovvero, nel caso di conti correnti già esistenti, dalla loro prima utilizzazione in operazioni finanziarie relative ad una commessa pubblica. In caso di persone giuridiche, la comunicazione de quo deve essere sottoscritta da un legale rappresentante ovvero da un soggetto munito di apposita procura. L'omessa, tardiva o incompleta comunicazione degli elementi informativi comporta, a carico del

soggetto inadempiente, l'applicazione di una sanzione amministrativa pecuniaria da 500 a 3.000 euro. Il mancato adempimento agli obblighi previsti per la tracciabilità dei flussi finanziari relativi all’appalto comporta la risoluzione di diritto del contratto.

In occasione di ogni pagamento all’appaltatore o di interventi di controllo ulteriori si procede alla verifica dell’assolvimento degli obblighi relativi alla tracciabilità dei flussi finanziari.

Il contratto è sottoposto alla condizione risolutiva in tutti i casi in cui le transazioni siano state eseguite senza avvalersi di banche o di Società Poste Italiane S.p.a. o anche senza strumenti diversi dal bonifico bancario o postale che siano idonei a garantire la piena tracciabilità delle operazioni per il corrispettivo dovuto in dipendenza del presente contratto.

21. INADEMPIENZE E PENALITÀ

Qualora l'esecuzione delle prestazioni ritardi, per negligenza dell'Affidatario, rispetto al piano di esecuzione concordato, la stazione appaltante potrà applicare una penale in ragione dell’uno (1) per mille dell’importo contrattuale per ogni giorno di ritardo oltre i 15 rispetto al termine previsto per ogni singola frase descritta nel paragrafo 6.

Nel caso in cui la piattaforma, ovvero parti di essa, presenti significative anomalie funzionali, queste saranno segnalate dalla stazione appaltante dal RUP a mezzo PEC o altro canale indicato dall’affidatario. Qualora non siano risolte entro 15 giorni (consecutivi e di calendario), sarà applicata una penale per il ritardo nella correzione delle anomalie segnalate, in ragione dello 0,5 per mille dell’importo contrattuale ogni giorno dopo la comunicazione.

Per l’applicazione delle penali si procederà, a mezzo PEC o altro strumento analogo, alla contestazione all’Affidatario del relativo inadempimento contrattuale da parte del Responsabile del Procedimento. Entro il limite di 3 (tre) giorni successivi a detta comunicazione, l’Affidatario potrà presentare eventuali osservazioni; decorso il suddetto termine, la Stazione appaltante, nel caso non abbia ricevuto alcuna giustificazione, oppure, se ricevuta non la ritenga fondata, procederà discrezionalmente all’applicazione delle penali e, in ogni caso, all’adozione di ogni determinazione ritenuta opportuna.

Le penali saranno applicate mediante ritenuta sul primo pagamento utile al verificarsi della contestazione, previa emissione di nota di credito da parte dell’Affidatario o, in alternativa, mediante prelievo a valere sulla cauzione definitiva.

Il pagamento delle penali non pregiudica il diritto del Politecnico di ottenere la prestazione. È salvo in tutti i casi il diritto del Politecnico di chiedere il risarcimento del maggior danno, nonché la risoluzione del contratto, impregiudicati gli altri rimedi contrattualmente previsti.

22. SUBAPPALTO

Il subappalto è ammesso in conformità a quanto previsto dall’art. 105 del D.lgs. 50/2016 e ss.mm.ii.

23. REFERENTE DELL’AFFIDATARIO

Il Referente responsabile della fornitura, cui è affidato il coordinamento delle attività oggetto del presente contratto e a cui competerà il ruolo di interlocutore con il Politecnico di Torino per ogni questione inerente all’esecuzione dello stesso contratto, è indicato dall’Affidatario prima dell’avvio dell’esecuzione.

Il Politecnico si rivolgerà direttamente al Referente per ogni informazione o problema che dovesse sorgere durante l'espletamento della fornitura. Tutte le comunicazioni formali saranno trasmesse all’attenzione del Referente e si intenderanno come validamente effettuate ai sensi e per gli effetti di legge. Quanto dichiarato e sottoscritto dal Referente, sarà considerato dal Politecnico come dichiarato e sottoscritto in nome e per conto dell’Affidatario.

Il Referente deve regolarmente aggiornare il Responsabile del Procedimento sullo svolgimento della fornitura.

24. FORO COMPETENTE

Per tutte le controversie relative alla validità, interpretazione, esecuzione e risoluzione del Contratto che non dovessero risolversi in via bonaria è competente esclusivamente il Foro di Torino, salva la giurisdizione del Giudice Amministrativo.

Le parti si impegnano ad esperire ogni iniziativa utile per addivenire ad un’equa e ragionevole composizione dell’eventuale vertenza, prima di adire le vie legali.

25. OBBLIGHI DI RISERVATEZZA E TRATTAMENTO DEI DATI PERSONALI

Il Contraente ha l’obbligo di mantenere riservati i dati e le informazioni, ivi compresi quelli che transitano per le apparecchiature di elaborazione dati, di cui venga in possesso o comunque a conoscenza, di non divulgarli in alcun modo e in qualsiasi forma, di non comunicarli a terzi non autorizzati e di non farne oggetto di utilizzazione a qualsiasi titolo per scopi diversi da quelli strettamente necessari all’esecuzione del Contratto, pur assicurando nel contempo la trasparenza delle attività svolte.

Il Contraente è responsabile per l’esatta osservanza degli obblighi anzidetti da parte dei propri dipendenti, consulenti e collaboratori, nonché dei subappaltatori e dei relativi dipendenti, consulenti e collaboratori.

Committente e Contraente si impegnano a rispettare le norme vigenti relative al trattamento dei dati personali e, in particolare, quelle contenute nel Regolamento (UE) 679/2016 e nel d.lgs. n. 196/03 s.m.i., rinviando, ove necessario, alla sottoscrizione di appositi successivi atti che disciplinino le rispettive responsabilità.

Ai fini del presente articolo, Titolare del Trattamento dati personali è il Politecnico di Torino, con sede in Xxxxx Xxxx xxxxx Xxxxxxx x. 00, 00000 – Xxxxxx, nella persona del Rettore. Il dato di contatto del Titolare è: xxxxxxxxxxxxxxxxxxx@xxx.xxxxxx.xx . Per ulteriori informazioni e chiarimenti: xxxxxxx@xxxxxx.xx. Il Responsabile della protezione dati (“DPO”) del Politecnico di Torino, al quale gli interessati possono rivolgersi per questioni relative al trattamento dei loro dati personali e all’esercizio dei loro diritti, è contattabile ai seguenti indirizzi: xxx@xxxxxx.xx; PEC: xxx@xxx.xxxxxx.xx .

Il Politecnico in quanto “Titolare del trattamento”, nominerà l’Affidatario “Responsabile del

trattamento” (ai sensi del Regolamento UE 2016/679 art. 28.

26. SPESE E ONERI FISCALI

Tutte le spese per l’organizzazione e l’espletamento delle prestazioni sono a carico del Contraente,

salvo diversa disposizione espressa del Capitolato.

Ad esso spettano altresì tutte le spese, le imposte, i diritti di segreteria e le tasse relativi al

perfezionamento e alla registrazione del Contratto in caso d’uso.

Il Contratto è soggetto all’imposta sul valore aggiunto (Iva), regolata dalla legge.

Tutti gli importi citati nel Contratto, nel Capitolato e negli atti che ne costituiscono parte integrante

s’intendono Iva esclusa, salvo diversa disposizione espressa.

27. FORMA DEL CONTRATTO

Il contratto verrà stipulato in modalità elettronica. Le spese tutte, inerenti e conseguenti al contratto relativo all'appalto di cui trattasi saranno a carico dell'Aggiudicatario.

28. NORMA GENERALE

L’Affidatario esegue le prestazioni con la migliore diligenza ed è responsabile della conformità delle stesse alle regole dell’arte e alle prescrizioni e direttive del Committente integrative delle disposizioni di legge e di Contratto. Egli risponde inoltre dei beni avuti in consegna o in custodia e della disciplina dei propri dipendenti.

L’attività dell’Affidatario non deve provocare alterazioni nell’organizzazione e nell’attività del Committente, né ritardi o rallentamenti nell’organizzazione del lavoro di quest’ultimo, eccedenti quelli strettamente connessi al tipo d’attività da prestare.

L’Affidatario è tenuto a osservare e far osservare ai propri dipendenti le Clausole Contrattuali, nonché le norme di legge e di regolamento, anche sopravvenute nel corso dell’esecuzione contrattuale, ivi comprese le norme regolamentari interne al Politecnico e all’azienda del Contraente medesimo.

L’Affidatario si impegna ad osservare e a far osservare ai propri collaboratori a qualsiasi titolo, per quanto compatibili con il ruolo e l’attività svolta, gli obblighi di condotta previsti dal Codice di comportamento del Committente disponibile al seguente link:

xxxxx://xxx.xxxxxx.xx/xxxxxx/xxxxxxxxx/?xx_xxxxxxxxx_xxxxxx00000 .

29. SEDE E REPERIBILITÀ

Per tutta la durata del Contratto l’Affidatario è tenuto a mantenere informato il Committente circa il luogo in cui è la propria sede legale, la sede amministrativa competente e la sede operativa cui afferiscono le prestazioni oggetto del Contratto, comunicando e aggiornando tempestivamente gli indirizzi e i numeri di telefono utili.

30. RINVIO

Per tutto quanto non previsto nel presente capitolato speciale si rimanda alle norme del codice civile e alle altre leggi e regolamenti vigenti in materia.

SEZIONE II – SPECIFICHE TECNICHE

REQUISITI MINIMI

La Piattaforma proposta dal Concorrente e descritta nell’Offerta Tecnica deve possedere obbligatoriamente tutte le funzionalità dettagliate nella Tabella II-1 che costituiscono requisiti minimi la cui mancanza, anche di un solo elemento, comporta l’esclusione del concorrente dalla gara ai sensi dell’art. 59, comma 3, lett. a) D.lgs. 50/2016,

TABELLA II-1 - Dettaglio funzionalità obbligatorie (requisiti minimi)

A – Piattaforma in cloud, secondo il modello SaaS, integrata in tutte le sue componenti e

configurabile da un amministratore locale

Cloud

La Piattaforma, composta da un gestionale di back office in grado di svolgere funzioni di ILS e di ERMS e da un’Interfaccia Utente Unificata, deve essere messa a disposizione dall’Appaltatore in

cloud, secondo il modello SaaS

Hosting

La Piattaforma deve essere hosted in cloud con un datacenter situato in Europa al fine di soddisfare i dettami normativi riguardanti il trattamento dei dati personali.

L’infrastruttura di hosting deve essere iscritta nel registro AgID dei

Cloud Service Provider (CSP) qualificati

Web based

L’accesso alla Piattaforma deve essere possibile con il solo ausilio di una connessione Internet e di un browser. L’utilizzo delle funzionalità sia di back-end che di front-end deve essere garantito con sistemi operativi diversi (Windows, Mac, Linux) e mediante l’utilizzo dei browser più diffusi tra i quali Mozilla Firefox, Google Chrome, Safari, Microsoft Edge ecc.

API e

interoperabilità

La Piattaforma deve supportare i seguenti standard aperti di comunicazione: OpenURL, SRU, Z39.50, EDI, NCIP, SIP2, OAI-PMH

nonché la disponibilità di web-service e API relative alla totalità dei dati (complete di supporto e documentazione) per garantire la connessione e l’interoperabilità con sistemi esterni in modalità

bidirezionale (lettura/scrittura).

Dimensioni

La Piattaforma deve essere dimensionata in modo da poter

gestire:

a. Una rete di almeno 19 biblioteche facenti parte del Politecnico di Torino, di cui 2 Biblioteche Centrali e 17 dipartimentali. Tale articolazione può essere soggetta a variazioni nel tempo (nascita di nuove biblioteche, accorpamenti, scissioni, estinzioni)

b. Almeno 45 operatori contemporanei di back office

x. Xxxxxx 00.000 utenti finali

Integrazione

Le funzionalità di back office della Piattaforma (acquisizione, catalogazione, circolazione, gestione delle risorse elettroniche, anagrafiche, ecc.) devono essere integrate fra di loro e con il

discovery tool in uso (Primo)

Lingua

L’interfaccia della Piattaforma deve essere disponibile almeno in lingua italiana (di default) ed inglese, con possibilità di scelta per

l’utente

Autenticazione

La Piattaforma deve essere integrabile con il sistema di

autenticazione adottato dall’Ateneo, attualmente basato su

Shibboleth [IDP 2.4.3]

Manutenzione

La gestione, la manutenzione e lo sviluppo della Piattaforma

devono essere interamente a carico dell’impresa Appaltatrice

Amministratore locale

Deve essere previsto un ruolo di “Amministratore Locale” di Sistema in grado di eseguire autonomamente, senza necessità di intervento da parte dell’Appaltatore, configurazioni e operazioni funzionali all’erogazione ordinaria dei servizi (a titolo esemplificativo e non esaustivo: gestione dell’anagrafica

operatori, spostamenti di dati, ecc.)

Configurazioni

Deve essere possibile variare il numero delle biblioteche, in aumento o in diminuzione, sia creando biblioteche nuove, sia accorpando / scindendo biblioteche esistenti, con contestuale spostamento integrale o parziale di tutti i dati di pertinenza (ordini, fatture, inventari, collocazioni, prestiti, ecc.) anche tramite un

intervento del fornitore.

La Piattaforma deve prevedere la gestione dell’anagrafica degli operatori del back office, associando a ciascuno di essi uno o più profili che ne definiscano il livello di abilitazione sia in funzione dei rispettivi ruoli, sia rispetto alle diverse modalità operative. I profili

dovranno essere personalizzabili fino alla singola funzionalità.

Tali abilitazioni devono poter essere modificabili in qualsiasi

momento a cura dell’Amministratore locale di sistema

Manualistica

Dovranno inoltre essere forniti manuali e documentazione in lingua

italiana relativi a tutte le funzionalità della piattaforma.

B – Gestione delle acquisizioni

Risorse gestite

Il processo di acquisizione deve potersi applicare a tutte le risorse gestite, sia analogiche sia elettroniche, nelle loro varie tipologie (monografie cartacee, e-book, periodici cartacei ed elettronici, opere in continuazione, banche dati, audiovisivi, carte geografiche

e geologiche, spartiti musicali, ecc.)

Iter dell’ordine

La Piattaforma deve gestire l’intero processo di acquisizione delle risorse documentali in tutte le sue fasi: proposte di acquisto, ordine, approvazione dell’ordine, invio dell’ordine, arrivo del materiale, ricezione fattura, caricamento fattura, chiusura ordine, cancellazione, reclami, statistiche, report, ecc.

Tipologie di acquisizione

Devono poter essere gestite almeno le seguenti tipologie di acquisizione: acquisto, dono, scambio, approval plan, passaggio interno (trasferimento di materiale bibliografico da una biblioteca

ad un’altra)

Gestione ordini

L’ordine deve prevedere campi per la registrazione del numero identificativo, codice del budget, numero di copie da ordinare, biblioteca ordinante, fornitore, status dell’ordine, note, commenti. Deve essere possibile la gestione di ordini relativi a singole risorse e a ordini aperti e chiusi. Deve poter essere possibile l’aggiornamento automatico della disponibilità di spesa. Deve essere possibile a più biblioteche gestire ordini per la medesima risorsa, sia creare ordini duplicati inserendo i dati una sola volta. Deve essere possibile la cancellazione delle registrazioni d’ordine, la produzione di liste di

ordini in ritardo e la generazione automatica di lettere di reclamo

Valute

Deve essere possibile gestire i prezzi sia in Euro che in valute estere.

Devono inoltre essere previsti sconti, commissioni ed eventuali imposte (IVA, ecc.)

Pre- catalogazione

Deve essere possibile effettuare la pre-catalogazione dei titoli in ordine, anche con l’acquisizione di record bibliografici provenienti da fonti esterne (SBN, LC, piattaforme di editori, distributori, ecc).

Deve essere possibile la ricerca real-time su piattaforme

elettroniche di distributori e librerie online esterne

Budget

Ogni biblioteca deve poter gestire un proprio budget articolato in voci e sottovoci di spesa, nonché la chiusura dell’anno finanziario. Deve essere possibile la suddivisione delle spese tra più voci e l’aggiornamento automatico della disponibilità finanziaria sulle

singole voci

Anagrafica fornitori

La Piattaforma deve consentire la gestione di un’anagrafica dei fornitori, condivisa tra tutte le biblioteche, con la possibilità di prevedere informazioni a livello di singola biblioteca. L’anagrafica deve prevedere almeno i seguenti campi: ragione sociale, indirizzo, codice fiscale, partita IVA, indirizzo e-mail, referente, codice identificativo attribuito al fornitore dall’Ateneo, sconti applicati, note. Deve poter essere possibile ricercare le informazioni secondo più canali di ricerca, tra i quali almeno la ragione sociale ed il

codice fiscale

Report e statistiche

Tutte le attività di acquisizione devono essere memorizzate e deve essere possibile la produzione di report e statistiche. Lo storico delle informazioni (stato dell’ordine, data, biblioteca, ecc.) deve essere

visualizzabile e filtrabile

EDI

Deve essere supportato l’Electronic Data Interchange (EDI) per le

comunicazioni con i fornitori almeno per i passaggi relativi all’ordine

e alla fattura

Alert

Deve essere prevista la possibilità di alert per la segnalazione di

ordini in ritardo, evasioni parziali, spese superiori alla disponibilità della voce di budget, esaurimento di budget

C - Gestione della catalogazione sia di materiale analogico che digitale

Catalogazione partecipata

La catalogazione deve avvenire in un unico catalogo centralizzato, in cui confluiscano i dati bibliografici di tutte le biblioteche di Ateneo

Materiale

Il Sistema deve gestire la catalogazione ed i record bibliografici relativi a tutte le tipologie di materiale documentale sia cartaceo (libri moderni, libri antichi, periodici), sia elettronico (e-journals, e-

book, banche dati, supporti multimediali)

Template

Deve essere disponibile un editor di catalogazione integrato con definizione di campi, sottocampi e indicatori, la possibilità di aggiungere campi locali e URL nei record.

Per ciascun tipo di documento (ad es. monografia, periodico, video, e-book, opere in più volumi, spogli, ecc.) deve poter essere definito uno o più template (bozze) catalografici specifici condivisi da tutti gli utenti. Inoltre, ciascun utente deve poter salvare dei

template personali.

Set di caratteri

Deve poter essere utilizzato l’intero set di caratteri UNICODE, con la

codifica UTF-8

Standard

Il Sistema deve supportare lo standard di catalogazione UNIMARC

e lo standard MARC-21 con la possibilità di conversione

Gestione dei record

Deve essere possibile duplicare, modificare e cancellare un record bibliografico.

Deve essere possibile gestire record bibliografici visibili solo

nell’interfaccia staff e non visualizzabili nell’interfaccia utente finale

Soggettari e Classificazioni

La Piattaforma deve essere in grado di gestire più soggettari (ad es. il Soggettario di Firenze) e più classificazioni: almeno la Classificazione Decimale Dewey (CDD) e la Classificazione Decimale Universale (CDU) e la Mathematical Subject Classification

(MSC)

Import - export

Deve essere possibile l’importazione e l’esportazione - anche in batch, anche massiva – di record bibliografici UNIMARC, MARC21 (MARC/XML, ISO 0000), Xxxxxx Xxxx, Xxxxxx Core Qualified e RDA. In caso di importazione di record in MARC21 deve essere possibile

la conversione in UNIMARC.

Operazioni massive

Deve essere possibile effettuare operazioni massive di cancellazione, modifica, sostituzione e spostamento di dati, anche

mediante operazioni batch

Catalogazione

derivata

La Piattaforma deve prevedere la catalogazione derivata da

cataloghi esterni con selezione dei campi da importare

Alert

Devono essere previsti strumenti di controllo in fase di inserimento dei dati in modo da impedire errori in fase di catalogazione (alert,

warning, ecc)

Aiuto sui campi

Devono essere disponibili strumenti per guidare l’utente alla

compilazione dei campi (x.xx. help contestuale) in fase di catalogazione

Colloquio SBN

La Piattaforma deve garantire la cooperazione con SBN al livello 4 del colloquio con l’indice. La conformità al protocollo applicativo SBN-MARC deve essere costantemente aggiornata all’ultima versione/release rilasciata dall’ICCU per tutta la durata del

contratto

Controllo URL

Deve essere possibile attivare il controllo periodico della validità degli URL presenti nelle schede bibliografiche e la produzione di

report relativi

RDA

Deve essere prevista l’uscita dei record bibliografici secondo lo

standard RDA (Resource Description and Access)

Interoperabilità

Tutti gli aggiornamenti del catalogo devono essere riportati in Primo

senza l’intervento degli operatori

D- Gestione dei periodici a stampa

Iter dei periodici

La Piattaforma deve gestire l’intero processo di trattamento dei periodici a stampa in tutte le sue fasi: abbonamenti, rinnovi, ordini, cardex elettronico, informazioni sul posseduto, reclami, rilegature,

ecc.

Modelli previsionali

La Piattaforma deve mettere a disposizione dei modelli previsionali di arrivo dei fascicoli, condivisi a livello di sistema, in grado di gestire anche periodicità irregolari e fascicoli non previsti (supplementi,

indici, ecc.)

Controlli

Devono essere disponibili controlli automatici sulla puntualità

dell’arrivo dei fascicoli, con rilevazione dei ritardi e produzione di

solleciti.

Integrazione

La gestione dei periodici deve essere integrata con la catalogazione e con la circolazione. Le informazioni sul posseduto devono essere visualizzate nell’interfaccia utente in formato

riassunto e dettagliato

Rinnovi

Deve essere prevista la rigenerazione automatica dei modelli

previsionali in fase di rinnovo degli abbonamenti

ACNP

Le informazioni bibliografiche sul posseduto dei periodici devono poter essere messe a disposizione nel Catalogo Italiano dei Periodici

ACNP

E – Gestione delle copie e delle raccolte

Dati delle copie

In ciascun record bibliografico deve essere possibile gestire un numero illimitato di copie con almeno i seguenti dati: biblioteca, collocazione, barcode, numero di inventario, data di inventario, prezzo, condizioni di prestabilità, tipo di materiale, note categorizzabili, numero d’ordine, data di creazione, data di

modifica.

Collocazione

Il record di copia deve poter essere gestito con diversi schemi di collocazione (multicodice, formato, classificazione, ecc.) sia inserendo la collocazione manualmente sia ottenendola

automaticamente nel caso di collocazioni sequenziali

Visibilità delle

copie

Deve essere possibile disabilitare la visualizzazione delle copie

(sia singole copie che blocchi di copie) in Primo

Operazioni massive

Deve essere possibile effettuare modifiche ai dati di copia mediante operazioni massive effettuabili direttamente dai

bibliotecari o almeno dall’amministratore del sistema locale

Scarto

Devono essere disponibili funzionalità per procedere allo scarto

o alla cancellazione individuale e/o massiva delle copie

Spostamento dati

Deve essere possibile spostare e/o accorpare alcuni o tutti i dati gestionali (copie, ordini, piani previsionali, ecc.) da un record

bibliografico ad un altro

Modifiche

Deve essere possibile effettuare modifiche ai dati di copia al

momento del prestito o della restituzione

Lettura ottica e RFID

Deve essere possibile gestire le copie con sistemi di lettura ottica (barcode) e tramite tecnologia RFID. I sistemi RFID devono supportare il protocollo SIP2 (ed eventuali evoluzioni future) e

devono essere integrati nella Piattaforma.

Ricognizione con

RFID

Deve essere possibile effettuare la ricognizione inventariale a

scaffale tramite la tecnologia RFID

Stampa etichette

Il sistema deve prevedere funzioni di stampa per le etichette relative alle copie, compatibili con i servizi di stampa in uso in Ateneo descritti nell’allegato A o, in alternativa, con funzionalità interne che garantiscano il medesimo risultato, in particolare i

punti al paragrafo 2 dell’Allegato stesso.

Altre funzioni

La Piattaforma deve poter gestire almeno le funzionalità di:

disponibilità al prestito, acquisizione, rilegatura, fascicolazione, smarrimento, inutilizzabilità

F – Gestione della circolazione

Tipologie di circolazione

La Piattaforma deve consentire la gestione delle seguenti tipologie di circolazione:

• Consultazione

• Prestito locale

• Prestito interbibliotecario (ILL), cioè con biblioteche

esterne all’Ateneo

• Document Delivery (DD)

Tutte le transazioni della circolazione devono essere tracciate in ogni loro passaggio

Politiche di circolazione

La Piattaforma deve poter gestire politiche di circolazione differenziate almeno in base ai seguenti parametri:

• Tipologie di utenti

• Tipologie di materiale (ad es. monografia, audiovisivo, etc.)

• Tipologie di circolazione (ad es. copia ammessa alla consultazione ma non al prestito, copia ammessa al prestito locale ma non all’ILL, ecc.)

• Collocazione

• Biblioteca

Personalizzazione

Le politiche di circolazione devono essere personalizzabili a livello di biblioteca. Il bibliotecario deve essere in grado di

modificare i singoli parametri.

Eccezioni e

storico

Deve essere possibile applicare delle eccezioni alle politiche di

circolazione per gestire casi particolari.

Deve essere possibile configurare rinnovi automatici parametrizzabili (ad es. tipologie di copia, utente, biblioteca, etc.)

Deve essere presente il log delle operazioni di circolazione svolte

sia relativo al singolo utente sia alla singola copia

Prenotazioni

La Piattaforma deve gestire le richieste di prestito sia relative alle copie disponibili sia alle copie in prestito, con la creazione di code di prenotazione e notifiche di disponibilità delle copie

prenotate

Controlli e solleciti

La Piattaforma deve gestire il controllo delle scadenze dei prestiti e l’invio di preavvisi di scadenza e solleciti automatici e secondo tempistiche configurabili dall’amministratore a livello di

biblioteca

Comunicazioni

Deve essere possibile inviare comunicazioni automatiche agli utenti (preavvisi di scadenza, solleciti, ecc.) almeno via e-mail. Tali comunicazioni devono poter essere impostate in batch con frequenza configurabile. I testi devono essere personalizzabili.

Deve essere possibile consultare il log degli invii

Sanzioni

Il sistema deve prevedere la gestione delle sanzioni e delle

sospensioni dai servizi a carico dell’utente

RFID

La Piattaforma deve poter essere integrata con sistemi a tecnologia RFID, in grado di supportare almeno il protocollo SIP2 (ed eventuali evoluzioni future), al fine di consentire la registrazione automatica dei prestiti sia tramite operatore, sia tramite apparecchiature self-check.

In particolare, deve garantire il funzionamento di almeno n. 3

stazioni self-check.

Integrazione

Il sistema deve interagire con Primo per la conferma dei dati

personali, l’accettazione e la gestione delle prenotazioni on-line, dei rinnovi e delle richieste ILL (creazione, cancellazione)

Calendario

La Piattaforma deve consentire a ogni biblioteca di gestire un

proprio calendario delle giornate di apertura/chiusura, con effetto sul calcolo della scadenza dei prestiti

Prestito off-line

Deve essere possibile una modalità di gestione del prestito off-

line quando il collegamento on-line sia temporaneamente

		indisponibile e una procedura di riallineamento quando il collegamento viene ripristinato
13	Rinnovo in blocco	La Piattaforma deve prevedere la possibilità di rinnovare in blocco i prestiti secondo parametri stabiliti dalla biblioteca
14	NILDE	La Piattaforma deve permettere l’integrazione la piattaforma di gestione di document delivery NILDE
15	ISO-ILL e ILL-SBN	La piattaforma deve consentire l’integrazione con il protocollo standard ISO-ILL (ISO 10160, ISO 10161) e con il sistema SBN-ILL

G – Gestione integrata delle risorse elettroniche in un unico flusso di lavoro

Iter delle risorse elettroniche

Al fine della gestione delle risorse elettroniche,

la Piattaforma deve disporre di almeno le seguenti funzionalità: selezione, trial, acquisizione, sottoscrizione, licenze, attivazione, manutenzione, valutazione e monitoraggio dell’uso, rinnovo, cancellazione.

Licenze

La Piattaforma deve mettere a disposizione un database comprensivo delle licenze d’uso delle risorse elettroniche sottoscritte.

Deve essere possibile caricare nel sistema i contratti di licenza

delle risorse elettroniche sottoscritte dall’Ateneo e collegarli ai

relativi record

Knowledge base

La Piattaforma deve disporre di una Knowledge Base, gestita dall’Appaltatore, comprensiva di risorse elettroniche di tutte le tipologie, relativi metadati e servizi per il loro utilizzo, all’interno della quale possano essere identificate ed attivate le risorse sottoscritte dall’Ateneo, indipendentemente dalle piattaforme di accesso prescelte e dagli accordi commerciali stipulati.

L’attivazione di una risorsa nella Knowledge Base deve tradursi

nella disponibilità della risorsa in Primo entro 24 ore

Record locali

La Piattaforma deve consentire la gestione di risorse non presenti nella Knowledge Base, dando la possibilità di aggiungere ed aggiornare record locali aventi la medesima struttura di quelli

presenti nella Knowledge Base

Link Resolver

La Piattaforma deve fornire un link resolver, basato sullo standard OpenUrl (ANSI-NISO Z39.88-2004, OpenURL 1.0), integrato. Il link

resolver deve usare i dati presenti nella Knowledge Base per

creare collegamenti alle risorse elettroniche accessibili agli utenti e ai servizi ad esse collegati, in particolare i link ai full-text

appropriati in base agli abbonamenti sottoscritti dall’Ateneo

Proxy

Deve essere possibile l’accesso alle risorse elettroniche dall’esterno della rete di Ateneo, a partire dall’Interfaccia Utente, utilizzando il Proxy server in uso presso il Politecnico

(EZproxy).

Liste A-Z

La Piattaforma deve consentire, a partire dalla Knowledge Base, la creazione di lista a-z di periodici elettronici, banche dati ed e- book ordinabili almeno per titolo. Tali liste devono poter essere

pubblicate, consultabili e ricercabili in Primo

Statistiche utilizzo delle risorse elettroniche

Deve essere possibile il download/caricamento automatico dei file degli editori contenenti i dati statistici sull’uso delle risorse elettroniche (in formato COUNTER e SUSHI nelle versioni più

aggiornate)

Sovrapposizione

delle risorse

La Piattaforma deve offrire la possibilità di eseguire in autonomia

l’analisi di sovrapposizione delle risorse

H – Anagrafica Utenti delle biblioteche

Gestione utenti

La Piattaforma deve permettere la gestione autonoma degli utenti in termini di inserimento, cancellazione e modifica delle anagrafiche.

Tutte le operazioni devono essere effettuabili

tramite API o tramite interfaccia web

Dati anagrafici

La Piattaforma deve gestire almeno i seguenti dati anagrafici minimi: tipologia di utente (docente, studente, esterno), cognome, nome, codice fiscale, data e luogo di nascita, sesso, cittadinanza, lingua, indirizzi di residenza e domicilio, numeri di telefono, indirizzi e-mail, numero di matricola (per gli utenti istituzionali), status utente (studente, laureando, dottorando,

ecc.).

Configurazione biblioteche

La Piattaforma, in fase di caricamento o modifica tramite API, deve permettere per ciascuno degli utenti l’assegnazione dei

privilegi per ciascuna delle biblioteche di ateneo.

ID utente

La Piattaforma deve permettere la definizione di più campi chiave (almeno 10) con cui identificare univocamente gli utenti (x.xx. codice fiscale, matricola, email, …)

Controlli

La Piattaforma deve permettere di inibire l’accesso al servizio di prestito agli utenti in posizione irregolare (ad es. ritardo nella restituzione, illeciti, sanzioni, ecc.).

Deve essere possibile applicare eccezioni da parte

dell’operatore.

Estrazione dati

Deve essere possibile la creazione di report con dati

anonimizzati.

I – Funzione di ricerca all’interno del gestionale

Tipologie di ricerca

Deve essere possibile effettuare ricerche all’interno del gestionale (ricerca semplice e avanzata) almeno nei seguenti ambiti: descrizione bibliografica, anagrafiche, acquisizioni, circolazione,

copie

Salvataggio

query e set

Deve essere possibile il salvataggio di modelli di query e set di

risultati da riutilizzare

Filtri

Deve essere possibile filtrare i risultati tramite l’utilizzo di faccette

personalizzabili

Campi di ricerca

Deve essere possibile la ricerca di record bibliografici per parole e scorrimento almeno per titolo, autore, collana, ISBN, ISSN,

collocazione

Indici

La Piattaforma deve permettere la definizione degli indici di ricerca da parte degli Amministratori del Sistema. I dati degli indici devono essere estraibili da tutti i campi UNIMARC bibliografici e

dai campi delle copie

L – Interoperabilità con il Discovery Tool già in uso

Esportazione dati

Deve essere possibile l’esportazione dei dati (dati bibliografici, di

copia e relativi alle risorse elettroniche) verso Primo

Integrazione dati profilo utente

La Piattaforma deve essere totalmente integrata con il discovery tool Primo, in particolare, l’utente deve poter utilizzare l’interfaccia

Primo per tutte le operazioni (prenotazioni, visualizzazione dello

stato utente, visualizzazione dei prestiti, rinnovi, comunicazioni

della biblioteca, richieste ILL, ecc.)

Real-time availability

Deve essere possibile presentare in tempo reale e direttamente

nell’interfaccia di Primo lo stato di prestabilità del materiale cartaceo

OpenURL

La Piattaforma deve supportare le chiamate OpenURL provenienti

da Primo SRU

Supporto EZproxy

La Piattaforma deve supportare l’utilizzo del software “EZproxy”

(OCLC) che permette la consultazione delle risorse elettroniche da fuori Ateneo

M- Gestione della reportistica

Report, grafici e statistiche

Devono essere disponibili report, grafici e statistiche specifici. Deve essere possibile estrarre, sia a livello di Sistema che di singola biblioteca:

- Report e statistiche su ordini, fatture, budget e tipologia di acquisizioni

- Cataloghi e bollettini bibliografici

- Report sullo stato dei fascicoli di periodici a stampa, sui fascicoli doppi e su quelli da rilegare

- Registri topografici

- Report e statistiche sulla circolazione delle copie (lista delle copie per ciascun tipo di movimento, movimenti per ciascuna copia, prestiti scaduti, copie non prestate, ritardi nella restituzione, ecc.)

- Statistiche sull’attività catalografica (record creati ex- novo, record modificati, record per tipologia, ecc)

- Statistiche sull’utilizzo delle risorse elettroniche (numero di download per risorsa e/o totali, numero di ricerche per risorsa e/o totali, numero di e-journal, e-book, banche dati, sia in Open Access che in abbonamento, ecc)

- Statistiche sulle attività svolte dagli operatori, anche ripartite per ambito di attività (catalogazione, acquisizione, ecc.)

Personalizzazione dei report

Deve essere possibile creare e personalizzare, sia a livello centrale che da parte delle singole biblioteche, report e statistiche che consentano di elaborare e incrociare fra loro le diverse tipologie di dati presenti nella Piattaforma, anche tramite schedulazione

periodica.

Export dei dati

Deve essere possibile esportare i report e le statistiche in vari

formati (xls, csv, xml, etc.).

N – Ambiente di test e pre-produzione

Ambiente di test

Accanto all’ambiente di esercizio la Piattaforma deve rendere disponibile un ambiente di test con caratteristiche analoghe all’ambiente di esercizio, sul quale poter effettuare prove e simulazioni (anche massive) da parte di utenti autorizzati.

L’ambiente di test deve essere messo a disposizione da parte dell’Appaltatore almeno 6 mesi prima dell’entrata in esercizio della Piattaforma e deve essere disponibile 24/24 7/7.

L’ambiente di test deve restare disponibile, attivo ed utilizzabile

per tutta la durata del contratto

Inserimento dati

L’inserimento iniziale dei dati deve essere interamente a carico

dell’appaltatore.

Collegamento

con il Discovery Tool

L’ambiente di test deve poter interagire con la versione di test di Xxxxx, in modo tale da poter verificare le operatività illustrate alla

lettera “L” della presente tabella.

Autenticazione

L’ambiente di test deve supportare l’autenticazione di Ateneo

Test per nuove release

Deve essere reso disponibile un ambiente di preproduzione atto a ospitare le nuove release del software con almeno 2 settimane di anticipo rispetto alla data di rilascio definitivo delle release stesse.

Può essere anche l’ambiente stesso di test.

O - Assistenza e SLA (Service Level Agreement)

Manutenzione evolutiva

Deve essere presentata e mantenuta aggiornata la roadmap dei prodotti previsti in sviluppo.

Ogni rilascio dovrà prevedere una “release note” relativa alle

funzionalità corrette e/o aggiuntive

SLA Minimi

Disservizio	Tempo minimo di presa in carico	Tempo minimo di risoluzione
Il sistema non permette erogazione della totalità dei servizi	4 ore	24 ore
Il sistema non permette erogazione di un servizio alla totalità delle utenze	8 ore	48 ore
Il sistema risulta funzionante parzialmente, ma garantisce i servizi essenziali e/o con livelli di performance degradati	16 ore	96 ore
Il sistema è funzionante ma risultano attive segnalazioni che necessitano della presa in carico. Tale problema ha impatto limitato sul sistema e le ordinarie attività operative possono procedere.	48 ore	Non definito
Richieste di miglioramento	48 ore	Non definito

SEZIONE III – CRITERIO DI AGGIUDICAZIONE

L'appalto di cui al presente CSO sarà aggiudicato secondo il criterio dell'offerta economicamente più vantaggiosa individuata sulla base del miglior rapporto qualità/prezzo, ai sensi dell’art. 95, comma 2 del D.Lgs. 50/2016.

La valutazione dell’offerta tecnica e dell’offerta economica è effettuata in base ai seguenti

punteggi

PUNTEGGIO MAX

Valutazione Tecnica

80 /100

Valutazione Economica

20 /100

TOTALE

100

Il punteggio dell’offerta tecnica è attribuito sulla base dei criteri di valutazione elencati nella sottostante tabella con la relativa ripartizione dei punteggi.

Nella colonna identificata con la lettera D vengono indicati i “Punteggi discrezionali”, vale a dire i punteggi il cui coefficiente è attribuito in ragione dell’esercizio della discrezionalità spettante alla commissione giudicatrice.

Nella colonna identificata dalla lettera T vengono indicati i “Punteggi tabellari”, vale a dire i punteggi fissi e predefiniti che saranno attribuiti o non attribuiti in ragione dell’offerta o mancata offerta di quanto specificamente richiesto.

Tabella III -1 – Dettaglio valutazione funzionalità aggiuntive

ELEMENTO DI VALUTAZIONE

CRITERIO DI ATTRIBUZIONE

PUNTEGGIO MASSIMO

MODALITA’ DI VALUTAZIONE

D/T

EV1.

Piattaforma messa a disposizione dal fornitore e sue funzionalità

Verranno valutate le funzionalità della piattaforma secondo l’elenco di seguito riportato in ordine di priorità decrescente:

o Possibilità di condivisione di dati di varia natura (bibliografici, authority, commerciali) e configurazioni con altri utilizzatori della medesima Piattaforma

o Attivazione di una risorsa presente nella KB con disponibilità immediata nell’interfaccia per l’utente finale

o Possibilità per il singolo operatore di personalizzare la propria interfaccia di back office tramite la gestione di widget associabili a ciascuna funzionalità.

o Possibilità di aggiornamento automatico del posseduto di e-journals e di e-book (autoload)

o Possibilità di gestione di reading list dei corsi

o Gestione di database di authority e possibilità di importazione da fonti esterne

o Integrazione dei dati del posseduto dei periodici

passati dal formato

Confronto a coppie

cartaceo all’on-line

o Supporto degli Standard KBART e ONIX-PL

EV2. APP

Verranno valutate le funzionalità delle App se disponibili almeno per le piattaforme Android e IOS. Tra le funzionalità verranno valutate:

o Visualizzazione prestiti attivi

o Rinnovo prestiti

o Notifiche push ritardi sui prestiti

o Ricerche su Discovery

o Comunicazioni dalla biblioteca

Confronto a coppie

EV3.

API e integrazione con sistemi terzi

Verranno valutati:

o Possibilità di comunicare con i fornitori attraverso web services o API (ad esempio Gobi, Casalini …)

o Possibilità di interfacciarsi con il sistema informativo integrato per la governance degli Atenei U-GOV

o Possibilità di “Social login” via Facebook e Google da parte degli utenti esterni

o Possibilità di incorporare i

widget anche su altre piattaforme

Confronto a coppie

EV4.

Controllo duplicazioni e report

Verranno valutati:

o Disponibilità di strumenti automatici per prevenire la duplicazione non intenzionale di titoli

o Possibilità di produrre report con filtri per anno, fornitore, tipologia

o Controllo automatico delle collocazioni duplicate

o Sono presenti funzioni di overlap analysis tra pacchetti inclusi nella KB e report caricati dall’esterno provenienti dagli editori

Confronto a coppie

EV5.

Piano di implementazione della Piattaforma, migrazione dei dati

Verranno valutati:

o Progetto organizzativo di migrazione: organizzazione, numero e competenze degli operatori dedicati a queste fasi, esperienza pregressa in progetti analoghi

o Piano di migrazione dei dati: strumenti e procedure utilizzate, interazione con il Team di progetto del committente, tempistiche di completamento delle fasi

Confronto a coppie

EV6.

Servizi gestionali connessi

Verrà valutata l’architettura tecnologica e del servizio in relazione in particolare all’aggiornamento e alla manutenzione dell’infrastruttura, alla sicurezza informatica e al trattamento dei dati (Art. 7 del

Capitolato).

Confronto a coppie

EV7.

Piano di evoluzione della piattaforma

Verrà valutato Il piano di adeguamento della piattaforma affinché questa sia mantenuta costantemente aggiornata all’evoluzione dello scenario tecnologico, al mutamento delle caratteristiche del mercato di riferimento e delle esigenze dell’utente.

Confronto a coppie

EV8.

Formazione

Verranno valutate le modalità con cui il fornitore intende erogare la formazione sia del team di progetto che degli operatori. In particolare, si terrà conto di:

o Numero di ore di formazione erogata

o Modalità di erogazione (in presenza/in remoto)

o Qualità della documentazione e dei manuali

o Disponibilità di rilascio certificazione dopo

esame finale

Confronto a coppie

EV9.

Ambiente di test popolato con i dati del Contraente e aggiornato con frequenza regolare e/o su richiesta

Verrà valutata la disponibilità di utilizzare i dati del contraente per l’ambiente di test

Disponibilità al caricamento iniziale

2 punti

Aggiornamenti almeno annuali 4 punti

Aggiornamenti almeno semestrali

5 punti

EV10.

Numero di Istituzioni Accademiche Italiane che utilizzano la piattaforma

Verrà valutato il numero di Istituzioni Accademiche Italiane che hanno adottato e utilizzano la Piattaforma con tutte le sue funzionalità e moduli

<5: 0 punti

5-6: 1 punti

7-8: 2 punti

9-10: 3 punti

11-12: 4 punti

>12: 5 punti

EV11. SLA

Verrà valutato il miglioramento degli SLA minimi (tempistiche di presa in carico e risoluzione), definiti nell’ambito della tabella O di pag. 40 del presente Capitolato

Riduzione di almeno il 25% dei tempi rispetto agli SLA minimi

2 punti

Riduzione di almeno il 50% dei tempi rispetto agli SLA Minimi

4 punti

1. Metodo di attribuzione del coefficiente per il calcolo del punteggio dell’offerta tecnica

A ciascuno degli elementi qualitativi cui è assegnato un punteggio tabellare (T), il relativo punteggio è assegnato automaticamente in valore assoluto sulla base della presenza o assenza nell’offerta dell’elemento richiesto.

A ciascuno degli elementi qualitativi cui è assegnato un punteggio discrezionale (D), il punteggio è assegnato mediante il criterio del confronto a coppie, in conformità a quanto previsto dalle Linee Guida n. 2 dell’X.X.XX., approvate dal Consiglio dell’Autorità con Delibera n. 1005 del 21 settembre 2016 e aggiornate con Delibera del Consiglio n. 424 del 2 maggio 2018, cui si rinvia.

Il confronto avviene sulla base delle preferenze accordate da ciascun commissario a ciascuna offerta tecnica in confronto con tutte le altre, secondo i criteri contenuti nella precedente Tabella.

2. Descrizione del metodo del confronto a coppie

Ciascun commissario confronta l’offerta di ciascun concorrente indicando quale offerta preferisce e il grado di preferenza, variabile tra 1 e 6 (1 - nessuna preferenza; 2 - preferenza minima; 3 - preferenza piccola; 4 – preferenza media; 5 – preferenza grande; 6 - preferenza massima), eventualmente utilizzando anche valori intermedi.

Viene costruita una matrice con un numero di righe e un numero di colonne pari al numero dei concorrenti meno uno come nell’esempio sottostante, nel quale le lettere individuano i singoli concorrenti; in ciascuna casella viene collocata la lettera corrispondente all’elemento che è stato preferito con il relativo grado di preferenza e, in caso di parità, vengono collocate nella casella le lettere dei due elementi in confronto, assegnando un punto ad entrambe.

Al termine dei confronti si attribuiscono i punteggi sulla base del seguente criterio:

si trasforma, per ciascun commissario, la somma dei coefficienti attribuiti mediante il "confronto a coppie", in coefficienti variabili tra zero e uno e si calcola la media dei coefficienti di ciascun commissario attribuendo uno al concorrente che ha ottenuto il coefficiente medio più alto e agli altri concorrenti un punteggio conseguentemente proporzionale al coefficiente raggiunto;

3. Metodo di attribuzione del coefficiente per il calcolo del punteggio dell’offerta economica

Quanto all’offerta economica, è attribuito all’elemento economico un coefficiente, variabile da

zero ad uno, calcolato tramite la formula bilineare

𝐶𝑖 = 𝑋 ∗ (𝐴

𝐴𝑖

𝑠𝑜𝑔𝑙𝑖𝑎

) 𝐴𝑖 ≤ 𝐴𝑠𝑜𝑔𝑙𝑖𝑎

𝐶𝑖

{

(𝐴𝑖 − 𝐴𝑠𝑜𝑔𝑙𝑖𝑎)

= 𝑋 + (1 − 𝑋) ∗ [ ] 𝐴𝑖

𝐴𝑚𝑎𝑥 − 𝐴𝑠𝑜𝑔𝑙𝑖𝑎

> 𝐴

𝑠𝑜𝑔𝑙𝑖𝑎

dove

Ci = coefficiente attribuito al concorrente i-esimo Ai = ribasso percentuale del concorrente i-esimo

Asoglia = media percentuale dei valori del ribasso percentuale offerto dai concorrenti Amax = valore del ribasso più conveniente

X = 0,90

Il coefficiente assegnato per il calcolo del punteggio economico verrà troncato alla seconda cifra decimale senza arrotondamento. Il punteggio economico ottenuto verrà parimenti troncato alla seconda cifra decimale senza arrotondamento.

4. Metodo per il calcolo dei punteggi

La commissione, terminata l’attribuzione dei coefficienti agli elementi qualitativi e quantitativi, procede, in relazione a ciascuna offerta, all’attribuzione dei punteggi per ogni singolo criterio secondo il metodo aggregativo compensatore. Il punteggio per il concorrente i-esimo è dato dalla seguente formula

𝑛

𝑃𝑖 = ∑ 𝐶𝑥𝑖 ∗ 𝑃𝑥

𝑥=1

dove

𝑃i = punteggio del concorrente i-esimo

𝐶xi = coefficiente criterio di valutazione X per il concorrente i-esimo

𝑃x = punteggio criterio X

X = numero totale dei requisiti

La scelta è ricaduta sul metodo aggregativo compensatore in quanto, la presenza di un elevato numero di requisiti tecnici minimi previsti alla Sezione II del presente capitolato, della riparametrazione dell’offerta tecnica e dell’applicazione della formula di interpolazione bilineare per la valutazione dell’offerta economica, mitiga il rischio delle distorsioni connesse all’applicazione di tale metodo (cfr. Linee Guida n. 2, di attuazione del D.lgs. 18 aprile 2016, n. 50, recanti “Offerta economicamente più vantaggiosa”).

5. Riparametrazione Punteggi Tecnici

Al fine di non alterare i pesi stabiliti tra i vari criteri, se nel punteggio per l’offerta tecnica complessiva nessun concorrente ottiene il punteggio massimo, tale punteggio verrà riparametrato attribuendo all’offerta del concorrente che ha ottenuto il punteggio complessivo più alto per l’offerta tecnica il punteggio massimo previsto e alle offerte degli altri concorrenti un punteggio proporzionale decrescente.

Allegato A – ATTUALE GESTIONE STAMPA ETICHETTE

1. ATTUALE GESTIONE STAMPA ETICHETTE

L’attuale sistema informativo (Aleph) permette di stampare direttamente dal client sulle stampanti di rete specifiche destinate alle etichette, installate nelle biblioteche Centrali. I client non utilizzano il driver di Windows. e sfruttano una configurazione particolare di Aleph (stampante virtuale) che permette di simulare una stampa salvando di fatto un file XML sul server Aleph. È stata sviluppata al nostro interno una procedura che

• intercetta i singoli file generati da Aleph

• estrae i dati salienti da inserire nell’etichetta

• genera un file PDF, formattato in base alla tipologia di collocazione

• a seconda del client che ha effettuato la richiesta, indirizza la stampa sulla stampante configurata

2. PUNTI DI FORZA

Considerato il gran numero di formati di etichetta e di tipologie di collocazioni differenti, questa gestione ha i seguenti punti di forza:

• l’analisi del file XML permette di scegliere il formato di etichetta più consono, in base alla biblioteca e al tipo di collocazione

• la generazione dei file PDF disaccoppia di fatto la generazione dell’etichetta dal tipo di

stampante, avendo semplicemente il driver della stampante attivo sul server di stampa

• si evita di dover configurare le stampanti sui singoli PC. Una semplice configurazione del client aleph permette di indirizzare l’etichetta verso la stampante corretta.

• la stampa avviene partendo dal client Aleph, senza dover utilizzare software di terze parti.

3. POSSIBILE SOLUZIONE PER SISTEMA IN SAAS

Riteniamo necessario mantenere questo metodo di stampa, che sarebbe possibile tramite la messa a disposizione da parte dell’Aggiudicatario di una interfaccia interrogabile mediante API REST o in modalità push. In questo modo si catturerebbe la coda di stampa delle etichette processabile dalla nostra applicazione come attualmente in uso.

Document Metadata

Table of Contents

CAPITOLATO SPECIALE D’ONERI

Document Metadata