ALTIRIS MANUALE OPERATORI ICT

Transcript

1 ALTIRIS MANUALE OPERATORI ICT Altiris - Manuale Operatori ICT Versione 2.3 del 10/06/2011

2 SOMMARIO PRESENTAZIONE 4 NOZIONI DI BASE SU PROCESSI GESTITI 5 IL CATALOGO DEI SERVIZI 5 Cos è un Servizio ICT 5 A chi sono rivolti i Servizi ICT 5 Cosa sono i KPI (Key Performance Indicator) 5 Cosa sono gli SLA (Service Level Agreement) 5 COS È UN TICKET 6 I Ticket 6 I Sub Task 6 IL PROCESSO DI INCIDENT MANAGEMENT 6 Cos è un Incident 7 IL PROCESSO DI REQUEST FULFILMENT 7 Cos è una Service Request 8 IL PROCESSO DI CHANGE MANAGEMENT 8 Cos è un Change 8 IL PROCESSO DI EVENT MANAGEMENT 9 Quali sono le segnalazioni ad evento 9 IL PROCESSO DI ACCESS MANAGEMENT 9 Le richieste di accesso ai Servizi ICT 9 Le autorizzazioni e le abilitazioni 10 GLI ATTORI NEI PROCESSI GESTITI 10 Chi innesca i processi 10 I canali per innescare i processi 11 Il Single Point Of Contact (SPOC) 12 Il Service Desk di II Livello 12 I gruppi di specialisti del Service Desk di III Livello 13 Chi autorizza le richieste di accesso ai servizi ICT 13 IL ROUTING DEI TICKET 14 La classificazione dei Ticket 14 L attribuzione della Priorità 14 LE DINAMICHE DI ESCALATION 16 ALTIRIS MANUALE OPERATORI ICT 2

3 Differenza tra Escalation, Alert e Notifica 16 LA CONFERMA DELLA CHIUSURA DI UN TICKET 17 SCOPRI LE FUNZIONALITÀ DISPONIBILI 19 COME È ORGANIZZATO ALTIRIS 19 Accesso 19 Home Page 20 I report disponibili 20 La Dashboard 20 INIZIA A UTILIZZARE ALTIRIS 21 La tua Home Page 21 Funzionalità che permettono di aprire un Ticket 21 Funzionalità che permettono di controllare l avanzamento dei propri Ticket 28 Funzionalità che consentono di agire come Operatore ICT sul Ticket assegnato 28 Gli avvisi dal Service Desk 57 GESTIONE DEI CHANGE 58 Principi 58 Processo 60 USER MANAGEMENT 89 Gestione Utenze 90 Gestione Utenze HR 91 Gestione Utenze Esterni 93 ALLEGATI 95 Tabella delle Priorità 96 Mappa mentale Escalation 97 Mappa mentale Classificazione 98 Mappa mentale Request Type 101 Mappa mentale Stati del Ticket 102 Mappa mentale Codici di chiusura del Ticket 103 INDICE GENERALE 104 ALTIRIS MANUALE OPERATORI ICT 3

