Příručka řešitele CA Service Desk Manager

Transkript

1 Příručka řešitele CA Service Desk Manager - Datum: , Projekt Implementace CA do SZR

2 Obsah OBSAH... 2 HISTORIE DOKUMENTU ÚVOD OBECNÝ POPIS FUNKCE SERVICE DESK Základní povinnosti: Organizační schéma SD Popis rolí SD: CA SERVICE DESK MANAGER V SZR Dostupné role pro řešitele ZÁKLADY OVLÁDÁNÍ SYSTÉMU Přístup do aplikace Service Desk Manager Přístup do produkčního SDM: Přístup do testovacího systému SDM: Založení požadavku V roli uživatele V roli operátora/řešitele Analýza a řešení požadavku Převzetí požadavku do řešení Vyžádání součinnosti Eskalace požadavku Vyřešení požadavku Vypořádání tiketů Informovanost uživatele Reklamace vyřešeného požadavku/incidentu Průzkum spokojenosti uživatelů/zákazníků s řešením požadavků/incidentů ová komunikace Rozhraní řešitele Úvodní obrazovka rozhraní řešitele Scoreboard Použití filtrů Editace údajů Standardní editační formulář Další možnosti změn údajů pomocí předdefinovaných funkcí Editace přímo v seznamu Vytváření vazeb Strana 2 / 81

3 Přiřazení konfigurační položky k záznamu Vazby mezi Requesty, Incidenty, Change Ordery Práce se šablonou Vykázání odpracované doby Využití konfigurační a znalostní databáze PRÁCE SE ZNALOSTNÍ DATABÁZÍ Vyhledávání informací ve znalostní databázi Vyhledávání přímo z prostředí Znalostní databáze Vyhledávání v kontextu konkrétního tiketu Vložení řešení požadavku do znalostní databáze PUBLIKOVÁNÍ INFORMACÍ DO OBLASTI ANNOUNCEMENTS TISKOVÉ VÝSTUPY POSTUP ŘEŠENÍ POŽADAVKU Požadavek zadaný neověřeným uživatelem - Guest Požadavek zadaný ověřeným uživatelem/řešitelem Sledování doby odezvy Stavy požadavku v průběhu řešení Požadavky vyžadující spolupráci od uživatele nebo jiné řešitelské skupiny Odmítnutí požadavku ve stavu V řešení POSTUP ŘEŠENÍ INCIDENTU Nastavení Service Type STIMSZR Stavy incidentu v průběhu řešení SCOREBOARD Definice Scoreboardu pro Operátor L Definice Scoreboardu pro OperátorL Definice Scoreboardu pro Řešitel Strana 3 / 81

4 Historie dokumentu Verze Datum Autor Popis Petr Poplstein Petr Poplstein, Marek Švejda Vytvoření draftu dokumentu Petr Poplstein Zapracování připomínek z Petr Poplstein Zapracované připomínky z Aktualizace Petr Poplstein Aktualizace Petr Poplstein Aktualizace Petr Poplstein Aktualizace, zapracování připomínek Petr Poplstein Aktualizace kapitoly Igor Jeřábek Vložení kap. 8.5 a 8.6 Strana 4 / 81

5 1. Úvod Tento dokument popisuje práci řešitele v systému CA Service Desk Manager (dále SDM), který slouží jako technologická podpora jednotného kontaktního místa pro uživatele služeb SZR a týmu podpory dodavatele služeb (dále jen SD). Systém řešiteli umožňuje přebírat požadavky od uživatelů, evidovat aktivity spojené s jejich řešením, komunikovat s uživateli a poskytovat jim informace o všech důležitých provozních stavech dodávaných služeb. Použité zkratky a názvosloví Service Desk (SD) Service Desk Manager (SDM) Služba Servisní požadavek (Request) Incident SZR Uživatel Provozní doba Mimoprovozní doba (MPD) KIVS JIP/KAAS Problém Požadavek na změnu (Change Order) Oddělení provádějící prvotní analýzy, řešící a koordinující řešení incidentů a servisních požadavků vztahujících se k ZR SW produkt pro evidenci a řešení incidentů/požadavků Viz seznam egon služeb na Formální žádost uživatele o službu zadaná v Service Deskovém nástroji (SDM) Provozní stav, kdy došlo k neplánovanému přerušení garantované služby IT nebo snížení její kvality Správa základních registrů je správní úřad, který je podřízen Ministerstvu vnitra a je správcem informačního systému základních registrů Osoba určená Správcem AIS (Administrátor AIS) nebo Uživatelským OVM pro komunikaci požadavků na ISZR se SZR prostřednictvím Help Desku. Je čas, ve kterém SD SZR poskytuje uživatelskou podporu. Pracovní dny 8:00-18:00 Je čas, ve kterém SD SZR poskytuje pouze nástroj pro řešení požadavků SDM. Doba pondělí-pátek 18:00-8:00, Soboty, Neděle, svátky. Komunikační infrastruktura veřejné správy Jednotný identitní prostor, zabezpečená adresářová služba obsahující údaje pro autentizaci a autorizaci Uživatelů. Webové služby pro autentizaci uživatelů do AIS a pro správu dat uložených v JIP. Společná příčina jednoho, nebo více incidentů. Problémy jsou evidovány a řešeny v SDM jako záznamy typu problém. Formální žádost o změnu, která je zaevidována, posuzována a řešena v rámci řešení záznamů typu Change Order. Strana 5 / 81

6 2. Obecný popis funkce Service Desk Service Desk (SD) představuje centrální kontaktní místo mezi poskytovatelem služeb a uživateli služeb. 2.1 Základní povinnosti: zaznamenání všech servisních požadavků od uživatelů a jejich odpovídající vyřešení zaznamenání všech incidentů a snaha o jejich řešení, popřípadě informování specializovaných týmů podpory či dodavatelů, kteří se pokusí incident analyzovat a vyřešit monitorování průběhu řešení incidentu, požadavku průběžné informování uživatelů o stavu řešení incidentu, požadavku, o možných řešeních, o případných náhradních opatřeních vytváření statistických zpráv pro potřeby managementu Důraz je kladen zejména na: Zajištění funkce jediného kontaktního místa Odpovídající dostupnost operátorů a řešitelů Adekvátní rychlost odezvy na požadavky Profesionalitu komunikace Osoby, které mají svojí roli definovanou v rámci funkce SD, se účastní plnění svých úkolů v rámci procesů řízení požadavků a incidentů dle popisu aktivit těchto procesů. 2.2 Organizační schéma SD Service Desk Manager Operátoři Řešitelé 2.3 Popis rolí SD: Service Desk Manager Service Desk Manager je zodpovědný za: koordinaci všech aktivit, které jsou prováděny na Service Desku v rámci definovaných procesů řešení incidentů/požadavků na službu řízení rolí, které mu v rámci organizační struktury podléhají. informování vedení o významných událostech, které mají dopad na poskytované služby vystupuje jako eskalační bod při řešení požadavků a incidentů Strana 6 / 81

7 Operátoři Úloha operátora spočívá v analýze požadavku a jeho vyřešení v souladu s existujícími smlouvami. Pokud nebylo možné požadavek vyřešit, v případné eskalaci, respektive přidělení požadavku skupině řešitelů nebo dodavateli, který bude provádět další analýzu a řešení požadavku. Operátoři se dělí dle odbornosti a prováděných aktivit na: Řešitelé Operátoři L1: zajišťují zpracování požadavků zadaných pomocí webového rozhraní, prvotní analýzu a řešení přidělených požadavků v případě, že se jedná o předem známý, opakovaný postup řešení, nebo je možno použít existující znalostní dokument u všech zadaných požadavků provádí kontrolu přiřazení kategorie, naléhavosti, úplnost poskytnutých informací eskalace na Operátora L2, pokud nejsou schopni požadavek vyřešit Operátoři L2: u přidělených požadavků provádí kontrolu přiřazení kategorie, priority, úplnost poskytnutých informací analýzu a řešení požadavku, který spadá do jejich kompetence zakládání podřízených požadavků, incidentů a souvisejících incidentů, problémů a požadavků na změnu eskalace na Řešitele dodavatele vytváření záznamů do znalostní databáze vytváření šablon požadavků Úloha řešitele spočívá v analýze požadavku, incidentu nebo problému a jeho vyřešení v souladu s existujícími smlouvami. Pokud je vyžadována součinnost dodavatele, je tato skutečnost zaznamenána u požadavku (popisem, přílohou, přiřazeným řešitelem apod.). Veškeré informace musí být evidovány u požadavku ve formě příloh, či zadaných aktivit. Role Reporter je role řešitele, který má oprávnění zpracovávat veškeré tikety řešené organizací, jíž je členem. Má přístup na záložku Reports, kde jsou pro něho dostupné reporty pro vyhodnocení dodávaných služeb. Jeho zodpovědností je provádění Vypořádání tiketů za období, které uzavírá. Popis postupu vypořádání je uveden v kapitole 4.5 Strana 7 / 81

