Servizi di Fleet Management

Capitolato Tecnico

INDICE

1. Premessa 4

2. Contesto 4

2.1. Contesto organizzativo 4

2.2. Contesto tecnologico 5

2.3. Tipologie di utenza 6

3. Definizione dell’appalto 7

3.1. Definizioni e acronimi 7

3.1.1. Definizioni 7

3.1.2. Acronimi 8

3.2. Oggetto 9

3.2.1. Anagrafica dei servizi oggetto dell’appalto 9

3.3. Durata delle attività 11

3.4. Criteri di valutazione tecnica 11

4. Descrizione dell’appalto 12

4.1. SO – Servizi organizzativi 12

4.1.1. XX.XX – Sistemi di supporto 12

4.1.2. SO.AP – Attività progettuali 22

4.2. GP – Gestione della PdL 27

4.2.1. Condizioni generali 27

4.2.2. XX.XX – Asset management 28

4.2.3. GP.RM – Gestione remota della PdL 29

4.2.4. XX.XX – Gestione in locale della PdL 37

4.2.5. XX.XX – Servizi di back office 46

4.3. LO – Locazione operativa 48

4.3.1. Condizioni generali 48

4.3.2. LO.UC – Locazione operativa Unità Centrale 52

4.3.3. LO.PP – Locazione operativa Unità Periferica Personale 59

4.3.4. XX.XX – Locazione operativa Unità Periferica di Workgroup 67

4.4. RI – Riscatto da locazione operativa 69

4.4.1. Condizioni generali 69

4.4.2. RI.UC – Riscatto Unità Centrale 70

4.4.3. RI.PP – Riscatto Unità Periferica Personale 71

4.4.4. XX.XX – Riscatto Unità Periferica di Workgroup 72

4.5. MH – Manutenzione HW 72

4.5.1. Condizioni generali 72

4.5.2. MH.LO – Manutenzione HW da Locazione Operativa 73

4.5.3. XX.XX – Manutenzione HW di Proprietà 75

4.6. RT – Xxxxxx XXXX 76

4.6.1. Condizioni generali 76

4.6.2. RT.UC – Ritiro RAEE Unità Centrale 77

4.6.3. RT.PP – Ritiro RAEE Unità Periferica Personale 78

4.6.4. XX.XX – Ritiro RAEE Unità Periferica di Workgroup 78

5. Piano di attivazione dei servizi richiesti 78

5.1. Approccio complessivo 79

5.2. Pianificazione temporale di riferimento 79

5.3. Numerosità e distribuzione di riferimento 80

6. Sistema di qualità 81

6.1. Piano di Qualità 82

6.2. Indicatori di Qualità 82

6.2.1. Revisione degli Indicatori di Qualità 84

6.3. Service Level Agreement 85

6.4. Penali 94

7. Appendici 99

7.1. Censimento HW di Proprietà 99

7.1.1. Unità Centrali di proprietà 99

7.1.2. Unità Periferiche Personali di proprietà 99

7.1.3. Unità Periferiche di Workgroup di proprietà 101

1. Premessa

Il presente documento rappresenta il Capitolato Tecnico, parte della documentazione ufficiale, della gara comunitaria a procedura aperta, indetta dal Centro InfoSapienza dell’Università “La Sapienza” di Roma (nel seguito indicata con i termini Università e Ateneo o più semplicemente la “Sapienza”), per servizi di Fleet Management nel periodo 2013-2016.

Tale documento descrive tutti gli aspetti tecnici dell’appalto, in termini di oggetto dell’appalto, di requisiti e condizioni espresse dall’Università in relazione all’oggetto ed alla modalità di esecuzione, di tutte le informazioni ritenute utili per il Fornitore affinché possa formulare l’offerta più congrua e conveniente ed infine in termini di criteri di valutazione tecnica ed economica che verranno applicati in fase di valutazione dell’offerta del Fornitore.

2. Contesto

Il seguente capitolo sintetizza i principali fattori che caratterizzano sia l’Università “La Sapienza” di Roma nel suo complesso, che più in particolare il contesto organizzativo e tecnologico all’interno del quale vengono definiti ed erogati i servizi di Fleet Management oggetto della presente gara.

2.1. Contesto organizzativo

Con oltre 700 anni di storia, 145.000 studenti e 10.000 dipendenti tra professori, impiegati e tecnici, la Sapienza è la più grande università in Europa. La sua missione è contribuire allo sviluppo della società della conoscenza attraverso la ricerca, la formazione di eccellenza e di qualità e la cooperazione internazionale.

Da un punto di vista organizzativo, l’Amministrazione Centrale racchiude gli uffici amministrativi dell’Ateneo, i quali sono articolati in base a specifiche competenze, organizzati per aree omogenee.

Come parte delle funzioni amministrative centrali, lo Statuto istituisce il Centro InfoSapienza quale centro di spesa ad ordinamento speciale, di programmazione e di sviluppo tecnologico, finalizzato al supporto della Information Communication Technology dell’Università.

Il Centro InfoSapienza si occupa della progettazione e gestione dei servizi informativi indispensabili alla ricerca, alla didattica e alle attività organizzativo-gestionali e costituisce, per l’Ateneo, il centro di competenze di riferimento per la predisposizione di soluzioni innovative inerenti l’elaborazione e la disseminazione dell’informazione elettronica.

In particolare il Centro InfoSapienza gestisce:

• le reti di comunicazione telematica e wireless gratuita per gli studenti e il personale, la fonia e il sistema informativo integrato della Sapienza per la gestione dei dati;

• il portale di Sapienza, i servizi web e i sistemi con autenticazione centralizzata, la posta elettronica per gli studenti e il personale;

• le applicazioni centralizzate di supporto per le attività amministrative di gestione della didattica, della carriera degli studenti, delle risorse universitarie;

• il servizio di hosting e housing per strutture centrali e decentrate.

Il particolare, all’interno dell’Ufficio Gestioni Sistemi, opera il Settore per i Sistemi Centrali e per l’office automation. Tale settore, fra le varie finalità, ha anche il compito di:

• aggiornare, gestire ed ottimizzare i sistemi di elaborazione del Centro;

• coordinare le attività per il controllo e la gestione centralizzata delle postazioni di lavoro dell'Amministrazione Centrale.

In tale quadro, il Centro InfoSapienza, ed in particolare il suddetto settore, è pertanto responsabile della definizione e della erogazione dei servizi di Fleet Management per l’Amministrazione Centrale dell’Ateneo.

Allo stato attuale l’Amministrazione Centrale è costituita da circa 900 unità di personale, di cui circa 90 unità sono in forza al Centro InfoSapienza, ed è dotata di circa 1040 postazioni di lavoro.

L’Amministrazione Centrale è distribuita geograficamente su più sedi, sia all’interno del territorio metropolitano della città di Roma, che in sedi periferiche fuori dal comune di Roma. In particolare, ad oggi i servizi di Fleet Management vengono erogati presso postazioni/utenti allocati in sette sedi, indicate in Tabella 1.

Sede	Città	Indirizzo	Postazioni allocate
Città Universitaria	Xxxx	Xxxxxxxx Xxxx Xxxx, 0 – 00185	940
Xxxxxx Xxxxxxxxxxx	Xxxx	Xxx xxx Xxxxxx Xxxxxxxxxxx, 0 – 00161	20
Xxx Xxxxxxx	Xxxx	Xxx xxx Xxxxx, 00/00 – 00185	20
Xxxxxxx Xxxxxxx	Xxxx	Xxxxx Xxxxxxxx Xxxxxxxx XX, 000 – 00186	20
Xx-Xxxxxxx Xxxx	Xxxx	Xxx Xxxxxxxx Xxxxxx, 000 – 00185	15
Xxxxxxxxxxx	Xxxx	Xxxxx xxx Xxxxxxxxxxx, 000 – 00161	10
Xxxxxx	Xxxxxx	Xxxxx XXXX Xxxxxx, 0 – 00142	15

Tabella 1 – Sedi dell’Ateneo interessate dai servizi di Fleet Management

In proiezione futura, l’Amministrazione Centrale potrebbe realizzare differenti dislocazioni di unità organizzative; sono pertanto da considerarsi in ambito alla presente gara ed in onere alla copertura territoriale garantita dal Fornitore anche ulteriori sedi presenti sul territorio metropolitano della città di Roma, benché si possa assumere per una quota sempre a bassa incidenza rispetto al parco complessivo da gestire.

2.2. Contesto tecnologico

Come menzionato nel paragrafo precedente, il Centro InfoSapienza è un dipartimento di Information e Communication Technology per l’Università, in particolare a favore dell’Amministrazione Centrale, verso cui offre tutte i servizi informatici necessari per il funzionamento, il controllo e l’evoluzione (digitale) delle attività tecnico-amministrative.

In relazione a quanto caratterizza il contesto tecnologico incidente sui servizi di Fleet Management, il Centro InfoSapienza è attualmente dotato di e/o gestisce:

• due data center, dislocati all’interno della Città Universitaria, all’interno dei quali mantiene in esercizio i sistemi centralizzati di gestione IT, i servizi applicativi centrali, i servizi in hosting e gli elementi topologici cardine della connettività interna (centri stella, backbone) e esterna (connessione alle reti GARR ed ai principali operatori nazionali di telecomunicazione), sia wired che wireless;

• sistemi centralizzati di gestione IT (già menzionati al precedente punto), fra cui i sistemi di supporto specifici per i servizi di Fleet Management così come descritti nel capitolo 4.1.1 (a cui si rimanda per ulteriori informazioni sul contesto tecnologico), nonché i sistemi ausiliari legati alle comunicazioni in rete, quali servizi DNS e DHCP, firewall, internet proxy, captive portal, ecc.;

• postazioni di lavoro con dotazioni hardware e software. In particolare:

o Il parco hardware attuale comprende:

▪ personal computer x86 di tipo desktop di fascia media o di fascia alta;

▪ personal computer x86 di tipo thin client;

▪ notebook x86 di fascia professionale;

▪ stampanti personali di varia tecnologia: a getto di inchiostro, laser, termiche;

▪ stampanti dipartimentali laser;

▪ altre periferiche ad usi peculiari (es. stampanti a matrice, lettori di smart card) in esigua numerosità.

Si rimanda al capitolo 7.1 per maggiori informazioni sul parco macchine attuale, pur precisando, come più approfonditamente espresso nel corso del presente documento, che il quadro ivi rappresentato non è assolutamente vincolante rispetto alle dotazioni e le strategie che il Centro InfoSapienza vorrà realizzare per i servizi di Fleet Management oggetto di gara.

o Il parco software attuale comprende in generale:

▪ sistemi operativi Microsoft Windows (XP / 2000 / Vista / Seven);

▪ suite di produttività personale Microsoft Office 2003 / 2007 / 2010;

▪ client di posta elettronica Microsoft Outlook 2003 / 2007 / 2010;

▪ web browser Microsoft Internet Explorer 7 / 8 / 9 o open-source freeware (es. Google Chrome, Mozilla Firefox)

▪ client anti-virus Microsoft Forefront;

▪ driver di periferiche (si veda il parco hardware sopra illustrato) e utility;

▪ altri prodotti ad usi peculiari (es. AutoCAD) in esigua numerosità.

• una rete di connettività, costituita in particolare da:

o una rete dedicata all’Amministrazione Centrale, comprendente:

▪ VLAN diverse per strutture (con indirizzamento IP privato);

▪ routing interno L3

▪ protezione con firewall e servizio NAT;

▪ un’area DMZ per i servizi esposti e accessibili da Internet (con indirizzamento IP pubblico);

▪ una seconda area DMZ per le connessioni di reti non interne ma trusted (compresa la rete Wi-Fi per gli studenti)

▪ una rete wireless protetta da un captive portal;

▪ servizio VPN (verso postazioni con indirizzo IP pubblico) per strutture fuori dal perimetro fisico dell’Amministrazione Centrale/Città Universitaria, ma afferenti comunque l’Amministrazione stessa (ad esempio, per le postazioni presso le sedi Palazzo Baleani e Policlinico menzionate in Tabella 1);

o un back-bone comprendente:

▪ routing tra reti di diverse sedi;

▪ firewall di frontiera;

▪ la connessione verso la rete GARR – INTERNET;

▪ il servizio DNS;

▪ una rete di servizio per hosting e housing.

2.3. Tipologie di utenza

Allo stato attuale si possono identificare tre tipologie di utenza/profili di attività, che si caratterizzano per la necessità di postazioni di lavoro e relativi servizi di supporto parzialmente diversificati (si rimanda al paragrafo 3.1.1 per la definizione di Postazione di Lavoro):

• Postazioni per operatori tecnico-amministrativi:

Sono le postazioni ordinarie dedicate agli operatori dell’Amministrazione Centrale, per attività tecnico- amministrative.

Rappresentano la frazione più consistente (indicativamente il 85%) dell’intero parco da gestire, nella quasi totalità costituite da postazioni desktop, standardizzate (come dotazione hardware e software) per macro-tipologie di funzioni tecnico-amministrative, salvo gruppi limitati di utenti con attività specializzate (es. Ufficio Tecnico) e necessità di dotazioni evolute (es. per prestazioni grafiche).

Richiedono un supporto completo sulle diverse e mutevoli casistiche di problematiche che possono interessare la postazione di lavoro.

• Postazioni per i servizi di front office verso gli studenti:

Sono le postazioni predisposte specificatamente per attività di sportello nelle diverse strutture di segreteria, tutoraggio e orientamento.

Rappresentano una frazione ridotta (indicativamente il 10%) dell’intero parco da gestire, totalmente di tipo desktop, standardizzate (come dotazione hardware e software) per macro-tipologie di servizio, ma con esigenze fortemente semplificate rispetto alle postazioni ordinarie. Richiedono un supporto tipicamente limitato alle più comuni casistiche di problematiche che possono interessare la postazione di lavoro semplificata.

• Postazioni per operatori informatici:

Sono le postazioni ordinarie o ausiliarie dedicate agli operatori del Centro InfoSapienza, per le attività di gestione informatica.

Rappresentano una frazione minimale (indicativamente il 5%) dell’intero parco da gestire, di tipo sia fisso che mobile (desktop/notebook), specializzate (come dotazione hardware e/o software) per le peculiari attività di natura tecnico-informatica e con la necessità di dotazioni complesse/evolute (es. per prestazioni computazionali). Dato il profilo degli utenti, richiedono un supporto ridotto e limitato alle casistiche di problematiche più specifiche (soprattutto relative all’hardware) che possono interessare la postazione di lavoro.

3. Definizione dell’appalto

3.1. Definizioni e acronimi

3.1.1. Definizioni

Postazione di Lavoro: Insieme di dotazioni hardware e software che costituiscono

l’ambiente di lavoro informatizzato personale e gli strumenti di produttività informatica individuale assegnate a ciascun un’utente. La Postazione di Lavoro rappresenta l’entità fondamentale destinataria dei servizi di Fleet Management oggetto dell’appalto. Ogni Postazione di Lavoro è caratterizzata da una e una sola Unità Centrale.

Unità Centrale: Singola apparecchiatura hardware, dotata del necessario software opportunamente installato e configurato, in grado di fornire capacità di elaborazione dati autonoma ad un utente / Postazione di Lavoro e più in generale l’accesso a tutte le funzionalità informatiche che fanno parte della Postazione di Lavoro ed alle Unità Periferiche Personali e Unità Periferiche di Workgroup disponibili per la Postazione di Lavoro. Sono esempi di Unità Centrale i personal computer desktop, i personal computer thin client, i notebook, i tablet. Ove applicabile, fanno parte dell’Unità Centrale anche le componenti esterne costituite dalla tastiera, dal mouse e/o da altri analoghi dispositivi di puntamento (es. touchpad).

Unità Periferica Personale: Singola apparecchiatura hardware, dotata del necessario software

opportunamente installato e configurato, che fornisce funzionalità ausiliari di gestione dell’input e dell’output di dati di una o più Postazioni di Lavoro, in locale oppure in rete. Sono esempi di Unità Periferica Personale i monitor, le stampanti personali semplici e

multi-funzione, le stampanti personali di etichette, gli scanner, i lettori di smart card.

Unità Periferica di Workgroup: Rappresenta una singola apparecchiatura hardware, dotata del

necessario software opportunamente installato e configurato, che fornisce funzionalità ausiliari di gestione dell’input e dell’output di dati di norma per un insieme consistente di Postazioni di Xxxxxx (non escludendo tuttavia che l’uso possa essere limitato ad un numero ristretto di Postazioni di Lavoro). Sono esempi di Unità Periferica Personale le stampanti di workgroup (dette anche dipartimentali) semplici e multi-funzione, le stampanti a matrice, i plotter.

Hardware da Locazione Operativa: Rappresenta ogni unità hardware (di tipo Unità Centrale o Unità

Periferica Personale o Unità Periferica di Workgroup) che l’Ateneo ha inizialmente utilizzato in virtù dei servizi di locazione operativa (rif.

§4.3) oggetto dell’appalto e che, a seguito dell’esercizio dell’opzione di riscatto (rif. §4.4), è divenuta di proprietà dell’Università. Tale hardware è quindi caratterizzato dall’essere stato in principio di proprietà del Fornitore.

Hardware di Proprietà: Rappresenta ogni unità hardware (di tipo Unità Centrale o Unità

Periferica Personale o Unità Periferica di Workgroup) che l’Ateneo ha acquisito in maniera autonoma, in tempi precedenti o nel corso del contratto. Tale hardware è quindi caratterizzato dal non essere mai stato di proprietà del Fornitore.

3.1.2. Acronimi

ADF: Automatic Document Feeder

DEC: Direttore dell’Esecuzione del Contratto

FAQ: Frequently Asked Questions

HW: Hardware

IQ: Indicatore di Qualità

LCD: Liquid Crystal Display

OEM: Original Equipment Manufacturer

PC: Personal Computer

PdL: Postazione di Lavoro

RAEE: Rifiuti da Apparecchiature Elettriche ed Elettroniche

RUP: Responsabile Unico del Procedimento

SLA: Service Level Agreement

SW: Software

UC: Unità Centrale

UP: Unità Periferica

UPP: Unità Periferica Personale

UPW: Unità Periferica di Workgroup

3.2. Oggetto

L'oggetto dell’appalto riguarda i servizi di gestione delle Postazioni di Lavoro e di fornitura in locazione operativa e/o di manutenzione delle apparecchiature hardware associate nonché di tutti i servizi organizzativi e accessori che nel complesso rientrano nella cosiddetta categoria dei servizi di Fleet Management.

L’elenco dei servizi richiesti è riportato nel paragrafo 3.2.1.

Il numero di PdL che il Fornitore dovrà gestire consta di un numero previsto di 1070 unità, secondo un piano di riferimento di attivazione dei servizi riportato nel capitolo 5.

Nell’ambito della gestione ordinaria del servizio di Fleet Management, il Centro InfoSapienza si riserva di apportare, durante l’esecuzione del contratto, variazioni minori al piano di riferimento illustrato, tali che non modifichino l’oggetto e la sostanza del contratto e non incidano sul corrispettivo contrattuale.

Il Centro si riserva altresì la facoltà di incrementare o ridurre il numero complessivo di PdL attive, nonché i servizi oggetto dell’appalto, nei termini imposti dall’art. 311 del X.X.X. 0 xxxxxxx 0000, x. 000 (xx rimanda all’art. 3 del Capitolato d’Oneri per maggiori dettagli).

Il Fornitore dovrà erogare i servizi nel rispetto totale dei livelli di qualità richiesti e concordati dall’Ateneo, attraverso l’impiego attivo ed efficace di un opportuno sistema di qualità (rif. §6).

3.2.1. Anagrafica dei servizi oggetto dell’appalto

La totalità dei servizi richiesti come oggetto dell’appalto sono sintetizzati nella Tabella 2 seguente.

I servizi sono suddivisi in aree e categorie e ad ogni servizio è assegnato un codice identificativo strutturato che lo identifica univocamente. Ogni servizio è descritto in dettaglio nel capitolo 4.

Area		Categoria		Servizio
Cod.	Nome	Cod.	Nome	Cod.	Nome	ID
SO	Servizi organizzativi	SS	Sistemi di supporto	ASIN	Sistema di asset inventory	SO.SS.ASIN
				SWDS	Sistema di software distribution	SO.SS.SWDS
				GRPL	Sistema di gestione remota delle PdL	SO.SS.GRPL
				GRUP	Sistema di gestione remota delle Unità Periferiche di rete	SO.SS.GRUP
				UTEN	Sistema di gestione integrata delle utenze	SO.SS.UTEN
				VRUS	Sistema di gestione antivirus e antispyware	SO.SS.VRUS
				RDOC	Repository documentale	SO.SS.RDOC
				CSAT	Sistema di gestione della customer satisfaction	SO.SS.CSAT
				SLAM	Sistema di reportistica e SLA management	SO.SS.SLAM
		AP	Attività progettuali	STUP	Fase di startup	SO.AP.STUP
				CONF	Verifica di conformità	SO.AP.CONF
				MONI	Monitoraggio e rendicontazione dei servizi	SO.AP.MONI
				FINA	Fase finale	SO.AP.FINA
				PROJ	Project management	SO.AP.PROJ
				SRVC	Service management	SO.AP.SRVC
GP	Gestione della PdL	AM	Asset management	INVE	Inventario	GP.AM.INVE
		RM	Gestione remota della PdL	CONT	Contact center	GP.RM.CONT
				HDSK	Help desk	GP.RM.HDSK
				ISWR	Installazione / configurazione / aggiornamento SW PdL da remoto	GP.RM.ISWR
				ASPL	Assistenza utilizzo PdL e periferiche e risorse di rete	GP.RM.ASPL
				ASSW	Assistenza utilizzo SW PdL	GP.RM.ASSW
				SWDS	Software distribution	GP.RM.SWDS

Area		Categoria		Servizio
Cod.	Nome	Cod.	Nome	Cod.	Nome	ID
		LC	Gestione in locale della PdL	PRES	Presidio su sede	GP.LC.PRES
				MAGA	Immagazzinamento	GP.LC.MAGA
				INTL	Intervento tecnico in locale	GP.LC.INTL
				MNHW	Intervento di manutenzione HW	GP.LC.MNHW
				ISWL	Installazione / configurazione / aggiornamento SW PdL in locale	GP.LC.ISWL
				IMAC	Install / Move / Add / Change / Remove	GP.LC.IMAC
		BO	Servizi di back office	ACCN	Gestione account e profilazioni PdL	GP.BO.ACCN
				MNUP	Monitoraggio Unità Periferiche di rete	GP.BO.MNUP
				CSAT	Valutazione e rendicontazione della customer satisfaction	GP.BO.CSAT
LO	Locazione operativa	UC	Locazione operativa Unità Centrale	PCDS	Locazione operativa PC desktop standard	LO.UC.PCDS
				PCDA	Locazione operativa PC desktop ad alte prestazioni	LO.UC.PCDA
				PCTC	Locazione operativa PC thin client	LO.UC.PCTC
				NTBK	Locazione operativa notebook	LO.UC.NTBK
		PP	Locazione operativa Unità Periferica Personale	MNTS	Locazione operativa monitor LCD standard	LO.PP.MNTS
				MNTA	Locazione operativa monitor LCD ad alte prestazioni	LO.PP.MNTA
				STLB	Locazione operativa stampante laser in bianco/nero personale	LO.PP.STLB
				STLC	Locazione operativa stampante laser a colori personale	LO.PP.STLC
				STTR	Locazione operativa stampante termica personale per etichette	LO.PP.STTR
				SCAF	Locazione operativa scanner personale con ADF	LO.PP.SCAF
		PW	Locazione operativa Unità Periferica di Workgroup	SMWL	Locazione operativa apparecchiatura multifunzione laser di workgroup	LO.PW.SMWL
RI	Riscatto da locazione operativa	UC	Riscatto Unità Centrale	PCDS	Riscatto PC desktop standard	RI.UC.PCDS
				PCDA	Riscatto PC desktop ad alte prestazioni	RI.UC.PCDA
				PCTC	Riscatto PC thin client	RI.UC.PCTC
				NTBK	Riscatto notebook	RI.UC.NTBK
		PP	Riscatto Unità Periferica Personale	MNTS	Riscatto monitor LCD standard	RI.PP.MNTS
				MNTA	Riscatto monitor LCD ad alte prestazioni	RI.PP.MNTA
				STLB	Riscatto stampante laser in bianco/nero personale	RI.PP.STLB
				STLC	Riscatto stampante laser a colori personale	RI.PP.STLC
				STTR	Riscatto stampante termica personale per etichette	RI.PP.STTR
				SCAF	Riscatto scanner personale con ADF	RI.PP.SCAF
		PW	Riscatto Unità Periferica di Workgroup	SMWL	Riscatto apparecchiatura multifunzione laser di workgroup	RI.PW.SMWL
MH	Manutenzione HW	LO	Manutenzione HW da Locazione Operativa	PCDT	Manutenzione HW PC desktop da locazione operativa	MH.LO.PCDT
				PCTC	Manutenzione HW PC thin client da locazione operativa	MH.LO.PCTC
				NTBK	Manutenzione HW notebook da locazione operativa	MH.LO.NTBK
				MNTR	Manutenzione HW monitor LCD da locazione operativa	MH.LO.MNTR
				STLB	Manutenzione HW stampante laser in bianco/nero personale da locazione operativa	MH.LO.STLB
				STLC	Manutenzione HW stampante laser a colori personale da locazione operativa	MH.LO.STLC
				STTR	Manutenzione HW stampante termica personale per etichette da locazione operativa	MH.LO.STTR
				SCAF	Manutenzione HW scanner personale con ADF da locazione operativa	MH.LO.SCAF
				SMWL	Manutenzione HW apparecchiatura multifunzione laser di workgroup da locazione operativa	MH.LO.SMWL

Area		Categoria		Servizio
Cod.	Nome	Cod.	Nome	Cod.	Nome	ID
		PR	Manutenzione HW di Proprietà	PCDT	Manutenzione HW PC desktop di proprietà	MH.PR.PCDT
				PCTC	Manutenzione HW PC thin client di proprietà	MH.PR.PCTC
				NTBK	Manutenzione HW notebook di proprietà	MH.PR.NTBK
				MNTR	Manutenzione HW monitor LCD di proprietà	MH.PR.MNTR
				STLB	Manutenzione HW stampante laser in bianco/nero personale di proprietà	MH.PR.STLB
				STLC	Manutenzione HW stampante laser a colori personale di proprietà	MH.PR.STLC
				STTR	Manutenzione HW stampante termica personale per etichette di proprietà	MH.PR.STTR
				STGI	Manutenzione HW stampante a getto d’inchiostro personale di proprietà	MH.PR.STGI
				SCAF	Manutenzione HW scanner personale con ADF di proprietà	MH.PR.SCAF
				SMWL	Manutenzione HW apparecchiatura multifunzione laser di workgroup di proprietà	MH.PR.SMWL
				STMT	Manutenzione HW stampante a matrice di workgroup di proprietà	MH.PR.STMT
RT	Ritiro RAEE	UC	Ritiro RAEE Unità Centrale	PCDT	Ritiro RAEE PC desktop	RT.UC.PCDT
				PCTC	Xxxxxx XXXX PC thin client	RT.UC.PCTC
				NTBK	Ritiro RAEE notebook	RT.UC.NTBK
		PP	Ritiro RAEE Unità Periferica Personale	MNTR	Ritiro RAEE monitor LCD	RT.PP.MNTR
				STLS	Ritiro RAEE stampante laser personale	RT.PP.STLS
				STTR	Ritiro RAEE stampante termica personale per etichette	RT.PP.STTR
				STGI	Ritiro RAEE stampante a getto d’inchiostro personale	RT.PP.STGI
				SCAF	Ritiro RAEE scanner personale con ADF	RT.PP.SCAF
		PW	Ritiro RAEE Unità Periferica di Workgroup	SMWL	Ritiro RAEE apparecchiatura multifunzione laser di workgroup	RT.PW.SMWL
		PW	Ritiro RAEE Unità Periferica di Workgroup	STMT	Ritiro RAEE stampante a matrice di workgroup	RT.PW.STMT

Tabella 2 – Anagrafica dei servizi oggetto dell’appalto

3.3. Durata delle attività

La durata del contratto è di 48 (quarantotto) mesi.

All’interno del periodo complessivo di durata contrattuale, si evidenziano due particolari fasi:

• fase di startup,

• fase finale,

caratterizzate da vincoli di durata e da attività organizzative ben specifiche, volte a garantire la più efficiente e completa transizione in ingresso ed in uscita del Fornitore all’interno del contesto operativo dell’Università; tali fasi sono descritte in dettaglio nei paragrafi 4.1.2.1 e 4.1.2.4 rispettivamente.

I servizi di fornitura in locazione operativa sono caratterizzati da una durata fissa di 36 (trentasei) mesi, salvo applicare le specifiche condizioni di terminazione anticipata previste nel presente capitolato, come indicato nel paragrafo 4.3.1.3.

3.4. Criteri di valutazione tecnica

I principali servizi oggetto dell’appalto, così come censiti nella Tabella 2 del paragrafo 3.2.1, saranno oggetto di valutazione tecnica rispetto a quanto proposto in sede di Offerta Tecnica dal Fornitore; si rimanda all’art. 7 del Disciplinare di Gara per maggiori dettagli.

Nel capitolo 4, oltre alla descrizione dei singoli servizi, verranno indicati, ove applicabile, i criteri di valutazione tecnica applicati a uno o più servizi considerati.

Per ogni criterio verranno descritte le modalità e i parametri di valutazione e sintetizzate in forma tabellare le seguenti informazioni:

• il codice identificativo composito del criterio di valutazione tecnica,

• il codice dei servizi (uno o più) oggetto di valutazione attraverso il criterio,

• una descrizione breve del criterio,

• la quota massima di punti tecnici associati al criterio,

• la modalità di valutazione del criterio, distinguendo fra:

o discrezionale con soglia,

o discrezionale,

o tabellare,

• l’eventuale punteggio minimo di soglia,

• alcune note specifiche relative alle modalità di valutazione.

4. Descrizione dell’appalto

Il seguente capitolo illustra obiettivi, caratteristiche operative, criteri di applicabilità e attivabilità ed eventuali vincoli relativi a ciascun servizio previsto nell’appalto.

4.1. SO – Servizi organizzativi

I servizi organizzativi di seguito descritti rappresentano i prerequisiti, i servizi e le soluzioni sia di tipo tecnologico che organizzativo e progettuale, che il Fornitore dovrà soddisfare/erogare al fine di rendere efficaci, produttivi e pienamente monitorabili e controllabili i servizi centrali di gestione delle PdL e di manutenzione HW, nonché in generale tutte le componenti oggetto dell’appalto.

4.1.1. XX.XX – Sistemi di supporto

Nei paragrafi seguenti vengono descritti alcuni sistemi informatici di supporto il cui utilizzo continuo, corretto e completo da parte del Fornitore è ritenuto dall’Ateneo necessario e determinante per l’erogazione dei servizi di Fleet Management.

Come meglio specificato nei paragrafi seguenti per i singoli sistemi, in taluni casi l’Università, ed in particolare il Centro InfoSapienza, dispone del proprio sistema informatico: in tal caso il Fornitore dovrà impiegare il sistema messo a disposizione dall’Ateneo, assumendo il ruolo di utilizzatore delle funzionalità di sistema, di responsabile dei dati gestiti e, laddove necessario/applicabile, anche di amministratore responsabile della propria area di impiego.

Per i restanti casi, il Fornitore dovrà predisporre (se necessario) ed utilizzare il proprio sistema informatico, purché in grado di rispettare i requisiti e i vincoli previsti dal presente capitolato. La soluzione informatica predisposta dal Fornitore potrà prevedere l’introduzione di componenti HW e/o SW all’interno dell’infrastruttura IT gestita dal Centro InfoSapienza (rif. §2.2), purché:

• rappresentino componenti adeguatamente identificati ed isolabili (es. specifici server e/o appliance);

• non prevedano costi aggiuntivi o integrativi per l’Ateneo, in particolare in relazione a loro installazione, utilizzo e manutenzione;

• si integrino, laddove opportuno/necessario, con componenti IT infrastrutturali (es. per la gestione delle utenze o per il traffico di rete) secondo regole da concordare con il Centro InfoSapienza;

• siano esplicitamente indicati in sede di Offerta Tecnica (come specificato nei paragrafi seguenti), laddove siano inevitabilmente necessari per il funzionamento della soluzione proposta.

Per ogni sistema informatico che verrà predisposto dal Fornitore e che prevedrà l’accesso alle funzionalità da parte dei referenti dell’Ateneo per il Fleet Management, il Fornitore dovrà in aggiunta garantire per tali utenti:

• la disponibilità di manualistica in lingua italiana relativamente alle modalità di accesso al sistema ed alle sue funzionalità;

• la partecipazione ad un corso di formazione, secondo modalità da concordare fra le parti;

• l’assistenza nell’utilizzo del sistema.

In ogni caso, l’Università intende utilizzare il proprio sistema informatico di configuration management per attività autonome di raccolta dati, monitoraggio e verifica sulle apparecchiature gestite; tale sistema è attualmente costituito da un’infrastruttura Microsoft System Center Configuration Manager 2012 (SCCM), con relative componenti software agent da installare sulle apparecchiature controllate. E’ responsabilità del Fornitore garantire la piena compatibilità con i sistemi di supporto predisposti (rif. §4.1.1) e le apparecchiature fornite nell’ambito dei servizi di locazione operativa (rif. §4.3).

L’Università, in caso di situazioni di emergenza informatica, di necessità organizzative o tecniche ad alta criticità/priorità non compatibili con i livelli di servizio contrattualizzati e/o in caso di inadempienza da parte del Fornitore nell’espletare interventi richiesti/concordati, si riserva di utilizzare il suddetto sistema per intervenire direttamente sulle apparecchiature gestite, al fine di preservare l’integrità e la piena operatività delle proprie risorse; in tal caso l’Università notificherà l’intervento al Fornitore, fornendo a posteriori il resoconto delle attività effettuate.

Relativamente al sistema SCCM in questione, a fini esclusivamente informativi si forniscono di seguito ulteriori informazioni tecniche (non esaustive) rispetto all’attuale installazione:

• l’installazione è standard (non sono presenti personalizzazioni del DB);

• la configurazione corrente prevede il seguente stato delle diverse funzionalità del sistema:

o Client Deployment – Manuale con boundaries pre-configurate

o Out of Band Management – Non configurato per assenza di Certification Authority e client compatibili AMT

o Remote Control – Abilitato RDP e Configuration Manager Remote Control. Disabilitato il remote assistance

o Hardware Inventory – Attiva

o Software Inventory – Attiva ma non configurata

o Asset Intelligence – Attiva e non personalizzata

o Software Metering – Attiva e non personalizzata

o Power Management – Attiva e non personalizzata

o Firewall Management – Attiva e non personalizzata

