LINEE GUIDA PER I SERVIZI DI ASSISTENZA E MANUTENZIONE PER I SOFTWARE
Allegato A1
LINEE GUIDA PER I SERVIZI DI ASSISTENZA E MANUTENZIONE PER I SOFTWARE
Vers. Febbraio 2020
INDICE
A) Il contesto
Nel presente documento vengono normate le modalità di erogazione dei servizi di assistenza e manutenzione per i software che devono essere erogati ad ESTAR e alle Aziende Sanitarie della Regione Toscana.
Il presente documento si applica a ciascuno dei seguenti casi:
• ESTAR e/o le Aziende Sanitarie della Regione Toscana utilizzano applicazioni software per le quali un fornitore è proprietario/licenziatario del software in seguito ad aggiudicazioni di gare o ad acquisizione di aziende precedentemente proprietarie/licenziatarie dei software; in tal caso si evidenzia che le Aziende Sanitarie hanno sempre acquistato la manutenzione dal fornitore proprietario/distributore delle licenze software e le attività richieste si inquadrano pertanto in una continuità di servizio
• ESTAR e/o le Aziende Sanitarie della Regione Toscana intendono acquisire nuove applicazioni software contestualmente all’acquisizione di servizi di assistenza e manutenzione
• ESTAR e/o le Aziende Sanitarie della Regione Toscana sono proprietarie di file sorgenti di un software e intendono acquisire i servizi di assistenza e manutenzione
B) Identificazione della fornitura
Il servizio di assistenza e manutenzione di un software prevede sempre le seguenti voci:
● Assistenza telefonica e on line agli utilizzatori e diffusione dei manuali utente. Ha ad oggetto un servizio di helpdesk telefonico e/o telematico (via email o web form) dedicati da erogarsi nei tempi indicati nel paragrafo 5.1 del presente documento, al fine di offrire supporto al per il corretto ed efficiente utilizzo del programma e delle estrazioni dati e la soluzione dei problemi operativi che possono emergere nel suo utilizzo. Rientrano in Assistenza tutte le richieste informative di carattere tecnico (funzionamento di script, estrazione flussi, estrazioni dati, viste, etc.) fatte esclusivamente da personale di ICT Estar, salvo che, quanto richiesto, non sia già presente nei manuali tecnici consegnati a ICT.
● Manutenzione ordinaria: comprende tutti gli interventi sul software volti a consentire il corretto funzionamento con altri software presenti sulla postazione e con i sistemi operativi aggiornati rispetto a quelli previsti dal contratto di licenze, anche sulla base di segnalazioni ricevute.
È realizzata ciclicamente su base temporale, ovvero a scadenze regolari. Le linee guida distinguono due tipi di manutenzione ordinaria:
a) programmata, ovvero basata sul tempo, che prevede interventi con cadenza regolare e verifiche determinate da elenchi prefissati;
b) di revisione, ovvero finalizzata ad assicurare aderenza delle procedure all’evoluzione dell’ambiente tecnologico, ad es: aggiornamento di versioni del software di base;
Rientra nella manutenzione ordinaria tutta l’attività di profilazione utenti e comunque di generica configurazione (parametri, dizionari) laddove il software non sia dotato di funzionalità applicativa o nel caso in cui i moduli da utilizzare risultino oggettivamente difficili da utilizzare in termini di rapporto tra il dato da immettere il numero di passaggi da fare nell’applicativo.
● Manutenzione correttiva: Attività di manutenzione realizzata in risposta a malfunzionamenti e/o non rispondenza a specifiche applicative o di flussi, sulla base dei test o delle segnalazioni fatte, da realizzarsi entro i tempi previsti dagli SLA contrattualizzati. Rientrano nella manutenzione correttiva tutti gli interventi necessari alla sistemazione dei dati sul database laddove la causa sia direttamente imputabile ad un malfunzionamento dell’applicativo o ad una integrazione con altri software.
● Manutenzione normativa: Attività di manutenzione realizzata per garantire il rispetto della
normativa nazionale e/o regionale, prevista da delibere emesse dall’organismo legislativo
competente ed effettuata su segnalazione/richiesta del Cliente. Rientrano nella manutenzione normativa anche gli aggiornamenti di tabelle di dizionari salvo che non siano già previsti tool per il caricamento massivo delle informazioni con i quali Estar può procedere in autonomia. Sono da quotare separatamente le attività relative a manutenzione normativa regionale laddove l’intervento richiesto dia luogo alla modifica delle strutture della base dati, o, nel caso di flussi, al cambio di tecnologia usata (es. da flussi a eventi) o quando la variazione richieda l’integrazione con software di altre ditte. La manutenzione normativa è soggetta a specifico collaudo.
● Erogazione dei seguenti servizi aggiuntivi:
- Assicurazione qualità e risoluzione dei problemi
- Fornitura documentazione esaustiva e aggiornata
- Reportistica periodica sugli SLA
- Reportistica periodica sulla gestione flussi ad eventi
C) Obiettivi del servizio
Gli obiettivi della Assistenza sono così definiti:
● facilitare le diverse categorie di Utenti nell’utilizzo operativo e funzionale dei mezzi
informativi e dei sistemi e servizi previsti;
● fornire in modo esaustivo tutte le informazioni e gli strumenti di supporto richiesti dagli Utenti per risolvere i problemi in modo tempestivo ed efficace;
● offrire agli Utenti tutte le informazioni che l’Amministrazione ritiene opportuno far conoscere in merito alla disponibilità di nuovi servizi o alla modifica di servizi esistenti;
● fornire manuali d'uso periodicamente aggiornati;
● garantire, alle strutture di controllo preposte, la verifica costante della qualità del servizio erogato e la conoscenza sia delle necessità e dello stato di soddisfazione degli Utenti sia dell’utilizzo dei servizi;
● identificare e segnalare all’Amministrazione la necessità di formazione sulla base delle informazioni monitorate dal Contact Center, al fine di adeguare o mantenere la competenza degli utenti e degli operatori sui servizi supportati.
Gli obiettivi della Manutenzione sono così definiti:
● mantenere operative le soluzioni software attraverso attività che assicurino in via continuativa la rimozione dei malfunzionamenti;
● risolvere, anche con eventuali workaround temporanei, le criticità del software o dei flussi estratti da correggersi in via definitiva con il rilascio di patch/release correttive;
● assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni;
● garantire l’evoluzione tecnico funzionale della soluzione software;
● assicurare l’aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell’affidabilità e dell’efficienza dei prodotti.
D) Utilizzatori
Gli utenti destinatari del servizio di assistenza si distinguono in:
● utenti identificati da ESTAR e/o dalle Aziende Sanitarie che utilizzano i software
● incaricati dall’Amministrazione delle Aziende Sanitarie per la Gestione Applicativi e Basi Dati, Gestione Sistemi e Gestione Reti, Postazioni di Lavoro
● personale del Dipartimento Tecnologie Informatiche di ESTAR
Si evidenzia che il principale utente per il Controllo dei Livelli di Servizio è il Dipartimento Tecnologie informatiche di ESTAR che deve monitorare, attraverso i Direttori dell’Esecuzione del Contratto, lo stato del servizio e informare l’Amministrazione di ESTAR e di ogni Azienda Sanitaria di eventuali criticità.
E) Oggetto del servizio
Il Fornitore di un servizio di assistenza e manutenzione dovrà svolgere le attività previste dal presente documento per tutto il software che rientra nel relativo contratto.
I moduli software oggetto del servizio possono essere installati presso le sale server delle Aziende Sanitarie, di ESTAR o presso Centri Servizi esterni (ad esempio TIX di Regione Toscana). In quest’ultimo caso le modalità di aggiornamento software per attività di manutenzione sono regolate in maniera specifica.
Per una più puntuale identificazione della fornitura si chiede che il Fornitore fornisca in sede di offerta tutti i dettagli necessari per identificare in dettaglio i singoli moduli in ambito alla fornitura in modo non vago o ambiguo. In particolare il Fornitore deve esplicitare/fornire tutti i dettagli per identificare in modo chiaro i moduli e le funzionalità a disposizione delle Aziende, evidenziando le eventuali differenze per le diverse installazioni.
1. Copertura oraria oggetto del servizio
Il servizio di assistenza può essere erogato con fasce orarie di copertura più o meno ampie; nella tabella seguente vengono indicate le fasce orarie di copertura più comuni adottate per gli applicativi gestiti da Estar:
Copertura oraria del servizio | ||
STANDARD | 5 gg – 10 h | Da lunedì a venerdì, dalle 8:00 alle 18:00, festivi esclusi |
ESTESO | 6 gg | Da lunedì a sabato, dalle 7:30 alle 19:30, festivi esclusi |
H24 | 365 gg H 24 | Tutti i giorni della settimana dalle 00:00 alle 23:59 festivi compresi |
Il Fornitore dovrà fare riferimento alla tipologia di fascia oraria richiesta nel capitolato per definire
nell’offerta per ogni Azienda/Software le fasce orarie di copertura ed i relativi costi.
F) Attività previste dal servizio
1. Modalità di gestione del servizio
Per tutti i servizi oggetto del capitolato, il Fornitore dovrà produrre documentazione su:
● organizzazione e responsabilità delle risorse (risorse hardware, software ed umane) previste dal fornitore per la gestione e l’erogazione del servizio, comprensivo dei limiti di competenza per i diversi livelli previsti nell’erogazione del servizio;
● attività, processi, metodologie affinché l’erogazione del servizio possa avvenire secondo i
livelli di qualità definiti (Operational Level Agreement - OLA);
● i controlli da svolgere internamente per assicurare la qualità della fornitura e relativi piani di verifica, incluse le specifiche responsabilità riguardo alla gestione delle non conformità, alla gestione delle configurazioni ed al controllo delle sub-forniture;
● le modalità di aggiornamento e condivisione della documentazione tecnica e funzionale;
● il piano di gestione delle comunicazioni (comprensivo delle procedure di escalation), in particolare nel caso in cui il rilascio assuma caratteristiche di criticità, quando siano previste significative modifiche o impatti sui processi o sull’organizzazione dell’utente o del gestore dei sistemi;
● le modalità per la condivisione/pubblicazione del Reporting sul Servizio ove si illustrano le performance del servizio nel periodo di riferimento
Si richiede che i manuali d’uso del software vengano mantenuti aggiornati in base alle evoluzioni del software e della base dati nel tempo.
● Fornitura dei seguenti manuali:
Manuale | Descrizione Documento |
Manuale Tecnico | ● Amministratore Sistema ● Struttura del Database – schema relazioni ● Estrazione Flussi (criteri e tabelle coinvolte) ● Integrazioni con altri sistemi |
Manuale Applicativo (Funzionale) | ● Amministratore ● Operatore |
2. Modello di erogazione del servizio di assistenza e manutenzione
Per poter svolgere il servizio di manutenzione richiesto il fornitore deve ricevere una segnalazione da un utente abilitato.
Le segnalazioni potranno essere effettuate da:
● Service desk aziendale dopo aver escluso o risolto problematiche legate alle postazioni di lavoro
● Personale ICT Estar addetto al presidio dei software
● Dall’utente aziendale (soprattutto in fasce orarie non coperte dai servizi interni)
● Dal Personale del fornitore del Middleware aziendale solo per i ticket oggetto di
integrazione con l’applicativo.
Si precisa che in caso di chiusura impropria di un ticket, senza aver riscontrato l’effettiva e definitiva risoluzione dell’anomalia e che comporta una successiva apertura di nuovo ticket riconducibile al precedente, gli SLA decorrono dalla data di apertura del primo ticket e le penali saranno calcolate sulla data di risoluzione definitiva del problema segnalato.
Il Fornitore deve indicare in sede di offerta il punto di accesso unificato per ESTAR e per ogni Azienda Sanitaria, rendendo disponibili numeri di telefono, relativi indirizzi email e piattaforme di trouble ticketing per le quali si richiede la visibilità per il monitoraggio dei ticket aperti.
È richiesta la disponibilità MINIMA di un numero telefonico dotato di tecnologia di gestione delle code e di un punto di accesso all'apertura di ticket via E-Mail.
Si precisa che, a prescindere dal modello organizzativo di assistenza ai software in essere presso le Aziende Sanitarie, il fornitore è tenuto a prendere in carico, gestire ed evadere qualsiasi richiesta di assistenza notificata attraverso i canali ufficiali.
3. Richieste utente che necessitano di manutenzione evolutiva
Ogni richiesta utente non compresa nel servizio di manutenzione ordinaria, correttiva o normativa
deve essere gestita secondo le modalità indicate nella “Procedura Software Change Request”.
4. Modalità di intervento
In relazione alla natura dell’intervento necessario questo potrà essere svolto dal Fornitore con:
● Intervento telefonico
● Intervento da remoto
● Intervento on site
Ogni intervento potrà comprendere anche più modalità.
L’impossibilità di intervento da remoto, qualsiasi sia la causa, non può costituire in alcun caso motivo di non intervento. In tali situazioni, il fornitore deve garantire l’intervento on-site in tempi compatibili con quanto previsto negli SLA.
Tutte le attività eseguite presso le sedi degli utenti dovranno essere documentate da un Rapporto di Intervento redatto a cura del tecnico del Fornitore che esegue l’intervento e dovrà essere controfirmato dal committente e/o da ESTAR. Una copia del Rapporto di Intervento firmato dovrà essere inviata al Direttore dell'Esecuzione del Contratto.
5. Gestione della sicurezza
L’applicazione dovrà mantenere il livello di sicurezza necessario atto a mantenere la riservatezza e integrità dei dati, dei flussi ed il controllo del livello di accesso alle funzioni del sistema. A tal fine il fornitore dovrà:
● evidenziare al committente eventuali carenze sulla protezione del software di base ai virus informatici che possono danneggiare gli applicativi e/o la base dati;
● gestire le emergenze attraverso l’uso efficace degli strumenti adottati per l’erogazione del
servizio;
● mettere tempestivamente in atto gli aggiornamenti sul software in esercizio necessari per
l’efficace funzionamento delle componenti fornite;
● monitorare gli eventi significativi per la sicurezza, evidenziati durante l’erogazione del
servizio;
● controllare ed analizzare, in modalità centralizzata, i dati (ad esempio i log dei sistemi) e gli allarmi di tipo automatico.
● progettare e monitorare un’architettura di backup per il recupero delle informazioni cliniche
di un paziente in assenza di accesso all’applicativo (offline)
6. Gestione della Privacy
La particolare delicatezza dei dati trattati per mezzo dei programmi impone un alto livello di attenzione per garantire il pieno rispetto degli obblighi imposti dalla normativa in vigore in tema di privacy.
In particolare le procedure informatiche dovranno risultare adeguate alla norme vigenti e alle direttive del garante in materia di sicurezza e privacy, alle linee guida in tema di fascicolo sanitario elettronico (FSE) e dossier sanitario (Del. n. 8 del 5 marzo 2009 e.s.m.) nonché, per l’attività in ambito, al documento sulle misure minime di sicurezza ict per le pubbliche amministrazioni (AGID). Qualora le procedure non fossero adeguate, si chiede l’evidenza delle parti/funzionalità ove le procedure non sono adeguate e un piano per la realizzazione di tutti gli interventi necessari per il loro adeguamento (si evidenzia che tali interventi rientrano nella manutenzione normativa). In attesa degli eventuali adeguamenti normativi, a fronte di eventuali sanzioni, Estar si rivarrà direttamente sulla ditta appaltatrice.
7. Gestione della Profilazione utenti
Gli applicativi in ambito ai contratti di assistenza e manutenzione devono garantire che il processo di profilazione ed autorizzazione degli utenti sia effettuato preservando i livelli di riservatezza legati ai profili configurati. Si richiede che gli applicativi informatici siano dotati di un’interfaccia utente amministrativa che consenta di configurare gli utenti associandogli gli opportuni profili di accesso alle funzionalità ed ai dati.
Tale interfaccia utente, per gli applicativi che ne sono sprovvisti o che non corrisponda ai requisiti descritti, dovrà essere realizzata e installata dal fornitore senza oneri aggiuntivi per Estar entro 3 mesi dalla sottoscrizione del contratto, includendo la formazione degli amministratori di sistema ed il manuale utente aggiornato per tale funzionalità. La realizzazione dell’interfaccia dovrà tener conto dei principi di semplicità e linearità garantendo il minor numero di passaggi possibili.
G) Livelli di Servizio
Il calcolo dei livelli di servizio deve avvenire in modo indipendente per ogni Ente.
I criteri di valutazione della Gravità sono identificati in base all’impatto che hanno sul funzionamento del sistema, sulle prestazioni, sulla sicurezza e sui vincoli di scadenza previsti dalle norme Nazionali o Regionali.
1. Livelli di servizio per l'assistenza, per la manutenzione correttiva e per la gestione di RDBMS/server (se inclusi)
Per definire i livelli di servizio si associa il livello di criticità ai relativi tempi di intervento richiesti come valori normali e valori limite.
I criteri di valutazione della complessità sono catalogati in base all’impatto che hanno per gli utenti, sul funzionamento del sistema, sulle prestazioni e sulla sicurezza; a tale proposito si individuano 3 livelli di criticità:
● GRAVITA' 1: una o più linee di prodotto presso una Azienda sono completamente bloccati oppure nessuna linea di prodotto è bloccata, ma le funzionalità critiche di uno o più moduli non sono disponibili o sono malfunzionanti. Si evidenzia che un guasto non bloccante può diventare bloccante in particolari momenti lavorativi (es. necessità di produrre report amministrativi il cui normale tempo di produzione non consente la presentazione entro la data di scadenza, impossibilità di fare ricoveri o dimissioni per un software ADT o per un Sistema Informativo Ospedaliero Integrato, impossibilità di inserire richieste in un Order Entry, etc...), rientrano in questa casistica anche i blocchi delle integrazioni che coinvolgono altri software collegati la cui funzionalità è strettamente connessa a processi clinici.
● GRAVITA' 2: Nessuna linea di prodotto è bloccata, ma importanti funzionalità di una o più linee di prodotto non sono disponibili o sono malfunzionanti. Si evidenzia che un guasto può diventare di Gravità 2 in particolari momenti lavorativi (es. impossibilità di invio un evento RFC o di un flusso entro le scadenze, mancato funzionamento di una integrazione non critica, etc...);
● GRAVITA' 3: le funzionalità non critiche e non importanti del sistema non sono disponibili o malfunzionanti, senza impatto sulla operatività degli utenti (es. maggiore inefficienza); in questa categoria sono comprese anche le normali chiamate di assistenza funzionale da parte degli operatori;
Livello di Criticità | Descrizione della Criticità | Tempi di Risoluzione Standard * | Tempi di Risoluzione Limite ** |
GRAVITA' 1 Alta criticità | Fermo operativo di aree critiche dell'Azienda o integrazioni critiche (legate a processi clinici) | Soluzione garantita entro 2 ore lavorative dalla segnalazione | Soluzione garantita entro 4 ore lavorative dalla segnalazione |
GRAVITA' 2 Media criticità | Fermo operativo di aree circoscritte dell’Azienda | Soluzione garantita entro 6 ore lavorative dalla segnalazione | Soluzione garantita entro 12 ore lavorative dalla segnalazione |
GRAVITA' 3 Bassa criticità | Assistenza all'utenza o malfunzionamento di funzionalità non critiche o non essenziali per l’Azienda | Soluzione garantita entro 24 ore lavorative dalla segnalazione | Soluzione garantita entro 96 ore lavorative dalla segnalazione |
* il tempo di risoluzione deve rispettare i Tempi indicati almeno nel 90% dei casi
** il tempo di risoluzione deve rispettare i Tempi indicati nel 100% dei casi
Si evidenzia che rientrano negli SLA anche le chiamate di assistenza e manutenzione successive all'installazione di una nuova release o di un aggiornamento di ambienti tecnologici, server, etc....
Per il calcolo dei livelli di servizio si considera il tempo che intercorre dalla data di segnalazione da parte dell’utente alla data di risoluzione della criticità all'interno del tempo di disponibilità del servizio contrattualizzato (solo per un servizio H24x365GG il calcolo del tempo di risoluzione non deve prevedere interruzioni).
Nel caso in cui il fornitore della manutenzione riscontri che la risoluzione della problematica sia completamente di competenza di fornitori terzi tali chiamate possono essere escluse dal Calcolo degli SLA, ma devono comunque essere riportate – in elenco a parte - nella rendicontazione trimestrale (Allegato 2 - Esempio Calcolo SLA) che deve sempre contenere TUTTE le chiamate aperte dal Cliente.
Si evidenzia che nel caso in cui il fornitore della manutenzione riscontri che la risoluzione della problematica sia completamente di competenza di terzi sono definiti dei livelli di servizio diversi che devono comunque essere rispettati. Si prevedono infatti i seguenti livelli di servizio per la sola presa in carico del problema (si intende per Tempo di presa in carico il tempo che intercorre tra la ricezione della segnalazione di un problema e il re-inoltro della segnalazione a terzi). Nel caso di integrazioni con terze parti, dove la ricerca del problema viene di norma fatta in modo congiunto tra le parti, la chiusura del ticket per escalation a terzi non esonera il fornitore dall’effettuare tutte le attività necessarie a supporto [informazioni, dati, test ecc..] raccordandosi direttamente con le software house interessate.
Livello di Criticità | Valori Normali (*) | Valori Limite (**) |
GRAVITA' 1 | 30 min | 1 ora |
GRAVITA' 2 | 2 ore | 4 ore |
GRAVITA' 3 | 8 ore | 12 ore |
* da rispettare almeno nel 90% dei casi
** da rispettare nel 100% dei casi
2. Misurazione dei livelli di servizio
Questa attività si rende necessaria per il controllo sulla conduzione del contratto e il monitoraggio
del servizio offerto all’utente.
A questo proposito:
● il personale di ESTAR e delle Aziende deve avere la possibilità monitorare i ticket, compresi gli avanzamenti di stato, presenti nella piattaforma di trouble ticketing del fornitore;
● il DEC per le diverse Aziende effettuerà la verifica del rispetto dei livelli di servizio e il calcolo delle eventuali penali;
● la verifica dei livelli di servizio avverrà trimestralmente a partire dalla reportistica inviata dal fornitore;
● Il Fornitore deve fornire il Rapporto sui Livelli di Servizio e il Rapporto sull’Attività erogata
trimestralmente, entro i primi 5gg lavorativi del mese successivo;
Il DEC analizzerà i dati forniti verificando la completezza e la correttezza dei dati forniti a suo insindacabile giudizio. Il DEC si riserva di effettuare verifiche a campione sulle chiamate effettuate e sui tempi di chiusura indicati nei report.
Il mancato rispetto dei livelli di servizio concordati potrà dare luogo all’addebito di penali come
esplicitato nel successivo capitolo.
H) Servizi aggiuntivi
1. Manutenzione Evolutiva
Gli interventi di manutenzione evolutiva per i software in esercizio riguardano prevalentemente:
● modifiche anche urgenti alle funzioni, realizzate con tempi e risorse contenuti (ad esempio la modifica di una transazione o di un tabulato per una diversa prospettazione dei dati); tali modifiche non comportano alcun impatto significativo sull’architettura generale delle applicazioni, sui processi o sull’organizzazione del lavoro degli utenti finali; possono comportare talvolta una variazione, di norma molto limitata, della consistenza dei prodotti;
● interventi volti ad arricchire il prodotto o comunque a modificare o integrare le funzionalità del prodotto. Tale manutenzione implica la scrittura di funzioni aggiuntive d’integrazione a sistemi applicativi esistenti o parti di funzioni (anche in sostituzione di altre già esistenti) di dimensione significativa e di cui è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze;
● attività mirate a migliorare l'asset tecnologico su cui si basano i sistemi oggetto della fornitura: aggiornamenti di release, migrazione di DB, upgrade di server, etc…;
2. Acquisto del servizio
Le Aziende Sanitarie non assumono alcun impegno per l’acquisto di attività di Manutenzione
Evolutiva o di altro servizio aggiuntivo.
L’indicazione dell’impegno per tipologia di figura professionale deve intendersi unicamente allo scopo di determinare una quantità di giorni uomo che sarà considerata dal committente disponibile e utilizzabile fino ad esaurimento. I giorni uomo disponibili si ridurranno con l’addebito a consuntivo, da parte del fornitore, dei servizi formalmente richiesti con un ordine specifico. Qualora sia necessario impiegare un numero di giorni uomo superiore rispetto a quanto previsto, dovranno essere definiti specifici accordi per la quota eccedente.
Gli interventi di Manutenzione Evolutiva sono regolati dalla Procedura “Software Change Request” che costituisce parte integrante del contratto.
La manutenzione evolutiva può essere fatturata dal Fornitore solo ad avvenuto collaudo positivo per le modifiche al software o a fronte di rendicontazione firmata delle attività svolte On Site.
3. Formazione e Addestramento
Il fornitore deve esplicitare nell’offerta tecnica la modalità di erogazione della formazione e:
● la tecnologia prevista e/o utilizzabile;
● le variabili di dimensionamento;
● i vincoli e i requisiti organizzativi;
● gli standard e le norme di riferimento.
La modalità di acquisto del servizio, di erogazione e di fatturazione sono analoghe a quanto illustrato per la Manutenzione evolutiva.
4. Impegno previsto
Per gli interventi presso sedi ESTAR o delle Aziende Sanitarie si ritiene che:
● la tariffa giornaliera sia comprensiva di spese e oneri di trasferta
● sia svolto un numero minimo di 8h lavorative presso la sede del Cliente e siano stati raggiunti gli obiettivi prefissati
I) Penali
Se l’Azienda o l’ESTAR riscontrano inosservanze delle obbligazioni contrattuali e/o inadempimenti non puntuali delle stesse, il Responsabile dell'Esecuzione contesta formalmente al fornitore le inadempienze riscontrate e assegna un termine per la presentazione di contro-deduzioni scritte.
Qualora le giustificazioni non pervengano o non siano ritenute idonee, saranno applicate penali dandone preventiva comunicazione al Fornitore.
1. Penali mancata copertura servizio
Le Aziende Sanitarie e/o il Dir. dell’Esecuzione procederanno a verifiche a campione sul rispetto dell’orario di copertura del servizio.
Nel caso in cui si verifichi per due volte nell’arco di un trimestre la mancanza di copertura oraria per il servizio, il Responsabile dell'Esecuzione ha la facoltà di decurtare dal canone di manutenzione l’importo come di seguito calcolato:
A = numero di ore intercorse dall’inizio del servizio giornaliero fino alla verifica di ESTAR (si considera l’orario maggiore, con arrotondamento all’ora successiva)
B = costo orario del canone di manutenzione
C = numero di giorni di manutenzione intercorsi dall’inizio del trimestre di fatturazione fino al
giorno del secondo rilevamento
Importo da decurtare = A x B x C x 2
2. Penali manutenzione ordinaria e correttiva
Nel caso di disservizi ovvero non osservanza dei livelli di servizio, ritardi negli interventi di manutenzione o nel ripristino delle funzionalità imputabili al Fornitore, il Responsabile dell'Esecuzione ha facoltà di applicare nei confronti del Fornitore le penali calcolate come di seguito illustrato:
Le penali previste per il mancato rispetto degli SLA (da applicarsi ad OGNI ticket che non rientra negli SLA) sono:
1. Gravità 1 – € 400,00 per avvenuto ripristino delle funzionalità entro la prima ora di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato; ulteriori € 800,00 per avvenuto ripristino delle funzionalità entro la seconda ora di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato; ulteriori € 1600,00 per avvenuto ripristino delle funzionalità entro la terza ora di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato; ulteriori € 3200,00 per ogni successiva ora (dalla quarta ora compresa in poi) di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato;
2. Gravità 2 – il ritardo rispetto al valore limite verrà considerato giornata intera e verrà applicata una penale pari ad € 200,00 per ogni giorno di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato;
3. Gravità 3 – il ritardo rispetto al valore limite verrà considerato giornata intera e verrà applicata una penale pari ad € 100,00 per ogni giorno di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato.
3. Penali manutenzione evolutiva standard
Le penali previste per i ritardi nella gestione della manutenzione evolutiva possono essere applicate fino ad un massimo di:
● €. 50,00 per ogni giorno successivo al 10° giorno lavorativo nella emissione di un preventivo da parte del Fornitore da calcolarsi da quando le specifiche tecnico-funzionali complete ed esaustive sono state formalmente inviate al fornitore;
● €. 100,00 per ogni giorno lavorativo di ritardo nella consegna di modifiche autorizzate, da calcolarsi dalla data in cui viene inviata al fornitore formale autorizzazione a procedere; si precisa che la data limite per la consegna non può ovviamente essere definita unilateralmente dal fornitore per non incorrere nell’applicazione delle penali e che essa deve essere concordata tra Cliente e Fornitore ; si ritiene a tal proposito congruo un tempo di consegna pari a N° 5 volte l'effort della modifica richiesta (ad es. per una modifica quotata in 4gg/uomo di sviluppo si ritiene congruo un tempo di realizzazione/consegna massimo pari a N° 20gg lavorativi oltre i quali il Cliente si riserva di applicare la penale), salvo diversi accordi tra le parti.
4. Penali manutenzione normativa standard
Le penali previste per i ritardi nella gestione della manutenzione normativa che prevede la quotazione della modifica (MEV) possono essere applicate fino ad un massimo di:
● €. 50,00 per ogni giorno successivo al 10° giorno lavorativo nella emissione di un preventivo da parte del Fornitore da calcolarsi da quando le specifiche tecnico-funzionali complete ed esaustive sono state formalmente inviate al fornitore;
● €. 100,00 per ogni giorno lavorativo di ritardo nella consegna di modifiche autorizzate, da calcolarsi dalla data in cui viene inviata al fornitore formale autorizzazione a procedere; si precisa che la data limite per la consegna non può ovviamente essere definita unilateralmente dal fornitore per non incorrere nell’applicazione delle penali e che essa deve essere concordata tra Cliente e Fornitore; si ritiene a tal proposito congruo un tempo di consegna pari a N° 5 volte l'effort della modifica richiesta (ad es. per una modifica quotata in 4gg/uomo di sviluppo si ritiene congruo un tempo di realizzazione/consegna massimo pari a N° 20gg lavorativi oltre i quali il Cliente si riserva di applicare la penale), salvo diversi accordi tra le parti.
Le penali previste per i ritardi nella gestione della manutenzione normativa che non prevede la quotazione della modifica (MEV) possono essere applicate fino ad un massimo di:
● €. 500,00 per ogni giorno lavorativo successivo alla data di attuazione prevista dalla normativa o (nel caso di diverso accordo tra le parti) dalla data formalmente concordata per l’avvio
5. Penali manutenzione evolutiva o normativa urgente
Il Responsabile dell’Esecuzione o il DEC hanno facoltà di formalizzare al Fornitore eventuali richieste di manutenzione evolutiva e/o normativa da soddisfare in regime di urgenza, garantendo che l’ammontare delle giornate destinate a questo fabbisogno non sia superiore al 20% del totale delle giornate contrattualizzate.
In tal caso, sul modulo ‘Software Change Request’, sarà riportata la dicitura ‘Richiesta URGENTE –
Riferimento paragrafo X.5 delle Linee Guida Manutenzione e Assistenza Software’.
In tal caso, le penali previste per i ritardi nella gestione della manutenzione evolutiva e/o normativa possono essere applicate fino ad un massimo di:
● €. 100,00 per ogni giorno successivo al 3° giorno lavorativo nella emissione di un preventivo da parte del Fornitore da calcolarsi da quando le specifiche tecnico-funzionali complete ed esaustive sono state formalmente inviate al fornitore;
● €. 200,00 per ogni giorno lavorativo di ritardo nella consegna di modifiche autorizzate, da calcolarsi dalla data in cui viene inviata al fornitore formale autorizzazione a procedere (intendendosi per essa anche il solo invio del modulo MEV autorizzato); si precisa che la data limite per la consegna non può ovviamente essere definita unilateralmente dal fornitore per non incorrere nell’applicazione delle penali e che essa deve essere concordata tra Cliente e Fornitore; si ritiene a tal proposito congruo un tempo di consegna pari a N° 2,5 volte l'effort della modifica richiesta (ad es. per una modifica quotata in 4gg/uomo di sviluppo si ritiene congruo un tempo di realizzazione/consegna massimo pari a N° 10gg lavorativi oltre i quali il Cliente si riserva di applicare la penale), salvo diversi accordi tra le parti.
6. Importi trattenuti a titolo di Penale
L’Azienda è autorizzata a trattenere l’importo di dette penali dalle fatture presentate dall’Impresa fornitrice o a richiedere diversa modalità di pagamento. L’Azienda ha facoltà di rifiutare la prestazione eseguita in ritardo.
Qualora il fornitore della manutenzione del software:
● non utilizzi un sistema di trouble ticketing, oppure il sistema di ticketing non sia adeguato alle richieste
● non vengano fornite le informazioni richieste nel presente capitolato per il controllo degli SLA
il Direttore dell'Esecuzione ha la facoltà di non autorizzare il pagamento delle fatture del fornitore fino alla completa messa in regola del sistema di ticketing e alla regolare produzione della reportistica richiesta.
Si evidenzia che ESTAR e/o le Aziende hanno facoltà di addebitare al fornitore eventuali costi indotti che le Aziende devono sostenere per il ripristino della funzionalità; es.:
● a causa dell’interruzione del servizio per consentire l’aggiornamento del software, l’Azienda addebiterà al fornitore il costo del lavoro mancato eventualmente aumentato dello straordinario che e’ risultato necessario;
Se per consentire l’aggiornamento del software il fornitore deve lavorare al di fuori delle ore lavorative per il rispetto degli SLA contrattuali, gli eventuali extracosto che il fornitore deve sostenere non sono a carico delle Aziende Clienti.
Nel caso in cui a danno delle Aziende Sanitarie e di ESTAR si determinano:
● sanzioni civili, perdite economiche, gravi ripercussioni sull’immagine
● interruzione del servizio con conseguenti danni economici e di immagine
da imputare alla mancata ottemperanza del servizio, totale o parziale, con le modalità e i Livelli di Servizio definiti nel presente documento, il Fornitore dovrà pagare il risarcimento completo del danno.
In caso di inadempienze gravi o nel caso in cui le penali superino il 10% complessivo dell’importo contrattuale da fatturare nel periodo di riferimento, l’Ente ha facoltà di risolvere il contratto senza obbligo di messa in mora.
J) Rischio Clinico
Il rischio è il risultato di una combinazione di probabilità e di danni, aventi valenza economica e di immagine. Il rischio in sanità riguarda un insieme di eventi assai diversificato; essi possono derivare, infatti, da fonti molto diverse, ma il manifestarsi di eventi avversi, ha, nella maggior parte dei casi, una rilevanza economica e, quindi, l’impegno nella prevenzione del rischio clinico rappresenta un investimento per il sistema sanitario.
Per tutto il periodo contrattuale qualora si verifichino degli eventi categorizzati con qualsiasi livello di rischio clinico, citiamo, senza pretesa di esaustività:
● Disallineamenti paziente / dati tra sistemi informatici
● Scambio di referti/pazienti su un software diagnostico o in una integrazione tra software
● Errori nella prescrizione/somministrazione di una terapia e/o errori sugli allarmi / alert
● Errori/ritardi nella trasmissione di una richiesta di esami
● Errori nella integrazione di molteplici tecnologie medicali (per es. Errori nell’integrazione tra
software diagnostici e sanitari sia in input che in output)
● Errate indicazione nelle politiche di backup e recovery dei dati sanitari
Il Responsabile dell'Esecuzione ha facoltà di applicare al fornitore una penalità nella misura che va dal 1% al 10% del valore del contratto di manutenzione e assistenza annuale, da valutarsi in base alla gravità dell'evento e al danno subito dall'Ente, ivi compreso il danno di immagine.
K) Appendice A
1. Premessa
Obiettivo della Appendice A è definire le linee guida entro le quali l’Area Infrastrutture, Processi e Flussi governa le attività di assistenza e manutenzione dei sistemi delle Aziende Sanitarie Toscane. Tali linee guida devono ritenersi vincolo e possibilità per tutti gli attori coinvolti nei processi di gestione delle attività di manutenzione dei sistemi informatici a supporto delle Aziende stesse. Per una corretta definizione di piani di manutenzione e degli SLA in essi contenuti, si individuano alcune linee guida generali che sono da ritenersi vincoli minimi per l'erogazione dei servizi di manutenzione.
2. Servizi del Fornitore per servizio di manutenzione
Lo SLA deve riportare i metodi utilizzati per la comunicazione fra il committente e l'esecutore della manutenzione.
Servizio | Descrizione Servizio | SLA del Servizio |
Figura Professionale | Personale del fornitore che esegue materialmente la manutenzione | Lista delle figure professionali coinvolte |
Stati Avanzamento | Riunione di verifica/pianificazione con la figura di riferimento di fornitore | Xxxxxx 1 volta al mese |
Ingaggio servizio manutenzione | Il fornitore deve predisporre a suo carico almeno un numero verde attivo 24x7x365 ed un indirizzo e-mail | Risposta telefonica garantita entro un minuto dalla chiamata Risposta mail garantita entro 10 minuti dalla comunicazione |
Accesso a servizi di reporting | Il fornitore deve predisporre a suo carico un cruscotto di monitoraggio in formato elettronico, che Estar possa rielaborare, sull'andamento del servizio di manutenzione | Almeno 1 volta al mese |
Tabella 1 - Servizi Fornitori
3. Modalità di intervento del Fornitore per servizio di manutenzione
Lo SLA deve riportare quali siano i metodi adottati dal fornitore per garantire gli interventi ed i tempi proposti.
Devono essere garantite almeno quattro modalità di intervento:
● Intervento da remoto in totale autonomia
● Intervento da remoto con supporto di altre risorse
● Intervento on-site in totale autonomia
● Intervento on-site con supporto di altre risorse
Lo SLA deve riportare i casi nei quali l'intervento da remoto può risultare limitato, ad esempio perché sono consentiti solamente accessi a porte/protocolli specifici in base alle politiche sulla sicurezza, oppure perché l'infrastruttura di rete che permette accesso remoto non è sotto controllo da parte di ESTAR e non è garantibile quindi la raggiungibilità.
L’impossibilità di intervento da remoto, qualsiasi sia la causa, non può costituire in alcun caso motivo di modifica dei tempi di intervento garantiti. In tali situazioni, il fornitore deve garantire l'immediato intervento on-site.
Il fornitore deve dettagliare i requisiti necessari per l’accesso alla rete aziendale ESTAR per
raggiungere i sistemi Estar.
4. Metodi oggettivi di misurazione delle performances
Per ognuno dei macro-oggetti identificati nello SLA, devono essere declinati i metodi di misurazione delle performances dell'oggetto stesso. Il fornitore deve presentare dei report con cadenze fissate nello SLA (minimo mensilmente), fra i quali quello sulle performances dei sistemi in manutenzione.
5. Risorse dedicate al supporto sistemistico
Il fornitore deve riportare quali siano le figure professionali che saranno coinvolte nel supporto sistemistico delle applicazioni ESTAR. Senza pretesa di esaustività le figure professionali possono essere: DBA, Sistemista di Rete, Sistemista Windows/Unix/Linux
6. Definizione degli elementi Hw / SW oggetto di manutenzione
Il fornitore nella proposta deve dettagliare le caratteristiche delle componenti hw e sw che sono necessarie per
l’erogazione del servizio del sistema. A titolo esemplificativo, senza pretesa di esaustività, si riportano i dettagli HW /
SW richiesti.
Componente HW | Specifiche Componenti HW | Dettaglio Richiesta |
Web Server | ● Configurazioni parametri di OS non standard ● Dettaglio Risorse aggiuntive rispetto a configurazione Standard | Lista parametri di configurazione con valore richiesto Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM aggiuntiva, etc) |
Application Server | ● Configurazioni parametri di OS non standard ● Dettaglio Risorse aggiuntive rispetto a configurazione Standard ● Apertura porte di rete | Lista parametri di configurazione con valore richiesto Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM aggiuntiva, etc) |
Integration Server | ● Configurazioni parametri di OS non standard ● Dettaglio Risorse aggiuntive rispetto a configurazione Standard ● Apertura porte di rete | Lista parametri di configurazione con valore richiesto Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM aggiuntiva, etc) |
Database Server | ● Configurazioni parametri di OS non standard ● Dettaglio Risorse aggiuntive rispetto a configurazione Standard ● Apertura porte di rete | Lista parametri di configurazione con valore richiesto Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM aggiuntiva, etc) |
Apparati controller | ● Politiche di Configurazione Accesso (i.e. WiFi) ● Politiche di Configurazione Accesso (i.e. Domini) | Documento Specifiche politiche di accesso |
Firewall | ● Regole firewall ● Regole di Natting | Lista delle regole su firewall Lista regole di Natting |
Client PDL | ● Dettaglio Risorse aggiuntive rispetto a configurazione Standard ● Caratteristiche di Lettori di carte ● Caratteristiche delle carte di firma ● Caratteristiche codici a barre, sw di firma | Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM aggiuntiva, etc) Caratteristiche Hw delle periferiche richieste |
Client Medicale | ● Caratteristiche apparato ● Caratteristiche del montaggio/ disinfezione apparato | Descrizione delle caratteristiche apparato |
Tabella 2- Specifiche Componenti HW
Componente SW | Caratteristiche del Componente | Dettaglio Richiesta |
Web Server | ● Configurazioni parametri del sw di base non standard ● Log del sw di base ● Log applicativi | Lista parametri di configurazione con valore richiesto |
Applica tion Server | ● Configurazioni parametri del sw di base non standard (Java, Tomcat, etc) ● Log del sw di base ● Log applicativi | Lista parametri di configurazione con valore richiesto |
Integra tion Server | ● Configurazioni parametri del sw di base non standard ● Log del sw di base ● Log applicativi | Lista parametri di configurazione con valore richiesto |
Databa se Server | ● Configurazioni parametri di DB non standard ● Storage richiesto per dati con proiezione a 1 / 3 anni ● Tuning DB (in fase di test) | Lista parametri di configurazione con valore richiesto |
Client PDL | ● Caratteristiche sw di firma ● Caratteristiche / Configurazione Java | Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM aggiuntiva, etc) Caratteristiche Hw delle periferiche richieste |
Tabella 3 - Specifiche Componenti SW (*)
(*) In ogni caso il fornitore deve fornire la garanzia di funzionalità con sistemi operativi client e Server presenti sul parco macchine aziendale, compresi i nuovi sistemi operativi rilasciati durante il periodo di validità del contratto.
7. Definizione delle interfacce di amministrazione applicativi
Gli applicativi in ambito al contratto di manutenzione devono includere le necessarie funzionalità, erogate mediante interfaccia client (o User Interface), a supporto degli amministratori di applicativo per l’esecuzione delle attività di amministrazione sul sistema (ad esempio Creazione e Profilazione utenti, definizioni profili, etc).
8. Definizione delle tipologie di manutenzione sulla componente architetturale del Database
La componente database riveste particolare criticità in quanto il corretto funzionamento garantisce tempi di risposta applicativi secondo gli SLA concordati e la conservazione dei dati. Il presente paragrafo include la classificazione delle operazioni di manutenzione sui database, nei due casi di gestione centralizzata e gestione demandata; in particolare, tutte le operazioni indicate si intendono incluse nel caso di gestione demandata; quelle indicate con (C) sono da intendersi come le sole applicabili in caso di gestione centralizzata del database (es. unico cluster Oracle che gestisce più applicazioni di più fornitori):
Tipologia di Manutenzione | Caratteristiche della manutenzione |
Ordinaria | ● Applicazione delle patch raccomandate da produttore su software di base ● Aggiornamento software di base del database ● Creazione e manutenzione delle procedure di backup / recovery dei dati ● Gestione degli ambienti di sviluppo e collaudo (incluso anche ambienti di test, duplicazioni, etc) ● ( C ) Seguito operativo a richieste utente di verifica dati in produzione, per sospetta anomalia di funzionalità ● ( C ) Estrazioni dati occasionali al fine di ottenere informazioni non ottenibili tramite il software applicativo ● Piena gestione delle utenze database (creazione/cancellazione oggetti, grant, etc) |
● Tuning proattivo del database per garantire le prestazioni ottimali al variare / evolversi delle funzionalità applicative ● ( C ) Modifica delle strutture dello schema utente del database nel caso di utilizzo di strutture diventate obsolete e non supportate ● ( C ) Monitoraggio proattivo delle necessità di storage ● ( C ) Monitoraggio e implementazione di procedure di archiviazione / storicizzazione dei dati su nuove funzionalità ● ( C ) Aggiornamento / manutenzione delle procedure di backup / recovery dei dati ● ( C ) Realizzazione di ulteriori funzionalità volte a soddisfare le esigenze dell’utente (inserimento di nuove funzionalità non presenti nell’attuale sistema e/o la modifica delle funzioni previste dall’attuale architettura) ● Garanzia di funzionalità con SO client e Server presenti sul parco macchine aziendale, compresi i nuovi sistemi operativi rilasciati durante il periodo di validità del contratto | |
Correttiva | ● ( C ) Svolgimento delle azioni necessarie a risolvere le anomalie applicative (ad esempio ripristino della congruenza dei dati eliminando eventuali inconsistenze causate dall’esecuzione delle funzioni dell’applicazione, realizzazione di procedure per correzione di anomalie che non richiedono interventi sul Software) ● ( C ) Analisi delle cause e tuning delle performance del database in caso di degrado delle prestazioni in fase di accesso ai dati ● ( C ) Creazione di nuove oggetti (ad es. indici) in caso di degrado delle prestazioni in fase di accesso ai dati ● ( C ) Modifica di oggetti (ad es. partizionamento tabelle, modifica viste, modifica tabelle) per miglioramento delle performance in fase di accesso ai dati ● ( C ) Modifica delle componenti applicative software (ad es. stored function, stored procedure, package) per miglioramento delle performance applicative ● ( C ) Adeguamento dello storage (ad es. allargamento tablespace) in caso di esaurimento degli spazi ● ( C ) Modifica delle strutture dello schema utente del database nel caso siano utilizzate strutture obsolete in fase di primo rilascio del sistema |
Evolutiva | ●Tutto quello che non compare nelle altre tipologie di manutenzione |
Normativa | ● ( C ) Sviluppi software finalizzati ad adattare la base dati esistente alle disposizioni di legge nazionali |