8 3. CA Service Desk Manager v SZR Lokalizované do českého jazyka je kompletní prostředí uživatelů včetně příručky uživatele, dostupné z menu Nápověda rozhraní Uživatele nebo Guest a provozní číselníky. Role používané v systému SDM: Guest (anonymní uživatel) Uživatel (zaměstnanec, správce AIS) Operátor L1 (zaměstnanec SZR - řeší pouze požadavky) Operátor L2 (zaměstnanec SZR - řeší všechny typy tiketů) Řešitel (zaměstnanec SZR nebo externista - vidí požadavky kde je řešitelem, a požadavky kde je řešitelem skupina, jíž je členem) Reporter (řešitel, který má přístup k části Reports) Schvalovatel (zaměstnanec SZR - řešitel s oprávněním schvalovat požadavky a měnit request area) Řešitel problémů Change Manager Knowledge Manager Administrator Oprávnění k úpravě provozních číselníků a Scoreboradů jednotlivých rolí má pouze Administrátor SDM. 3.1 Dostupné role pro řešitele Řešitel po přihlášení do systému získává přístup v systémových rolích Uživatel a Řešitel, Operátoři L1 a L2 mají své odpovídající role. Zde nejde o role z hlediska procesního, ale o role nastavené v rámci systému definující vzhled formulářů, funkčnost aplikace, scoreboard a přístupová oprávnění. Role uživatele umožňuje řešiteli zadávat požadavky na službu, vázané ke svému kontaktu a sledovat průběh jejich řešení. Upravovat kontaktní údaje u svého kontaktu při zakládání požadavku (výběr kategorie Z) Změna Kontaktu). Podrobný popis je obsahem příručky uživatele, dostupné z rozhraní Uživatele z odkazu Nápověda. Role operátora/řešitele umožňuje provádění následujících činností: Přebírat požadavky (Requests) pomocí aktivity Transfer Menu Activities Editace údajů v záznamech (záznamem může být požadavek, incident, problém nebo požadavek na změnu) Práce se znalostní databází, vyhledávání řešení již známých záznamů a předávání nových řešení do databáze ve formě návrhu Kontrola, případně změna přidělené kategorie, priority, skupiny řešitelů, řešitele a dalších atributů záznamu liší se pro Operátory a Řešitele Změna stavu záznamu na základě průběhu jeho řešení Eskalace řešení jednotlivých záznamů pomocí aktivity Escalate menu Activities. Je využívána při změně řešitelské skupiny mezi Operátorem L1 a L2. V ostatních případech, zvláště pokud je nutno zajistit přiřazení nového Service Type, nové skupiny a změnu stavu požadavku na Zadaný, je nutno využít Editaci Request Area operátorem. Strana 8 / 81

9 4. Základy ovládání systému Tato kapitola obsahuje popis základů ovládání systému. V dalších částech dokumentu jsou v rámci metodiky popsány konkrétní příklady použití zde zmiňovaných činností. 4.1 Přístup do aplikace Service Desk Manager Systém CA SDM je dostupný na několika URL, jejichž použití se liší tím, odkud uživatel k systému přistupuje a zda má, nebo nemá svůj účet v prostředí SZR. Možné varianty jsou: Přístup do produkčního SDM: 1. Uživatelé s účtem v AD - používá se primárně pro řešitele SZR: a. Z internetu: b. Z KIVS: c. Interně: 2. Uživatelé s účtem v JIP: a. Z internetu: b. Z KIVS: Strana 9 / 81

10 c. Interně: nelze Pro plně kvalifikovanou podporu je nutná registrace v JIP a nutná podmínka nastavení role ve Správě dat. Práva a roli Přístupová role (Service desk manager Správy základních Správa základních registrů) pro autorizovaný a autentizovaný přístup do CA Service Desk Manageru, Vám nastaví Váš lokální administrátor. Uživatelé přistupující do systému mohou využít svého existujícího účtu v JIP. V tom případě je možno pro autentizaci použít jak přihlášení jménem a heslem, tak pomocí osobního certifikátu: nebo přihlášení pomocí OTP: Příslušnou variantu si uživatel zvolí výběrem z dostupných možností v dolní části přihlašovací obrazovky. Pro přístup do systému uživatel používá internetový prohlížeč. Podporované jsou následující produkty a verze: Microsoft Internet Explorer 8 až 10 Mozilla Firefox ESR 10 a vyšší Google Chrome a vyšší Strana 10 / 81

11 Apple Safari 5.1 a vyšší Přístup do testovacího systému SDM: 1. Uživatelé s účtem v AD: a. Z internetu: b. Z KIVS: c. Interně: 2. Uživatelé s účtem v JIP: a. Z internetu: b. Z KIVS: c. Interně: nelze Pro korektní fungování Service Desku je nutno zajistit komunikaci se serverem na portech 443 a 8443 a důvěřovat certifikátům, které ověřují komunikaci se servery Service Desk Manager SZR: Strana 11 / 81

12 4.2 Založení požadavku V roli uživatele V sekci Dostupné akce zvolte položku Vytvořit nový požadavek Obrazovka založení nového požadavku: Nahlásil Při vytváření požadavku je automaticky vyplněno pole Nahlásil podle evidovaných údajů přihlášeného uživatele. Toto pole není možno měnit. Jméno, Příjmení, Telefonní číslo mobil, ová adresa, Organizace Tato pole jsou předvyplněna podle evidovaných údajů přihlášeného uživatele. Pole je možno při zakládání požadavku upravit. Touto úpravou uživatel provede aktualizaci kontaktních informací v příslušných polích u svého kontaktu vedeného v SDM. Tyto údaje jsou následně využity v systému pro další aktivity (notifikace, SMS apod.) Strana 12 / 81

13 Pokud v poli Organizace uživatel nenalezne svoji organizaci, vybere položku Obecná organizace a do popisu požadavku uvede jméno organizace, za kterou požadavek v systému zadává. Operátoři Service Desku zajistít doplnění této organizace do číselníku. Naléhavost Uživatel může upravit předvyplněnou hodnotu v poli Naléhavost výběrem z číselníku dostupných hodnot. Tento údaj vyjadřuje naléhavost, s jakou uživatel řešení vyžaduje. 1 - systém je nefunkční nebo pro uživatele nedostupný, zařízení vadné, akutní požadavek, problém z pohledu uživatele vyžaduje okamžité řešení (např. zamezení ztráty dat, či úniku informací, zajištění důležitého jednání či obchodní schůzky, odjezd na služební cestu) 2 - funkčnost systému nebo dostupnost pro uživatele je omezena, zařízení je poškozené, spěšný požadavek. 3 - na systému se vyskytuje problém, který zásadním způsobem neomezuje funkčnost systému, zařízení je poškozené, běžný požadavek. 4 - uživatel má evidovaný požadavek, není vyžadováno okamžité řešení, problém je možno odstranit v průběhu běžné pracovní doby. Lze nahradit provizorním řešením. 5 - uživatel má evidovaný požadavek. Termín jeho vyřešení není z jeho pohledu významný a řešení nechává na možnostech poskytovatele služeb. Pole, jejichž vyplnění je povinné jsou označena textem (vyžadováno) a systém nedovolí uložení požadavku bez jejich vyplnění. Při pokusu o uložení bez vyplnění povinných polí, jsou tato označena červeným rámečkem a popisem v záhlaví okna: Kompletní popis práce v rozhraní uživatele je uveden v dokumentu Příručka uživatele, která je dostupná z odkazu Nápověda v rozhraní role Uživatel a Guest. Strana 13 / 81

14 4.2.2 V roli operátora/řešitele V menu File zvolíte položku New Request: V zobrazeném formuláři pro založení požadavku je nutno vyplnit všechna pole, která jsou povinná - označena hvězdičkou. Affected End User uživatel, který požadavek hlásí Request Area oblast požadavku zadaná výběrem z číselníku předdefinovaných hodnot. Tato položka definuje skupinu řešitelů, SLA a doplňující údaje, které jsou při výběru položky z číselníku k požadavku doplněny Urgence informace, jak uživatel spěchá na řešení, v případě založení požadavku s urgencí 1, odejde notifikace řešitelům o založení i prostřednictvím SMS Summary krátký popis požadavku Description podrobný popis požadavku Strana 14 / 81