o Exchange Server Connector – Assente

o Mobile Device Client – Non gestiti

o Endpoint Protection – Attiva

o Software Deployment – Attiva

o Software Update – Attiva e non personalizzata

o Operating System Deployment – Disattivata

o Reporting – Attiva

o Alerts – Attiva;

• le porte attualmente attive sono:

o Client Requests-HTTP (TCP) – 80

o Client Requests-HTTPS (TCP) – 443

o Client Notification (TCP) – 10123

o Wake On LAN (UDP) – 12287.

4.1.1.1. SO.SS.ASIN – Sistema di asset inventory

Al fine di supportare i servizi di asset management (rif. §4.2.2) e più in generale l’erogazione e la gestione di tutti i servizi oggetto dell’appalto e la migliore pianificazione strategica e operativa, il Fornitore dovrà predisporre e rendere disponibili gli opportuni strumenti operativi di asset inventory, aventi le seguenti macro-funzionalità obbligatorie/opzionali:

• (obbligatoria) gestione centralizzata in una base dati strutturata delle informazioni delle PdL (da intendersi comprensive di tutte le unità UC, UPP, UPW gestite) relative ad aspetti logistici, amministrativi, di configurazione HW e SW;

• (opzionale) possibilità di estendere il modello dati delle informazioni censite secondo necessità e opportunità espresse dal Centro InfoSapienza;

• (obbligatoria) possibilità di alimentare la base dati attraverso strumenti (semi)automatici di discovery e/o di caricamenti massivi di basi dati esterne e/o inserimenti puntuali di informazioni;

• (obbligatoria) possibilità di esportare i dati archiviati;

• (obbligatoria) produzione di report, periodicamente o su richiesta, secondo specifiche da concordare con l’Ateneo, relativi a:

o situazione degli asset gestiti, a vari livelli di aggregazione;

o movimentazione mensile degli asset, a vari livelli di aggregazione.

Criteri di valutazione tecnica

In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere le principali caratteristiche funzionali e tecnologiche del sistema al fine di consentire la valutazione tecnica della bontà e congruità della soluzione. In particolare saranno oggetto di valutazione i parametri indicati come note nella scheda sottostante.

Inoltre, il Fornitore dovrà comunque garantire che la propria soluzione non impedisca all’Ateneo di impiegare il sistema SCCM di cui è dotato, per attività autonome di raccolta dati, monitoraggio e verifica. Infine, il Fornitore dovrà altresì indicare eventuali componenti HW e/o SW della soluzione che necessariamente dovranno essere introdotte all’interno dell’infrastruttura IT gestita dal Centro InfoSapienza per il funzionamento della soluzione stessa.

Criterio	Descrizione breve		Servizi interessati
VT.SO.SS.ASIN.1	Caratteristiche del sistema proposto		• SO.SS.ASIN
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
3,0	Discrezionale con soglia	0,9
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità obbligatorie richieste; • il livello di copertura e le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità opzionali richieste; • eventuali funzionalità aggiuntive/migliorative proposte dal Fornitore; • le modalità di accesso e funzionalità disponibili specificatamente per i referenti dell’Ateneo per il Fleet Management

4.1.1.2. SO.SS.SWDS – Sistema di software distribution

Al fine di supportare l’erogazione dei servizi di installazione / configurazione / aggiornamento SW delle PdL (rif. §4.2.3.3) e di software distribution (rif. §4.2.3.6) e più in generale di abilitare una efficace gestione

remota delle PdL (rif. §4.2.3), il Fornitore dovrà predisporre e rendere disponibili gli opportuni strumenti operativi di software distribution, aventi le seguenti macro-funzionalità obbligatorie/opzionali:

• (obbligatoria) verifica dell’andamento del processo di distribuzione;

• (obbligatoria) verifica dei risultati ed eventuali azioni conseguenti;

• (obbligatoria) attivazione di azioni di rollback (recovery della versione precedente e possibile ripristino), se applicabile;

• (obbligatoria) possibilità di effettuare operazioni di reboot prima e/o dopo l'esecuzione delle procedure di installazione stesse;

• (opzionale) possibilità di definire il livello di occupazione della banda di rete durante il trasferimento del software;

• (obbligatoria) possibilità di effettuare la disinstallazione del software distribuito/installato sulle postazioni remote.

Il software dovrà essere in grado di installare, aggiornare e disinstallare pacchetti applicativi Microsoft, ivi compreso il sistema operativo, sia nella stessa versione che in upgrade. Dovrà anche essere in grado di copiare singoli file non compresi all’interno di un programma di installazione. L’accesso remoto alla macchina dovrà essere possibile solo da parte di utenti autorizzati in possesso di credenziali di amministratore.

Nel caso di attività estese, come l’aggiornamento di versione che prevede la disinstallazione della versione precedente, il sistema dovrà consentire anche la gestione delle installazioni complesse mediante script di automazione o altro sistema di concatenazione delle attività e di gestione dei prerequisiti.

Criteri di valutazione tecnica

Criterio	Descrizione breve		Servizi interessati
VT.SO.SS.SWDS.1	Caratteristiche del sistema proposto		• SO.SS.SWDS
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
3,0	Discrezionale con soglia	0,9
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità obbligatorie richieste; • il livello di copertura e le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità opzionali richieste; • eventuali funzionalità aggiuntive/migliorative proposte dal Fornitore; • le modalità di accesso e funzionalità disponibili specificatamente per i referenti dell’Ateneo per il Fleet Management

4.1.1.3. SO.SS.GRPL – Sistema di gestione remota delle PdL

Al fine di supportare efficacemente il servizio di gestione remota delle PdL (rif. §4.2.3), anche in relazione all’effettiva capacità di limitare al minimo gli interventi di gestione in locale (rif. §4.2.4), il Fornitore dovrà predisporre e rendere disponibili gli opportuni strumenti operativi adatti allo scopo.

Tale sistema dovrà/potrà presentare le seguenti macro-funzionalità obbligatorie/opzionali di gestione remota della singola UC:

• (obbligatoria) controllo della configurazione hardware:

o con l’apparecchiatura spenta, l’accesso da console remota alle seguenti informazioni hardware sull’apparecchiatura stessa:

▪ informazioni generali di sistema (produttore, modello, ecc.);

▪ processore;

▪ scheda madre;

▪ memoria RAM;

▪ hard disk.

• (obbligatoria) controllo dello stato di accensione:

o con l’apparecchiatura spenta, eseguire da console remota il comando di accensione e verificare che l’apparecchiatura esegua l’avvio e il caricamento del sistema operativo;

o con l’apparecchiatura accesa e il sistema operativo caricato, da console remota eseguire il comando di spegnimento e verificare che l’apparecchiatura esegua la chiusura del sistema operativo e l’arresto del sistema.

• (opzionale) controllo della configurazione BIOS:

o con l’apparecchiatura spenta, eseguire da console remota il comando di accensione con l’opzione “BIOS setup” e verificare che la schermata BIOS appaia sia sull’apparecchiatura che sulla console remota;

o verificare che, agendo da console remota, si possa navigare nei menu BIOS dell’apparecchiatura e che le opzioni siano modificabili e salvabili.

• (opzionale) controllo remoto:

o il software dovrà permettere di prendere il controllo pieno del desktop remoto, mantenendo aperta la sessione in modo che l’utente della PdL possa visualizzare costantemente le operazioni eseguite remotamente. Durante la sessione remota dovrà essere possibile lo scambio file bidirezionale e la chat testuale tra controllato e controllante. L’accesso remoto alla macchina dovrà essere possibile solo da parte di utenti autorizzati in possesso di credenziali di amministratore e su esplicita accettazione dell’utente finale.

Criteri di valutazione tecnica

Criterio	Descrizione breve		Servizi interessati
VT.SO.SS.GRPL.1	Caratteristiche del sistema proposto		• SO.SS.GRPL
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
5,0	Discrezionale con soglia	1,5
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità obbligatorie richieste; • il livello di copertura e le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità opzionali richieste; • eventuali funzionalità aggiuntive/migliorative proposte dal Fornitore; • le modalità di accesso e funzionalità disponibili specificatamente per i referenti dell’Ateneo per il Fleet Management

4.1.1.4. SO.SS.GRUP – Sistema di gestione remota delle Unità Periferiche di rete

Al fine di supportare il servizio di monitoraggio delle Unità Periferiche di rete (rif. §4.2.5.2), il Fornitore dovrà predisporre e rendere disponibili gli opportuni strumenti operativi di gestione remota delle UP di rete.

Tale sistema dovrà/potrà presentare le seguenti macro-funzionalità obbligatorie/opzionali (con riferimento al caso di UP di stampa):

• (obbligatoria) verifica centralizzata dello stato di funzionamento delle UP (ad es. stato on-line);

• (opzionale) controlli automatici e allarmistica in caso di situazioni anomale e malfunzionamenti (es. carta inceppata o toner in esaurimento);

• (opzionale) possibilità di intervenire da remoto sulla gestione SW dell’UP (es. reset della coda di stampa);

• (opzionale) calcolo e reportistica di indicatori di utilizzo della singola UP (es. numero di stampe effettuate) e/o di sfruttamento dei materiali di consumo (es. livello di toner residuo), eventualmente anche per singolo utente abilitato o per aggregazioni organizzative.

L’utilizzo del sistema in questione sarà impiegabile naturalmente solo per le UP gestite che presentino le caratteristiche tecniche necessarie per l’integrazione e la gestione remota e siano configurate in esercizio come unità di rete.

Criteri di valutazione tecnica

Inoltre, il Fornitore dovrà altresì indicare eventuali componenti HW e/o SW della soluzione che necessariamente dovranno essere introdotte all’interno dell’infrastruttura IT gestita dal Centro InfoSapienza per il funzionamento della soluzione stessa.

Criterio	Descrizione breve		Servizi interessati
VT.SO.SS.GRUP.1	Caratteristiche del sistema proposto		• SO.SS.GRUP
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
2,0	Discrezionale	Non applicabile
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità obbligatorie richieste; • il livello di copertura e le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità opzionali richieste; • eventuali funzionalità aggiuntive/migliorative proposte dal Fornitore

4.1.1.5. SO.SS.UTEN – Sistema di gestione integrata delle utenze

Il sistema di gestione integrata delle utenze ha la finalità di gestire, da un unico punto centralizzato, l’insieme (elenco) strutturato di risorse note nell’ambito dei servizi di rete; più precisamente si fa riferimento ad una parte (es. LDAP) di quelle funzionalità denominate tecnicamente directory services.

Le risorse vengono quindi identificate da un’utenza o account, ossia un’identità registrata nell’elenco, che può corrispondere, nel nostro contesto, ad un utente, un operatore o ad un’unità HW (UC, UPP; UPW).

Il sistema di gestione integrata permette la gestione centralizzata e l’accesso condiviso dell’identità delle risorse, ad uso di altri servizi tecnici quali l’autenticazione e l’autorizzazione nell’accesso alle varie risorse IT.

Come anche evidenziato dalle tipologie di apparecchiature HW previste per i servizi di locazione operativa (rif. §4.3) e manutenzione HW (rif. §4.5), l’Università intende gestire un parco macchine fondamentalmente basato sui sistemi operativi Microsoft.

Pertanto, per le funzionalità di gestione integrata delle utenze e per i servizi correlati (es. Help desk – rif.

§4.2.3.2 – e gestione account e profilazioni PdL – rif. §4.2.5.1), il Fornitore dovrà obbligatoriamente utilizzare il sistema Microsoft Active Directory messo a disposizione dal Centro InfoSapienza. Nella fattispecie, la versione attualmente gestita per l’intero dominio di attestazione delle PdL corrisponde a Active Directory 2003; nel periodo contrattuale sono ipotizzabili upgrade a versioni superiori.

Data la notorietà e diffusione del prodotto, si rimanda a documentazione del produttore pubblicamente disponibile per maggiore informazioni sul sistema e sulle funzionalità in questione.

4.1.1.6. SO.SS.VRUS – Sistema di gestione antivirus e antispyware

Il sistema di gestione antivirus e antispyware ha la finalità di garantire che l’intero parco macchine gestito dal Fornitore sia quanto più possibile sicuro e protetto dalle minacce informatiche virali di varia natura, quali appunto virus, worm, trojan, rootkit, spyware, keylogger, ecc., anche a beneficio dell’intera infrastruttura informatica dell’Ateneo all’interno del quale le PdL operano.

Pertanto, il Fornitore dovrà predisporre un sistema atto allo scopo, tipicamente costituito da un’infrastruttura comprendente componenti SW client installate localmente sulle UC, ai fini di un controllo attivo e passivo locale, ed una componente centrale di gestione.

Tale sistema dovrà/potrà presentare le seguenti macro-funzionalità obbligatorie/opzionali:

• (obbligatoria) console di amministrazione centralizzata sulla configurazione, sullo stato di funzionamento e sullo stato di aggiornamento degli agenti client;

• (obbligatoria) aggiornamento automatico degli archivi di firme degli agenti client;

• (opzionale) gestione centralizzata di politiche di avvio su base pianificata (regolare o su richiesta) di scansioni massive delle apparecchiature host;

• (opzionale) report sullo stato di aggiornamenti in grado di evidenziare i casi limite ad alto rischio.

Nell’ambito delle funzionalità offerte dalla soluzione, dovrà essere garantito da parte del Fornitore l’accesso ad un laboratorio di analisi (eventualmente tramite il supporto di un produttore di soluzioni antivirus), con reattività entro un giorno lavorativo (Next Business Day), in grado di supportare tempestivamente la rilevazione e l’identificazione di minacce e di fornire indicazioni su workaround o azioni risolutive da applicare.

Infine, è responsabilità del Fornitore garantire che il sistema proposto sia compatibile con le caratteristiche di UC di proprietà dell’Ateneo, sulla base dello scenario di riferimento espresso nel contesto tecnologico attuale dell’Università (rif. §2.2), di modo che, qualora venga attivato il servizio di manutenzione per HW di Proprietà (rif. §0), il sistema sia in grado di proteggere con adeguato livello di sicurezza anche tale tipologia di apparecchiature.

Criteri di valutazione tecnica

Criterio	Descrizione breve		Servizi interessati
VT.SO.SS.VRUS.1	Caratteristiche del sistema proposto		• SO.SS.VRUS
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
3,0	Discrezionale con soglia	0,9
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità obbligatorie richieste; • il livello di copertura e le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità opzionali richieste; • eventuali funzionalità aggiuntive/migliorative proposte dal Fornitore; • le modalità di accesso e funzionalità disponibili specificatamente per i referenti dell’Ateneo per il Fleet Management

4.1.1.7. SO.SS.RDOC – Repository documentale

Il Fornitore dovrà obbligatoriamente utilizzare un repository documentale, predisposto dal Centro InfoSapienza utilizzando tecnologie di network file system condiviso in ambiente Microsoft o ambienti di collaborazione via web (es. Microsoft SharePoint), finalizzato alla raccolta centralizzata, l’archiviazione, la gestione, l’aggiornamento e la consultazione in maniera efficiente ed organizzata dei documenti e dei pacchetti SW generati a partire dalla decorrenza contrattuale per ogni attività e servizio connesso con l’ambito dell’appalto.

Il sistema si configura come strumento di supporto a molti dei servizi richiesti, come, ad esempio, la gestione della configurazione delle PdL per le quali, a fronte di variazioni della configurazione corrente, sarà necessario produrre, aggiornare o modificare la relativa documentazione.

La soluzione tecnica di dettaglio verrà predisposta dal Centro InfoSapienza nella fase di startup del servizio (rif. §4.1.2.1), anche in funzione della definizione delle procedure operative di dettaglio per l’erogazione dei servizi ambito della fornitura. Relativamente a tale contesto, il sistema di repository documentale vedrà come utenti solo il personale tecnico e gestionale sia del Centro InfoSapienza che del Fornitore, interessato dai servizi stessi. Non è attualmente previsto l’accesso da parte degli utenti dei servizi.

4.1.1.8. SO.SS.CSAT – Sistema di gestione della customer satisfaction

Al fine di supportare adeguatamente l’erogazione del servizio di valutazione e rendicontazione della customer satisfaction (rif. §4.2.5.2), il Fornitore dovrà predisporre e rendere disponibili gli opportuni strumenti operativi, aventi le seguenti macro-funzionalità obbligatorie/opzionali:

• (obbligatoria) gestione dei questionari concordati ed approvati dall’Ateneo;

• (obbligatoria) raccolta e conservazione dei dati relativi ai questionari compilati;

• (obbligatoria) garanzia dell’anonimato dei questionari compilati e dei dati archiviati;

• (opzionale) controllo di qualità dei dati raccolti;

• (obbligatoria) gestione del piano di campionamento approvato dall’Ateneo;

• (obbligatoria) produzione di report di dettaglio e di sintesi dei risultati;

• (obbligatoria) esportabilità dei dati.

I risultati della rilevazione saranno rendicontati con il sistema di reportistica di cui al successivo paragrafo.

Ai fini del raggiungimento del maggior numero di utenti e di raccolta quindi di un numero di questionari statisticamente significativo, e in considerazione delle tipologie di campagne che l’Università intende intraprendere (si veda il servizio sopra menzionato), l’Ateneo ritiene opportuno e premiante (si veda il sotto- paragrafo seguente) l’impiego di diversi e quanto più automatizzabili strumenti di campionamento, quali ad esempio:

• l’invio automatico di email all’utente a seguito della chiusura di un ticket, riportante un link ad una pagina web per la compilazione del questionario;

• l’invio massivo di email in determinati momenti secondo il piano di campionamento previsto, riportanti un link ad una pagina web per la compilazione del questionario. In tali occasioni può essere utile anche un meccanismo di invio massivo di solleciti agli utenti selezionati (possibilmente quando non hanno risposto);

• form di richiesta di valutazione in fase di uscita dalle pagine web del servizio di Contact center, laddove disponibili (per maggiori dettagli si veda il paragrafo 4.2.3.1).

Criteri di valutazione tecnica

Infine, il Fornitore dovrà indicare eventuali componenti HW e/o SW della soluzione che necessariamente dovranno essere introdotte all’interno dell’infrastruttura IT gestita dal Centro InfoSapienza per il funzionamento della soluzione stessa.

Criterio	Descrizione breve		Servizi interessati
VT.SO.SS.CSAT.1	Caratteristiche del sistema proposto		• SO.SS.CSAT
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
4,0	Discrezionale con soglia	1,2
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità obbligatorie richieste; • il livello di copertura e le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità opzionali richieste; • eventuali funzionalità aggiuntive/migliorative proposte dal Fornitore; • gli strumenti di campionamento che il Fornitore intende predisporre; • le modalità di accesso e funzionalità disponibili specificatamente per i referenti dell’Ateneo per il Fleet Management

4.1.1.9. SO.SS.SLAM – Sistema di reportistica e SLA management

Al Fornitore è richiesto di predisporre e rendere disponibili gli opportuni strumenti operativi di reportistica e SLA management che supportino adeguatamente un’ottimale pianificazione ed erogazione dell’intero oggetto contrattuale e rendano disponibili e fruibili le informazioni necessarie per:

• verificare la conformità dei servizi rispetto a quanto richiesto/proposto;

• verificare l’effettivo andamento dei servizi e anticipare la gestione degli scostamenti;

• supportare la gestione operativa dei servizi, in maniera proattiva, ed in particolare la gestione dell’escalation;

• consuntivare i servizi e le attività;

• implementare il sistema di qualità (rif. §6), in particolare per verificare l’andamento degli Indicatori di Qualità, dei livelli di customer satisfaction e dei Service Level Agreement;

• ottimizzare le attività di monitoraggio dei servizi.

Il sistema dovrà/potrà presentare le seguenti macro-funzionalità obbligatorie/opzionali:

• (Obbligatoria) Raccogliere e organizzare i dati elementari della fornitura e dei servizi erogati, in una base dati strutturata. Il tempo massimo tra il verificarsi di un evento e la pubblicazione nel sistema di reporting non potrà superare i 2 (due) giorni lavorativi. Nel caso in cui alcuni dati elementari siano gestiti da sistemi dell’Ateneo, il Fornitore dovrà predisporre ed assicurare tutto quanto necessario per il caricamento dei dati, nel formato e con la periodicità stabilita congiuntamente, e la successiva elaborazione e pubblicazione secondo le stesse modalità applicate ai dati elementari direttamente gestiti.

• (Obbligatoria) Permettere di esportare l’insieme organico e integrato di tutti i dati rilevati attraverso una base dati relazionale di dettaglio da rilasciare all’Ateneo.

• (Obbligatoria) Fornire, periodicamente e/o in tempo reale, indicazioni sintetiche sui principali aspetti operativi (es. stato delle consegne, stato delle installazioni, ticket inevasi, ecc.) rilevanti per le procedure operative che verranno concordate nella fase di startup dell’appalto.

• (Obbligatoria) Aggregare e analizzare i dati rilevati e determinare gli Indicatori di Qualità richiesti, secondo le frequenze di aggiornamento previste e/o concordate con l’Ateneo.

• (Obbligatoria) Permettere agli utenti la possibilità di aggregare i dati, creare interrogazioni e report ad- hoc, definire e salvare template di report per un successivo riutilizzo e visualizzazione con dati aggiornati. In particolare, dovrà essere permesso all’Ateneo l’accesso autonomo e flessibile alle informazioni del sistema, senza alcuna limitazione.

• (Opzionale) Visualizzare tutte le informazioni raccolte e/o calcolate attraverso viste di sintesi e di dettaglio e esportare i risultati in forma grafica e/o tabellare secondo formati dati e grafici di comune utilizzo e visualizzabili nelle comuni suite applicative per l’ufficio, per un successivo ed eventuale trattamento (modifica, manipolazione, esportazione, ecc).

Dovranno, inoltre, essere rese disponibili tutte le informazioni inerenti il personale impegnato in ciascun servizio/attività, in termini di figura professionale e grado di utilizzo.

Criteri di valutazione tecnica

Inoltre, il Fornitore dovrà indicare eventuali componenti HW e/o SW della soluzione che necessariamente dovranno essere introdotte all’interno dell’infrastruttura IT gestita dal Centro InfoSapienza per il funzionamento della soluzione stessa.

Criterio	Descrizione breve		Servizi interessati
VT.SO.SS.SLAM.1	Caratteristiche del sistema proposto		• SO.SS.SLAM
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
5,0	Discrezionale con soglia	1,5
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità obbligatorie richieste; • il livello di copertura e le modalità tecnico-funzionali con cui la soluzione proposta coprirà le macro-funzionalità opzionali richieste; • eventuali funzionalità aggiuntive/migliorative proposte dal Fornitore; • le modalità di accesso e funzionalità disponibili specificatamente per i referenti dell’Ateneo per il Fleet Management

4.1.1.9.1. Report

Il Fornitore dovrà implementare la produzione dei report necessari ad un completo controllo da parte dell’Ateneo sulla quantità, qualità e conformità dei servizi erogati, in particolare in funzione del servizio di monitoraggio e rendicontazione (rif. §4.1.2.3).

A titolo indicativo non esaustivo, a tale scopo si prevedono i seguenti report:

• statistiche su apparati e guasti più frequenti,

• tipologia e numero di richieste all’Help desk,

• sintesi operative sullo stato di lavorazione delle richieste,

• sintesi operative sugli interventi effettuati.

L’elenco, il formato e le logiche di calcolo dei report verranno concordati fra le parti.

Sussistenti i requisiti di autonomia e flessibilità per l’Ateneo nell’accesso al sistema di reportistica ed alle informazioni contenute, l’Università potrà richiedere al Fornitore lo sviluppo di specifici report utili alle proprie necessità di valutazione dei servizi, analisi dei comportamenti degli utenti e delle tendenze, sviluppo di strategie.

4.1.2. SO.AP – Attività progettuali

Di seguito vengono descritti i requisiti e le caratteristiche richieste per i servizi di natura organizzativa e progettuale finalizzati ad avviare, gestire, monitorare ed infine terminare, in maniera pianificata e controllata, i servizi centrali di gestione delle PdL e di manutenzione HW, nonché in generale tutte le componenti oggetto dell’appalto.

In quanto regola valida in generale, il Fornitore è tenuto ad erogare i servizi con competenza e professionalità, nel rispetto del livelli di qualità attesi e concordati attraverso il sistema di qualità predisposto (rif. §6).

In tale ottica, l’Ateneo ritiene pertanto determinante che il Fornitore predisponga l’impiego di risorse specializzate con adeguate e comprovate competenze tecniche nonché esperienze pluriennali di Fleet Management in contesti operativi reali di classe enterprise, e che mantenga tali competenze aggiornate nel tempo e a fronte della naturale evoluzione delle best practice e del parco gestito per l’Università. Come indicato nel sotto-paragrafo seguente, la qualità delle professionalità e dell’esperienza acquisita dei profili professionali che il Fornitore intenderà impiegare nell’erogazione delle attività progettuali, sarà un parametro di valutazione premiante in sede di valutazione dell’Offerta Tecnica.

In ogni caso l’Ateneo si riserva, nel corso del contratto, di segnalare al Fornitore – in prima istanza – l’eventuale presenza di personale ritenuto non adeguato alle caratteristiche ed ai livelli di qualità dei servizi dichiarati in sede di Offerta Tecnica, in termini di competenze, esperienza, professionalità; a tale scopo l’Ateneo si riserva altresì di richiedere il curriculum professionale del personale proposto e/o documentazione comprovante l’esperienza dello stesso.

A fronte di tali segnalazioni il Fornitore dovrà porre in atto le opportune e concordate azioni correttive e migliorative. Nei casi più severi o a seguito di reiterate segnalazioni, l’Ateneo potrà richiedere, in forma ufficiale e adeguatamente motivata, la rimozione e sostituzione del personale, a cui il Fornitore dovrà necessariamente dare seguito in maniera tempestiva.

Criteri di valutazione tecnica

In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere complessivamente le modalità organizzative e procedurali proposte per l’esecuzione delle attività progettuali, al fine di consentire la valutazione tecnica della bontà e congruità della soluzione proposta. In particolare saranno oggetto di valutazione i parametri indicati come note nella scheda sottostante.

Criterio	Descrizione breve		Servizi interessati
VT.SO.AP.EROG.1	Modalità di gestione e organizzazione del lavoro		• SO.AP.STUP • SO.AP.CONF • SO.AP.MONI • SO.AP.FINA • SO.AP.PROJ • SO.AP.SRVC
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
7,0	Discrezionale con soglia	2,1
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le caratteristiche e l’organizzazione di ruoli, responsabilità e risorse previste dal Fornitore; • la qualità delle competenze, professionalità ed esperienze predisposte dal Fornitore; • le metodologie di approccio alle problematiche e di organizzazione del lavoro; • l’efficacia e i livelli di standardizzazione e qualità delle modalità operative previste, in particolare in riferimento alla tracciabilità ed al monitoraggio delle attività, alla gestione della documentazione, ai meccanismi di gestione delle priorità, di rischi e criticità, di escalation, del cambiamento, di miglioramento continuo e di verifica del rispetto degli SLA e dell’applicazione del sistema di qualità; • eventuali misure organizzative, tecniche o procedurali specifiche per affrontare gli aspetti più problematici o complessi dei servizi da erogare, soprattutto quando sottolineati nel presente capitolato; • le modalità di impiego dei sistemi di supporto previsti; • le modalità di interazione, collaborazione e condivisione con i referenti dell’Ateneo per i servizi di Fleet Management o altri servizi interessati

4.1.2.1. SO.AP.STUP – Fase di startup

La fase di startup si pone il duplice obiettivo di:

• introdurre pienamente ed efficacemente il Fornitore nel contesto organizzativo, tecnologico ed operativo dell’Ateneo ed avviare operativamente l’erogazione dei servizi;

• permettere il passaggio di consegne tra la struttura di servizio precedente all’avvio del contratto e la struttura predisposta dal Fornitore, al fine di garantire all’Ateneo ed agli utenti del servizio di Fleet Management la migliore continuità di servizio nell’avvicendamento.

Tale periodo di transizione dovrà terminare entro massimo 90 (novanta) giorni solari dalla data di sottoscrizione del contratto.

La fase di startup è caratterizzata dalle seguenti attività principali:

• Affiancamento e gestione transitoria iniziale: affiancamento e collaborazione con il gestore dei servizi di Fleet Management in uscita e il Centro InfoSapienza, per acquisire informazioni e dati e coordinare le attività in sovrapposizione/progressivo avvicendamento.

• Predisposizione del piano generale della fornitura: definizione di dettaglio e condivisione di tutte le componenti organizzative, progettuali e procedurali della fornitura e revisione del piano di riferimento di attivazione dei servizi (rif. §5), sulla base del contesto e delle esigenze dell’Ateneo maturate all’avvio delle attività contrattuali.

• Predisposizione del sistema di qualità: definizione di dettaglio e condivisione di tutte le componenti del sistema di qualità richiesto e illustrato nel capitolo 6.

• Predisposizione dei sistemi di supporto: messa a disposizione, configurazione e definizione delle procedure operative di utilizzo dei sistemi di supporto richiesti in fornitura e illustrati nel capitolo 4.1.1.

• Avvio dei servizi: attivazione progressiva dei servizi oggetto dell’appalto, in particolare dei servizi di gestione delle PdL e di locazione operativa.

Come indicato anche nei capitoli 0 e 6.4, si precisa che, relativamente all’avvio dei servizi durante la fase di startup, in tale periodo iniziale del contratto i diversi livelli di servizio previsti saranno oggetto di misurazione e valutazione, ai fini di fornire elementi concreti sull’efficacia delle soluzioni adottate e su eventuali aree di miglioramento su cui intervenire tempestivamente, tuttavia non si procederà all’applicazione delle penali associate a fronte di mancato rispetto degli SLA; l’applicazione delle penali potrà quindi diventare effettiva solo a partire dal termine della fase di startup.

In ogni caso, entro la scadenza del periodo di startup l’Università potrà recedere dal contratto ai sensi dell’art. 1373 del codice civile, qualora la collaborazione sviluppata nel periodo trascorso dovesse profilare difficoltà, accertate e documentabili, nella successiva erogazione del servizio. La comunicazione di recesso dovrà essere effettuata, previo preavviso di almeno 15 (quindici) giorni, a mezzo raccomandata A.R..

Qualora la facoltà di recesso venga esercitata, l’Ateneo dovrà riconoscere al Fornitore un corrispettivo in relazione all’opera di collaborazione fornita o prestata nella fase transitoria, determinato nella misura del canone per i servizi pari al periodo prestato sulla base dei canoni contrattuali, escludendo ogni altro risarcimento al Fornitore. In ogni caso il Fornitore dovrà impegnarsi a supportare l’Ateneo nelle operazioni di ripristino dei servizi alle condizioni esistenti alla data d’inizio del periodo di transizione.

Criteri di valutazione tecnica

Come evidenziato dal piano di riferimento di attivazione dei servizi, in particolare dall’approccio previsto (rif.

§5.1), nella fase di startup si prevede un’attivazione massiva in breve periodo sia dei servizi di gestione delle PdL che di locazione operativa, proprio per rendere quanto più breve e lineare possibile il periodo di affiancamento e transizione. In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere le modalità organizzative, tecniche e procedurali proposte specificatamente per gestire la complessità operativa di tale avvio dei servizi, al fine di consentire la valutazione tecnica della bontà e congruità della soluzione proposta.

Criterio	Descrizione breve		Servizi interessati
VT.SO.AP.STUP.1	Modalità di attivazione massiva dei servizi		• SO.AP.STUP
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
4,0	Discrezionale con soglia	1,2
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le modalità organizzative, tecniche e procedurali proposte specificatamente per gestire la complessità operativa dell’avvio dei servizi

4.1.2.2. SO.AP.CONF – Verifica di conformità

L’Ateneo si riserva di sottoporre a verifica di conformità ogni bene, sistema e attività rilasciato dal Fornitore nell’ambito dell’appalto. La verifica comprenderà tutte le ispezioni, prove e misure che saranno ritenute opportune dal Centro InfoSapienza per accertare che la componente rilasciata sia stata realizzata a regola d’arte e in completo accordo con le specifiche contrattuali e con la documentazione tecnica presentata in sede di Offerta Tecnica, in particolare con riferimento alla documentazione richiesta nel capitolo 4.3 a convalida del rispetto dei requisiti minimi e di conformità richiesti per le apparecchiature in locazione operativa.

In particolare saranno oggetto di verifica di conformità:

• I sistemi di supporto (rif. §4.1.1) e le connesse procedure operative di utilizzo. Ogni sistema o ogni blocco ben identificato di componenti/funzionalità di un sistema (in caso di rilasci multipli) verrà collaudato entro 20 (venti) giorni lavorativi dalla data di rilascio.

• Le apparecchiature in locazione operativa (rif. §4.3). Ogni partita rilasciata potrà essere collaudata a campione per la quota massima del 10% di unità per tipologia di HW, entro 20 (venti) giorni lavorativi dalla data di rilascio.

Il Fornitore darà il necessario supporto tecnico a tutte le attività di verifica di conformità.

Al termine delle operazioni di verifica, in caso di esito positivo il Centro InfoSapienza emetterà il conseguente certificato di verifica di conformità, con l’indicazione analitica delle attività svolte e delle risultanze delle ispezioni, prove e misure eseguite. Copia del documento sarà consegnata al Fornitore.

Nel caso la verifica non dia esito positivo, il Centro InfoSapienza comunicherà per iscritto – con qualsiasi mezzo – al Fornitore mediante una specifica richiesta di adeguamento, le carenze, le difformità o gli inconvenienti riscontrati. Il Fornitore dovrà realizzare gli adeguamenti richiesti e, al termine, darà

comunicazione per iscritto della fine degli interventi adeguativi al Centro InfoSapienza e richiederà l’effettuazione di una nuova verifica di conformità. Tale procedura potrà essere ripetuta fino a tre volte consecutive nel caso in cui la verifica non dia esito positivo; superato tale limite l’Ateneo, tenuto conto della fase contrattuale in atto, procederà a mettere in atto le azioni più opportune previste dalle condizioni contrattuali a garanzia del rispetto dei requisiti di gara.

In caso di non conformità delle apparecchiature in locazione operativa, il Fornitore ha l’obbligo di sostituire le apparecchiature non funzionanti o con caratteristiche non conformi a quanto contrattualizzato.

Tutti gli oneri e le spese di verifica sono a carico del Fornitore.

4.1.2.3. SO.AP.MONI – Monitoraggio e rendicontazione dei servizi

Durante l’intero periodo di vigenza contrattuale, al Fornitore è richiesto di procedere regolarmente ad un monitoraggio continuo, corretto e completo dei servizi erogati.

In particolare, è richiesto di produrre, attraverso l’utilizzo del sistema di reportistica e SLA management (rif.

§4.1.1.9), le opportune informazioni ed evidenze necessarie alla conduzione di regolari incontri fra le parti, in base al seguente approccio su frequenza e finalità:

