Portale assistenza Creazione ticket V 2.0

Transcript

1 V 2.0

2 Storico Documento Versione Data modifica Autore modifica Breve descrizione modifica V1.0 01/10/2014 Regesta Versione iniziale V2.0 11/02/2015 Regesta Nuove funzionalità: - Possibilità di gestione doppio livello approvazione ticket - Gestione stima ticket - Gestione validazione ticket - Gestione comunicazioni in modalità simil chat - Flag bug fixing

3 Pagina 3 di 13 SOMMARIO 1. Introduzione Overview generale Ruoli utente Stati del ticket Invio Comunicazioni Accesso al portale Visualizzazione ticket Apertura nuovo ticket Gestione allegati... 13

4 Pagina 4 di Introduzione Scopo di questo documento è la descrizione delle funzioni base di gestione e visualizzazione dei ticket, offerte dal portale di assistenza Regesta. Si tratta di uno strumento nato per fornire un chiaro e trasparente supporto ai clienti nella gestione delle richieste di assistenza (ticket), aperte verso Regesta e riguardanti i propri progetti attivi. 2 Overview generale Il portale, raggiungibile da remoto dal seguente url: Garantisce ai clienti (tramite utenti abilitati) la possibilità di creare, modificare, e visualizzare i ticket di assistenza desiderati, visualizzarne lo stato di avanzamento lavori e, quando necessario, dichiararne la chiusura. 2.1 Ruoli utente Per garantire ad ogni cliente flessibilità e controllo sui ticket prima che vengano definitivamente aperti verso Regesta, il portale è stato sviluppato in modo da supportare diversi ruoli utente le cui funzioni verranno descritte di seguito. Tali ruoli dovranno essere necessariamente attribuiti (mediante una veloce attività di configurazione degli accessi in carico a Regesta) ai diversi user del portale definiti per ciascun cliente. A seconda del tipo di ruolo attribuito ciascuno user potrà creare: - ticket immediatamente aperti ed inviati verso Regesta - ticket soggetti ad approvazione interna (semplice o doppia) prima dell inoltro a Regesta. La gestione del campo Commessa (introdotto nella versione 2.0 del tool) consente la mappatura di Utenti e Amministratori separati per i diversi plant che un cliente può avere. La mappatura dei ruoli utente di seguito descritta consente di gestire, con la massima flessibilità, le esigenze di clienti che necessitano di un solo user per il portale, che inserisce, modifica e chiude i ticket, insieme alle esigenze di clienti che richiedono users diversi, in plant diversi, che inseriscono ticket soggetti all approvazione (semplice o doppia) di un amministratore prima dell inoltro a Regesta.

5 Pagina 5 di 13 Amministratore: super user che ha la possibilità di creare, modificare e chiudere i ticket. Ha inoltre la possibilità di approvare e gestire i ticket aperti da utenti di tipo approvazione semplice o approvazione doppia. Vi possono essere diversi tipi di Amministratore: - Con Area specificata e Commessa specificata o Esempio: Amministratore Area FI della Commessa Commessa Plant1 o Rappresenta il responsabile funzionale di un ufficio di un determinato plant o Può vedere ed approvare (se richiesto) tutti i ticket di utenti della propria Area e del proprio Plant - Con Area specificata e Commessa non specificata o Esempio: Amministratore Area FI o Rappresenta il responsabile funzionale di un ufficio per tutti i plant del gruppo o Può vedere ed approvare (se richiesto) tutti i ticket di utenti della propria Area per tutti i plant del gruppo - Con Area non specificata e Commessa specificata o Esempio: Amministratore della Commessa Commessa Plant1 o Rappresenta l IT Manager di un determinato plant o Può vedere ed approvare (se richiesto) tutti i ticket di utenti del proprio Plant, a qualsiasi Area essi appartengano - Con Area non specificata e Commessa non specificata o Rappresenta l IT Manager del gruppo o Può vedere ed approvare (se richiesto) tutti i ticket di utenti del gruppo, a qualsiasi Area essi appartengano Utente stato aperto: utente che può creare ticket che al salvataggio vengono direttamente inoltrati a Regesta, senza necessità di cicli di approvazione interna. Rispetto ad un utente di tipo Amministratore ha privilegi limitati in quanto non può approvare ticket e può visualizzare ticket solo della propria Area e del proprio Plant. Vi possono essere diversi tipi di Utente Stato Aperto: - Con Area specificata e Commessa specificata o Esempio: Utente Area FI della Commessa Commessa Plant1 o Rappresenta l utente di un ufficio di un determinato plant o Può inserire e vedere solo ticket della propria Area e del proprio Plant - Con Area specificata e Commessa non specificata o Esempio: Utente Area FI o Rappresenta l utente di un ufficio centralizzato, che serve tutti i plant del gruppo o Può inserire e vedere solo ticket della propria Area, ma per tutti i plant del gruppo, specificando poi sul singolo ticket a quale commessa (e quindi quale Plant) il ticket si riferisce - Con Area non specificata e Commessa specificata o Esempio: Utente della Commessa Commessa Plant1 o Rappresenta un Utente di un determinato plant che si occupa di più aree o Può inserire e vedere solo ticket del proprio Plant, ma per tutte le aree, specificando poi sul singolo ticket a quale Area il ticket si riferisce - Con Area non specificata e Commessa non specificata