15 Na záložce 1. Additional Information sekce Properties mohou být u některých Request Area další povinné údaje, které slouží k upřesnění zadávaného požadavku a bez jejich vyplnění požadavek není možno uložit Záznam se uloží pomocí tlačítka Save. Po uložení požadavku systém odešle notifikace o založení požadavku na skupiny přiřazených řešitelů: a uživatele, který je uveden v poli Affected End User: Strana 15 / 81

16 4.3 Analýza a řešení požadavku U přidělených požadavků se snaží operátor/řešitel najít příčinu a řešení, popřípadě využít dočasného řešení. K dispozici má znalostní databázi s popisem doporučených postupů a typických řešení, šablony požadavků s předvyplněným obsahem vybraných polí, konfigurační databázi s informacemi o jednotlivých konfiguračních položkách a historii požadavků uživatele. Veškeré činnosti prováděné při analýze a řešení by měl zaznamenat v systému pomocí menu Activities pro další vyhodnocení Převzetí požadavku do řešení Řešitel si vyhledá požadavek. Využije buď připravené dotazy Scoreboard, nebo seznam z menu Search - Requests: Detail požadavku otevře v novém okně kliknutím na číslo požadavku: Strana 16 / 81

17 V případě, že operátor/řešitel bude požadavek řešit, pomocí aktivity Transfer z Menu Activities: vyplní do pole New Assignee svůj kontakt: Strana 17 / 81

18 Může doplnit k aktivitě: popis pole User Description čas, který spotřeboval na provedení aktivity Odpracovaná doba (je nutno dodržet vyžadovaný formát) záznam uloží pomocí tlačítka Save. Od této chvíle je brán, jako řešitel požadavku. Systém automaticky nastaví stav požadavku na hodnotu V řešení Vyžádání součinnosti Pokud kterákoliv z rolí na tiketu potřebuje součinnost někoho dalšího, může využít těchto možností s notifikací druhé strany o požadování součinnosti: Log comment oboustranně mezi řešitelem a zadavatelem Manuální notifikace - z SD nebo mimo SD na příjemce, ručně zpracovat pokud nesplňuje náležitosti pro zpracování odpovědi na manuální notifikaci Update status řešitele na "Čeká na součinnost" ze stavu "V řešení", provedení součinnosti je nezbytné Uživatelem potvrdit vložením komentáře o poskytnutí součinnosti a následný update status Řešitelem do "Součinnost poskytnuta", kdy se tiket vrátí do "V řešení", případné lhůty nebo SLA nejsou po dobu součinnosti zastavovány, lhůty SLA řeší pouze kategorizace tiketů (Request/Incident Area) Eskalace požadavku V případě, že Operátoři požadavek nebudou řešit, mohou požadavek eskalovat = změnit řešitelskou skupinu. Eskalace je prováděna pouze při předávání požadavku/incidentu mezi operátory (L1-L2). Pro potřeby předávání požadavku/incidentu na řešitele a jako preferovaná varianta i mezi operátory, je nutno změnit pole Request/Incident Area. Tím je zajištěno, že se požadavek po přidělení na novu skupinu řešitelů Strana 18 / 81

19 nastaví do stavu Zadaný, začne se sledovat doba reakce a vyřešení a odebere se původní řešitel, pokud byl přidělen. Strana 19 / 81

20 Komunikační schéma pro založení, řešení a vyřešení požadavku/incidentu Uživatel Telefon SDM telefon SDM Operátor L1 Telefon SDM Operátor L2 ,Tel., SDM Řešitel - dodavatel Uživatel provádí nahlášení požadavku vždy pouze na SD výše definovanými způsoby SD funguje jako komunikační spojení mezi uživatelem, pracovníky 2. a vyšší úrovně podpory, externími dodavateli služeb a ostatními účastníky procesu Uživatel nekontaktuje přímo pracovníky 2. a vyšší úrovně podpory, ani externí dodavatele, pokud není požádán o poskytnutí součinnosti, nebo se nejedná o řešení v režimu MPD Řešitelé 2. a vyšší úrovně podpory komunikují přímo s uživatelem pouze v těch případech, kdy je vyžadováno operativní řešení požadavku, typicky MPD S dodavateli komunikují pouze Operátoři L2 úrovně Při vyřešení požadavku obdrží uživatel informaci od SDM formou u a může si průběh řešení i výsledek řešení ověřit v SDM. 4.4 Vyřešení požadavku Pokud řešitel požadavek vyřešil, musí vyplnit popis řešení požadavku, pomocí aktivity v Menu Activities položka Solution. V případě, že považuje zvolené řešení za užitečné, odešle toto řešení jako návrh pomocí Save and Submit Knowledge do znalostní databáze. Následně změní stav požadavku na Vyřešeno Strana 20 / 81

21 Po změně stavu požadavku na Vyřešeno odejde notifikace o vyřešení požadavku na kontakt uvedený v poli Affected End User : 4.5 Vypořádání tiketů Vypořádání tiketů provádí zástupce řešitelů v roli Reporter. Tato role má dostupné všechny záznamy, které jsou v systému SDM evidovány na organizaci Reportera. Vypořádáním se myslí: doplnění polí Smlouva, Katalogový list, Období kontrola údajů v polích Předpokládaná a Skutečná doba odezvy a vyřešení kontrola a doplnění odpracované doby na jednotlivých tiketech Strana 21 / 81

22 4.6 Informovanost uživatele Uživatel sleduje průběh řešení požadavku přímo v SDM. O založení, průběhu řešení a vyřešení svých požadavků je uživatel informován em. Každému uživateli je přidělen účet do SDM, ve kterém má přístupné informace o svých požadavcích Zobrazení mých požadavků ty které jsou stále v řešení otevřené požadavky, požadavků u kterých je vyžadována součinnost požadavků v součinnosti, vyřešených požadavcích vyřešené požadavky a uzavřených. SDM poskytuje uživatelům, v části Oznámení, také základní informace o provozních stavech odstávky, hromadné výpadky, změny, release apod. Strana 22 / 81

23 Pokud je v průběhu řešení vyžadována součinnost, řešitel může využít následující možnosti: Komunikace mimo SDM: průběh a výsledky komunikace je možno doplnit k požadavku ve formě komentáře, přílohy, doplnění popisu. Komunikace z prostředí SDM: pomocí o Manual Notify z menu Activities odeslat na vybrané adresy s popisem požadavku na součinnost. Tento postup je možno využít při informování uživatele o všech podstatných změnách v řešení požadavku. Veškeré podrobnosti komunikace jsou logovány v historii požadavku. Případné odpovědi uživatele mohou být, při zachování předmětu zprávy, automaticky zpracovány a přiloženy k požadavku. o Log Comment z menu Activities přiložení komentáře k požadavku O všech podstatných změnách v průběhu řešení požadavku je uživatel informován ovými notifikacemi. Požadavky zadané pod účtem Guest pole Affected End User obsahuje hodnotu System Anonymous nejsou notifikovány a zadavatel nemá možnost sledovat průběh jejich řešení, řešení rozporovat, přidávat komentáře atd. V případě, že se uživatel do SDM zaregistruje až po zadání požadavku v roli Guest, řešitel vyplní do pole Affected End User nově vytvořený kontakt uživatele, aby další zpracování požadavku probíhalo jako u standardního uživatele Reklamace vyřešeného požadavku/incidentu Uživatel/zákazník může po vyřešení požadavku/incidentu provést reklamaci řešení, pokud s ním nesouhlasí. Termín pro reklamaci je stanoven na 5 pracovních dní od okamžiku vyřešení požadavku = změna stavu na vyřešeno a notifikace žadateli o vyřešení požadavku. Postup při vyřešení požadavku je popsán v kapitole 4.4. Poté je požadavek převeden do stavu Uzavřený a uživatel musí založit požadavek nový. Toto může provést kontaktováním SD pomocí webového rozhraní, nebo telefonicky. Při reklamaci požadavku pomocí vložení komentáře, nebo odpovědí na doručenou notifikaci o vyřešení, obdrží tuto informaci poslední řešitel. Pokud je reklamace oprávněná, musí řešitel pokračovat v řešení požadavku. Operátor u oprávněné reklamace změní stav požadavku na Reklamace, vyplní povinné pole User Description odůvodněním reklamace. Systém automaticky vrátí požadavek dostavu V řešení a řešitel pokračuje ve standardním řešení přiděleného požadavku. Strana 23 / 81

