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

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

-

Datum: 17.10. 2013

© GORDIC spol. s r.o., 2012 - Projekt Implementace CA do SZR

Obsah OBSAH ................................................................................................................... 2 HISTORIE DOKUMENTU ............................................................................................. 4 1.

ÚVOD ............................................................................................................... 5

2.

OBECNÝ POPIS FUNKCE SERVICE DESK .............................................................. 6

2.1

Základní povinnosti: ......................................................................................................... 6

2.2

Organizační schéma SD ................................................................................................... 6

2.3

Popis rolí SD: .................................................................................................................... 6

3.

CA SERVICE DESK MANAGER V SZR ................................................................. 8

3.1

4.

Dostupné role pro řešitele ............................................................................................... 8

ZÁKLADY OVLÁDÁNÍ SYSTÉMU ........................................................................... 9

4.1

Přístup do aplikace Service Desk Manager ................................................................... 9

4.1.1

Přístup do produkčního SDM: ................................................................................................ 9

4.1.2

Přístup do testovacího systému SDM: .................................................................................. 11

4.2

Založení požadavku ........................................................................................................ 12

4.2.1

V roli uživatele ..................................................................................................................... 12

4.2.2

V roli operátora/řešitele ........................................................................................................ 14

4.3

Analýza a řešení požadavku .......................................................................................... 16

4.3.1

Převzetí požadavku do řešení ............................................................................................... 16

4.3.2

Vyžádání součinnosti ............................................................................................................ 18

4.3.3

Eskalace požadavku .............................................................................................................. 18

4.4

Vyřešení požadavku ....................................................................................................... 20

4.5

Vypořádání tiketů............................................................................................................ 21

4.6

Informovanost uživatele ................................................................................................ 22

4.6.1

Reklamace vyřešeného požadavku/incidentu ....................................................................... 23

4.6.2

Průzkum spokojenosti uživatelů/zákazníků s řešením požadavků/incidentů ........................ 24

4.7

Emailová komunikace .................................................................................................... 24

4.8

Rozhraní řešitele ............................................................................................................. 25

4.8.1

Úvodní obrazovka rozhraní řešitele ...................................................................................... 25

4.8.2

Scoreboard ............................................................................................................................ 25

4.8.3

Použití filtrů .......................................................................................................................... 28

4.9

Editace údajů .................................................................................................................. 32

4.9.1

Standardní editační formulář ................................................................................................ 32

4.9.2

Další možnosti změn údajů pomocí předdefinovaných funkcí ............................................. 33

4.9.3

Editace přímo v seznamu ...................................................................................................... 38

4.10

Vytváření vazeb ............................................................................................................... 39

Strana 2 / 81 GORDIC spol. s r.o.

4.10.1

Přiřazení konfigurační položky k záznamu........................................................................... 39

4.10.2

Vazby mezi Requesty, Incidenty, Change Ordery ................................................................ 42

4.11

Práce se šablonou .......................................................................................................... 45

4.12

Vykázání odpracované doby ......................................................................................... 47

4.13

Využití konfigurační a znalostní databáze ................................................................... 47

5.

PRÁCE SE ZNALOSTNÍ DATABÁZÍ ...................................................................... 48

5.1

Vyhledávání informací ve znalostní databázi .............................................................. 48

5.1.1

Vyhledávání přímo z prostředí Znalostní databáze .............................................................. 48

5.1.2

Vyhledávání v kontextu konkrétního tiketu .......................................................................... 49

5.2

Vložení řešení požadavku do znalostní databáze ....................................................... 52

6.

PUBLIKOVÁNÍ INFORMACÍ DO OBLASTI ANNOUNCEMENTS ................................... 57

7.

TISKOVÉ VÝSTUPY........................................................................................... 59

8.

POSTUP ŘEŠENÍ POŽADAVKU ........................................................................... 61

8.1

Požadavek zadaný neověřeným uživatelem - Guest................................................... 61

8.2

Požadavek zadaný ověřeným uživatelem/řešitelem ................................................... 66

8.3

Sledování doby odezvy .................................................................................................. 72

8.4

Stavy požadavku v průběhu řešení .............................................................................. 72

8.5

Požadavky vyžadující spolupráci od uživatele nebo jiné řešitelské skupiny .......... 73

8.6

Odmítnutí požadavku ve stavu „V řešení“ ................................................................... 73

9.

POSTUP ŘEŠENÍ INCIDENTU .............................................................................. 74

9.1

Nastavení Service Type STIMSZR................................................................................. 76

9.2

Stavy incidentu v průběhu řešení ................................................................................. 77

10. SCOREBOARD ................................................................................................ 79 10.1

Definice Scoreboardu pro Operátor L1 ........................................................................ 79

10.2