• Incontri mensili relativi a:

o verifica dello stato della gestione operativa ordinaria;

o verifica degli Indicatori di Qualità e degli SLA di frequenza mensile;

o analisi e valutazione di casi limite o problematiche operative specifiche riscontrate.

• Incontri trimestrali relativi a:

o rendicontazione e verbalizzazione dei servizi erogati nel trimestre;

o verifica degli Indicatori di Qualità e degli SLA di frequenza trimestrale;

o analisi delle criticità e delle azioni di correzione e/o miglioramento nell’erogazione dei servizi.

• Incontri semestrali relativi a:

o verifica degli Indicatori di Qualità e degli SLA di frequenza semestrale o annuale;

o valutazione dei risultati e delle azioni relative alla customer satisfaction (rif. §4.2.5.2);

o andamento dei consumi nell’attivazioni dei servizi e previsioni per i periodi successivi.

4.1.2.4. SO.AP.FINA – Fase finale

La fase finale si pone il duplice obiettivo (esattamente speculare a quello della fase di startup) di:

• avviare la progressiva terminazione dell’erogazione dei servizi da parte del Fornitore ed il rilascio o ritiro di tutte le risorse impiegate allo scopo, fino alla completa uscita del Fornitore dal contesto organizzativo, tecnologico ed operativo dell’Ateneo;

• permettere il passaggio di consegne tra il Fornitore e l’Ateneo o terzi gestori da esso incaricati, al fine di garantire all’Ateneo ed agli utenti del servizio di Fleet Management la migliore continuità di servizio nell’avvicendamento.

Tale periodo di transizione dovrà essere avviato al massimo 180 (centottanta) giorni solari antecedenti alla data di conclusione del contratto e comunque secondo una pianificazione di dettaglio che verrà concordata fra le parti.

Al termine del periodo di vigenza contrattuale, stante l’obiettivo imprescindibile dell’Università di definire e designare una nuova struttura operativa (interna e/o tramite gestori terzi) che subentri al Fornitore nell’erogazione dei servizi di Fleet Management con continuità, l’Ateneo si riserva la facoltà di prorogare il contratto per il tempo necessario all’attuazione di quanto esposto.

Relativamente alle apparecchiature in locazione operativa che terminino il periodo di locazione in concomitanza con la terminazione del periodo contrattuale e per le quali l’Ateneo non eserciti la facoltà di acquisto, il Fornitore dovrà provvedere alle operazioni di ritiro previste (rif. §4.3.1.3) entro il termine di 60

(sessanta) giorni solari successivi alla data di scadenza contrattuale, secondo una pianificazione concordata con l’Ateneo e senza alcun onere aggiuntivo per l’Università.

4.1.2.5. SO.AP.PROJ – Project management

Come già evidenziato nella descrizione della fase di startup e della fase finale dell’appalto, alcuni servizi e attività oggetto dell’appalto presentano una natura progettuale, caratterizzata da obiettivi e milestone ben identificati e vincoli su tempi e precondizioni fra attività.

Per tale motivo al Fornitore è richiesto di predisporre tutte le misure necessarie per una gestione progettuale precisa e in grado di garantire il raggiungimento degli obiettivi, quali:

• una chiara identificazione di ruoli e responsabilità all’interno dei gruppi di lavoro e delle linee di riporto nell’organigramma;

• metodologie di provata efficacia nella organizzazione delle attività e nella gestione di:

o obiettivi e ambito (scope),

o rischi e criticità,

o escalation dei problemi,

o cambiamenti;

• strumenti di pianificazione, in particolare l’utilizzo di diagrammi GANTT, e di tracciatura (logging), ad esempio rispetto a rischi, criticità, change request, ecc..

In particolare, per ogni attività di natura progettuale è richiesto al Fornitore di identificare un Responsabile Operativo/Project Manager, coadiuvato da un team di lavoro (eventualmente suddiviso in sottogruppi per aree di responsabilità), che dovrà rappresentare l’interfaccia unica di comunicazione, intervento e coordinamento verso le figure preposte dall’Ateneo, quali:

• il Direttore dell’Esecuzione del Contratto (DEC),

• il Responsabile Unico del Procedimento (RUP),

• eventuale altro personale dell’Ateneo delegato dal DEC o dal RUP per casi specifici.

L’eventuale sostituzione, in corso di vigenza contrattuale, da parte del Fornitore per propria iniziativa, della risorsa incaricata del ruolo di Project Manager, dovrà essere comunicata dal Fornitore all’Ateneo con un preavviso di almeno 30 (trenta) giorni solari; nel caso, il Fornitore dovrà proattivamente mettere in atto tutte le necessarie azioni per garantire un passaggio di consegne completo e minimizzare gli eventuali impatti negativi sulla continuità ed i livelli di qualità nell’espletamento delle attività.

4.1.2.6. SO.AP.SRVC – Service management

L’oggetto principale dell’appalto è rappresentato da servizi ordinari e continuativi, caratterizzati da una gestione su medio-lungo periodo delle risorse e da una misurazione costante dei livelli di servizio.

Per tale motivo al Fornitore è richiesto di predisporre tutte le misure necessarie per una gestione dei servizi efficiente e in grado di garantire sempre i livelli di qualità previsti, quali:

• una chiara identificazione di ruoli e responsabilità all’interno dei gruppi di lavoro e delle linee di riporto nell’organigramma;

• metodologie di provata efficacia nella organizzazione delle attività e nella gestione di:

o priorità e conflitti di risorse nell’erogazione dei servizi,

o pianificazione di medio e lungo termine,

o Service Level Agreement,

o Indicatori di Qualità,

o miglioramento continuo (continuous improvement);

• strumenti di supporto, quali quelli già ampiamente illustrati nel capitolo 4.1.1.

In particolare, è richiesto al Fornitore di identificare un Responsabile Unico per la Fornitura/Service Manager, che dovrà rappresentare l’interfaccia unica di comunicazione, confronto e coordinamento verso le figure preposte dall’Ateneo, quali:

• il DEC,

• il RUP,

• eventuale altro personale dell’Ateneo delegato dal DEC o dal RUP per casi specifici.

L’eventuale sostituzione, in corso di vigenza contrattuale, da parte del Fornitore per propria iniziativa, della risorsa incaricata del ruolo di Service Manager dovrà essere comunicato dal Fornitore all’Ateneo con un preavviso di almeno 30 (trenta) giorni solari; nel caso, il Fornitore dovrà proattivamente mettere in atto tutte le necessarie azioni per garantire un passaggio di consegne completo e minimizzare gli eventuali impatti negativi sulla continuità ed i livelli di qualità nell’erogazione dei servizi.

4.2. GP – Gestione della PdL

Il servizio di gestione della PdL comprende tutte le attività di gestione di una Postazione di Lavoro per un utente, in modo da garantire all’utente stesso la costante disponibilità di una dotazione informatica HW e SW pienamente funzionante e funzionale alle sue mansioni.

Insieme al servizio di locazione operativa (rif. §4.3), rappresenta uno dei due fattori chiave su cui verrà percepita/valutata, da parte dell’Università e degli utenti interessati, la qualità dei servizi di Fleet Management di cui il Centro InfoSapienza è responsabile: nel caso specifico si tratta della “cura” verso i propri utenti, che rappresentano la forza motrice della gestione amministrativa dell’intera Università.

In tale senso l’efficacia e l’efficienza nella gestione è l’elemento essenziale e per tale motivo, come meglio dettagliato nel seguito, a tale servizio verrà riservata una componente importante nella valutazione tecnica delle soluzioni offerte dal Fornitore.

4.2.1. Condizioni generali

Il servizio ha come unità identificativa base l’Unità Centrale: ogni PdL oggetto dei servizi di Fleet Management richiede obbligatoriamente l’associazione ad una Unità Centrale gestita dal Fornitore. La contabilizzazione (in termini numerici ed economici) avverrà su base trimestrale, per tutto il periodo in cui è sottoposta a gestione.

Per quanto riguarda il numero di riferimento delle PdL per cui verrà attivato il servizio, si rimanda a quanto specificato nel capitolo 3.2.

Rientra nei servizi complessivi ambito dell’appalto, la disponibilità a erogare attività di gestione delle PdL in orari di lavoro diversi dalla finestra di servizio ordinaria (specificata di seguito) e/o ad intervenire nei giorni festivi, senza ulteriori oneri per l’Università, solo in casi eccezionali o preventivamente programmati, dietro richiesta formale dell’Università, per un monte ore complessivo sul parco macchine gestito, anche non continuativo, non superiore alle 40 ore/uomo lavorative per anno solare. In ogni caso l’erogazione di tali attività potrà essere richiesta limitatamente alla finestra dalle ore 7:00 alle ore 22:00, tutti i giorni festivi inclusi.

Il servizio è articolato in servizi elementari, illustrati nei paragrafi a seguire, accorpabili nelle seguenti categorie:

• Asset management,

• Gestione remota della PdL,

• Gestione in locale della PdL,

• Servizi di back office.

Il servizio di gestione della PdL dovrà rispettare la seguente finestra di servizio: dal lunedì al venerdì dalle ore 8:30 alle ore 17:30, esclusi i festivi.

Il Fornitore è tenuto ad erogare i servizi con competenza e professionalità, nel rispetto del livelli di qualità attesi e concordati attraverso il sistema di qualità predisposto (rif. §6).

In tale ottica, l’Ateneo ritiene pertanto determinante che il Fornitore predisponga, per ciascuna categoria di servizio, l’impiego di risorse specializzate con adeguate e comprovate competenze tecniche nonché esperienze pluriennali di Fleet Management in contesti operativi reali di classe enterprise, e che mantenga tali competenze aggiornate nel tempo e a fronte della naturale evoluzione del panorama tecnologico e del parco gestito per l’Università. Come indicato nei paragrafi seguenti interessati, la qualità delle professionalità e dell’esperienza acquisita dei profili professionali che il Fornitore intenderà impiegare nell’erogazione dei servizi di gestione della PdL, sarà un parametro di valutazione premiante in sede di valutazione dell’Offerta Tecnica.

Per tutti i servizi dell’area GP, la lingua di riferimento per le comunicazioni e l’interazione con personale e gli utenti dell’Università è la lingua italiana.

Il Fornitore deve inoltre garantire la sicurezza e la riservatezza delle informazioni gestite, anche attraverso la formalizzazione e l’applicazione di procedure da adottare internamente alla propria struttura operativa, in ossequio di quanto disposto dalla L.196/2003.

4.2.2. XX.XX – Asset management

La gestione strutturata delle informazioni sul ciclo di vita degli asset è la base per l’erogazione e la gestione di tutti i servizi richiesti e per un’ottimale pianificazione strategica e operativa.

Il servizio di asset management verrà supportato dal sistema di asset inventory illustrato nel paragrafo 4.1.1.1.

4.2.2.1. GP.AM.INVE – Inventario

Il servizio di gestione dell’inventario delle apparecchiature ha l’obiettivo di rendere disponibile e mantenere aggiornata, durante tutta la durata del contratto, una base informativa completa e dettagliata del parco macchine in servizio presso l’Ateneo e gestite dal Fornitore. Tali informazioni dovranno indirizzare:

• aspetti logistici e amministrativi, quali a titolo indicativo non esaustivo:

o dati identificativi (numero identificativo univoco, marca, modello, numero di serie, nome macchina, indirizzo IP, ecc.),

o ubicazione fisica (sede, edificio, scala, piano, stanza, ecc.),

o ufficio (ripartizione o struttura, settore, ecc.),

o utente assegnatario (matricola, nome, cognome, ecc.),

o copertura della garanzia (fornitore, data di scadenza della garanzia, ecc.),

o data di installazione presso l’utente finale;

• aspetti di configurazione HW e SW.

Il Fornitore dovrà effettuare un censimento di tutte le risorse (UC, UPP, UPW, SW) presenti nelle sedi dell’Università già previste (rif. §2.1) e riconducibili alle PdL gestite dal Fornitore stesso. Il censimento potrà partire anche da registrazioni già presenti presso l’Ateneo (quali quelli resi disponibili dalla struttura di Fleet Management pre-operante), attraverso attività di estrazione e normalizzazione dei dati, a carico del

Fornitore, ed eventuale integrazione di informazioni che il Centro InfoSapienza riterrà necessarie o opportune.

Il censimento potrà anche essere effettuato preliminarmente attraverso modalità automatizzate per la rilevazione dei componenti HW e SW, da riscontrare poi su base puntuale ed eventualmente in locale, in funzione della completezza dello strumento di discovery utilizzato e/o delle risultanze emerse. Pertanto, quando necessario, esso sarà effettuato dai tecnici del Fornitore, che effettueranno una ricognizione “fisica” presso le sedi al fine di censire gli asset informatici.

Il censimento dovrà essere completato al massimo entro 30 (trenta) giorni lavorativi dalla data di sottoscrizione del contratto.

Ogni apparecchiatura informatica dovrà essere etichettata a cura del Fornitore durante la fase di censimento, utilizzando una targhetta non asportabile e leggibile mediante appositi lettori portatili di bar-code o sistemi di rilevazione equivalenti. L’etichetta, oltre al numero identificativo univoco di inventario rappresentato a barre, dovrà riportare in chiaro almeno l’indicazione del produttore ed il numero di serie attribuito dal produttore.

La generazione e l’assegnazione del numero identificativo di inventario per apparecchiature di nuova acquisizione dovrà proseguire la progressione alfanumerica già avviata dall’Ateneo per le proprie apparecchiature già in uso; in ogni caso le regole della progressione alfanumerica dovranno essere pienamente rispondenti alle esigenze specifiche dell’Università. Anche per quanto riguarda la naming convention delle apparecchiature HW, laddove applicabile, il Fornitore sarà tenuto ad applicare le regole già utilizzate o comunque richieste dall’Ateneo.

L’inventario dovrà essere mantenuto costantemente aggiornato, riportando informazioni veritiere e accurate, con la reale situazione del parco macchine gestito, in particolare a fronte dello svolgersi dei vari servizi che interessano direttamente le PdL. Gli aggiornamenti dovranno essere effettuati possibilmente attraverso automatismi a partire dagli eventi gestionali. L’Ateneo si riserva di verificare con frequenza al più mensile il livello di correttezza e completezza dell’inventario.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.AM.INVE.1

• SL.GP.AM.INVE.2

4.2.3. GP.RM – Gestione remota della PdL

Tale categoria di servizi racchiude tutte quelle attività di gestione della PdL che possono essere realizzate da remoto, attraverso l’impiego di opportuni canali di comunicazione (es. telefono, email, ecc.) e di strumenti di supporto, quali i sistemi di software distribution (rif. §4.1.1.2), gestione remota (rif. §0), gestione antivirus e antispyware (rif. §4.1.1.6).

Nell’economia e nell’organizzazione operativa complessiva, l’Ateneo ritiene che l’attività di gestione remota deve rappresentare la modalità principale e prioritaria di intervento sulle PdL e verso le richieste degli utenti, in modo da beneficiare di una struttura operativa più snella, di tempi di servizio abbreviati, di possibili sinergie ed economie di scala per le risorse e le competenze del Fornitore, di minori esigenze logistiche presso le sedi dell’Università; tutto ciò si ritiene a vantaggio sia dell’Ateneo che del Fornitore.

Inoltre, sempre in tale ottica, l’Ateneo ritiene auspicabile che, coerentemente con quanto indicato anche per i servizi di gestione in locale (rif. §4.2.4) ed in particolare con riferimento al servizio di presidio (rif. §4.2.4.1), il Fornitore eroghi i servizi di gestione remota attraverso proprie strutture esterne alle sedi dell’Ateneo; in tale ipotesi:

• al fine di predisporre tecnologicamente l’integrazione con strutture del Fornitore esterne alle sedi dell’Ateneo, il Fornitore dovrà comunque valutare attentamente le caratteristiche del contesto tecnologico dell’Università, illustrate nel paragrafo 2.2 (in particolare rispetto alla connettività di rete), e rispettare i seguenti vincoli:

o l’integrazione/connessione verso la rete universitaria dovrà avvenire a partire da punti di origine (strutture) ben identificate e numericamente contenute;

o l’integrazione/connessione dovrà essere adeguatamente protetta da un punto di vista di sicurezza dell’informazione (ad es. attraverso una Virtual Private Network con protocolli di trasmissione cifrati) e affidabilità;

o la soluzione dovrà adeguatamente gestire le diverse casistiche di indirizzamento privato e/o pubblico per le diversi sedi dell’Università previste, come descritte nel paragrafo 2.2;

• in fase di startup dell’appalto (rif. §4.1.2.1), l’Ateneo, nel declinare le modalità tecniche e operative, si renderà disponibile in maniera collaborativa a definire la soluzione più idonea per entrambe le parti ed a valutare eventuali richieste o specificità avanzate dal Fornitore a supporto di tale organizzazione operativa.

Rimane tuttavia facoltà del Fornitore impiegare il proprio personale addetto ai servizi di gestione in locale, come indicati nel paragrafo 4.2.4, anche per i servizi di gestione remota (ad eccezione delle risorse impiegate dal servizio di Contact center – rif. §4.2.3.1).

Criteri di valutazione tecnica

In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere complessivamente le modalità organizzative e procedurali e le soluzioni tecniche proposte per l’esecuzione dei servizi di gestione remota della PdL, al fine di consentire la valutazione tecnica della bontà e congruità della soluzione proposta. In particolare saranno oggetto di valutazione i parametri indicati come note nella scheda sottostante.

Criterio	Descrizione breve		Servizi interessati
VT.GP.RM.EROG.1	Modalità di erogazione del servizio		• GP.RM.CONT • GP.RM.HDSK • GP.RM.ISWR • GP.RM.ISWS • GP.RM.ASPL • GP.RM.ASSW • GP.RM.SWDS
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
7,0	Discrezionale con soglia	2,1
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • la disponibilità e l’organizzazione di ruoli, responsabilità e risorse previste dal Fornitore; • la qualità delle competenze, professionalità ed esperienze predisposte dal Fornitore; • le metodologie di approccio alle problematiche e di organizzazione del lavoro; • l’efficacia e i livelli di standardizzazione e qualità delle modalità operative previste, in particolare in riferimento alla tracciabilità ed al monitoraggio delle attività, alla gestione della documentazione, ai meccanismi di gestione delle priorità, di rischi e criticità, di escalation, del cambiamento, di miglioramento continuo e di verifica del rispetto degli SLA e dell’applicazione del sistema di qualità; • la flessibilità ed adattabilità delle soluzioni per una gestione efficace e controllata dei casi non standard o delle esigenze estemporanee; • eventuali misure organizzative, tecniche o procedurali specifiche per affrontare gli aspetti più problematici o complessi dei servizi da erogare, soprattutto quando sottolineati nel presente capitolato; • le modalità di impiego dei sistemi di supporto previsti; • le modalità di interazione, collaborazione e condivisione con i referenti dell’Ateneo per i servizi di Fleet Management o altri servizi interessati

4.2.3.1. GP.RM.CONT – Contact center

Ogni servizio di assistenza richiesto dagli utenti / Postazioni di Lavoro gestite, dovrà essere da questi inoltrato unicamente al servizio di Contact center erogato dal Fornitore, così come eventuali successive richieste di aggiornamento sullo stato di lavorazione per richieste già aperte.

Il Fornitore dovrà predisporre una propria infrastruttura, esterna alle sedi dell’Ateneo, che riceva le richieste di assistenza attraverso una modalità multi-canale:

• (obbligatorio) numero verde telefonico, con onere del costo delle chiamate a carico del Fornitore, eventualmente limitabile alle sole chiamate da telefono fisso (in tal caso da specificare in sede di Offerta Tecnica). E’ facoltà del Fornitore predisporre un servizio di segreteria telefonica

(esclusivamente al di fuori della finestra di servizio), con richiamata (call back) dell’utente da parte del Contact center alla ripresa del servizio; tale opzione è considerata un parametro di valutazione premiante da parte dell’Ateneo (si veda il sotto-paragrafo sui criteri di valutazione tecnica);

• (obbligatorio) indirizzo email dedicato all’Università;

• (opzionale) pagine web. La disponibilità di pagine web, da utilizzarsi sia per la ricezione delle richieste, che per la consultazione diretta da parte degli utenti dello stato di lavorazione delle proprie richieste o di frequently asked questions (FAQ) e/o altre informazioni utili, è da ritenersi facoltativa per il Fornitore, tuttavia è considerata un parametro di valutazione premiante da parte dell’Ateneo (si veda il sotto-paragrafo sui criteri di valutazione tecnica).

Ai fini della qualità del servizio e per il rispetto degli SLA, è richiesto, relativamente alle richieste inoltrate al numero telefonico, che il Fornitore predisponga un risponditore automatico, in alta affidabilità, che assista il chiamante, gestendo eventualmente le attese, l’instradamento verso la migliore risorsa disponibile e/o lo smistamento su più code di lavorazione.

A titolo puramente indicativo, si fa presente che storicamente il servizio di Contact center già presente per gli attuali servizi di Fleet Management dell’Ateneo riceve una media di circa 230/250 chiamate mensili, pressoché uniformamente distribuite all’interno dell’orario di servizio (dal lunedì al venerdì dalle 8:30 alle 17:30, cfr. §4.2.1). Rimandando al paragrafo 4.2.4.6 per una migliore comprensione, si fa presente che la suddetta media include anche richieste IMAC-R qualora provenienti da utenti/PdL; tali richieste rappresentano i cosiddetti “blocchi singoli”, mentre le richieste di “blocchi massivi” di norma non transitano dal servizio di Contact center.

Il processo operativo di gestione di una richiesta al Contact center dovrà articolarsi attraverso i seguenti punti principali:

1. l’utente richiedente e la PdL vengono identificati, attraverso dei criteri di qualificazione concordati con il Centro InfoSapienza, e contestualmente viene pertanto verificato che la PdL sia effettivamente coperta dal servizio di gestione;

2. la richiesta viene tracciata (apertura di un caso o ticket) e classificata, associando le dichiarazioni dell’utente sul motivo del contatto, alle tipologie di richiesta previste dal servizio;

3. sulla base della tipologia, la richiesta viene inoltrata al servizio di Help desk (rif. §4.2.3.2);

4. se la richiesta non è pertinente con i servizi attivati ed erogati dal Fornitore, il caso viene chiuso e la richiesta deve essere inoltrata a opportuni contatti predisposti dall’Ateneo, secondo modalità da concordare fra le parti.

L’apertura del ticket costituisce l’elemento provante essenziale dell’avvenuta ricezione della richiesta, anche in considerazione della migliore user experience; pertanto è necessario, per tutti i canali disponibili, che ad ogni richiesta corrisponda l’apertura e l’assegnazione di un codice univoco per il ticket e che questo sia comunicato nel modo più congruo ed efficace possibile all’utente (es. direttamente durante la chiamata, se il canale è il numero telefonico, oppure via email o via web negli altri casi).

Alla luce di questo, l’evento di “risposta” alla richiesta si definisce nel seguente modo, in particolare ai fini del calcolo degli SLA:

• per le richieste avanzate attraverso il numero telefonico, è il momento in cui l’operatore prende in carico la telefonata e avvia l’interazione con l’utente;

• per le richieste avanzate per canali diversi dal numero telefonico, è il momento in cui gli estremi del ticket generato vengono comunicati all’utente (ad es. con l’invio di una email).

Il Centro InfoSapienza si riserva ampia e insindacabile facoltà di verificare la qualità del servizio erogato anche attraverso mistery call gestite da esperti e tecnici dell’Ateneo o di terze parti, nonché attraverso apposite campagne di auditing.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.RM.CONT.1

• SL.GP.RM.CONT.2

Criteri di valutazione tecnica

In sede di Offerta Tecnica, al Fornitore è richiesto di dettagliare le caratteristiche (tecnologiche e non) del sistema multi-canale che intende predisporre, con particolare riferimento agli aspetti facoltativi evidenziati nel paragrafo, al fine di consentire la valutazione tecnica del livello di qualità e robustezza della soluzione proposta.

Criterio	Descrizione breve		Servizi interessati
VT.GP.RM.CONT.1	Caratteristiche del sistema multi-canale		• GP.RM.CONT
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
4,0	Discrezionale	Non applicabile
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • le caratteristiche, tecnologiche e non, del sistema multi-canale proposto; • il livello di copertura e le caratteristiche tecniche/funzionali dei requisiti opzionali richiesti

4.2.3.2. GP.RM.HDSK – Help desk

Il servizio è volto alla gestione di primo livello, e possibilmente alla risoluzione attraverso attività da remoto, delle richieste pervenute attraverso il Contact center.

Il processo operativo di gestione delle richieste da parte dell’Help desk dovrà articolarsi attraverso i seguenti punti principali:

1. la richiesta viene analizzata, dettagliando il tipo di assistenza richiesta e valutandone la priorità;

2. se necessario, in caso di malfunzionamenti (presunti o reali), si provvede ad un’attività di problem determination / root cause analysis, ossia di identificazione del reale problema da risolvere, all’occorrenza utilizzando i sistemi di supporto disponibili e/o coinvolgendo attivamente l’utente chiamante;

3. la richiesta viene quindi gestita innanzitutto in modalità remota, se applicabile, attivando il servizio più idoneo:

o installazione / configurazione / aggiornamento del SW della PdL (rif. §4.2.3.3),

o assistenza nell’utilizzo della PdL o di unità periferiche o di altre risorse di rete (rif. §4.2.3.4),

o assistenza nell’utilizzo del SW della PdL (rif. §4.2.3.5),

o servizi di back office (rif. §4.2.5);

4. se la richiesta è stata risolta in modalità remota, il ticket viene chiuso, dandone opportuna comunicazione all’utente in funzione del canale utilizzato o più idoneo;

5. se la richiesta non è risolvibile in modalità remota, il ticket viene inoltrato verso la struttura preposta all’erogazione dei servizi di gestione in locale della PdL (rif. 4.2.4);

6. qualora si evidenzi che per soddisfare in tutto o in parte la richiesta sia necessario l’intervento tecnico dell’Ateneo sull’infrastruttura di propria competenza, la segnalazione dovrà essere inoltrata a opportuni contatti predisposti dall’Ateneo, secondo modalità da concordare fra le parti.

Il servizio può essere attivato anche in back office, dal servizio di monitoraggio delle Unità Periferiche (rif.

§4.2.5.2), qualora si rilevi la necessità di intervento su un’Unità Periferica (ad es. perché non funzionante o per sostituire i materiali di consumo), non segnalato da alcun utente attraverso il Contact center.

Relativamente all’assegnazione del livello di priorità alla richiesta, sono previsti tre livelli, riportati in ordine decrescente di rilevanza, a cui corrispondono diversi livelli di servizio (si veda il sotto-paragrafo seguente):

• Priorità 1 – Alta: la richiesta va gestita con il livelli di servizio massimi, con precedenza sulle restanti priorità. Tipicamente corrisponde ad un problema di tipo bloccante, per cui l’utente / la PdL non dispone della necessaria operatività minima per indisponibilità o malfunzionamento di una risorsa o perché le sue prestazioni risultano fortemente degradate.

• Priorità 2 – Media: la richiesta va gestita in un tempo congruo, con livelli di servizio medi, in considerazione della presenza o meno di richieste con priorità pari o superiore. Tipicamente corrisponde ad un problema di tipo non bloccante severo, per cui l’utente / la PdL dispone di un livello di operatività accettabile, ma le prestazioni risultano degradate o non ha accesso completo ad alcune risorse.

• Priorità 3 – Bassa: la richiesta va gestita con il livelli di servizio meno stringenti, benché sempre in un tempo congruo, in considerazione della presenza o meno di richieste con priorità pari o superiore. Tipicamente corrisponde ad un problema di tipo non bloccante non severo, per cui l’utente / la PdL dispone di adeguata operatività, ma il livello di funzionamento complessivo o l’accesso ad alcune risorse non è ottimale. In tale categoria possono rientrare a titolo di esempio anche richieste informative, richieste di componenti aggiuntive (es. software o driver da installare) o richieste di aggiornamento su ticket aperti.

L’Ateneo provvederà, in collaborazione con il Fornitore, a definire e mantenere aggiornate le regole di dettaglio per la determinazione della priorità da assegnare a ciascuna richiesta; va prevista comunque la possibilità di gestire una golden list di utenti (destinata a figure particolari e di rilievo nell’organizzazione dell’Università) per i quali la priorità può venire automaticamente innalzata rispetto ai casi standard.

La priorità assegnata ad una richiesta può comunque essere rivista e modificata nel corso della lavorazione, a fronte di nuove informazioni disponibili o della maggiore comprensione acquisita sulla natura e l’entità della richiesta.

Infine, nell’ambito dei servizi di service management (rif. §4.1.2.6), l’Ateneo potrà interagire con il Service Manager del Fornitore (o suoi delegati operativi) per determinare puntualmente priorità differenti rispetto ai casi standard laddove il contesto specifico lo richieda o nel caso in cui sia necessario attivare una procedura di escalation nella gestione dei ticket.

Nell’esecuzione del servizio di Help desk, le fasi di lavorazione attraversate, le analisi effettuate, le principali azioni intraprese, i risultati ottenuti (sia intermedi, laddove rilevanti, che definitivi) o le indicazioni fornite agli utenti (es. workaround), devono essere adeguatamente documentate e associate al ticket, attraverso la più opportuna combinazione di commenti testuali, informazioni allegate e soprattutto stati di lavorazione codificati; tali informazioni devono formare la “storia” del ticket, conservata in maniera permanente e ripercorribile in una eventuale ricostruzione logica/temporale successiva.

Per tale motivo e, altrettanto importante, per il corretto calcolo dei livelli di servizio, ogni attività e stato di lavorazione registrato, deve riportare data e ora di accadimento (timestamp), nonché l’operatore / struttura responsabile.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.RM.HDSK.1

• SL.GP.RM.HDSK.2

• SL.GP.RM.HDSK.3

• SL.GP.RM.HDSK.4

4.2.3.3. GP.RM.ISWR – Installazione / configurazione / aggiornamento SW PdL da remoto

Il servizio è volto alla gestione di tutto il software (facente parte di un catalogo di prodotti noto al Fornitore e autorizzato dall’Ateneo) e le relative configurazioni installate sull’Unità Centrale della PdL, al fine di garantire

che l’ambiente di lavoro informatizzato sia pienamente accessibile e funzionante, non presenti conflitti SW, fornisca l’accesso completo alle unità periferiche (UPP e UPW – salvo problemi loro inerenti) e/o altre eventuali risorse.

A titolo indicativo non esaustivo si riportano alcune attività tipiche previste:

• installazione / re-installazione di driver per UPP o di configurazioni per l’utilizzo di UPW,

• verifica della presenza di virus o spyware e relative azioni di rimedio,

• installazioni di patch puntuali,

• verifica di configurazioni SW o di sistema,

• installazione / re-installazione di moduli o componenti SW,

• ripristino / recupero di dati.

E’ da intendersi attivato solo dietro richiesta o segnalazione pervenuta al servizio di Contact center / Help desk, previa verifica del rispetto di policy di distribuzione prefissate dall’Ateneo e comunicate al Fornitore oppure previa condivisione con il DEC e sua esplicita approvazione (formalizzata via email). A tal proposito si precisa che, in linea generale, l’Ateneo vuole adottare una policy di gestione delle PdL per la quale i relativi utenti assegnatari non dispongano di utenze amministrative e non siano pertanto abilitati ad operazioni che modifichino la configurazione SW della PdL con diritti amministrativi; l’Ateneo si riserva di valutare, congiuntamente con il Fornitore, eventuali deroghe a tale politica generale.

Il servizio si avvale dei sistemi di supporto previsti nella fornitura (rif. §4.1.1), in particolare i sistemi di:

• software distribution,

• gestione remota delle PdL,

• gestione integrata delle utenze,

• gestione antivirus e antispyware.

Ogni variazione della configurazione della PdL dovrà comportare, se applicabile, l’aggiornamento delle relative informazioni all’interno del sistema di asset inventory (rif. §4.1.1.1).

Qualora sia possibile – organizzativamente, proceduralmente e tecnologicamente – eseguire l’attività in modalità automatica pianificata (batch) al di fuori dalle finestra di servizio, tale possibilità (non vincolante) è da ritenersi preferibile, a beneficio sia degli utenti (che non ne verrebbero interessati durante il normale orario di lavoro) che del Fornitore (in quanto il tempo dedicato ad attività fuori dalla finestra di lavoro non è conteggiato nel calcolo degli SLA – per maggiori dettagli si rimanda al paragrafo 6.3).

Qualora, per problemi tecnici, siano essi estemporanei o strutturali, il servizio di installazione / configurazione

/ aggiornamento SW delle PdL da remoto non riesca in talune occasioni a raggiungere tempestivamente e efficacemente alcune PdL (ad es. per problemi di connettività, disponibilità di banda, ecc.), in tali situazioni il Fornitore può attivare il corrispondente servizio erogato in locale (rif. §4.2.4.5), secondo le modalità già previste per il servizio generale di Help desk (rif. §4.2.3.2). Il Fornitore è tenuto alla celere e completa rimozione dei fattori ostativi alla gestione remota, se ad esso imputabili. Se invece le problematiche sono imputabili all’Ateneo, come indicato nel paragrafo 6.3 ne verrà tenuto conto nella valutazione degli SLA, tuttavia è richiesta al Fornitore comunque una collaborazione piena e proattiva con l’Ateneo per la risoluzione o per l’individuazione di efficaci workaround.

Service Level Agreement

Per gli SLA applicabili al servizio in questione si rimanda a quanto previsto per il servizio di Help desk (rif.

§4.2.3.2) in funzione della priorità della singola richiesta.

4.2.3.4. GP.RM.ASPL – Assistenza utilizzo PdL e periferiche e risorse di rete

Il servizio è volto a fornire assistenza agli utenti delle PdL gestite nell’accesso alle funzionalità delle stesse o di periferiche connesse (UPP / UPW) o di altre risorse di rete accessibili (ad es. cartelle di rete – laddove le responsabilità rientrino nell’ambito dei servizi contrattualizzati e attivati), al fine di supportare l’utente nel

mantenimento della piena operatività, di disporre di tutte le informazioni necessarie e di risolvere eventuali dubbi o difficoltà riscontrate nell’utilizzo del suo ambiente di lavoro informatizzato.

A titolo indicativo non esaustivo si riportano alcune attività tipiche previste:

• verifica dello stato dell’account dell’utente,

• supporto nel recupero o reset della password dell’account,

• verifica sullo stato di disponibilità delle risorse richieste,

• rilascio di informazioni sulla dotazione della PdL e su configurazioni di sistema,

• ripristino di configurazioni perse o corrotte,

• risoluzione di dubbi dell’utente sulle corrette procedure per l’accesso alle risorse.