24 4.6.2 Průzkum spokojenosti uživatelů/zákazníků s řešením požadavků/incidentů Uživatelé/zákazníci jsou telefonicky dotazování na hodnocení spojené s řešením jejich požadavku. Na základě stanovených dotazů je zjišťována spokojenost s dobou odezvy na požadavek, rychlostí řešení, přístupem technika, hodnocení celkového dojmu s řešením. Tyto informace jsou předávány Service desk managerovi, který provádí jejich analýzu a zajišťuje návrh opatření. Při uzavírání incidentu je uživatel dotazován em na spokojenost s poskytovanou službou SD ová komunikace Systém odesílá při řešení tiketů notifikace o významných událostech. Adresáti notifikací mohou na tyto notifikace odpovídat. Jejich odpovědi jsou zpracovány a přiloženy k tiketům. Pro korektní zpracování je nutno dodržet následující zásady: Obdržíte-li notifikace z titulu AEU, řešitele nebo řešitele ve skupině a bez zásahu do předmětu u provedete RE: při jakékoli editaci těla u a přidání cc, bude Vaše odpověď vložena jako komentář do tiketu včetně vložení příloh z u, o těchto aktivitách je notifikován AEU a řešitel, jsou zapsány v Activity logu, Pozor - pokud mezi doručením notifikace, na kterou jako řešitel odpovídáte, nebo ji k odpovědi využijete, dojde ke změně přidělené skupiny na tiketu, nedojde ke zpracování Vaší odpovědi zpracování či nezpracování Vašeho u budete informováni ovou notifikací nezasahovat do předmětu zprávy, v těle neponechávat předchozí komunikace (mazat) musíte odpovídat z u uvedeného u Vašeho kontaktu Strana 24 / 81

25 4.8 Rozhraní řešitele Úvodní obrazovka rozhraní řešitele Obrazovka rozhraní řešitele je rozdělena do tří bloků: a) Záhlaví, kde je k dispozici nástroj pro vyhledávání informací v systému, informace o přihlášeném uživateli s volbou log out a možnost přepínání uživatele v rolích, které jsou uživateli přiděleny. V záhlaví se zobrazují záložky, které umožňují rychlý přechod na konkrétní části systému: Service Desk práce se záznamy Quick Profile rychlý přehled Knowledge práce ve znalostní databázi b) Levý sloupec, kde je umístěn tzv. Scoreboard c) Pravý sloupec, kde jsou zobrazena aktuální oznámení nebo podrobnosti o položkách zvolených ve Scoreboardu Scoreboard 1) Obsahuje v administrátorem definované hierarchické struktuře databázové dotazy, které slouží pro zobrazení seznamu informací požadovaného typu. Obsah Scoreboardu se liší pro každou roli a zohledňuje přístupová oprávnění uživatele v systému. Strana 25 / 81

26 2) Položky začínající My odkazují na seznam záznamů, které jsou přiděleny přihlášenému řešiteli. 3) Číslo uvedené v závorce za jednotlivými databázovými dotazy informuje řešitele o počtu záznamů, které danému dotazu aktuálně odpovídají. 4) Po kliknutí na příslušný databázový dotaz (například My Incidents) se v pravé části okna zobrazí seznam všech vyhovujících záznamů (v našem případě seznam všech incidentů, kde je jako řešitel přiřazen aktuálně přihlášený uživatel). 5) Na následujícím obrázku je obdobným způsobem zobrazen obsah kontejneru Incidents, který obsahuje podkontejnery Assigned a dále roztříděné incidenty podle Priority. Strana 26 / 81

27 6) Po kliknutí na databázový dotaz se v pravé části okna zobrazí seznam všech záznamů (incidentů), které odpovídají zadanému dotazu. Strana 27 / 81

28 7) Po kliknutí na příslušnou položku v seznamu, se zobrazí formulář s podrobnými informacemi o daném záznamu. Pro každou roli je připravena specifická struktura Scoreboardu, která umožňuje přístup k záznamům, které má řešitel v dané roli a skupině dostupné Použití filtrů 1) Řešitel má možnost aplikovat na zobrazený seznam uživatelský filtr. 2) Filtr je možné definovat po stisknutí tlačítka Show Filter. Strana 28 / 81

29 3) Kritéria filtru lze nastavit na základě většiny informací, které jsou v záznamu standardně obsaženy (například hodnota aktuálního stavu, jméno řešitele, jméno řešitelské skupiny, priorita atd.). Viz obrázek níže. 4) U položek jejichž obsah vychází z číselníku, lze požadovanou hodnotu pro definici filtru vybrat kliknutím na symbol, nebo nadpis pole. Možné varianty jsou: 1, Seznam dostupných hodnot rozbalovací číselník 2, Strom hodnot hierarchie Request area 3, Seznam položek seznam kontaktů, který je možno také filtrovat pro snadné nalezení odpovídající hodnoty Strana 29 / 81

30 5) Další obrázek ukazuje příklad číselníku řešitelů, který se zobrazil po kliknutí na záhlaví pole Assignee v definici filtru a stisknutí tlačítka Search. 6) Kliknutím na požadovaný řádek se zvolená hodnota automaticky zapíše do aktuálně nastavovaného pole filtru. 7) Pokud je číselník příliš dlouhý, lze i na něj aplikovat filtr, jehož definice probíhá podle stejných pravidel. Klikněte na tlačítko Show Filter, zadejte do vybraných polí náležité hodnoty a tlačítkem Search filtr aplikujte. Vyhledávání v Service Desku V prostředí Service Desku je možné při vyhledávání informací (kontakty, skupiny atd.) využít zástupný znak "%", který lze použít před i za slovem např. admin%, %sitel, %vicede%. Strana 30 / 81

31 Detailní popis všech možností vyhledávání a syntaxe použitelná v poli Additional Search Argument je uvedena v originální dokumentaci k produktu, která je dostupná z Menu Help. Strana 31 / 81

32 4.9 Editace údajů Údaje záznamu je možné editovat více způsoby Standardní editační formulář 1) Standardní editační formulář otevřeme kliknutím na požadovaný záznam a volbou tlačítka Edit jak je ukázáno na následujících obrázcích. Strana 32 / 81

33 Po ukončení editace je nutno změny uložit volbou tlačítka Save. Aby byl dodržen princip řešení požadavků/incidentů, jsou pro některé role vybraná pole pouze pro čtení a jejich úprava je prováděna buď systémem automaticky, nebo je možná pouze pomocí předdefinovaných funkcí z Menu Activities (převzetí požadavku k řešení pomocí aktivity Transfer, Eskalace požadavku pomocí aktivity Escalate, vybrané změny stavu pomocí aktivity Update Status, atd.). Možnosti řešitele a operátora se v dostupných aktivitách liší Další možnosti změn údajů pomocí předdefinovaných funkcí 1) V menu Activities ve formuláři záznamu je k dispozici řada funkcí, které zjednodušují realizaci nejčastěji prováděných aktualizací. Strana 33 / 81

34 K dispozici jsou tyto funkce: Update status - umožňuje měnit stavu v průběhu řešení požadavku, některé stavy není možno nastavit manuálně, jsou nastaveny systémem automaticky. Stav Ke schválení po založení požadavku s danou Request Area a stav V řešení po vyplnění pole Assignee přiřazení řešitele pomocí aktivity Transfer Callback - umožňuje přidat do Activity logu daného servisního případu informaci o tom, že zákazník byl telefonicky kontaktován Research - umožňuje přidat do Activity logu daného servisního případu informaci o tom, že byl proveden výzkum vedoucí k vyřešení případu, popis provedených aktivit atd. Log Comment - Umožňuje přidat obecnou položku do Activity Logu využívá se pro vkládání komentářů od uživatelů a řešitelů, případně informací ze zpracovaných ů Solution využívá se k popisu řešení požadavku, které se zobrazuje na záložce Knowledge Management, sekce Solutions. Zde se soustřeďují všechny informace o zvoleném řešení, které je dále možno publikovat do znalostní databáze, případně o využitých znalostních dokumentech Transfer - využívá se k převzetí požadavku řešitelem do řešení provede se výběrem kontaktu přihlášeného řešitele ze seznamu. Od okamžiku převzetí do řešení je řešitel zodpovědný za další řešení požadavku. Pokud není schopen požadavek vyřešit změnou stavu na Odmítnutý, předá ho zpět Operátorům, kteří zajistí jeho nové přidělení. Pokud operátor/řešitel požadavek převzal k řešení, je ve stavu V řešení, není možno ho odmítnout a je nutno ho budˇ Vyřešit, nebo Zrušit vždy pomocí aktivity Update Status a výběrem odpovídajícího stavu. Escalate využívá se pro změnu skupiny řešitelů, bez nutnosti změny assignee, změny stavu požadavku na Zadaný a restartu Service Type. Tato položka je dostupná pouze pro Operátory. Manual Notify - Umožňuje vytvořit manuální ovou notifikaci V případě, že chcete odeslat notifikaci pomocí SMS, je nutno upravit pole Urgency na hodnotu Emergency a pole Preferred Method na hodnotu Notification. Notifikace odejde na zadané tel. číslo u vybraných kontaktů. Pro korektní doručení musí mít kontakt uvedeno správné číslo mobilního telefonu. Strana 34 / 81