6 Pagina 6 di 13 o In questo caso si consiglia la mappatura dell utente con uno user di tipo Amministratore Utente approvazione semplice: può creare ticket che al salvataggio non vengono direttamente inoltrati a Regesta, ma necessitano dell approvazione di uno user di tipo Amministratore, che sovrintenda, almeno, all Area cui il ticket si riferisce. Nel caso in cui esistano più user di tipo Amministratore (es. uno che Amministra solo un area, l altro che amministra tutte le aree del plant), tutti vengono informati del ticket aperto e possono approvarlo; all approvazione del primo Amministratore il ticket viene inoltrato a Regesta. Vi possono essere diversi tipi di Utente approvazione semplice: per la categorizzazione si rimanda a quanto descritto per l Utente Stato aperto. Utente approvazione doppia: può creare ticket che al salvataggio non vengono direttamente inoltrati a Regesta, ma necessitano dell approvazione di due user di tipo Amministratore: l Amministratore dell Area cui il ticket si riferisce e un Amministratore IT (del plant o del gruppo). Solo dopo l approvazione di entrambi gli Amministratori il ticket viene inoltrato a Regesta. Vi possono essere diversi tipi di Utente approvazione doppia: per la categorizzazione si rimanda a quanto descritto per l Utente Stato aperto. 2.2 Stati del ticket Ogni ticket assume stati diversi in base allo step cui si trova all interno del ciclo di vita, dall inserimento fino alla chiusura dello stesso. La modifica degli stati avviene da parte dei diversi attori coinvolti nel ciclo di vita del ticket, siano essi utenti del cliente o consulenti Regesta, modificando l apposito campo come di seguito indicato, in funzione del livello autorizzativo assegnato allo user stesso. Resp. AREA: approvare Obbligatorio solo per utenti con doppio livello di approvazione Serve a richiedere l approvazione di un responsabile di funzione (es. Direttore Amministrativo) per un ticket inserito da un utente (es. impiegato ufficio amministrativo) Resp. IT: approvare Obbligatorio solo per utenti con singolo o doppio livello di approvazione