L’assistenza può essere fornita sia attraverso un semplice scambio di informazioni e comunicazioni con l’utente, anche coinvolgendolo attivamente, sia ricorrendo all’ausilio dei sistemi di supporto previsti nella fornitura (rif. §4.1.1), in particolare i sistemi di:

• gestione remota delle PdL,

• gestione integrata delle utenze.

In ogni caso al Fornitore è richiesto un atteggiamento proattivo, volto a comprendere al meglio la problematica espressa dall’utente, raccogliere il maggior numero di informazioni e, soprattutto nei casi di malfunzionamenti (presunti o reali), escludendo le cause più comuni e tipicamente più facilmente risolvibili, così da minimizzare la necessità di attivare altre tipologie di servizi più complesse, quali quelle di gestione in locale della PdL (rif. §4.2.4). A tale scopo può essere utile la messa a disposizione da parte del Fornitore di FAQ consultabili attraverso pagine web, come già evidenziato per il servizio di Contact center (rif. §4.2.3.1).

Service Level Agreement

Per gli SLA applicabili al servizio in questione si rimanda a quanto previsto per il servizio di Help desk (rif.

§4.2.3.2) in funzione della priorità della singola richiesta.

4.2.3.5. GP.RM.ASSW – Assistenza utilizzo SW PdL

Il servizio è volto a fornire assistenza agli utenti delle PdL gestite nell’accesso alle funzionalità del SW installato / configurato sulla PdL, al fine di supportare l’utente nel mantenimento della piena operatività, di disporre di tutte le informazioni necessarie e di risolvere eventuali dubbi o difficoltà riscontrate nell’utilizzo del suo ambiente di lavoro informatizzato.

A titolo indicativo non esaustivo si riportano alcune attività tipiche previste:

• verifica della disponibilità di funzionalità SW installate,

• supporto nell’accesso alle funzionalità SW,

• rilascio di informazioni sulle componenti SW e sulle loro configurazioni,

• ripristino di configurazioni perse o corrotte,

• risoluzione di dubbi dell’utente sulle corrette procedure per l’accesso alle funzionalità SW.

Sono escluse dal servizio in questione, per prodotti SW diversi dal sistema operativo e da pacchetti di base o di produttività personale (es. client di posta elettronica, suite Microsoft Office, antivirus, antispyware), attività di assistenza che implichino una conoscenza funzionale e specifica del prodotto, dei processi aziendali dell’Università e della natura e semantica dei dati elaborati dall’Università, o che siano finalizzate alla formazione strutturale degli utenti.

• gestione remota delle PdL,

• gestione integrata delle utenze.

Service Level Agreement

Per gli SLA applicabili al servizio in questione si rimanda a quanto previsto per il servizio di Help desk (rif.

§4.2.3.2) in funzione della priorità della singola richiesta.

4.2.3.6. GP.RM.SWDS – Software distribution

Il servizio prevede le stesse finalità, attività e caratteristiche del servizio di installazione / configurazione / aggiornamento SW delle PdL da remoto, ma da attivarsi in caso di operazioni massive che coinvolgano l’intero insieme (oppure un determinato sotto-insieme) delle PdL gestite e che pertanto richiedono l’impiego di procedure automatizzate e pianificate sia per l’esecuzione che per il monitoraggio e controllo degli interventi.

In tale ottica il servizio è attivabile solo su richiesta (formalizzata via email) del DEC o in base a valutazioni proprie del Fornitore, previa condivisione con l’Ateneo. Il Fornitore è tenuto a prendere in carico la richiesta, identificando dei referenti responsabili della valutazione tecnica della richiesta e fornendo una pianificazione prevista, oggetto di condivisione e revisione con l’Ateneo.

Si individuano tre sotto-tipologie di richiesta / modalità di erogazione del servizio:

• aggiornamenti ordinari,

• interventi urgenti,

• evoluzioni pianificate.

Gli aggiornamenti ordinari rappresentano la necessità di interventi non urgenti, ma che appunto interessano una parte consistente (o il totale) del parco di PdL gestite. Casi tipici possono essere rappresentati da attività di patch management (ad es. sul sistema operativo delle UC) o da interventi richiesti da un singolo utente tramite il servizio di Help desk (rif. §4.2.3.2) per i quali si valuti da parte dell’Ateneo o del Fornitore l’opportunità di estendere l’intervento massivamente ad altre PdL.

A titolo indicativo non esaustivo gli interventi per aggiornamenti ordinari possono contemplare:

• patch management delle componenti SW installate sulle PdL,

• il rilascio o l’aggiornamento di script di startup sui sistemi operativi delle PdL,

• l’aggiornamento di link ad applicazioni presenti sul desktop degli utenti delle PdL,

• la distribuzione di software a determinati uffici dell’Ateneo.

La software distribution per aggiornamenti ordinari potrà essere pianificata congiuntamente fra l’Ateneo ed il Fornitore, in funzione delle caratteristiche e della complessità del singolo intervento richiesto.

Gli interventi urgenti devono invece indirizzare situazioni in cui l’operatività e/o la sicurezza informatica delle PdL è messa a serio rischio o già impattata da eventi negativi, quali la presenza di un software malware, che si propaga velocemente all’intero insieme di Pdl.

A questa necessità deve corrispondere una risposta del Fornitore, dove la tempestività è fattore critico (si veda il sotto-paragrafo su SLA). L’attività sarà erogata nella modalità più rapida possibile, proprio per far fronte all’emergenza e potrà avvenire anche al di fuori della finestra di servizio.

Le evoluzioni pianificate rappresentano invece interventi, sempre di natura massiva, caratterizzati da un profondo cambiamento della configurazione delle PdL, quali a titolo di esempio l’aggiornamento / cambiamento della versione del sistema operativo delle PdL.

La software distribution per evoluzioni pianificate potrà essere valutata e pianificata congiuntamente fra l’Ateneo ed il Fornitore, in funzione delle caratteristiche e della complessità del singolo intervento richiesto.

A titolo puramente indicativo, si fa presente che storicamente il servizio di software distribution già presente per gli attuali servizi di Fleet Management dell’Ateneo, per aggiornamenti ordinari (diversi dal patch management, di norma giornaliero) o per interventi urgenti è stato attivato mediamente una volta al mese.

Per quanto riguarda evoluzioni pianificate, allo stato attuale l’Ateneo prevede solo la necessità, secondo l’approccio illustrato nel paragrafo 5.1, di allineare la configurazione SW dell’intero parco di PdL al sistema operativo Microsoft Windows 7 o Microsoft Windows 8, intervenendo con un aggiornamento da Microsoft Windows XP per una eventuale parte residua di PdL di proprietà dell’Ateneo (HW di Proprietà) che al momento dell’avvio delle attività contrattuali dovessero presentare ancora tale sistema operativo in dismissione (attualmente circa il 65% delle PdL presenta Microsoft Windows XP installato, è tuttavia in corso una progressiva migrazione a Microsoft Windows 7).

Nel servizio di software distribution dovranno essere incluse le seguenti attività:

• pacchettizzazione del software in conformità alle regole imposte dallo strumento di distribuzione (rif.

§4.1.1.2);

• distribuzione del pacchetto su postazioni campione / di laboratorio e verifica funzionale condotta dall’Ateneo, con conseguente approvazione della distribuzione massiva;

• distribuzione del pacchetto alle apparecchiature destinatarie del software, sia a livello globale che parziale, verso specifici gruppi di utenti individuati o liste di distribuzione nominali;

• verifica dell’andamento del processo di distribuzione;

• verifica dei risultati ed eventuali azioni conseguenti;

• attivazione di eventuali azioni di rollback (recovery della versione precedente e possibile ripristino), se applicabile;

• aggiornamento dei dati di inventario relativo alla configurazione software delle apparecchiature, sul sistema di asset inventory (rif. §4.1.1.1);

• collezione del pacchetto preparato all’interno del repository documentale (rif. §4.1.1.7).

La distribuzione potrà interessare ogni componente applicativa (configurazione e/o applicazione) facente parte della Postazione di Lavoro e necessaria all’operatività degli utenti.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.RM.SWDS.1

• SL.GP.RM.SWDS.2

4.2.4. XX.XX – Gestione in locale della PdL

Tale categoria di servizi racchiude tutte quelle attività di gestione della PdL e dell’intero parco macchine gestito, che per la loro intrinseca natura o per fattori ostativi (alla gestione remota) contingenti o strutturali, devono essere realizzate in locale, ossia attraverso la presenza fisica di operatori del Fornitore presso le sedi previste dell’Università (rif. §2.1).

E’ in ogni caso assolutamente esclusa una modalità di erogazione di servizi che implichi, per la loro fruizione, l’accesso fisico degli utenti dell’Ateneo a luoghi esterni alle sedi universitarie previste.

Il Fornitore dovrà comunicare all’Ateneo i nominativi del personale incaricato per gli interventi tecnici in locale presso le sedi dell’Università, nonché comunicare tempestivamente ogni variazione. Il personale incaricato dovrà essere munito di badge identificativo riportante nominativo, foto e dati aziendali, da indossare in maniera ben visibile per tutto il periodo di presenza presso le sedi universitarie.

Sarà cura dell’Ateneo consentire l’accesso alle sedi ed ai locali universitari al personale incaricato, manlevando il Fornitore dai vincoli sugli SLA nei casi in cui i locali fossero inaccessibili per responsabilità

dell’Ateneo o per cause di forza maggiore, fermo restando l’obbligo da parte del Fornitore di documentare puntualmente ogni impedimento all’esecuzione dell’intervento.

L’Ateneo si riserva la facoltà, qualora lo ritenga opportuno e a sua totale discrezione, di affiancare proprio personale tecnico al personale incaricato del Fornitore.

In ogni caso di intervento in locale e per ogni procedura applicata, il Fornitore dovrà operare nelle modalità più consone, condivise operativamente con l’Ateneo, per preservare la sicurezza fisica e ambientale degli utenti, degli operatori dell’Università e del Fornitore, dei locali dell’Ateneo, nel pieno rispetto delle normative vigenti applicabili.

Pur rientrando negli obiettivi generali dell’Università il ricorrere alla gestione in locale solo per una quota parte quanto più possibile contenuta e minoritaria rispetto alla gestione remota (cfr. §4.2.3), tali servizi sono imprescindibili ai fini del Fleet Management complessivo. Gli elementi qualificanti da parte del Fornitore a cui l’Ateneo pone attenzione sono pertanto il modello di governo centralizzato e integrato, che assicuri continuità e omogeneità fra la gestione remota e quella in locale, e la capacità di gestire efficacemente la complessità logistica dell’organizzazione geografica dell’Ateneo (rif. §2.1).

Tali elementi saranno oggetto di valutazione tecnica, come esplicitato di seguito.

Criteri di valutazione tecnica

In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere complessivamente le modalità organizzative e procedurali e le soluzioni tecniche proposte per l’esecuzione dei servizi di gestione in locale della PdL, al fine di consentire la valutazione tecnica della bontà e congruità della soluzione proposta. In particolare saranno oggetto di valutazione i parametri indicati come note nella scheda sottostante.

Criterio	Descrizione breve		Servizi interessati
VT.GP.LC.EROG.1	Modalità di erogazione del servizio		• GP.LC.PRES • GP.LC.MAGA • GP.LC.INTL • GP.LC.MNHW • GP.LC.ISWL • GP.LC.IMAC
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
7,0	Discrezionale con soglia	2,1
Note sulle modalità di valutazione
Saranno oggetto di valutazione: • la disponibilità e l’organizzazione di ruoli, responsabilità e risorse previste dal Fornitore; • la qualità delle competenze, professionalità ed esperienze predisposte dal Fornitore; • le metodologie di approccio alle problematiche e di organizzazione del lavoro; • l’efficacia e i livelli di standardizzazione e qualità delle modalità operative previste, in particolare in riferimento alla tracciabilità ed al monitoraggio delle attività ed all’integrazione con il modello di governo dei servizi di gestione remota, in modo da garantire l’applicazione degli stessi meccanismi di controllo (gestione delle priorità, di rischi e criticità, di escalation, del cambiamento, di miglioramento continuo e di verifica del rispetto degli SLA e dell’applicazione del sistema di qualità, ecc.); • la flessibilità ed adattabilità delle soluzioni per una gestione efficace e controllata dei casi non standard o delle esigenze estemporanee; • eventuali misure organizzative, tecniche o procedurali specifiche per affrontare gli aspetti più problematici o complessi dei servizi da erogare, soprattutto quando sottolineati nel presente capitolato; • le modalità di impiego dei sistemi di supporto previsti; • le modalità di interazione, collaborazione e condivisione con i referenti dell’Ateneo per i servizi di Fleet Management o altri servizi interessati

4.2.4.1. GP.LC.PRES – Presidio

In considerazione dell’esperienza maturata dall’Università sui servizi di Fleet Management, si ritiene che il presidio, intesa quale la dislocazione permanente presso una sede dell’Ateneo di personale, sia estremamente funzionale (benché non strettamente necessario) alla migliore erogazione dei servizi di gestione in locale delle PdL.

Per tale motivo l’Ateneo intende mettere a disposizione del Fornitore, nei pressi della sede principale dell’Università, dei locali adeguatamente attrezzati ad ospitare stabilmente al più cinque risorse del team di presidio in contemporanea.

Rimane in carico al Fornitore stabilire autonomamente il numero ed i profili delle risorse ritenute necessarie ai servizi di gestione in locale, in funzione dei servizi attivati e del contesto operativo delineato.

Inoltre si evidenzia che rimane in carico al Fornitore predisporre la soluzione organizzativa, procedurale e/o tecnica più opportuna per erogare, secondo i livelli di qualità previsti, i servizi alle diverse sedi dell’Università interessate, ivi compresa la sede di Latina (rif. §2.1).

4.2.4.2. GP.LC.MAGA – Immagazzinamento

Il servizio di immagazzinamento consiste nella gestione logistica ed al deposito temporaneo di materiale HW a supporto dei servizi di gestione in locale delle PdL e di manutenzione HW (rif. §4.5), ossia nell’utilizzo di locali dedicati al deposito di apparecchiature HW (UC, UPP e UPW).

L’Ateneo ritiene che la disponibilità di locali per immagazzinamento in loco sia estremamente funzionale (benché non strettamente necessario) alla migliore erogazione dei suddetti servizi. Per tale motivo l’Ateneo potrà mettere a disposizione del Fornitore, presso la sede principale dell’Università, dei locali predisposti a tale scopo; la superficie complessiva di tali locali sarà comunque limitata (a titolo puramente indicativo nell’ordine di circa 20 mq) ed eventualmente soggetta a futura revisione in caso di mutate esigenze di qualsiasi natura da parte dell’Università.

Vige comunque il principio che ogni materiale di proprietà dell’Ateneo (HW di Proprietà, come definito nel paragrafo 3.1.1), in stato di non utilizzo per tempo indefinito, sia conservato sempre all’interno delle sedi dell’Università, salvo non siano in atto procedure di manutenzione HW che richiedano l’invio temporaneo a terzi (es. produttori o fornitori di assistenza in garanzia) o non sia stato effettuato il discarico inventariale del cespite dal patrimonio dell’Ateneo (ad es. per Rifiuti da Apparecchiature Elettriche ed Elettroniche – RAEE). Per tali materiali è obbligatorio, anche da parte del Fornitore, l’utilizzo dei locali di immagazzinamento messi a disposizione dell’Ateneo.

Rimane pertanto in carico al Fornitore:

• la responsabilità di predisporre autonomamente, presso locali di propria pertinenza esterni alle sedi dell’Ateneo, la capacità di immagazzinamento e di gestione logistica dei materiali HW di proprietà del Fornitore stesso, nella misura e nelle modalità ritenute più opportune per l’erogazione dei servizi richiesti ed il rispetto dei livelli di servizi contrattualizzati;

• l’obbligo di utilizzare gli spazi di immagazzinamento messi a disposizione dell’Ateneo per l’HW di Proprietà;

• la facoltà di utilizzare, in funzione dell’effettiva disponibilità residua, gli spazi di immagazzinamento messi a disposizione dall’Ateneo anche per la gestione del materiale di proprietà del Fornitore (a riduzione delle esigenze individuate al primo punto), assicurando in ogni istante l’inventariamento completo di quanto conservato. In tale scenario, l’Ateneo è da intendersi comunque sollevato da qualsiasi responsabilità per danni o furti sul materiale stesso per tutta la durata dell’immagazzinamento.

Si evidenzia che rimane in carico al Fornitore predisporre la soluzione organizzativa, procedurale e/o tecnica più opportuna per erogare, secondo i livelli di qualità previsti, i servizi alle diverse sedi dell’Università interessate, ivi compresa la sede di Latina (rif. §2.1).

4.2.4.3. GP.LC.INTL – Intervento tecnico in locale

Il servizio è volto alla gestione di secondo livello e alla risoluzione attraverso un intervento in locale, delle richieste pervenute attraverso il Contact center e non risolvibili da remoto attraverso il servizio di Help desk (rif. §4.2.3.2).

La modalità di gestione ed erogazione del servizio dovrà presentare continuità e omogeneità nella gestione dell’intero ciclo di vita delle richieste (ticket), integrandosi quindi con le attività già effettuate dal servizio di Help desk.

In particolare il processo operativo di gestione degli interventi tecnici in locale dovrà articolarsi attraverso i seguenti punti principali:

1. la richiesta viene presa in carico e analizzata, dettagliando il tipo di assistenza richiesta in funzione delle competenze specifiche del servizio di gestione in locale;

2. l’operatore incaricato prende contatto con l’utente richiedente per pianificare l’intervento in locale sulla PdL;

3. viene effettuato l’intervento in locale, in presenza dell’utente oppure di un sostituto incaricato, attivando il servizio più idoneo (e le relative procedure):

o intervento di manutenzione HW (rif. §4.2.4.4),

o installazione / configurazione / aggiornamento del SW della PdL (rif. §4.2.4.5),

o servizio di IMAC-R (rif. §4.2.4.6);

4. qualora si evidenzi che per soddisfare in tutto o in parte la richiesta sia necessario l’intervento tecnico dell’Ateneo sull’infrastruttura di propria competenza, la segnalazione dovrà essere inoltrata a opportuni contatti predisposti dall’Ateneo, secondo modalità da concordare fra le parti;

5. al termine dell’intervento e a fronte della risoluzione accertata, il ticket viene chiuso, dandone opportuna comunicazione all’utente in funzione del canale utilizzato o più idoneo, eventualmente impiegando il servizio di Help desk.

La richiesta eredita in principio il livello di priorità assegnato dal servizio di Help desk, da cui consegue lo specifico livello di servizio applicabile fra quelli previsti (si veda il sotto-paragrafo seguente).

La priorità è comunque modificabile nel corso della lavorazione, sia a seguito delle verifiche in loco sulla reale natura ed entità del problema sia in base ad azioni puntuali effettuate nell’ambito dei servizi di service management (rif. §4.1.2.6), come già indicato per i servizi di Help desk. Analogamente, nell’esecuzione del servizio, le fasi di lavorazione attraversate, le analisi effettuate, le principali azioni intraprese, i risultati ottenuti (sia intermedi, laddove rilevanti, che definitivi) o le indicazioni fornite agli utenti (es. workaround), devono essere adeguatamente documentate e associate al ticket, attraverso la più opportuna combinazione di commenti testuali, informazioni allegate e soprattutto stati di lavorazione codificati; tali informazioni devono formare la “storia” del ticket, conservata in maniera permanente e ripercorribile in una eventuale ricostruzione logica/temporale successiva. Per tale motivo e, altrettanto importante, per il corretto calcolo dei livelli di servizio, ogni attività e stato di lavorazione registrato, deve riportare data e ora di accadimento (timestamp), nonché l’operatore / struttura responsabile.

Ai fini della valutazione dei livelli di servizio (si veda il sotto-paragrafo seguente), va considerato il caso in cui l’operatore incaricato non riesca a contattare alcun referente per pianificare l’intervento in locale. A tal proposito, per mancata pianificabilità si intende il caso il cui l’operatore non riesca a contattare (entro un determinato tempo limite) né l’utente richiedente né un sostituto incaricato, avendo provato almeno 2 volte, sufficientemente distanziate nel tempo, via telefono e almeno 1 volta per email. A tale scopo è necessario che il servizio di Help desk, da principio o almeno nel momento in cui viene identificata la necessità di inoltrare la richiesta al servizio di gestione in locale, richieda all’utente chiamante i contatti a cui essere ricontattato e i riferimenti di un eventuale sostituto incaricato.

Ancora ai fini della valutazione dei livelli di servizio ottenuti, nei casi più complessi è possibile che per la risoluzione di una richiesta occorra un tempo di lavorazione superiore a quanto previsto dai livelli di servizio applicabili. In tal caso rientra fra gli oneri del Fornitore, quando la richiesta implica un malfunzionamento di priorità media o alta riscontrato su un’Unità Centrale o su un’Unità Periferica di Workgroup, mettere temporaneamente a disposizione, per il tempo di risoluzione necessario, un’apparecchiatura HW equivalente o superiore, adeguatamente configurata per garantire analoga operatività rispetto all’apparecchiatura malfunzionante e, nel caso di Unità Centrale, corredata di una copia dei dati di lavoro dell’utente, salvo impossibilità tecniche (relativamente alla copia dei dati) opportunamente documentate. Tale apparecchiatura

HW sostitutiva viene definita muletto. Rimane facoltà del Fornitore estendere l’impiego di muletti ad altre casistiche, al fine di garantire un più facile rispetto degli SLA anche in tali casi.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.LC.INTL.1

• SL.GP.LC.INTL.2

• SL.GP.LC.INTL.3

• SL.GP.LC.INTL.4

• SL.GP.LC.INTL.5

• SL.GP.LC.INTL.6

• SL.GP.LC.INTL.7

• SL.GP.LC.INTL.8

• SL.GP.LC.INTL.9

4.2.4.4. GP.LC.MNHW – Intervento di manutenzione HW

Il servizio è volto alla manutenzione della corretta e completa funzionalità di tutte le componenti HW (UC, UPP e UPW) facenti parte del parco macchine gestito, ossia per le quali è stato attivato un servizio di manutenzione HW (capitolo 4.5), avviando e tracciando, fino al ripristino della normale operatività, le procedure corrispondenti (in funzione della tipologia di HW).

E’ da intendersi attivato solo dietro richiesta o segnalazione pervenuta al servizio di intervento tecnico in locale (rif. §4.2.4.3).

L’intervento di manutenzione HW può prevedere in generale:

• operazioni in loco presso la PdL,

• il ritiro temporaneo della postazione per una lavorazione in laboratorio,

• il ritiro temporaneo per l’invio del materiale presso fornitori terzi nei casi di riparazione.

In ogni caso si applicano i criteri di deposito e movimentazione del materiale indicati nel paragrafo 4.2.4.2.

Ogni variazione della configurazione della PdL dovrà comportare, se applicabile, l’aggiornamento delle relative informazioni all’interno del sistema di asset inventory (rif. §4.1.1.1).

Service Level Agreement

Per gli SLA applicabili al servizio in questione si rimanda a quanto previsto per il servizio di intervento tecnico in locale (rif. §4.2.4.3) in funzione della priorità della singola richiesta; tuttavia, in caso di intervento di manutenzione HW (come specificato nella definizione degli SLA);

• i tempi massimi di risoluzione della richiesta vengono estesi a 30 (trenta) giorni solari, previa assegnazione di muletto, nel caso sia necessaria la riparazione/sostituzione di componenti;

• il conteggio dei tempi è sospeso per attività/servizi in carico a fornitori terzi per contratto diretto con l’Università.

4.2.4.5. GP.LC.ISWL – Installazione / configurazione / aggiornamento SW PdL in locale

Il servizio prevede analoghe finalità e attività del corrispondente servizio da remoto (rif. §4.2.3.3), ma viene erogato in locale nei casi di necessità, esclusivamente all’interno della normale finestra di servizio.

Ogni variazione della configurazione della PdL dovrà comportare, se applicabile, l’aggiornamento delle relative informazioni all’interno del sistema di asset inventory (rif. §4.1.1.1).

Service Level Agreement

Per gli SLA applicabili al servizio in questione si rimanda a quanto previsto per il servizio di intervento tecnico in locale (rif. §4.2.4.3) in funzione della priorità della singola richiesta.

4.2.4.6. GP.LC.IMAC – Install / Move / Add / Change / Remove (IMAC-R)

Il servizio rappresenta l’insieme di possibili operazioni che definiscono, manutengono ed evolvono l’intero parco macchine oggetto dei servizi di Fleet Management:

• Install – Installazione: rappresenta il rilascio di nuove apparecchiature HW, di tipo UC, e comporta quindi un’estensione del parco macchine gestito.

• Move – Movimentazione: rappresenta una variazione sulla dislocazione organizzativa/logistica delle componenti (UC, UPP, UPW), a parità di parco macchine gestito.

• Add – Aggiunta: rappresenta il rilascio o la condivisione di nuove apparecchiature HW, di tipo UPP e UPW (è invece da escludere il rilascio di nuove UC, per le quali è più opportuno far riferimento all’operazione Install), e comporta quindi un arricchimento della complessità del parco macchine.

• Change – Modifica: consiste nella variazione della configurazione HW delle singole apparecchiature (UC, UPP, UPW) del parco macchine, rimanendo invariato il dimensionamento complessivo.

• Remove – Disinstallazione / rimozione: rappresenta la dismissione di apparecchiature HW (UC, UPP, UPW) facenti parte del parco macchine, con una sua conseguente riduzione.

Per maggiori dettagli sulle singole operazioni si rimanda ai paragrafi seguenti. Tali operazioni rispondono a diverse esigenze:

• la crescita del parco macchine ed in generale degli ambienti di lavoro informatizzati forniti agli utenti (Install, Add),

• la manutenzione preventiva ed evolutiva (Install/Add + Remove),

• il rinnovamento tecnologico del parco macchine (Install/Add + Remove),

• l’allineamento continuo con le strutture organizzative (Change, Move),

• l’ottimizzazione dell’allocazione delle apparecchiature HW gestite (Change, Move).

In tale ottica, le richieste di servizi di IMAC-R possono provenire sia da utenti / PdL, attraverso la richiesta di interventi tecnici in locale (originariamente pervenuti tramite il servizio di Contact center – rif. §4.2.3.1), sia direttamente dai referenti dell’Ateneo per i servizi di Fleet Management.

Al Fornitore è anche richiesto, al fine di fornire i servizi di Fleet Management di migliore qualità, efficienza e sostenibilità complessiva, di analizzare e promuovere proattivamente la manutenzione preventiva ed evolutiva del parco macchine gestito.

In linea generale ogni richiesta di servizi di IMAC-R va convalidata dall’Ateneo, ossia deve essere valutata e approvata dal DEC:

• se la richiesta proviene da un utente / PdL, il DEC deve venir informato della richiesta e deve esprimere la propria approvazione (formalizzata via email). In fase operativa, il DEC potrà definire e condividere con il Fornitore eventuali regole parametriche di convalida automatica di determinate richieste (es. per specifiche operazioni Add relative a UPP o UPW fino a determinate soglie limite);

• se l’intervento è proposto dal Fornitore, si applicano gli stessi criteri del caso precedente;

• se la richiesta proviene dal DEC, è da intendersi ovviamente come convalidata all’origine.

In generale, gli interventi IMAC-R devono essere effettuati attraverso un’opportuna pianificazione. Nei casi più complessi il Fornitore è infatti tenuto a prendere in carico la richiesta convalidata, identificando dei referenti responsabili della valutazione tecnica della richiesta e fornendo una pianificazione prevista, oggetto di condivisione e revisione con l’Ateneo.

La complessità dell’intervento del servizio di IMAC-R è in prima istanza collegato con la numerosità delle operazioni coinvolte. Ai fini di una gestione più efficace di tale servizio ed al calcolo degli SLA applicabili (si veda il sotto-paragrafo seguente), si definiscono i seguenti termini:

• Blocco di operazioni IMAC-R: è costituito dalla richiesta unitaria di più operazioni da eseguire e pianificare contestualmente/contemporaneamente, ad esempio la sostituzione di più UC che può quindi comportare più operazioni Remove e Install.

• Blocco singolo: è definito come una richiesta semplice, che interessa un numero singolo/esiguo di PdL e soprattutto implica un numero ristretto di operazioni IMAC-R (al più 10). Esempi tipici possono essere la richiesta di sostituzione di una PdL o di una UPW da parte del DEC o la richiesta di aggiunta di una UPP da parte di un utente.

• Blocco massivo: è definito come una richiesta di complessità medio-alta, che interessa un numero più o meno consistente di PdL e soprattutto implica un numero significativo di operazioni IMAC-R. Esempi tipici possono essere la sostituzione di PdL per un intero ufficio, il trasloco di un ufficio o il rinnovo tecnologico massivo di apparecchiature HW. La gestione di blocchi massivi più complessi può di fatto assumere una connotazione progettuale (coinvolgendo i servizi di project management – rif. §4.1.2.5), richiedendo pertanto una valutazione e pianificazione congiunta fra l’Ateneo ed il Fornitore, specifica di caso in caso.

Al Fornitore è richiesto di erogare un numero di operazioni IMAC-R per anno (ossia ogni 12 mesi, dalla data di sottoscrizione del contratto) pari al più al 100% del numero massimo di PdL gestite trimestralmente nell’anno di riferimento. In altri termini: ricordando che la numerosità delle PdL gestite nell’ambito dei servizi di Fleet Management in linea generale può variare trimestralmente, secondo i princìpi indicati nel capitolo 3.2, nell’arco dell’anno (ossia ogni 12 mesi, dalla data di sottoscrizione del contratto) andrà considerato il numero massimo di PdL gestite nei quattro trimestri; tale numero massimo rappresenterà il numero di operazioni IMAC-R al più richieste al Fornitore per l’anno medesimo. Dal conteggio sono escluse le operazioni Install, che si considerano univocamente associate al servizio di locazione operativa illustrato nel capitolo 4.3, e le relative operazioni Remove al termine della locazione operativa (rif. §4.3.1.3). Più in generale si precisa che un singolo intervento concordato su una PdL che preveda più operazioni IMAC-R elementari (es. un’operazione Move con un’operazione Add contestuale) verrà conteggiato come una sola operazione IMAC-R.

L’Ateneo riterrà un elemento premiante in sede di valutazione tecnica, la disponibilità del Fornitore ad eseguire un numero superiore di operazioni IMAC-R annue; si veda a tal proposito il sotto-paragrafo seguente sui criteri di valutazione tecnica.

Nelle operazioni Move può essere inclusa la necessità di un trasloco dell’apparecchiatura HW fra le sedi universitarie interessate (rif. §2.1), con oneri organizzativi, logistici ed economici a carico del Fornitore.

In linea generale, il servizio IMAC-R richiede l’attivazione dei servizi di locazione operativa (rif. §4.3) e/o manutenzione HW (rif. §4.5) e/o ritiro RAEE (rif. §4.6) per le apparecchiature HW interessate.

Tutti i blocchi di operazioni IMAC-R eseguiti dal Fornitore dovranno essere rendicontanti e verbalizzati in un documento denominato Rapporto di Intervento, il cui modello verrà concordato fra le parti, controfirmato dall’utente beneficiario. I rapporti in originale verranno conservati dal Fornitore e resi disponibili se richiesti o in caso di contenzioso, mentre una copia elettronica verrà depositata nel sistema di repository documentale (rif. §4.1.1.7).

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.LC.IMAC.1

• SL.GP.LC.IMAC.2

• SL.GP.LC.IMAC.3

• SL.GP.LC.IMAC.4

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda rendere disponibile un numero superiore di operazioni IMAC-R per anno, ossia fino al 200% del numero massimo di PdL gestite trimestralmente nell’anno (escludendo dal computo le operazioni Install), in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore si impegna ad erogare un numero di operazioni IMAC-R per anno (escludendo le operazioni Install e Remove connesse con il servizio di locazione operativa LO) pari al più al 200% del numero massimo di PdL gestite trimestralmente nell’anno, nel rispetto di tutte le caratteristiche del servizio richiesti contrattualmente dall’Ateneo, senza ulteriori oneri per l’Ateneo rispetto ai canoni offerti in fase di offerta”.

Criterio	Descrizione breve		Servizi interessati
VT.GP.LC.IMAC.1	Numerosità di operazioni disponibili		• GP.LC.IMAC
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
4,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore si impegna ad erogare un numero di operazioni IMAC-R per anno (escludendo le operazioni Install e Remove connesse con il servizio di locazione operativa LO) pari al più al 200% del numero massimo di PdL gestite trimestralmente nell’anno, nel rispetto di tutte le caratteristiche del servizio richiesti contrattualmente dall’Ateneo, senza ulteriori oneri per l’Ateneo rispetto ai canoni offerti in fase di offerta”

4.2.4.6.1. Install – Installazione

L’operazione prevede almeno le seguenti attività, riportate a titolo esemplificativo, anche se non esaustivo:

• trasporto del materiale presso la sede universitaria di destinazione;

• etichettatura dell’apparecchiatura con numero di censimento inventariale, coordinandosi con l’Ateneo perché provveda contestualmente alle dovute operazioni di gestione del registro dei cespiti;

• consegna dell’apparecchiatura all'utente finale nel sito di destinazione;

• assemblaggio dei singoli componenti;

• sistemazione delle apparecchiature sugli appositi arredi;

• collegamento dei singoli componenti alla rete elettrica e alla rete dati;

• configurazione di base dell’apparecchiatura (es. in caso di UC: generazione da immagine standard, valorizzazione del nome macchina e della descrizione dell’unità, iscrizione nel dominio di utenze, ecc.)

• configurazione in rete locale e geografica, utilizzando gli indirizzi IP e gli indirizzi di posta elettronica rilasciati dall’Ateneo;

• ripristino/importazione, secondo le procedure concordate con l’Ateneo, di eventuali componenti software non standard e/o di archivi di dati e/o di profili utente;

• test di funzionalità per l'accettazione dell'apparecchiatura da parte dell'utente o del responsabile della stessa, comprensivo, ove applicabile, di:

o primo logon da parte dell’utente,

o verifica dell’effettivo stato di funzionamento e aggiornamento del SW antivirus e antispyware,

o verifica di eventuali impostazioni di firewalling o internet proxying,

o verifica dell’effettivo stato di funzionamento dei sistemi di supporto alla gestione remota (rif.

§4.1.1);

• ritiro (eventuale) delle apparecchiature preesistenti (corrispondente all’operazione Remove, se richiesta);

• consegna di eventuale materiale accessorio disponibile, anche documentale (es. manualistica d’uso), facente parte del corredo dell’apparecchiatura;

• recupero degli imballi e dei materiali di trasporto e smaltimento secondo le norme vigenti o, se concordato, trasporto in specifico luogo indicato dall’Ateneo.

In fase di startup dell’appalto (rif. §4.1.2.1), verrà definita congiuntamente fra le parti la procedura di dettaglio per l’esecuzione dell’operazione.