35 Tyto aktivity umožňují: definovat, zda se jedná o aktivitu Interní (záznam o jejím provedení uživatel nevidí) - položka Internal? zadat čas, který řešitel strávil na jejím provedení (evidence odpracované doby) položka Odpracovaná doba je nutno dodržet uvedený formát. Reporting umožnuje zobrazit výkaz práce jednotlivých řešitelů. přiložit popis prováděné aktivity položka User Description. Pro některé aktivity je vyplnění pole Description povinné Strana 35 / 81

36 Příklad aktivity zadávané fukcemi z menu Activities vložení komentáře (Log Comment): Internal aktivity označené Internal nejsou u požadavku zobrazeny vybraným rolím Uživatelům Date of Activity datum a čas provedení aktivity Odpracovaná doba pole pro evidenci odpracované doby. Je nutno dodržet uvedený formát. Při editaci je možno zadat část hodnoty (např. 1:30 pro zadání jedna hodina 30 minu.) a pomocí tabulátoru nebo klávesy Enter nechat systém doplnit. User Description pole pro popis k prováděné aktivitě. Některé aktivity mají popis povinný toto je avizováno hvězdičkou u názvu pole, a bez vyplnění pole není možno záznam uložit. Záložka 2. Logs, sekce Activities: Strana 36 / 81

37 Log zobrazuje: Seznam všech podstatných úkonů, které byly nad konkrétním servisním případem v rámci jeho životního cyklu provedeny. Součástí každého zápisu je obvykle popis operace, datum a čas operace, jméno řešitele, který operaci provedl a doba trvání operace. Většina operací je zapsána do logu automaticky. Řešitel má možnost přidat položku Activity Logu i manuálně (např. v případě funkcí Callback, Research nebo Log Comment). Tyto informace slouží k vyhodnocování činnosti servisního centra a také jako informace pro řešitele při řešení servisního případu. Strana 37 / 81

38 4.9.3 Editace přímo v seznamu 1) Klíčové údaje záznamu lze editovat přímo v seznamu, který je zobrazen na obrázku níže. 2) Po kliknutí na tlačítko Edit in List má operátor možnost změnit následující položky vybraného servisního případu (v ukázce jde o request číslo 29): Status Priority Parent request (rodičovský nadřízený request) Caused by Change Order relace ne změnový požadavek Assignee (řešitel) 3) Aktuální servisní případ pro editaci se zvolí kliknutím na příslušný řádek seznamu. Stisknutím tlačítka Change All dojde ke změně údajů u všech případů v seznamu. 4) Tato metoda je výhodná v případě dávkové změny údajů u většího počtu servisních případů. Strana 38 / 81

39 4.10 Vytváření vazeb Přiřazení konfigurační položky k záznamu K záznamům, které vyžadují, pro zajistění konzistence údajů, přiřazení konfigurační položky, je možno definovat vazbu do CMDB. K požadavkům je možno navázat konkrétní položku. K Incidentům a problémům dvě. První je položka, na které je Incident/Problém způsoben, druhá je služba, která je Incidentem/Problémem ovlivněna. K požadavkům na změnu je možno připojit relaci na více položek současně. Při definici relace je zobrazeno vyhledávací okno pro vyhledání položek v CMDB, které umožňuje záznamy filtrovat. Strana 39 / 81

40 Obrazovky pro definici relace pro: Požadavek (Request) - pole Configuration Item v sekci Detail: Incident a Problem pole Configuration Item a pole Affected Service výběr služby, na které je incident / problem řešen. Strana 40 / 81

41 Požadavek na změnu Change Order záložka Configuration Management Strana 41 / 81

42 Vazby mezi Requesty, Incidenty, Change Ordery Řešitel může na záložce 4. Realtionships u požadavku definovat závislosti typu nadřízený/podřízený záznam. Následně je možné automatizovat zpracování podřízených požadavků nař. při uzavírání. Obdobným postupem je možno definovat relace mezi incidenty. Sekce 1 Request Parent/Child definice souvisejících požadavků Sekce 3. Incident Parent/Child definice souvisejících Incidentů Sekce 2. Oprávnění Parent/Child administrátor a operátoři mají možnost rozšířit právo přistoupit k tiketu i pro jiné skupiny, než jsou aktální řešitelé tiketu. Využívá se při řešení podřízených tiketů, kdy jsou detaily a historie evidovány u nadřízeného tiketu. Relace mezi požadavkem a Incidentem Strana 42 / 81

43 Z detailu požadavku pomocí tlačítka Create Incident může řešitel založit Incident, který bude navázán na požadavek, ze kterého je vytvářen. V tomto případě jsou přebírány popisy a většina informací z požadavku a není je nutno opět zadávat. V poli Description je doplněn text (created from Request xxx) a na záložce 4. Relationships část 1. Request Parent/Child jsou zaevidovány vazby mezi Requesty v systému. Strana 43 / 81

44 Relace mezi Incidentem a Problemem Z detailu Incidentu může řešitel založit pomocí tlačítka Create Problem problem, který bude navázán na incident, ze kterého je vytvářen. V tomto případě jsou přebírány popisy a většina informací z iincidentu a není je nutno opět zadávat. Strana 44 / 81

45 Relace mezi Incidentem a Change Order Z detailu Incidentu nebo požadavku může řešitel založit pomocí tlačítka Create Change Order změnový požadavek, který bude navázán na incident/poaždavek, ze kterého je vytvářen. V tomto případě jsou přebírány popisy a většina informací z incidentu/požadavku a není je nutno opět zadávat Práce se šablonou Řešitel L2 má možnost při řešení rozhodnout, zda řešený, nebo nově zakládaný požadavek (Request, Incident, Problem, Change Order) je možno využít do budoucna jako šablonu Template. Šablonu může použít řešitel pro zakládání požadavků s předvyplněnými údaji. Šablony nejsou využitelné uživateli. Vytvoření šablony: Při editaci požadavku řešitel definuje na záložce č. 4 Template jméno,třídu, typ a popis šablony. Následně požadavek uloží. Strana 45 / 81

46 Požadavek je uložen a označen jako template. Použití šablony Řešitelé v budoucnu mohou tyto předvyplněné/požadavky použít pro rychlé založení požadavků pomocí výběru položky New Request from Template z menu File. Pokud je definováno více šablon, zobrazí se řešiteli seznam, ze kterého si zvolí položku dle potřeby. Šablony je možno využít například pro potřeby evidence profylaxe a jiný provozních činností, které s sebou nesou stejné postupy řešení. Pro potřeby evidence a reportování bude využito pole SZR, které odkazuje na číselník hodnot: Strana 46 / 81

47 4.12 Vykázání odpracované doby Operátoři a řešitelé vykazují dobu odpracovanou při řešení požadavků do pole Odpracovaná doba v aktivitě, kterou k záznamu evidují. Je nutné dodržet předepsaný formát hh:mm:ss Využití konfigurační a znalostní databáze Řešitelé využívají konfigurační databázi pro získání informací usnadňujících analýzu a identifikaci řešení (historie řešených požadavků, incidentů a změn u dotčené položky a uživatele, přehled souvisejících konfiguračních položek a jejich vliv na řešený požadavek atd.). Vytváření vazeb na konfigurační databázi je popsáno v kapitole Řešitelé dále využívají znalostní databázi, kde jsou sdíleny znalosti a zkušenosti týmu podpory ve formě znalostních dokumentů, popisujících typická řešení požadavků a dočasná řešení pro oblast incidentů. Pokud uzná za vhodné, může řešitel při identifikaci řešení odeslat návrh na zveřejnění řešení ve znalostní databázi. Tento návrh je následně zpracován a publikován ostatním řešitelům. Popis práce se znalostní databází je uveden v kapitole 5. Strana 47 / 81