Definice Scoreboardu pro OperátorL2 ......................................................................... 80

10.3

Definice Scoreboardu pro Řešitel ................................................................................. 81


Historie dokumentu Verze

Datum

Autor

Popis

1.0

15. 11. 2012

Petr Poplstein

Vytvoření draftu dokumentu

1.1

20. 11. 2012

Petr Poplstein

Zapracování připomínek z 19. 11. 2012

1.2

23. 11. 2012

Petr Poplstein

Zapracované připomínky z 23. 11. 2012

1.3

4. 3. 2013

Petr Poplstein, Marek Švejda

Aktualizace

1.5

10. 5. 2013

Petr Poplstein

Aktualizace

1.6

31.5 2013

Petr Poplstein

Aktualizace

26.6 2013

Petr Poplstein

Aktualizace, zapracování připomínek

25.8.2013

Petr Poplstein

Aktualizace kapitoly 4.10.2

17.10.2013

Igor Jeřábek

Vložení kap. 8.5 a 8.6

1.7


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 www.szrcr.cz 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.


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ů


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: 

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ů

Řešitelé 

Ú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


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.


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:

4.1.1 1.

2.

Uživatelé s účtem v AD - používá se primárně pro řešitele SZR: a.

Z internetu: https://sd.szrcr.cz/CAisd/pdmweb.exe

b.

Z KIVS: https://sd.szrcr.egon.cms/CAisd/pdmweb.exe

c.

Interně: https://sd.szrcr.cz/SSO/pdmweb.exe

Uživatelé s účtem v JIP: a.

Z internetu: https://loginsd.szrcr.cz

b.

Z KIVS: https://loginsd.szrcr.egon.cms


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 registrů @ 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 13.0.782 a vyšší




Apple Safari 5.1 a vyšší

Přístup do testovacího systému SDM:

4.1.2 1.

2.

Uživatelé s účtem v AD: a.

Z internetu: https://tsd.szrcr.cz/CAisd/pdmweb.exe

b.

Z KIVS: https://tsd.szrcr.egon.cms/CAisd/pdmweb.exe

c.

Interně: https://tsd.szrcr.cz/SSO/pdmweb.exe

Uživatelé s účtem v JIP: a.

Z internetu: https://logintsd.szrcr.cz

b.

Z KIVS: https://logintsd.szrcr.egon.cms

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:


4.2 Založení požadavku 4.2.1

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, Emailová 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 „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 zařízení je poškozené, běžný požadavek.

neomezuje funkčnost systému,

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.


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




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:


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í.

4.3.1

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:


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:


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í“.

4.3.2

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 email 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)

4.3.3

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ů


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.


Komunikační schéma pro založení, řešení a vyřešení požadavku/incidentu

Uživatel

Telefon Email telefon SDM

Email

Operátor L1

Email

Telefon

Operátor L2

     

SDM

SDM Email,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 emailu 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“


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


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 emailem. 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.


  

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 email 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 emailový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.

4.6.1 

 

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.


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 emailem na spokojenost s poskytovanou službou SD.

4.7 Emailová 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 emailu provedete RE: při jakékoli editaci těla emailu a přidání cc, bude Vaše odpověď vložena jako komentář do tiketu včetně vložení příloh z emailu, 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 emailu budete informováni emailovou notifikací



nezasahovat do předmětu zprávy, v těle neponechávat předchozí komunikace (mazat)



musíte odpovídat z emailu uvedeného u Vašeho kontaktu


4.8 Rozhraní řešitele 4.8.1

Ú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

4.8.2

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.


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.


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.


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é.

4.8.3

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.


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


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%.


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.


4.9 Editace údajů Údaje záznamu je možné editovat více způsoby.

4.9.1

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.


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ší.

4.9.2

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í.


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 emailů



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í emailovou 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.


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é


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:


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.


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ů.


4.10 Vytváření vazeb 4.10.1 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.


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.


Požadavek na změnu Change Order záložka Configuration Management


4.10.2 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


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.


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.


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.

4.11 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ží.


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:


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.

4.13 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 4.10.1 Ř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.


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.

5.1.1

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.


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:


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ý.


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


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


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.


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:


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


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í.


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.)



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.


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.


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 5.

8.1 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.


Zadání požadavku je shodné s postupem v roli Uživatel, popsaným v kapitole 4.2.1. Pole Jméno Příjmení Telefon, Email 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.


. 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 emailu. Žá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


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ý“








pokud je neoprávněné, vrací k řešení pomocí aktivity Update Status na „Zadaný“

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ý

o

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

o

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

Vyřeší – doplní řešení pomocí aktivity Log Solution, změní stav pomocí aktivity Update Status na Vyřešený

o

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

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í“) 




Zruší – je notifikována skupina MNGSD, aby rozhodnula o oprávněnosti zrušení

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í“) 