Laddove necessaria, rimane in carico all’Ateneo la responsabilità dell’attività propedeutica di site preparation, ossia di corretta predisposizione dei locali e dell’infrastruttura complessiva per ricevere la nuova apparecchiatura da installare (es. predisposizione dell’impianto dati o di quello elettrico).

4.2.4.6.2. Move – Movimentazione

L’operazione prevede almeno le seguenti attività, riportate a titolo esemplificativo, anche se non esaustivo:

• disinstallazione dell’apparecchiatura e dei dispositivi aggiuntivi;

• imballaggio dei diversi componenti;

• trasporto delle apparecchiature nel sito di destinazione;

• installazione dell’apparecchiatura e dei dispositivi aggiuntivi e riconfigurazione secondo i parametri relativi al nuovo sito.

In fase di startup dell’appalto (rif. §4.1.2.1), verrà definita congiuntamente fra le parti la procedura di dettaglio per l’esecuzione dell’operazione.

4.2.4.6.3. Add – Aggiunta

L’operazione è da intendersi operativamente come un caso semplificato dell’operazione Install, a cui si rimanda per ulteriori informazioni.

4.2.4.6.4. Change – Modifica

L’operazione è da intendersi operativamente come un caso semplificato dell’operazione Install, per la parte che interessa la gestione delle configurazioni, a cui si rimanda per ulteriori informazioni.

Può essere prevista preliminarmente un’attività di backup dei dati, ove applicabile.

4.2.4.6.5. Remove – Disinstallazione / rimozione

Le attività di disinstallazione potranno essere effettuate sia contestualmente ad un’operazione Install, quando richiesto, che separatamente.

Normalmente sono incluse le attività di:

• disattivazione delle funzionalità HW e SW del sistema da disinstallare;

• eventuale disconnessione fisica e logica dalla rete;

• cancellazione irreversibile di tutti i dati personali e/o dell’Ateneo (se applicabile), con eventuale salvataggio preliminare verso dispositivi o risorse di rete concordate con l’Ateneo;

• disassemblaggio delle apparecchiature;

• rimozione dell’etichettatura inventariale, coordinandosi con l’Ateneo perché provveda contestualmente alle dovute operazioni di gestione del registro dei cespiti;

• bonifica del sito, ossia la raccolta ordinata dei cavi delle apparecchiature disinstallate e posizionamento degli stessi all’interno di contenitori predisposti per il deposito o il trasporto;

• predisposizione al trasporto.

L’operazione Remove può attivare, ove richiesto, anche il servizio di ritiro RAXX, descritto nel capitolo 4.6: in tal caso rientra nell’operazione (e quindi nei livelli di servizio connessi) il ritiro del materiale dalla sede universitaria al fine di liberare gli spazi occupati (per le successive attività di smaltimento effettivo si applicano i livelli di servizio indicati nel capitolo 4.6).

In fase di startup dell’appalto (rif. §4.1.2.1), verrà definita congiuntamente fra le parti la procedura di dettaglio per l’esecuzione dell’operazione.

4.2.5. XX.XX – Servizi di back office

Tale categoria di servizi racchiude alcune attività, che pur avendo come oggetto e dimensione di riferimento le PdL e gli utenti assegnatari, hanno come destinatario primario i referenti dell’Ateneo per i servizi di Fleet Management nelle loro funzioni di governo del servizio e dell’infrastruttura necessaria; per tale motivo sono definiti servizi di back office.

4.2.5.1. GP.BO.ACCN – Gestione account e profilazioni PdL

Il servizio consiste nella manutenzione attiva dell’insieme di account degli utenti e delle PdL, gestiti attraverso il sistema di gestione integrata delle utenze (rif. §4.1.1.5), e delle loro profilazioni.

Le attività previste sono, a titolo indicativo non esaustivo:

• creazione, modifica, sospensione o eliminazione di account;

• gestione degli account all’interno di sotto-domini gerarchici o in gruppi;

• creazione o modifica di cartelle condivise centralizzate;

• gestione dei diritti di accesso alle cartelle condivise centralizzate per gli account utente.

Le richieste di servizio possono provenire sia da utenti / PdL, attraverso il servizio di Contact center / Help desk (rif. §4.2.3.2), sia direttamente dai referenti dell’Ateneo per i servizi di Fleet Management.

In linea generale ogni richiesta del servizio va convalidata dall’Ateneo, ossia deve essere valutata e approvata dal DEC

• se la richiesta proviene dal DEC stesso, è da intendersi ovviamente come convalidata all’origine.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.BO.ACCN.1

4.2.5.2. GP.BO.MNUP – Monitoraggio Unità Periferiche di rete

Il servizio consiste nel controllo ordinario continuo da remoto dello stato di funzionamento delle Unità Perifiche di rete gestite, sia Personali che di Workgroup, affinché, a titolo di esempio non esaustivo:

• siano sempre visibili sulla rete (on-line);

• lo stato del SW sia sempre operativo e in grado di servire le richieste (ad es. le code di stampa non siano bloccate, nel caso di stampanti);

• i meccanismi HW siano funzionanti (ad es. risolvendo eventuali inceppamenti di carta, nel caso di stampanti);

• i materiali di consumo non siano esauriti (es. toner, nel caso di stampanti).

Il servizio dovrà attivarsi per la risoluzione di eventuali anomalie, segnalandole al servizio di Help desk (rif.

§4.2.3.2). In fase operativa, l’Ateneo concorderà con il Fornitore le specifiche di dettaglio dei casi e delle segnalazioni ritenute anomalie, per le quali intervenire (ad es. stabilendo con precisione quando un segnale di avvertimento di toner in esaurimento diviene anomalia).

Il servizio si avvale dei sistemi di supporto previsti nella fornitura (rif. §4.1.1), in particolare i sistemi di:

• gestione remota delle Unità Periferiche di rete,

• asset inventory,

• gestione remota delle PdL,

laddove le Unità Periferiche gestite presentino le caratteristiche tecniche necessarie per una gestione in remoto.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.BO.MNUP.1

4.2.5.3. GP.BO.CSAT – Valutazione e rendicontazione della customer satisfaction

Il servizio prevede una rilevazione e valutazione del livello di soddisfazione degli utenti nella fruizione dei servizi di Fleet Management.

Al Fornitore è richiesto di predisporre le opportune metodologie, organizzazione, competenze e processi, affinché, con l’ausilio degli strumenti di supporto previsti (gestione della customer satisfaction – rif. §4.1.1.8 - e reportistica e SLA management – rif. §4.1.1.9), l’attività e i risultati vengano strutturati in maniera chiara, ripetibile, confrontabile e misurabile tramite specifici Indicatori di Qualità (rif. §6.2).

L’Ateneo prevede due tipologie di campionamenti e analisi:

• verifica su base semestrale della customer satisfaction puntuale e contestuale all’evasione delle richieste di servizio avanzate dall’utente / PdL verso il servizio di Contact center (rif. §4.2.3.1);

• verifica su base annuale della customer satisfaction complessiva da parte degli utenti per l’intero corpo di servizi di Fleet Management.

A queste due tipologie corrispondono due specifici Indicatori di Qualità (codici IQ.03.CSAT.1 e IQ.03.CSAT.2); al Fornitore è richiesto, in sede di Offerta Tecnica, di esplicitare il modello di calcolo che prevede di utilizzare per la determinazione di tali indicatori (si veda il sotto-paragrafo seguente sui criteri di valutazione tecnica).

In fase operativa, le attività saranno guidate da un piano di campionamento predisposto dal Fornitore e approvato dall’Ateneo.

In fase di valutazione periodica dei risultati in maniera congiunta fra le parti, al Fornitore è altresì richiesto un approccio proattivo nel proporre azioni di correzione e/o miglioramento, anche identificando livelli target da raggiungere in campionamenti successivi.

Service Level Agreement

Al servizio si applicano i seguenti SLA:

• SL.GP.BO.CSAT.1

• SL.GP.BO.CSAT.2

Criteri di valutazione tecnica

In sede di Offerta Tecnica, al Fornitore è richiesto di descrivere complessivamente le modalità organizzative, metodologiche e procedurali proposte per l’esecuzione del servizio di valutazione e rendicontazione della customer satisfaction, al fine di consentire la valutazione tecnica del livello di qualità e congruità della soluzione proposta. In particolare saranno oggetto di valutazione i parametri indicati come note nella scheda sottostante.

Criterio	Descrizione breve		Servizi interessati
VT.GP.BO.CSAT.1	Modalità di erogazione del servizio		• GP.BO.CSAT
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
4,0	Discrezionale	Non applicabile
Note sulle modalità di valutazione
In particolare saranno oggetto di valutazione: • la disponibilità e l’organizzazione di ruoli, responsabilità e risorse previsti; • le metodologie di campionamento, le tipologie di questionari previsti (es. domanda aperta / chiusa / risposta multipla, ecc.), i fattori oggetto delle domande, la modellazione dei dati e degli indicatori di soddisfazione / Indicatori di Qualità; • la gestione in itinere di campionamenti statisticamente poco rilevanti; • il processo di miglioramento continuo; • le modalità di impiego dei sistemi di supporto previsti; • le modalità di interazione, collaborazione e condivisione con i referenti dell’Ateneo per i servizi di Fleet Management

4.3. LO – Locazione operativa

Il servizio di locazione operativa consiste nella fornitura di apparecchiature HW come parte della dotazione delle PdL gestite dal Fornitore per l’Ateneo; tale fornitura dovrà erogata nel rispetto di quanto disciplinato nel presente capitolo.

Come analogamente espresso per il servizio di gestione della PdL (rif. §4.2), si evidenzia che la locazione operativa rappresenta il secondo fattore chiave su cui verrà percepita/valutata, da parte dell’Università e degli utenti interessati, la qualità dei servizi di Fleet Management di cui il Centro InfoSapienza è responsabile: nel caso specifico, si tratta di rendere disponibili agli utenti le adeguate dotazioni HW necessarie per gli ambienti di lavoro informatizzati.

In tale senso la qualità ed il livello prestazionale delle apparecchiature è l’elemento essenziale e per tale motivo, come meglio dettagliato nel seguito, anche a tale servizio verrà riservata una componente importante nella valutazione tecnica delle soluzioni offerte dal Fornitore.

4.3.1. Condizioni generali

E’ prevista la locazione operativa di tre differenti tipologie di HW, per la cui definizione si rimanda al paragrafo 3.1.1:

• Unità Centrale,

• Unità Periferica Personale,

• Unità Periferica di Workgroup.

Per quanto riguarda il numero di riferimento per le varie apparecchiature HW per cui verrà attivato il servizio, si rimanda a quanto specificato nel capitolo 3.2.

Nei seguenti paragrafi si illustrano le caratteristiche richieste per ogni tipologia di apparecchiatura; in particolare vengono riportate:

• le caratteristiche minime obbligatorie, che ogni apparecchiatura rilasciata dal Fornitore deve rispettare;

• le caratteristiche minime migliorative (laddove applicabili), che rappresentano un innalzamento opzionale del livello di caratteristiche minime che il Fornitore si impegna a rispettare e costituiscono un elemento premiante in fase di valutazione tecnica dell’offerta del Fornitore, come indicato con maggior dettaglio nel seguito.

La fornitura in locazione operativa dovrà conformarsi ai requisiti di seguito indicati:

1. Tutte le apparecchiature dovranno rispettare sia le caratteristiche minime sopra menzionate sia i requisiti di conformità illustrati nel paragrafo 4.3.1.4. Dovrà essere prodotta nell’Offerta Tecnica tutta la certificazione (quale documentazione tecnica o certificazione del fabbricante o una relazione di prova

di un organismo internazionale riconosciuto) attestante il rispetto di tali caratteristiche e requisiti per le apparecchiature fornite.

2. Le apparecchiature dovranno rappresentare beni esistenti sul mercato, essere nuove di fabbrica, ed essere costruite utilizzando parti nuove.

3. Il rilascio di ogni apparecchiatura corrisponderà ad un’operazione Install nell’ambito del servizio IMAC- R e pertanto dovrà avvenire secondo le modalità indicate nel paragrafo 4.2.4.6.

4. Il Fornitore dovrà certificare e garantire l’interoperabilità di tutti i componenti che costituiscono la soluzione proposta.

5. Per tutto il periodo di locazione operativa, la singola apparecchiatura HW dovrà essere coperta anche da tutti i servizi di manutenzione HW, così come descritti nel capitolo 4.5, senza ulteriori oneri per l’Ateneo.

6. Per ciascuna apparecchiatura dovrà essere fornita una copia digitale della manualistica tecnica completa, edita dal produttore; la documentazione dovrà essere in lingua italiana oppure, se non prevista, in lingua inglese.

Per le tipologie di UP di stampa, la fornitura in locazione operativa dovrà prevedere un primo kit completo di materiali di consumo, nella capacità massima disponibile, come specificato nei singoli paragrafi interessati. Per materiali di consumo si intendono tutte le componenti tecniche interne all’apparecchiature HW, consumabili e sostituibili, secondo procedure standard, quali toner, drum, cartucce, ecc.; è esclusa dai materiali di consumo considerati la carta o qualsiasi altro supporto di stampa. I materiali di consumo devono essere originali del produttore dell’apparecchiatura HW. E’ facoltà del Fornitore offrire, come dotazione iniziale inclusa nel servizio, un secondo kit completo di materiali di consumo, nella capacità massima disponibile; tale opzione sarà ritenuta premiante in fase di valutazione dell’Offerta Tecnica del Fornitore, secondo i criteri dettagliati nei singoli paragrafi interessati.

Nei paragrafi seguenti si dettagliano ulteriori caratteristiche del servizio di locazione operativa relativamente ad alcuni temi specifici.

4.3.1.1. Aggiornamento tecnologico

Fra gli obiettivi dell’Ateneo per i servizi di Fleet Management rientra il garantire con continuità ai propri utenti apparecchiature quanto più possibile allineate rispetto allo stato dell’arte tecnologico e di mercato, al fine di offrire sempre i più validi strumenti disponibili e, da un punto di vista gestionale, assicurarsi sempre i vantaggi derivanti dal continuo aggiornamento appunto della tecnologia e dell’offerta di mercato.

Per tale motivo, il Fornitore:

• in sede di Offerta Tecnica, dovrà descrivere dettagliatamente i prodotti offerti e le caratteristiche delle apparecchiature proposte, nel rispetto di tutti i requisiti generali già espressi (rif. §4.3.1). Tali prodotti saranno oggetto di valutazione tecnica, come dettagliato nei paragrafi seguenti;

• in seguito, per tutta la durata contrattuale, dovrà includere i prodotti offerti in sede di Offerta Tecnica in un più generale catalogo di prodotti, per tutte le tipologie di apparecchiature HW previste dal presente capitolato, da cui l’Ateneo, nell’attivare i servizi di locazione operativa, potrà di volta in volta selezionare le apparecchiature più idonee per le proprie necessità. Naturalmente ogni prodotto presente nel catalogo dovrà sempre rispettare i requisiti generali già espressi (rif. §4.3.1), in particolare le caratteristiche minime (obbligatorie o migliorative, a seconda di quanto offerto dal Fornitore in sede di Offerta Tecnica); l’Ateneo potrà procedere a tutte le verifiche del caso per assicurarsi tale conformità.

Nell’ottica degli obiettivi dell’Ateneo menzionati all’inizio del paragrafo, il Fornitore è pertanto invitato, sfruttando i meccanismi e le naturali evoluzioni tecnologiche e di mercato, a rendere sempre più vantaggiosi i propri servizi nel corso del contratto, proponendo prodotti a catalogo con caratteristiche incrementate a costi pari a quanto stabilito in sede di Offerta.

Il catalogo dovrà essere aggiornato ogni 6 mesi e all’occorrenza nei seguenti casi:

• per cessata produzione di qualche prodotto/bene precedentemente incluso nel catalogo,

• per necessario/opportuno aggiornamento della componentistica,

• quando le parti ne concordino la necessità/opportunità.

4.3.1.2. Durata del noleggio

Ogni singolo servizio di locazione operativa (ossia relativo ad una singola apparecchiatura HW fra quelle previste) dovrà avere una durata fissa pari a 36 (trentasei) mesi, a decorrere dalla data di effettivo rilascio dell’apparecchiatura (ossia dalla data verbalizzata dell’operazione Install del servizio IMAC-R, rif. §4.2.4.6).

Ai fini della rendicontazione del servizio, la locazione operativa di un’apparecchiatura HW verrà conteggiata (e corrisposta economicamente) dal trimestre contrattuale in cui è avvenuto il rilascio, per una durata di 12 (dodici) trimestri consecutivi, salvo terminazione anticipata secondo le condizioni riportate nel paragrafo

4.3.1.3 (per trimestri contrattuali si intendono i periodi di tre mesi consecutivi, calcolati a partire dalla data di sottoscrizione del contratto).

L’Ateneo potrà attivare, nei limiti dei corrispettivi economici complessivi, il servizio di locazione operativa per determinate apparecchiature in qualsiasi mese/trimestre facente parte del periodo di vigenza contrattuale.

4.3.1.3. Condizioni di terminazione

Per ciascuna apparecchiatura HW per cui verrà attivato il servizio di locazione operativa, si applicheranno le seguenti condizioni di terminazione:

a. La locazione operativa terminerà alla data di conclusione dell’appalto, salvo non siano già trascorsi i 36 mesi della durata naturale (rif. §4.3.1.2) della locazione medesima.

b. L’Ateneo potrà richiedere, in qualsiasi momento e a proprio arbitrario e insindacabile giudizio, la terminazione anticipata della locazione operativa, che diverrà effettiva al termine del trimestre contrattuale in cui è stata richiesta.

c. Qualora la locazione operativa venga terminata prima della data di naturale scadenza del noleggio, l’Ateneo dovrà aderire obbligatoriamente ad una delle seguenti opzioni mutuamente esclusive:

1. corrispondere una penale di restituzione anticipata, secondo le condizioni esposte nel paragrafo 4.3.1.3.1;

2. attivare il servizio di riscatto da locazione operativa per la specifica apparecchiatura HW considerata, così come illustrato nel capitolo 4.4;

3. nel solo caso in cui è sopraggiunta la conclusione dell’appalto, sarà facoltà dell’Ateneo richiedere (in forma scritta) il prolungamento del servizio di locazione operativa, a stessi patti e condizioni, per un periodo rimanente a scelta dell’Ateneo, al più uguale al periodo residuo di noleggio (ossia al più fino a decorrenza della data di scadenza naturale). In tale caso, il Fornitore sarà obbligato a soddisfare la richiesta dell’Ateneo; l’attivazione di tale opzione è strettamente limitata al servizio di locazione operativa (comprensivo delle attività di manutenzione HW correlate) e non implica né può applicarsi agli altri servizi oggetto dell’appalto.

d. Infine, in tutti i casi in cui la locazione operativa dovesse giungere al termine naturale del noleggio, l’Ateneo avrà la possibilità di attivare il servizio di riscatto da locazione operativa per la specifica apparecchiatura HW considerata, così come illustrato nel capitolo 4.4.

Al termine della locazione operativa, eccettuato il caso di attivazione del servizio di riscatto, il Fornitore è tenuto al ritiro dell’apparecchiatura, senza ulteriori oneri a carico dell’Ateneo al netto di eventuali penali di restituzione anticipata applicabili; tale ritiro corrisponderà ad un’operazione Remove nell’ambito del servizio IMAC-R e pertanto dovrà avvenire secondo le modalità indicate nel paragrafo 4.2.4.6.

4.3.1.3.1. Penale di restituzione anticipata

Nel caso di restituzione anticipata, l’Ateneo corrisponderà al Fornitore un importo per singola apparecchiatura pari al 90% dei canoni trimestrali di locazione operativa residui non più dovuti.

In altri termini, dati:

• CA: canone trimestrale offerto dal Fornitore per il servizio di locazione operativa dell’apparecchiatura HW del generico tipo A;

• i: numero d’ordine del trimestre contrattuale in cui viene richiesta la restituzione anticipata (che avrà effetto dal termine del trimestre);

l’Ateneo corrisponderà l’importo PAi dovuto, secondo la seguente formula:

PAi = 90% x (12 – i) x CA.

La Tabella 3 riporta i singoli valori PAi per ogni trimestre i.

I	PAi
12	-
11	0,9 x CA
10	1,8 x CA
9	2,7 x CA
8	3,6 x CA
7	4,5 x CA
6	5,4 x CA
5	6,3 x CA
4	7,2 x CA
3	8,1 x CA
2	9,0 x CA
1	9,9 x CA

Tabella 3 – Importi da corrispondere in caso di restituzione anticipata del servizio di locazione operativa

4.3.1.4. Requisiti di conformità

Le apparecchiature fornite in locazione operativa devono essere munite dei marchi di certificazione riconosciuti da tutti i Paesi dell’Unione Europea e devono essere conformi alle norme relative alla compatibilità elettromagnetica.

Il Fornitore dovrà garantire la conformità delle apparecchiature alle normative CEI o ad altre disposizioni internazionali riconosciute e, in generale, alle vigenti norme legislative, regolamentari e tecniche disciplinanti i componenti e le modalità di impiego delle apparecchiature medesime ai fini della sicurezza degli utilizzatori.

A titolo esemplificativo e non esaustivo, le apparecchiature fornite dovranno rispettare:

• i requisiti di ergonomia stabiliti nella Direttiva CEE 90/270 recepita dalla legislazione italiana con Legge 19 febbraio 1992, n. 142;

• i requisiti di compatibilità elettromagnetica stabiliti nella direttiva 2004/108/CE recepita dalla legislazione italiana con X.Xxx. 6 novembre 2007, n. 194;

• per le componenti opzionali di accessibilità, nonché laddove esplicitamente previsto, i requisiti espressi dal D.M. 8 luglio 2005 "Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici", Allegato C, nonché dall’articolo 4, comma 1 della Legge n.4 del 2004;

• la direttiva 2002/95/CE, anche nota come "Restriction of Hazardous Substances (RoHS), recepita dalla legislazione italiana con X.Xxx. n. 151/2005;

• i requisiti stabiliti nel D.Lgs. n. 188/2008, che recepisce la direttiva 206/66/CE concernente pile, accumulatori e relativi rifiuti;

• le linee guida EPA ENERGY STAR nell’ultima versione disponibile per la specifica apparecchiatura.

Dovrà essere prodotta nell’Offerta Tecnica tutta la certificazione (quale documentazione tecnica o certificazione del fabbricante o una relazione di prova di un organismo internazionale riconosciuto) attestante il rispetto di tali caratteristiche e requisiti per le apparecchiature fornite.

4.3.2. LO.UC – Locazione operativa Unità Centrale

Per la definizione di Unità Centrale si rimanda al paragrafo 3.1.1.

Nell’identificare le caratteristiche minime (obbligatorie o migliorative) richieste per le UC di tipo PC, si fa riferimento ad un indice prestazionale generale, indicato con il termine Overall Rating, misurato mediante il software BAPCO SysMark 2012. Tale software rappresenta un sistema metrico, universalmente riconosciuto, del livello di dotazioni e prestazioni delle UC di interesse, in grado di formulare un benchmark significativo di comparazione fra prodotti, valutati nel loro utilizzo in un contesto reale/realistico. In particolare il benchmark richiesto è BAPCO SysMark 2012 – MS Windows 7 Professional 64 bit – Overall Rating.

Come evidenziato dalle caratteristiche delle UC di seguito dettagliate, l’Università intende gestire un parco macchine fondamentalmente basato sui sistemi operativi Microsoft; in tale ottica l’Università ha sottoscritto un contratto di tipo Campus che permette l’aggiornamento del sistema operativo delle UC all’ultima release disponibile in commercio, a condizione che le UC già dispongano di una licenza d’uso di un qualunque sistema operativo Microsoft Windows di tipo client. La fornitura delle UC dovrà quindi comprendere una licenza OEM di sistema operativo client Microsoft e l’UC stessa dovrà essere messa in esercizio con installato il sistema operativo Microsoft Windows 8 in Italiano, salvo eccezioni concordate fra le parti.

4.3.2.1. LO.UC.PCDS – Locazione operativa PC desktop standard

Le apparecchiature HW di tipo PC desktop standard sono, in linea generale, finalizzate a costituire l’UC delle PdL più comuni e diffuse, in grado di fornire l’adeguato ambiente di lavoro informatizzato alla quasi totalità degli utenti dei servizi di Fleet Management dell’Università.

Le due tabelle riportate di seguito sintetizzano rispettivamente le caratteristiche minime obbligatorie e migliorative dei PC desktop standard.

Caratteristiche minime obbligatorie

Caratteristica	Valore minimo
Prestazione di sistema	Non inferiori a 180, valore indice misurato attraverso SYSMark 2012 – Overall, SO MS 7 Professional 64 bit
Compatibilità sistema operativo	Microsoft Windows 7 Professional o superiore a 32\64 bit
Processore	• Quad-core nativo • Velocità minima 3,2 GHz • 6 MB Cache
RAM di sistema	8 GB DDR3 a 1.600 MHz non-ECC (2 x 4 GB)
Hard disk interno	• Serial ATA • Capacità minima 500 GB • Velocità di rotazione minima 7200 giri al minuto • Protocollo di trasferimento 3 Gb/sec
Unità ottiche	Unità DVD+/-RW 16x
Scheda video – Output	• 1 Dual-Link DVI (fornibile anche tramite adattatore, incluso nella fornitura) • 1 DisplayPort

Caratteristica	Valore minimo
Scheda video – Memoria	Fino a 1 GB di memoria RAM di sistema dedicabile alla memoria video
Scheda video – GPU	• Risoluzione video almeno di 1920 x 1200 pixel su porte digitali • Supporto di due display indipendenti • DirectX® 11
Scheda madre – Memoria	• 4 slot per moduli di memoria DDR3 in grado di ospitare fino a 32 GB di memoria di sistema • Architettura di memoria a doppio canale
Scheda madre – Audio	Integrata
Scheda madre – LAN	• Conformità alle norme ISO 8802-3 (IEEE 802.3 (10Base-T), 802.3u (100Base-TX), 802.3ab (1000Base-T)) • Supporto WOL
Scheda madre – Interfaccia di storage	• 2 connettori SATA 2 a 3 Gb/s • 2 connettori SATA 3 a 6 Gb/s
Scheda madre – I/O	• 1 porta RJ-45 • 1 porta Line In • 1 porta Line Out • 1 porta Microfono • 1 porta Headphone • 1 porta DVI-D (fornibile anche tramite adattatore, incluso nella fornitura) • 1 DisplayPort • 1 connessione per mouse e tastiera PS/2 • 2 porte USB 3.0 frontali o laterali • 4 porte USB 2.0
Consumi elettrici – Conformità alle specifiche	EPA ENERGY STAR versione 5.0
Livello massimo di potenza sonora emessa (Lwad) misurato a livello Operatore secondo lo Standard ISO 7779:2010, ECMA-74	• Modalità idle: 32 dB (A) • Hard disk attivo: 36 dB (A)
Tastiera	• Italiana estesa, QWERTY • Tasto funzione Windows • Tastierino numerico separato • Tasto euro
Mouse	Tecnologia ottica con due tasti e rotella di scrolling con funzionalità di terzo tasto, collegabile ad una delle porte del computer
Cabinet	Middle Tower

Tabella 4 – Caratteristiche minime obbligatorie per PC desktop standard

Caratteristiche minime migliorative

Caratteristica

Valore minimo

RAM di sistema

16 GB DDR3 a 1.600 MHz non-ECC (4 x 4 GB)

Hard disk interno

• Serial ATA

• Capacità minima 1 TB

• Velocità di rotazione minima 7200 giri al minuto

• Protocollo di trasferimento 6 Gb/sec

Tabella 5 – Caratteristiche minime migliorative per PC desktop standard

Criteri di valutazione tecnica

In sede di Offerta Tecnica al Fornitore è richiesto di esplicitare in forma tabellare marca, modello e tutte le caratteristiche di dettaglio delle apparecchiature HW che intende offrire per la tipologia in questione. Tali caratteristiche devono essere uguali o superiori alle caratteristiche minime obbligatorie richieste dall’Ateneo.

Nel caso in cui il Fornitore intenda offrire apparecchiature HW che rispettino anche le caratteristiche minime migliorative, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.UC.PCDS, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio”.

In tal caso, pertanto, le caratteristiche di dettaglio indicate dal Fornitore devono essere tutte uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo. Qualora i dati riportati non soddisfino tale criterio, ma il Fornitore abbia comunque espresso testualmente (nella forma sopra indicata) l’intenzione di avanzare un’offerta migliorativa, tale intenzione verrà considerata vincolante per il Fornitore, premiata in sede di valutazione tecnica (vedi il criterio riportato di seguito) ed accertata in fase di verifica di conformità, con le dovute conseguenze in caso di inadempienza da parte del Fornitore.

Criterio	Descrizione breve		Servizi interessati
VT.LO.UC.PCDS.1	Caratteristiche migliorative dell'HW		• LO.UC.PCDS
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
9,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.UC.PCDS, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio"

4.3.2.2. LO.UC.PCDA – Locazione operativa PC desktop ad alte prestazioni

Le apparecchiature HW di tipo PC desktop ad alte prestazioni sono, in linea generale, finalizzate a costituire l’UC di PdL evolute, rivolte ad utenti con particolari esigenze in termini prestazionali, in grado quindi di fornire l’adeguato ambiente di lavoro informatizzato anche nei casi di lavoro più complesso dal punto di vista informatico.

Le due tabelle riportate di seguito sintetizzano rispettivamente le caratteristiche minime obbligatorie e migliorative dei PC desktop ad alte prestazioni.

Caratteristiche minime obbligatorie

Caratteristica	Valore minimo
Prestazione di sistema	Non inferiori a 200, valore indice misurato attraverso SYSMark 2012 - Overall, SO MS 7 Professional 64 bit
Compatibilità sistema operativo	Microsoft Windows 7 Professional o superiore a 32\64 bit
Processore	• Quad-core nativo • Velocità minima 3,4GHz • 8 MB Cache
RAM di sistema	8 GB DDR3 a 1.600 MHz non-ECC (2 x 4 GB)

Caratteristica	Valore minimo
Hard disk interno	• Serial ATA • Capacità minima 1 TB • Velocità di rotazione minima 7200 giri al minuto • Protocollo di trasferimento 6 Gb/sec
Unità ottiche	Unità DVD+/-RW 16x
Scheda video – Output	• 1 Dual-Link DVI (fornibile anche tramite adattatore, incluso nella fornitura) • 1 DisplayPort
Scheda video – Memoria	2 GB DD3 di memoria dedicata su scheda grafica PCI Express 16x
Scheda video – GPU	• Risoluzione video supporta fino a 2560 x 1600 pixel su porte digitali • Supporto di due display indipendenti • DirectX® 11
Scheda madre – Memoria	• 4 slot per moduli di memoria DDR3 in grado di ospitare fino a 32 GB di memoria di sistema • Architettura di memoria a doppio canale
Scheda madre – Audio	Integrata
Scheda madre – LAN	• Conformità nella norma ISO 0000-0 (XXXX 802.3 (10Base-T), 802.3u (100Base-TX), 802.3ab (1000Base-T)) • Supporto WOL
Scheda madre – Interfaccia di storage	• 2 connettori SATA 2 a 3 Gb/s • 2 connettori SATA 3 a 6 Gb/s
Scheda madre – Xxxxxxxx posteriore I/O	• 1 porta RJ-45 • 1 porta Line In • 1 porta Line Out • 1 porta Microfono • 1 porta Headphone • 1 porta DVI-D (fornibile anche tramite adattatore, incluso nella fornitura) • 1 DisplayPort • 1 connessione per mouse e tastiera PS/2 • 2 porte USB 3.0 frontali o laterali • 4 porte USB 2.0
Consumi elettrici – Conformità alle specifiche	EPA ENERGY STAR versione 5.0
Livello massimo di potenza sonora emessa (Lwad) misurato a livello Operatore secondo lo Standard ISO 7779:2010, ECMA-74	• Modalità idle: 32 dB (A) • Hard disk attivo: 36 dB (A)
Tastiera	• Italiana estesa, QWERTY • Tasto funzione Windows • Tastierino numerico separato • Tasto euro
Mouse	Tecnologia ottica con due tasti e rotella di scrolling con funzionalità di terzo tasto, collegabile ad una delle porte del computer
Cabinet	Middle Tower

Tabella 6 – Caratteristiche minime obbligatorie per PC desktop ad alte prestazioni

Caratteristiche minime migliorative

Caratteristica

Valore minimo

RAM di sistema

16 GB DDR3 a 1.600 MHz o superiore non-ECC (2 x 8 GB)

Hard disk interno

• Disco primario:

o Serial ATA

o Tecnologia SSD

o Capacità minima 256 GB

o Protocollo di trasferimento 6 Gb/sec

• Disco secondario:

o Serial ATA

o Capacità minima 1 TB

o Velocità di rotazione minima 7200 giri al minuto

o Protocollo di trasferimento 6 Gb/sec

Tabella 7 – Caratteristiche minime migliorative per PC desktop ad alte prestazioni

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire apparecchiature HW che rispettino anche le caratteristiche minime migliorative, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.UC.PCDA, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.UC.PCDA.1	Caratteristiche migliorative dell'HW		• LO.UC.PCDA
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
6,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.UC.PCDA, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio"

4.3.2.3. LO.UC.PCTC – Locazione operativa PC thin client

Le apparecchiature HW di tipo PC thin client sono, in linea generale, finalizzate a costituire l’UC di PdL semplificate, rivolte ad utenti o situazioni con esigenze ridotte in termini prestazionali e/o con la necessità di

una dotazione HW ridimensionata (es. per servizi di segreteria); in questa accezione, nell’ambito dell’appalto, rientrano in tale categoria anche i cosiddetti mini-PC.

La tabella seguente sintetizza le caratteristiche minime obbligatorie dei PC thin client.

Caratteristica	Valore minimo
Compatibilità sistema operativo	Microsoft Windows 7 Professional o superiore a 32\64 bit
Processore	• Dual-core • Velocità minima 2,0 GHz
RAM di sistema	• 2 GB DDR3 SDRAM • Espandibile fino a 4 GB
Hard disk interno	• Serial ATA • Capacità minima 320 GB • Velocità di rotazione minima 5400 giri al minuto
Scheda video – Output	• 1 Dual-Link DVI (fornibile anche tramite adattatore, incluso nella fornitura) • 1 HDMI
Scheda video – GPU	• Risoluzione video almeno di 1920 x 1200 pixel su porte digitali • DirectX® 11
Espansione/connettività	• 1 porta DVI-D (fornibile anche tramite adattatore, incluso nella fornitura) • 1 porta HDMI • 2 porte USB 3.0 • 2 porte USB 2.0 • 1 porta RJ45 per Ethernet 10/100/1000 • 1 porta Microfono • 1 porta Line Out / Headphone
Tastiera	• Italiana estesa, QWERTY • Tasto funzione Windows • Tastierino numerico separato • Tasto euro
Mouse	Tecnologia ottica con due tasti e rotella di scrolling con funzionalità di terzo tasto, collegabile ad una delle porte del computer
Dimensioni massime (volume)	<= 2 litri