48 5. Práce se znalostní databází Znalostní databáze slouží řešitelům jako nástroj, umožňující vyhledávat vhodná řešení pro zadané požadavky, incidenty a problémy. Díky integraci znalostní databáze (Knowledge Base) se systémem Service Desk je možno rychle vyhledávat přímo z jednotlivých tiketů. K dispozici jsou také intuitivní nástroje usnadňující publikaci nových vyzkoušených řešení formou nového znalostního dokumentu. 5.1 Vyhledávání informací ve znalostní databázi Vyhledávat informace ve znalostní databázi lze přímo z prostředí Knowledge nebo v kontextu konkrétního záznamu Vyhledávání přímo z prostředí Znalostní databáze Do prostředí Knowledge se operátor, řešitel dostane pomocí záložky Knowledge ve svém webovém rozhraní. Viz následující obrázek Vyhledávat podle klíčových slov. Na následujícím obrázku je ukázka vyhledávání pomocí klíčové fráze tipy. Parametry vyhledávání lze zvolit prostřednictvím odkazu Advanced Search. Strana 48 / 81

49 5.1.2 Vyhledávání v kontextu konkrétního tiketu 1) Ve formuláři requestu klikneme na záložku Knowledge Management část Knowledge. Přímo z formuláře requestu je možné prohledávat znalostní databázi a zobrazit seznam nalezených dokumentů. Do pole pro vyhledávání se automaticky doplní obsah pole Summary. Po případné úpravě řetězce pro vyhledávání a podmínek jsou zobrazeny odpovídající dokumenty, setříděné podle relevance: Strana 49 / 81

50 2) Seznam klíčovému slovu odpovídajících položek se vypíše přímo na formuláře requestu Pokud je tento dokument využitelný jako řešení k požadavku, je možno pomocí odkazu Accept as Solution svázat dokument s požadavkem a následně změnit stav požadavku na vyřešený. Strana 50 / 81

51 Položky dostupné v Page options jsou různé, podle role, ve které je uživatel v systému přihlášen. Na přiložené obrazovce jsou volby dostupné pro Roli Operátora. Položka Accept as Solution je dostupná pouze, pokud je dokument zobrazen v kontextu řešeného požadavku/incidentu/problemu/změnového požadavku. Všechna použitá řešení, ať manuálně popsaná přes menu aktivity -> Solution, nebo odkazy na dokumenty znalostní databáze, jsou zobrazena u požadavku na záložce Knowledge Management část Solutions Strana 51 / 81

52 Na příkladu je zobrazeno řešení: Popsané u požadavku a odeslané do Znalostní databáze (Type = Knowledge Submitted) Popsané pouze u požadavu, bez vazby na znalostní databázi (Type = Log Solution) Použitý znalostní dokument jako řešení (Type = KT Solution Linked) 5.2 Vložení řešení požadavku do znalostní databáze Pokud chcete uložit řešení požadavku do znalostní databáze, zvolíte z menu Activities -> Solution Strana 52 / 81

53 a v okně Vytvořit novou aktivitu pro požadavek XX doplníte do pole User Description popis řešení a zmáčknete tlačítko Save And Submit Knowledge. Po zmáčknutí tohoto tlačítka se zobrazí okno dle definované šablony znalostního dokumentu. Strana 53 / 81

54 Systém automaticky zkopíruje text požadavku i text řešení, pro záznam do znalostní databáze je možné texty upravit, aby byly obecné a opakovatelně využitelné. Pole Resolution je možno formátovat pomocí html formátovacích znaků. Jednoduchý editor pro formátování zobrazíte zmáčknutím tlačítka Edit Resolution. Příklad vidíte na následujícím obrázku: Strana 54 / 81

55 Zmáčknutím tlačítka OK uložíte takto formátovaný text do pole Resolution. Strana 55 / 81

56 Pro uložení záznamu do znalostní databáze zmáčkněte tlačítko Save, nebo Save and close pro současné uzavření okna požadavku, pokud je v editaci. Uvedeným postupem se vytvoří znalostní dokument ve stádiu návrhu (Draft) a předáno k dalšímu zpracování správci znalostní databáze, který rozhodne o jeho dalším zpracování, případně publikování. Strana 56 / 81

57 6. Publikování informací do oblasti Announcements Oprávnění publikovat oznámení pro ostatní uživatele mají pouze řešitelé L2 a správce systému. V rozhraní řešitele na záložce Service Desk menu File položka New Announcement V novém okně pro definici oznámení je možno definovat: Text oznámení Location omezit zobrazení tohoto oznámení pouze na uživatele vybrané lokality Internal omezit zobrazení oznámení pouze na role, které vidí takto označené informace (nevidí je uživatelé) Organization omezit oznámení pouze na uřivatele z konkrétní definované organizace Announcement Type výběr z hodnot, které vizuelně odlišují oznámení rutinní, závažná a kritická Status výber z hodnot Active/Inactive ovlivňující platnost oznámení Closed Date/Time omezit platnost oznámení do určité doby Dále je možno k tomuto oznámení přiložit odkaz na další zdroj (znalostní dokument, přílohu apod.) Strana 57 / 81

58 Strana 58 / 81

59 7. Tiskové výstupy Tiskové výstupy jsou přístupné pouze pro rozhraní operátorů/řešitelů. Standardní rozhraní poskytuje dva tiskové výstupy: 1. Z detailu jednotlivých požadavků, incidentů, problémů a změn. Menu Reports položka Detail: 2. Z obrazovek seznamů požadavků, incidentů, problémů a změn Menu Reports položka Summary: Tiskové sestavy obsahují základní údaje o vybraných záznamech. Z obrazovek seznamů je možno údaje pomocí tlačítka Export vyexportovat do souboru XLS a dále zpracovávat např. v Excelu. Strana 59 / 81

60 Vybrané role (Knowledge Manager, Řešitel problémů, Change Manager) mají přístupnou záložku Reports, kde jsou dostupné další reporty z prostředí BOXI. Podrobný popis práce s reporty systému BOXI je uveden v samostatném dokumentu. Strana 60 / 81

61 8. Postup řešení požadavku Pro provádění dále uváděných aktivit při zpracování tiketů v systému SDM se předpokládá znalost postupů z kapitol 4 a Požadavek zadaný neověřeným uživatelem - Guest Pro uživatele, kteří v systému Service Desk Manager dosud nemají vytvořen účet, je dostupná role Host. Tato role umožní zadat do systému obecný požadavek, který bude následně zpracován Operátorem SD. Přihlášení do systému pod účtem Host provede uživatel kliknutím na odkaz v dolní části přihlašovací obrazovky do systému: Úvodní obrazovka hosta umožňuje pouze zadání nového požadavku. Strana 61 / 81

62 Zadání požadavku je shodné s postupem v roli Uživatel, popsaným v kapitole Pole Jméno Příjmení Telefon, a Organizace nejsou předvyplněná a je povinné tato pole vyplní, aby bylo možno s takto zadaným požadavkem dále pracovat. Host dále nemá možnost prohlížet své dříve zadané požadavky a nejsou mu odesílány notifikací o průběhu řešení požadavku. Při výběru kategorie požadavku, je pro hosta dostupná pouze jedna kategorie. Strana 62 / 81

63 Požadavky založené pod účtem hosta mohou být po založení regulérního účtu uživatele převedeny do procesu zpracování požadavku uživatele s notifikacemi a možností prohlížet a doplňovat komentáře a přílohy z web rozhraní, či u. Žádost o přiřazení těchto požadavků provede uživatel požadavkem založeným v SDM. Nutná podmínka pro realizaci je, že jsou vyplněna u těchto požadavků pole Jméno a Příjmení shodně se Jménem a Příjmením regulérního účtu, případně uživatel předá čísla těchto požadavků operátorům, kteří přiřazení následně provedou. Schéma zobrazuje obecný postup při zpracování požadavku zadaného Hostem. Strana 63 / 81

64 Zadaný požadavek je předán k řešení skupině Operátor L1 Operátor L1 požadavek: Odmítne, nebo Zruší pomocí Aktivity Update Status je notifikována skupina MNGSD, aby rozhodla o oprávněnosti odmítnutí/zrušení pokud je oprávněné, převede pomocí aktivity Update Status na Uzavřený Strana 64 / 81