Pokud není schopen řešit, předá na jinou skupinu přes operátora o

Manuální notifikace na Operátora L2 co si žádáte a na koho

o

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




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, Emailová 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 zařízení je poškozené, běžný požadavek.

neomezuje funkčnost systému,


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 emailovou 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.


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ě.


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)




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.


Ř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 GORDIC spol. s r.o.

 

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

Popis

Zadaný

Požadavek zadaný do SDM, před kontrolou kategorie, priority a přidělením řešitele

V řešení

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.

Vyřešený

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.

Čeká na součinnost

Řešitel čeká na součinnost, aby mohl pokračovat v řešení

Součinnost poskytnuta

Řešitel dostal potřebné informace a bude pokračovat v řešení

Uzavřený

Požadavek, který je neaktivní a u kterého nebylo řešení rozporováno.

Odmítnutý

Požadavek, který nespadá svým charakterem do oblasti, kterou poskytovatel služeb podporuje, nebo nebyl vznesen oprávněným uživatelem

Zrušený

Požadavek, který již nebude dále řešen

Vypořádaný

Požadavek, který byl zpracován v rámci vypořádání uplynulého období. Není ho možno dále upravovat.


Ke schválení

Požadavek, jehož řešení musí být nejprve schváleno

Reklamace

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ý“.


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.


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.


9.1 Nastavení Service Type STIMSZR Aktivita SZR P2 - 15 minut response SZR P1 - 15 minut response SZR P1 - 20 minut response SZR P1- 23 minut response SZR P2 - 30 minut response SZR P1 - 30 minut response SZR P2 - 45 minut reponse SZR P3 60 minut response SZR P2 - 60 minut reponse SZR P1 - 50% SLA

Událost SZR P2 15 minut response SZR P1 15 minut reponse SZR P1 20 minut response SZR P1 23 minut reponse SZR P2 30 minut response SZR P1 30 minut reponse SZR P2 45 minut reponse SZR P3 60 minut response SZR P2 60 minut reponse SZR P1 50% SLA

Čas od startu Service Type 15 min 15 min 20 min 23 min 30 min 30 min 45 min 1 hod 1 hod 2 hod


SZR P3 - 120 minut reponse SZR P3 - 180 minut reponse SZR P1 - 75% SLA SZR P2 - 50% SLA SZR P1 - SLA Violated SZR P3 - 4 hodin reponse SZR P2 - 75% SLA SZR P4 5 hodin response SZR P2 - SLA Violated SZR P4 12 hodin reponse SZR P3 50% SLA SZR P4 18 hodin reponse SZR P3 75% SLA SZR P4 NBD response SZR P3 SLA Violated SZR P4 50% SLA SZR P4 75% SLA SZR P4 SLA Violated

SZR P3 120 minut reponse SZR P3 180 minut reponse SZR P1 75% SLA SZR P2 50% SLA SZR P1 SLA Violated SZR P3 4 hodin reponse SZR P2 75% SLA SZR P4 6 hodin response SZR P2 SLA Violated SZR P4 12 hodin reponse SZR P3 50% SLA SZR P4 18 hodin reponse SZR P3 75% SLA SZR P4 NBD minut reponse SZR P3 SLA Violated SZR P4 50% SLA SZR P4 75% SLA SZR P4 SLA Violated

2 hod 3 hod 3 hod 3 hod 4 hod 4 hod 3:40 hod 5 hod 6 hod 12 hod 12 hod 18 hod 18 hod 24 hod 24 hod 84 hod 114 hod 168 hod

9.2 Stavy incidentu v průběhu řešení Stav

Popis

Zadaný

Incident zadaný do SDM, před kontrolou kategorie, priority a přidělením řešitele

V řešení

Incident, 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.

Vyřešený

Incident, 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.

Čeká na součinnost

Řešitel čeká na součinnost, aby mohl pokračovat v řešení

Součinnost poskytnuta

Řešitel dostal potřebné informace a bude pokračovat v řešení

Uzavřený

Incident, který je neaktivní a u kterého nebylo řešení rozporováno.

Odmítnutý

Incident, který nespadá svým charakterem do oblasti, kterou poskytovatel služeb podporuje, nebo nebyl vznesen oprávněným uživatelem

Zrušený

Incident, který již nebude dále řešen


Vypořádaný

Incident, který byl zpracován v rámci vypořádání uplynulého období. Není ho možno dále upravovat.

Reklamace

Incident, u něhož byla vznesena oprávněná reklamace řešení


10. Scoreboard 10.1 Definice Scoreboardu pro Operátor L1


10.2 Definice Scoreboardu pro OperátorL2


10.3 Definice Scoreboardu pro Řešitel


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

Recommend Documents