4 PRESENTAZIONE Nell ambito delle iniziative di integrazione di gruppo è previsto l avvio del nuovo servizio accentrato Service Desk ICBPI. Il Service Desk ICBPI è l ente con cui comunicare circa l andamento dei Servizi ICT al quale rivolgere segnalazioni di anomalie e richieste di attività e manutenzioni evolutive. Il servizio è rivolto a tutte le società del gruppo, riguardo tutti gli ambiti ICT organizzati e descritti nel Catalogo dei Servizi ICT. Il nuovo servizio accentrato nasce con l intento di uniformare e standardizzare i processi di gestione delle richieste ICT: fornendo un punto di contatto unico (SPOC Single Point of Contact) ai Clienti dei servizi erogati dall ICT; garantendo tracciabilità di tutte le richieste, dalla presa in carico alla risoluzione; razionalizzando i flussi di gestione delle richieste, inquadrandone le modalità operative in una cornice omogenea trasversale ai diversi ambiti gestiti. La gestione accentrata secondo i nuovi processi permette al Service Desk di eseguire una costante attività di monitoraggio e governo complessivo sulla corretta e tempestiva gestione delle segnalazioni, innescando procedure di notifica ed escalation al verificarsi di situazioni critiche. L avvio del nuovo servizio, costruito su linee guida derivate dalle best practice di settore, è un passo importante e necessario per creare condizioni di coerenza e misurabilità dalle quali muovere per tenere sotto controllo e migliorare i livelli di servizio erogati dall ICT a supporto delle esigenze di business del Gruppo. Il nuovo servizio prevede l introduzione di un nuovo strumento di gestione delle richieste e degli asset ICT che sostituisce progressivamente gli strumenti prima in uso per le stesse finalit{. Il nuovo strumento, Altiris di Symantec personalizzato per ICBPI, è accessibile a tutti gli utenti del Gruppo, ai Clienti e ai fornitori ICT coinvolti nell erogazione del servizio. Il presente documento, indirizzato agli Operatori ICT di Altiris, vuole essere di aiuto all introduzione del nuovo strumento e dei processi con esso indirizzati fornendo sia un inquadramento di approccio ai processi gestiti sia una guida alle funzionalità rese disponibili. 4 ALTIRIS MANUALE OPERATORI ICT

5 NOZIONI DI BASE SU PROCESSI GESTITI Il Catalogo dei Servizi Il Catalogo dei Servizi documenta i servizi forniti ai clienti e dettaglia le caratteristiche salienti di ogni servizio. Il Catalogo dei Servizi è la base per una comune comprensione dei servizi offerti. Tra i benefici dell adozione di un Catalogo dei Servizi vi sono i seguenti: Le incomprensioni tra fornitori di servizi e clienti sono minimizzate; I livelli di servizio possono essere una base per la determinazione del valore del servizio; Implementa un processo di continua revisione e miglioramento della qualità dei servizi. Cos è un Servizio ICT Un Servizio ICT può essere definito come un insieme di funzionalità fornite, per un periodo continuativo di tempo, attraverso l infrastruttura IT nel supportare una o più aree di business. Può essere costituito da software, hardware e mezzi di comunicazione, ma l utente lo percepisce come un unica entità. Per comodità di analisi e di più facile individuazione dei Servizi ICT, si è scelto di raggrupparli in famiglie di servizi sotto la classe Macroservizio. A chi sono rivolti i Servizi ICT I Servizi ICT del Gruppo ICBPI si rivolgono a tutti gli utenti interni e a quelle entità esterne (ad es. banche clienti) con cui il Gruppo ICBPI ha concordato una collaborazione di business stretta consentendo anche l utilizzo di alcuni Servizi ICT. I fruitori di Servizi ICT del Gruppo ICBPI usufruiscono automaticamente anche del servizio di Service Desk ICBPI. Cosa sono i KPI (Key Performance Indicator) Un indicatore chiave di prestazione (in inglese Key Performance Indicator, in sigla KPI) è un indice che monitora l andamento di un processo aziendale. Gli indicatori definiscono cosa deve essere misurato e possono essere utilizzati per individuare trend, produttività, etc.. Cosa sono gli SLA (Service Level Agreement) I Service Level Agreement (in italiano: Accordo sul livello del servizio, in sigla SLA) sono strumenti contrattuali attraverso i quali si definiscono le metriche di servizio che devono essere rispettate dal fornitore di servizi. Gli SLA sono diventati uno strumento comune per misurare efficacemente i servizi. In questo contesto, la definizione di uno SLA consiste in un contratto tangibile tra due parti che, se da un lato assicura la fornitura dei servizi a livelli pre-negoziati, dall altro comporta l adozione di penalità in caso di mancato raggiungimento di tali livelli. ALTIRIS MANUALE OPERATORI ICT 5

6 La definizione degli SLA è basata sulla determinazione da parte del cliente del livello di servizio ideale a garanzia del suo business. Il monitoraggio degli SLA consente di verificare sia l andamento dei livelli di servizio in termini di rispetto dei valori obiettivo contrattuali sia la presenza di anomalie tecniche e applicative che potrebbero causare disservizi nei confronti dell utente finale. Sotto questo profilo, si parla di monitoraggio in tempo reale degli SLA la cui gestione implica il ricorso a sistemi di alerting in grado di segnalare on-line il verificarsi di problemi durante l erogazione del servizio. Cos è un Ticket Un Ticket è una richiesta di supporto che ogni utente senza limitazioni di orario può generare semplicemente accedendo allo strumento di Service Desk ovvero interagendo con un operatore di Service Desk attraverso i canali telefonici o inviando un alla casella predisposta al servizio. Nella gestione organizzativa dei Ticket attraverso Altiris (scelta dalla Governance di Gruppo ICBPI aderendo alle best practice di mercato sul tema e alle dinamiche e funzionalità standard dello strumento), si è deciso di differenziare i Ticket dai Sub Task. Questa modalità permette di differenziare la segnalazione che innesca un processo (il Ticket) e che segue un suo percorso di risoluzione (ad es. richiesta di abilitazione ad una funzionalità), dalle ulteriori attività complementari che potranno dover essere eseguite (i Sub Task) per risolverlo sotto tutti gli aspetti (ad es. richiesta di autorizzazione da rivolgere all owner del Servizio ICT). I Ticket I Ticket si identificano con una numerazione che si compone di: Un identificativo di tipologia ticket: o IM- Incident Management e Request Fulfilment Management; o CM- Change Management; o PR- Problem Management Un progressivo numerico di 6 cifre. I Sub Task I Sub Task si identificano con una numerazione che si compone di: Identificativo del Ticket da cui si è originato il Sub Task (ad es. IM ); Un progressivo numerico separato dal numero Ticket con un. (ad es. IM ). Il Processo di Incident Management L obiettivo principale del processo di Incident Management è il ripristino del funzionamento normale del servizio nel più breve tempo possibile minimizzando l impatto negativo delle funzioni di business, assicurando il mantenimento dei migliori livelli possibili di qualità e disponibilità del servizio. ALTIRIS MANUALE OPERATORI ICT 6

7 Funzionamento normale del Servizio è inteso qui come funzionamento all interno dei limiti di SLA concordati. Cos è un Incident Un Incident è un interruzione non pianificata o il degrado della qualità di un Servizio ICT. Non si può iniziare a trattare un Incident finché questo non sia avvenuto. Dal punto di vista del business non è di solito accettabile attendere che un utente abbia dei disagi e contatti il Service Desk. Per quanto possibile, tutti i componenti chiave vanno monitorati in modo che i guasti reali o potenziali siano rilevati al più presto possibile e il processo di Incident Management sia avviato velocemente. Teoricamente, gli Incident andrebbero risolti prima di avere un impatto sugli utenti. Tutti gli Incident vanno tracciati completamente e marcati con data e ora; scopo del tracciamento è l assegnazione di un codice di classificazione idoneo all Incident in modo che sia registrato correttamente. Un altro aspetto importante del tracciamento di ogni Incident è l assegnazione di un codice appropriato e concordato di priorit{, giacché questo determina come l Incident sarà gestito sia dagli strumenti sia dal personale di supporto. La Priorità è assegnata incrociando i seguenti parametri: Urgenza determina quanto possa essere vincolante per il Business l attesa di avere l operativit{ del Servizio ICT ai valori di disponibilità previsti; è indicato dall utente all atto di apertura del Ticket; Impatto determina il grado di effetto che l evento segnalato sta dando in termini di popolazione utente interessata nella dinamica in oggetto al Ticket; è indicato dall utente all atto di apertura del Ticket; Severit{ determina il valore d importanza che il Servizio ICT ha per il corretto funzionamento delle attività di Business aziendali essendo parte dei processi cui è stato dedicato. È associata in fase di definizione del Servizio dall owner del Servizio stesso ed è inserita in modalità automatica dallo strumento di gestione dei Ticket (nel corso delle prime fasi del ciclo di vita del processo di Incident Management) all atto di selezione del Servizio impattato dalla richiesta. Il Processo di Request Fulfilment Il Request Fulfilment è il processo che si occupa delle Service Request degli utenti. I suoi obiettivi sono: Fornire un canale attraverso cui gli utenti possono richiedere e ricevere servizi standard per i quali esiste un processo predefinito di approvazione e qualificazione; Fornire informazioni agli utenti sui servizi disponibili e su come ottenerli; Originare e consegnare i componenti dei servizi standard richiesti (tipo le licenze e il software); Essere di aiuto per informazioni generali, reclami o commenti. ALTIRIS MANUALE OPERATORI ICT 7

8 Cos è una Service Request Il termine Service Request è utilizzato come descrizione generica per molti differenti tipi di domande che sono rivolte dagli utenti all area ICT. Molte sono solo piccole modifiche a basso rischio, frequenti e a basso costo quali, ad esempio: La richiesta di cambio password; La richiesta d installazione di un altra applicazione su una particolare workstation; La richiesta di spostare alcuni elementi del desktop; La semplice richiesta d informazioni. La loro dimensione, frequenza e natura a basso rischio suggerisce che esse debbano essere trattate da un processo separato piuttosto che congestionare e intasare i normali processi di Incident e Change Management. Il Processo di Change Management L esigenza di cambiamento nasce per diverse ragioni: Proattivamente, ad esempio nella ricerca di benefici di business quali la riduzione dei costi, il miglioramento dei servizi, l aumento dell efficacia e della semplicit{ del supporto offerto; Reattivamente, quale mezzo di risoluzione di errori e per adattarsi a nuove circostanze. I cambiamenti vanno gestiti per: Ottimizzare l esposizione ai rischi (a sostegno del profilo di business richiesto dal business); Minimizzare la gravità di qualsiasi possibile impatto e guasto; Avere successo al primo tentativo. Tale approccio è essenziale per mantenere il giusto equilibrio fra la necessità di cambiare e l impatto del cambiamento. Lo scopo del Change Management è di garantire che: Siano usati metodi e procedure standard per una gestione rapida ed efficiente di tutti i cambiamenti; Siano registrati tutti i cambiamenti ai componenti dei Servizi ICT; Sia ottimizzato il rischio globale di business. Si deve, quindi, assicurare che i cambiamenti siano registrati, valutati, autorizzati, messi in priorità, pianificati, testati, implementati, documentati e revisionati in modo corretto. Cos è un Change Per Change si intende l aggiunta, la modifica o la rimozione di un servizio o di componenti di un servizio (e relativa documentazione) che sia stata autorizzata, pianificata o supportata. ALTIRIS MANUALE OPERATORI ICT 8

9 Un Ticket relativo ad un Change (Richiesta di Cambiamento o, in inglese, Change Request) registra l intera storia del cambiamento, con tutte le informazioni relative di dettaglio, i parametri concordati quali la priorit{ e l autorizzazione e i dati d implementazione e revisione. Il Processo di Event Management Un Event è definito come un cambio di stato che ha rilevanza ai fini della gestione di un Servizio ICT o di un suo elemento. Un Event potrebbe indicare un malfunzionamento di una componente informatica e, quindi, fungere da innesco per la generazione di un Incident. Gli Event, comunque, possono anche segnalare un andamento normale delle attività quale l effettivo funzionamento nel continuo di un processo di business informatizzato come l Autorizzativo. Quali sono le segnalazioni ad evento Il processo di Event Management si basa ovviamente su sistemi di monitoraggio, ma differisce dal normale monitoraggio in quanto l'event Management genera e identifica eventi (cambi di stato), mentre i sistemi di monitoraggio normale controllano i componenti informatici anche in assenza di eventi. I sistemi di monitoraggio su cui si basa l'event Management sono normalmente di due tipi: Sistemi di monitoraggio attivi, che attivamente verificano il funzionamento dei servizi; Sistemi di monitoraggio passivi che rilevano e mettono in correlazione notifiche operative e comunicazioni generate dai servizi stessi. Dopo che l'event è stato identificato, esso può diventare un Incident che a sua volta potrà poi evolvere in un Problem o in un Change ovvero semplicemente registrato per futura analisi. In sintesi, l obiettivo principale del processo di Event Management è identificare gli eventi, capirne il senso e determinare l'azione più appropriata. Il Processo di Access Management L Access Management è il processo che autorizza alcuni utenti all uso di un Servizio e vieta accessi non autorizzati. Lo si definisce talvolta anche come Identity Management. L Access Management è in realt{ l esecuzione sia dell Availability sia dell Information Security Management, in quanto abilita l organizzazione a gestire la confidenzialit{, disponibilit{ e integrit{ dei dati e della priorit{ intellettuale dell organizzazione. L Access Management può essere attivato da una Service Request per mezzo del Service Desk. Le richieste di accesso ai Servizi ICT L accesso (o la restrizione) può essere richiesto usando uno o più canali, fra i quali: ALTIRIS MANUALE OPERATORI ICT 9

10 Una Change Request ad esempio, una richiesta standard generata dal sistema del Personale in occasione dell assunzione, promozione, trasferimento di area organizzativa o risoluzione della attività in azienda di qualcuno; Una Service Request sottoposta tramite il Request Fulfilment System ad esempio, una richiesta standard indicata dal responsabile organizzativo di una persona che muta il proprio ruolo operativo e necessita, pertanto, di un adeguamento del profilo di abilitazione a lui assegnata. Le regole per richiedere l accesso sono documentate come parte del Catalogo dei Servizi. Le autorizzazioni e le abilitazioni L Access Management deve verificare ogni richiesta di accesso a un Servizio ICT da due prospettive: L utente che chiede l accesso sia chi dice di essere; Egli abbia diritto ad accedere a quel servizio. L Access Management non decide chi può accedere ad un determinato Servizio ICT. L Access Management esegue le norme e i regolamenti definiti dagli obiettivi strategici e di progettazione del servizio e persegue la modalità di autorizzazione comunque deliberata dall owner del Servizio richiesto. L Access Management non deve limitarsi a rispondere a delle richieste ma deve anche assicurarsi che i diritti forniti siano usati correttamente. Inoltre, così come l Access Management fornisce i privilegi per utilizzare un servizio, allo stesso modo, è responsabile della revoca di tali privilegi. Gli attori nei processi gestiti Come per qualsiasi processo organizzativo, anche quelli per l erogazione dei Servizi ICT vedono la partecipazione di vari attori che a diverso titolo ne innescano l avvio, partecipano alla dinamica di flusso degli stessi e ne sono utilizzatori dei prodotti conseguenti. Chi innesca i processi Di seguito sono descritti i principali attori che possono attivare i processi descritti nei paragrafi precedenti: L utente L utente è il principale fruitore dei Servizi ICT e, in quanto tale, è anche l entit{ che può individuare la necessità di innescare un processo di segnalazione di diversa necessità sui Servizi rispetto a quanto fino a quel momento utilizzato sia in occasione di richieste di evoluzioni sia di richiesta di servizi complementari sia relativamente ad anomalie riscontrate nell utilizzo standard. Il monitoraggio preventivo ICT Una caratteristica dell evoluzione dei sistemi informativi degli ultimi anni è di poter eseguire dei monitoraggi preventivi dei Servizi ICT erogati. Così come descritto nel processo di Event Management, questi monitoraggi possono individuare degli Event che, se differenti dal normale fluire, automaticamente innescano il processo di Incident Management. ALTIRIS MANUALE OPERATORI ICT 10

11 Il continuous improvement ICT Una moderna area ICT è strutturata non solo per erogare giorno per giorno i Servizi ICT che ha reso disponibili ai propri utenti attendendo che siano questi ultimi a individuarne possibili evoluzioni, ma si è sicuramente resa capace di cogliere nel continuo le possibili aree di miglioramento sia per quanto concerne le proprie modalità operative sia per quanto relativo alle evoluzioni dei sistemi applicativi in sintonia con le mutate necessità delle aree di business aziendali. In questa dinamica, ad esempio, l ICT potrebbe innescare il processo di Change Management al fine di indirizzare le evoluzioni individuate per il miglioramento delle prestazioni dei propri servizi o per il miglioramento delle funzionalità rese disponibili agli utenti. Tali cambiamenti saranno comunque sempre oggetto di accordo con gli utenti owner delle componenti di Servizio in questione. I canali per innescare i processi Con l avvio del nuovo Service Desk, le modalit{ per innescare i processi descritti nei paragrafi precedenti sono state indirizzate sui principali canali che maggiormente possono essere utilizzati dagli utenti dei Servizi ICT. Di seguito sono descritte le regole di innesco dei processi utilizzando i canali riconosciuti attivi alla data di validità di questo documento. Web Self-ticketing Un utente che deve inoltrare una segnalazione al Service Desk può agevolmente creare in autonomia un Ticket attraverso lo strumento di Ticketing Altiris (per dettagli si veda il capitolo Come è organizzato Altiris). In base alla classificazione guidata dallo strumento che l utente dovr{ compilare in aggiunta alle informazioni specifiche descrittive relative alla segnalazione, Altiris instraderà il Ticket verso l area ICT preposta alla risoluzione della segnalazione. All atto dell apertura automatica del Ticket lo strumento invierà una all utente per confermare l avvenuta registrazione della segnalazione fornendo indicazione del numero progressivo del Ticket assegnato. ALTIRIS MANUALE OPERATORI ICT 11

12 Apertura Ticket via Un altro canale con cui poter inoltrare segnalazioni all ICT attraverso il Service Desk è quello dell invio di una alla casella L sarà raccolta dal Service Desk attraverso il suo punto di ingresso (SPOC Single Point of Contact) che opererà nello strumento Altiris per aprire un corrispondente Ticket allegandovi l stessa dell utente. A quest ultimo sar{ data comunicazione di avvenuta apertura Ticket esattamente con la stessa modalità descritta al punto precedente. Apertura Ticket mediante Fax Un altra possibilit{ alternativa alle precedenti con cui poter inoltrare segnalazioni all ICT attraverso il Service Desk è quella dell invio di un Fax al numero Esattamente come descritto per l , questa segnalazione sarà raccolta dal Service Desk attraverso il suo punto di ingresso (SPOC Single Point of Contact) che opererà nello strumento Altiris per aprire un corrispondente Ticket allegandovi copia del Fax. All utente sar{ data comunicazione di avvenuta apertura Ticket esattamente con le stesse modalità descritte ai punti precedenti. Apertura Ticket al telefono L ultimo canale reso disponibile agli utenti per poter inoltrare segnalazioni all ICT attraverso il Service Desk è quello di chiamare telefonicamente il numero In questo caso, sarà un operatore del SPOC Single Point of Contact che accoglier{ l utente e operer{ nello strumento Altiris per aprire un corrispondente Ticket. Al termine della registrazione della segnalazione, lo strumento fornir{ all utente via una comunicazione di avvenuta apertura Ticket esattamente con le stesse modalità sopra descritte. Il Single Point Of Contact (SPOC) Il Single Point Of Contact (SPOC) è l entit{ che l area ICT del Gruppo ICBPI ha messo a disposizione per svolgere le attività di Service Desk di I livello, cioè fornire il principale punto di contatto tra gli utenti dei Servizi ICT e l area ICT di Gruppo. Tra i principali compiti dello SPOC si ricordano qui: L accoglienza all utente che attraverso il canale telefonico desiderasse inoltrare una segnalazione all ICT di Gruppo; La classificazione del Ticket, a fronte di una prima analisi della segnalazione inoltrata dall utente, per permetterne una successiva risoluzione attraverso il corretto instradamento verso gli specialisti competenti; La risoluzione di Ticket attraverso un operativit{ ricompresa tra le competenze demandate allo SPOC l operatore che avr{ preso in carico il Ticket provvederà ad agire in ambito ICT fornendo nel più breve tempo possibile avviso all utente di avvenuta chiusura della segnalazione; La predisposizione di segnalazioni massive (ad es. attraverso la creazione di messaggi vocali udibili dall utente all atto della chiamata telefonica al numero del Service Desk), qualora siano preventivate attività straordinarie su Servizi ICT (ad es. fermi per manutenzioni straordinarie su servizi di posta elettronica) o anomalie agli stessi che compromettano l operativit{ per un numero significativo di utenti. Il Service Desk di II Livello Nella struttura organizzativa di Governance ICT, è stata composta un unit{ (Service Desk di II Livello) dedicata al governo dei processi di competenza del servizio. I principali compiti del Service Desk di II Livello sono così sintetizzabili: ALTIRIS MANUALE OPERATORI ICT 12

13 Incident Management: riassegnazione ticket in caso di ambiguità; Gestione Escalation: monitoraggio e intervento per solleciti su Ticket fuori SLA; Gestione Incident che coinvolgono processor: attualmente coinvolti nella gestione di tutti i ticket verso il processor per classificazione / solleciti / gestione di chiarimenti Gestione Knowledge Base: stimolare e supervisionare il popolamento della base dati di conoscenze per la risoluzione rapida di Incident ricorrenti; Gestione della comunicazione: o supervisione con linee di indirizzo e controlli a campione sulla modalità e qualità delle risposte agli utenti fornite nei Ticket; o diffusione di informazioni nel caso di fermi rilevati autonomamente (ad es. informazioni per fermi ATM) o fermi che coinvolgono molti utenti (ad es. broadcasting, ); Supervisione corretta presa in carico dei casi da analizzare da parte degli specialisti e delle evidenze prodotte; Monitoraggio SLA di processo e intervento in caso di degrado delle performance dei fornitori; Gestione del calendario degli interventi e dei fermi programmati; Reportistica Governance ICT: o Rilevamento dati economici, rappresentazione, analisi e quadratura fra prospetti; o Rilevamento dati di avanzamento delle attività progettuali e rappresentazioni sintetiche elaborate dai dati analitici. I gruppi di specialisti del Service Desk di III Livello L ICT del Gruppo ICBPI ha organizzato i propri specialisti in Gruppi di Service Desk di III livello che sono dedicati in maniera puntuale alle diverse competenze sui Servizi ICT per erogare il servizio nella maniera più consona ai Livelli di Servizio concordati. Di norma, gli specialisti sono ingaggiati nelle loro attività di supporto ai Servizi ICT attraverso l assegnazione delle attivit{ attraverso lo strumento di Ticketing Altiris. Il contatto tra i gruppi di Service Desk di III Livello e gli utenti sarà occasionale e soltanto unidirezionale (da gruppo di Service Desk di III Livello a utente e non viceversa) a garanzia del corretto impegno degli specialisti alle attività di loro competenza e di salvaguardia dei livelli di servizio attesi. Gli utenti, in caso di necessità di comunicazione verso qualche gruppo di Service Desk di III Livello o di uno dei suoi specialisti, dovranno necessariamente passare attraverso il canale SPOC comunicando il numero di Ticket di riferimento o scrivendo direttamente in Altiris una nuova nota in aggiunta al Ticket. Chi autorizza le richieste di accesso ai servizi ICT Tutti gli utenti, per poter accedere ai Servizi ICT informatizzati, devono essere abilitati al loro utilizzo attraverso l assegnazione di un profilo delle proprie credenziali (utenza e password aziendali) che deve essere accordato dai responsabili dei Servizi ICT di cui si è fatta domanda di abilitazione. Queste richieste sono indirizzate attraverso specifiche Service Request verso il processo di Access Management che predispone quanto necessario perché i responsabili dei Servizi ICT oggetto di richiesta forniscano il loro benestare o il loro diniego. ALTIRIS MANUALE OPERATORI ICT 13

14 Il routing dei Ticket Altiris è uno strumento di workflow che consente di supportare il ciclo di vita del Ticket in tutte le sue fasi di processo. In quest ottica, sono stati implementati i flussi operativi aderenti ai processi descritti nei paragrafi precedenti. Tra le fasi che sono state automatizzate in Altiris e che rendono gli strumenti di Ticketing dei preziosi assistenti all operativit{ interna degli operatori ICT si vuole qui sottolineare la dinamica realizzata per l assegnamento di un Ticket ad un particolare settore destinatario del successivo passo di avanzamento delle attività ad esso legate. La classificazione dei Ticket L assegnazione di un Ticket avviene sempre analizzando una tripletta di parametri impostati in fase di apertura del Ticket dall utente ed eventualmente modificabili, in caso di non corretta identificazione da parte dell utente, nelle prime fasi di analisi e classificazione da parte del Service Desk; questi valori sono necessari per la corretta successiva lavorazione del Ticket da parte degli specialisti di competenza il cui ingaggio sarà stato ottimizzato nel suo percorso proprio dalla corretta identificazione di questi parametri. La tripletta si compone di: Parametri ( Macroservizio e Servizio ) per individuare il Servizio ICT interessato dalla segnalazione; Alberatura di Classificazione che permette la scelta della catena di valori di classificazione che identificano la tipologia di componente informatico interessato dalla segnalazione; La Request Type che identifica il tipo di azione (ad es. Richiesta informazioni, Aggiunta o Installazione, Cancellazione-Rimozione, etc.) che si desidera sia applicata alla tipologia di componente del Servizio ICT interessato dalla segnalazione. La corretta identificazione di tutta la tripletta porter{ lo strumento Altiris all assegnamento guidato verso il gruppo di competenza che ha la capacità di risolvere il Ticket entro i tempi previsti dai livelli di servizio concordati. L attribuzione della Priorità Chiaramente, la tripletta di cui al paragrafo precedente si accompagner{ ad un altro insieme di valori che è identificabile come attribuzione della Priorit{ e che permette, in definitiva, di stabilire quale attività debba essere eseguita, con quale tempistica e in risposta a quale criticità per il Business aziendale, per risolvere la segnalazione inoltrata al Service Desk. In questo caso, è stata definita una logica di attribuzione delle Priorità che si basa su tre valori in input: l Urgenza, l Impatto, la Severità. La combinazione dei tre indicatori determina la Priorità così come illustrato nell allegato Tabella delle Priorità. È importante sottolineare sin da ora che per l Urgenza, l Impatto e la Priorità quindi, ad esclusione della Severità nel corso delle diverse fasi del ciclo di vita del Ticket si potrebbero determinare condizioni che farebbero scegliere di modificare il valore o i valori indicati per questi indicatori sia dall utente sia da qualsiasi operatore di Service Desk. ALTIRIS MANUALE OPERATORI ICT 14

15 In questi casi, è stato previsto che lo strumento Altiris obblighi l operatore che ha deciso di modificare tali valori a dover indicare le motivazioni che hanno portato a tale scelta e, quindi, mantenerne traccia in automatico attraverso la registrazione nell area di History del Ticket. Urgenza L Urgenza determina quanto possa essere vincolante per il Business l attesa di avere l operativit{ del Servizio ICT ai valori di disponibilità previsti. Parametro caratterizzato da: Essere dipendente dal momento temporale in cui avviene segnalato l evento con il Ticket; A discrezionalit{ dell utente segnalante di norma secondo un giudizio qualitativo; Essere valorizzabile su una scala a quattro valori: o 1 Attività relativa a Business critico o rischio significativo impatto finanziario per l azienda; o 2 Attività che vincola un lavoro urgente; o 3 Attività che vincola un lavoro di routine; o 4 Nessuna immediata urgenza. Impatto L Impatto determina il grado di effetto che l evento segnalato sta dando in termini di popolazione utente interessata nella dinamica in oggetto al Ticket. Parametro caratterizzato da: Essere dipendente dal momento temporale in cui avviene segnalato l evento con il Ticket; A discrezionalit{ dell utente segnalante di norma secondo un giudizio qualitativo; Essere valorizzabile su una scala a quattro valori: o 1 Intera Direzione o tutti i Clienti; o 2 Intero Servizio o gruppo di Clienti o VIP; o 3 Intero Ufficio o singolo Cliente; o 4 Singolo utente interno. Severità La Severità determina il valore d importanza che il Servizio ICT ha per il corretto funzionamento delle attività di Business aziendali essendo parte dei processi cui è stato dedicato. Parametro caratterizzato da: Essere pre-definito e assegnato al Servizio ICT all atto della sua costituzione in accordo, ove applicabile, tra l area ICT e il referente di Business cui è stata assegnata l ownership del servizio stesso; Essere stabile nel tempo in quanto attributo peculiare del Servizio ICT; Assegnato in automatico dal sistema se presente nel Catalogo dei Servizi - nel momento in cui sono stati scelti dall utente i parametri di Macroservizio e Servizio ; Se il Servizio ICT è già stato classificato nel corso delle attività di Business Continuity (fase di Business Impact Analysis BIA), il valore di Severità coincide con quello determinato in questo processo; ALTIRIS MANUALE OPERATORI ICT 15

16 Essere valorizzabile su una scala a tre valori: o 1 Alta; o 2 Media; o 3 Bassa. Priorità La Priorità determina la sequenza di lavorazione dei Ticket da parte del Service Desk nel rispetto dei valori assegnati agli indicatori Urgenza, Impatto e Severità. Parametro caratterizzato da: Essere valorizzabile su una scala a sei valori: o 1 Straordinaria; o 2 Critica; o 3 Alta; o 4 Normale; o 5 Bassa; o 6 Opzionale Essere determinato in maniera automatica ma solo per i valori compresi tra 2 Critica e 6 Opzionale dallo strumento Altiris nel momento in cui si completa la scelta degli altri tre indicatori Urgenza, Impatto e Severità. Il valore 1 Straordinaria può essere impostato soltanto manualmente dagli operatori di Service Desk poiché assegnabile a eventi di particolare e straordinaria gravità, tanto da dover creare un immediato livello di Escalation verso il Management aziendale e applicando disposizioni organizzative atte a risolvere l evento in tempi rapidissimi coerentemente con l eccezionalit{ dell evento stesso. Le dinamiche di Escalation Nella definizione delle caratteristiche di funzionamento dei processi supportati dallo strumento Altiris, è stata posta attenzione particolare alla gestione delle dinamiche di Escalation che devono essere applicate il più possibile in modalità automatica al verificarsi di determinate condizioni. Differenza tra Escalation, Alert e Notifica I concetti di Escalation, Alert e Notifica sono sovente scambiati creando confusione nella terminologia adottata e, conseguentemente, nelle attese d indirizzamento delle dinamiche sottostanti ai tre concetti stessi. Si è deciso, pertanto, di indicare qui una definizione di ognuna delle tre tipologie di segnalazioni automatizzate in Altiris. Escalation Identifica il caso in cui Altiris invia una segnalazione per richiedere ai destinatari del messaggio di compiere un azione di loro specifica competenza in quanto si è determinata una deviazione dal processo standard. Tipicamente, si inquadrano tra le Escalation le segnalazioni che lo strumento di Ticketing invia ai responsabili di una determinata area di competenza (ad es. il referente del gruppo di Service Desk di III Livello che ha in lavorazione il Ticket) perché l attivit{ si sta avvicinando al ALTIRIS MANUALE OPERATORI ICT 16

17 termine previsto dagli SLA per il completamento dell attivit{ senza che questa sia ancora stata risolta. Alert Letteralmente, Altiris si deve preoccupare di inviare a pre-determinate figure una segnalazione preventiva di un possibile loro coinvolgimento in una attività di processo. In questa categoria si possono individuare, ad esempio, quelle segnalazioni che sono rese visibili agli utenti tramite il Bulletin Board di Altiris o attraverso le comunicazioni udibili al momento della telefonata da parte di un utente verso il numero del Service Desk, qualora si fosse in condizioni di dover dare avvisi su possibili malfunzionamenti o disservizi preventivati che interessino una gran parte della popolazione utilizzatrice dei Servizi ICT. Notifica Con questa tipologia, Altiris deve inviare una segnalazione per informare una o più entità, secondo processo standard, che si è verificata una determinata condizione che prevede: O un loro coinvolgimento operativo (ad es. qualora sia assegnato a un operatore di Service Desk un Ticket su cui egli deve agire per prendere in carico l attivit{) O un loro coinvolgimento puramente informativo sulla dinamica in essere (ad es. l invio di una all utente che ha aperto un Ticket per informarlo dell avvenuta apertura effettiva di un Ticket e del numero progressivo assegnato allo stesso per poterne tracciare l evoluzione successiva). In Altiris sono stati previsti: I parametri guida per determinare su quali indicatori predisporre gli algoritmi di gestione di queste segnalazioni (ad es. Priorità del Ticket; SLA associati al Ticket; tipo di processo quali Incident Management, Change Management, etc.) Una serie di eventi possibili scatenanti le diverse tipologie di segnalazioni (ad es. il superamento di un valore soglia previsto per uno SLA); Le tipologie di entità destinatarie dei diversi tipi di segnalazioni (ad es. il Management ICT, l operatore che ha il Ticket in lavorazione, il gruppo di Service Desk di II Livello per azioni di intervento in ambito di Governance del processo); I metodi di comunicazione (ad es. , SMS, telefonata). In tutti i casi di segnalazioni sopra descritti, Altiris garantisce la registrazione delle stesse nella History del Ticket perché possa essere sempre analizzata sia in corso d opera sia in successive fasi di analisi a posteriori dell effettiva dinamica comportamentale durante le fasi di lavorazione. La conferma della chiusura di un Ticket Come in ogni sistema di Ticketing, anche in Altiris sono stati diversificati i momenti di chiusura di un Ticket da quelli di conferma della sua risoluzione. Infatti, se l operatore che ha lavorato il Ticket arriva a risolverlo portandolo nel corrispondente stato Risolto, soltanto l utente che ha aperto il Ticket avrà la responsabilità di portarlo in stato Chiuso confermandone così l effettiva risoluzione. ALTIRIS MANUALE OPERATORI ICT 17

18 È stata esclusa la possibilità di chiudere i Ticket d ufficio dopo che sia trascorso un periodo predeterminato di latenza in stato Risolto senza che l utente l abbia effettivamente confermato chiudendolo. Infatti, è stata ritenuta assolutamente importante e non sostituibile la responsabilit{ dell utente nel dichiarare l effettiva possibilit{ di ritenere chiuso il Ticket perché risolto. ALTIRIS MANUALE OPERATORI ICT 18

19 SCOPRI LE FUNZIONALITÀ DISPONIBILI Come è organizzato Altiris Accesso L accesso allo strumento di Ticketing è possibile: sia in ambiente interno aziendale tramite la Intranet in questo caso l accesso è permesso senza dover specificare le proprie credenziali (Account User e Password) perché sono dedotte automaticamente dallo strumento da quelle gi{ fornite dall utente al momento del collegamento alla rete aziendale con il proprio computer; sia esternamente all azienda attraverso il web acceduto da un qualsiasi computer diversamente dalla Intranet, l utente dovr{ fornire le proprie credenziali attraverso l apposita finestra di Login che sar{ presentata da Altiris. Nel caso in cui l utente abbia modificato la propria Password di Rete nell ultima ora rispetto al momento in cui voglia accedere ad Altiris, lo strumento potrebbe presentargli la finestra di Login e, in questo caso, dovrà essere inserita la vecchia Password. Appena l allineamento tra i sistemi responsabili della gestione delle credenziali sarà stato eseguito (tempo medio circa 1 ora), Altiris torner{ a garantire l accesso al sistema in automatico senza indicazione delle credenziali. Requisiti minimi di sistema Altiris è supportato per il suo funzionamento sulle seguenti configurazioni di browser: Microsoft Internet Explorer 7 o successive; Mozilla Firefox 2 o successive; Safari 3 o successive. Account L Account si compone di una User e di una Password che devono rispettare le seguenti disposizioni: USER: corrispondente al proprio indirizzo aziendale (ad es.: mario.rossi@icbpi.it); PASSWORD: corrispondente alla password di dominio/rete che si inserisce al momento della connessione alla rete aziendale. Link Per richiamare Altiris dalla propria Intranet, utilizzare il link >Entra! predisposto alla voce Service Desk; L attivazione di Altiris al di fuori della rete aziendale è eseguibile attraverso l indicazione dell indirizzo nel browser del computer da cui si accede. ALTIRIS MANUALE OPERATORI ICT 19

20 Home Page All avvio di Altiris l utente è indirizzato automaticamente alla Home Page dello strumento strutturata nelle componenti di seguito descritte nelle proprie caratteristiche generali. Nel successivo capitolo Inizia a utilizzare Altiris sono illustrate con maggior dettaglio le funzionalità consentite nella propria Home Page. Menu Altiris presenta nella parte alta della finestra alcuni menu sempre visibili che permettono l accesso alle diverse videate con cui operare. Report a video Una delle caratteristiche principali di Altiris, oltre a quella di base di fornire la possibilità di inserire dei Ticket di segnalazioni verso il Servizio ICT, è quella di evidenziare lo stato di avanzamento dei Ticket stessi lungo un percorso di lavoro ( workflow ) che è rappresentato attraverso diverse tipologie di report a video. Tali report sono rappresentati nelle loro versioni di default già personalizzate in fase di configurazione dello strumento da parte della Governance ICT. Nell uso quotidiano da parte del singolo utente è possibile apportare alcune modificazioni temporanee di tali report attraverso la parametrazione personalizzata di alcuni settaggi. Operando attraverso questi report, è possibile anche eseguire alcune operazioni su singoli Ticket ovvero eseguire azioni massive sui Ticket selezionati attraverso un report ovvero cercare specifici Ticket all interno di una lista rappresentata in un report. I report disponibili Sono in fase di definizione i report che saranno resi disponibili agli operatori ICT. Pertanto, in questa versione di manuale, questo paragrafo è da considerarsi temporaneamente vuoto. La Dashboard È in fase di definizione la struttura della Dashboard e, in particolare, dei report in essa ricompresi e che saranno resi disponibili agli operatori ICT. Pertanto, in questa versione di manuale, questo paragrafo è da considerarsi temporaneamente vuoto. ALTIRIS MANUALE OPERATORI ICT 20

21 Inizia a utilizzare Altiris La tua Home Page Area di Broadcasting e avvisi alle utenze In Altiris è stata prevista un area che consente di informare gli utenti dello strumento relativamente a dinamiche in essere nell ambito ICT (ad es. attivit{ straordinarie di manutenzione che potrebbero impattare sul normale servizio dei sistemi informativi, rilasci di nuove funzionalità che interessano una significativa parte della popolazione utilizzatrice dei sistemi informativi, etc.) e che è denominata Bulletin Board. Il report sulle My Requests Nella Home Page è sempre rappresentato un report standard che presenta tutti i Ticket che sono stati aperti dall operatore di Altiris di quella sessione. In sostanza, sono riportati tutti i Ticket in tutti i loro possibili stati di avanzamento che l utente in Altiris abbia aperto fino a quel momento. La ricerca puntuale di un Ticket Stando all interno del report di cui al punto precedente ( My Requests ), l utente di Altiris può effettuare la ricerca puntuale di un Ticket semplicemente scegliendo il bottone a forma di lente di ingrandimento riportato in alto a destra dell area del report stesso che permette tale ricerca. Funzionalità che permettono di aprire un Ticket Le scelte rapide e facilitate Per un più agevole utilizzo di Altiris, sono stati creati alcuni link che permettono un accesso facilitato a principali funzionalità di maggior utilizzo da un punto di vista utente. Selezionando la voce di menu Submit Request, si apre la pagina corrispondente al cui interno, nell area in basso a sinistra denominata Service Catalog, sono visibili le cartelle Incident Management, Service Request e Knowledge Base. Scegliendo una di queste cartelle, sulla parte destra della pagina si popola la corrispondente area di New Request al cui interno sono esposte le scelte rapide e facilitate attraverso specifici link attivi. Di seguito, sono descritte tali scelte rapide e facilitate: GESTIONE UTENZA: Questo tipo di richiesta, che si trova all interno della cartella Service Request, permette di richiedere delle attività sulle utenze, come ad esempio Creazione, Variazione, Sospensione/Sblocco e Cancellazione utenza ALTIRIS MANUALE OPERATORI ICT 21

22 Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattato dall esigenza segnalata; What is your Issue (campo obbligatorio): In questo campo va inserito il titolo del Ticket; Details that might help resolve this issue (campo obbligatorio): In questo campo va inserita la descrizione che permette di meglio identificare la richiesta espresso con il Ticket; Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; Master Services (campo obbligatorio): In questo campo va inserito il nome del Macroservizio cui fa riferimento il Ticket che si sta aprendo; ALTIRIS MANUALE OPERATORI ICT 22

23 Services (campo obbligatorio): In questo campo va inserito il nome del Servizio cui fa riferimento il Ticket che si sta aprendo; Supporting Documents or Images (campo non obbligatorio): In questo campo possono essere inseriti eventuali allegati INCIDENT / ANOMALIA Questa tipologia di richiesta, che si trova all interno della cartella Incident, permette di aprire una segnalazione di anomalia. Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattato dall esigenza segnalata; What is your Issue (campo obbligatorio): In questo campo va inserito il titolo del Ticket; Details that might help resolve this issue (campo obbligatorio): In questo campo va inserita la descrizione che permette di meglio identificare la richiesta espresso con il Ticket; Classification (campo non obbligatorio): Questo campo permette di definire l ambito sul quale si sta inserendo la richiesta Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; ALTIRIS MANUALE OPERATORI ICT 23

24 Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): ): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; Master Services (campo obbligatorio): In questo campo va inserito il nome del Macroservizio cui fa riferimento il Ticket che si sta aprendo; Services (campo obbligatorio): In questo campo va inserito il nome del Servizio cui fa riferimento il Ticket che si sta aprendo; Supporting Documents or Images (campo non obbligatorio): In questo campo possono essere inseriti eventuali allegati RESET PASSWORD Questa tipologia di richiesta, che si trova all interno della cartella Incident, permette di inserire un Ticket di tipo Incident per il Reset della password. ALTIRIS MANUALE OPERATORI ICT 24

25 Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattato dall esigenza segnalata; What is your Issue (campo obbligatorio): In questo campo va inserito il titolo del Ticket; Details that might help resolve this issue (campo obbligatorio): In questo campo va inserita la descrizione che permette di meglio identificare la richiesta espresso con il Ticket; Classification (campo non obbligatorio): Questo campo permette di definire l ambito sul quale si sta inserendo la richiesta Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): ): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; Master Services (campo obbligatorio): In questo campo va inserito il nome del Macroservizio cui fa riferimento il Ticket che si sta aprendo; Services (campo obbligatorio): In questo campo va inserito il nome del Servizio cui fa riferimento il Ticket che si sta aprendo; Supporting Documents or Images (campo non obbligatorio): In questo campo possono essere inseriti eventuali allegati SERVICE REQUEST BASIC Questa tipologia di richiesta, che si trova all interno della cartella Service Request, permette l inserimento di Service Request che non hanno un costo, come ad esempio Backup-Restore, Richiesta informazioni, Aggiunta o Installazione, Cancellazione-Rimozione, Denuncia furtosmarrimento. ALTIRIS MANUALE OPERATORI ICT 25

26 Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattato dall esigenza segnalata; What is your Issue (campo obbligatorio): In questo campo va inserito il titolo del Ticket; Details that might help resolve this issue (campo obbligatorio): In questo campo va inserita la descrizione che permette di meglio identificare la richiesta espresso con il Ticket; Classification (campo non obbligatorio): Questo campo permette di definire l ambito sul quale si sta inserendo la richiesta Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): ): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; ALTIRIS MANUALE OPERATORI ICT 26

27 Master Services (campo obbligatorio): In questo campo va inserito il nome del Macroservizio cui fa riferimento il Ticket che si sta aprendo; Services (campo obbligatorio): In questo campo va inserito il nome del Servizio cui fa riferimento il Ticket che si sta aprendo; Request type (campo obbligatorio): Qui è possibile definire il tipo di richiesta che si sta inserendo; Supporting Documents or Images (campo non obbligatorio): In questo campo possono essere inseriti eventuali allegati SERVICE REQUEST PLUS Questa tipologia di Ticket, che si trova all interno della cartella Service Request, permette l inserimento di Service Request che hanno un costo aggiuntivo, come ad esempio Richiesta supporto/incontri, Richiesta di analisi/stima, Verifica/Estrazione dati, Modifica. Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattato dall esigenza segnalata; What is your Issue (campo obbligatorio): In questo campo va inserito il titolo del Ticket; ALTIRIS MANUALE OPERATORI ICT 27

28 Details that might help resolve this issue (campo obbligatorio): In questo campo va inserita la descrizione che permette di meglio identificare la richiesta espresso con il Ticket; Classification (campo non obbligatorio): Questo campo permette di definire l ambito sul quale si sta inserendo la richiesta Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): ): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; Master Services (campo obbligatorio): In questo campo va inserito il nome del Macroservizio cui fa riferimento il Ticket che si sta aprendo; Services (campo obbligatorio): In questo campo va inserito il nome del Servizio cui fa riferimento il Ticket che si sta aprendo; Request type (campo obbligatorio): Qui è possibile definire il tipo di richiesta che si sta inserendo; Supporting Documents or Images (campo non obbligatorio): In questo campo possono essere inseriti eventuali allegati. Funzionalità che permettono di controllare l avanzamento dei propri Ticket Cercare un Ticket conoscendo il suo numero Entrando nella propria Home Page di Altiris, se non già visibile tra i Ticket presentati a video nel report My Requests, all interno di quest area in alto a destra premere il pulsante con l icona della lente di ingrandimento e inserire nel campo che si presenterà il numero del Ticket di cui si vuole verificare il suo stato di avanzamento. Visualizzare uno dei Ticket analizzati di recente Dopo aver selezionato il menu My Task List, nella videata che si aprir{ Altiris presenta in alto a sinistra un report denominato Recent Items. All interno sono visibili tutti i Ticket che sono stati oggetto di recente analisi da parte dell operatore. Questo report è personalizzabile attraverso il suo menu interno Show Options. Funzionalità che consentono di agire come Operatore ICT sul Ticket assegnato La pagina My Task List Per gestire i ticket assegnati all operatore o ai gruppi di cui lo stesso fa parte, si può procedere in due modi differenti: ALTIRIS MANUALE OPERATORI ICT 28

29 Premendo sul link all interno della mail che viene inviata all operatore o a tutti i membri appartenenti al gruppo a cui il ticket è assegnato; Utilizzando il menu My Task List. Mentre il link all interno della mail consente l accesso diretto al Ticket, la pagina My Task List permette di eseguire diverse operazioni: Vedere i Ticket visualizzati di recente o sui cui si sono svolte delle operazioni; Eseguire la ricerca di Ticket tramite Task ID; Eseguire la ricerca di Ticket tramite ID; Visualizzare i Ticket in carico direttamente all operatore o a gruppi di cui lo stesso fa parte suddivisi in base al processo che li ha generati. Una volta individuato il Ticket di cui si vuole prendere visione, è sufficiente effettuare un click con il mouse sul numero dello stesso per visualizzarlo. Pagina di gestione del Ticket Nella parte in alto si possono vedere tutte le informazioni relative al Ticket: o ID Che indica il numero del Ticket; o Stato; o Priorità; o Impatto; o Urgenza; o Severità; o Start Date Data e ora di apertura; o Needed By Date Eventuale data per la quale è richiesta la risoluzione del Ticket da parte dell utente; o Escalation Count Numero di volte che il Ticket ha subito una riassegnazione; o Time Spent Tempo Speso sul Ticket. Si tratta del tempo in cui si è tenuto aperto il Ticket; o External ID Campo dove è visualizzato il riferimento al numero di Ticket aperto verse terze parti; o Sub Task Number Dove è visualizzato il numero del Sub Task; o Source Indica il processo che ha generato il Ticket. ALTIRIS MANUALE OPERATORI ICT 29

30 Primary Contact: In questa parte è indicato il contatto primario del Ticket, cioè la persona con il problema o colui che l ha segnalato; Description: Qui è riportata la descrizione del Ticket inserita in fase di apertura dello stesso; Classification Information: Qui sono riportate le informazioni relative alla classificazione; History: Dove sono riportate tutte le attività eseguite sul Ticket. Nella parte destra invece sono presenti: My Action: Dove sono contenute tutte le operazioni che è possibile eseguire sul Ticket; Documents: Dove sono riportati gli eventuali allegati o dove è possibile allegare nuovi file; All Contacts: Qui è riportato sia il contatto primario sia, nel caso di Ticket aperti per terze persone, il nominativo di chi ha aperto il Ticket; Permission: Qui sono riportate le persone che hanno dei permessi sul Ticket e il tipo di permessi che hanno; Chat: Che permette di attivare una chat con il contatto primario; Process Time: Qui sono riportati i tempi di gestione del Ticket; o Total Process Time: Il tempo in cui il Ticket è stato editato; o User Process Time: Il tempo in cui il Ticket è stato editato dall utente corrente; o Current User Process Time: Il tempo in cui il Ticket è aperto al momento. Operazioni per la gestione del ticket I menu di gestione dei Ticket sono suddivisi in: Resolve Incident: Per risolvere il Ticket; Reference Tool: Che contiene una serie di link che danno accesso ad alcuni motori di ricerca; Smart Tasks: Che contiene tutti i link per la gestione dei Ticket; ALTIRIS MANUALE OPERATORI ICT 30

31 Change and Problem Management Tools: Che contiene i link per la gestione di Change e Problem. Tutte le operazioni eseguite per la gestione dei Ticket sono registrate all interno dell History, che permette di avere una visione di quanto fatto. SMART TASKS Presa in Carico Questo menu permette di prendere in carico il Ticket che si sta guardando. L operazione di presa in carico del Ticket è la prima da eseguire quando si decide di lavorare su un nuovo Ticket. Premendo questo link, il Ticket che risulta assegnato ad uno dei gruppi di cui si fa parte, è assegnato all oepratore corrente. Tale operazione oltre ad evitare che altre persone lavorino sulla stessa problematica, consente l accesso ad una serie di menu aggiuntivi per la gestione del Ticket. Si può decidere di prendere in carico un Ticket per lavorarci in un secondo momento, quando si avrà del tempo da dedicare alla risoluzione dello stesso. ALTIRIS MANUALE OPERATORI ICT 31

32 In Lavorazione Questo menu serve per cambiare lo stato del Ticket da Preso in Carico a In Lavorazione. Quando si inizia a lavorare su un Ticket è necessario mettere lo stesso In Lavorazione per permettere a tutti di sapere che il Ticket non solo è stato preso in carico, ma che ci si sta lavorando. Attach Process Questo link permette di collegare due Ticket tra di loro. Due Ticket possono essere legati tra di loro perché fanno riferimento ad uno stesso problema o perché concettualmente collegabili tra loro. Create SubTask Questo link permette di creare dei Sub Task per richiedere attività necessarie per la risoluzione dei Ticket a persone di altri gruppi o a colleghi del proprio gruppo. Per aprire un Sub Task si può procedere come segue: ALTIRIS MANUALE OPERATORI ICT 32

33 a) Premere sul link Create SubTask Una volta aperta la pagina di creazione dei Sub Task, oltre a vedere alcune informazioni relative al Ticket nel riquadro in alto a destra, è possibile eseguire alcune selezioni: o Leave Incident Open After Subtask Completion: Per decidere se la chiusura del Sub Task deve lasciare aperto il Ticket principale o se lo stesso deve essere chiuso; o Select a Template: Per selezionare un template per la creazione di Sub Task; o Use Template: Per aprire il Sub Task utilizzando il template; o Add SubTask: Per aprire un Sub Task senza l utilizzo di template predefiniti b) Premere su Use Template o su Add Subtask ; A questo punto si apre la pagina di creazione del Sub Task: ALTIRIS MANUALE OPERATORI ICT 33

34 o Assignments (campo obbligatorio): Premendo il pulsante Choose Assignee, si può scegliere a chi riassegnare il Sub Task; o Subtask Title (campo obbligatorio): Dove inserire il titolo del Sub Task; o Description (campo obbligatorio): Dove inserire la descrizione del Sub Task che si vuole creare; o Warn Date (campo obbligatorio): Data entro cui il sistema avviserà l assegnatario che si sta avvicinando la data entro cui ci si attende che sia risolto il Sub Task; o Late Date (campo obbligatorio): dove inserire la data entro cui si attende che sia eseguito il Sub Task; o Priority (campo obbligatorio): Priorità del Sub Task o Riferimenti al Catalogo dei Servizi: Master Service (campo obbligatorio): Nome del Macroservizio, come da Catalogo dei Servizi; Service (campo obbligatorio): Nome del Servizio, come da Catalogo dei Servizi; System (campo non obbligatorio): Nome del Sistema, come da Catalogo dei Servizi; SubSystem (campo non obbligatorio): Nome del Sottosistema, come da Catalogo dei Servizi; Asset (campo non obbligatorio): Nome del Asset, come da Catalogo dei Servizi ALTIRIS MANUALE OPERATORI ICT 34

35 c) Selezionare a chi riassegnare il Sub Task utilizzando il tasto Choose Assignee ; d) Compilare tutti i campi obbligatori e quelli facoltativi se necessario; e) Premendo Add Another è possibile aggiungere un ulteriore Sub Task; f) Premendo Add Task si può salvare il Sub Task creato; g) Premere il tasto Complete. La persona a cui è assegnato il Sub Task riceverà una mail che lo avvisa di tale attività. Accedendo al Ticket questa persona vedrà il Sub Task a lei assegnato e potrà procedere con i passi per la risoluzione così come di seguito descritto: ALTIRIS MANUALE OPERATORI ICT 35

36 a) Premere su Resolve Incident o Resolution or Response (campo obbligatorio): In questo campo bisogna inserire la spiegazione della soluzione adottata per la risoluzione del Sub Task; ALTIRIS MANUALE OPERATORI ICT 36

37 o Specify Time Worked (campo non obbligatorio): Selezionando questa opzione, Altiris renderà visibile un campo dove sarà possibile inserire il tempo dedicato alla risoluzione del Sub Task. Il formato di questa informazione è Giorni/Ore/Minuti; o Riferimenti al Catalogo dei Servizi: Master Service (campo obbligatorio): Nome del Macroservizio, come da Catalogo dei Servizi; Service (campo obbligatorio): Nome del Servizio, come da Catalogo dei Servizi; System (campo non obbligatorio): Nome del Sistema, come da Catalogo dei Servizi; SubSystem (campo non obbligatorio): Nome del Sottosistema, come da Catalogo dei Servizi; Asset (campo non obbligatorio): Nome del Asset, come da Catalogo dei Servizi b) Compilare i campi obbligatori e quelli facoltativi compilabili; c) Premere sul pulsante Resolve Inoltro Terze Parti Questo link serve per mettere il Ticket in stato di attesa perché si è richiesto l intervento di una terza parte che non ha accesso ad Altiris. ALTIRIS MANUALE OPERATORI ICT 37

38 a) Premere sul Link Inoltro Terze Parti Viene aperta la pagina per l inoltro a terze parti b) Compilare i campi che compongono la pagina: o Justification(campo obbligatorio): Inserire la motivazione per la quale si sta attivando un fornitore per la risoluzione del Ticket; o Fornitore (campo obbligatorio): Dove selezionare il nominativo del fornitore a cui si sta richiedendo supporto; o External ID (campo non obbligatorio): Dove si può inserire il riferimento dell eventuale Ticket aperto dal fornitore; o Postpone Date (campo obbligatorio): In cui selezionare l ora in cui il Ticket deve essere ripresentato per verificarne il completamento; o Postpone Time (campo obbligatorio): Dove inserire l ora in cui ripresentare il Ticket c) Premere il pulsante Schedule ; Nel Ticket è popolato il campo External ID Il Ticket passa nello stato In attesa intervento terza parte ed è rimossa dall elenco dei Ticket presenti nella My Task List. In ogni momento è comunque possibile rimuovere il Ticket dallo stato di In attesa intervento terza parte ricercando lo stesso e premendo sul link Remove from Hold Reassign Incident Questo link permette di ri-assegnare il Ticket ad un altro gruppo o a persone del proprio gruppo. ALTIRIS MANUALE OPERATORI ICT 38

39 a) Premere sul link Reassign Incident Come prima cosa è visualizzata una schermata che permette di riclassificare il Ticket (per questa operazione fare riferimento al menu Reclassify ) b) Premere il pulsante Next A questo punto è visualizzata la pagina per la rassegnazione del Ticket che prevede i seguenti campi: o Justification(campo obbligatorio): Dove inserire la motivazione per il quale si sta riassegnando il Ticket; o Search For(campo non obbligatorio): Permette la ricerca del nominativo a cui riassegnare il Ticket; o User/Groups: in cui sono elencate le persone a cui si può riassegnare un Ticket premendo sul link Reassign ; o Auto Assignment: Questo bottone permette di riassegnare il Ticket utilizzando delle regole di routing predefinite. Nel caso in cui non fosse applicabile alcuna regola, Altiris presenta un messaggio e si è rimandati alla pagina di rassegnazione; o Advanced Assignment: Permette di eseguire la ri-assegnazione in modo avanzato Auto Assignment: Se si preme sul pulsante Auto Assignment, è mostrata una schermata riepilogativa di quanto inserito ALTIRIS MANUALE OPERATORI ICT 39

40 a) Premere su Confirm ; b) Alla videata successiva che comunica che è stata effettuata la conferma, premere il pulsante Close In caso non vi siano regole di Auto Routing applicabili, lo strumento mostra il seguente messaggio: ALTIRIS MANUALE OPERATORI ICT 40

41 In questo caso, è necessario eseguire la ri-assegnazione manualmente premendo sul pulsante Avanti. Riassegnazione Manuale Per la ri-assegnazione manuale dei Ticket, invece di premere sul tasto Auto Assignement : a) Selezionare il gruppo a cui si vuole riassegnare il Ticket; b) Premere sul link Reassign. c) Premere Confirm per confermare la ri-assegnazione o Edit per modificarla; d) Alla videata successiva che comunica che è stata effettuata la conferma, premere il pulsante Close. Advanced Assignment E anche possibile eseguire una rassegnazione di tipo Advanced. Per eseguire una ri-assegnazione avanzata, invece di premere su Auto Assignment o di eseguire una ri-assegnazione manuale, procedere come segue: a) Compilare la motivazione della ri-assegnazione; b) Premere Advanced Assignment ; c) Selezionare il gruppo a cui riassegnare il Ticket tra quelli già presenti o tramite la ricerca, aggiungendoli premendo sul pulsante Add, inserendoli nell area Assignment List ALTIRIS MANUALE OPERATORI ICT 41

42 d) Premere il pulsante Reassign per procedere con la ri-assegnazione o Back per cambiare il tipo di ri-assegnazione da utilizzare e) Premere Confirm per confermare la ri-assegnazione o Edit per modificarla. ALTIRIS MANUALE OPERATORI ICT 42

43 Reclassify Questo link permette di riclassificare il Ticket modificando una serie di informazioni utili per la gestione del Ticket. In questa versione i campi della sezione Extended Classification non sono utilizzati per la gestione del Ticket. o Classification: Permette di definire il tipo di problema segnalato; o Request type: Tipo di richiesta (Break-Fix; Richiesta Informazioni; etc.); o Urgency: Questo campo riporta l Urgenza segnalata dall utente al momento dell apertura del Ticket; o Impact: Questo campo riporta l Impatto segnalato dall utente al momento dell apertura del Ticket; o Severity: Questo campo riporta la Severity legata al servizio selezionato; o Priority: Questo campo indica la Priorità del Ticket. o Riferimenti al catalogo servizi: Master Service (campo obbligatorio): Nome del Macroservizio, come da Catalogo dei Servizi; Service (campo obbligatorio): Nome del Servizio, come da Catalogo dei Servizi; System (campo non obbligatorio): Nome del Sistema, come da Catalogo dei Servizi; SubSystem (campo non obbligatorio): Nome del Sottosistema, come da Catalogo dei Servizi; Asset (campo non obbligatorio): Nome del Asset, come da Catalogo dei Servizi o Tutti i campi possono essere modificati singolarmente; o Se viene modificato il Servizio selezionato, il campo Severity è modificato a sua volta con quella del nuovo Servizio; o Il campo Priority è calcolato automaticamente da Altiris ALTIRIS MANUALE OPERATORI ICT 43

44 a) Premere il pulsante Reclassify b) Modificare i campi che si vogliono variare; c) Se si è scelta come priorit{ Straordinaria, è mostrato un messaggio di avviso: a. Premendo Back si torna alla schermata di riclassificazione e tutti i campi sono impostati nuovamente al valore iniziale; b. Premendo conferma viene inviata una mail ad una lista di distribuzione pre-impostata b. Siccome è stato modificato un campo della classificazione, ne è richiesta la motivazione. Richiesta Autorizzazione Questo link permette di richiedere un autorizzazione per eseguire delle attività sul Ticket. a) Premere il tasto Richiesta Autorizzazione Una volta aperta la pagina di creazione dei Sub Task, oltre a vedere alcune informazioni relative al Ticket nel riquadro in alto a destra, è possibile eseguire alcune selezioni: ALTIRIS MANUALE OPERATORI ICT 44

45 o Leave Incident Open After Subtask Completion: Per decidere se la chiusura del Sub Task deve lasciare aperto il Ticket principale o se lo stesso deve essere chiuso; o Select a Template: Per selezionare un template per la creazione di Sub Task; o Use Template: Per aprire il Sub Task utilizzando il template; o Add SubTask: Per aprire un Sub Task senza l utilizzo di template predefiniti b) Premere su Use Template o su Add Subtask A questo punto si apre la pagina di creazione del SubTask o Assignments (campo obbligatorio): Premendo Choose Assignee si può scegliere a chi riassegnare il Sub Task; o Subtask Title (campo obbligatorio): Dove inserire il titolo del Sub Task; o Description (campo obbligatorio): Dove inserire la descrizione del Sub Task che si vuole creare; o Warn Date (campo obbligatorio): Data entro cui il sistema avviserà l assegnatario che si sta avvicinando la data entro cui ci si attende che sia risolto il Sub Task; o Late Date (campo obbligatorio): Data entro cui ci si attende che sia risolto il Sub Task; o Priority (campo obbligatorio): Priorità del Sub Task; c) Selezionare a chi riassegnare il Sub Task utilizzando il tasto Choose Assignee ; d) Compilare tutti i campi; ALTIRIS MANUALE OPERATORI ICT 45

46 e) Premendo Add Another è possibile aggiungere un ulteriore Sub Task; f) Premendo Aggiungi Richiesta si salva la richiesta di autorizzazione; g) Premere il tasto Complete La persona cui è stato assegnato il Ticket riceverà una mail con un link che consente l accesso alla seguente pagina esterna ad Altiris (di tipo Web) ALTIRIS MANUALE OPERATORI ICT 46

47 h) Premendo su Approva. Il Sub Task è chiuso e l esito positivo è salvato nell History; i) Premendo su Rifiuta è richiesta la motivazione del rifiuto ALTIRIS MANUALE OPERATORI ICT 47