65 pokud je neoprávněné, vrací k řešení pomocí aktivity Update Status na Zadaný o o o Může být "Odmítnutý" řešitelem pro nepříslušnost řešitelské skupiny, vyčkejte, operátor "Odmítnutý" vidí a provede předání na příslušnou řešitelskou skupinu. V User Description * je nezbytné slovně uvést, že "Důvodem odmítnutí je věcná nepříslušnost řešitelské skupině/řešiteli a žádost o předání Operátorem na vhodnější příslušnou řešitelskou skupinu, pokud možno s návrhem řešitelské skupiny nebo slovním vymezením působnosti vhodné řešitelské skupiny". Tento komentář dostane i uživatel! Operátor odpoví, že převádí, pokud by nedošlo k převodu na jinou řešitelskou skupinu Operátorem bude Request přes Auto Close do 5 pr. Dní uzavřen a je potřeba zadat nový Může být "Odmítnutý" operátorem, poznáte po "Řešitel" - nastavit roli, "Request xxxx Go" a na requestu group Operátor, nesouhlas vložením komentáře, běží 5 pr.dní Auto Close a pokud nedojde k update status, bude automaticky uzavřen Může být "Zrušen", jedná se o technické zrušení požadavku např. požadavek byl zadán omylem, je třeba vyhodnotit důvod technického zrušení, nesouhlas vložením komentáře, běží 5 pr.dní Auto Close, poté bude uzavřen Převezme do řešení pomocí aktivity Transfer (vyplní pole New Assignee svým kontaktem, systém změní stav na V řešení ) o o Vyřeší doplní řešení pomocí aktivity Log Solution, změní stav pomocí aktivity Update Status na Vyřešený Zruší - je notifikována skupina MNGSD, aby rozhodla o oprávněnosti zrušení Předá řešení na Operátory L2 pomocí Změny Request Area nebo aktivitou Escalate o Operátor L2 převezme do řešení pomocí aktivity Transfer (vyplní pole New Assignee, systém změní stav na V řešení ) Vyřeší doplní řešení pomocí aktivity Log Solution, změní stav pomocí aktivity Update Status na Vyřešený Zruší je notifikována skupina MNGSD, aby rozhodnula o oprávněnosti zrušení o Předá řešení na Řešitele (L3) pomocí Změny Request Area Řešitel převezme do řešení pomocí aktivity Transfer (vyplní pole New Assignee, systém změní stav na V řešení ) Vyřeší doplní řešení pomocí aktivity Log Solution, změní stav pomocí aktivity Update Status na Vyřešený Pokud není schopen řešit, předá na jinou skupinu přes operátora o o Manuální notifikace na Operátora L2 co si žádáte a na koho Operátor L2 provede změnu area s těmito dopady: Stav do Zadaný Změna řešitelské skupiny dle přiřazení u area Odebrání řešitele Strana 65 / 81

66 Restart service type - tedy všechny lhůty a jejich notifikace na response apod. běží znovu novou přiřazenou řešitelskou skupinu Notifikace řešitelské skupiny o přiřazení Vyřešené požadavky jsou notifikovány zadavateli, a pokud není řešení rozporováno, jsou po 5ti dnech uzavřeny. Poté v daném období vypořádány. 8.2 Požadavek zadaný ověřeným uživatelem/řešitelem Nahlásil Při vytváření požadavku je automaticky vyplněno pole Nahlásil podle evidovaných údajů přihlášeného uživatele. Toto pole není možno měnit. Jméno, Příjmení, Telefonní číslo mobil, ová adresa, Organizace Tato pole jsou předvyplněna podle evidovaných údajů přihlášeného uživatele. Pole je možno při zakládání požadavku upravit. Touto úpravou uživatel provede aktualizaci kontaktních informací v příslušných polích u svého kontaktu vedeného v SDM. Tyto údaje jsou následně využity v systému pro další aktivity (notifikace, SMS apod.) Pokud v poli Organizace uživatel nenalezne svoji organizaci, vybere položku Guest a do popisu požadavku uvede jméno organizace, za kterou požadavek v systému zadává. Operátoři Service Desku zajistít doplnění této organizace do číselníku. Naléhavost Uživatel může upravit předvyplněnou hodnotu v poli Naléhavost výběrem z číselníku dostupných hodnot. Tento údaj vyjadřuje naléhavost, s jakou uživatel řešení vyžaduje. 1 - systém je nefunkční nebo pro uživatele nedostupný, zařízení vadné, akutní požadavek, problém z pohledu uživatele vyžaduje okamžité řešení (např. zamezení ztráty dat, či úniku informací, zajištění důležitého jednání či obchodní schůzky, odjezd na služební cestu) 2 - funkčnost systému nebo dostupnost pro uživatele je omezena, zařízení je poškozené, spěšný požadavek. 3 - na systému se vyskytuje problém, který zásadním způsobem neomezuje funkčnost systému, zařízení je poškozené, běžný požadavek. Strana 66 / 81

67 4 - uživatel má evidovaný požadavek, není vyžadováno okamžité řešení, problém je možno odstranit v průběhu běžné pracovní doby. Lze nahradit provizorním řešením. 5 - uživatel má evidovaný požadavek. Termín jeho vyřešení není z jeho pohledu významný a řešení nechává na možnostech poskytovatele služeb. Kategorie požadavku V poli Kategorie požadavku uživatel vybere z číselníku kategorií požadavků tu, která co nepřesněji odpovídá oblasti, ke které se zadávaný požadavek váže. Číselník má několik úrovní. Existence dalších podsložek je indikována šipkou před názvem nadřízené položky. Výběr se provede kliknutím na zvolenou kategorii, která se automaticky doplní do aktivního pole v požadavku. Číselník kategorií je uveden v kapitole Číselník kategorií požadavků Pro požadavky zakládané mimo provozní dobu uživatel musí vybrat kategorii z příslušné sekce číselníku (A-2), jinak nebude požadavek korektně předán k řešení a bude zpracován až následující pracovní den ve standardním režimu. Některé kategorie mohou vyžadovat doplnění dalších upřesňujících informací k zakládanému požadavku. Po výběru kategorie se zobrazí nová pole pro doplnění těchto údajů. Uživatel musí vyplnit hodnoty všude, kde je pole označeno slovem (vyžadováno) Další standardní pole vyplňovaná zákazníkem Pole Souhrn stručné shrnutí požadavku Uživatel doplní popis svého požadavku do pole Podrobný popis, kde uvede všechny informace nezbytné pro jeho korektní zatřídění a vyřešení. Uložení požadavku provede kliknutím na tlačítko Uložit v horní části okna. Požadavek se uloží do systému a uživatel se vrací na základní obrazovku. O úspěšném založení požadavku je informován odkazem Požadavek XXX byl vytvořen., v horní části sekce Dostupné akce. Současně systém odesílá na definovanou ovou adresu uživatele notifikaci o založení požadavku s informací o přiděleném identifikačním čísle, kontaktních údajích uživatele a částí popisu. Strana 67 / 81

68 Pokud je požadavek založen mimo provozní dobu, první řešitel není kompetentní k řešení a ve své reakci na přidělení požadavku doporučí uživateli jinou kategorii, je uživatel zodpovědný za založení nového požadavku s touto doporučenou kategorií, pokud vyžaduje řešení svého požadavku v mimoprovozní dobu. Schéma zobrazuje obecný postup při zpracování požadavku zadaného uživatelem v provozní době. Strana 68 / 81

69 Při řešení je možno navíc oproti požadavku Guesta využít: Vkládání komentářů pomocí Log Comment a příloh Attachments s následnou notifikací o vložení komentáře/přílohy Odesílání Manuální notifikace pomocí Manual Notify (řešitel) Strana 69 / 81

70 Odpovědi na doručené notifikace v průběhu řešení automatické připojení těchto mailů k požadavku, včetně příloh Do okamžiku zahájení řešení (změna stavu na V řešení a následující stavy) může uživatel požadavek editovat a uzavřít. Po zahájení řešení již pouze doplňovat komentáře a přílohy. Po vyřešení (změna stavu na Vyřešený ) požadavek uzavřít potvrdit souhlas s řešením. Pokud tam neučiní, systém automaticky požadavek uzavře za 5 pracovních dní. Schéma zobrazuje obecný postup při zpracování požadavku zadaného uživatelem mimo provozní dobu. Komunikace mezi uživatelem a řešitelem L3 probíhá napřímo standardní mailovou komunikací. Pokud je potřeba zaslat přílohu, je nutné ji poslat také mailem. Pro evidenci komunikace je nutno uvádět adresu Service Desku v kopii zpráv toto je vždy zdůrazněno v notifikacích, které v režimu MPD systém odesílá. Pokud se řešení požadavku zadaného mimo provozní dobu neuzavře do začátku následujícího pracovního dne, přechází další postup do režimu standardního řešení v rámci provozní doby. Schéma zobrazuje obecný postup při zpracování požadavku zadaného řešitelem. Strana 70 / 81