7 Pagina 7 di 13 Serve a richiedere l approvazione del responsabile IT dopo quella del responsabile di funzione (es. Direttore Amministrativo) per un ticket inserito da un utente (es. impiegato ufficio amministrativo) Da stimare Stato scelto (in genere dal responsabile IT cliente) per richiedere a Regesta una stima dell effort necessario per l evasione della richiesta, prima di procedere Stimato Stato impostato dal consulente Regesta cui è stato affidato il ticket in stato Da stimare, dopo aver popolato il campo Giorni stimati Se il ticket è in questo stato NON devono essere svolte attività sul ticket da parte di Regesta Aperto È lo stato che autorizza Regesta alla presa in carico dell attività Può rappresentare: ü lo stato iniziale del ticket, nel caso in cui sia inserito da utente non soggetto ad approvazione e non sia necessaria alcuna stima da parte di Regesta ü In altri casi può rappresentare uno stato intermedio del ticket, nei casi in cui o sia stato inserito da utente soggetto ad approvazione e un Amministratore l abbia approvato o sia necessaria una stima preliminare da parte di Regesta, Regesta l abbia stimato e l Amministratore del Cliente abbia approvato la stima stessa. Rilasciato Impostato dal consulente Regesta, responsabile dell evasione del ticket, al momento dell identificazione e risoluzione della problematica segnalata Consente di comunicare all utente che ha inserito il ticket (e ad eventuali amministratori) che la richiesta è stata evasa, al fine dell impostazione di uno degli stati successivi Validato Quando il consulente Regesta imposta il ticket in stato Rilasciato apposita comunicazione arriva all utente del cliente che ha inserito il ticket per una sua validazione L utente può portarlo in stato Validato o riportarlo in stato Aperto nel caso in cui i propri test verifichino la mancata risoluzione della problematica evidenziata inizialmente nel ticket Questo stato è opzionale Da mettere in PROD Il responsabile IT del cliente, invece di chiudere direttamente il ticket, può impostare questo stato (indicando nel campo Data produzione la data richiesta di messa in produzione) nel caso in cui, ad esempio, la soluzione della problematica comporti il trasporto in produzione di nuove parti di customizing e/o workbench o modifica di parti

8 Pagina 8 di 13 esistenti e si richieda a Regesta, da parte del cliente, che il trasporto sia effettuato in una data specifica per evitare disturbi all ambiente produttivo A questo punto è compito del consulente Regesta impostare il ticket in stato Chiuso dopo aver effettuato il trasporto in produzione Questo stato è opzionale Chiuso L impostazione di tale stato su di un ticket (da parte di uno User del cliente o di Regesta) certificherà la conclusione dei lavori per il ticket selezionato. 2.3 Invio Ai principali eventi legati alla vita di un ticket, descritti in precedenza, è associato un workflow di invio a User del Cliente e/o di Regesta. In questo modo in base al tipo di utenza che ha modificato il ticket stesso, è sempre possibile tenere automaticamente aggiornate le persone interessate (sia lato cliente che internamente a Regesta). Di seguito vengono illustrati i workflow ad oggi esistenti: Creazione di un ticket in stato Resp. AREA: approvare : al salvataggio il sistema provvede ad inviare una allo User cliente identificato come Amministratore dell Area cui il ticket si riferisce, così come all Amministratore del Plant cui il ticket si riferisce, ove esistano entrambi. Creazione/modifica di un ticket in stato Resp. IT: approvare : al salvataggio il sistema provvede ad inviare una allo User cliente identificato come Amministratore IT (del gruppo o del plant a seconda della struttura degli utenti). Creazione/modifica di un ticket in stato Da stimare : al salvataggio il sistema provvede ad inviare una a Regesta, per informare della necessità di effettuare una stima delle attività necessarie. Creazione/modifica di un ticket in stato Stimato : al salvataggio il sistema provvede ad inviare una allo/agli User Amministratore del Cliente, per informare della stima effettuata e per richiedere, in caso di accettazione, la modifica dello stato in Aperto. Creazione/modifica di un ticket in stato Aperto : al salvataggio o alla modifica di un ticket in stato Aperto (e quindi inviato a Regesta), il sistema provvede in primis ad inviare una di avvenuto invio allo user che ha aperto o modificato la richiesta. Contestualmente provvede ad inviare una informativa ai consulenti funzionali Regesta, definiti come responsabili del progetto o comunque dell area funzionale per cui tale ticket è stato aperto. Creazione/modifica di un ticket in stato Rilasciato : quando la lavorazione di un ticket (internamente a Regesta) viene funzionalmente e/o tecnicamente risolta, il sistema provvede ad inviare una mail informativa allo user che ha aperto il ticket stesso cosi che egli possa effettivamente procedere alla valutazione della soluzione ed eventualmente Validare il ticket in precedenza aperto.