48 j) Premere Save. Il Sub Task è chiuso e l esito e la motivazione sono salvati nell History; k) A questo punto il Ticket torna attivo e si può proseguire con la gestione dello stesso. Schedule for Later Questo link permette di posticipare la gestione del Ticket ad un secondo momento. a) Premere il link Schedule for Later Altiris presenta la pagina per posticipare il Ticket che prevede i seguenti campi: o Justification(campo obbligatorio): Per motivare il perché si sta posticipando il Ticket; o Tipologia (campo obbligatorio): Per indicare se si tratta di un Sospeso o se motivato dalla necessità di ricevere delle informazioni dal Primary User ( In attesa approfondimenti utente ); o Postpone Date (campo obbligatorio): In cui selezionare la data in cui il Ticket deve essere ripresentato per verificarne il completamento; o Postpone Time (campo obbligatorio): Dove inserire l ora in cui ripresentare il Ticket b) Premere Schedule ALTIRIS MANUALE OPERATORI ICT 48

49 A questo punto il Ticket passa nello stato Sospeso ed è rimosso dall elenco dei Ticket presenti nella My Task List. In ogni momento, è comunque possibile rimuovere il Ticket dallo stato di Sospeso ricercando lo stesso e premendo sul link Remove from Hold Resolve Incident Questo link permette la risoluzione del Ticket: a) Premere su Resolve Incident Nella parte alta della schermata di risoluzione è possibile eseguire la riclassificazione del Ticket prima di risolverlo (fare riferimento alla parte di riclassificazione) ALTIRIS MANUALE OPERATORI ICT 49