71 Řešitel může ve svém rozhraní navíc oproti uživateli využívat: další Request Area F)Řešitelské skupiny (SZR)" a "G) Servisní požadavky změny stavů pomocí aktivity Update Status při Reklamaci a Poskytování součinnosti využít Manuálních notifikací zadávat požadavky přímo na konkrétní řešitelské skupiny Požadavky, které vyžadují před zahájením řešení schválení (Request Area z části G) Servisní požadavky ), jsou po zadání ve stavu Ke schválení a jsou přiřazeny zodpovědným Schvalovatelům (skupiny APP_XXX). Schvalovatelé provedou: Schválení o Změnu Request Area Strana 71 / 81

72 o Vložením komentáře ke schválení pomocí aktivity Log Comment Odmítnutí standardní postup řešitele při Odmítnutí požadavku Řešení standardní postup řešení přiděleného požadavku 8.3 Sledování doby odezvy Při řešení požadavků je sledována doba odezvy - zahájení řešení. Je to okamžik, kdy je k požadavku přidělen řešitel a stav požadavku se změní na V řešení, nebo odmítnutím požadavku pomocí aktivity Update status s komentářem. V případě, že není zahájeno řešení, systém odesílá notifikace po: 30 minutách od přiřazení Request Area - kontakt MEM_SZR 60 minutách od přiřazení Request Area skupina MNG_SD 90 minutách od přiřazení Request Area - skupina MNG_IT Po vypršení 90 minut je nastaven k požadavku příznak nesplnění doby odezvy. 8.4 Stavy požadavku v průběhu řešení Stav Zadaný V řešení Vyřešený Čeká na součinnost Součinnost poskytnuta Uzavřený Odmítnutý Zrušený Vypořádaný Popis Požadavek zadaný do SDM, před kontrolou kategorie, priority a přidělením řešitele Požadavek, který má přiděleného řešitele. V případě, že uživatel obdržel notifikaci o vyžádané součinnosti, bude řešitel pokračovat v řešení, až po obdržení této součinnosti. Požadavek, u kterého řešitel popsal řešení a běží u něj čas pro reklamaci. Uživatel je o změně stavu informován mailem. Řešitel čeká na součinnost, aby mohl pokračovat v řešení Řešitel dostal potřebné informace a bude pokračovat v řešení Požadavek, který je neaktivní a u kterého nebylo řešení rozporováno. Požadavek, který nespadá svým charakterem do oblasti, kterou poskytovatel služeb podporuje, nebo nebyl vznesen oprávněným uživatelem Požadavek, který již nebude dále řešen Požadavek, který byl zpracován v rámci vypořádání uplynulého období. Není ho možno dále upravovat. Strana 72 / 81

73 Ke schválení Reklamace Požadavek, jehož řešení musí být nejprve schváleno Požadavek, u něhož byla vznesena oprávněná reklamace řešení 8.5 Požadavky vyžadující spolupráci od uživatele nebo jiné řešitelské skupiny Při řešení požadavku příslušným řešitelem je nutná k řešení spolupráce uživatele či jiné řešitelské skupiny: Řešitel daného požadavku, který má ve stavu V řešení potřebuje jako součást řešení doplňující informaci od uživatele. V tomto případě řešitel definuje svůj požadavek přes tlačítko Activities a Log Comment vložením komentáře a přes tlačítko Activities a Update Status změní stav na čeká na součinnost. Po obdržení odpovědi od uživatele přes tlačítko Activities a Update Status změní stav na Součinnost poskytnuta a dále pokručuje v řešení a změně statusu do Vyřešený. Řešitel daného požadavku, který má ve stavu V řešení potřebuje jako součást řešení vyjádření či spolupráci dalšího subjektu( řešitele, správce registru, ) a po obdržení požadované spolupráce pokračuje v řešení požadavku. V tomto případě řešitel založí nový požadavek, kde v komentáři uvede, jakou součinnost potřebuje a od koho jí žádá, a tento požadavek sváže s původním požadavkem pomocí tlačítka 4.Relationships a Update Children a dále přes tlačítko Search vyhledá a vloží.. U původního požadavku přes tlačítko Activities a Update Status změní stav na čeká na součinnost a přes tlačítko Activities a Log Comment vloží komentář: k řešení vašeho požadavku byla vyžádána součinnost jiného řešitele- čeká se na součinnost. Po vyřešení svého požadavku přes tlačítko Activities a Update Status změní stav na Součinnost poskytnuta a pokračuje v řešení původního požadavku do Vyřešený. Řešitel daného požadavku, který má ve stavu V řešení, provede finální vyřešení části požadavku a další řešení je v kompetenci jiné řešitelské skupiny. V tomto případě řešitel založí nový požadavek, kde v poli Affected End User zadá původního uživatele. Zadá požadavek, který se týká následujícího řešitele, popř. zkopíruje potřebné přílohy. V poznámce uvede, komu tento požadavek náleží. U původního požadavku přes tlačítko Activities a Log Comment vloží komentář: řešení vašeho požadavku pokračuje requestem č. xxxx ( uživatel bude o tomto informován notifikací) a tento požadavek dá do statusu Vyřešený. 8.6 Odmítnutí požadavku ve stavu V řešení Řešitel uvedl omylem požadavek do statusu V řešení. V tomto případě řešitel založí nový požadavek, kde v poli Affected End User zadá původního uživatele. Do nově založeného požadavku zkopíruje původní zadání uživatele včetně příloh. V poznámce uvede, komu tento požadavek náleží. U původního požadavku přes tlačítko Activities a Log Comment vloží komentář: řešení vašeho požadavku pokračuje requestem č. xxxx ( uživatel bude o tomto informován notifikací) a tento požadavek dá do statusu Vyřešený. Strana 73 / 81

74 9. Postup řešení incidentu Incidenty jsou zakládány Operátorem L2 v případě, že se jedná o nedostupnost služby a omezenou funkčnost, která má za následek zásadní ovlivnění činnosti systému. Incident je zakládán pomocí tlačítka Create Incident u Requestu: V tom případě jsou přenesena pole Incident Area, Repoerted By, Urgency, Summary a Description Operátor doplní všechna zbývající povinná (označena hvězdičkou) pole, zkontroluje správnost přiřazení Incident Area a Priority. Tyto dva atributy určují jaké SLA bude na incidentu platné. Incident uloží pomocí tlačítka Save. Následující řešení incidentu řešitelem zachovává pricipy zpracování Requestů popisované v předchozích kapitolách. (převzetí do řešení pomocí Transfer, Manual Notify, změny stavů pomocí Update Status, Log Comment, vkládání příloh). Z důvodu korektního počítání SLA není možno používat eskalace pro změnu řešitelské skupiny. Tuto aktivitu mají oprávnění provádět pouze Operátoři L2. Strana 74 / 81

75 Pokud Řešitel nebude incident řešit, a ještě nepřevzal Incident k řešení (aktivita Transfer a stav V řešení ) změní stav pomocí aktivity Update Staus na Odmítnutý. Tím se Incident vrátí Operátorům L2, kteří určí další postup řešení. U incidentu se přiřazením Incident Area nastaví skupina řešitelů, properties a Service Type SLA pro sledování Response Time a Fix Time. Splnění Response Time je dosaženo změnou stavu požadavku ze stavu Zadaný (i odmítnutí je považováno za splnění Response Time). Splnění Fix Time je dosaženo změnou stavu na Vyřešený nebo, Uzavřený, nebo Zrušený. Aktuálně přiřazené SLA k Incidentu je vidět na záložce 1. Additional Information část 3 Service Type. Schéma zobrazuje obecný postup při zpracování incidentu, který vzniká na základě požadavku zadaného uživatelem. Strana 75 / 81

76 9.1 Nastavení Service Type STIMSZR Aktivita Událost Čas od startu Service Type SZR P2-15 minut response SZR P2 15 minut response 15 min SZR P1-15 minut response SZR P1 15 minut reponse 15 min SZR P1-20 minut response SZR P1 20 minut response 20 min SZR P1-23 minut response SZR P1 23 minut reponse 23 min SZR P2-30 minut response SZR P2 30 minut response 30 min SZR P1-30 minut response SZR P1 30 minut reponse 30 min SZR P2-45 minut reponse SZR P2 45 minut reponse 45 min SZR P3 60 minut response SZR P3 60 minut response 1 hod SZR P2-60 minut reponse SZR P2 60 minut reponse 1 hod SZR P1-50% SLA SZR P1 50% SLA 2 hod Strana 76 / 81