Tabella 8 – Caratteristiche minime obbligatorie per PC thin client

4.3.2.4. LO.UC.NTBK – Locazione operativa notebook

Le apparecchiature HW di tipo notebook sono, in linea generale, finalizzate a costituire l’UC di PdL (parzialmente) mobili, rivolte ad utenti con particolari esigenze di mobilità, in grado quindi di fornire l’adeguato ambiente di lavoro informatizzato sia all’interno che all’esterno delle sedi universitarie.

Le due tabelle riportate di seguito sintetizzano rispettivamente le caratteristiche minime obbligatorie e migliorative dei notebook.

Caratteristiche minime obbligatorie

Caratteristica	Valore minimo
Processore	• Quad-core nativo • Velocità minima 2,2 GHz • 6 MB Cache
RAM di sistema	4 GB DDR3 a 1.600 MHz non-ECC (2 x 2 GB)
Hard disk interno	• Serial ATA • Capacità minima 500 GB • Velocità di rotazione minima 5400 giri al minuto • Protocollo di trasferimento 3 Gb/sec
Unità ottiche	Unità DVD+/-RW 8x
Display	• LED HD 15" • Risoluzione video almeno di 1366 x 768 pixel • Antiriflesso
Compatibilità sistema operativo	Microsoft Windows 7 Professional o superiore a 32\64 bit
Dispositivo I/O – Interfacce esterne	• 2 porte USB 3.0 • 1 dispositivo Bluetooth integrato • 1 porta RJ45 per Ethernet 10/100/1000 • 1 porta DVI-D (fornibile anche tramite adattatore, incluso nella fornitura) • 1 porta Microfono • 1 porta Line Out / Headphone
Specifiche Ethernet	10/100/1000TX integrata
Connettività WI-FI	• WI-FI integrato • Specifiche wireless 802.11b/g-/n
Tastiera	• Italiana da almeno 85 tasti QWERTY • Tasto euro
Mouse	• Esterno di tipo ottico • 2 tasti • Rotella di scorrimento
Sicurezza	Supporto blocco Kensington
Peso	Non superiore a 2,6 Kg esclusi accessori e alimentatore
Borsa	Da viaggio in tessuto antiurto, a due scomparti, con tracolla antiscivolo, protezione sul fondo

Tabella 9 – Caratteristiche minime obbligatorie per notebook

Caratteristiche minime migliorative

Caratteristica

Valore minimo

RAM di sistema

8 GB DDR3 a 1.600 MHz non-ECC (2 x 4 GB)

Hard disk interno

• Serial ATA

• Tecnologia SSD

• Capacità minima 256 GB

• Protocollo di trasferimento 6 Gb/sec

Caratteristica

Valore minimo

Display

• LED HD 15"

• Risoluzione video almeno di 1920 x 1080 pixel

• Antiriflesso

Tabella 10 – Caratteristiche minime migliorative per notebook

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire apparecchiature HW che rispettino anche le caratteristiche minime migliorative, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.UC.NTBK, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.UC.NTBK.1	Caratteristiche migliorative dell'HW		• LO.UC.NTBK
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
3,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.UC.NTBK, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio"

4.3.3. LO.PP – Locazione operativa Unità Periferica Personale

Per la definizione di Unità Periferica Personale si rimanda al paragrafo 3.1.1.

4.3.3.1. LO.PP.MNTS – Locazione operativa monitor LCD standard

I monitor LCD standard sono, in linea generale, finalizzati a corredare le UC delle PdL più comuni e diffuse (basate di norma su PC desktop standard), in grado di fornire l’adeguato ambiente di lavoro informatizzato alla quasi totalità degli utenti dei servizi di Fleet Management dell’Università.

Le due tabelle riportate di seguito sintetizzano rispettivamente le caratteristiche minime obbligatorie e migliorative dei monitor LCD standard.

Caratteristiche minime obbligatorie

Caratteristica	Valore minimo
Immagine/Display	• Schermo LCD TFT • Retroilluminazione con sistema LED • Dimensioni pannello 21,5" • Formato 16:9 • Risoluzione ottimale 1920 x 1080 a 60 Hz • Tempo di risposta (tipico) 5 ms • Luminosità 250 cd/m² • Fattore di contrasto (tipico) 1000:1 • Pixel pitch 0,24 x 0,24 mm • Angolo visuale 170º (O) / 160º (V) • Colori display 16,7 M
Connettività – Video	DVI-D
Connettività – Audio	• 1 uscita cuffie (jack da 3,5 mm) • Ingresso audio PC
Funzioni utili	Audio incorporato 1,0 W x 2
Compatibilità Plug & Play	Windows 8 / 7 / Vista / XP
Base	Inclinazione -5°/+20°
Sostenibilità ambientale ed energetica	• Energy Star 5.0 • RoHS
Conformità e standard – Omologazioni	• Marchio CE • TCO 5.0

Tabella 11 – Caratteristiche minime obbligatorie per monitor LCD standard

Caratteristiche minime migliorative

Caratteristica

Valore minimo

Immagine/Display

• Schermo LCD TFT

• Retroilluminazione con sistema W-LED

• Dimensioni pannello 24"

• Formato 16:9

• Risoluzione ottimale 1920 x 1080 a 60Hz

• Tempo di risposta (tipico) 5 ms

• Luminosità 250 cd/m²

• Fattore di contrasto (tipico) 1000:1

• Pixel pitch 0,27 x 0,27

• Angolo visuale 170º (O) / 160º (V)

• Colori display 16,7 M

Base

• Funzione Pivot 90°

• Inclinazione -5°/+20°

• Regolabile in altezza

Tabella 12 – Caratteristiche minime migliorative per monitor LCD standard

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire apparecchiature HW che rispettino anche le caratteristiche minime migliorative, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.PP.MNTS, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.PP.MNTS.1	Caratteristiche migliorative dell'HW		• LO.PP.MNTS
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
9,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.PP.MNTS, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio"

4.3.3.2. LO.PP.MNTA – Locazione operativa monitor LCD ad alte prestazioni

I monitor LCD standard sono, in linea generale, finalizzati a corredare le UC delle PdL evolute (basate di norma su PC desktop ad alte prestazioni), rivolte ad utenti con particolari esigenze grafiche, in grado quindi di fornire l’adeguato ambiente di lavoro informatizzato anche nei casi di lavoro più complesso dal punto di vista informatico.

Le due tabelle riportate di seguito sintetizzano rispettivamente le caratteristiche minime obbligatorie e migliorative dei monitor LCD da alte prestazioni.

Caratteristiche minime obbligatorie

Caratteristica

Valore minimo

Immagine/Display

• Schermo LCD TFT

• Retroilluminazione con sistema LED

• Dimensioni pannello 24"

• Formato 16:9

• Risoluzione ottimale 1920 x 1080 a 60Hz

• Tempo di risposta (tipico) 5 ms

• Luminosità 250 cd/m²

• Fattore di contrasto (tipico) 1000:1

• Pixel pitch 0,27 x 0,27

• Angolo visuale 170º (O) / 160º (V)

• Colori display 16,7 M

Connettività – Video

DVI-D

Caratteristica	Valore minimo
Connettività – Audio	• 1 uscita cuffie (jack da 3,5 mm) • Ingresso audio PC
Funzioni utili	Audio incorporato 1,0 W x 2
Compatibilità Plug & Play	Windows 8 / 7 / Vista / XP
Base	Inclinazione -5°/+20°
Sostenibilità ambientale ed energetica	• Energy Star 5.0 • RoHS
Conformità e standard – Omologazioni	• Marchio CE • TCO 5.0

Tabella 13 – Caratteristiche minime obbligatorie per monitor LCD ad alte prestazioni

Caratteristiche minime migliorative

Caratteristica

Valore minimo

Immagine/Display

• Schermo LCD

• Retroilluminazione con sistema W-LED

• Dimensioni pannello 27"

• Formato 16:9

• Risoluzione ottimale 1920 x 1080 a 60 Hz

• Tempo di risposta (tipico) 12 ms

• Luminosità 300 cd/m²

• Fattore di contrasto (tipico) 1.000:1

• Pixel pitch 0,31 x 0,31 mm

• Angolo visuale 170º (O) / 160º (V)

• Colori display 16,7 M

Base

• Regolazione in altezza

• Inclinazione -5°/+20°

Tabella 14 – Caratteristiche minime migliorative per monitor LCD ad alte prestazioni

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire apparecchiature HW che rispettino anche le caratteristiche minime migliorative, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.PP.MNTA, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.PP.MNTA.1	Caratteristiche migliorative dell'HW		• LO.PP.MNTA
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
6,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.PP.MNTA, si impegna a fornire apparecchiature HW che presentino caratteristiche uguali o superiori alle caratteristiche minime migliorative indicate dall’Ateneo per la tipologia di HW interessata dal servizio"

4.3.3.3. LO.PP.STLB – Locazione operativa stampante laser in bianco/nero personale

Le stampanti laser in bianco/nero personali sono, in linea generale, finalizzate a comporre le PdL di utenti con posizioni di responsabilità o con esigenze specifiche, che possono necessitare quindi di funzionalità di stampa più evolute e flessibili.

Il servizio deve prevedere la fornitura di un primo kit completo di materiali di consumo, nella capacità massima disponibile, come definito nelle condizioni generali (rif. §4.3.1); è considerato un fattore premiante la fornitura, nell’ambito del medesimo servizio, di un secondo kit completo, nella capacità massima disponibile, come indicato nel sotto-paragrafo seguente relativo ai criteri di valutazione tecnica.

La Tabella 15 sintetizza le caratteristiche minime obbligatorie delle stampanti laser in bianco/nero personali.

Caratteristica	Valore minimo
Velocità di stampa – Solo fronte	• 28 ppm in formato A4 • 30 ppm in formato Letter
Stampa fronte-retro	• Presente • Automatica
Formati carta	• A4 • A5 • A6 • B5 • Letter • Legal
Risoluzione	1.200 x 1.200 dpi reali
Memoria	32 MB
Livello massimo di rumorosità	• Modalità standby: 30 dBA • Modalità di stampa: 55 dBA
Consumi elettrici – Conformità alle specifiche	EPA ENERGY STAR ver 1.2
Ciclo operativo	30.000 pagine/mese
Interfaccia	• 1 porta USB 2.0 • 1 porta RJ45 per Ethernet 10/100
Compatibilità sistema operativo	• Windows XP/Vista/7/Server 2003/Server 2008/Server 2008 R2 a 32/64 bit • Mac OS X 10.5 / 10.6 • Linux
Driver della stampante	• Driver PCL6 • Driver PostScript
Capacità carta	Cassetto da 250 fogli
Dimensioni massime (L x P x A) – Volume	50 X 45 X 35 cm

Tabella 15 – Caratteristiche minime obbligatorie per stampanti laser in bianco/nero personali

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire la fornitura di un secondo kit completo di materiali di consumo, nella capacità massima disponibile, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.PP.STLB, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.PP.STLB.1	Fornitura di un secondo kit di materiali di consumo		• LO.PP.STLB
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
1,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.PP.STLB, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio"

4.3.3.4. LO.PP.STLC – Locazione operativa stampante laser a colori personale

Le stampanti laser a colori personali sono, in linea generale, finalizzate a comporre le PdL di utenti con posizioni di responsabilità o con esigenze specifiche, che possono necessitare quindi di funzionalità di stampa più evolute e flessibili, comprensive anche di stampa a colori.

La tabella seguente sintetizza le caratteristiche minime obbligatorie delle stampanti laser a colori personali.

Caratteristica	Valore minimo
Tecnologia	Laser / LED
Velocità di stampa A4	18 ppm a colori e monocromatico
Formati carta	• A4 • A5 • A6 • B5 • Letter • Legal
Risoluzione	600 x 600 dpi
Memoria	128 MB
Livello massimo di rumorosità	• Modalità standby: 40 dBA • Modalità di stampa: 55 dBA
Interfaccia	• 1 porta USB 2.0 • 1 porta RJ45 per Ethernet 10/100
Display	LCD
Compatibilità sistema operativo	• Windows XP/Vista/7/Server 2003/Server 2008/Server 2008 R2 a 32/64 bit • Mac OS X 10.5 / 10.6 • Linux
Driver della stampante	• Driver PCL6 • Driver PostScript

Caratteristica	Valore minimo
Capacità carta	• Cassetto standard 250 fogli • Vassoio multifunzione da 50 fogli
Consumi elettrici – Conformità alle specifiche	EPA ENERGY STAR ver 1.2
Dimensioni massime (L x P x A) – Volume	50 x 45 x 35 cm

Tabella 16 – Caratteristiche minime obbligatorie per stampanti laser a colori personali

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire la fornitura di un secondo kit completo di materiali di consumo, nella capacità massima disponibile, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.PP.STLC, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.PP.STLC.1	Fornitura di un secondo kit di materiali di consumo		• LO.PP.STLC
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
1,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.PP.STLC, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio"

4.3.3.5. LO.PP.STTR – Locazione operativa stampante termica personale per etichette

Le stampanti termiche personali per etichette sono, in linea generale, finalizzate a comporre le PdL di utenti destinati a specifiche attività, quali quelle di protocollazione informatica, che possono necessitare quindi di funzionalità peculiari di stampa su etichette.

La tabella seguente sintetizza le caratteristiche minime obbligatorie delle stampanti termiche personali per etichette.

Caratteristica	Valore minimo
Tecnologia di stampa	Trasferimento termico
Risoluzione	203 dpi / 8 dots per mm
Memoria	• 4 MB Flash • 8 MB SDRAM
Larghezza di stampa	104 mm
Lunghezza di stampa massima	990 mm
Velocità di stampa	120 mm per secondo
Supporti sensori	• Sensori fissi per riflessione e trasparenza • Sensore regolabile riflettente per linea nera
Supporto di stampa – Lunghezza massima	990 mm

Caratteristica	Valore minimo
Supporto di stampa – Larghezza massima	108 mm
Supporto di stampa – Spessore massimo	0.19 mm
Interfaccia	• 1 porta USB 2.0 • 1 porta RJ45 per Ethernet 10/100
Compatibilità sistema operativo	• Windows XP/Vista/7/Server 2003/Server 2008/Server 2008 R2 a 32/64 bit • Mac OS X 10.5 / 10.6 • Linux
Dimensioni massime (L x P x A) – Volume	20 X 25 X 20 cm

Tabella 17 – Caratteristiche minime obbligatorie per stampanti termiche personali per etichette

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire la fornitura di un secondo kit completo di materiali di consumo, nella capacità massima disponibile, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.PP.STTR, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.PP.STTR.1	Fornitura di un secondo kit di materiali di consumo		• LO.PP.STTR
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
1,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.PP.STTR, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio"

4.3.3.6. LO.PP.SCAF – Locazione operativa scanner personale con ADF

Gli scanner personali sono, in linea generale, finalizzati a comporre le PdL di utenti destinati a specifiche attività, quali quelle di protocollazione informatica, che possono necessitare delle funzionalità di scansione dei documenti; la disponibilità di un componente di Automatic Document Feeder assicura inoltre le prestazioni adeguate per la complessità operativa prevista.

La tabella seguente sintetizza le caratteristiche minime obbligatorie degli scanner personali con ADF.

Caratteristica	Valore minimo
Tecnologia di acquisizione	• ADF • Piano d’esposizione
Modalità di acquisizione	• Solo fronte / fronte e retro • Colore / scala di grigi / monocromo
Sensore immagine	1 CCD (dispositivo ad accoppiamento di carica) a colori
Fonte luminosa	Lampada a scarica bianca a catodo a freddo
Formati documenti	• ADF: massimo 216 x 356 mm • Piano di esposizione: massimo 216 x 297 mm
Grammatura	• ADF: 60 g/m2 - 120 g/m2
Capacità alimentazione documenti	50 fogli

Caratteristica	Valore minimo
Colore di fondo	Bianco
Risoluzione ottica	600 dpi
Risoluzione di uscita	50-600 dpi
Formato uscita	• Binario 1-bit • Scala di grigi 8-bit • Colore 24-bit
Interfacce	• 1 porta USB 2.0 • 1 porta RJ45 per Ethernet 10/100
Consumi elettrici – Conformità alle specifiche	EPA ENERGY STAR versione 1.2
Dimensioni massime (L x P x A) – Volume	55 x 45 x 20 cm (escluso ADF)

Tabella 18 – Caratteristiche minime obbligatorie per scanner personali con ADF

4.3.4. XX.XX – Locazione operativa Unità Periferica di Workgroup

Per la definizione di Unità Periferica di Workgroup si rimanda al paragrafo 3.1.1.

4.3.4.1. LO.PW.SMWL – Locazione operativa apparecchiatura multifunzione laser di workgroup

Le apparecchiature multifunzione laser di workgroup sono, in linea generale, finalizzate a supportare a livello dipartimentale più utenti / PdL per le funzionalità di input/output di:

• stampa da file,

• copia da documento cartaceo,

• scansione digitale di documenti cartacei con invio ad e-mail,

• invio di fax da documento cartaceo.

Per apparecchiatura multifunzione si intende appunto un dispositivo di rete in grado di fornire in maniera integrata tutte le suddette funzionalità.

La tabella seguente sintetizza le caratteristiche minime obbligatorie delle apparecchiature multifunzione laser di workgroup.

Caratteristica	Valore minimo
Funzionalità	• Stampa • Copia • Scansione • Fax • Tutte disponibili via network
Stampa – Velocità di stampa	40 ppm in A4
Stampa – Risoluzione	600x600 dpi
Stampa – Emulazione	• PCL5 • PCL6 • Postscript3 (emulazione) • XPS
Stampa – Fronte-Retro	• Automatico • Integrato

Caratteristica	Valore minimo
Copia – Velocità di stampa	40 ppm in A4
Copia – Risoluzione	600x600 dpi
Copia – Multicopia	• Automatico • Integrato
Scansione – Velocità di scansione (B/N)	19 ipm (in A4 a 300 dpi)
Scansione – Formato massimo carta	A3
Scansione – Risoluzione (Ottica)	600x600 dpi
Scansione – Destinazione output	• E-mail • USB • FTP • PC
Fax – Velocità Modem	33.6Kbps
Fax – Risoluzione Fax	300x300 dpi
Fax – Funzionalità	• Composizione veloce • Invio a gruppi • Invio a colori (solo in invio) • Auto ricomposizione • Ricomposizione ultimo numero • Invio posticipato • Inoltro fax ad e-mail/fax • Ricezione sicura • Fax block list
Capacità carta – Xxxxxxxx	• Standard: 2 cassetti da almeno 500 fogli ciascuno • Vassoio multiuso da 100 fogli • Massima capacità di almeno 3000 fogli
Capacità carta – Uscita	• Standard: 500 fogli
Tipologia supporti	• Carta prestampata • Carta preforata • Carta intestata • Lucidi • Cartoncino • Buste • Etichette
Capacità DADF	100 fogli
Dimensione dei fogli da ADF	• A3 • A4 • A5 • B4 • B5
Display	LCD
Memoria	512MB
Compatibilità sistema operativo	• Windows XP/Vista/7/Server 2003/Server 2008/Server 2008 R2 a 32/64 bit • Mac OS X 10.5 / 10.6
Interfaccia	• 1 porta USB 2.0 • 1 porta RJ45 per Ethernet 10/100/1000
Ciclo operativo	150.000 pagine/mese
Dimensioni massime (LxPxA) – Volume	70 x 75 x 95 cm (incluso DADF)

Tabella 19 – Caratteristiche minime obbligatorie per apparecchiature multifunzione laser di workgroup

Criteri di valutazione tecnica

Nel caso in cui il Fornitore intenda offrire la fornitura di un secondo kit completo di materiali di consumo, nella capacità massima disponibile, in sede di Offerta Tecnica è richiesto di esplicitare testualmente che “il Fornitore, nell’ambito del servizio LO.PW.SMWL, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio”.

Criterio	Descrizione breve		Servizi interessati
VT.LO.PW.SMWL.1	Fornitura di un secondo kit di materiali di consumo		• LO.PW.SMWL
Punteggio massimo	Modalità di valutazione	Punteggio minimo di soglia
2,0	Tabellare	Non applicabile
Note sulle modalità di valutazione
Per l’assegnazione del punteggio (massimo) per il servizio interessato deve essere presente in Offerta Tecnica la dicitura testuale: “il Fornitore, nell’ambito del servizio LO.PW.SMWL, si impegna a fornire un secondo kit completo di materiali di consumo, nella capacità massima disponibile, per la tipologia di HW interessata dal servizio"

4.4. RI – Riscatto da locazione operativa

Il servizio di riscatto da locazione operativa consiste nel passaggio di proprietà del bene noleggiato (apparecchiatura HW) dal Fornitore all’Ateneo, da realizzarsi, su volontà dell’Università, al termine naturale del servizio di locazione operativa o anche prima, in corso di noleggio.

Si fa presente che da un punto di vista strategico, nell’ambito dei servizi di Fleet Management l’Ateneo ha già intrapreso da diversi anni una direzione ben precisa, quella dell’outsourcing dei servizi, in linea con la quale si sviluppa la presente gara. Lungo questa direzione strategica, si realizza anche la scelta di non investire le proprie risorse in spese a capitale (capex), ma in spese operative (opex), al fine di ottenere migliori benefici gestionali.

In tale ottica, la proprietà dei beni e in particolare il riscatto dei beni noleggiati, non rientra fra gli obiettivi centrali dell’Università, anzi ne diverge; tuttavia, il riscatto è una possibilità che l’Ateneo vuole riservarsi al fine di gestire in maniera quanto più flessibile e ottimale, secondo le proprie necessità, una pianificazione del noleggio dilazionata nel tempo, nonché la fase finale del contratto (rif. §4.1.2.4), in vista della terminazione dei servizi del Fornitore e della scelta e del subentro di una nuova struttura operativa per il successivo periodo di esercizio.

4.4.1. Condizioni generali

Per quanto riguarda il numero di riferimento di apparecchiature per cui verrà attivato il servizio, si rimanda a quanto specificato nel capitolo 3.2.

Come già indicato in relazione alle condizioni di terminazione della locazione operativa (rif. §4.3.1.3), il servizio di riscatto potrà essere attivato per la singola apparecchiatura HW, su richiesta formale dell’Ateneo:

• al termine naturale del periodo completo di locazione operativa;

• anticipatamente, durante il periodo di locazione operativa.

A seguito del riscatto la proprietà del bene passerà all’Ateneo (eseguendo tutte le attività amministrative necessarie, secondo procedure concordate fra le parti); qualora l’Ateneo intenda continuare a sottoporre l’apparecchiatura riscattata a servizi di manutenzione HW da parte del Fornitore, dovrà attivare lo specifico servizio per HW da Locazione Operativa (si rimanda al paragrafo 3.1.1 per la definizione) in base alla tipologia di HW in questione (rif. §4.5.2).

Qualora il riscatto avvenga anticipatamente, il Fornitore è comunque tenuto a prestare una garanzia che copra il bene acquistato dall’Ateneo per il periodo residuo fino a decorrenza del periodo naturale di noleggio.

In sede di Offerta Economica al Fornitore è richiesto di formulare, per ogni tipologia di HW in locazione operativa, l’importo unitario da corrispondere per il servizio di riscatto a fine noleggio per singola

apparecchiatura, nel rispetto dell’importo massimale ammissibile da gara pari al 15% dell’importo totale corrisposto per l’intero noleggio (somma di tutti i 12 canoni trimestrali di locazione operativa); in altri termini l’importo offerto non può superare un valore pari a 1,8 volte il singolo canone trimestrale di locazione operativa.

Nel caso di riscatto anticipato, l’Ateneo corrisponderà al Fornitore un importo per singola apparecchiatura pari al 90% dei canoni trimestrali di locazione operativa residui non più dovuti sommato all’importo offerto dal Fornitore per il riscatto a fine noleggio.

In altri termini, dati:

• CA: canone trimestrale offerto dal Fornitore per il servizio di locazione operativa dell’apparecchiatura HW del generico tipo A;

• RAf: costo del servizio di riscatto da locazione operativa a fine noleggio offerto dal Fornitore per l’apparecchiatura HW di tipo A;

• i: numero d’ordine del trimestre contrattuale in cui viene richiesto il servizio di riscatto (che avrà effetto da termine del trimestre);

l’Ateneo corrisponderà l’importo RAi dovuto, secondo la seguente formula:

RAi = 90% x (12 – i) x CA + RAf con RAf <= 15% x 12 x CA = 1,8 x CA.

La Tabella 20 riporta i singoli valori RAi per ogni trimestre i.

i	RAi	Note
12	RAf	RAi <= 1,8 x CA
11	0,9 x CA + RAf	RAi <= 2,7 x CA
10	1,8 x CA + RAf	RAi <= 3,6 x CA
9	2,7 x CA + RAf	RAi <= 4,5 x CA
8	3,6 x CA + RAf	RAi <= 5,4 x CA
7	4,5 x CA + RAf	RAi <= 6,3 x CA
6	5,4 x CA + RAf	RAi <= 7,2 x CA
5	6,3 x CA + RAf	RAi <= 8,1 x CA
4	7,2 x CA + RAf	RAi <= 9,0 x CA
3	8,1 x CA + RAf	RAi <= 9,9 x CA
2	9,0 x CA + RAf	RAi <= 10,8 x CA
1	9,9 x CA + RAf	RAi <= 11,7 x CA

Tabella 20 – Importi da corrispondere per il servizio di riscatto da locazione operativa

4.4.2. RI.UC – Riscatto Unità Centrale

Nell’ambito della locazione operativa delle UC, vengono definiti i seguenti servizi di riscatto, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista.

4.4.2.1. RI.UC.PCDS – Riscatto PC desktop standard

Il servizio rappresenta il riscatto, nel rispetto delle condizioni generali (rif. §4.4.1), di apparecchiature HW rilasciate all’Ateneo dal Fornitore nell’ambito del servizio di locazione operativa di PC desktop standard (rif.

§4.3.2.1).

4.4.2.2. RI.UC.PCDA – Riscatto PC desktop ad alte prestazioni

4.4.2.3. RI.UC.PCTC – Riscatto PC thin client

§4.3.2.3).

4.4.2.4. RI.UC.NTBK – Riscatto notebook

4.4.3. RI.PP – Riscatto Unità Periferica Personale

Nell’ambito della locazione operativa delle UPP, vengono definiti i seguenti servizi di riscatto, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista.

4.4.3.1. RI.PP.MNTS – Riscatto monitor LCD standard

§4.3.3.1).

4.4.3.2. RI.PP.MNTA – Riscatto monitor LCD ad alte prestazioni

4.4.3.3. RI.PP.STLB – Riscatto stampante laser in bianco/nero personale

4.4.3.4. RI.PP.STLC – Riscatto stampante laser a colori personale

4.4.3.5. RI.PP.STTR – Riscatto stampante termica personale per etichette

4.4.3.6. RI.PP.SCAF – Riscatto scanner personale con ADF

4.4.4. XX.XX – Riscatto Unità Periferica di Workgroup

Nell’ambito della locazione operativa delle UPW, vengono definiti i seguenti servizi di riscatto, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista.

4.4.4.1. RI.PW.SMWL – Riscatto apparecchiatura multifunzione laser di workgroup

4.5. MH – Manutenzione HW

Il servizio di manutenzione HW comprende tutte le attività e le soluzioni (tecniche, organizzative, contrattuali, ecc.) necessarie per garantire il corretto e completo funzionamento delle apparecchiature HW gestite, intervenendo sulle componenti fisiche per la loro manutenzione ordinaria/straordinaria e la revisione, riparazione e/o sostituzione in caso di anomalie, malfunzionamenti, inefficienze o degradazione delle prestazioni.

Nell’accezione con cui si declina il servizio in questione nell’ambito dell’appalto (come descritto nel paragrafo seguente), analogamente a quanto espresso per il servizio di riscatto da locazione operativa (rif. §4.4), tale servizio non rientra fra gli obiettivi centrali dell’Università, anzi ne diverge; tuttavia, è una possibilità che l’Ateneo vuole riservarsi al fine di gestire in maniera quanto più flessibile e ottimale, secondo le proprie necessità, una pianificazione del noleggio dilazionata nel tempo e conseguentemente una configurazione mista del parco macchine complessivo, soprattutto nella fase di startup (rif. §4.1.2.1) e nella fase finale dell’appalto (rif. §4.1.2.4), dove si sviluppa la transizione fra vecchie e nuove strutture operative dei differenti periodo di esercizio. Il concetto di parco macchine misto viene chiarito nel paragrafo seguente.

4.5.1. Condizioni generali

Il servizio di manutenzione HW si può applicare a tre casistiche di HW differenti:

• HW in locazione operativa, ossia goduto dall’Ateneo nell’ambito del servizio di locazione operativa (rif.

§4.3);

• HW da Locazione Operativa, ossia riscattato dall’Ateneo (rif. §4.4) dopo un periodo di locazione operativa (per una definizione più dettagliata si rimanda al paragrafo 3.1.1);

• HW di Proprietà, da intendersi di proprietà dell’Ateneo (per una definizione più dettagliata si rimanda al paragrafo 3.1.1).

Le attività previste nell’ambito del servizio, illustrate nel seguito, sono comuni a tutte e tre le casistiche presentate (che possono contribuire ognuna a comporre il parco macchine complessivo gestito), tuttavia:

• per quanto riguarda l’HW in locazione operativa, le attività sono da considerarsi completamente comprese (e quindi attivate e corrisposte economicamente) nell’ambito dei servizi di locazione operativa, per ciascuna tipologia di apparecchiatura HW;

• per quanto riguarda l’HW da Locazione Operativa e l’HW di Proprietà, le attività costituiscono servizi a sé stanti, specificati nei paragrafi seguenti.

Al di là delle differenze organizzative od operative dei due tipi di servizi, l’Ateneo vuole sottolineare il fattore chiave che ha portato alla distinzione fra manutenzione di HW da Locazione Operativa e manutenzione di HW di Proprietà: l’HW da Locazione Operativa, in quanto completamente conosciuto dal Fornitore sin dal rilascio e dal primo utilizzo e per tutta la sua storia all’interno dell’Università, presenta assolutamente per il Fornitore una minor fonte di rischio e di interventi, tanto più probabilisticamente ridotti quanto più la qualità e tempestività delle attività di gestione e manutenzione condotte dal Fornitore, durante il periodo di locazione operativa, hanno mantenuto le apparecchiature in perfetto stato di funzionamento. In tale ottica, l’Ateneo ritiene che tale tipo di manutenzione HW debba presentare dei costi per l’Università necessariamente inferiori rispetto all’altra tipologia.

Le attività di manutenzione HW previste sono comunque comuni a tutte le casistiche indicate, ed includono a titolo indicativo non esaustivo:

• verifiche tecniche sullo stato di funzionamento delle apparecchiature;

• manutenzione ordinaria e straordinaria delle apparecchiature;

• diagnosi sulle cause di anomalie, malfunzionamenti, inefficienze o degradazione delle prestazioni;

• riparazione o ricambio di componenti dell’apparecchiatura ove necessario;

• sostituzione dei materiali di consumo (forniti dall’Ateneo), ove applicabile.

Le attività verranno erogate nel contesto degli interventi di manutenzione HW (rif. §4.2.4.4), sulla base di richieste o segnalazioni pervenuta al servizio di intervento tecnico in locale (rif. §4.2.4.3).

L’eventuale sostituzione di componenti deve essere effettuata con prodotti originali, intendendo per originali quelle componenti garantite come nuove e almeno dello stesso livello di revisione della componente da sostituire, realizzati o commercializzati dal medesimo produttore della componente da sostituire. In caso di irreperibilità di componenti originali, il Fornitore potrà utilizzare in sostituzione componenti compatibili, possibilmente dotate della certificazione del produttore originale. Nel caso di malfunzionamenti causati dall’uso di componenti incompatibili con i sistemi in uso, il Fornitore sarà tenuto, a propria cura e spese, alla sostituzione ed al ritiro delle componenti difettose nonché al ripristino generale delle funzionalità.

Qualora per un’apparecchiatura si rilevassero anomalie o malfunzionamenti critici non riparabili o la cui riparazione non risultasse conveniente, si applicheranno le seguenti regole:

• se l’apparecchiatura rappresenta HW ancora in locazione operativa, l’eventuale sostituzione dell’intera apparecchiatura dovrà avvenire a totale onere del Fornitore;

• se l’apparecchiatura rappresenta HW da Locazione Operativa o HW di Proprietà, il Fornitore non sarà tenuto all’eventuale sostituzione, ma dovrà fornire all’Ateneo adeguata documentazione delle cause del malfunzionamento e dell’impossibilità o non sostenibilità della riparazione; l’Ateneo potrà quindi valutare se procedere autonomamente alla riparazione (mantenendo attivo il servizio di manutenzione HW) o se dismettere definitivamente l’apparecchiatura.

In generale, è opportuno sottolineare che le attività di manutenzione HW sono da intendersi come manutenzione di tipo correttivo e pertanto del tutto differenti e svincolate dalle operazioni del servizio IMAC- R (rif. §4.2.4.6).

In qualunque caso il Fornitore rappresenterà il referente e garante unico verso l’Ateneo nell’eventuale accesso a servizi di assistenza e manutenzione di terze parti (ad es. per componenti in garanzia o laddove ritenuto necessario). Nel caso, il Fornitore sarà responsabile della predisposizione all’invio e del trasporto del materiale oggetto di intervento da e verso la parte terza, garantendo nei confronti dell’Ateneo la totale protezione dalle conseguenze di eventi dannosi non imputabili all’Ateneo stesso (es. danneggiamenti, smarrimenti, ecc.), nonché del monitoraggio dei tempi e della modalità di intervento delle terze parti, mettendo a disposizione dell’Ateneo in maniera trasparente i dati relativi, attraverso gli strumenti di reportistica e SLA management previsti (rif. §4.1.1.9).

In tal senso, nel caso la manutenzione HW erogata dal Fornitore interessi componenti o apparecchiature di proprietà dell’Ateneo ancora coperte da garanzia, il Fornitore dovrà attivare e gestire direttamente i rapporti tecnico-commerciali con le terze parti fornitrici della garanzia. Al termine del periodo di garanzia, gli oneri di manutenzione HW relativi passeranno naturalmente in carico al Fornitore.

Per quanto riguarda il numero di riferimento di apparecchiature per cui verrà attivato il servizio, si rimanda a quanto specificato nel capitolo 3.2.

4.5.2. MH.LO – Manutenzione HW da Locazione Operativa