50 Nella parte bassa, invece, è possibile inserire due tipi di spiegazione alla risoluzione del Ticket e il codice di chiusura. o Close Code(campo obbligatorio): Codice per indicare la tipologia di soluzione identificata; o Response (campo obbligatorio): Dove inserire la soluzione che sarà mostrata alla persona che ha inserito la richiesta; o Technical Resolution (campo obbligatorio): Dove inserire la spiegazione tecnica Selezionando Specify Time Worked è possibile consuntivare il tempo che la risoluzione del Ticket ha richiesto. b) Premere Save per salvare quanto inserito e completare la risoluzione in un secondo momento o Resolve per risolvere il Ticket. Una volta premuto il tasto Resolve, il sistema invia una mail al Primary Contact per chiedere se il problema è realmente risolto. Start PcAnywhere Questo link permette di utilizzare PcAnywhere per il controllo remoto dei client Suggest Self Service Questo link permette di identificare i processi attivi, e di consigliare all utente quello da utilizzare per il suo problema. View Previous Submition Questo link permette di vedere tutti i Ticket già aperti per verificare se esistono richieste simili. ALTIRIS MANUALE OPERATORI ICT 50

51 OTHER ACTIONS Manage Equipment Permette di selezionare gli Asset da associare al Ticket a) Premere il link Manage Equipment b) Ricercare l asset utilizzando una delle tre modalit{ di ricerca ALTIRIS MANUALE OPERATORI ICT 51

52 c) Premendo Add vicino agli asset che si vogliono associare al Ticket, gli stessi sono inseriti nella lista degli asset da aggiungere d) Premere il tasto Save e) Close All interno del Ticket è possibile vedere gli asset che si è deciso di associare al Ticket Send Mail Questo link permette di inviare una mail dall interno del Ticket. In questo modo tutte le mail inviate e le eventuali risposte sono inserite nell History del Ticket. ALTIRIS MANUALE OPERATORI ICT 52