9 Pagina 9 di 13 Creazione/modifica di un ticket in stato Validato : al salvataggio viene inviata una allo/agli User Amministratore del Cliente, per informare della verifica effettuata e per richiederela modifica dello stato in Chiuso o in Da mettere in produzione. Creazione/modifica di un ticket in stato Da mettere in PROD : al salvataggio viene inviata una al consulente Regesta responsabile del ticket, per informarlo della necessità di effettuare la messa in produzione nella data desiderata.

10 Pagina 10 di Comunicazioni Nella versione 2.0 del tool è stata introdotta una nuova funzionalità per gestire la comunicazione tra Cliente e Regesta durante il ciclo di vita del ticket. Ciò consente di: - Evitare la modifica del testo esteso contenuto nel campo Testo all interno della sezione Richiesta, che deve contenere la richiesta originale dell utente che ha inserito il ticket - Evitare o comunque ridurre al minimo la necessità di comunicazioni riferite al ticket e slegate dal tool tra utenti o amministratori del cliente e consulenti Regesta - Tracciare in modalità simil chat la storia delle comunicazioni, conservando tutto in un unico nuovo campo, denominato Altre informazioni e contenuto nella sezione Chiusura. Il campo sarà visibile solo dopo aver salvato il ticket originario, nel momento in cui utenti o amministratori del cliente o consulenti Regesta entreranno in modifica nel ticket stesso.

11 Pagina 11 di 13 3 Accesso al portale L accesso alle funzioni del portale di assistenza ( è regolato da un necessario controllo. Dopo l iniziale parametrizzazione (a carico di Regesta) ogni utente potrà accedere al portale digitando la propria user (solitamente una di riferimento) e la password ad essa associata. 4 Visualizzazione ticket Una volta validato l accesso, l utente avrà la possibilità di visualizzare tutti i ticket aperti e filtrati in base alle autorizzazioni definite. Cliccando su per uno qualsiasi dei ticket visualizzati, l utente potrà accederne il dettaglio e visualizzarne o modificarne i contenuti, in base alle proprie autorizzazioni.

12 Pagina 12 di 13 5 Apertura nuovo ticket La creazione di un nuovo ticket, potrà sempre essere effettuata dalla main screen del portale di assistenza. Premendo l icona dedicata, l utente accederà alla schermata di creazione nuovo ticket, dove, in base ai criteri autorizzativi impostati, potrà operare la creazione o la modifica di un ticket secondo le procedure descritte in precedenza Le informazioni anagrafiche quali: Utente, Cliente, Commessa ed Area, se configurate nell anagrafica dello User, vengono automaticamente compilate dal sistema, cosi da facilitare l inserimento e la compilazione dell anagrafica ticket da parte dell utente. La versione 2.0 del tool contiene un nuovo campo di tipo flag, denominato Bug fixing e contenuto nella sezione Richiesta, che serve ad indentificare richieste relative a bug individuati dal cliente in relazione a sviluppi o customizzazioni effettuate da Regesta. Tale flag potrà essere

13 Pagina 13 di 13 modificato sia da user e amministratori del cliente che da consulenti Regesta, nel caso in cui l analisi del problema consenta poi di verificare che tale etichetta non era corretta. L utilità di tale flag si manifesta soprattutto in sede di fatturazione, per consentire sia al Cliente che a Regesta l identificazione univoca dei ticket che non devono essere soggetti a fatturazione. 5.1 Gestione allegati La versione 2.0 del tool ha modificato la gestione degli allegati: nella versione precedente era consentito l upload di due allegati, ora tale limite è stato superato, consentendo l upload di un numero illimitato di allegati. In sede di inserimento del ticket è consentito l upload di un solo allegato: Dopo il salvataggio è possibile effettuare l upload di altri allegati in due modalità: - Dalla schermata principale di visualizzazione della lista ticket cliccando sull icona : - Dalla schermata di dettaglio del ticket, sempre cliccando sull icona :