Nell’ambito del possibile HW da Locazione Operativa gestito, vengono definiti i seguenti servizi di manutenzione HW, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista per UC, UPP e UPW.

4.5.2.1. MH.LO.PCDT – Manutenzione HW PC desktop da locazione operativa

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di apparecchiature HW riscattate all’Ateneo nell’ambito dei servizi di riscatto di PC desktop standard (rif.

§4.4.2.1) o di PC desktop ad alte prestazioni (rif. §4.4.2.2).

4.5.2.2. MH.LO.PCTC – Manutenzione HW PC thin client da locazione operativa

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di apparecchiature HW riscattate all’Ateneo nell’ambito del servizio di riscatto di PC thin client (rif. §4.4.2.3).

4.5.2.3. MH.LO.NTBK – Manutenzione HW notebook da locazione operativa

4.5.2.4. MH.LO.MNTR – Manutenzione HW monitor LCD da locazione operativa

§4.4.3.1) o di monitor LCD ad alte prestazioni (rif. §4.4.3.2).

4.5.2.5. MH.LO.STLB – Manutenzione HW stampante laser in bianco/nero personale da locazione operativa

4.5.2.6. MH.LO.STLC – Manutenzione HW stampante laser a colori personale da locazione operativa

4.5.2.7. MH.LO.STTR – Manutenzione HW stampante termica personale per etichette da locazione operativa

4.5.2.8. MH.LO.SCAF – Manutenzione HW scanner personale con ADF da locazione operativa

§4.4.3.6).

4.5.2.9. MH.LO.SMWL – Manutenzione HW apparecchiatura multifunzione laser di workgroup da locazione operativa

4.5.3. XX.XX – Manutenzione HW di Proprietà

Nell’ambito del possibile HW di Proprietà dell’Ateneo, vengono definiti i seguenti servizi di manutenzione HW, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista per UC, UPP e UPW.

Nel capitolo 7.1 si riporta a titolo puramente indicativo il censimento del potenziale HW di Proprietà dell’Ateneo al momento dell’avvio delle attività contrattuali. Tale censimento è da considerarsi un mero, ma significativo, quadro di riferimento sulla tipologia di apparecchiature che hanno caratterizzato il parco macchine dell’Ateneo afferente ai servizi di Fleet Management e non necessariamente rappresenterà il reale piano di attivazione dei servizi di manutenzione HW nei confronti del Fornitore.

Al fine di una congrua valutazione da parte del Fornitore, si può comunque assumere che le caratteristiche essenziali (es. funzionalità, tecnologia, tecniche di costruzione, materiali, standard, ecc.) delle diverse tipologie di apparecchiature HW di Proprietà gestibili, siano analoghe a quanto indicato per le corrispondenti apparecchiature HW in locazione operativa (rif. §4.3), salvo le inevitabili differenze o specificità dovute a diversità di marca, modello, prestazioni, dotazioni accessorie e vetustà, rispetto alle apparecchiature di nuova fabbricazione offerte dal Fornitore in locazione operativa. Un approfondimento specifico viene riportato nei paragrafi 4.5.3.8 e 4.5.3.11 seguenti, in relazione alle stampanti a getto d’inchiostro personali ed alle stampanti a matrice di workgroup, per le quali non è previsto un corrispondente servizio di locazione operativa.

Le unità HW di proprietà eventualmente sottoposte alla manutenzione HW non presenteranno comunque una vetustà superiore ai 5 anni (in realtà difficilmente superiore ai 3-4 anni), ad eccezione delle stampanti a matrici di workgroup per cui il limite di vetustà si innalza a 10 anni.

4.5.3.1. MH.PR.PCDT – Manutenzione HW PC desktop di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di PC desktop di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.2. MH.PR.PCTC – Manutenzione HW PC thin client di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di PC thin client di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.3. MH.PR.NTBK – Manutenzione HW notebook di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di notebook di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.4. MH.PR.MNTR – Manutenzione HW monitor LCD di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di monitor LCD di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.5. MH.PR.STLB – Manutenzione HW stampante laser in bianco/nero personale di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di stampanti laser in bianco/nero personali di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.6. MH.PR.STLC – Manutenzione HW stampante laser a colori personale di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di stampanti laser a colori personali di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.7. MH.PR.STTR – Manutenzione HW stampante termica personale per etichette di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di stampanti termiche personali per etichette di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif.

§3.1.1).

4.5.3.8. MH.PR.STGI – Manutenzione HW stampante a getto d’inchiostro personale di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di stampanti a getto d’inchiostro personali di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

Le caratteristiche di riferimento per questa tipologia di apparecchiatura sono del tutto generali e deducibili dall’attuale parco di stampanti a getto d’inchiostro personali censito nel paragrafo Error! Reference source not found.; in particolare si evidenzia che il massimo formato supportato è A3.

4.5.3.9. MH.PR.SCAF – Manutenzione HW scanner personale con ADF di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di scanner personali con ADF di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.10. MH.PR.SMWL – Manutenzione HW apparecchiatura multifunzione laser di workgroup di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di apparecchiature multifunzione laser di workgroup di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.5.3.11. MH.PR.STMT – Manutenzione HW stampante a matrice di workgroup di proprietà

Il servizio rappresenta la manutenzione HW, nel rispetto delle condizioni generali (rif. §4.5.1), di stampanti a matrice di workgroup di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

Le caratteristiche di riferimento per questa tipologia di apparecchiatura sono deducibili dall’attuale parco di stampanti a matrice (che in realtà consta di solamente cinque unità), censito nel paragrafo 7.1.3.2.

4.6. RT – Xxxxxx XXXX

Il servizio consiste nel ritiro e nello smaltimento di apparecchiature HW considerate come Rifiuti da Apparecchiature Elettriche ed Elettroniche (RAEE) secondo quanto previsto dalla normativa vigente.

Esso potrà essere impiegato dall’Ateneo per avviare al trattamento di fine vita le apparecchiature di sua proprietà di cui non si valuta più possibile o conveniente l’utilizzo.

4.6.1. Condizioni generali

Il servizio riguarda esclusivamente le unità HW di proprietà dell’Ateneo, identificabili con i termini HW da Locazione Operativa e HW di Proprietà definiti nel paragrafo 3.1.1; in qualsiasi caso rimane totale responsabilità del Fornitore gestire l’eventuale trattamento di fine vita di qualsiasi materiale di sua proprietà.

Le analoghe attività che si rivelino necessarie per il corretto smaltimento di materiali di risulta prodotti dal servizio di manutenzione HW (rif. §4.5), quand’anche fosse coinvolta la sostituzione completa dell’intera unità HW, sono da considerarsi totalmente incluse nel servizio stesso di manutenzione HW.

Il servizio di ritiro XXXX dovrà essere svolto in coerenza e nel rispetto dei requisiti e modalità di legge, secondo la normativa applicabile, quale, in maniera non esaustiva:

• D.Lgs. 151/2005 e ss.mm.ii.,

• D.Lgs. 152/2006 e ss.mm.ii.,

• DM 25/9/2007,

• DM 65/2010,

• DM Ambiente 17 dicembre 2009 – SISTRI – recante l’istituzione del nuovo sistema di controllo della tracciabilità dei rifiuti e ss.mm.ii.,

• D.Lgs. n. 205/2010.

Il Fornitore si impegna, inoltre, a consegnare all'Ateneo il formulario di cui all'art. 188, comma 3 lett. b) e 188 bis del decreto legislativo richiamato sopra, nelle modalità e termini ivi previsti, ed al conferimento dei RAEE ai soli impianti di smaltimento e recupero autorizzati ai sensi degli artt. 208 e ss. del D.Lgs. 152/2006 e ss.mm.ii..

Il servizio comprende le attività di predisposizione al trasporto, di trasporto e consegna all’impianto di smaltimento e infine di certificazione dell’avvenuto smaltimento tramite idonea documentazione. Sarà responsabilità del Fornitore anche lo smaltimento del materiale utile al trasporto, quali gli imballaggi.

E’ esclusa l’attività di cancellazione dei cespiti dal patrimonio delle apparecchiature, che verrà svolta dai normali servizi amministrativi dell’Ateneo.

Il servizio potrà essere richiesto esclusivamente dai referenti dell’Ateneo per i servizi di Fleet Management, direttamente o come parte di un’operazione Remove del servizio IMAC-R (rif. §4.2.4.6.5).

Il Fornitore potrà organizzare, concordandolo con l’Ateneo, il ritiro RAEE per stock, ossia aggregando e immagazzinando temporaneamente il materiale indicato da una o più richieste, fino a consolidare un carico da avviare allo smaltimento. In tale caso è importante sottolineare che:

• se il materiale è collegato ad una PdL attiva e quindi la sua rimozione rientra in un’operazione Remove del servizio IMAC-R, è fondamentale innanzitutto il ritiro del materiale dalla sede universitaria al fine di liberare gli spazi occupati (si veda il sotto-paragrafo seguente sui livelli di servizio);

• l’eventuale immagazzinamento temporaneo rimane in ogni caso in carico al Fornitore, che dovrà utilizzare propri locali di propria pertinenza (quali ad esempio quelli previsti per il servizio di immagazzinamento descritto nel paragrafo 4.2.4.2), salvo concordare con l’Ateneo l’utilizzo di idonei locali universitari;

• la data di consolidamento dello stock per l’avviamento allo smaltimento deve essere nota/concordata con l’Ateneo, che potrà così verificare il rispetto dei livelli di servizio (come indicato nel sotto-paragrafo seguente sui livelli di servizio).

In fase di startup dell’appalto (rif. §4.1.2.1), verrà definita congiuntamente fra le parti la procedura di dettaglio per l’esecuzione del servizio.

Service Level Agreement

Nell’ambito dell’attivazione del servizio all’interno di un’operazione Remove (rif. §4.2.4.6.5) si applicano i livelli di servizio generali del servizio IMAC-R.

Al servizio si applicano inoltre i seguenti SLA:

• SL.RT.00.EROG.1

4.6.2. RT.UC – Ritiro RAEE Unità Centrale

Nell’ambito del possibile HW di Proprietà dell’Ateneo di tipo UC, vengono definiti i seguenti servizi di ritiro RAEE, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista.

4.6.2.1. RT.UC.PCDT – Ritiro RAEE PC desktop

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di PC desktop di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.6.2.2. RT.UC.PCTC – Xxxxxx XXXX PC thin client

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di PC thin client di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.6.2.3. RT.UC.NTBK – Xxxxxx XXXX notebook

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di notebook di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.6.3. RT.PP – Ritiro RAEE Unità Periferica Personale

Nell’ambito del possibile HW di Proprietà dell’Ateneo di tipo UPP, vengono definiti i seguenti servizi di ritiro RAEE, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista.

4.6.3.1. RT.PP.MNTR – Ritiro RAEE monitor LCD

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di monitor LCD di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.6.3.2. RT.PP.STLS – Ritiro RAEE stampante laser personale

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di stampanti laser in bianco/nero o a colori personali di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif.

§3.1.1).

4.6.3.3. RT.PP.STTR – Ritiro RAEE stampante termica personale per etichette

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di stampanti termiche personali per etichette di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.6.3.4. RT.PP.STGI – Ritiro RAEE stampante a getto d’inchiostro personale

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di stampanti a getto d’inchiostro personali di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.6.3.5. RT.PP.SCAF – Ritiro RAEE scanner personale con ADF

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di scanner personali con ADF di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

4.6.4. XX.XX – Ritiro RAEE Unità Periferica di Workgroup

Nell’ambito del possibile HW di Proprietà dell’Ateneo di tipo UPW, vengono definiti i seguenti servizi di ritiro RAEE, in corrispondenza di ogni singola tipologia di apparecchiatura HW prevista.

4.6.4.1. RT.PW.SMWL – Ritiro RAEE apparecchiatura multifunzione laser di workgroup

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di apparecchiature multifunzione laser di workgroup di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif.

§3.1.1).

4.6.4.2. RT.PW.STMT – Ritiro RAEE stampante a matrice di workgroup

Il servizio rappresenta il ritiro RAEE, nel rispetto delle condizioni generali (rif. §4.6.1), di stampanti a matrice di workgroup di proprietà dell’Ateneo, secondo la definizione di HW di Proprietà (rif. §3.1.1).

5. Piano di attivazione dei servizi richiesti

Nel seguente capitolo viene presentata la pianificazione di riferimento che l’Ateneo, nella fattispecie il Centro InfoSapienza, ha delineato come opportuna e sostenibile per la gestione e l’erogazione dei servizi di Fleet Management per i propri utenti.

Il piano è sicuramente frutto del contesto, delle strategie e degli obiettivi generali, consolidati, e di un approccio ben preciso (descritto nel paragrafo seguente), che l’Università intende perseguire nel periodo interessato, ma inevitabilmente anche strettamente correlato alle informazioni ed alla visibilità correntemente disponibili. Per tale motivo, si ribadisce la riserva del Centro InfoSapienza ad apportare, durante

l’esecuzione del contratto, variazioni minori al piano di riferimento illustrato, come già indicato nel paragrafo 3.2.

5.1. Approccio complessivo

Il piano di attivazione dei servizi di Fleet Management oggetto dell’appalto seguirà un approccio, volto chiaramente al raggiungimento degli obiettivi complessivi già ampiamente illustrati, articolato sui seguenti princìpi:

• Durante la fase di startup (rif. §4.1.2.1), oltre alle attività di definizione e messa a regime delle soluzioni organizzative, tecnologiche (vedi sistemi di supporto, rif. §4.1.1) e procedurali necessarie per attivare l’erogazione dei servizi, si dovrà in tempi ristretti procedere all’attivazione dei servizi di locazione operativa per una consistente quota del parco macchine complessivo. In particolare si procederà a:

o installare/sostituire l’UC per circa il 40% delle PdL;

o installare/sostituire gli scanner e le stampanti termiche per circa il 50% delle unità totali previste a regime;

o installare/sostituire le apparecchiature multifunzione di workgroup per circa il 35% delle unità totali previste a regime;

o installare/sostituire le stampanti laser personali (in bianco/nero e a colori) per circa il 50% delle unità totali previste a regime, secondo una nuova politica dell’Ateneo volta a fornire di unità personale solo una porzione circoscritta (circa il 25%) delle PdL (rispetto all’attuale quota del 45% delle PdL).

• Contestualmente all’attivazione della locazione operativa di nuovo HW per una parte del parco macchine complessivo, si procederà ad attivare da subito il servizio di manutenzione HW di Proprietà per la rimanente parte del parco macchine, costituito da apparecchiature di limitata vetustà (minore di 3-4 anni). Tale HW di Proprietà in generale si può assumere che sarà fuori garanzia del produttore, salvo minime eccezioni in quantità contenute, indicativamente nell’ordine di 20-30 PC desktop standard, 10-20 notebook, 20-30 scanner personali con ADF, 20-30 stampanti termiche personali per etichette.

• Progressivamente, dal termine della fase di startup ed entro il primo trimestre del secondo anno di contratto (indicativamente in due tranche), verrà completata la sostituzione di tutte le apparecchiature HW di Proprietà, attivando il servizio di locazione operativa per le nuove apparecchiature e smaltendo come RAEE le vecchie unità sostituite.

• Nei due anni centrali del periodo contrattuale è presumibile assistere ad una stabilizzazione dei consumi, salvo valutare e gestire eventuali esigenze specifiche non previste.

• Durante il quarto anno di contratto verranno tendenzialmente riscattate le apparecchiature HW per cui risulti terminato il servizio di locazione operativa e contestualmente attivato il servizio di manutenzione HW da Locazione Operativa.

• Al termine del periodo contrattuale verrà infine valutata la migliore opzione di terminazione del servizio di locazione operativa sia per quelle apparecchiature HW non ancora giunte a terminazione naturale del noleggio sia per quelle per cui la terminazione fra contratto e noleggio coincide temporalmente; a tal proposito, l’Ateneo potrà quindi eventualmente ricorrere al servizio di riscatto.

5.2. Pianificazione temporale di riferimento

In linea con quanto già descritto in relazione all’approccio complessivo ipotizzato dall’Ateneo (rif. 5.1), il diagramma in Figura 1 sintetizza macroscopicamente la pianificazione temporale di riferimento per l’esecuzione dei servizi richiesti, rispetto al periodo contrattuale previsto (rif. §3.3) suddiviso per trimestri contrattuali, ossia per periodi di tre mesi consecutivi, calcolati a partire dalla data di sottoscrizione del contratto; dati i fini puramente illustrativi, nel diagramma vengono menzionati solo alcuni servizi, ritenuti più significativi agli scopi.

Macro-Attività	Rif. Servizi	Trimestri Contrattuali
		1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
Setup dei sistemi di supporto	XX.XX
Fase di startup	SO.AP.STUP
Gestione delle PdL	GP
Locazione operativa (1° tranche)	LO
Locazione operativa (2° tranche)	LO
Manutenzione HW di Proprietà	XX.XX
Locazione operativa (3° tranche)	LO
Riscatto (1° e 2° tranche)	RI
Manutenzione HW da Locazione Operativa	MH.LO
Fase finale	SO.AP.FINA

Figura 1 – Pianificazione temporale di riferimento dei servizi oggetto dell’appalto

5.3. Numerosità e distribuzione di riferimento

In linea con quanto già descritto in relazione all’approccio complessivo ipotizzato dall’Ateneo (rif. 5.1) ed analogamente per quanto fatto da un punto di vista temporale nel paragrafo precedente, la Tabella 21 sintetizza macroscopicamente la pianificazione temporale di riferimento per l’esecuzione dei servizi richiesti, rispetto al periodo contrattuale previsto (rif. §3.3) suddiviso per trimestri contrattuali, ossia per periodi di tre mesi consecutivi, calcolati a partire dalla data di sottoscrizione del contratto; nel diagramma vengono riportati solo i servizi che prevendono un corrispettivo economico.

Rif. Servizio	Descrizione Breve Servizio	Numerosità Attivazioni per Trimestre Contrattuale
Rif. Servizio	Descrizione Breve Servizio	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
GP	Gestione PdL	1070	1070	1070	1070	1070	1070	1070	1070	1070	1070	1070	1070	1070	1070	1070	1070
LO.UC.PCDS	Loc. Oper. PC desktop standard	400	400	660	660	900	900	900	900	900	900	900	900	500	500	240	240
LO.UC.PCDA	Loc. Oper. PC desktop ad alte prestazioni	0	0	100	100	100	100	100	100	100	100	100	100	100	100	0	0
LO.UC.PCTC	Loc. Oper. PC thin client	0	0	30	30	30	30	30	30	30	30	30	30	30	30	0	0
LO.UC.NTBK	Loc. Oper. notebook	30	30	30	30	40	40	40	40	40	40	40	40	10	10	10	10
LO.PP.MNTS	Loc. Oper. monitor LCD standard	410	410	710	710	960	960	960	960	960	960	960	960	550	550	250	250
LO.PP.MNTA	Loc. Oper. monitor LCD ad alte prestazioni	0	0	100	100	100	100	100	100	100	100	100	100	100	100	0	0
LO.PP.STLB	Loc. Oper. stampante laser in b/n personale	100	100	140	140	170	170	170	170	170	170	170	170	70	70	30	30
LO.PP.STLC	Loc. Oper. stamp. laser a colori personale	40	40	80	80	110	110	110	110	110	110	110	110	70	70	30	30
LO.PP.STTR	Loc. Oper. stampante termica per etichette	40	40	40	40	80	80	80	80	80	80	80	80	40	40	40	40
LO.PP.SCAF	Loc. Oper. scanner personale con ADF	000	000	000	170	200	200	200	200	200	200	200	200	100	100	30	30
LO.PW.SMWL	Loc. Oper. app. multifunzione laser	20	20	40	40	60	60	60	60	60	60	60	60	40	40	20	20
RI.UC.PCDS	Riscatto PC desktop standard	-	-	-	-	-	-	-	-	-	-	-	-	400	0	260	0
RI.UC.PCDA	Riscatto PC desktop ad alte xxxxxxxxxxx	-	-	-	-	-	-	-	-	-	-	-	-	0	0	100	0
RI.UC.PCTC	Riscatto PC thin client	-	-	-	-	-	-	-	-	-	-	-	-	0	0	30	0
RI.UC.NTBK	Xxxxxxxx xxxxxxxx	-	-	-	-	-	-	-	-	-	-	-	-	00	0	0	0
RI.PP.MNTS	Riscatto monitor LCD standard	-	-	-	-	-	-	-	-	-	-	-	-	410	0	300	0
RI.PP.MNTA	Riscatto monitor LCD ad alte xxxxxxxxxxx	-	-	-	-	-	-	-	-	-	-	-	-	0	0	100	0
RI.PP.STLB	Riscatto stampante laser in b/n personale	-	-	-	-	-	-	-	-	-	-	-	-	100	0	40	0
RI.PP.STLC	Riscatto stampante laser a colori personale	-	-	-	-	-	-	-	-	-	-	-	-	40	0	40	0
RI.PP.STTR	Riscatto stampante termica per etichette	-	-	-	-	-	-	-	-	-	-	-	-	40	0	0	0
RI.PP.SCAF	Riscatto scanner personale con ADF	-	-	-	-	-	-	-	-	-	-	-	-	100	0	70	0
RI.PW.SMWL	Riscatto app. multifunzione xxxxx	-	-	-	-	-	-	-	-	-	-	-	-	00	0	20	0
MH.LO.PCDT	Manut. HW PC desktop da xxx. xxxxxxxxx	-	-	-	-	-	-	-	-	-	-	-	-	000	400	760	760
MH.LO.PCTC	Manut. HW PC thin client da xxx. xxxxxxxxx	-	-	-	-	-	-	-	-	-	-	-	-	0	0	30	30

Rif. Servizio	Descrizione Breve Servizio	Numerosità Attivazioni per Trimestre Contrattuale
Rif. Servizio	Descrizione Breve Servizio	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
MH.LO.NTBK	Manut. HW notebook da xxx. xxxxxxxxx	-	-	-	-	-	-	-	-	-	-	-	-	00	30	30	30
MH.LO.MNTR	Manut. HW monitor LCD da xxx. xxxxxxxxx	-	-	-	-	-	-	-	-	-	-	-	-	000	410	810	810
MH.LO.STLB	Manut. HW stamp. laser in b/n da xxx. xxxx.	-	-	-	-	-	-	-	-	-	-	-	-	000	100	140	140
MH.LO.STLC	Manut. HW stamp. laser a colori da xxx. xx.	-	-	-	-	-	-	-	-	-	-	-	-	00	40	80	80
MH.LO.STTR	Manut. HW stampante termica da xxx. xxxx.	-	-	-	-	-	-	-	-	-	-	-	-	00	40	40	40
MH.LO.SCAF	Manut. HW scanner con ADF da xxx. xxxx.	-	-	-	-	-	-	-	-	-	-	-	-	000	100	170	170
MH.LO.SMWL	Manut. HW app. multif. laser da xxx. xxxx.	-	-	-	-	-	-	-	-	-	-	-	-	00	20	40	40
MH.PR.PCDT	Manut. HW PC desktop di proprietà	600	600	240	240	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.PCTC	Manut. HW PC thin client di proprietà	30	30	0	0	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.NTBK	Manut. HW notebook di proprietà	10	10	10	10	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.MNTR	Manut. HW monitor LCD di proprietà	600	600	240	240	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.STLB	Manut. HW stamp. laser in b/n di proprietà	70	70	30	30	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.STLC	Manut. HW stamp. laser a colori di proprietà	5	5	5	5	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.STTR	Manut. HW stampante termica di proprietà	40	40	40	40	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.STGI	Manut. HW stamp. a getto d’inc. di proprietà	70	70	30	30	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.SCAF	Manut. HW scanner con ADF di proprietà	100	100	30	30	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.SMWL	Manut. HW app. multifunz. laser di proprietà	40	40	20	20	-	-	-	-	-	-	-	-	-	-	-	-
MH.PR.STMT	Manut. HW stampanti a matrice di proprietà	5	5	5	5	5	5	5	5	2	2	2	2	2	2	2	2
RT.UC.PCDT	Ritiro RAEE PC desktop	-	-	3600	0	2400	-	-	-	-	-	-	-	-	-	-	-
RT.UC.PCTC	Xxxxxx XXXX PC thin client	-	-	150	0	0	-	-	-	-	-	-	-	-	-	-	-
RT.UC.NTBK	Ritiro RAEE notebook	-	-	0	0	30	-	-	-	-	-	-	-	-	-	-	-
RT.PP.MNTR	Ritiro RAEE monitor LCD	-	-	1080	0	720	-	-	-	-	-	-	-	-	-	-	-
RT.PP.STLS	Ritiro RAEE stampante laser personale	-	-	440	0	380	-	-	-	-	-	-	-	-	-	-	-
RT.PP.STTR	Ritiro RAEE stampante termica personale	-	-	0	0	400	-	-	-	-	-	-	-	-	-	-	-
RT.PP.STGI	Ritiro RAEE stamp. a getto d’inch. person.	-	-	400	0	300	-	-	-	-	-	-	-	-	-	-	-
RT.PP.SCAF	Ritiro RAEE scanner personale con ADF	-	-	350	0	150	-	-	-	-	-	-	-	-	-	-	-
RT.PW.SMWL	Ritiro RAEE apparec. multifunzione laser	-	-	1000	0	1000	-	-	-	-	-	-	-	-	-	-	-
RT.PW.STMT	Ritiro RAEE stampante a matrice di workgr.	-	-	-	-	-	-	-	-	160	-	-	-	-	-	-	-

Tabella 21 – Numerosità e distribuzione di riferimento dei servizi oggetto dell’appalto

6. Sistema di qualità

L’erogazione dei servizi richiesti dovrà avvenire in regime di qualità, secondo gli standard UNI EN ISO 9001:2008, nel settore EA 33 – “ Tecnologia dell’Informazione”.

Il Fornitore, sulla base dei requisiti e dei livelli di qualità richiesti dall’Ateneo, dovrà predisporre e impiegare un adeguato sistema di qualità, che abiliti, monitori e misuri la qualità dei servizi erogati, attraverso le seguenti componenti illustrate nel presente capitolo:

• Piano di Qualità,

• Indicatori di Qualità,

• Service Level Agreement,

• penali applicabili.

6.1. Piano di Qualità

Il Fornitore, nell’ambito delle attività previste per la fase di startup dell’appalto (rif. §4.1.2.1), dovrà predisporre e fornire all’Ateneo il Piano di Qualità della fornitura.

Tale Piano di Qualità sarà valutato dal Centro InfoSapienza, il quale procederà, entro 15 (quindici) giorni solari dalla data di emissione, o ad una esplicita approvazione o alla formulazione di rilievi; gli eventuali rilievi dovranno essere recepiti dal Fornitore entro 10 (dieci) giorni solari dalla loro ricezione.

Il Fornitore, nello svolgimento delle attività contrattualmente previste, dovrà attenersi e dovrà essere conforme a quanto previsto dal Piano di Qualità approvato.

In particolare il Piano di Qualità dovrà:

• fornire lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del sistema di qualità del Fornitore già esistenti;

• esplicitare le disposizioni organizzative e metodologiche adottate dal Fornitore, allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;

• dettagliare i metodi di lavoro messi in atto dal Fornitore, facendo riferimento o a procedure relative al proprio sistema, e per ciò descritte nel manuale qualità, o a procedure sviluppate per la specifica fornitura in oggetto, a supporto delle attività in essa prevista, in questo caso da allegare al Piano;

• garantire il corretto e razionale evolversi delle attività contrattualmente previste, nonché la trasparenza e la tracciabilità di tutte le azioni messe in atto dalle parti.

Il Fornitore dovrà accettare, in corso di vigenza contrattuale, le eventuali verifiche ispettive (verifiche mirate o verifiche di seconda parte), effettuate dall’organismo di ispezione designato dal Centro InfoSapienza e svolte nel rispetto di quanto prescritto dalla serie di norme EN ISO 19011, allo scopo di verificare il rispetto di quanto stabilito nel Piano di Qualità.

6.2. Indicatori di Qualità

Gli Indicatori di Qualità (IQ) rappresentano misurazioni sintetiche di determinati eventi o risultati caratterizzanti l’erogazione da parte del Fornitore dei servizi richiesti, significativi del loro livello di qualità e rispetto ai quali pertanto l’Ateneo e il Fornitore stesso possono basare una valutazione dell’andamento della fornitura, dei risultati prodotti, della bontà delle soluzioni predisposte (organizzative, tecnologiche, procedurali), nonché definire degli obiettivi target e sviluppare le strategie di evoluzione e miglioramento continuo.

A tal fine gli IQ sono rappresentati da valori oggettivi e quantitativi, strettamente numerici, e non pertanto soggettivi o qualitativi.

Tutti gli IQ previsti dovranno essere indicati nel Piano di Qualità generale da sottoporre all’approvazione del Centro InfoSapienza. Il Fornitore è tenuto, per l’intera durata contrattuale, a rendicontare gli IQ attraverso gli specifici servizi, quali:

• il monitoraggio e rendicontazione dei servizi (rif. §4.1.2.3),

• la valutazione e rendicontazione della customer satisfaction (rif. §4.2.5.3), e i sistemi di supporto previsti (rif. §4.1.1), quali:

• il sistema di gestione della customer satisfaction,

• il sistema di reportistica e SLA management.

Nel presente capitolo si riportano gli IQ da applicare ai servizi oggetto dell’appalto.

Per ogni IQ viene fornita una descrizione in forma tabellare riportante le seguenti informazioni:

• il codice identificativo dell’IQ,

• una descrizione breve dell’IQ,

• l’unità di misura (UM) dell’IQ,

• il periodo di riferimento usato come base di calcolo dell’indicatore,

• il riferimento ad eventuali penali applicabili in caso si rilevi un degrado eccessivo della qualità, con rimando al capitolo 6.4 per maggiori dettagli a riguardo,

• una descrizione estesa dell’IQ e delle modalità di calcolo,

• eventuali note sulle modalità di calcolo o sul dominio di applicazione.

IQ	Descrizione breve	UM	Periodo	Penali applicabili
IQ.01.SCAD.1	Rispetto delle scadenze	Giorni	Semestrale	Non applicabile
Descrizione di dettaglio		Note sulle modalità di calcolo
Indicatore complessivo del rispetto delle scadenze stabilite o concordate fra le parti in virtù di requisiti contrattuali, piani di lavoro approvati o altri documenti ufficiali, rientranti nel periodo di riferimento. Per una qualità ottimale, il valore dell’indicatore deve tendere a zero		L’indicatore è determinato come la somma dei ritardi per ogni data di scadenza rientrante nel periodo di riferimento. Per ogni data di scadenza il ritardo è da intendersi come pari a: • zero giorni se il Fornitore ha rispettato (o anticipato) la data di scadenza, • la differenza (positiva) in giorni lavorativi fra la data effettiva e la data di scadenza se la data effettiva è stata successiva alla data di scadenza. Per data effettiva si intende la data in cui il Fornitore dimostra, rispetto a criteri concordati precedentemente fra le parti, di aver completamente erogato la prestazione richiesta. Sono oggetto del calcolo dell’indicatore solo le date di scadenza non rientranti direttamente nell’ambito di applicazione specifico di SLA contrattuali

IQ	Descrizione breve	UM	Periodo	Penali applicabili
IQ.02.PERS.1	Adeguatezza del personale del Fornitore	Intero	Semestrale	• PN.IQ.02.PERS.1
Descrizione di dettaglio		Note sulle modalità di calcolo
Indicatore complessivo della capacità di impiego, da parte del Fornitore, di personale pienamente adeguato alle caratteristiche ed ai livelli di qualità attesi dei servizi, in termini di competenze, esperienza e professionalità. Per una qualità ottimale, il valore dell’indicatore deve tendere a zero		L’indicatore è determinato dal numero di risorse sostituite su richiesta, in forma ufficiale e adeguatamente motivata, dell’Ateneo, nei casi più severi o a seguito di reiterate segnalazioni, nel periodo di riferimento. L’indicatore non si applica durante il primo semestre contrattuale

IQ	Descrizione breve	UM	Periodo	Penali applicabili
IQ.02.PERS.2	Turnover del personale gestionale	Intero	Annuale	• PN.IQ.02.PERS.2
Descrizione di dettaglio		Note sulle modalità di calcolo
Indicatore complessivo della continuità, resa disponibile da parte del Fornitore, del personale ricoprente i ruoli gestionali di: • Responsabile Operativo/Project Manager, • Responsabile Unico per la Fornitura/Service Manager. Per una qualità ottimale, il valore dell’indicatore deve tendere a zero		L’indicatore è determinato dal numero di sostituzioni, effettuate dal Fornitore per propria iniziativa nel periodo di riferimento, di personale incaricato di ricoprire i ruoli gestionali indicati nell’ambito dei servizi di project management (codice SO.AP.PROJ) e service management (codice SO.AP.SRVC). Sono escluse dal computo le sostituzioni richieste dall’Ateneo in caso di inadeguatezza del personale

IQ	Descrizione breve	UM	Periodo	Penali applicabili
IQ.03.CSAT.1	Customer satisfaction puntuale	Numerico	Semestrale	Non applicabile
Descrizione di dettaglio		Note sulle modalità di calcolo
Indicatore del livello di soddisfazione totale degli utenti misurato puntualmente e contestualmente all’evasione delle richieste di servizio avanzate dagli utenti / PdL verso il servizio di Contact center, nel periodo di riferimento		Le modalità di calcolo dovranno essere espresse dal Fornitore in sede di Offerta Tecnica secondo la modalità di erogazione proposta per il servizio di valutazione e rendicontazione della customer satisfaction (codice GP.BO.CSAT)

IQ	Descrizione breve	UM	Periodo	Penali applicabili
IQ.03.CSAT.2	Customer satisfaction complessiva	Numerico	Annuale	Non applicabile
Descrizione di dettaglio		Note sulle modalità di calcolo
Indicatore del livello di soddisfazione complessiva totale degli utenti per l’intero corpo di servizi di Fleet Management, nel periodo di riferimento		Le modalità di calcolo dovranno essere espresse dal Fornitore in sede di Offerta Tecnica secondo la modalità di erogazione proposta per il servizio di valutazione e rendicontazione della customer satisfaction (codice GP.BO.CSAT)

IQ	Descrizione breve	UM	Periodo	Penali applicabili
IQ.04.RILV.1	Rilievi sulla fornitura	Intero	Semestrale	• PN.IQ.04.RILV.1 • PN.IQ.04.RILV.2
Descrizione di dettaglio		Note sulle modalità di calcolo
Indicatore del livello di ineccepibilità complessiva della fornitura per l’intero corpo di servizi di Fleet Management, ossia dell’adeguato rispetto, da parte del Fornitore, di tutte le adempienze contrattuali o normative e dell’adeguata professionalità ed efficacia. Per una qualità ottimale, il valore dell’indicatore deve tendere a zero		L’indicatore è determinato dal numero di rilievi formali, notificati ufficialmente in forma scritta al Fornitore, nel periodo di riferimento. I rilievi considerati possono afferire, a titolo di esempio non esaustivo, a: • servizi oggetto dell’appalto, • obblighi contrattuali non adempiuti nei tempi e nei modi stabiliti da documenti ufficiali, • inadempimenti ai sensi di normativa vigente applicabile