53 a) Premere il link Send Mail È visualizzata la pagina da cui è possibile selezionare: A chi si vuole inviare la mail: Add a Group ; Add a Contact ; Search for Specific User or Group nel caso la persona a cui si vuole inviare la mail non sia già visualizzata Il template che si vuole utilizzare b) Premendo Quick Send i campi del template sono compilati in automatico e la mail è inviata; c) Premendo Modify and Send è possibile modificare il template inserendo informazioni aggiuntive ALTIRIS MANUALE OPERATORI ICT 53

54 È possibile inserire i destinatari manualmente; Aggiungere allegati; Modificare il testo della mail; Il campo Include the Reply Code permette di inserire il testo necessario per gestire le eventuali risposte alla mail d) Premere Preview ALTIRIS MANUALE OPERATORI ICT 54

55 e) Premere il tasto Send per inviare la mail e Back per modificarla Add\Manage Bulletin Board Questo link permette di gestire i Bulletin Board all interno del sistema Search KB Questo link permette di eseguire la ricerca di possibili soluzioni all interno della Knowledge Base a) Premere il link Search KB ; b) Eseguire la ricerca ALTIRIS MANUALE OPERATORI ICT 55

56 È possibile eseguire diverse operazioni: View KB: Per prendere visione dell articolo; Article: Per inviare l articolo via mail REFERENCE TOOLS I link presenti sotto questa sezione permettono di accedere direttamente a dei motori di ricerca per identificare la soluzione a problemi segnalati CHANGE AND PROBLEM MANAGEMENT TOOLS Questa sezione contiene tutti i link per l apertura e la gestione di Change e Problem legati al Ticket. I Reports Sono in fase di definizione i report che saranno resi disponibili agli operatori ICT. Pertanto, in questa versione di manuale, questo paragrafo è da considerarsi temporaneamente vuoto. La Technician Dashboard È in fase di definizione la struttura della Technician Dashboard e, in particolare, dei report in essa ricompresi e che saranno resi disponibili agli operatori ICT. Pertanto, in questa versione di manuale, questo paragrafo è da considerarsi temporaneamente vuoto. ALTIRIS MANUALE OPERATORI ICT 56

57 La Knowledge Base Sono in fase di definizione le dinamiche di processo con cui mantenere popolata la Knowledge Base; in particolare, i report ricompresi nell area presentata in Altiris all attuale versione del manuale sono quelli standard che potrebbero essere oggetto di revisione nelle successive versioni sia di strumento sia di manuale. Pertanto, in questa versione di manuale, questo paragrafo è da considerarsi temporaneamente vuoto. Gli avvisi dal Service Desk In occasione di particolari dinamiche di gestione dei Servizi ICT quali: rilasci in ambiente di produzione di funzionalità che, in maniera concordata con gli utenti, possono comunque rendere non operativi dei Servizi per un periodo limitato di tempo in orario lavorativo interessando una vasta popolazione utente; fermi non pianificati in ambiente di produzione di Servizi ICT che interessano una vasta popolazione utente, quale il Servizio di Posta Elettronica, disservizi di connettività; etc. il Service Desk predispone una messaggistica opportuna di avviso e di previsione di dinamica evolutiva dell evento che gli utenti possono visualizzare nella specifica area Bulletin Board posizionata in alto a sinistra della pagina Home Page. Quest area sar{ visibile soltanto in occasione di presenza di una o più segnalazioni e i messaggi in essa contenuti sono presentati con una dinamica di scrolling verticale che eventualmente può essere temporaneamente bloccato. Selezionando il titolo del messaggio, Altiris apre la pagina di Knowledge Base che contiene i dettagli sul messaggio stesso. ALTIRIS MANUALE OPERATORI ICT 57

58 Gestione dei Change Principi Quali richieste possono essere dei Change? Si è detto, nel capitolo relativo alla definizione del Processo di Change Management, che per Change (o, di seguito, anche Request For Change RFC) si intende l aggiunta, la modifica o la rimozione di un servizio o di componenti di un servizio (e relativa documentazione) che sia stata autorizzata, pianificata o supportata. Le RFC, per loro natura, possono essere di maggior o minor impatto e, conseguentemente, potrebbero configurarsi come veri e propri progetti. Per determinare se si tratti di una RFC gestibile con il processo di Change Management o se si debba gestire nell ambito del Project Management, di norma si definisce un valore soglia di impegno di realizzazione che varia da realtà a realtà. Nel caso del Gruppo ICBPI, le diverse società (che di recente si sono integrate organizzativamente) hanno adottato diversi livelli soglia per indirizzare i cambiamenti ai servizi esistenti in relazione anche a diverse contrattualizzazioni con i propri fornitori e Outsourcer. Sono in fase di valutazione i livelli soglia che rendano uniforme il trattamento dei Change rispetto ai Progetti e alle Service Request. Lo strumento Altiris, non potendo entrare nel merito delle valutazioni soggettive e qualitative che sono fatte dai Service Manager per poter decidere se si tratti di una RFC o di un Progetto, si limita a trattare i veri e propri Change soltanto dopo essere stati così classificati dal Change Manager ed escludendo, pertanto, i progetti che dovrebbero essere supportati da workflow e strumenti diversi dedicati. Sono, pertanto, ricompresi tra le RFC tutte le iniziative che, in accordo con l utente, si configurano, ad esempio, come: cambiamenti imposti esternamente (ad es. per adeguamenti legislativi); realizzati proattivamente per cercare di raggiungere livelli imposti di efficienza ed efficacia; per attuare iniziative a supporto del business, o ancora da programmi, progetti o iniziative per il miglioramento dei servizi; cambiamenti conseguenti ad incidenti che si presentano ricorsivamente e che, quindi, necessitano una soluzione definitiva; Implementazioni atte a produrre migliorie. Attori Altiris, essendo un tool ITIL compliant, si riferisce a tipologie di figure coinvolte nel processo di Change Management secondo questo standard. Questo significa che a tutte le risorse del Gruppo ICBPI coinvolte in questo processo sono attribuiti uno o più ruoli di quelli sotto riportati a seconda del loro coinvolgimento (a volte anche dinamicamente e in fase di trattazione di una RFC) in attività di questa tipologia. ALTIRIS MANUALE OPERATORI ICT 58

59 CHANGE INITIATOR Colui che innesca il processo di Change inserendo nel tool la RFC. Può essere un utente chiave (utente selezionato ad hoc all interno di un area lavorativa a cui sono stati dati i permessi a livello di utenza per la gestione delle RFC) o un operatore ICT (utente tecnico dell area ICT che usufruisce degli stessi privilegi di cui sopra). Una RFC può essere aperta soltanto direttamente in Altiris e non via mail. CHANGE MANAGER I compiti principali del Change Manager, alcuni dei quali possono essere delegati, sono i seguenti: Ricevere, tracciare e, insieme ai Change Initiator, assegnare la priorità a tutte le RFC. Rigettare subito le richieste impraticabili; Cooperare con tutte le strutture coinvolte per coordinarne l implementazione e i test secondo la pianificazione definita; Verificare tutti i Change eseguiti per assicurarsi che si sono raggiunti gli obiettivi prefissati; Analizzare tutti i Change per individuare eventuali trend in atto o problemi emergenti; Chiudere le RFC; Produrre dei report regolari e accurati da presentare al management. CAB CHANGE ADVISORY BOARD Il Change Advisory Board (CAB) è un comitato di persone che valuta le RFC e offre consigli al processo di Change Management sulle singole RFC. Può avere delega di approvazione delle RFC. I membri del CAB devono essere rappresentativi di tutte le componenti del dipartimento ICT per assicurarsi di considerare tutti i punti di vista nella valutazione dei cambiamenti. Il Change Advisory Board / Emergency Commitee (CAB / EC) è una versione ristretta del CAB, usata nel caso di necessità consultive urgenti. Per i processi realizzati per il Gruppo ICBPI e documentati in questo manuale, non si è dovuta attivare la componente di attraversamento del processo a favore del CAB e del CAB/EC. I compiti principali dei membri del Change Advisory Board sono elencati di seguito: Analizzare tutte le RFC che sono proposte in sede di CAB, determinandone gli impatti e le risorse necessarie per l implementazione; Partecipare a tutti i meeting del CAB, esprimendo il proprio parere sui Change in agenda al fine di autorizzarne l esecuzione; Nel caso di CAB convocati per Emergency Change essere disponibili per una consultazione. ALTIRIS MANUALE OPERATORI ICT 59

60 CHANGE IMPLEMENTER Di questa classe fanno parte tutti coloro che realizzano una qualche componente della soluzione richiesta dalla RFC. Compiti del Change Implementer sono: realizzare la soluzione richiesta; testarne in ambiente di Test dedicato la validità operativa e funzionale; richiedere il passaggio delle componenti realizzate e testate in ambienti di Collaudo per permettere al Change Tester di provvedere secondo i propri compiti; provvedere a modificare e correggere quanto realizzato ma che risulti non funzionante al termine dei collaudi; richiedere il passaggio delle componenti realizzate e testate in ambienti di Produzione; provvedere all eventuale ripristino (rollback) secondo i piani di back-out in caso di fallimento dell implementazione eseguita; documentare quanto realizzato. CHANGE TESTER Tra i Change Tester si possono identificare sia gli utenti sia gli stessi Change Implementer sia altre risorse ICT coinvolte nella soluzione. Compiti principali dei Change Tester sono: verifica di effettiva e completa realizzazione delle funzionalità / soluzioni descritte nella documentazione di specifiche funzionali a supporto della RFC; verifica di effettiva correttezza del comportamento delle soluzioni realizzate; verifica di non regressione delle soluzioni pre-esistenti integrate da quelle nuove. Processo Change Initiator - Apertura nuova RFC Ogni membro dell organizzazione dovrebbe essere autorizzato a richiedere un cambiamento, questo consente di incoraggiare l innovazione e di far emergere potenziali problemi. Gli IT Competence Center potranno avere un accesso diretto all inserimento di RFC, mentre si suggerisce di far transitare le richieste di utenti e clienti da una struttura in grado di filtrarle, come ad esempio i Service Manager dei Competence Center o una struttura di Demand Management. Il Change Inititiator può, pertanto, essere sia un Utente chiave abilitato all'apertura di RFC tramite il link facilitato sia un operatore ICT dell'area di competenza del Change. Nella figura seguente è rappresentata la videata d inserimento della RFC da parte del Change Initiator. A seguire, sono fornite spiegazioni in merito alla compilazione della stessa. ALTIRIS MANUALE OPERATORI ICT 60

61 Lo strumento Altiris, una volta creata la RFC dal Change Inititiator, assegna il corrispondente ticket al gruppo di Change Manager di riferimento in base alla scelta che è stata eseguita in fase di apertura della RFC di Macroservizio - Servizio (ad es. se è stato scelto Macroservizio - Servizio "Portale Titolari CartaSi - 3D Secure", Altiris assegnerà il ticket al gruppo di Change Manager "CHA - WEB"). Qualunque componente del gruppo di Change Manager, potrà operare sul ticket iniziando di fatto il processo di Change assistito dal tool. Nel corso del ciclo di vita della RFC, il processo potrebbe in diverse fasi ri-assegnare il ticket al gruppo di Change Manager per eseguire uno degli step previsti. In questi casi, sarà sempre notificata l'assegnazione al gruppo di Change Manager e, quindi, chiunque dei suoi componenti in qualità di Change Manager di tale area potrà intervenire e operare per far proseguire la RFC. Una informazione che dovrà obbligatoriamente essere indicata dal Change Initiator è quella relativa alla data attesa di completamento della RFC ( Requested Completion Date ). Questa indicazione, non è utilizzata all interno del processo in modalit{ strutturata, ma bensì entra a far parte delle informazioni di cui il Change Manager dovrà tener conto in fase di pianificazione del Change. Primo compito del gruppo di Change Manager è quello di filtrare tutte le RFC di competenza rigettando quelle inapplicabili, dopodiché verificare se sono presenti Emergency Change a cui dare priorità applicando le procedure per i Change in emergenza o RFC che rientrano in predefiniti Change Model. Per le RFC residue, dovrà definire la categoria di appartenenza; ITIL identifica tre categorie di base in relazione a impatto atteso e risorse richieste: ALTIRIS MANUALE OPERATORI ICT 61

62 Minor; Significant; Major. Nell'applicazione realizzata per ICBPI è stato scelto di sviluppare in prima battuta dei processi che possano trattare Change di tipo Minor e di tipo Significant rinominati qui rispettivamente in Base e Avanzato. Nel processo di tipo Base si considera di poter trattare anche quelle RFC che sono indirizzate per gli step realizzativi ai diversi Processor in outsourcing (ad es., SIASSB, Equens, etc.). Inoltre, per coprire le esigenze di lavorazione di cambiamenti urgenti (ad es. manutenzioni evolutive in emergenza) o di tipo comunque veloce, è stato predisposto un ulteriore processo di Emergency / Quick Change. SCELTA DELL URGENZA In fase di apertura della RFC, il Change Initiator è chiamato anche a scegliere il grado di Urgenza ( Urgency of Change ) che ritiene valido al momento della segnalazione. La scelta di questo valore è esattamente riproposta secondo i criteri previsti nel processo di Incident Management in quanto si è ritenuto valido anche per le segnalazioni di Change riferirsi al medesimo approccio. Infatti, le caratteristiche dei Change sono quelle di essere comunque attività da dover essere eseguite con un limitato impegno di risorse e, quindi, con una possibile risoluzione teorica di alcuni giorni di elapsed. Pertanto, potranno essere scelti i seguenti valori: 1 Attività relativa a Business critico o rischio significativo impatto finanziario per l azienda; 2 Attività che vincola un lavoro urgente; 3 Attività che vincola un lavoro di routine; 4 Nessuna immediata urgenza. CATALOGO DI SERVIZIO Esattamente come nel processo di Incident Management, anche per il Change si deve indicare per quale Macroservizio-Servizio è richiesta l esecuzione di un cambiamento. Infatti, un Change è riferibile sempre ad uno o più componenti di un Servizio pre-esistente a cui si chiede di apportare una modifica o una aggiunta che ne migliorino la fruibilità ai fini Business o ai fini tecnici di gestione dello stesso. Il Change Initiator dovrà, pertanto, scegliere negli opportuni campi i valori di Macroservizio e Servizio che fanno parte del Catalogo dei Servizi. DESCRIZIONE DELLA RFC Oltre ad un campo di inserimento del titolo con cui identifica il ticket di Change ( Change Title ), lo strumento fornisce un ulteriore campo di descrizione ( Change Description ) in cui si richiede al Change Initiator di descrivere il più possibile compiutamente la RFC. GIUSTIFICAZIONE DELLA RFC Il Change Initiator deve qui ( Change Justification ) descrivere le motivazioni organizzative / operative / funzionali di business / tecnologiche che stanno inducendo all apertura della RFC. Al termine della compilazione della videata di apertura RFC, il sistema propone una finestra di revisione della richiesta ( Review Request ) prima della conferma di sottomissione del ticket per consentire all operatore di verificare quanto verr{ poi inoltrato alle fasi successive del ALTIRIS MANUALE OPERATORI ICT 62

63 processo. Change Manager Group - Initial Approval Scopo della fase di Approvazione è la discussione e valutazione di tutte le proposte di cambiamento di competenza dei singoli gruppi di Change Manager responsabili per il Macroservizio-Servizio scelto, al fine di evitare il verificarsi di effetti indesiderati nell ambiente di produzione. Il livello di approvazione del cambiamento dovrebbe essere legato al livello di rischio del change. Per garantire la valutazione di impatto, costi, benefici e rischi ci sono tre sotto-processi logici di approvazione: Tecnico, che è parte del processo di Service Support; Finanziario; Business, che è parte del processo di Demand Management e consiste nello sviluppo di giustificazioni di business al cambiamento. Concluso il processo di approvazione è possibile passare all esecuzione del Change. COSTI E IMPATTI Il change richiesto va esaminato e occorre considerare tutte le sue implicazioni, compreso l impatto potenziale di un eventuale fallimento sui servizi, sui service asset e sulle configurazioni. I costi della RFC devono considerare, oltre ai beni materiali (HD e/o SW), la quantità di risorse umane e il tempo necessario alla realizzazione del change richiesto. Fornire, ove possibile e selezionandoli dagli elenchi forniti, indicazioni in merito agli impatti di Business, verso il Cliente e relativamente alla principale Location aziendale interessati dalla RFC. Ipotizzando che tutto vada a buon fine, ponderare quale sia il ritorno previsto dal cambiamento. Ipotizzare anche il possibile costo derivante dalla decisione di non implementare la RFC. Il Change Manager, qualora sappia identificare anche Sistema, Sottosistema e Asset associati al Servizio e impattati dalla RFC, potrà sceglierli dagli appositi campi di selezione. Queste valorizzazioni possono essere indicate sia in fase iniziale di valutazione della RFC sia all Approvazione ( Approve Change ) della RFC prima della effettiva Implementazione. ALTIRIS MANUALE OPERATORI ICT 63

64 EDIT PUBLIC DESCRIPTION Fornire una descrizione pubblica che sarà utilizzata come descrizione "non tecnica" visibile da tutti coloro che potranno accedere alla visione del ticket. ALTIRIS MANUALE OPERATORI ICT 64

65 APPROVE CHANGE Dopo aver fornito le indicazioni in merito ai Costi e agli Impatti previsti per la RFC, ed eventualmente aver fornito una descrizione pubblica, il Change Manager può procedere con l approvazione del Change. Nella videata specifica di approvazione, il Change Manager ha la possibilità di scegliere (anche visualizzandone prima il contenuto e gli estremi) di combinare questa RFC con una già esistente scegliendo di premere il tasto Combine with existing RFC. In questo caso, si aprir{ una videata che visualizza tutte le RFC esistenti al momento in cui si sta operando e, dopo aver proceduto eventualmente a visualizzarne i dettagli (scelta View in corrispondenza del titolo di una specifica RFC in elenco), potrà selezionare quella scelta. Altra possibilità è quella che, invece, voglia negare l esecuzione della RFC scegliendo di premere il tasto Deny. In questo caso, il Change Manager è chiamato a fornire le motivazioni che giustifichino tale scelta. Ultima possibilità è di Approvare la RFC. Con questa scelta, il Change Manager avvia la fase successiva del processo che consiste nella scelta del tipo di processo di Change che lo strumento dovr{ seguire tra quelli previsti (ad es., Base o Avanzato o Emergency/Quick Change ). In entrambe le scelte riguardanti i processi standard (no Emergency/Quick Change ), il procedimento prevede in questa fase di dover scegliere quali risorse parteciperanno all esecuzione del Change e con quale ruolo. La videata (divisa verticalmente in due aree differenti) consente sia di scegliere tra singole risorse cui assegnare uno dei possibili ruoli previsti dal processo, sia di scegliere uno dei Change Team predefiniti a sistema che comprende già una serie di partecipanti con ruoli pre-assegnati. ALTIRIS MANUALE OPERATORI ICT 65

66 In questa fase devono essere indicate le risorse che assumono per la RFC i seguenti ruoli: Risk Assessment (obbligatorio almeno un partecipante con questo ruolo) chi si deve occupare di eseguire le verifiche sui possibili impatti della richiesta sull esistente sistema informativo; Nell attuale release dello strumento, in tutte le sue fasi, il processo di Change prevede la dicitura Risk Assessment che in realtà per il Gruppo ICBPI deve essere letta come Analisi d impatto. Plan creation (obbligatorio almeno un partecipante con questo ruolo) chi predispone il piano per la realizzazione e il testing della RFC; Change Authorization (obbligatorio almeno un partecipante con questo ruolo) chi deve ulteriormente fornire approvazione alla effettiva esecuzione della RFC; alerts (facoltativo inserire partecipanti con questo ruolo) chi deve ricevere indicazioni via relativamente alle diverse fasi di lavorazione della RFC. Altra scelta da indicare all interno di questa videata è quella che si riferisce a chi assume il ruolo di Scheduler di questa RFC. Per scheduling s intende la scelta di quando avviare l attivit{ di implementazione della RFC e l eventuale ricorrenza della RFC. Oltre alla scelta da elenco di persone predefinite come quelle cui è possibile assegnare questo ALTIRIS MANUALE OPERATORI ICT 66

67 ruolo per la RFC in questione, lo strumento consente anche di poter indicare come Scheduler per la RFC il Change Manager stesso. In quest ultimo caso, si deve anche selezionare se si procederà allo scheduling immediatamente o dopo la fase di Analisi d impatto selezionando l apposito flag. La sottomissione della videata tramite il tasto Submit, porterà il processo allo step successivo di Analisi d Impatto ( Risk Assessment ). ANALISI D'IMPATTO Gli incaricati alla fase di Analisi d impatto ( Risk Assessment ) devono, come prima attività, assegnare nel ticket Altiris un Punteggio di Impatto per la RFC. Nel campo descrittivo successivo, deve essere indicato il piano di attività da eseguire per compiere l analisi d impatto. È possibile, inoltre, allegare documentazione a supporto usando le apposite funzionalità a fondo videata. ALTIRIS MANUALE OPERATORI ICT 67

68 SCHEDULING Come precedentemente accennato, in questa fase del procedimento l incaricato allo scheduling della RFC deve dichiarare: la data e l ora in cui attivare l implementazione della RFC (è possibile consultare il calendario dei Change selezionando Forward Schedule of Change ); definire una stima di durata dell intervento (da esprimere in giorni e ore); fornire dei commenti relativamente a tale pianificazione; eventualmente indicare nella specifica area le condizioni di ricorrenza dell attivit{. Dalla pagina di Schedule, premendo il tasto Submit, si passa alla fase di Create Plan. ALTIRIS MANUALE OPERATORI ICT 68

69 PLAN CREATION La fase di creazione del piano si concentra, più precisamente, sulle fasi di realizzazione del Change permettendo di: assegnare un titolo al piano che si sta inserendo ( Plan Title ); scegliere quale sviluppatore deve implementare l attivit{ ( Change Implementer ); indicare il tempo stimato in ore per la realizzazione ( Est. Implementation Time ); indicare in maniera descrittiva (eventualmente con il supporto di documentazione da allegare nell apposita sezione) i contenuti del piano. È possibile, inoltre, tramite due appositi campi su cui apporre una spunta, indicare se è necessaria la fornitura di nuovi apparati tecnologici e se la realizzazione prevede l esistenza di un nuovo Business Service. Il passo successivo nella creazione del Piano, prevede di inserire il Piano di Test indicando chi lo eseguirà e fornendo tutti i dettagli descrittivi (eventualmente con il supporto di documentazione da allegare nell apposita sezione). ALTIRIS MANUALE OPERATORI ICT 69

70 Potrebbe essere anche indicato, da chi compila questa parte della richiesta, che il Piano non prevede fase di Test, premendo il tasto Not applicable (lo strumento propone in questo caso una videata ove descrivere le motivazioni a supporto di tale scelta). ALTIRIS MANUALE OPERATORI ICT 70

71 Ulteriore sezione è quella che prevede la descrizione di un Piano di Backout (o di rollback) se applicabile, fornendo i dettagli operativi (anche con supporti da allegare) nelle aree predisposte. ALTIRIS MANUALE OPERATORI ICT 71

72 Anche in questo caso, potrebbe essere indicato da chi compila questa parte della richiesta che il Piano non prevede un Piano di Backout, premendo il tasto Not applicable (lo strumento propone in questo caso una videata ove descrivere le motivazioni a supporto di tale scelta). Al termine di questa fase, il tool permette di visualizzare sommariamente in una lista il piano predisposto. ALTIRIS MANUALE OPERATORI ICT 72

73 In questa videata è possibile scegliere da un apposito tasto la necessità di voler aggiungere un nuovo Piano ( Add another Plan ). Lo strumento avvier{ un percorso del tutto identico a quello appena descritto arrivando, al termine, ad aggiungere una nuova istanza in questa videata per visualizzare tutti i piani creati. Al termine, si dovr{ confermare tutta l attivit{ di pianificazione sottomettendo (tasto Submit ) la pianificazione della RFC. Change Manager Group - Final Review Terminata la fase di creazione del Piano, lo strumento assegna il ticket di RFC al Change Manager che deve procedere alle verifiche finali prima di approvarlo (o rifiutarlo) permettendo così l inizio della fase successiva di effettiva realizzazione e rilascio. VIEW PLANNING Dopo aver eventualmente modificato alcuni dettagli attraverso il link Edit Change Details, la fase di CM Final Review prevede che il Change Manager possa analizzare i documenti presenti in Altiris per i diversi piani realizzati (Implementation, Test e Backout) visibili in una lista. ALTIRIS MANUALE OPERATORI ICT 73

74 In questo passaggio iniziale, il Change Manager potrebbe anche indicare (attraverso la selezione di un apposito marcatore) che la RFC deve essere considerata Unplanned, di fatto forzando lo strumento ad ignorare qualunque scheduling fosse stato inserito precedentemente dallo Scheduler, questo per sopraggiunti razionali che facciano optare per tale scelta. È in fase di studio la possibilità di rendere disponibile in una prossima release dello strumento la modifica della data di schedulazione della RFC anche successivamente alla sua fase di Approvazione finale. ALTIRIS MANUALE OPERATORI ICT 74

75 REJECT / APPROVE Continuando nei passaggi di Final Review, il Change Manager deve scegliere se approvare o rigettare la richiesta, in quest ultimo caso fornendo spiegazione scritta in apposita videata proposta dallo strumento e scegliendo a quale fase si debba tornare attraverso la scelta da effettuare nel campo Return to:. ALTIRIS MANUALE OPERATORI ICT 75

76 Premendo sul tasto Approve si passa alla fase di Waiting for Implemention Date (or Assignment to Release). Waiting for Implementation Date or Assignement to Release Nel periodo che separa l approvazione della RFC dalla fase di effettiva partenza di realizzazione attivata tramite assegnazione automatica del ticket allo sviluppatore da parte del tool in base al piano di schedulazione inserito nelle fasi precedenti, il Change Manager può verificare lo stato del ticket ed eventualmente decidere di forzare direttamente l implementazione anche in data antecedente a quella pianificata, se sopraggiunti razionali che facciano decidere in tal senso. ALTIRIS MANUALE OPERATORI ICT 76

77 Questa operativit{ può essere eseguita scegliendo l azione View che aprir{ una finestra riepilogativa della RFC e procedendo alla scelta della forzatura tramite l apposito tasto a fondo videata ( Force Implementation Now ). Implementing Sia nel caso in cui sia stato lo strumento a riattivare il ticket secondo schedulazione sia che abbia provveduto il Change Manager a forzare l implementazione rispetto allo scheduling, il processo propone all implementatore il ticket attraverso un normale assegnamento. Con questo passaggio lo sviluppatore deve scegliere la voce Implement Change dal menu Actions. REVIEW REQUEST La prima finestra presentata dallo strumento è quella di Review della RFC per fornire le indicazioni allo sviluppatore circa quanto da lui atteso. ALTIRIS MANUALE OPERATORI ICT 77

78 In questa fase è data possibilit{ all operatore incaricato dell implementazione di indicare l eventuale riferimento al corrispondente Ticket aperto dal fornitore esterno (ad es., Processor SIASSB/Equens) a fronte di richiesta di sviluppi di propria competenza (campo External ID ). DETAILS CONFIRMATION Il passo successivo per lo sviluppatore è quello di confermare o meno i dettagli che il ticket gli propone, eventualmente fornendo in caso negativo le spiegazioni opportune. IMPLEMENTATION PLAN Nel caso in cui fosse stato confermato al passo precedente che i dettagli sono quelli attesi, lo strumento propone la finestra dove sono elencati i piani di implementazione che erano stati inseriti e propone la domanda se lo sviluppatore ha provveduto o meno alla realizzazione, ai test tecnici, di integrazione e di non regressione. ALTIRIS MANUALE OPERATORI ICT 78

79 Al termine di questa fase di implementazione, prima di analizzare il comportamento specifico dello strumento nel trattare le possibili risposte alla domanda Have you implemented the change?, è importante far notare che da questo momento il processo si potrà comportare differentemente a seconda che si sia scelta la via di processo Base o Avanzato. La parte di manuale riferita al processo Avanzato è rappresentata di seguito in appositi riquadri che ne evidenziano la particolarità di trattazione. Nel caso in cui si risponda negativamente, il processo si chiude in attesa di un successivo rilancio in cui dare risposta affermativa. Viceversa, se si risponde positivamente, il processo procede con la fase di scelta sullo User Acceptance Test (UAT) ponendo il ticket in stato Wait confirm UAT on production e assegnandolo al Change Manager con richiesta di azione Confirm UAT on Prod. ALTIRIS MANUALE OPERATORI ICT 79

80 Nel caso in cui si sia risposto affermativamente alla domanda il processo procede con la fase di UAT ponendo il ticket in stato Testing, altrimenti il processo continua con la fase di CM Verification. ALTIRIS MANUALE OPERATORI ICT 80

81 AVANZATO Al termine della fase di implementazione e al momento in cui si deve rispondere alla domanda Have you implemented the change?, per il processo di tipo Avanzato se fosse scelta la risposta affermativa, lo strumento pone il ticket in stato Staging e lo assegna al gruppo SD3 Gestione Deploy. GESTIONE STAGING Quando l operatore del gruppo SD3 Gestione Deploy prende in gestione il ticket, deve scegliere l azione Stage Change e alla videata che gli si propone deve rispondere alla domanda se sia stato predisposto correttamente l ambiente di Staging per questa RFC. Nel caso in cui si risponda negativamente, lo strumento propone avviso di procedere alla predisposizione dell ambiente di Staging. Viceversa, se si risponde positivamente, è proposta una finestra di inserimento dei Success comments. ALTIRIS MANUALE OPERATORI ICT 81

82 AVANZATO Il processo continua con l assegnamento del ticket al Change Manager ponendolo in stato Wait confirm UAT on Test. Il Change Manager ha a disposizione l azione di Confirm UAT on Test che gli permette di accedere ad una videata di domanda sulla effettiva necessità di procedere con una specifica sessione di User Acceptance Test in ambiente di Test. Nel caso in cui si risponda negativamente, lo strumento richiede in apposita videata di darne spiegazione. Quindi, il processo procede con l assegnazione del ticket al gruppo SD3 Gestione Deploy e pone lo stato a In attesa di conferma rilascio (continuare al paragrafo Approvazione al rilascio ). Viceversa, se si risponde positivamente, è proposta una finestra di inserimento dei Success comments e poi il processo procede con l assegnazione del ticket alla risorsa che era stata indicata come Tester in fase di pianificazione del test, per effettuare lo User Acceptance Test concordato. ALTIRIS MANUALE OPERATORI ICT 82

83 AVANZATO UAT IN AMBIENTE DI TEST Lo strumento propone le domande sul fatto che sia stato eseguito il piano di test utente e sull effettivo esito positivo. Nel caso in cui sia stato eseguito il test ma l esito sia stato negativo, il sistema provvede a richiedere in prima battuta di inserire un commento in cui descrivere l esito del test e le motivazioni relative ( Failure Comments ). Poi il processo continua con lo step di Test Backout Plan ponendo il ticket in stato Backing Out e lo riassegna allo sviluppatore. In questo caso, il processo chiede con videata dedicata di specificare se il backout è andato a buon fine o meno; nel caso sia fallito il Backout, Altiris invia il ticket al Change Manager per procedere con lo step di dichiarazione di Backout Failure; quindi, passando dall azione Verify Change, chiede di decidere da quale step di processo si debba riprendere il processo (implementazione, analisi impatto, pianificazione, chiusura definitiva del ticket come fallito). ALTIRIS MANUALE OPERATORI ICT 83

84 AVANZATO Mentre, nel caso di procedimento andato a buon fine, Altiris invia il ticket (che sarà in stato CM reassigning Rolled Back Change ) al Change Manager che dove decidere, passando dall azione Verify Change, da quale step di processo si debba riprendere il processo (implementazione, analisi impatto, pianificazione, chiusura definitiva del ticket come fallito). Se, invece, l esito dello User Acceptance Test in ambiente di Test è stato positivo, il flusso di processo continua con la videata di Success Comments. Dopodiché il ticket è assegnato con stato In attesa di conferma al rilascio nuovamente al SD3 Gestione Deploy per la fase di approvazione del deployment. ALTIRIS MANUALE OPERATORI ICT 84

85 AVANZATO APPROVAZIONE AL RILASCIO Lo strumento propone le domande sul fatto che si autorizzi la messa in Produzione delle modifiche previste dalla RFC. Nel caso in cui sia fatta la scelta autorizzativa, il sistema richiede di inserire un commento in cui descrivere l esito dello step ( Success Comments ). Se, invece, si esegue la scelta di rifiuto, il sistema provvede a richiedere in prima battuta di inserire un commento in cui descrivere le motivazioni relative al rifiuto. Dopodiché viene data indicazione che comunque dovrà attendersi la successiva autorizzazione alla messa in Produzione da parte del SD3 Gestione Deploy appena sar{ stata valutata possibile da loro. Quando sar{ stata confermata l autorizzazione, il ticket sar{ posto in stato Deployment e assegnato al CHA Datacenter Delivery che, con l azione Rilascio, dovrà indicare se la messa in Produzione è avvenuta con successo o meno. Nel caso si risponda No, Altiris presenta una videata di Failure Comments in cui inserire le dinamiche rilevate. Lo strumento avvia, quindi, la fase di Backout Change in Produzione del tutto assimilabile come processo a quello della fase in ambiente di Test. Nel caso si risponda Si, il flusso di processo continua con la videata di Success Comments e il ticket è assegnato al Change Manager perché effettui la scelta di eseguire o meno gli UAT in ambiente di Produzione. ALTIRIS MANUALE OPERATORI ICT 85

86 USER ACCEPTANCE TEST DI PRODUZIONE Lo strumento propone le domande sul fatto che sia stato eseguito il piano di test utente e sul suo effettivo esito positivo. Nel caso in cui sia stato eseguito il test ma l esito sia stato negativo, il sistema richiede in prima battuta di inserire un commento in cui descrivere l esito del test e le motivazioni relative. Poi il processo continua con lo step di Production Backout Plan ponendo il ticket in stato Backing Out e riassegnandolo allo sviluppatore. In questo caso, il processo chiede con videata dedicata di specificare se il backout è andato a buon fine o meno; nel caso sia fallito il Backout, Altiris invia il ticket al Change Manager per procedere con lo step di dichiarazione di Backout Failure e poi chiude il ticket con stato Closed as Failed. Mentre, nel caso di procedimento andato a buon fine, non sarà necessario passare dal Change Manager per la dichiarazione di Backout Failure ma si andrà direttamente alla chiusura del ticket sempre con stato Closed as Failed. Se, invece, l esito dello User Acceptance Test è stato positivo il flusso di processo continua con la videata di Success Comments. ALTIRIS MANUALE OPERATORI ICT 86

87 SUCCESS COMMENTS In questa fase è richiesto di inserire una descrizione (eventualmente associando documentazione a supporto) sul buon esito dei test. Proseguendo con il tasto Submit, il flusso assegna la fase di CM-Verification al Change Manager che deve provvedere (con l azione Verify Change ) alla revisione completa dell andamento del Change e fornire il feedback finale circa il completo buon esito del procedimento o il mancato raggiungimento dell obiettivo. CM Verification REVIEW OF CHANGE Nella videata di questa fase il Change Manager può indicare se il Change ha subito un esito negativo (tasto Failure ) o se è risultato conforme alle attese (tasto Success ). ALTIRIS MANUALE OPERATORI ICT 87

88 Nel caso di Failure, è proposta una classica videata di inserimento commenti sui razionali che hanno condotto a questa scelta ed è richiesto al Change Manager di indicare a quale fase del processo dover ritornare (campo Return to: ) per rivedere eventualmente la ri-lavorazione del Change. Nel caso, invece, in cui sia stato indicato il completamento con successo del Change, il ticket viene posto dallo strumento in stato Awaiting 30 Day-Review. Questo stato rimarrà assegnato al ticket per 30 giorni al fine di permettere in questo periodo di attesa verifiche di possibili correlazioni di Incident con quanto è stato rilasciato nel periodo recente. Al termine dei 30 giorni, il ticket sar{ automaticamente portato allo stato Closed dallo strumento Altiris. In alternativa, il Change Manager potrà forzare anticipatamente la chiusura della RFC (arrivando allo stato Closed ) scegliendo l azione View e, nella videata corrispondente, selezionando il tasto Review complete. A chiusura completa del ticket, Altiris invia una mail di chiusura al Change Initiator. ALTIRIS MANUALE OPERATORI ICT 88

89 USER MANAGEMENT Come evidenziato in precedenza, per un più agevole utilizzo di Altiris, sono stati creati alcuni link che permettono un accesso facilitato, riservato a funzioni e a profili abilitati, utili per instradare e formulare rapidamente alcune tipologie di ticket. La gestione delle credenziali di accesso ai servizi erogati è stata suddivisa in tre modelli di Service Request, accessibili tramite le voci di menu a essi dedicati e riservati alla funzione HR e ai Responsabili d'ufficio - Team Leader. I link implementati sono i seguenti: Gestione Utenze, per le richieste di abilitazione a singole applicazioni o per l assegnazione di profili tipo; Gestione Utenze HR, per le richieste di abilitazione, per censimento nuovo utente, per cambi ufficio o per cessazioni di rapporto; Gestione Utenze Esterni, per le richieste di censimento o cancellazione di utente esterne; I link in oggetto sono abilitati e riservati alla Funzione HR e ai Responsabili d ufficio Team Leader ALTIRIS MANUALE OPERATORI ICT 89

90 Gestione Utenze Questo tipo di richiesta, che si trova all interno della cartella Service Request, permette di richiedere attività sulle utenze ovvero richieste di abilitazione su singole applicazioni o assegnazione profilo tipo. Per ogni richiesta è necessario allegare il relativo template, da scaricare tramite apposito link presente all interno della maschera di apertura ticket. Il template, compilato secondo le istruzioni allegate (link a file.pdf), deve essere obbligatoriamente allegato al ticket. Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattata dall esigenza segnalata; ALTIRIS MANUALE OPERATORI ICT 90

91 What is your Issue (campo obbligatorio): campo precompilato non modificabile; Details that might help resolve this issue (campo obbligatorio): campo precompilato non modificabile; Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; Master Service (campo obbligatorio): campo precompilato non modificabile; Service (campo obbligatorio): campo precompilato non modificabile; Supporting Documents or Images (campo obbligatorio): In questo campo è necessario allegare il template a supporto della richiesta correttamente compilato. Gestione Utenze HR Questo tipo di richiesta, che si trova all interno della cartella Service Request, permette alla funzione HR di richiedere attività sulle utenze, in particolar modo: richieste di censimento nuovo utente, cambio ufficio, cessazione rapporto. Per ogni richiesta è necessario allegare il relativo template, da scaricare tramite apposito link presente all interno della maschera di apertura ticket. Il template, compilato secondo le istruzioni allegate (link a file.pdf) deve essere obbligatoriamente allegato al ticket. ALTIRIS MANUALE OPERATORI ICT 91

92 Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattata dall esigenza segnalata; What is your Issue (campo obbligatorio): campo precompilato non modificabile; Details that might help resolve this issue (campo obbligatorio): campo precompilato non modificabile; Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; ALTIRIS MANUALE OPERATORI ICT 92

93 Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; Master Service (campo obbligatorio): campo precompilato non modificabile; Service (campo obbligatorio): campo precompilato non modificabile; Supporting Documents or Images (campo obbligatorio): In questo campo è necessario allegare il template a supporto della richiesta correttamente compilato. Gestione Utenze Esterni Questo tipo di richiesta, che si trova all interno della cartella Service Request, permette di richiedere attività sulle utenze relative a personale esterno. Who does this issue affected (campo obbligatorio): Permette di definire chi ha il problema, dando la possibilità di aprire Ticket per colleghi o altre persone; User Affected (campo obbligatorio): Contiene il nome della persona che è impattata dall esigenza segnalata; What is your Issue (campo obbligatorio): campo precompilato non modificabile; ALTIRIS MANUALE OPERATORI ICT 93

94 Details that might help resolve this issue (campo obbligatorio): campo precompilato non modificabile; Needed By Date (campo non obbligatorio): Si può impostare una data entro la quale ci si attende che il Ticket sia risolto; Location Affected (campo non obbligatorio): In questo campo è riportata l informazione di dove si trova la persona, indicata nel campo User Affected. Se la persona si trova in un posto differente, si può modificare l informazione tramite il link Change Location; Department Affected (campo non obbligatorio): In questo campo è riportata l informazione del dipartimento della persona che risulta nel campo User Affected. Se il dipartimento riportato non è quello corretto, si può modificare tramite il link Change Department. Andrebbe inoltre segnalata la necessità di una correzione; Urgency of this Need or Issue: In questo campo va indicata l Urgenza del Ticket che si sta aprendo; Who is Affected?: In questo campo va indicato l Impatto del Ticket che si sta aprendo; Master Service (campo obbligatorio): campo precompilato non modificabile; Service (campo obbligatorio): campo precompilato non modificabile; Supporting Documents or Images (campo obbligatorio): In questo campo è necessario allegare il template a supporto della richiesta correttamente compilato. ALTIRIS MANUALE OPERATORI ICT 94

95 Allegati ALTIRIS MANUALE OPERATORI ICT 95

96 Tabella delle Priorità Priorità su 6 livelli, con il livello 1 riservato ad eventi straordinari Priorità in funzione di Urgenza e Impatto (indicati dall utente) e Severit{ (associata al Servizio) IMPACT SEVERITY oppure N.A. 2 oppure N.A. 2 oppure N.A. 2 oppure N.A URGENCY SEVERITY x URGENCY PRIORITY Definiti nel Catalogo Servizi Livello Descrizione 1 ALTA 2 MEDIA 3 BASSA SEVERITA' 1*1 1*2 1*3 1*4 2*1 2*2 2*3 2*4 3*1 3*2 3*3 3* IPOTESI La priorità 1 non scaturisce mai da un calcolo automatico: è forzata da una persona del SD IMPATTO Livello Descrizione 1 1-Intera Direzione o tutti i Clienti 2 2-Intero Servizio o gruppo di Clienti o VIP 3 3-Intero Ufficio o singolo Cliente 4 4-Singolo Utente interno URGENZA Livello Descrizione 1 1-Attività relativa a Business critico o rischio significativo impatto finanziario per l'azienda 2 2-Attività che vincola un lavoro urgente 3 3-Attività che vincola un lavoro di routine 4 4-Nessuna immediata urgenza PRIORITA' Livello Descrizione 1 Straordinaria 2 Critica 3 Alta 4 Normale 5 Bassa 6 Opzionale Forniti da Utente in fase apertura ticket Calcolato da Altiris ALTIRIS MANUALE OPERATORI ICT 96

97 Mappa mentale Escalation ALTIRIS MANUALE OPERATORI ICT 97

98 Mappa mentale Classificazione ALTIRIS MANUALE OPERATORI ICT 98

99 ALTIRIS MANUALE OPERATORI ICT 99

100 ALTIRIS MANUALE OPERATORI ICT 10 0

101 Mappa mentale Request Type ALTIRIS MANUALE OPERATORI ICT 10 1

102 Mappa mentale Stati del Ticket ALTIRIS MANUALE OPERATORI ICT 10 2

103 Mappa mentale Codici di chiusura del Ticket ALTIRIS MANUALE OPERATORI ICT 10 3