IQ	Descrizione breve	UM	Periodo	Penali applicabili
IQ.05.DFHW.1	Difettosità HW delle apparecchiature fornite	Intero	Trimestrale	Non applicabile
Descrizione di dettaglio		Note sulle modalità di calcolo
Indicatore del livello di affabilità delle apparecchiature HW fornite il locazione operativa. Per una qualità ottimale, il valore dell’indicatore deve tendere a zero		L’indicatore è determinato dal numero di difettosità/malfunzionamenti HW gestiti nell’ambito del servizio di manutenzione HW nel periodo di riferimento. Sono oggetto del calcolo dell’indicatore solo le difettosità riscontrate su apparecchiature HW in locazione operativa, nel corso del periodo di noleggio

6.2.1. Revisione degli Indicatori di Qualità

Durante l’intero periodo contrattuale ciascun IQ potrà essere riesaminato su richiesta del Centro InfoSapienza; il riesame potrà derivare da nuovi strumenti di misurazione non disponibili alla data di stipula del contratto e/o dall’adeguamento delle metodiche atte alla rilevazione ed al calcolo dei singoli IQ che sono risultate non efficaci.

Il Centro InfoSapienza ed il Fornitore, in caso di necessità, concorderanno eventuali modifiche ai metodi di calcolo successivamente riportati e tracciati nel Piano di Qualità. Il Fornitore sarà tenuto ad erogare i servizi tenendo conto delle modifiche richieste e a recepirle nel Piano, da sottoporre all’approvazione del Centro InfoSapienza.

6.3. Service Level Agreement

Nel presente capitolo si riportano i Service Level Agreement (SLA) da applicare ai servizi oggetto dell’appalto.

Per ogni SLA viene fornita un descrizione in forma tabellare riportante le seguenti informazioni:

• il codice identificativo composito dello SLA,

• una descrizione breve dello SLA,

• il periodo di riferimento usato come base di calcolo del livello di servizio,

• il riferimento ad eventuali penali applicabili in caso di non rispetto dello SLA, con rimando al capitolo

6.4 per maggiori dettagli a riguardo,

• una descrizione estesa del livello di servizio atteso e delle modalità di calcolo,

• eventuali note sulle modalità di calcolo o sul dominio di applicazione,

• il codice dei servizi (uno o più) a cui si applica lo SLA.

Per gli SLA che non prevedono penali direttamente applicabili, in caso di mancato rispetto da parte del Fornitore, l’Ateneo potrà provvedere a notificare un rilievo formale di inadempienza, che sarà oggetto di valutazione attraverso lo specifico IQ (codice IQ.04.RILV.1) previsto dal sistema di qualità (rif. §6.2).

Si evidenzia che l’applicazione di penali, a fronte di mancato rispetto degli SLA, non sarà ammissibile durante la fase di startup dell’appalto, come indicato nel paragrafo 4.1.2.1.

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.AM.INVE.1	Completezza dell’aggiornamento dell’inventario	Mensile	Non applicabile
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Il sistema di asset inventory deve registrare nell’inventario tutte le variazioni occorse nel parco macchine gestito, in modo da garantire un corretto allineamento della base dati con la configurazione reale. Ogni variazione deve essere registrata entro 16 ore dall’evento che l’ha generata		Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.AM.INVE

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.AM.INVE.2	Qualità dei dati dell’inventario	Mensile	• PN.GP.AM.INVE.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Le informazioni registrate nell’inventario gestito dal sistema di asset inventory devono essere sempre veritiere e accurate, presentando complessivamente al più 10 difformità in caso di verifica da parte dell’Ateneo		Non sono considerate difformità le informazioni che in fase di verifica non risultino veritiere e accurate perché interessate da un evento di variazione non ancora registrato nell’inventario, purché il Fornitore dimostri, attraverso evidenze documentali, che per tale evento lo SLA SL.GP.AM.INVE.1 sia ancora rispettato	• GP.AM.INVE

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.RM.CONT.1	Tempo di risposta alle richieste	Mensile	Non applicabile
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Risposta entro i tempi limite per il 90% delle richieste. I tempi limite sono così definiti: • 2 minuti in caso di richiesta via telefono, • 20 minuti in caso di richiesta via email o via web Risposta entro i tempi massimi per il 100% delle richieste. I tempi massimi sono così definiti: • 8 minuti in caso di richiesta via telefono, • 120 minuti in caso di richiesta via email o via web		Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. Per la definizione dell’evento di “risposta” si veda la descrizione del servizio interessato	• GP.RM.CONT

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.RM.CONT.2	Percentuale di richieste senza risposta	Mensile	Non applicabile
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Percentuale di richieste senza risposta non superiore al 4%		Per la definizione dell’evento di “risposta” si veda la descrizione del servizio interessato. La risposta è considerata mancante se: • per richieste telefoniche, non si ottiene risposta da un operatore entro 5 minuti o segue il segnale di occupato; • per richieste via email o via web, non segue risposta entro 2 ore	• GP.RM.CONT

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.RM.HDSK.1	Tempo di reazione per richieste di priorità 1	Mensile	• PN.GP.RM.HDSK.1 • PN.GP.RM.HDSK.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 1 l’Help desk deve completare la propria gestione da remoto entro 4 ore per l’85% delle richieste, ossia entro tale limite di tempo: • la richiesta è stata evasa completamente • oppure è stata comunicata al DEC per convalida (ove applicabile, salvo regole di convalida automatica) • oppure è stata inoltrata ai servizi di gestione in locale previa motivazione adeguatamente documentata (nella storia del ticket). L’Help desk deve comunque completare la propria gestione da remoto entro 8 ore dalla richiesta		Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.RM.HDSK • GP.RM.ISWR • GP.RM.ASPL • GP.RM.ASSW

SLA

Descrizione breve

Periodo

Penali applicabili

SL.GP.RM.HDSK.2

Tempo di reazione per richieste di priorità 2

Mensile

• PN.GP.RM.HDSK.2

• PN.GP.RM.HDSK.4

Descrizione di dettaglio

Note sulle modalità di calcolo

Servizi interessati

Per le richieste di priorità 2 l’Help desk deve completare la propria gestione da remoto entro 8 ore per il 90% delle richieste, ossia entro tale limite di tempo:

• la richiesta è stata evasa completamente,

• oppure è stata comunicata al DEC per convalida (ove applicabile, salvo regole di convalida automatica)

• oppure è stata inoltrata ai servizi di gestione in locale previa motivazione adeguatamente documentata (nella storia del ticket).

L’Help desk deve comunque completare la propria gestione da remoto entro 16 ore dalla richiesta

Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa

• GP.RM.HDSK

• GP.RM.ISWR

• GP.RM.ASPL

• GP.RM.ASSW

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.RM.HDSK.3	Tempo di reazione per richieste di priorità 3	Mensile	• PN.GP.RM.HDSK.3 • PN.GP.RM.HDSK.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 3 l’Help desk deve completare la propria gestione da remoto entro 12 ore per il 90% delle richieste, ossia entro tale limite di tempo: • la richiesta è stata evasa completamente, • oppure è stata comunicata al DEC per convalida (ove applicabile, salvo regole di convalida automatica) • oppure è stata inoltrata ai servizi di gestione in locale previa motivazione adeguatamente documentata (nella storia del ticket). L’Help desk deve comunque completare la propria gestione da remoto entro 24 ore dalla richiesta		Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.RM.HDSK • GP.RM.ISWR • GP.RM.ASPL • GP.RM.ASSW

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.RM.HDSK.4	Percentuale di richieste evase dall'Help desk in remoto	Trimestrale	• PN.GP.RM.HDSK.5
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Percentuale di richieste evase dal servizio di Help		Per richiesta evasa si intende una	• GP.RM.HDSK
desk in remoto, per richieste che non implicano manutenzione HW, non inferiore all’70%		richiesta completamente soddisfatta, il cui risultato è verificato e il cui ticket viene chiuso. Verranno esclusi dal computo richieste	• GP.RM.ISWR • GP.RM.ASPL • GP.RM.ASSW
		per cui la gestione in locale è dovuta
		all’impossibilità della gestione remota per
		cause non imputabili al Fornitore, previa
		adeguata documentazione e tracciatura

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.RM.SWDS.1	Tempo di presa in carico per aggiornamenti ordinari	Mensile	• PN.GP.RM.SWDS.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per ogni richiesta di aggiornamento ordinario il servizio di software distribution deve prendere in carico la richiesta entro 16 ore		La richiesta si intende presa in carico nel momento in cui il Fornitore costituisce e formalizza verso l’Ateneo il team / referente per l’intervento, con indicazione (almeno preliminare) dei tempi previsti per lo stesso. Per la definizione di richieste di aggiornamento ordinario si veda la descrizione del servizio interessato. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.RM.SWDS

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.RM.SWDS.2	Tempo di presa in carico per interventi urgenti	Mensile	• PN.GP.RM.SWDS.2
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per ogni richiesta di intervento urgente il servizio di software distribution deve prendere in carico la richiesta entro 4 ore		La richiesta si intende presa in carico nel momento in cui il Fornitore costituisce e formalizza verso l’Ateneo il team / referente per l’intervento, con indicazione (almeno preliminare) dei tempi previsti per lo stesso. Per la definizione di richieste di intervento urgente si veda la descrizione del servizio interessato. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.RM.SWDS

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.1	Tempo di intervento per richieste di priorità 1 su Roma	Mensile	• PN.GP.LC.INTL.1 • PN.GP.LC.INTL.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 1 per PdL site sul territorio del comune di Roma, il servizio di intervento tecnico in locale deve intervenire fisicamente sulla PdL entro 3 ore per l’85% delle richieste. Il servizio di intervento tecnico in locale deve comunque intervenire fisicamente entro 8 ore dalla richiesta		Il tempo di intervento è conteggiato a partire dal momento di assegnazione della richiesta al servizio di intervento tecnico in locale. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. Sono esclusi dal conteggio i casi di mancata pianificabilità dell’intervento, così come definiti per il servizio di intervento tecnico in locale, entro i primi 30 minuti. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.2	Tempo di intervento per richieste di priorità 2 su Roma	Mensile	• PN.GP.LC.INTL.2 • PN.GP.LC.INTL.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 2 per PdL site sul territorio del comune di Roma, il servizio di intervento tecnico in locale deve intervenire fisicamente sulla PdL entro 6 ore per l’90% delle richieste. Il servizio di intervento tecnico in locale deve comunque intervenire fisicamente entro 12 ore dalla richiesta		Il tempo di intervento è conteggiato a partire dal momento di assegnazione della richiesta al servizio di intervento tecnico in locale. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. Sono esclusi dal conteggio i casi di mancata pianificabilità dell’intervento, così come definiti per il servizio di intervento tecnico in locale, entro i primi 60 minuti. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.3	Tempo di intervento per richieste di priorità 3 su Roma	Mensile	• PN.GP.LC.INTL.3 • PN.GP.LC.INTL.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 3 per PdL site sul territorio del comune di Roma, il servizio di intervento tecnico in locale deve intervenire fisicamente sulla PdL entro 8 ore per l’90% delle richieste. Il servizio di intervento tecnico in locale deve comunque intervenire fisicamente entro 16 ore dalla richiesta		Il tempo di intervento è conteggiato a partire dal momento di assegnazione della richiesta al servizio di intervento tecnico in locale. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. Sono esclusi dal conteggio i casi di mancata pianificabilità dell’intervento, così come definiti per il servizio di intervento tecnico in locale, entro i primi 120 minuti. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.4	Tempo di intervento per richieste di priorità 1 fuori Roma	Mensile	• PN.GP.LC.INTL.1 • PN.GP.LC.INTL.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 3 per PdL site al di fuori del territorio del comune di Roma, il servizio di intervento tecnico in locale deve intervenire fisicamente sulla PdL entro 5 ore per l’85% delle richieste. Il servizio di intervento tecnico in locale deve comunque intervenire fisicamente entro 12 ore dalla richiesta		Il tempo di intervento è conteggiato a partire dal momento di assegnazione della richiesta al servizio di intervento tecnico in locale. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. Sono esclusi dal conteggio i casi di mancata pianificabilità dell’intervento, così come definiti per il servizio di intervento tecnico in locale, entro i primi 30 minuti. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.5	Tempo di intervento per richieste di priorità 2 fuori Roma	Mensile	• PN.GP.LC.INTL.2 • PN.GP.LC.INTL.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 3 per PdL site al di fuori del territorio del comune di Roma, il servizio di intervento tecnico in locale deve intervenire fisicamente sulla PdL entro 8 ore per l’90% delle richieste. Il servizio di intervento tecnico in locale deve comunque intervenire fisicamente entro 16 ore dalla richiesta		Il tempo di intervento è conteggiato a partire dal momento di assegnazione della richiesta al servizio di intervento tecnico in locale. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. Sono esclusi dal conteggio i casi di mancata pianificabilità dell’intervento, così come definiti per il servizio di intervento tecnico in locale, entro i primi 60 minuti. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.6	Tempo di intervento per richieste di priorità 3 fuori Roma	Mensile	• PN.GP.LC.INTL.3 • PN.GP.LC.INTL.4
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 3 per PdL site al di fuori del territorio del comune di Roma, il servizio di intervento tecnico in locale deve intervenire fisicamente sulla PdL entro 10 ore per l’90% delle richieste. Il servizio di intervento tecnico in locale deve comunque intervenire fisicamente entro 20 ore dalla richiesta		Il tempo di intervento è conteggiato a partire dal momento di assegnazione della richiesta al servizio di intervento tecnico in locale. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. Sono esclusi dal conteggio i casi di mancata pianificabilità dell’intervento, così come definiti per il servizio di intervento tecnico in locale, entro i primi 120 minuti. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.7	Tempo di risoluzione per richieste di priorità 1	Mensile	• PN.GP.LC.INTL.5 • PN.GP.LC.INTL.8
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 1 il servizio di intervento tecnico in locale deve fornire una risoluzione entro 4 ore dal momento dell’intervento fisico sulla PdL, per l’85% delle richieste. La risoluzione può consistere: • nell'evasione completa della richiesta, • oppure nell’assegnazione temporanea di un muletto (fino all’evasione completa). Il servizio deve comunque evadere completamente la richiesta entro 12 ore dalla ricezione, in assenza di muletto, o 48 ore, in caso di assegnazione di muletto (in tal caso estendibile fino a 30 giorni solari per interventi di manutenzione HW con riparazione/sostituzione di componenti)		Per richiesta evasa si intende una richiesta completamente soddisfatta, il cui risultato è verificato e il cui ticket viene chiuso. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. In caso di interventi di manutenzione HW il conteggio dei tempi è sospeso per attività/servizi in carico a fornitori terzi per contratto diretto con l’Università. Per la definizione di muletto si veda la descrizione del servizio di intervento tecnico in locale. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL • GP.LC.MNHW • GP.LC.ISWL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.8	Tempo di risoluzione per richieste di priorità 2	Mensile	• PN.GP.LC.INTL.6 • PN.GP.LC.INTL.8
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 2 il servizio di intervento tecnico in locale deve fornire una risoluzione entro 8 ore dal momento dell’intervento fisico sulla PdL, per il 90% delle richieste. La risoluzione può consistere: • nell'evasione completa della richiesta, • oppure nell’assegnazione temporanea di un muletto (fino all’evasione completa). Il servizio deve comunque evadere completamente la richiesta entro 24 ore dalla ricezione, in assenza di muletto, o 48 ore, in caso di assegnazione di muletto (in tal caso estendibile fino a 30 giorni solari per interventi di manutenzione HW con riparazione/sostituzione di componenti)		Per richiesta evasa si intende una richiesta completamente soddisfatta, il cui risultato è verificato e il cui ticket viene chiuso. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. In caso di interventi di manutenzione HW il conteggio dei tempi è sospeso per attività/servizi in carico a fornitori terzi per contratto diretto con l’Università. Per la definizione di muletto si veda la descrizione del servizio di intervento tecnico in locale. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL • GP.LC.MNHW • GP.LC.ISWL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.INTL.9	Tempo di risoluzione per richieste di priorità 3	Mensile	• PN.GP.LC.INTL.7 • PN.GP.LC.INTL.8
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per le richieste di priorità 3 il servizio di intervento tecnico in locale deve fornire una risoluzione entro 12 ore dal momento dell’intervento fisico sulla PdL, per il 90% delle richieste. La risoluzione può consistere: • nell'evasione completa della richiesta, • oppure nell’assegnazione temporanea di un muletto (fino all’evasione completa). Il servizio deve comunque evadere completamente la richiesta entro 36 ore dalla ricezione, in assenza di muletto, o 56 ore, in caso di assegnazione di muletto (in tal caso estendibile fino a 30 giorni solari per interventi di manutenzione HW con riparazione/sostituzione di componenti)		Per richiesta evasa si intende una richiesta completamente soddisfatta, il cui risultato è verificato e il cui ticket viene chiuso. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa. In caso di interventi di manutenzione HW il conteggio dei tempi è sospeso per attività/servizi in carico a fornitori terzi per contratto diretto con l’Università. Per la definizione di muletto si veda la descrizione del servizio di intervento tecnico in locale. Sono escluse dal conteggio le richieste di servizi IMAC-R	• GP.LC.INTL • GP.LC.MNHW • GP.LC.ISWL

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.IMAC.1	Tempo di esecuzione per IMAC-R singolo	Mensile	• PN.GP.LC.IMAC.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per ogni blocco singolo di operazioni IMAC-R richiesto, il servizio deve evadere completamente la richiesta entro 16 ore dalla convalida per il 90% delle richieste		Per la definizione di blocco singolo e di richiesta convalidata si veda la descrizione del servizio interessato. Per richiesta evasa si intende una richiesta completamente soddisfatta, il cui risultato è verificato e verbalizzato e il cui ticket viene chiuso. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.LC.IMAC

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.IMAC.2	Tempo di presa in carico per IMAC-R massivo limitato	Mensile	• PN.GP.LC.IMAC.2
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per ogni blocco massivo limitato di operazioni IMAC-R (ossia fino a 50 operazioni) richiesto, il servizio deve prendere in carico la richiesta convalidata entro 24 ore		Per la definizione di blocco massivo e di richiesta convalidata si veda la descrizione del servizio interessato. La richiesta si intende presa in carico nel momento in cui il Fornitore identifica e formalizza verso l’Ateneo il team / referente per l’intervento, con indicazione (almeno preliminare) dei tempi previsti per lo stesso. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.LC.IMAC

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.IMAC.3	Tempo di esecuzione per IMAC-R massivo limitato	Mensile	• PN.GP.LC.IMAC.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per ogni blocco massivo limitato – fino a 50 operazioni – di operazioni IMAC-R richiesto, il servizio deve evadere completamente la richiesta entro 15 giorni solari dalla presa in carico per il 100% delle richieste		Per la definizione di blocco massivo si veda la descrizione del servizio interessato. La richiesta si intende presa in carico nel momento in cui il Fornitore identifica e formalizza verso l’Ateneo il team / referente per l’intervento, con indicazione (almeno preliminare) dei tempi previsti per lo stesso. Per richiesta evasa si intende una richiesta completamente soddisfatta, il cui risultato è verificato e verbalizzato e il cui ticket viene chiuso	• GP.LC.IMAC

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.LC.IMAC.4	Tempo di presa in carico per IMAC-R massivo	Mensile	• PN.GP.LC.IMAC.2
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per ogni blocco massivo di operazioni IMAC-R (superiore a 50 operazioni) richiesto, il servizio deve prendere in carico la richiesta convalidata entro 48 ore		Per la definizione di blocco massivo e di richiesta convalidata si veda la descrizione del servizio interessato. La richiesta si intende presa in carico nel momento in cui il Fornitore identifica e formalizza verso l’Ateneo il team / referente per l’intervento, con indicazione (almeno preliminare) dei tempi previsti per lo stesso. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.LC.IMAC

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.BO.ACCN.1	Tempo di evasione per richieste di gestione account PdL	Trimestrale	• PN.GP.BO.ACCN.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Il servizio di gestione account e profilazioni PdL deve evadere completamente la richiesta entro 2 ore dalla convalida per il 90% delle richieste		Per la definizione di richiesta convalidata si veda la descrizione del servizio interessato. Per richiesta evasa si intende una richiesta completamente soddisfatta, il cui risultato è verificato e il cui ticket viene chiuso. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.BO.ACCN

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.BO.MNUP.1	Tempo di segnalazione per anomalie a UP di rete	Trimestrale	• PN.GP.BO.MNUP.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Il servizio di monitoraggio delle Unità Periferiche deve segnalare la necessità di intervento al servizio di Help desk entro 2 ore dal riscontro dell’anomalia, per il 90% degli eventi anomali riscontrati		Per la definizione di anomalia si veda la descrizione del servizio interessato. Il conteggio dei tempi è calcolato solo durante la finestra di servizio, mentre è sospeso al di fuori di essa	• GP.BO.MNUP

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.BO.CSAT.1	Percentuale di campionamento su servizi puntuali	Semestrale	• PN.GP.BO.CSAT.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Il servizio di valutazione e rendicontazione della customer satisfaction deve produrre un report sul livello di soddisfazione degli utenti su un campione di almeno il 40% delle richieste di servizio avanzate al servizio di Contact center nel periodo di riferimento		Il livello di soddisfazione deve essere relativo alla risposta fornita alla singola richiesta. La percentuale di campionamento misurata è relativa al numero di richieste per le quali l’utente richiedente è stato contattato/invitato ad esprimere la propria valutazione, indipendentemente dall’avventura risposta da parte dell’utente stesso	• GP.BO.CSAT

SLA	Descrizione breve	Periodo	Penali applicabili
SL.GP.BO.CSAT.2	Percentuale di campionamento su servizi complessivi	Annuale	• PN.GP.BO.CSAT.2
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Il servizio di valutazione e rendicontazione della customer satisfaction deve produrre un report sul livello di soddisfazione per l’intero complesso di servizi di Fleet Management nel periodo di riferimento su almeno il 60% degli utenti		Il livello di soddisfazione deve essere relativo all’esperienza complessiva verso i servizi di Fleet Management. La percentuale di campionamento misurata è relativa al numero di utente contattati/invitati ad esprimere la propria valutazione, indipendentemente dall’avventura risposta da parte degli utenti stessi	• GP.BO.CSAT

SLA	Descrizione breve	Periodo	Penali applicabili
SL.RT.00.EROG.1	Tempo di smaltimento per ritiro RAEE	Trimestrale	• PN.RT.00.EROG.1
Descrizione di dettaglio		Note sulle modalità di calcolo	Servizi interessati
Per ogni richiesta pervenuta il servizio di ritiro RAEE		Per la definizione di stock si vedano le	• RT.UC.PCDT • RT.UC.PCTC • RT.UC.NTBK • RT.PP.MNTR • RT.PP.STLS • RT.PP.STTR • RT.PP.STGI • RT.PP.SCAF • RT.PW.SMWL • RT.PW.STMT
deve completare lo smaltimento a norma di legge		condizioni generali del servizio
del materiale entro 20 giorni solari dalla data di		interessato
effettivo ritiro del materiale dalle sedi universitarie o
da data di consolidamento dello stock da smaltire se
concordata fra le parti, certificando la data di
effettivo smaltimento tramite l’opportuna
documentazione

6.4. Penali

Nel presente capitolo si riportano le penali contrattuali applicabili al Fornitore in caso di rilevata e documentata inadempienza della fornitura rispetto a criteri di qualità e livelli di servizio fissati e condivisi. Ogni criterio deve essere di natura numerica e misurabile sulla base di una analisi di eventi ben identificati e documentati.

A supporto di tale attività viene predisposto dal Fornitore, come più opportuno, il sistema di reportistica e SLA management illustrato nel paragrafo 4.1.1.9.

Per ogni penale viene fornita un descrizione in forma tabellare riportante le seguenti informazioni:

• il codice identificativo composito della penale,

• una descrizione breve della penale,

• il periodo di riferimento usato come base di calcolo della penale,

• una descrizione estesa dell’importo della penale previsto e delle modalità di calcolo,

• eventuali note sulle modalità di calcolo o sul dominio di applicazione.

• il codice dei criteri di qualità (uno o più) a cui è applicabile la penale, con indicazione del tipo di ciascun criterio: IQ o SLA.

Per tutte le condizioni contrattuali relative alle modalità di applicazioni delle penali, si rimanda all’art. 5 del Capitolato d’Oneri.

Si evidenzia che l’applicazione di penali, a fronte di mancato rispetto degli SLA, non sarà ammissibile durante la fase di startup dell’appalto, come indicato nel paragrafo 4.1.2.1.

Penale	Descrizione breve		Periodo
PN.IQ.02.PERS.1	Personale del Fornitore inadeguato		Semestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 2.000,00 (duemila/00) moltiplicato per il valore dell’eccedenza dell’IQ interessato rispetto al valore soglia di 2 unità	Si rimanda alla modalità di calcolo dell’IQ interessato. Per eccedenza si intende la differenza fra il valore dell’indicatore calcolato ed il valore soglia	IQ.02.PERS.1	IQ

Penale	Descrizione breve		Periodo
PN.IQ.02.PERS.2	Turnover eccessivo del personale gestionale		Annuale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 2.000,00 (duemila/00) moltiplicato per il valore dell’eccedenza dell’IQ interessato rispetto al valore soglia di 1 unità	Si rimanda alla modalità di calcolo dell’IQ interessato. Per eccedenza si intende la differenza fra il valore dell’indicatore calcolato ed il valore soglia	IQ.02.PERS.2	IQ

Penale	Descrizione breve		Periodo
PN.IQ.04.RILV.1	Numero eccessivo di rilievi sulla fornitura		Semestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 5.000,00 (cinquemila/00) moltiplicato per il valore dell’eccedenza dell’IQ interessato rispetto al valore soglia di 1 unità	Si rimanda alla modalità di calcolo dell’IQ interessato. Per eccedenza si intende la differenza fra il valore dell’indicatore calcolato ed il valore soglia	IQ.04.RILV.1	IQ

Penale	Descrizione breve		Periodo
PN.IQ.04.RILV.2	Numero eccessivo di rilievi sulla fornitura su più periodi		Semestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 5.000,00 (cinquemila/00) qualora in ciascuno degli ultimi 2 semestri il Fornitore sia già stato passivo della penale: • PN.IQ.04.RILV.1	La penale è applicabile semestralmente, avendo come periodo di analisi una finestra mobile data dal semestre di calcolo più il semestre precedente	IQ.04.RILV.1	IQ

Penale	Descrizione breve		Periodo
PN.GP.AM.INVE.1	Qualità dei dati dell’inventario		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 400,00 (quattrocento/00) qualora in fase di verifica da parte dell’Ateneo sulla correttezza delle informazioni registrate nell’inventario venga rilevato un numero di difformità superiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.AM.INVE.2	SLA

Penale	Descrizione breve		Periodo
PN.GP.RM.HDSK.1	Tempo di reazione per richieste di priorità 1 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 150,00 (centocinquanta/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.RM.HDSK.1	SLA

Penale	Descrizione breve		Periodo
PN.GP.RM.HDSK.2	Tempo di reazione per richieste di priorità 2 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.RM.HDSK.2	SLA

Penale	Descrizione breve		Periodo
PN.GP.RM.HDSK.3	Tempo di reazione per richieste di priorità 3 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.RM.HDSK.3	SLA

Penale	Descrizione breve		Periodo
PN.GP.RM.HDSK.4	Tempo di reazione non conforme su più periodi		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 2.000,00 (duemila/00) qualora in ciascuno degli ultimi 3 mesi il Fornitore sia già stato passivo di una delle seguenti penali: • PN.GP.RM.HDSK.1 • PN.GP.RM.HDSK.2 • PN.GP.RM.HDSK.3	La penale è applicabile mensilmente, avendo come periodo di analisi una finestra mobile data dal mese di calcolo più i 2 mesi precedenti	SL.GP.RM.HDSK.1 SLA SL.GP.RM.HDSK.2 SLA
		SL.GP.RM.HDSK.3	SLA

Penale	Descrizione breve		Periodo
PN.GP.RM.HDSK.5	Percentuale di richieste evase dall’Help desk in remoto non conforme		Trimestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	La percentuale di richieste evase è calcolata secondo le modalità descritte nello SLA interessato	SL.GP.RM.HDSK.4	SLA

Penale	Descrizione breve		Periodo
PN.GP.RM.SWDS.1	Tempo di presa in carico per richieste di aggiornamenti ordinari non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 200,00 (duecento/00) per ogni richiesta non soddisfatta nei tempi previsti dallo SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.RM.SWDS.1	SLA

Penale	Descrizione breve		Periodo
PN.GP.RM.SWDS.2	Tempo di presa in carico per richieste di interventi urgenti non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 300,00 (trecento/00) per ogni richiesta non soddisfatta nei tempi previsti dallo SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.RM.SWDS.2	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.1	Tempo di intervento per richieste di priorità 1 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 150,00 (centocinquanta/00) per ogni punto percentuale inferiore alla soglia di rispetto degli SLA interessati	Si rimanda alla modalità di calcolo degli SLA interessati	SL.GP.LC.INTL.1 SLA
		SL.GP.LC.INTL.4	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.2	Tempo di intervento per richieste di priorità 2 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto degli SLA interessati	Si rimanda alla modalità di calcolo degli SLA interessati	SL.GP.LC.INTL.2 SLA
		SL.GP.LC.INTL.5	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.3	Tempo di intervento per richieste di priorità 3 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto degli SLA interessati	Si rimanda alla modalità di calcolo degli SLA interessati	SL.GP.LC.INTL.3 SLA
		SL.GP.LC.INTL.6	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.4	Tempo di intervento non conforme su più periodi		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 2.000,00 (duemila/00) qualora	La penale è applicabile mensilmente,	SL.GP.LC.INTL.1 SL.GP.LC.INTL.2 SL.GP.LC.INTL.3 SL.GP.LC.INTL.4 SL.GP.LC.INTL.5 SL.GP.LC.INTL.6	SLA SLA SLA SLA SLA SLA
in ciascuno degli ultimi 3 mesi il Fornitore sia	avendo come periodo di analisi una
già stato passivo di una delle seguenti penali:	finestra mobile data dal mese di calcolo
• PN.GP.LC.INTL.1	più i 2 mesi precedenti
• PN.GP.LC.INTL.2
• PN.GP.LC.INTL.3

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.5	Tempo di risoluzione per richieste di priorità 1 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 150,00 (centocinquanta/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.LC.INTL.7	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.6	Tempo di risoluzione per richieste di priorità 2 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.LC.INTL.8	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.7	Tempo di risoluzione per richieste di priorità 3 non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.LC.INTL.9	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.INTL.8	Tempi di risoluzione non conforme su più periodi		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 2.000,00 (duemila/00) qualora in ciascuno degli ultimi 3 mesi il Fornitore sia già stato passivo di una delle seguenti penali: • PN.GP.LC.INTL.5 • PN.GP.LC.INTL.6 • PN.GP.LC.INTL.7	La penale è applicabile mensilmente, avendo come periodo di analisi una finestra mobile data dal mese di calcolo più i 2 mesi precedenti	SL.GP.LC.INTL.7 SLA SL.GP.LC.INTL.8 SLA
		SL.GP.LC.INTL.9	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.IMAC.1	Tempo di esecuzione per IMAC-R non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 100,00 (cento/00) per ogni punto percentuale inferiore alla soglia di rispetto per ciascuno SLA interessato	Si rimanda alla modalità di calcolo degli SLA interessati	SL.GP.LC.IMAC.1 SLA
		SL.GP.LC.IMAC.3	SLA

Penale	Descrizione breve		Periodo
PN.GP.LC.IMAC.2	Tempo di presa in carico per IMAC-R massivo non conforme		Mensile
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 150,00 (centocinquanta/00) per ogni richiesta convalidata di blocco massivo di operazioni IMAC-R presa in carico in tempi superiori a quelli previsti dagli SLA interessati	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.LC.IMAC.2 SLA
		SL.GP.LC.IMAC.4	SLA

Penale	Descrizione breve		Periodo
PN.GP.BO.ACCN.1	Tempo di evasione per richieste di gestione account PdL non conforme		Trimestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 50,00 (cinquanta/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.BO.ACCN.1	SLA

Penale	Descrizione breve		Periodo
PN.GP.BO.MNUP.1	Tempo di segnalazione per anomalie a UP di rete non conforme		Trimestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 50,00 (cinquanta/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.BO.MNUP.1	SLA

Penale	Descrizione breve		Periodo
PN.GP.BO.CSAT.1	Percentuale di campionamento su servizi puntuali non conforme		Semestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 200,00 (duecento/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.BO.CSAT.1	SLA

Penale	Descrizione breve		Periodo
PN.GP.BO.CSAT.2	Percentuale di campionamento su servizi complessivi non conforme		Annuale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 150,00 (centocinquanta/00) per ogni punto percentuale inferiore alla soglia di rispetto dello SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.GP.BO.CSAT.2	SLA

Penale	Descrizione breve		Periodo
PN.RT.00.EROG.1	Tempo di smaltimento per ritiro RAEE non conforme		Trimestrale
Descrizione di dettaglio	Note sulle modalità di calcolo	Criteri di qualità interessati
Penale di euro 500,00 (cinquecento/00) per ogni smaltimento non completato nei tempi previsti dallo SLA interessato	Si rimanda alla modalità di calcolo dello SLA interessato	SL.RT.00.EROG.1	SLA

7. Appendici

7.1. Censimento HW di Proprietà

7.1.1. Unità Centrali di proprietà

7.1.1.1. PC desktop

Marca	Modello	Numerosità
ACER	ACER POWER	1
DELL	VOSTRO460	32
DELL	VOSTRO470	30
HP	DC 7900	1
HP	DX 2300	1
HP	DX 2400	359
HP	PAVILLION M9643IT	1
HP	PAVILLION P6000	1
HP	PAVILLION T3000	1
HP	VN773ET	1
LENOVO	THINKCENTER	563
MAXDATA	MAXDATA	4

7.1.1.2. PC thin client

Marca	Modello	Numerosità
HP	T5630W	23

7.1.1.3. Notebook

Marca	Modello	Numerosità
DELL	VOSTRO 3550	40

7.1.2. Unità Periferiche Personali di proprietà

7.1.2.1. Monitor LCD

Marca	Modello	Numerosità
ACER	AL1916W	3
ASUS	VB172D	2
ASUS	VH222	7
ASUS	VW193	1
ASUS	VW193S	1

Document Metadata

Table of Contents

Servizi di Fleet Management

Document Metadata